Help wanted with USB and OMAP3 off_mode

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

drivers/mfd/omap-usb-host.c +8 -0

index 23cec57..522405e 100644
@@ -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;

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

Hi Neil,

Quoted 1 line · NeilBrown

Quoted 6 lines

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

Quoted 59 lines

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

drivers/mfd/omap-usb-host.c +8 -0

index 23cec57..522405e 100644
@@ -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;

drivers/mfd/omap-usb-host.c static int usbhs_runtime_suspend(struct device *dev) · line 334

Quoted 8 lines

drivers/mfd/omap-usb-host.c +2 -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-----

Quoted 7 lines · On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg <[email protected]>…

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

Hi Neil,

Quoted 1 line · NeilBrown

Quoted 8 lines

Quoted 6 lines

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

Quoted 64 lines

Quoted 64 lines

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

drivers/mfd/omap-usb-host.c +10 -0

index 23cec57..522405e 100644
@@ -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);
 

Quoted 7 lines

drivers/mfd/omap-usb-host.c static int usbhs_runtime_suspend(struct device *dev) · line 334

Quoted 2 lines

drivers/mfd/omap-usb-host.c +0 -0

 	if (is_ehci_tll_mode(pdata->port_mode[0]))
 		clk_disable(omap->usbhost_p1_fck);

- --
Regards,
Igor.

