Help wanted with USB and OMAP3 off_mode

Message ID	20130109092915.1c2077b5@notabene.brown (mailing list archive)
State	New, archived
Headers	show Return-Path: <linux-omap-owner@vger.kernel.org> Date: Wed, 9 Jan 2013 09:29:15 +1100 From: NeilBrown <neilb@suse.de> To: linux-omap@vger.kernel.org Subject: Help wanted with USB and OMAP3 off_mode Message-ID: <20130109092915.1c2077b5@notabene.brown> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/i/wOCVT5oDITxlHN6o2OTNA"; protocol="application/pgp-signature" Sender: linux-omap-owner@vger.kernel.org Precedence: bulk

NeilBrown Jan. 8, 2013, 10:29 p.m. UTC

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

After a suspend/resume cycle with off_mode enabled the GSM module disappears.
i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't
exist.
Without off mode, the modem always appears after resume.

I discovered that the registers set by:

   drivers/mfd/omap-usb-host.c

are not maintained across as suspend/resume so I added the following patch
(which I can make a formal submission of if it looks right to others), but
that didn't help (or didn't help enough).

If I

  echo 1 > /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend

thus keeping just the USBHOST power domain out of off_mode, the GSM module
doesn't disappear.  So it seems that some context in the usbhost domain is
not being save and restored.

This is as far as I can get.  Can someone suggest where I should look to find
out what is not being saved/restored properly, and how to go about saving and
restoring?

Thanks in advance,
NeilBrown

Igor Grinberg Jan. 9, 2013, 10 a.m. UTC | #1

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

> 
> After a suspend/resume cycle with off_mode enabled the GSM module disappears.
> i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't
> exist.
> Without off mode, the modem always appears after resume.
> 
> I discovered that the registers set by:
> 
>    drivers/mfd/omap-usb-host.c
> 
> are not maintained across as suspend/resume so I added the following patch
> (which I can make a formal submission of if it looks right to others), but
> that didn't help (or didn't help enough).
> 
> If I
> 
>   echo 1 > /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend
> 
> thus keeping just the USBHOST power domain out of off_mode, the GSM module
> doesn't disappear.  So it seems that some context in the usbhost domain is
> not being save and restored.
> 
> This is as far as I can get.  Can someone suggest where I should look to find
> out what is not being saved/restored properly, and how to go about saving and
> restoring?
> 
> Thanks in advance,
> NeilBrown
> 
> 
> 
> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
> index 23cec57..522405e 100644
> --- a/drivers/mfd/omap-usb-host.c
> +++ b/drivers/mfd/omap-usb-host.c
> @@ -100,6 +100,10 @@ struct usbhs_hcd_omap {
>  
>  	void __iomem			*uhh_base;
>  
> +	struct {
> +		unsigned		hostconfig;
> +	} context;
> +
>  	struct usbhs_omap_platform_data	platdata;
>  
>  	u32				usbhs_rev;
> @@ -300,6 +304,10 @@ static int usbhs_runtime_resume(struct device *dev)
>  	clk_enable(omap->utmi_p1_fck);
>  	clk_enable(omap->utmi_p2_fck);
>  
> +	usbhs_write(omap->uhh_base,
> +		    OMAP_UHH_HOSTCONFIG,
> +		    omap->context.hostconfig);
> +
>  	spin_unlock_irqrestore(&omap->lock, flags);
>  
>  	return 0;
> @@ -319,6 +327,8 @@ static int usbhs_runtime_suspend(struct device *dev)
>  	}
>  
>  	spin_lock_irqsave(&omap->lock, flags);
> +	omap->context.hostconfig = usbhs_read(omap->uhh_base,
> +					      OMAP_UHH_HOSTCONFIG);
>  
>  	if (is_ehci_tll_mode(pdata->port_mode[0]))
>  		clk_disable(omap->usbhost_p1_fck);

- -- 
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQ7T+kAAoJEBDE8YO64Efaj8YQAI5nOE9vvf8wxbu5IXTxaMxn
6B+g2m/zkMlyVNL5hTrwkPkP4CTBwvsGCZYkZT5JS3KM+R+TuyIX07+eM59Ie0Po
u1CCn2XKZY2CP53b3nAtgk9Phxwruf5fDjEu9QiQapdUpbiTWmIn8W3CVye241O2
wXBKAXszX1bD81NFNY+Jm5Us5uGHNTtNtqe78Rng7BTvmaaNgE61PurFclgn0xQb
IO5E7eyq7TG1u/IBhge2jlZGx2BbLcVsrQI3WyuE2L6F+MRgAKBDD7K8uHTfxPyM
eXAk/u5tbA21t1mTIXk19N4c0YVgeFW2kKQOPShKywy9J6k3tE5LE4yUjooo4ZeS
TlIf7HFcp15N3FfX90FOYsQOXILnoNL6a8SOK3gU+iVxZU/4VohKOXBlMjuZ7o10
5FnglPaHjsEaa1DgB/FcnYh3OO33mODJsckUhi5GiIlrbm70JspfWShZfln1k8FS
SwClmyb6FCiqBOcRJ2uS1KTwObzYV9WeuPGCTXC5d4UBB57eRcGcX/NvSftV57mX
jcSEle93kgZx1EiG53Vwd29oV9nU6SJECF7Q8CqulDEQVr76E7Xh8Z1CrsD+BhKe
XuFa3zdtMg1SZO/ctcTIPPpElCVPF1FChX2lY9fCIdK2luHNrOs4GyrozCGXQcXO
ZMFiiStsjr021CGqQUFw
=yIA2
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

NeilBrown Jan. 9, 2013, 10:19 a.m. UTC | #2

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

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

NeilBrown



> 

> > 

> > After a suspend/resume cycle with off_mode enabled the GSM module disappears.

> > i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't

> > exist.

> > Without off mode, the modem always appears after resume.

> > 

> > I discovered that the registers set by:

> > 

> >    drivers/mfd/omap-usb-host.c

> > 

> > are not maintained across as suspend/resume so I added the following patch

> > (which I can make a formal submission of if it looks right to others), but

> > that didn't help (or didn't help enough).

> > 

> > If I

> > 

> >   echo 1 > /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend

> > 

> > thus keeping just the USBHOST power domain out of off_mode, the GSM module

> > doesn't disappear.  So it seems that some context in the usbhost domain is

> > not being save and restored.

> > 

> > This is as far as I can get.  Can someone suggest where I should look to find

> > out what is not being saved/restored properly, and how to go about saving and

> > restoring?

> > 

> > Thanks in advance,

> > NeilBrown

> > 

> > 

> > 

> > diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c

> > index 23cec57..522405e 100644

> > --- a/drivers/mfd/omap-usb-host.c

> > +++ b/drivers/mfd/omap-usb-host.c

> > @@ -100,6 +100,10 @@ struct usbhs_hcd_omap {

> >  

> >  	void __iomem			*uhh_base;

> >  

> > +	struct {

> > +		unsigned		hostconfig;

> > +	} context;

> > +

> >  	struct usbhs_omap_platform_data	platdata;

> >  

> >  	u32				usbhs_rev;

> > @@ -300,6 +304,10 @@ static int usbhs_runtime_resume(struct device *dev)

> >  	clk_enable(omap->utmi_p1_fck);

> >  	clk_enable(omap->utmi_p2_fck);

> >  

> > +	usbhs_write(omap->uhh_base,

> > +		    OMAP_UHH_HOSTCONFIG,

> > +		    omap->context.hostconfig);

> > +

> >  	spin_unlock_irqrestore(&omap->lock, flags);

> >  

> >  	return 0;

> > @@ -319,6 +327,8 @@ static int usbhs_runtime_suspend(struct device *dev)

> >  	}

> >  

> >  	spin_lock_irqsave(&omap->lock, flags);

> > +	omap->context.hostconfig = usbhs_read(omap->uhh_base,

> > +					      OMAP_UHH_HOSTCONFIG);

> >  

> >  	if (is_ehci_tll_mode(pdata->port_mode[0]))

> >  		clk_disable(omap->usbhost_p1_fck);

> 

> - -- 

> Regards,

> Igor.

> -----BEGIN PGP SIGNATURE-----

> Version: GnuPG v2.0.17 (GNU/Linux)

> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

> 

> iQIcBAEBAgAGBQJQ7T+kAAoJEBDE8YO64Efaj8YQAI5nOE9vvf8wxbu5IXTxaMxn

> 6B+g2m/zkMlyVNL5hTrwkPkP4CTBwvsGCZYkZT5JS3KM+R+TuyIX07+eM59Ie0Po

> u1CCn2XKZY2CP53b3nAtgk9Phxwruf5fDjEu9QiQapdUpbiTWmIn8W3CVye241O2

> wXBKAXszX1bD81NFNY+Jm5Us5uGHNTtNtqe78Rng7BTvmaaNgE61PurFclgn0xQb

> IO5E7eyq7TG1u/IBhge2jlZGx2BbLcVsrQI3WyuE2L6F+MRgAKBDD7K8uHTfxPyM

> eXAk/u5tbA21t1mTIXk19N4c0YVgeFW2kKQOPShKywy9J6k3tE5LE4yUjooo4ZeS

> TlIf7HFcp15N3FfX90FOYsQOXILnoNL6a8SOK3gU+iVxZU/4VohKOXBlMjuZ7o10

> 5FnglPaHjsEaa1DgB/FcnYh3OO33mODJsckUhi5GiIlrbm70JspfWShZfln1k8FS

> SwClmyb6FCiqBOcRJ2uS1KTwObzYV9WeuPGCTXC5d4UBB57eRcGcX/NvSftV57mX

> jcSEle93kgZx1EiG53Vwd29oV9nU6SJECF7Q8CqulDEQVr76E7Xh8Z1CrsD+BhKe

> XuFa3zdtMg1SZO/ctcTIPPpElCVPF1FChX2lY9fCIdK2luHNrOs4GyrozCGXQcXO

> ZMFiiStsjr021CGqQUFw

> =yIA2

> -----END PGP SIGNATURE-----


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

