-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 16 Jan 2013 11:28:02 +0200 Igor Grinberg <grinb...@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 <grinb...@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 > >>>> <mich...@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 > >>>>>> <grinb...@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-----
