+ anand and moiz if they can pitch in.
I am stuck with some customer defects that I not letting me follow well this thread.

On Jul 12, 2012 1:38 PM, "Émeric Vigier" <emeric.vigier@savoirfairelinux.com> wrote:
Hi all,

Some follow-up on my long lasting issue...
Ming Lei, from Canonical, made me test usb host storage: https://bugs.launchpad.net/linux-linaro/+bug/709245.
It is broken as well, barely 100KBps (with usbmon...). Then my problem does not come from usbnet or smsc95xx.c driver, but probably something with omap ehci and/or omap PM.

I still cannot believe that I am alone using ethernet and usb host on a pandaboard running google official ICS.

Emeric

----- Mail original -----
> Today, I wanted to check ehci PHY was in a correct state. The
> register dump of smsc9514 shows that the chip is always in READY
> state.
> But I can't state concerning omap ehci PHY: there are a lot of
> PM_RUNTIME, clk and regulator things I have to decrypt...
>
> omap4_ehci_init() gets auxclk3_ck and sets it to 19.2MHz. Here is
> what I see:
>
> # cd
> /sys/kernel/debug/clock/virt_38400000_ck/sys_clkin_ck/auxclk3_src_ck
> # for file in `find . -type f`; do echo "$file `cat $file`"; done
> ./auxclk3_ck/auxclkreq3_ck/flags 0x30a21c00
> ./auxclk3_ck/auxclkreq3_ck/rate 19200000
> ./auxclk3_ck/auxclkreq3_ck/usecount 0
> ./auxclk3_ck/flags 0x30a31c00
> ./auxclk3_ck/rate 19200000
> ./auxclk3_ck/usecount 1
> ./flags 0x30a31c00
> ./rate 38400000
> ./usecount 1
>
> "auxclkreq3_ck/usecount" never gets positive, whatever I do (mouse
> event,RX , TX, ...).
> Linaro working release shows the same usecount and flags. So that
> must be fine.
>
> # cat /sys/kernel/debug/prcm-on
>    PD_L3_INIT curr=ON prev=OFF logic=ON
>       CD_L3_INIT mode=SW_WKUP activity=0x2007300
>          USBPHY mode=AUTO idlest=ON optclk=0x100
>          FSUSB mode=ENABLED stbyst=STBY idlest=ON
>          HSUSBHOST mode=ENABLED stbyst=ON idlest=ON
>          HSUSBOTG mode=AUTO stbyst=ON idlest=ON
>          USBTLL mode=AUTO idlest=ON
>          DPLL_USB status=locked
>
> I cannot get this on linaro as prcm-on file does not exist :-(
>
> # cd /sys/kernel/debug/regulator/VUSB
> # for file in `busybox find . -type f`; do echo "$file `cat $file`";
> done
> ./twl6030_usb-vusb/max_uV 0
> ./twl6030_usb-vusb/min_uV 0
> ./twl6030_usb-vusb/uA_load 0
> ./open_count 1
> ./use_count 1
>
> I checked also pm_debug/time and count on both linaro-12.05 and my
> faulty build:
> http://pastebin.com/6AJtEXut
> http://pastebin.com/L0JzVtJy
>
> Unfortunately, /sys/kernel/debug/pm_debug is not present on
> linaro-11.09...
>
> Emeric
>
> ----- Mail original -----
> > De: "Émeric Vigier" <emeric.vigier@savoirfairelinux.com>
> > À: "Michael Malyshev" <mike.malyshev@gmail.com>
> > Cc: "Jassi Brar" <jaswinder.singh@linaro.org>, "linaro-android"
> > <linaro-android@lists.linaro.org>,
> > pandaboard@googlegroups.com, omapandroid-discussion@gforge.ti.com
> > Envoyé: Mercredi 4 Juillet 2012 19:16:00
> > Objet: Re: [Omapandroid-discussion] smsc95xx: download ok, upload
> > hangs
> >
> > With patch reverted, VDD33IO signals look the same as I depicted on
> > Ti forums.
> > I checked VDD33A, and it is 3.3V flat. It never goes low.
> > According to my pandaboard-a-schematic.pdf, both signals should
> > have
> > the same shape as VDD33IO and VDD33A are (supposed to be) connected
> > to VDD_HUB_FLT.
> > But I see different signals, hmmm...
> > I don't know what that means. Any idea?
> >
> > Emeric
> >
> > ----- Mail original -----
> > > De: "Émeric Vigier" <emeric.vigier@savoirfairelinux.com>
> > > À: "Michael Malyshev" <mike.malyshev@gmail.com>
> > > Cc: "Jassi Brar" <jaswinder.singh@linaro.org>, "linaro-android"
> > > <linaro-android@lists.linaro.org>,
> > > pandaboard@googlegroups.com, omapandroid-discussion@gforge.ti.com
> > > Envoyé: Mercredi 4 Juillet 2012 18:48:38
> > > Objet: Re: [Omapandroid-discussion] smsc95xx: download ok, upload
> > > hangs
> > >
> > > Hi Michael,
> > >
> > > Ok, I will get back to the schematics and try some probing again.
> > > 9514.pdf is the datasheet I have on my side as well. But it lacks
> > > register descriptions... Steve Glendinning told me the only
> > > public
> > > register description lies in smsc95xx.h. I suppose I should
> > > consider
> > > this great enough...
> > >
> > > I narrowed down the patches touching drivers/usb/host/ehci-omap.c
> > > which are in my (faulty) kernel, but not on the (working) linaro
> > > one.
> > > I reverted them all one by one with following status:
> > >
> > >     Revert "mfd: Add omap-usbhs runtime PM support"
> > >     This reverts commit 1233c937d09450956989953841837445aff09336.
> > >  => FAILED
> > >
> > >     Revert "arm: omap: usb: global Suspend and resume support of
> > >     ehci
> > >     and ohci"
> > >     This reverts commit 8e9aaf5c4051a8051a87d5fde67141ae062a2f04.
> > >  => FAILED
> > >
> > >     Revert "usb: ehci-omap: fix clock enabling in shutdown path"
> > >     This reverts commit 33a2170896e4f52b504b1fb06e885b4505c69f05.
> > >  => FAILED
> > >
> > >     Revert "OMAP4: USBHS: Enable remote wakeup using I/O pads"
> > >     This reverts commit e50bc2a90c69d09a5fee40f1afaebf19bd559352.
> > >     Conflicts:
> > >         arch/arm/mach-omap2/pm44xx.c
> > >  => FAILED, although I fixed/hacked the conflict
> > >
> > >     Revert "usb: ehci-omap: control transceiver clock"
> > >     This reverts commit 43deff8560f2395cb833a21d1e0cf518182f086f.
> > >  => FAILED
> > >
> > > Previously, with Manuel from Ti, I checked that VDD33IO was fine:
> > > http://e2e.ti.com/support/omap/f/849/p/196732/705274.aspx#705274
> > > I pushed a drawing of my scope capture.
> > >
> > > I will if my patch revert have changed anything to this power
> > > signal.
> > >
> > > Thanks,
> > > Emeric
> > >
> > > ----- Mail original -----
> > > > De: "Michael Malyshev" <mike.malyshev@gmail.com>
> > > > À: "Émeric Vigier" <emeric.vigier@savoirfairelinux.com>
> > > > Cc: "Jassi Brar" <jaswinder.singh@linaro.org>, "linaro-android"
> > > > <linaro-android@lists.linaro.org>,
> > > > pandaboard@googlegroups.com,
> > > > omapandroid-discussion@gforge.ti.com
> > > > Envoyé: Mercredi 4 Juillet 2012 17:33:55
> > > > Objet: Re: [Omapandroid-discussion] smsc95xx: download ok,
> > > > upload
> > > > hangs
> > > >
> > > > it worth a try to monitor signals on PM pins of
> > > > ETH chip using oscilloscope
> > > >
> > > >
> > > > On Thu, Jul 5, 2012 at 1:31 AM, Michael Malyshev <
> > > > mike.malyshev@gmail.com > wrote:
> > > >
> > > >
> > > > the datasheet for the chip is here
> > > >
> > > > http://www.smsc.com/media/Downloads_Public/Data_Sheets/9514.pdf
> > > >
> > > > reading this paper I noticed that power management is shared
> > > > between
> > > > USB and ETH. I think that when you move your mouse ETH is waken
> > > > up
> > > > because USB is waken up. the datasheet says
> > > >
> > > > "Many customers use a single poly fuse to power all their
> > > > devices.
> > > > For the ganged situation, all power
> > > > control pins must be tied together"
> > > >
> > > > I think you need to check the schematics for your board and
> > > > analyze
> > > > how PM is implemented. I had problems with TI's implementation
> > > > of
> > > > ETH support on other boards. It always was a low priority for
> > > > some
> > > > reason. Maybe because Linux kernel is being updated too often
> > > > and
> > > > ETH is not that required.
> > >
> > >
> > >
> > > >
> > > > as a conclusion I would look into PM implementation differences
> > > > in
> > > > working and non-working kernels including PLL and power domain
> > > > configurations
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Jul 4, 2012 at 11:45 PM, Émeric Vigier <
> > > > emeric.vigier@savoirfairelinux.com > wrote:
> > > >
> > > >
> > > > ----- Mail original -----
> > > > > De: "Jassi Brar" < jaswinder.singh@linaro.org >
> > > > > À: "Émeric Vigier" < emeric.vigier@savoirfairelinux.com >
> > > > > Cc: "Vikram Pandita" < vikram.pandita@ti.com >,
> > > > > "linaro-android"
> > > > > <
> > > > > linaro-android@lists.linaro.org >,
> > > > > pandaboard@googlegroups.com ,
> > > > > omapandroid-discussion@gforge.ti.com
> > > > > Envoyé: Mercredi 4 Juillet 2012 11:22:29
> > > >
> > > > > Objet: Re: [Omapandroid-discussion] smsc95xx: download ok,
> > > > > upload
> > > > > hangs
> > > > >
> > > > > On 4 July 2012 18:51, Émeric Vigier
> > > >
> > > > > < emeric.vigier@savoirfairelinux.com > wrote:
> > > > > >
> > > > > > Disabling CONFIG_CPU_IDLE does not improve anything, TX
> > > > > > remains
> > > > > > stuck.
> > > > > > Interrupt 109 ehci_usb:usb1 occurs, I logged usb_hcd_irq
> > > > > > successfully, but only on when RX i on-going. When it
> > > > > > occurs,
> > > > > > my
> > > > > > TX gets resumed for some time.
> > > > > > When I move my mouse, dozen of 109 interrupts occurs, then
> > > > > > TX
> > > > > > gets
> > > > > > resumed for a longer period. And eventually got stuck
> > > > > > again.
> > > > > >
> > > > > > I made a usbmon trace yesterday. I am not a USB expert, but
> > > > > > if
> > > > > > someone in the room finds something (not) obvious (to me),
> > > > > > that
> > > > > > would make my day (week actually...).
> > > > > > http://pastebin.com/v9GXn5Z7
> > > > > >
> > > > > Perhaps someone could relieve me of my naivety, but I think
> > > > > unlike
> > > > > mouse/keyboard input and ethernet RX, the TX isn't triggered
> > > > > by
> > > > > any
> > > > > interrupt, so WFI not moving on is only natural ?
> > > >
> > > > You may be right, I only see interrupts in usbmon traces when I
> > > > moved
> > > > my USB mouse.
> > > > The fact that mouse activity resumes TX activity would then not
> > > > be
> > > > related to interrupts, but something else.
> > > > Argh... I hate making assumptions, because I know it is the
> > > > worst
> > > > way
> > > > to debug a problem.
> > > >
> > > >
> > > > I booted linaro kernel built with panda_defconfig, and my
> > > > current
> > > > android images. Android zygote did not start, but I could test
> > > > eth0
> > > > from command line anyway.
> > > > Not surprisingly, TX worked fine, achieving ~10MBps (compared
> > > > to
> > > > 20KBps when TX gets stuck).
> > > >
> > > > The panda_defconfig from linaro and mine has only
> > > > CONFIG_DYNAMIC_DEBUG difference. Then my bug must come from the
> > > > sources:
> > > > $ git diff kernel_linaro/drivers/usb kernel/drivers/usb >
> > > > linaro-11.09_android-omap-panda-3.0_kernel-drivers-usb.diff
> > > > http://pastebin.com/Cdas1SMc
> > > >
> > > > There is a huge part concerning PM_RUNTIME in
> > > > drivers/usb/host/ehci-omap.c that looks suspect...
> > > > I will try without related patches.
> > > >
> > > > $ git diff kernel_linaro/drivers/net/usb kernel/drivers/net/usb
> > > > only contains diffs on cdc_ncm.c, asix.c. Not interesting...
> > > >
> > > > $ git diff kernel_linaro/drivers/net kernel/drivers/net
> > > > has huge differences... But I prefer to ignore them for now.
> > > >
> > > > git diff kernel_linaro/arch/arm/mach-omap2
> > > > kernel/arch/arm/mach-omap2
> > > > has huge differences as well... The omap44xx_usbhs_ehci_hwmod
> > > > is
> > > > not
> > > > present in linaro kernel for instance.
> > > >
> > > >
> > > > Regards,
> > > >
> > > >
> > > > Emeric
> > > >
> > > > _______________________________________________
> > > > Omapandroid-discussion mailing list
> > > > Omapandroid-discussion@gforge.ti.com
> > > > https://gforge.ti.com/mailman/listinfo/omapandroid-discussion
> > > >
> > > >
> > > >
> >

--
Emeric

_______________________________________________
Omapandroid-discussion mailing list
Omapandroid-discussion@gforge.ti.com
https://gforge.ti.com/mailman/listinfo/omapandroid-discussion