iQIVAwUBUO1EMznsnt1WYoG5AQJ9Gg//Qwx5P/VjOi+9TDXIGr10OqldLEQKG4zv
Dbwhw5l9DR85JIuF+m5xVXUe9IWJZ0UCasi61LtkRJVGW8U7Lv0O2mmXcYHoQ9zt
diph8SVM9ZTh4SAaz2iiHeJ1Sqz0WkiZ47Kv1C0Q/n9MyFqKKG7Nxg5UAyAj39x4
pa8vsBGcPmwn5U/dUPQBxs3QKdp9aI3i2I6Q6vObRLYLJSvxAeXkGYfrmMy/NoZz
RNhkLhVTajPCYTBcPw+zH06Pv8VF+i/UwFggnVl+uW+6LrIpKbaLa7CMntXmrSgz
fi7y1LLiQuE7qK26IizLu/XIapb0tPGy28AebYwSbjFTaqHPNmlLAzyfww3lBteI
PS76DulKiR4YX58v0KGKITcYLKK3mUliOETcWylot2eTyqbP9m0Y3nX57AEDi0+N
FBBuoG4EKUQaLf5CnjF6ViMttUfvcfwL+Vrn+4VaYndS9S9w5IXTii5b1OcuhJaZ
aGS+Tm/Mwa1uNQWBjujc/DdvwKZRrRilHTBH4w/rHRwxNTqKAxWmq72162efpxdR
JxkHrPTEZZZwLewPXmTbD1+h50284apAw+D2PERFiB+Fh4ZVzsLIcBcUIZ3OT4L1
AlrqYC0wAS2RgjhvmveR360i8DS1SXMMafonrLhrwRu7oe1uzltKmnNX21Sp76vB
gM5LIokwosA=
=8VnD
-----END PGP SIGNATURE-----

NeilBrown Jan. 9, 2013, 11:34 a.m. UTC | #3

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 :-(
> 
> 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?
Can you suggest some way I could test the hypothesis?

The power pin is connected to a 3v3 regulator which certainly should stay on
the whole time and other things which depend on it keep working.

The reset line is connected to GPIO174 which is configured:

# cat /sys/kernel/debug/omap_mux/mcspi1_cs0
name: mcspi1_cs0.gpio_174 (0x480021ce/0x19e = 0x011c), b ac2, t NA
mode: OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE4
signals: mcspi1_cs0 | sdmmc2_dat7 | NA | NA | gpio_174 | NA | NA | safe_mode

The "PIN_INPUT" seems a bit odd, so I changed it to OMAP_PIN_OUTPUT but that
didn't appear to make any difference.

Thanks,
NeilBrown

Michael Nazzareno Trimarchi Jan. 9, 2013, 11:42 a.m. UTC | #4

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 :-(
>>
>> 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?
> Can you suggest some way I could test the hypothesis?
> 
> The power pin is connected to a 3v3 regulator which certainly should stay on
> the whole time and other things which depend on it keep working.
> 
> The reset line is connected to GPIO174 which is configured:
> 
> # cat /sys/kernel/debug/omap_mux/mcspi1_cs0
> name: mcspi1_cs0.gpio_174 (0x480021ce/0x19e = 0x011c), b ac2, t NA
> mode: OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE4
> signals: mcspi1_cs0 | sdmmc2_dat7 | NA | NA | gpio_174 | NA | NA | safe_mode
> 
> The "PIN_INPUT" seems a bit odd, so I changed it to OMAP_PIN_OUTPUT but that
> didn't appear to make any difference.
> 

Can you try to add this OMAP_PIN_OFF_OUTPUT_HIGH or LOW? It's suppose to be the off_mode status of the pin.
Is it correct?


Michael




> Thanks,
> NeilBrown
>

Michael Nazzareno Trimarchi Jan. 9, 2013, 12:08 p.m. UTC | #5

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

> 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

Michael

> 
> The power pin is connected to a 3v3 regulator which certainly should stay on
> the whole time and other things which depend on it keep working.
> 
> The reset line is connected to GPIO174 which is configured:
> 
> # cat /sys/kernel/debug/omap_mux/mcspi1_cs0
> name: mcspi1_cs0.gpio_174 (0x480021ce/0x19e = 0x011c), b ac2, t NA
> mode: OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE4
> signals: mcspi1_cs0 | sdmmc2_dat7 | NA | NA | gpio_174 | NA | NA | safe_mode
> 
> The "PIN_INPUT" seems a bit odd, so I changed it to OMAP_PIN_OUTPUT but that
> didn't appear to make any difference.
> 
> Thanks,
> NeilBrown
> 

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

Igor Grinberg Jan. 9, 2013, 12:54 p.m. UTC | #6

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.

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

NeilBrown Jan. 16, 2013, 7:26 a.m. UTC | #7

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.

Thanks,
NeilBrown

NeilBrown Jan. 16, 2013, 7:28 a.m. UTC | #8

On Wed, 09 Jan 2013 12:42:43 +0100 Michael Trimarchi
<michael@amarulasolutions.com> wrote:

> 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 :-(
> >>
> >> 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?
> > Can you suggest some way I could test the hypothesis?
> > 
> > The power pin is connected to a 3v3 regulator which certainly should stay on
> > the whole time and other things which depend on it keep working.
> > 
> > The reset line is connected to GPIO174 which is configured:
> > 
> > # cat /sys/kernel/debug/omap_mux/mcspi1_cs0
> > name: mcspi1_cs0.gpio_174 (0x480021ce/0x19e = 0x011c), b ac2, t NA
> > mode: OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE4
> > signals: mcspi1_cs0 | sdmmc2_dat7 | NA | NA | gpio_174 | NA | NA | safe_mode
> > 
> > The "PIN_INPUT" seems a bit odd, so I changed it to OMAP_PIN_OUTPUT but that
> > didn't appear to make any difference.
> > 
> 
> Can you try to add this OMAP_PIN_OFF_OUTPUT_HIGH or LOW? It's suppose to be the off_mode status of the pin.
> Is it correct?
> 

You only set OMAP_PIN_OFF_OUTPUT_HIGH etc if you want the status  in
offmode to be different to what is was before off mode.
In the normal case without any of these bits set, the current value is
latched when output in entered and it remains like that that until you
leave off_mode.

Thanks,
NeilBrown

Igor Grinberg Jan. 16, 2013, 9:28 a.m. UTC | #9

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

- -- 
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQ9nKiAAoJEBDE8YO64Efa7U4QAKFXRyyNR5Q7jjwVG6UwITWq
6kJyNXJKQTqn6GLEV7xJmT4SZAtxq+dRDl/XE9dcXFK3RTebttXxyVz1X0vXZQud
h6QLenH8jHczNubfn6CTLI38PKprl1F2zpZtjKpHfNmD5cLWzJ1EIoTH19ENsJ4v
zV3KI3RgiFuq02vxOULtp9gP/x0WZSHwBEGm/ToqqsEaX7wAJc2BDFOSS8NpSGbb
VLPFA1doMrFOYkL+oMS2IVudM0wEYCBGhGxMi/Y++RY1omlonhEGCoVxaxzGoHrk
H/ZpxFheIGBKwo+VX1eSgW9oQZyzbPZttyEWXXNCRh/6oejXCBSS3zkKrWrctmVD
ONu1gzoaC9p/c1n2GDioIfxC41dPKdjCETMbTi9rR5shc12ZmwtrgUOU80mpzWj3
6fY+TRW4x8qYbsFL89T6TWGpDz7JrBdtdJiBD/TPtJW05ikn9DTL5/GNVjeeoRk0
5DJ06pHh+rQFKThEvoDdLAH3PZdtDVSdXnAg+gF4D7/BMZ14TLHmW2l471I95S2I
eKxZxIwFa2IscTbGKhTlrdPF4UShEvLuFgO6NCb1ea1FT7m3ih8rwA5ObI4676DG
Y5kokqi9dpzMB/6T/SDk/gySTg9WUDXFlhS6x/b89f1xC71GzGTJkkqqH4u6KfX8
GcqI3wEFlqpG4FM39XAw
=nynZ
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Roger Quadros Jan. 16, 2013, 10 a.m. UTC | #10

On 01/09/2013 12:29 AM, 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).
> 
> After a suspend/resume cycle with off_mode enabled the GSM module disappears.
> i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't
> exist.
> Without off mode, the modem always appears after resume.
> 
> I discovered that the registers set by:
> 
>    drivers/mfd/omap-usb-host.c
> 
> are not maintained across as suspend/resume so I added the following patch
> (which I can make a formal submission of if it looks right to others), but
> that didn't help (or didn't help enough).
> 
> If I
> 
>   echo 1 > /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend
> 
> thus keeping just the USBHOST power domain out of off_mode, the GSM module
> doesn't disappear.  So it seems that some context in the usbhost domain is
> not being save and restored.
> 
> This is as far as I can get.  Can someone suggest where I should look to find
> out what is not being saved/restored properly, and how to go about saving and
> restoring?

You need to ensure that USBHOST/TLL context is saved as per the Save and
Restore sequence see section "USBHOST/USBTLL Save-and-Restore
Management" in the OMAP Technical Reference Manual.

The basic idea there is that software does the context saving into SAR
RAM before entering OFF mode and hardware automatically restores the
context after coming out of OFF mode.

But that alone is not enough for USB host to work. We need to make sure
we have covered all the erratas. There are a number of them which are
not covered yet in mainline.

USB remote wakeup is another challenge with OMAP USB host (while in OFF
mode). The usual workaround here is to use a GPIO as a wakeup line from
the modem.

regards,
-roger

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

NeilBrown Jan. 16, 2013, 10:19 a.m. UTC | #11

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

NeilBrown Jan. 16, 2013, 10:27 a.m. UTC | #12

On Wed, 16 Jan 2013 12:00:48 +0200 Roger Quadros <rogerq@ti.com> wrote:

> On 01/09/2013 12:29 AM, 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).
> > 
> > After a suspend/resume cycle with off_mode enabled the GSM module disappears.
> > i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't
> > exist.
> > Without off mode, the modem always appears after resume.
> > 
> > I discovered that the registers set by:
> > 
> >    drivers/mfd/omap-usb-host.c
> > 
> > are not maintained across as suspend/resume so I added the following patch
> > (which I can make a formal submission of if it looks right to others), but
> > that didn't help (or didn't help enough).
> > 
> > If I
> > 
> >   echo 1 > /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend
> > 
> > thus keeping just the USBHOST power domain out of off_mode, the GSM module
> > doesn't disappear.  So it seems that some context in the usbhost domain is
> > not being save and restored.
> > 
> > This is as far as I can get.  Can someone suggest where I should look to find
> > out what is not being saved/restored properly, and how to go about saving and
> > restoring?
> 
> You need to ensure that USBHOST/TLL context is saved as per the Save and
> Restore sequence see section "USBHOST/USBTLL Save-and-Restore
> Management" in the OMAP Technical Reference Manual.
> 
> The basic idea there is that software does the context saving into SAR
> RAM before entering OFF mode and hardware automatically restores the
> context after coming out of OFF mode.

