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

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