Re: Help wanted with USB and OMAP3 off_mode

[NeilBrown <neilb@suse.de>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 16 Jan 2013 11:28:02 +0200 Igor Grinberg <grinberg@compulab.co.il>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 01/16/13 09:26, NeilBrown wrote:
> > On Wed, 09 Jan 2013 14:54:00 +0200 Igor Grinberg <grinberg@compulab.co.il>
> > wrote:
> > 
> >> On 01/09/13 14:08, Michael Trimarchi wrote:
> >>> Hi Neil
> >>>
> >>> I forget to answer to your questions
> >>>
> >>> On 01/09/2013 12:34 PM, NeilBrown wrote:
> >>>> On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi
> >>>> <michael@amarulasolutions.com> wrote:
> >>>>
> >>>>> Hi Neil
> >>>>>
> >>>>> On 01/09/2013 11:19 AM, NeilBrown wrote:
> >>>>>> On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg <grinberg@compulab.co.il>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>>>>> Hash: SHA1
> >>>>>>
> >>>>>>> Hi Neil,
> >>>>>>
> >>>>>>> On 01/09/13 00:29, NeilBrown wrote:
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>  I'm trying to get off_mode working reliably on my gta04 mobile phone.
> >>>>>>>>
> >>>>>>>> My current stumbling block is USB.  The "Option" GSM module is attached via
> >>>>>>>> USB (there is a separate transceiver chip attached to port 1 which is placed
> >>>>>>>> in OMAP_EHCI_PORT_MODE_PHY).
> >>>>>>
> >>>>>>> Which PHY is this (vendor/model)?
> >>>>>>
> >>>>>> Hi Igor,
> >>>>>>   it is the SMSC USB3322
> >>>>>>
> >>>>>> http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf
> >>>>>>
> >>>>>>
> >>>>>> BTW I subsequently discovered that keeping USBHOST out off off_mode only
> >>>>>> sometimes avoid the problem, not always.  So there are probably multiple
> >>>>>> issues :-(
> >>
> >> We have the same PHY and it has some issues with the OMAP USB code.
> >> First issue we experience is that if we reset the PHY more then once
> >> w/o power cycling it, the PHY dies until next power cycle.
> >> So, we stop providing the reset GPIO to the usb code and do the reset
> >> in the board code.
> > 
> > I've tried various change w.r.t the resetting and  I cannot fault it.
> > Resetting or not resetting neither causes a problem while the USB is
> > otherwise working, not fixed the USB while  it is otherwise failing.
> > So I don't think this is my problem - thanks.
> > 
> >>
> >>>>>
> >>>>> Are you sure that you don't have glitch on power, reset pin during suspend?
> >>>>>
> >>>>
> >>>> No, I don't really have the equipment to measure such things.
> >>>> But is it likely?  Would enabling off_mode make it more likely?
> >>>
> >>> I don't know the reason of the off_mode problem :(
> >>
> >> We have the equipment to check this and no - this is not the case.
> >>
> >>>
> >>>> Can you suggest some way I could test the hypothesis?
> >>>
> >>> I had the same problem on a rugged mobile phone, so it is just experience
> >>> Check the modem power and reset gpio too, but if you don't need to unblock it
> >>> with the pin after resume we know that modem is not the problem
> >>
> >> I don't think modem is the problem...
> >> We have plain USB connector ports that are dead after the resume from off-mode.
> >>
> >> The good news are that we have the off-mode working on v3.6.1,
> >> including the USB, but we had to do some horrible ugly hacking for this.
> >>
> > 
> > I assume this  means "some patches on top of 3.6.1" ??
> > Care to share your code?  Even horribly ugly hacks can be educational.
> 
> We are not ready to share these patches (this will happen eventually
> after some work is finished), but I can explain what they do...
> 
> We split the ehci_run function to separate the debugfs and sysfs stuff from
> other initializations, so we can run the new version without the debugfs and
> sysfs stuff multiple times.
> 
> Then we implement the suspend/resume ehci callbacks:
> on suspend, assert phy reset,
> on resume, deassert phy reset, write EHCI_INSNREG04_DISABLE_UNSUSPEND to
> EHCI_INSNREG04, and call the new ehci_run() function.
> 
> That does the job for USB host to resume from off mode.

Interesting thanks.  That makes a certain amount of sense.

However I tried compiling ehci-hcd as a module and  unload/reloading it which
should have a similar net effect to what you did, but it didn't make any
difference - device disappears on resume.

I also tried restoring the correct value to EHCI_INSNREG04 and
EHCI_INSNREG05_ULPI which are the only registers written by 
ehci-omap.c, and that didn't help either.

The only thing I've found that works is keeping 'core' out of off-mode.

BTW I discovered that arch/arm/mach-omap2/powerdomains3xxx_data.c
comments out the setting of 
  .flags    = PWRDM_HAS_HDWR_SAR,
for the usbhost powerdomain - that is why I had to leave it in retention.
If I uncomment that setting, the it is safe for USBHOST to go to off-mode,
just not for CORE.

I'll keep exploring.

NeilBrown
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQIVAwUBUPZ+rznsnt1WYoG5AQLYug//T+J3L11fwVq8JHfiPJVfbEfrAdx96+Id
OD+qpwWUarWfpxcgthuRmkrxxUSXxI8sBr0Y0wKWRw4biFxtzcY3qk5xnlUMCfFx
BuqrevVZ6bQZ3JDORv1OfeRwZXOheW0ocJ50s1aV8QTTZvrTKo0TNv7G2uLYIssK
vafA1WOTQPWAxMd7gx8qjpbT/HPi2kYaLlEJ1/kXYeylGboncUyus42j1q1qnGqy
xN6031rpwba4CXtXysx830/uPrnr3LPCh15HUUpxHsYB8rey+60F0ClbT72ZqajJ
w1Cy1GR+UDAM7DP3wt1z87H6/IHRXpJLVodUQ5LIZezbWYF1CbAcyJoSyrjZhefe
yQnGrFaxHS9oNwaZpDOccxGCPOt8uY5DBRMtEpQKt+3LR0lFJzeICMpfENyMg+3a
mU+fzVfGs0puyg/Imcds5yrpmjtGDzuF0yIZ2pIW8pcWjJwbYVzaw9TfzYSSALv1
VaJp7DItUw9JreBtyb7W4P3KvLjH1GAHjPSFBU4iWhXF6JmQnG6ntDeH+eKNpO2F
0BcaxhP8Ll1kWif+cf0gIVBMBTjbBaWYkD8zPpXAnEI+FHNdxT5knbohMDPVjR1A
W5rYHvzpa04N/DQSVJVq7zBbAs0QkYGLtC03b9ebk7Y9z7HS/KdzZafqW0Gr50j7
DqBKnGA/0GE=
=srfM
-----END PGP SIGNATURE-----