Is it?  The way I read the doco, the hardware both saves to SAR RAM, and
restores from  SAR RAM.
  Section 22.2.4.1.6  Save and Restore
of my copy of the TRM says:

> The save-and-restore (SAR) mechanism can extract the hardware context of the high-speed USB host
> controller (after all USB activity has been suspended) before switching off (=save), save it to an external
> always-on memory, and reinject it later after the module has been switched on again and reset (=restore)
> seamlessly for the USB. Part of that context is composed of the register fields described in the current
> chapter. The rest of the context is composed of the "buried" flip-flops and memories (not accessible by
> software) like finite state-machine (FSM) states, buffer contents, and miscellaneous random logic bits.

which strongly suggests that it is all handled by hardware.  Of course there
are other registers that aren't covered  by the SAR - we need to identify
those and make sure they are saved and restored.  I've found a few registers
that aren't being restored, but restoring them hasn't made a visible
difference yet.

Am I missing something?

> 
> But that alone is not enough for USB host to work. We need to make sure
> we have covered all the erratas. There are a number of them which are
> not covered yet in mainline.

Is there a list somewhere?

> 
> USB remote wakeup is another challenge with OMAP USB host (while in OFF
> mode). The usual workaround here is to use a GPIO as a wakeup line from
> the modem.

Yes, this is not a problem for my device.  There is a GPIO line which signals
and incoming SMS or Call and it successfully wakes the device.

> 
> regards,
> -roger

Thanks,
NeilBrown

Roger Quadros Jan. 16, 2013, 10:57 a.m. UTC | #13

On 01/16/2013 12:27 PM, NeilBrown wrote:
> On Wed, 16 Jan 2013 12:00:48 +0200 Roger Quadros <rogerq@ti.com> wrote:
> 
>> On 01/09/2013 12:29 AM, 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).
>>>
>>> After a suspend/resume cycle with off_mode enabled the GSM module disappears.
>>> i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't
>>> exist.
>>> Without off mode, the modem always appears after resume.
>>>
>>> I discovered that the registers set by:
>>>
>>>    drivers/mfd/omap-usb-host.c
>>>
>>> are not maintained across as suspend/resume so I added the following patch
>>> (which I can make a formal submission of if it looks right to others), but
>>> that didn't help (or didn't help enough).
>>>
>>> If I
>>>
>>>   echo 1 > /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend
>>>
>>> thus keeping just the USBHOST power domain out of off_mode, the GSM module
>>> doesn't disappear.  So it seems that some context in the usbhost domain is
>>> not being save and restored.
>>>
>>> This is as far as I can get.  Can someone suggest where I should look to find
>>> out what is not being saved/restored properly, and how to go about saving and
>>> restoring?
>>
>> You need to ensure that USBHOST/TLL context is saved as per the Save and
>> Restore sequence see section "USBHOST/USBTLL Save-and-Restore
>> Management" in the OMAP Technical Reference Manual.
>>
>> The basic idea there is that software does the context saving into SAR
>> RAM before entering OFF mode and hardware automatically restores the
>> context after coming out of OFF mode.
> 
> Is it?  The way I read the doco, the hardware both saves to SAR RAM, and
> restores from  SAR RAM.
>   Section 22.2.4.1.6  Save and Restore
> of my copy of the TRM says:
> 
>> The save-and-restore (SAR) mechanism can extract the hardware context of the high-speed USB host
>> controller (after all USB activity has been suspended) before switching off (=save), save it to an external
>> always-on memory, and reinject it later after the module has been switched on again and reset (=restore)
>> seamlessly for the USB. Part of that context is composed of the register fields described in the current
>> chapter. The rest of the context is composed of the "buried" flip-flops and memories (not accessible by
>> software) like finite state-machine (FSM) states, buffer contents, and miscellaneous random logic bits.
> 
> which strongly suggests that it is all handled by hardware.  Of course there
> are other registers that aren't covered  by the SAR - we need to identify
> those and make sure they are saved and restored.  I've found a few registers
> that aren't being restored, but restoring them hasn't made a visible
> difference yet.

Yes, you are right. I mixed it up with OMAP4 behaviour, sorry.
But still, software needs to ensure that the USBHOST and CORE power
domain's SAVEANDRESTORE bit are set to ensure that SAR works.

see section "3.5.4.6 USBHOST/USBTLL Save-and-Restore Management"

This seems to be done by the powerdomain code based on the
PWRDM_HAS_HDWR_SAR flag. However, this flag is disabled for USBHOST
powerdomain with the following comment.

> Both USBHOST and USBTLL support a save-and-restore mechanism. When the device enters into off
> mode (that is, all power domains, except the WKUP power domain, are off), the user may want to save
> the USBHOST context and restore it when exiting off mode. The save-and-restore mechanism for the HS
> USB Host is enabled by setting the PRCM.PM_PWSTCTRL_USBHOST[4] SAVEANDRESTORE bit; for
> the USBTLL, it is configured by the PRCM.PM_PWSTCTRL_CORE[4] SAVEANDRESTORE bit. The save
> mechanism is initiated as the power domain transitions from active to off state (or to OSWR state for the
> USBTLL), whereas the restore mechanism is initiated as the power domain transitions from off to active
> power state.

Can you try with the flag enabled?

> 
> Am I missing something?
> 
>>
>> But that alone is not enough for USB host to work. We need to make sure
>> we have covered all the erratas. There are a number of them which are
>> not covered yet in mainline.
> 
> Is there a list somewhere?
> 

They should be mentioned in the Silicon Errata.

http://www.ti.com/product/omap3530

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

Igor Grinberg Jan. 16, 2013, 11:11 a.m. UTC | #14

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

On 01/16/13 12:19, NeilBrown wrote:
> 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.

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=

- -- 
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQ9oreAAoJEBDE8YO64EfaRasP/iUDBXhmPQtVm7ESB1DPopMc
b5dUWY1mwQGfNhdcPqApyPk5MPzHTAFfNiLTxJURUqN562gMl1+SR4Mr9cOX6ju4
ahlxyciOlb2KzsCTAUC9PPJVQSR2UbAPMZIA84B4pt6GOYF0OVHzFDickFhAg7Nu
dvnpMyE1gNTCISAi28lp6pLY5POcyo4HAeZaapPrl3G1GbivplKH+AqJLLeVoJzA
InebBUBe1lCDZ31RyY8uiTjjr8Qc+JDzSLybKkuijULwXualJDaJjRxvfG9cfoju
3v+/HvVdAJzqTN9cdQBJJ3VLAhpLZJHKvSlQ3K8IYLHaG5K4QJsrf6WZldRIPaAe
Ztv5EdKK3l2e4nbTP3oJmU56R2XREcKltw8e1XWNkpnN6sKn6sx8iuVPCeFlb/SA
snA1i9gkvQWRnKeW7At2Jiv3C3Xn9L+1fulYzTjk/mX+P4sKhigllV73naAeGnZZ
GOa7F1FeCq0L8d2CV36FWwXOvOqdyrkgCabA2GQrOHlIOjnOqhymc/pybGGly1Ph
arGUSdcFdl1rxcuzIYcBKgV8eF5E+wjnLMVubO/Bj9nrpbxVAeyAyF0qNY1RWmBx
oY5JJah2EM/AyPBKCSEY3PBugwAFLPV9uL69Bw0rJbxfT1uWBHVoby3Q5/dpWAJv
bt+zpdKaK5n3KYHqbPci
=qbkL
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

NeilBrown Jan. 17, 2013, 12:22 a.m. UTC | #15

LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpPbiBXZWQs
IDE2IEphbiAyMDEzIDEzOjExOjI2ICswMjAwIElnb3IgR3JpbmJlcmcgPGdyaW5iZXJnQGNvbXB1
bGFiLmNvLmlsPg0Kd3JvdGU6DQoNCj4gLS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0t
LQ0KPiBIYXNoOiBTSEExDQo+IA0KPiBPbiAwMS8xNi8xMyAxMjoxOSwgTmVpbEJyb3duIHdyb3Rl
Og0KPiA+IE9uIFdlZCwgMTYgSmFuIDIwMTMgMTE6Mjg6MDIgKzAyMDAgSWdvciBHcmluYmVyZyA8
Z3JpbmJlcmdAY29tcHVsYWIuY28uaWw+DQo+ID4gd3JvdGU6DQo+ID4gDQo+ID4+IC0tLS0tQkVH
SU4gUEdQIFNJR05FRCBNRVNTQUdFLS0tLS0NCj4gPj4gSGFzaDogU0hBMQ0KPiA+IA0KPiA+PiBP
biAwMS8xNi8xMyAwOToyNiwgTmVpbEJyb3duIHdyb3RlOg0KPiA+Pj4gT24gV2VkLCAwOSBKYW4g
MjAxMyAxNDo1NDowMCArMDIwMCBJZ29yIEdyaW5iZXJnIDxncmluYmVyZ0Bjb21wdWxhYi5jby5p
bD4NCj4gPj4+IHdyb3RlOg0KPiA+Pj4NCj4gPj4+PiBPbiAwMS8wOS8xMyAxNDowOCwgTWljaGFl
bCBUcmltYXJjaGkgd3JvdGU6DQo+ID4+Pj4+IEhpIE5laWwNCj4gPj4+Pj4NCj4gPj4+Pj4gSSBm
b3JnZXQgdG8gYW5zd2VyIHRvIHlvdXIgcXVlc3Rpb25zDQo+ID4+Pj4+DQo+ID4+Pj4+IE9uIDAx
LzA5LzIwMTMgMTI6MzQgUE0sIE5laWxCcm93biB3cm90ZToNCj4gPj4+Pj4+IE9uIFdlZCwgMDkg
SmFuIDIwMTMgMTE6MjQ6MDkgKzAxMDAgTWljaGFlbCBUcmltYXJjaGkNCj4gPj4+Pj4+IDxtaWNo
YWVsQGFtYXJ1bGFzb2x1dGlvbnMuY29tPiB3cm90ZToNCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4gSGkg
TmVpbA0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gT24gMDEvMDkvMjAxMyAxMToxOSBBTSwgTmVpbEJy
b3duIHdyb3RlOg0KPiA+Pj4+Pj4+PiBPbiBXZWQsIDA5IEphbiAyMDEzIDEyOjAwOjA1ICswMjAw
IElnb3IgR3JpbmJlcmcgPGdyaW5iZXJnQGNvbXB1bGFiLmNvLmlsPg0KPiA+Pj4+Pj4+PiB3cm90
ZToNCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IC0tLS0tQkVHSU4gUEdQIFNJR05FRCBNRVNTQUdF
LS0tLS0NCj4gPj4+Pj4+Pj4+IEhhc2g6IFNIQTENCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IEhp
IE5laWwsDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBPbiAwMS8wOS8xMyAwMDoyOSwgTmVpbEJy
b3duIHdyb3RlOg0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gSGksDQo+ID4+Pj4+Pj4+Pj4g
IEknbSB0cnlpbmcgdG8gZ2V0IG9mZl9tb2RlIHdvcmtpbmcgcmVsaWFibHkgb24gbXkgZ3RhMDQg
bW9iaWxlIHBob25lLg0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gTXkgY3VycmVudCBzdHVt
YmxpbmcgYmxvY2sgaXMgVVNCLiAgVGhlICJPcHRpb24iIEdTTSBtb2R1bGUgaXMgYXR0YWNoZWQg
dmlhDQo+ID4+Pj4+Pj4+Pj4gVVNCICh0aGVyZSBpcyBhIHNlcGFyYXRlIHRyYW5zY2VpdmVyIGNo
aXAgYXR0YWNoZWQgdG8gcG9ydCAxIHdoaWNoIGlzIHBsYWNlZA0KPiA+Pj4+Pj4+Pj4+IGluIE9N
QVBfRUhDSV9QT1JUX01PREVfUEhZKS4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IFdoaWNoIFBI
WSBpcyB0aGlzICh2ZW5kb3IvbW9kZWwpPw0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBIaSBJZ29y
LA0KPiA+Pj4+Pj4+PiAgIGl0IGlzIHRoZSBTTVNDIFVTQjMzMjINCj4gPj4+Pj4+Pj4NCj4gPj4+
Pj4+Pj4gaHR0cDovL3d3dy5zbXNjLmNvbS9tZWRpYS9Eb3dubG9hZHNfUHVibGljL0RhdGFfU2hl
ZXRzLzMzMjAucGRmDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IEJUVyBJIHN1
YnNlcXVlbnRseSBkaXNjb3ZlcmVkIHRoYXQga2VlcGluZyBVU0JIT1NUIG91dCBvZmYgb2ZmX21v
ZGUgb25seQ0KPiA+Pj4+Pj4+PiBzb21ldGltZXMgYXZvaWQgdGhlIHByb2JsZW0sIG5vdCBhbHdh
eXMuICBTbyB0aGVyZSBhcmUgcHJvYmFibHkgbXVsdGlwbGUNCj4gPj4+Pj4+Pj4gaXNzdWVzIDot
KA0KPiA+Pj4+DQo+ID4+Pj4gV2UgaGF2ZSB0aGUgc2FtZSBQSFkgYW5kIGl0IGhhcyBzb21lIGlz
c3VlcyB3aXRoIHRoZSBPTUFQIFVTQiBjb2RlLg0KPiA+Pj4+IEZpcnN0IGlzc3VlIHdlIGV4cGVy
aWVuY2UgaXMgdGhhdCBpZiB3ZSByZXNldCB0aGUgUEhZIG1vcmUgdGhlbiBvbmNlDQo+ID4+Pj4g
dy9vIHBvd2VyIGN5Y2xpbmcgaXQsIHRoZSBQSFkgZGllcyB1bnRpbCBuZXh0IHBvd2VyIGN5Y2xl
Lg0KPiA+Pj4+IFNvLCB3ZSBzdG9wIHByb3ZpZGluZyB0aGUgcmVzZXQgR1BJTyB0byB0aGUgdXNi
IGNvZGUgYW5kIGRvIHRoZSByZXNldA0KPiA+Pj4+IGluIHRoZSBib2FyZCBjb2RlLg0KPiA+Pj4N
Cj4gPj4+IEkndmUgdHJpZWQgdmFyaW91cyBjaGFuZ2Ugdy5yLnQgdGhlIHJlc2V0dGluZyBhbmQg
IEkgY2Fubm90IGZhdWx0IGl0Lg0KPiA+Pj4gUmVzZXR0aW5nIG9yIG5vdCByZXNldHRpbmcgbmVp
dGhlciBjYXVzZXMgYSBwcm9ibGVtIHdoaWxlIHRoZSBVU0IgaXMNCj4gPj4+IG90aGVyd2lzZSB3
b3JraW5nLCBub3QgZml4ZWQgdGhlIFVTQiB3aGlsZSAgaXQgaXMgb3RoZXJ3aXNlIGZhaWxpbmcu
DQo+ID4+PiBTbyBJIGRvbid0IHRoaW5rIHRoaXMgaXMgbXkgcHJvYmxlbSAtIHRoYW5rcy4NCj4g
Pj4+DQo+ID4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IEFyZSB5b3Ugc3VyZSB0aGF0IHlvdSBk
b24ndCBoYXZlIGdsaXRjaCBvbiBwb3dlciwgcmVzZXQgcGluIGR1cmluZyBzdXNwZW5kPw0KPiA+
Pj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gTm8sIEkgZG9uJ3QgcmVhbGx5IGhhdmUgdGhlIGVx
dWlwbWVudCB0byBtZWFzdXJlIHN1Y2ggdGhpbmdzLg0KPiA+Pj4+Pj4gQnV0IGlzIGl0IGxpa2Vs
eT8gIFdvdWxkIGVuYWJsaW5nIG9mZl9tb2RlIG1ha2UgaXQgbW9yZSBsaWtlbHk/DQo+ID4+Pj4+
DQo+ID4+Pj4+IEkgZG9uJ3Qga25vdyB0aGUgcmVhc29uIG9mIHRoZSBvZmZfbW9kZSBwcm9ibGVt
IDooDQo+ID4+Pj4NCj4gPj4+PiBXZSBoYXZlIHRoZSBlcXVpcG1lbnQgdG8gY2hlY2sgdGhpcyBh
bmQgbm8gLSB0aGlzIGlzIG5vdCB0aGUgY2FzZS4NCj4gPj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+Pj4g
Q2FuIHlvdSBzdWdnZXN0IHNvbWUgd2F5IEkgY291bGQgdGVzdCB0aGUgaHlwb3RoZXNpcz8NCj4g
Pj4+Pj4NCj4gPj4+Pj4gSSBoYWQgdGhlIHNhbWUgcHJvYmxlbSBvbiBhIHJ1Z2dlZCBtb2JpbGUg
cGhvbmUsIHNvIGl0IGlzIGp1c3QgZXhwZXJpZW5jZQ0KPiA+Pj4+PiBDaGVjayB0aGUgbW9kZW0g
cG93ZXIgYW5kIHJlc2V0IGdwaW8gdG9vLCBidXQgaWYgeW91IGRvbid0IG5lZWQgdG8gdW5ibG9j
ayBpdA0KPiA+Pj4+PiB3aXRoIHRoZSBwaW4gYWZ0ZXIgcmVzdW1lIHdlIGtub3cgdGhhdCBtb2Rl
bSBpcyBub3QgdGhlIHByb2JsZW0NCj4gPj4+Pg0KPiA+Pj4+IEkgZG9uJ3QgdGhpbmsgbW9kZW0g
aXMgdGhlIHByb2JsZW0uLi4NCj4gPj4+PiBXZSBoYXZlIHBsYWluIFVTQiBjb25uZWN0b3IgcG9y
dHMgdGhhdCBhcmUgZGVhZCBhZnRlciB0aGUgcmVzdW1lIGZyb20gb2ZmLW1vZGUuDQo+ID4+Pj4N
Cj4gPj4+PiBUaGUgZ29vZCBuZXdzIGFyZSB0aGF0IHdlIGhhdmUgdGhlIG9mZi1tb2RlIHdvcmtp
bmcgb24gdjMuNi4xLA0KPiA+Pj4+IGluY2x1ZGluZyB0aGUgVVNCLCBidXQgd2UgaGFkIHRvIGRv
IHNvbWUgaG9ycmlibGUgdWdseSBoYWNraW5nIGZvciB0aGlzLg0KPiA+Pj4+DQo+ID4+Pg0KPiA+
Pj4gSSBhc3N1bWUgdGhpcyAgbWVhbnMgInNvbWUgcGF0Y2hlcyBvbiB0b3Agb2YgMy42LjEiID8/
DQo+ID4+PiBDYXJlIHRvIHNoYXJlIHlvdXIgY29kZT8gIEV2ZW4gaG9ycmlibHkgdWdseSBoYWNr
cyBjYW4gYmUgZWR1Y2F0aW9uYWwuDQo+ID4gDQo+ID4+IFdlIGFyZSBub3QgcmVhZHkgdG8gc2hh
cmUgdGhlc2UgcGF0Y2hlcyAodGhpcyB3aWxsIGhhcHBlbiBldmVudHVhbGx5DQo+ID4+IGFmdGVy
IHNvbWUgd29yayBpcyBmaW5pc2hlZCksIGJ1dCBJIGNhbiBleHBsYWluIHdoYXQgdGhleSBkby4u
Lg0KPiA+IA0KPiA+PiBXZSBzcGxpdCB0aGUgZWhjaV9ydW4gZnVuY3Rpb24gdG8gc2VwYXJhdGUg
dGhlIGRlYnVnZnMgYW5kIHN5c2ZzIHN0dWZmIGZyb20NCj4gPj4gb3RoZXIgaW5pdGlhbGl6YXRp
b25zLCBzbyB3ZSBjYW4gcnVuIHRoZSBuZXcgdmVyc2lvbiB3aXRob3V0IHRoZSBkZWJ1Z2ZzIGFu
ZA0KPiA+PiBzeXNmcyBzdHVmZiBtdWx0aXBsZSB0aW1lcy4NCj4gPiANCj4gPj4gVGhlbiB3ZSBp
bXBsZW1lbnQgdGhlIHN1c3BlbmQvcmVzdW1lIGVoY2kgY2FsbGJhY2tzOg0KPiA+PiBvbiBzdXNw
ZW5kLCBhc3NlcnQgcGh5IHJlc2V0LA0KPiA+PiBvbiByZXN1bWUsIGRlYXNzZXJ0IHBoeSByZXNl
dCwgd3JpdGUgRUhDSV9JTlNOUkVHMDRfRElTQUJMRV9VTlNVU1BFTkQgdG8NCj4gPj4gRUhDSV9J
TlNOUkVHMDQsIGFuZCBjYWxsIHRoZSBuZXcgZWhjaV9ydW4oKSBmdW5jdGlvbi4NCj4gPiANCj4g
Pj4gVGhhdCBkb2VzIHRoZSBqb2IgZm9yIFVTQiBob3N0IHRvIHJlc3VtZSBmcm9tIG9mZiBtb2Rl
Lg0KPiA+IA0KPiA+IEludGVyZXN0aW5nIHRoYW5rcy4gIFRoYXQgbWFrZXMgYSBjZXJ0YWluIGFt
b3VudCBvZiBzZW5zZS4NCj4gPiANCj4gPiBIb3dldmVyIEkgdHJpZWQgY29tcGlsaW5nIGVoY2kt
aGNkIGFzIGEgbW9kdWxlIGFuZCAgdW5sb2FkL3JlbG9hZGluZyBpdCB3aGljaA0KPiA+IHNob3Vs
ZCBoYXZlIGEgc2ltaWxhciBuZXQgZWZmZWN0IHRvIHdoYXQgeW91IGRpZCwgYnV0IGl0IGRpZG4n
dCBtYWtlIGFueQ0KPiA+IGRpZmZlcmVuY2UgLSBkZXZpY2UgZGlzYXBwZWFycyBvbiByZXN1bWUu
DQo+IA0KPiBZZXMgaXQgZG9lcyBmb3IgY20tdDM3MzAsIGluIGZhY3QsIHRoYXQgaXMgd2hhdCB3
ZSBoYXZlIHN0YXJ0ZWQgZnJvbS4uLg0KPiANCj4gPiANCj4gPiBJIGFsc28gdHJpZWQgcmVzdG9y
aW5nIHRoZSBjb3JyZWN0IHZhbHVlIHRvIEVIQ0lfSU5TTlJFRzA0IGFuZA0KPiA+IEVIQ0lfSU5T
TlJFRzA1X1VMUEkgd2hpY2ggYXJlIHRoZSBvbmx5IHJlZ2lzdGVycyB3cml0dGVuIGJ5IA0KPiA+
IGVoY2ktb21hcC5jLCBhbmQgdGhhdCBkaWRuJ3QgaGVscCBlaXRoZXIuDQo+ID4gDQo+ID4gVGhl
IG9ubHkgdGhpbmcgSSd2ZSBmb3VuZCB0aGF0IHdvcmtzIGlzIGtlZXBpbmcgJ2NvcmUnIG91dCBv
ZiBvZmYtbW9kZS4NCj4gDQo+IEFoLCBvbmUgbW9yZSB0aGluZywgd2UgZW5zdXJlIHRoYXQgcGh5
IGlzIGNvbXBsZXRlbHkgcG93ZXJlZCBvZmYgdGhyb3VnaA0KPiB0aGUgVFBTIHBvd2VyIHNjcmlw
dHMsIG90aGVyd2lzZSwgaXQgZG9lcyBub3Qgd29yay4uLg0KPiANCg0KQWhoaC4uLi4gIHRoYXQg
ZG9lcyBtYWtlIGEgZGlmZmVyZW5jZS4NCg0KSSB0dXJuZWQgb2ZmIHRoZSA1VjUgcmFpbCB3aGlj
aCBwb3dlcmVkIHRoZSBwaHkgKGFuZCBhIGZldyBvdGhlciB0aGluZ3MpIGFuZA0Kbm93IHRoZSB1
c2ItYXR0YWNoZWQgbW9kZW0gYXBwZWFycyBhZnRlciByZXN1bWUuICBWZXJ5IGludGVyZXN0aW5n
Lg0KDQpJIGhhZG4ndCBiZWVuIGRvaW5nIHRoaXMgYXMgSSBoYWQgYmVlbiBhZHZpc2VkIHRoYXQg
dGhlIGhhcmR3YXJlIHdvdWxkbid0DQpsaWtlIGl0LiAgVGhlcmUgYXJlIGEgZmV3IGRldmljZXMg
KGluY2x1ZGluZyB0aGUgIFVTQiBQSFkpIHdoaWNoIGFyZSBzdXBwbGllZA0KYnkgYm90aCBhIDFW
OCByYWlsIGFuZCB0aGUgNVY1IHJhaWwuICBTb21lIG9mIHRoZW0gYXJlIG91dC1vZi1zcGVjIGlm
IHRoZSAxVjgNCmlzIHN1cHBsaWVkLCBidXQgdGhlIDVWNSBpc24ndC4NClRoZSAxVjggbXVzdCBy
ZW1haW4gb24gZHVyaW5nIHN1c3BlbmQgYXMgaXQga2VlcCB0aGUgUkFNIHBvd2VyZWQsIHNvIHRo
ZSA1VjUNCm11c3QgYXMgd2VsbC4gIEF3a3dhcmQuDQoNCg0KSXQgaXMgbm90IGVudGlyZWx5IHNh
dGlzZmFjdG9yeSBmb3Igb3RoZXIgcmVhc29ucy4gSXQgc2VlbXMgdGhhdCB3aXRoDQpvZmZfbW9k
ZSBmdWxseSB3b3JraW5nLCB3ZSBkcm9wIHRvIG9mZiBtb2RlIHdoZW4gQ1BVSURMRSBwdXRzIHRo
aW5ncyB0bw0Kc2xlZXAsIGFuZCB0aGF0IHJlbW92ZXMgdGhlIDVWNSB0b28sIHdoaWNoIGlzIGJh
ZC4gIFRoaXMgZGlzY29ubmVjdHMgdGhlIFVTQi4NCk15IGN1cnJlbnQgY29uc29sZSBsb2cgc2hv
d3M6DQoNCg0KWyAyNDUzLjgzNzQwMl0gdXNiIDEtMjogbmV3IGhpZ2gtc3BlZWQgVVNCIGRldmlj
ZSBudW1iZXIgMTAgdXNpbmcgZWhjaS1vbWFwDQpbIDI0NTQuMDA2MjU2XSB1c2IgMS0yOiBOZXcg
VVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MGFmMCwgaWRQcm9kdWN0PTg4MDANClsgMjQ1NC4w
MTU2ODZdIHVzYiAxLTI6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIs
IFNlcmlhbE51bWJlcj0wDQpbIDI0NTQuMDI1NTEyXSB1c2IgMS0yOiBQcm9kdWN0OiBHbG9iZXRy
b3R0ZXIgSFNVUEEgTW9kZW0NClsgMjQ1NC4wMzEwMDVdIHVzYiAxLTI6IE1hbnVmYWN0dXJlcjog
T3B0aW9uIE4uVi4NClsgMjQ1NS4zNTU4MDRdIHVzYiAxLTI6IFVTQiBkaXNjb25uZWN0LCBkZXZp
Y2UgbnVtYmVyIDEwDQpbIDI0NTkuODI5NTg5XSB1c2IgMS0yOiBuZXcgaGlnaC1zcGVlZCBVU0Ig
ZGV2aWNlIG51bWJlciAxMSB1c2luZyBlaGNpLW9tYXANClsgMjQ1OS45OTc4OTRdIHVzYiAxLTI6
IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0wYWYwLCBpZFByb2R1Y3Q9ODgwMA0KWyAy
NDYwLjAwNzM4NV0gdXNiIDEtMjogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1
Y3Q9MiwgU2VyaWFsTnVtYmVyPTANClsgMjQ2MC4wMTcyNDJdIHVzYiAxLTI6IFByb2R1Y3Q6IEds
b2JldHJvdHRlciBIU1VQQSBNb2RlbQ0KWyAyNDYwLjAyMjY0NF0gdXNiIDEtMjogTWFudWZhY3R1
cmVyOiBPcHRpb24gTi5WLg0KWyAyNDY5LjQ5NjQ5MF0gdXNiIDEtMjogVVNCIGRpc2Nvbm5lY3Qs
IGRldmljZSBudW1iZXIgMTENClsgMjQ3Mi44NDUyNDVdIHVzYiAxLTI6IG5ldyBoaWdoLXNwZWVk
IFVTQiBkZXZpY2UgbnVtYmVyIDEyIHVzaW5nIGVoY2ktb21hcA0KWyAyNDczLjAxMzk0Nl0gdXNi
IDEtMjogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTBhZjAsIGlkUHJvZHVjdD04ODAw
DQpbIDI0NzMuMDIzMzc2XSB1c2IgMS0yOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9Mywg
UHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MA0KWyAyNDczLjAzMzI2NF0gdXNiIDEtMjogUHJvZHVj
dDogR2xvYmV0cm90dGVyIEhTVVBBIE1vZGVtDQpbIDI0NzMuMDM4NzU3XSB1c2IgMS0yOiBNYW51
ZmFjdHVyZXI6IE9wdGlvbiBOLlYuDQpbIDI0NzQuNTI4Mjg5XSB1c2IgMS0yOiBVU0IgZGlzY29u
bmVjdCwgZGV2aWNlIG51bWJlciAxMg0KWyAyNDc4LjgyOTU4OV0gdXNiIDEtMjogbmV3IGhpZ2gt
c3BlZWQgVVNCIGRldmljZSBudW1iZXIgMTMgdXNpbmcgZWhjaS1vbWFwDQpbIDI0NzguOTk4NzQ4
XSB1c2IgMS0yOiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MGFmMCwgaWRQcm9kdWN0
PTg4MDANClsgMjQ3OS4wMDgyMDldIHVzYiAxLTI6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1m
cj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0wDQpbIDI0NzkuMDE4MDA1XSB1c2IgMS0yOiBQ
cm9kdWN0OiBHbG9iZXRyb3R0ZXIgSFNVUEEgTW9kZW0NClsgMjQ3OS4wMjM0OThdIHVzYiAxLTI6
IE1hbnVmYWN0dXJlcjogT3B0aW9uIE4uVi4NClsgMjQ4MC4zNzQ2OTRdIHVzYiAxLTI6IFVTQiBk
aXNjb25uZWN0LCBkZXZpY2UgbnVtYmVyIDEzDQoNCmkuZS4gdGhlIG1vZGVtIGRpc2Nvbm5lY3Rp
bmcgYW5kIHJlY29ubmVjdGluZy4gZXZlcnkgZmV3IHNlY29uZHMuICBUaGUgbW9kZW0NCmV2ZW50
dWFsbHkgZ290IHVwc2V0IGFuZCBoYXMgIGVudGVyZWQgYSBzdGF0ZSB3aGVyZSBJIGNhbm5vdCBj
b21tdW5pY2F0ZSB3aXRoDQppdC4NCg0KU28gLSBpbnRlcmVzdGluZyBhbmQgdXNlZnVsLCBidXQg
SSBkb24ndCBoYXZlIGEgY29tcGxldGUgc29sdXRpb24geWV0Lg0KDQoNCkFsc28sIHdoaWxlIHRo
aXMgZ2V0cyB0aGUgaW50ZXJuYWwgVVNCIHdvcmtpbmcgKHRvIHNvbWUgZXh0ZW50KSB0aGUgZXh0
ZXJuYWwNCnVzYiAoVVNCLU9URyB1c2luZyB0aGUgbXVzYiBkcml2ZXIpIGlzIHN0aWxsIGJyb2tl
bi4gIFdoZW4gQ09SRSBpcyBvbmx5DQphbGxvd2VkIGludG8gcmV0ZW50aW9uIG1vZGUsIGl0IHdv
cmtzIGZpbmUuIFdoZW4gQ09SRSBnb2VzIHRvIG9mZi1tb2RlLCBJDQpsb3NlIHRoZSBVU0IgcG9y
dC4gIFNvIHRoYXQnbGwgYmUgYW5vdGhlciAgcHJvYmxlbSB0byBzb2x2ZS4NCg0KVGhhbmtzIGFn
YWluLA0KDQpOZWlsQnJvd24NCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQpWZXJzaW9u
OiBHbnVQRyB2Mi4wLjE5IChHTlUvTGludXgpDQoNCmlRSVZBd1VCVVBkRVh6bnNudDFXWW9HNUFR
SjVxZy84RHJTaXJTWGZJVDBVL0lxeVF5aW1kUlM2dzExSmp1VWENCnhRblNsN2JlNlRyMGJ1Tk0v
eFoxWmZRNmZzNDdhT09uRllqQVZMVWpIVXFWeFhoVWpEWkxvNUt4STB5b1lpMzUNCmd6b0dXVEI0
QVM4QngvVjdkT0h4QnRPTzB0L3ZVeXhpVGlBV2hHN0FGWlpjNkNNL1o0VXpRdkQ0dXlZK2JRTmoN
CjJZbUYxMTJsTVVMdHBmVzVtNTZ2c3F4eWY5c1FuK0NyKzFzbm5PeDQxNndGMlZxNWxOYVpoVmhx
WCtPcXo5bzINClR2dFNTMnAzaG50QVFQQlBsMFZaNERaQWRpcXVTa3E4TFpUS0tjYTB1ODVNSHdI
eDF2NEh2RzVTOU5xRGtEZm8NCmhJYVFkYWt1NVhlN1NnTG9VckliNGEycHBXZThPd2pjckI2TVNE
dWd6UDBZMGd0L2txNXVvZTc1L1RWSjIzS3cNCmlqam8vTHdRTnZUMUc4cnVIQmcwZXZhd1g1VHRu
NHByZmgxRlFleUprRFdld1h0VmFvbmI3QVY0RStSVWMycXcNCm9iaFo0cnhvcitzR3k3UWoxOFJC
TXNXdis4bjQvUVBLdzFSa1VZcmtTSVREb2YzT1lJM1VjbkZmVDloS1Z3aGUNClV6MnZGWC9yQmoz
dVZuKzV1U1IzZmxNdHdncGV5OVJBQWI1dE16cUR0UFBpK1I4djZnVXhPWmt2QmpqZTZoUWMNCllM
Y1VMaUZ4ZFBpRk5UaVdzN0JrVE83blJ4UzVESUU1bXRHL0xtV29hNzNhYkFOMkpqSWZWSVB3Unds
Uzd4ZEINCm9uME13VU5JUW1OTDU4c2VZUzJKQTJVYXZEUC9ZL0xjbmpvczBiL0JxeGpYV3JIVEVk
UDZXU2txMms0OCs0ME0NCjVEM3dLQ05YQzh3PQ0KPW05TSsNCi0tLS0tRU5EIFBHUCBTSUdOQVRV
UkUtLS0tLQ0K
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

