Hash: SHA1

On 01/16/13 12:19, NeilBrown wrote:
> On Wed, 16 Jan 2013 11:28:02 +0200 Igor Grinberg <grinb...@compulab.co.il>
> wrote:
>> 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.

Yes it does for cm-t3730, in fact, that is what we have started from...

> 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.

Ah, one more thing, we ensure that phy is completely powered off through
the TPS power scripts, otherwise, it does not work...

> 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
> N?§²æìr¸?yúè?Øb²X¬¶Ç§vØ^?)Þº{.nÇ+?·¥?{±¢f©?{ayºÊ?Ú?ë,j­¢f£¢·h??àz¹®w¥¢¸
> ¢·¦j:+v?¨?wèjØm¶?ÿ¾«?êçzZ+?ù???Ý¢j"?ú!tml=

- -- 
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to