N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±¢f©Š{ayºʇڙë,j­¢f£¢·hš‹àz¹®w¥¢¸¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾«‘êçzZ+ƒùšŽŠÝ¢j"�ú!tml=

Hi Neil

Quoted 22 lines · NeilBrown

Quoted 7 lines · On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg <[email protected]>…

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

Hi Neil,

Quoted 1 line · NeilBrown

Quoted 8 lines

Quoted 6 lines

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

Quoted 6 lines

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?

Quoted 25 lines · On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi…

Hi Neil

Quoted 22 lines · NeilBrown

Quoted 7 lines · On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg <[email protected]>…

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

Hi Neil,

Quoted 1 line · NeilBrown

Quoted 8 lines

Quoted 6 lines

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

Quoted 9 lines

Quoted 6 lines

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

Quoted 52 lines · NeilBrown

Quoted 25 lines · On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi…

Hi Neil

Quoted 22 lines · NeilBrown

Quoted 7 lines · On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg <[email protected]>…

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

Hi Neil,

Quoted 1 line · NeilBrown

Quoted 8 lines

Quoted 6 lines

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

Quoted 9 lines

Quoted 6 lines

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

Quoted 3 lines

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?

Quoted 32 lines · On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi…

Hi Neil

Quoted 28 lines · NeilBrown

Quoted 7 lines · On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg <[email protected]>…

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

Hi Neil,

Quoted 1 line · NeilBrown

Quoted 8 lines

Quoted 6 lines

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

Quoted 2 lines

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

Hi Neil

I forget to answer to your questions

Quoted 34 lines · NeilBrown

Quoted 31 lines · On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi…

Hi Neil

Quoted 28 lines · NeilBrown

Quoted 7 lines · On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg <[email protected]>…

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

Hi Neil,

Quoted 1 line · NeilBrown

Quoted 8 lines

Quoted 6 lines

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

Quoted 6 lines

Quoted 3 lines

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

Quoted 2 lines

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

Quoted 39 lines · Michael Trimarchi

Hi Neil

I forget to answer to your questions

Quoted 34 lines · NeilBrown

Quoted 31 lines · On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi…

Hi Neil

Quoted 28 lines · NeilBrown

Quoted 7 lines · On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg <[email protected]>…

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

Hi Neil,

Quoted 1 line · NeilBrown

Quoted 8 lines

Quoted 6 lines

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.

Quoted 9 lines

Quoted 7 lines

Quoted 4 lines

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.

Quoted 6 lines

Quoted 2 lines

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.

Quoted 41 lines · On Wed, 09 Jan 2013 14:54:00 +0200 Igor Grinberg <[email protected]>…

Quoted 39 lines · Michael Trimarchi

Hi Neil

I forget to answer to your questions

Quoted 34 lines · NeilBrown

Quoted 31 lines · On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi…

Hi Neil

Quoted 28 lines · NeilBrown

Quoted 7 lines · On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg <[email protected]>…

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

Hi Neil,

Quoted 1 line · NeilBrown

Quoted 8 lines

Quoted 6 lines

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

Quoted 5 lines

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.

Quoted 22 lines

Quoted 9 lines

Quoted 7 lines

Quoted 4 lines

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.

Quoted 6 lines

Quoted 2 lines

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.

Quoted 3 lines

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.

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

Quoted 77 lines · NeilBrown

Quoted 41 lines · On Wed, 09 Jan 2013 14:54:00 +0200 Igor Grinberg <[email protected]>…

Quoted 39 lines · Michael Trimarchi

Hi Neil

I forget to answer to your questions

Quoted 34 lines · NeilBrown

Quoted 31 lines · On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi…

Hi Neil

Quoted 28 lines · NeilBrown

Quoted 7 lines · On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg <[email protected]>…

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

Hi Neil,

Quoted 1 line · NeilBrown

Quoted 8 lines

Quoted 6 lines

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

Quoted 5 lines

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.

Quoted 22 lines

Quoted 9 lines

Quoted 7 lines

Quoted 4 lines

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.

Quoted 6 lines

Quoted 2 lines

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.

Quoted 6 lines

Quoted 3 lines

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.

Quoted 99 lines · On Wed, 16 Jan 2013 11:28:02 +0200 Igor Grinberg <[email protected]>…

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

Quoted 77 lines · NeilBrown

Quoted 41 lines · On Wed, 09 Jan 2013 14:54:00 +0200 Igor Grinberg <[email protected]>…

Quoted 39 lines · Michael Trimarchi

Hi Neil

I forget to answer to your questions

Quoted 34 lines · NeilBrown

Quoted 31 lines · On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi…

Hi Neil

Quoted 28 lines · NeilBrown

Quoted 7 lines · On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg <[email protected]>…

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

Hi Neil,

Quoted 1 line · NeilBrown

Quoted 8 lines

Quoted 6 lines

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

Quoted 5 lines

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.

Quoted 22 lines

Quoted 9 lines

Quoted 7 lines

Quoted 4 lines

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.

Quoted 6 lines

Quoted 2 lines

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.

Quoted 6 lines

Quoted 3 lines

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.

Quoted 1 line

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

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

Quoted 103 lines · NeilBrown

Quoted 99 lines · On Wed, 16 Jan 2013 11:28:02 +0200 Igor Grinberg <[email protected]>…

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

Quoted 77 lines · NeilBrown

Quoted 41 lines · On Wed, 09 Jan 2013 14:54:00 +0200 Igor Grinberg <[email protected]>…

Quoted 39 lines · Michael Trimarchi

Hi Neil

I forget to answer to your questions

Quoted 34 lines · NeilBrown

Quoted 31 lines · On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi…

Hi Neil

Quoted 28 lines · NeilBrown

Quoted 7 lines · On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg <[email protected]>…

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

Hi Neil,

Quoted 1 line · NeilBrown

Quoted 8 lines

Quoted 6 lines

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

Quoted 5 lines

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.

Quoted 22 lines

Quoted 9 lines

Quoted 7 lines

Quoted 4 lines

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.

Quoted 6 lines

Quoted 2 lines

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.

Quoted 6 lines

Quoted 3 lines

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.

Quoted 7 lines

Quoted 1 line

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

Quoted 1 line

Quoted 5 lines

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

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

Quoted 118 lines · On Wed, 16 Jan 2013 13:11:26 +0200 Igor Grinberg <[email protected]>…

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

Quoted 103 lines · NeilBrown

Quoted 99 lines · On Wed, 16 Jan 2013 11:28:02 +0200 Igor Grinberg <[email protected]>…

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

Quoted 77 lines · NeilBrown

Quoted 41 lines · On Wed, 09 Jan 2013 14:54:00 +0200 Igor Grinberg <[email protected]>…

Quoted 39 lines · Michael Trimarchi

Hi Neil

I forget to answer to your questions

Quoted 34 lines · NeilBrown

Quoted 31 lines · On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi…

Hi Neil

Quoted 28 lines · NeilBrown

Quoted 7 lines · On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg <[email protected]>…

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

Hi Neil,

Quoted 1 line · NeilBrown

Quoted 8 lines

Quoted 6 lines

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

Quoted 5 lines

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.

Quoted 22 lines

Quoted 9 lines

Quoted 7 lines

Quoted 4 lines

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.

Quoted 6 lines

Quoted 2 lines

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.

Quoted 6 lines

Quoted 3 lines

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.

Quoted 7 lines

Quoted 1 line

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

Quoted 1 line

Quoted 9 lines

Quoted 5 lines

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.

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?

Quoted 25 lines · NeilBrown

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

Quoted 7 lines

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.

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.

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

Quoted 34 lines · On Wed, 16 Jan 2013 12:00:48 +0200 Roger Quadros <[email protected]> wrote:

Quoted 25 lines · NeilBrown

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

Quoted 7 lines

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?

Quoted 7 lines

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:

Quoted 6 lines

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.

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.

Am I missing something?

Quoted 4 lines

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?

Quoted 56 lines · NeilBrown

Quoted 34 lines · On Wed, 16 Jan 2013 12:00:48 +0200 Roger Quadros <[email protected]> wrote:

Quoted 25 lines · NeilBrown

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

Quoted 7 lines

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?

Quoted 7 lines

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:

Quoted 6 lines

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.

Quoted 5 lines

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.

Quoted 8 lines

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?

Quoted 82 lines · On Wed, 16 Jan 2013 12:57:08 +0200 Roger Quadros <[email protected]> wrote:

Quoted 56 lines · NeilBrown

Quoted 34 lines · On Wed, 16 Jan 2013 12:00:48 +0200 Roger Quadros <[email protected]> wrote:

Quoted 25 lines · NeilBrown

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

Quoted 7 lines

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?

Quoted 7 lines

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:

Quoted 6 lines

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.

Quoted 5 lines

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.

Quoted 8 lines

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.

Quoted 1 line

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.

Quoted 89 lines · NeilBrown

Quoted 82 lines · On Wed, 16 Jan 2013 12:57:08 +0200 Roger Quadros <[email protected]> wrote:

Quoted 56 lines · NeilBrown

Quoted 34 lines · On Wed, 16 Jan 2013 12:00:48 +0200 Roger Quadros <[email protected]> wrote:

Quoted 25 lines · NeilBrown

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

Quoted 7 lines

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?

Quoted 7 lines

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:

Quoted 6 lines

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.

Quoted 5 lines

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.

Quoted 8 lines

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.

Quoted 1 line

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.

Quoted 9 lines

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.

Quoted 15 lines

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

Quoted 4 lines

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.

Quoted 16 lines

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

Quoted 1 line

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?