NeilBrown Jan. 17, 2013, 9:24 a.m. UTC | #16

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

On Thu, 17 Jan 2013 11:22:55 +1100 NeilBrown <neilb@suse.de> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----

> Hash: SHA1

> 

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

> wrote:

> 

> > -----BEGIN PGP SIGNED MESSAGE-----

> > Hash: SHA1

> > 

> > On 01/16/13 12:19, NeilBrown wrote:

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

> > 

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

> > 

> 

> Ahhh....  that does make a difference.

> 

> I turned off the 5V5 rail which powered the phy (and a few other things) and

> now the usb-attached modem appears after resume.  Very interesting.

> 

> I hadn't been doing this as I had been advised that the hardware wouldn't

> like it.  There are a few devices (including the  USB PHY) which are supplied

> by both a 1V8 rail and the 5V5 rail.  Some of them are out-of-spec if the 1V8

> is supplied, but the 5V5 isn't.

> The 1V8 must remain on during suspend as it keep the RAM powered, so the 5V5

> must as well.  Awkward.

> 

> 

> It is not entirely satisfactory for other reasons. It seems that with

> off_mode fully working, we drop to off mode when CPUIDLE puts things to

> sleep, and that removes the 5V5 too, which is bad.  This disconnects the USB.

> My current console log shows:

> 

> 

> [ 2453.837402] usb 1-2: new high-speed USB device number 10 using ehci-omap

> [ 2454.006256] usb 1-2: New USB device found, idVendor=0af0, idProduct=8800

> [ 2454.015686] usb 1-2: New USB device strings: Mfr=3, Product=2, SerialNumber=0

> [ 2454.025512] usb 1-2: Product: Globetrotter HSUPA Modem

> [ 2454.031005] usb 1-2: Manufacturer: Option N.V.

> [ 2455.355804] usb 1-2: USB disconnect, device number 10

> [ 2459.829589] usb 1-2: new high-speed USB device number 11 using ehci-omap

> [ 2459.997894] usb 1-2: New USB device found, idVendor=0af0, idProduct=8800

> [ 2460.007385] usb 1-2: New USB device strings: Mfr=3, Product=2, SerialNumber=0

> [ 2460.017242] usb 1-2: Product: Globetrotter HSUPA Modem

> [ 2460.022644] usb 1-2: Manufacturer: Option N.V.

> [ 2469.496490] usb 1-2: USB disconnect, device number 11

> [ 2472.845245] usb 1-2: new high-speed USB device number 12 using ehci-omap

> [ 2473.013946] usb 1-2: New USB device found, idVendor=0af0, idProduct=8800

> [ 2473.023376] usb 1-2: New USB device strings: Mfr=3, Product=2, SerialNumber=0

> [ 2473.033264] usb 1-2: Product: Globetrotter HSUPA Modem

> [ 2473.038757] usb 1-2: Manufacturer: Option N.V.

> [ 2474.528289] usb 1-2: USB disconnect, device number 12

> [ 2478.829589] usb 1-2: new high-speed USB device number 13 using ehci-omap

> [ 2478.998748] usb 1-2: New USB device found, idVendor=0af0, idProduct=8800

> [ 2479.008209] usb 1-2: New USB device strings: Mfr=3, Product=2, SerialNumber=0

> [ 2479.018005] usb 1-2: Product: Globetrotter HSUPA Modem

> [ 2479.023498] usb 1-2: Manufacturer: Option N.V.

> [ 2480.374694] usb 1-2: USB disconnect, device number 13

> 

> i.e. the modem disconnecting and reconnecting. every few seconds.  The modem

> eventually got upset and has  entered a state where I cannot communicate with

> it.

> 

> So - interesting and useful, but I don't have a complete solution yet.

> 

> 

> Also, while this gets the internal USB working (to some extent) the external

> usb (USB-OTG using the musb driver) is still broken.  When CORE is only

> allowed into retention mode, it works fine. When CORE goes to off-mode, I

> lose the USB port.  So that'll be another  problem to solve.


Actually, forget all that.  My testing methodology was flawed and I wasn't
really seeing what I thought I was seeing.
I'll try to find time to be more careful and if I find something interesting,
I'll let you know.

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

iQIVAwUBUPfDZTnsnt1WYoG5AQJ66w/6Ai4Gw4qQRcSWjK+trZ+1LjobLxjzSmOf
OXygPengsCbkAvHyEGPVilsz3C/INQm4DEo6xxqeva8aMU5LjCJFXgwdVCI/mi60
/FShjWVcLWzuakemEbBdXHLC4zrBTbYUb0yFwdqDlBhjSpBtyOqPCqfWNc3oTLs5
p2K8cUsCctKQfQCQW7LWOtgoyC1sRXQY1hTSCkdiXIruv5Kmb038CHUNhpdBbhkC
YrG8YE/Xjh7rEJPsrskPpemXgWS80gTQ0R0FPjQ9NNS85USvmAx20ei7DpoGZub1
8QIyGlULq9fXrA4wzlF5+dGgPsNkxjwRRd9MxFoogO0VUMdOocr6hnoS6QCn9AcI
VNNJvaBu8bOkyoWU65d46RL+NPYiYMb/6NzPdiLqSYbAeI050+DH589t/yZUeei8
vranN0haOGHbURoi3sw2A4EFID22uSyCdUtyIYAWLpxu0f3Cao3UddzGJFli63wk
LnG9a6T6iReeRf3fJwobiIQeEOQTjWTYQknaQscWBzzdFt3Wp72s5uTOhonvES0o
60HpCFHEqfQeK1KG7ueMlFUOggUfO81y0Yow3GZ7SG1QKaiJdt7SnqKJpb4T+IDX
BIatatH/s66jLCHWB205t/3/Xf7O83YaqEeLnyY8U4n91vspntW5J2gFltapTymj
jzJQI7m9+9c=
=ebni
-----END PGP SIGNATURE-----

NeilBrown Jan. 17, 2013, 11:01 a.m. UTC | #17

On Wed, 16 Jan 2013 12:57:08 +0200 Roger Quadros <rogerq@ti.com> wrote:

> On 01/16/2013 12:27 PM, NeilBrown wrote:
> > On Wed, 16 Jan 2013 12:00:48 +0200 Roger Quadros <rogerq@ti.com> wrote:
> > 
> >> On 01/09/2013 12:29 AM, 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).
> >>>
> >>> After a suspend/resume cycle with off_mode enabled the GSM module disappears.
> >>> i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't
> >>> exist.
> >>> Without off mode, the modem always appears after resume.
> >>>
> >>> I discovered that the registers set by:
> >>>
> >>>    drivers/mfd/omap-usb-host.c
> >>>
> >>> are not maintained across as suspend/resume so I added the following patch
> >>> (which I can make a formal submission of if it looks right to others), but
> >>> that didn't help (or didn't help enough).
> >>>
> >>> If I
> >>>
> >>>   echo 1 > /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend
> >>>
> >>> thus keeping just the USBHOST power domain out of off_mode, the GSM module
> >>> doesn't disappear.  So it seems that some context in the usbhost domain is
> >>> not being save and restored.
> >>>
> >>> This is as far as I can get.  Can someone suggest where I should look to find
> >>> out what is not being saved/restored properly, and how to go about saving and
> >>> restoring?
> >>
> >> You need to ensure that USBHOST/TLL context is saved as per the Save and
> >> Restore sequence see section "USBHOST/USBTLL Save-and-Restore
> >> Management" in the OMAP Technical Reference Manual.
> >>
> >> The basic idea there is that software does the context saving into SAR
> >> RAM before entering OFF mode and hardware automatically restores the
> >> context after coming out of OFF mode.
> > 
> > Is it?  The way I read the doco, the hardware both saves to SAR RAM, and
> > restores from  SAR RAM.
> >   Section 22.2.4.1.6  Save and Restore
> > of my copy of the TRM says:
> > 
> >> The save-and-restore (SAR) mechanism can extract the hardware context of the high-speed USB host
> >> controller (after all USB activity has been suspended) before switching off (=save), save it to an external
> >> always-on memory, and reinject it later after the module has been switched on again and reset (=restore)
> >> seamlessly for the USB. Part of that context is composed of the register fields described in the current
> >> chapter. The rest of the context is composed of the "buried" flip-flops and memories (not accessible by
> >> software) like finite state-machine (FSM) states, buffer contents, and miscellaneous random logic bits.
> > 
> > which strongly suggests that it is all handled by hardware.  Of course there
> > are other registers that aren't covered  by the SAR - we need to identify
> > those and make sure they are saved and restored.  I've found a few registers
> > that aren't being restored, but restoring them hasn't made a visible
> > difference yet.
> 
> Yes, you are right. I mixed it up with OMAP4 behaviour, sorry.
> But still, software needs to ensure that the USBHOST and CORE power
> domain's SAVEANDRESTORE bit are set to ensure that SAR works.
> 
> see section "3.5.4.6 USBHOST/USBTLL Save-and-Restore Management"
> 
> This seems to be done by the powerdomain code based on the
> PWRDM_HAS_HDWR_SAR flag. However, this flag is disabled for USBHOST
> powerdomain with the following comment.
> 
> > Both USBHOST and USBTLL support a save-and-restore mechanism. When the device enters into off
> > mode (that is, all power domains, except the WKUP power domain, are off), the user may want to save
> > the USBHOST context and restore it when exiting off mode. The save-and-restore mechanism for the HS
> > USB Host is enabled by setting the PRCM.PM_PWSTCTRL_USBHOST[4] SAVEANDRESTORE bit; for
> > the USBTLL, it is configured by the PRCM.PM_PWSTCTRL_CORE[4] SAVEANDRESTORE bit. The save
> > mechanism is initiated as the power domain transitions from active to off state (or to OSWR state for the
> > USBTLL), whereas the restore mechanism is initiated as the power domain transitions from off to active
> > power state.
> 
> Can you try with the flag enabled?

If I keep CORE and  USBHOST out of off-mode (by writing to the relevant
'suspend' files in /sys/kernel/debug/pm-debug) then it all works.

If I set this flag, then I can allow USBHOST to enter off-mode as long as I
keep CORE in retention or better.

If I let CORE and USBHOST go to off-mode and don't have the flag set, then I
can resume from suspend, but the usb modem has disappeared.

If I let CORE and USBHOST go to off-mode and DO have the flag set, then I
cannot even resume from suspend.... sometimes.

I hate those "sometimes"s!

If I remove the battery (with no other power source present) and re-insert
it, and let the phone boot up to  stable state and then enter suspend, I
cannot resume from suspend.  (I tried setting "no_console_suspend" to see if
anything was happening - but that keeps CORE awake).

If I do the same but before  it suspends I:

   echo 1 > /sys/kernel/debug/pm_debug/core_pwrdm/suspend
   
then let is suspend and resume, the resume works.  Then I:

   echo 0 > /sys/kernel/debug/pm_debug/core_pwrdm/suspend

to allow full sleep mode and now suspend, and again resume works.
And it continues to work.
And the USB modem remains visible - it doesn't disconnect at all.

So.... something very odd is happening somewhere.
Maybe the USBHOST powerdomain isn't really going to off-mode again after the
first time like the comment in powerdomains3xxx_data.c says:

	/*
	 * REVISIT: Enabling usb host save and restore mechanism seems to
	 * leave the usb host domain permanently in ACTIVE mode after
	 * changing the usb host power domain state from OFF to active once.
	 * Disabling for now.
	 */

However the  /sys/kernel/debug/pm_debug/count file shows the "OFF" count for
usbhost_pwrdm increments on each suspend, and that seems to be based on info
read out of the the OMAP3 itself....

All very odd.

Thanks,
NeilBrown

Roger Quadros Jan. 17, 2013, 11:29 a.m. UTC | #18

On 01/17/2013 01:01 PM, NeilBrown wrote:
> On Wed, 16 Jan 2013 12:57:08 +0200 Roger Quadros <rogerq@ti.com> wrote:
> 
>> On 01/16/2013 12:27 PM, NeilBrown wrote:
>>> On Wed, 16 Jan 2013 12:00:48 +0200 Roger Quadros <rogerq@ti.com> wrote:
>>>
>>>> On 01/09/2013 12:29 AM, 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).
>>>>>
>>>>> After a suspend/resume cycle with off_mode enabled the GSM module disappears.
>>>>> i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't
>>>>> exist.
>>>>> Without off mode, the modem always appears after resume.
>>>>>
>>>>> I discovered that the registers set by:
>>>>>
>>>>>    drivers/mfd/omap-usb-host.c
>>>>>
>>>>> are not maintained across as suspend/resume so I added the following patch
>>>>> (which I can make a formal submission of if it looks right to others), but
>>>>> that didn't help (or didn't help enough).
>>>>>
>>>>> If I
>>>>>
>>>>>   echo 1 > /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend
>>>>>
>>>>> thus keeping just the USBHOST power domain out of off_mode, the GSM module
>>>>> doesn't disappear.  So it seems that some context in the usbhost domain is
>>>>> not being save and restored.
>>>>>
>>>>> This is as far as I can get.  Can someone suggest where I should look to find
>>>>> out what is not being saved/restored properly, and how to go about saving and
>>>>> restoring?
>>>>
>>>> You need to ensure that USBHOST/TLL context is saved as per the Save and
>>>> Restore sequence see section "USBHOST/USBTLL Save-and-Restore
>>>> Management" in the OMAP Technical Reference Manual.
>>>>
>>>> The basic idea there is that software does the context saving into SAR
>>>> RAM before entering OFF mode and hardware automatically restores the
>>>> context after coming out of OFF mode.
>>>
>>> Is it?  The way I read the doco, the hardware both saves to SAR RAM, and
>>> restores from  SAR RAM.
>>>   Section 22.2.4.1.6  Save and Restore
>>> of my copy of the TRM says:
>>>
>>>> The save-and-restore (SAR) mechanism can extract the hardware context of the high-speed USB host
>>>> controller (after all USB activity has been suspended) before switching off (=save), save it to an external
>>>> always-on memory, and reinject it later after the module has been switched on again and reset (=restore)
>>>> seamlessly for the USB. Part of that context is composed of the register fields described in the current
>>>> chapter. The rest of the context is composed of the "buried" flip-flops and memories (not accessible by
>>>> software) like finite state-machine (FSM) states, buffer contents, and miscellaneous random logic bits.
>>>
>>> which strongly suggests that it is all handled by hardware.  Of course there
>>> are other registers that aren't covered  by the SAR - we need to identify
>>> those and make sure they are saved and restored.  I've found a few registers
>>> that aren't being restored, but restoring them hasn't made a visible
>>> difference yet.
>>
>> Yes, you are right. I mixed it up with OMAP4 behaviour, sorry.
>> But still, software needs to ensure that the USBHOST and CORE power
>> domain's SAVEANDRESTORE bit are set to ensure that SAR works.
>>
>> see section "3.5.4.6 USBHOST/USBTLL Save-and-Restore Management"
>>
>> This seems to be done by the powerdomain code based on the
>> PWRDM_HAS_HDWR_SAR flag. However, this flag is disabled for USBHOST
>> powerdomain with the following comment.
>>
>>> Both USBHOST and USBTLL support a save-and-restore mechanism. When the device enters into off
>>> mode (that is, all power domains, except the WKUP power domain, are off), the user may want to save
>>> the USBHOST context and restore it when exiting off mode. The save-and-restore mechanism for the HS
>>> USB Host is enabled by setting the PRCM.PM_PWSTCTRL_USBHOST[4] SAVEANDRESTORE bit; for
>>> the USBTLL, it is configured by the PRCM.PM_PWSTCTRL_CORE[4] SAVEANDRESTORE bit. The save
>>> mechanism is initiated as the power domain transitions from active to off state (or to OSWR state for the
>>> USBTLL), whereas the restore mechanism is initiated as the power domain transitions from off to active
>>> power state.
>>
>> Can you try with the flag enabled?
> 
> If I keep CORE and  USBHOST out of off-mode (by writing to the relevant
> 'suspend' files in /sys/kernel/debug/pm-debug) then it all works.
> 
> If I set this flag, then I can allow USBHOST to enter off-mode as long as I
> keep CORE in retention or better.
> 
> If I let CORE and USBHOST go to off-mode and don't have the flag set, then I
> can resume from suspend, but the usb modem has disappeared.
> 
> If I let CORE and USBHOST go to off-mode and DO have the flag set, then I
> cannot even resume from suspend.... sometimes.
> 

It looks like the problem creeps in when the OMAP device hits OFF. i.e.
CORE is allowed to go OFF.

> I hate those "sometimes"s!
> 
> If I remove the battery (with no other power source present) and re-insert
> it, and let the phone boot up to  stable state and then enter suspend, I
> cannot resume from suspend.  (I tried setting "no_console_suspend" to see if
> anything was happening - but that keeps CORE awake).
> 
> If I do the same but before  it suspends I:
> 
>    echo 1 > /sys/kernel/debug/pm_debug/core_pwrdm/suspend
>    
> then let is suspend and resume, the resume works.  Then I:
> 
>    echo 0 > /sys/kernel/debug/pm_debug/core_pwrdm/suspend
> 
> to allow full sleep mode and now suspend, and again resume works.
> And it continues to work.
> And the USB modem remains visible - it doesn't disconnect at all.
> 

So does repeated suspend/resume work after this? Or is it only the first
suspend/resume.

> So.... something very odd is happening somewhere.
> Maybe the USBHOST powerdomain isn't really going to off-mode again after the
> first time like the comment in powerdomains3xxx_data.c says:
> 
> 	/*
> 	 * REVISIT: Enabling usb host save and restore mechanism seems to
> 	 * leave the usb host domain permanently in ACTIVE mode after
> 	 * changing the usb host power domain state from OFF to active once.
> 	 * Disabling for now.
> 	 */
> 
> However the  /sys/kernel/debug/pm_debug/count file shows the "OFF" count for
> usbhost_pwrdm increments on each suspend, and that seems to be based on info
> read out of the the OMAP3 itself....
> 
> All very odd.

I need to give this a try. I can try it out on OMAP3 beagle board.

What OMAP3 are you on, and which kernel are you using for your tests?

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

NeilBrown Jan. 17, 2013, 9:08 p.m. UTC | #19

On Thu, 17 Jan 2013 13:29:07 +0200 Roger Quadros <rogerq@ti.com> wrote:

> On 01/17/2013 01:01 PM, NeilBrown wrote:
> > On Wed, 16 Jan 2013 12:57:08 +0200 Roger Quadros <rogerq@ti.com> wrote:
> > 
> >> On 01/16/2013 12:27 PM, NeilBrown wrote:
> >>> On Wed, 16 Jan 2013 12:00:48 +0200 Roger Quadros <rogerq@ti.com> wrote:
> >>>
> >>>> On 01/09/2013 12:29 AM, 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).
> >>>>>
> >>>>> After a suspend/resume cycle with off_mode enabled the GSM module disappears.
> >>>>> i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't
> >>>>> exist.
> >>>>> Without off mode, the modem always appears after resume.
> >>>>>
> >>>>> I discovered that the registers set by:
> >>>>>
> >>>>>    drivers/mfd/omap-usb-host.c
> >>>>>
> >>>>> are not maintained across as suspend/resume so I added the following patch
> >>>>> (which I can make a formal submission of if it looks right to others), but
> >>>>> that didn't help (or didn't help enough).
> >>>>>
> >>>>> If I
> >>>>>
> >>>>>   echo 1 > /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend
> >>>>>
> >>>>> thus keeping just the USBHOST power domain out of off_mode, the GSM module
> >>>>> doesn't disappear.  So it seems that some context in the usbhost domain is
> >>>>> not being save and restored.
> >>>>>
> >>>>> This is as far as I can get.  Can someone suggest where I should look to find
> >>>>> out what is not being saved/restored properly, and how to go about saving and
> >>>>> restoring?
> >>>>
> >>>> You need to ensure that USBHOST/TLL context is saved as per the Save and
> >>>> Restore sequence see section "USBHOST/USBTLL Save-and-Restore
> >>>> Management" in the OMAP Technical Reference Manual.
> >>>>
> >>>> The basic idea there is that software does the context saving into SAR
> >>>> RAM before entering OFF mode and hardware automatically restores the
> >>>> context after coming out of OFF mode.
> >>>
> >>> Is it?  The way I read the doco, the hardware both saves to SAR RAM, and
> >>> restores from  SAR RAM.
> >>>   Section 22.2.4.1.6  Save and Restore
> >>> of my copy of the TRM says:
> >>>
> >>>> The save-and-restore (SAR) mechanism can extract the hardware context of the high-speed USB host
> >>>> controller (after all USB activity has been suspended) before switching off (=save), save it to an external
> >>>> always-on memory, and reinject it later after the module has been switched on again and reset (=restore)
> >>>> seamlessly for the USB. Part of that context is composed of the register fields described in the current
> >>>> chapter. The rest of the context is composed of the "buried" flip-flops and memories (not accessible by
> >>>> software) like finite state-machine (FSM) states, buffer contents, and miscellaneous random logic bits.
> >>>
> >>> which strongly suggests that it is all handled by hardware.  Of course there
> >>> are other registers that aren't covered  by the SAR - we need to identify
> >>> those and make sure they are saved and restored.  I've found a few registers
> >>> that aren't being restored, but restoring them hasn't made a visible
> >>> difference yet.
> >>
> >> Yes, you are right. I mixed it up with OMAP4 behaviour, sorry.
> >> But still, software needs to ensure that the USBHOST and CORE power
> >> domain's SAVEANDRESTORE bit are set to ensure that SAR works.
> >>
> >> see section "3.5.4.6 USBHOST/USBTLL Save-and-Restore Management"
> >>
> >> This seems to be done by the powerdomain code based on the
> >> PWRDM_HAS_HDWR_SAR flag. However, this flag is disabled for USBHOST
> >> powerdomain with the following comment.
> >>
> >>> Both USBHOST and USBTLL support a save-and-restore mechanism. When the device enters into off
> >>> mode (that is, all power domains, except the WKUP power domain, are off), the user may want to save
> >>> the USBHOST context and restore it when exiting off mode. The save-and-restore mechanism for the HS
> >>> USB Host is enabled by setting the PRCM.PM_PWSTCTRL_USBHOST[4] SAVEANDRESTORE bit; for
> >>> the USBTLL, it is configured by the PRCM.PM_PWSTCTRL_CORE[4] SAVEANDRESTORE bit. The save
> >>> mechanism is initiated as the power domain transitions from active to off state (or to OSWR state for the
> >>> USBTLL), whereas the restore mechanism is initiated as the power domain transitions from off to active
> >>> power state.
> >>
> >> Can you try with the flag enabled?
> > 
> > If I keep CORE and  USBHOST out of off-mode (by writing to the relevant
> > 'suspend' files in /sys/kernel/debug/pm-debug) then it all works.
> > 
> > If I set this flag, then I can allow USBHOST to enter off-mode as long as I
> > keep CORE in retention or better.
> > 
> > If I let CORE and USBHOST go to off-mode and don't have the flag set, then I
> > can resume from suspend, but the usb modem has disappeared.
> > 
> > If I let CORE and USBHOST go to off-mode and DO have the flag set, then I
> > cannot even resume from suspend.... sometimes.
> > 
> 
> It looks like the problem creeps in when the OMAP device hits OFF. i.e.
> CORE is allowed to go OFF.
> 
> > I hate those "sometimes"s!
> > 
> > If I remove the battery (with no other power source present) and re-insert
> > it, and let the phone boot up to  stable state and then enter suspend, I
> > cannot resume from suspend.  (I tried setting "no_console_suspend" to see if
> > anything was happening - but that keeps CORE awake).
> > 
> > If I do the same but before  it suspends I:
> > 
> >    echo 1 > /sys/kernel/debug/pm_debug/core_pwrdm/suspend
> >    
> > then let is suspend and resume, the resume works.  Then I:
> > 
> >    echo 0 > /sys/kernel/debug/pm_debug/core_pwrdm/suspend
> > 
> > to allow full sleep mode and now suspend, and again resume works.
> > And it continues to work.
> > And the USB modem remains visible - it doesn't disconnect at all.
> > 
> 
> So does repeated suspend/resume work after this? Or is it only the first
> suspend/resume.

suspend/resume continues to work until a power-down.
Even after a soft reboot (which goes back to ILO and u-boot, but doesn't
remove power), suspend/resume continue to work.
It is only after a power-off that I need one suspend cycle with CORE in
retention before things work.

> 
> > So.... something very odd is happening somewhere.
> > Maybe the USBHOST powerdomain isn't really going to off-mode again after the
> > first time like the comment in powerdomains3xxx_data.c says:
> > 
> > 	/*
> > 	 * REVISIT: Enabling usb host save and restore mechanism seems to
> > 	 * leave the usb host domain permanently in ACTIVE mode after
> > 	 * changing the usb host power domain state from OFF to active once.
> > 	 * Disabling for now.
> > 	 */
> > 
> > However the  /sys/kernel/debug/pm_debug/count file shows the "OFF" count for
> > usbhost_pwrdm increments on each suspend, and that seems to be based on info
> > read out of the the OMAP3 itself....
> > 
> > All very odd.
> 
> I need to give this a try. I can try it out on OMAP3 beagle board.
> 
> What OMAP3 are you on, and which kernel are you using for your tests?

I believe it is a DM3730

# cat /proc/cpuinfo 
Processor	: ARMv7 Processor rev 2 (v7l)
BogoMIPS	: 311.92
Features	: swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x3
CPU part	: 0xc08
CPU revision	: 2

Hardware	: GTA04
Revision	: 0020
Serial		: 0000000000000000


Kernel is the 'mainline' branch of git://neil.brown.name/gta04 (commit
  388c9f46f9d566bd7f7dd6acb45c113c59c11417)

This is 3.7 plus a bunch of fixes and additions to make it all mostly work on
this board (Panel driver, audio glue, sdio wifi fixes, sensor drivers, bug
fixes, etc etc etc).

Thanks,
NeilBrown

Help wanted with USB and OMAP3 off_mode

Commit Message

Comments

Patch