EHCI and MUSB do not discover devices without CONFIG_PM

Hi there,

USB hosts do not discover any connected device on OMAP3 based board with CONFIG_PM=n. Just enabling this option is enough to restore working behaviour. Nothing unusual in log. Tested 4.14.2 and 4.15-rc1. I know a lot of stuff depends on CONFIG_PM, but is this expected behaviour? Neither EHCI nor MUSB is working without CONFIG_PM.

Quoted 7 lines · Ladislav Michl

Hi there,

USB hosts do not discover any connected device on OMAP3 based board with CONFIG_PM=n. Just enabling this option is enough to restore working behaviour. Nothing unusual in log. Tested 4.14.2 and 4.15-rc1. I know a lot of stuff depends on CONFIG_PM, but is this expected behaviour? Neither EHCI nor MUSB is working without CONFIG_PM.

What bus type is your controllers on? PCI? platform? Something else?

And yes, perhaps this is to be expected, why would you not want CONFIG_PM to be enabled? :)

Quoted 10 lines · Greg KH

Quoted 7 lines · Ladislav Michl

Hi there,

USB hosts do not discover any connected device on OMAP3 based board with CONFIG_PM=n. Just enabling this option is enough to restore working behaviour. Nothing unusual in log. Tested 4.14.2 and 4.15-rc1. I know a lot of stuff depends on CONFIG_PM, but is this expected behaviour? Neither EHCI nor MUSB is working without CONFIG_PM.

What bus type is your controllers on? PCI? platform? Something else?

Platform controllers inside OMAP3630 Soc.

Quoted 2 lines

And yes, perhaps this is to be expected, why would you not want CONFIG_PM to be enabled? :)

For a start, I know Linux is general purpose OS and I know I cannot expect low latency or low jitter when dealing with interrupts.

Original problem is described here:
https://www.spinics.net/lists/linux-omap/msg140081.html

Shortly, with CONFIG_PM jitter of GPIO interrupt is about 350us which renders IR receiver unuseable - is cannot reliably decode IR protocol (gpio-ir-recv is used). With CONFIG_PM disabled, jitter is around 30us and that's enough to make IR decoders work.

And as I was unable to fix it, nor anyone provided useful hint, I though I could work around problem from another side. And here we are...

Hi Greg,

Quoted 10 lines · Greg KH

Quoted 7 lines · Ladislav Michl

Hi there,

USB hosts do not discover any connected device on OMAP3 based board with CONFIG_PM=n. Just enabling this option is enough to restore working behaviour. Nothing unusual in log. Tested 4.14.2 and 4.15-rc1. I know a lot of stuff depends on CONFIG_PM, but is this expected behaviour? Neither EHCI nor MUSB is working without CONFIG_PM.

What bus type is your controllers on? PCI? platform? Something else?

Platform controllers inside OMAP3630 Soc.

Quoted 2 lines

And yes, perhaps this is to be expected, why would you not want CONFIG_PM to be enabled? :)

For a start, I know Linux is general purpose OS and I know I cannot expect low latency or low jitter when dealing with interrupts.

Original problem is described here:
https://www.spinics.net/lists/linux-omap/msg140081.html

Shortly, with CONFIG_PM jitter of GPIO interrupt is about 350us which renders IR receiver unuseable - is cannot reliably decode IR protocol (gpio-ir-recv is used). With CONFIG_PM disabled, jitter is around 30us and that's enough to make IR decoders work.

Quoted 16 lines · Ladislav Michl

Hi Greg,

Quoted 10 lines · Greg KH

Quoted 7 lines · Ladislav Michl

Hi there,

USB hosts do not discover any connected device on OMAP3 based board with CONFIG_PM=n. Just enabling this option is enough to restore working behaviour. Nothing unusual in log. Tested 4.14.2 and 4.15-rc1. I know a lot of stuff depends on CONFIG_PM, but is this expected behaviour? Neither EHCI nor MUSB is working without CONFIG_PM.

What bus type is your controllers on? PCI? platform? Something else?

Platform controllers inside OMAP3630 Soc.

Quoted 5 lines

Quoted 2 lines

And yes, perhaps this is to be expected, why would you not want CONFIG_PM to be enabled? :)

For a start, I know Linux is general purpose OS and I know I cannot expect low latency or low jitter when dealing with interrupts.

Well, it's the best latency of any other OS out there :)

Anyway, if you want guaranteed response time, you are going to have to use the RT patchset, no matter what. Otherwise you have the potential to have bad jitter at times.

Quoted 7 lines

Original problem is described here:
https://www.spinics.net/lists/linux-omap/msg140081.html

Shortly, with CONFIG_PM jitter of GPIO interrupt is about 350us which renders IR receiver unuseable - is cannot reliably decode IR protocol (gpio-ir-recv is used). With CONFIG_PM disabled, jitter is around 30us and that's enough to make IR decoders work.

bit-banging an ir decoder, ugh, you are in for a world of hurt. Can't you put a chip on the device that does this for you in hardware?

Anyway, good luck!

Quoted 28 lines · Ladislav Michl

Quoted 10 lines · Greg KH

Quoted 7 lines · Ladislav Michl

Hi there,

USB hosts do not discover any connected device on OMAP3 based board with CONFIG_PM=n. Just enabling this option is enough to restore working behaviour. Nothing unusual in log. Tested 4.14.2 and 4.15-rc1. I know a lot of stuff depends on CONFIG_PM, but is this expected behaviour? Neither EHCI nor MUSB is working without CONFIG_PM.

What bus type is your controllers on? PCI? platform? Something else?

Platform controllers inside OMAP3630 Soc.

Quoted 2 lines

And yes, perhaps this is to be expected, why would you not want CONFIG_PM to be enabled? :)

For a start, I know Linux is general purpose OS and I know I cannot expect low latency or low jitter when dealing with interrupts.

Original problem is described here:
https://www.spinics.net/lists/linux-omap/msg140081.html

Shortly, with CONFIG_PM jitter of GPIO interrupt is about 350us which renders IR receiver unuseable - is cannot reliably decode IR protocol (gpio-ir-recv is used). With CONFIG_PM disabled, jitter is around 30us and that's enough to make IR decoders work.

Quoted 2 lines

And as I was unable to fix it, nor anyone provided useful hint, I though I could work around problem from another side. And here we are...

Isn't it enough to just set a huge timeout for GPIO's runtime_pm? You can do that through sysfs. Just write a big number to the GPIO's autosuspend_delay_ms file. This should help you:

modified drivers/gpio/gpio-omap.c

(quoted diff) +2 -0

@@ -1238,6 +1238,8 @@ static int omap_gpio_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, bank);
 
+	pm_runtime_use_autosuspend(dev);
+	pm_runtime_set_autosuspend_delay(dev, 60000);
 	pm_runtime_enable(dev);
 	pm_runtime_irq_safe(dev);
 	pm_runtime_get_sync(dev);

Signature · 2 lines

-- 
balbi

Quoted 2 lines · Greg KH

bit-banging an ir decoder, ugh, you are in for a world of hurt. Can't you put a chip on the device that does this for you in hardware?

OMAP has DM timer which can be externally trigered on edge. Perfect for that purpose. But I cannot pinmux its input as hw designers did poor job. And there are thousands of devices deployed.

So it is about a lot of soldering or providing software solution.

Quoted 1 line

Anyway, good luck!

A little pointer would increase "luck" by several order of magnitudes.

From what I recall you just set the latency to less than C2

Quoted 8 lines · Ladislav Michl

Quoted 2 lines · Greg KH

bit-banging an ir decoder, ugh, you are in for a world of hurt. Can't you put a chip on the device that does this for you in hardware?

OMAP has DM timer which can be externally trigered on edge. Perfect for that purpose. But I cannot pinmux its input as hw designers did poor job. And there are thousands of devices deployed.

Quoted 5 lines

So it is about a lot of soldering or providing software solution.

Quoted 1 line

Anyway, good luck!

A little pointer would increase "luck" by several order of magnitudes.

Hmm did you already try limiting cpuidle to C1 only in /sys?

From what I recall you just set the latency to less than C2 has. The cpuidle latencies are in struct omap3_idle_statedata omap3_idle_data[].

Quoted 11 lines · Tony Lindgren

Quoted 10 lines · Ladislav Michl

Quoted 2 lines · Greg KH

bit-banging an ir decoder, ugh, you are in for a world of hurt. Can't you put a chip on the device that does this for you in hardware?

OMAP has DM timer which can be externally trigered on edge. Perfect for that purpose. But I cannot pinmux its input as hw designers did poor job. And there are thousands of devices deployed.

So it is about a lot of soldering or providing software solution.

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

Anyway, good luck!

A little pointer would increase "luck" by several order of magnitudes.

Hmm did you already try limiting cpuidle to C1 only in /sys?

I have CONFIG_CPU_IDLE=n, which should be the same. Is that right?

Quoted 3 lines

From what I recall you just set the latency to less than C2 has. The cpuidle latencies are in struct omap3_idle_statedata omap3_idle_data[].

I disabled cpuidle and frequency scaling completely. The only thing that make jitter difference is CONFIG_PM (see original thread).

There's lot of pm_wkup interrupts with CONFIG_PM - order of magnitude more than gp_timer.

Quoted 7 lines · Ladislav Michl

Hi there,

USB hosts do not discover any connected device on OMAP3 based board with CONFIG_PM=n. Just enabling this option is enough to restore working behaviour. Nothing unusual in log. Tested 4.14.2 and 4.15-rc1. I know a lot of stuff depends on CONFIG_PM, but is this expected behaviour? Neither EHCI nor MUSB is working without CONFIG_PM.

What bus type is your controllers on? PCI? platform? Something else?

And yes, perhaps this is to be expected, why would you not want CONFIG_PM to be enabled? :)

Quoted 9 lines · Greg KH

Quoted 7 lines · Ladislav Michl

Hi there,

USB hosts do not discover any connected device on OMAP3 based board with CONFIG_PM=n. Just enabling this option is enough to restore working behaviour. Nothing unusual in log. Tested 4.14.2 and 4.15-rc1. I know a lot of stuff depends on CONFIG_PM, but is this expected behaviour? Neither EHCI nor MUSB is working without CONFIG_PM.

Quoted 4 lines

What bus type is your controllers on? PCI? platform? Something else?

And yes, perhaps this is to be expected, why would you not want CONFIG_PM to be enabled? :)

Well, no, it's not expected. Systems are supposed to work correctly with CONFIG_PM=n -- just not at an optimum power level.

EHCI certainly should work without CONFIG_PM. When a device is plugged in to the EHCI controller, what shows up in /sys/kernel/debug/usb/ehci/*/registers (fill in the '*' with the correct bus ID)?

For that matter, what does that file contain before any devices are plugged in?

Alan Stern

Quoted 12 lines · Ladislav Michl

Quoted 11 lines · Tony Lindgren

Quoted 10 lines · Ladislav Michl

Quoted 2 lines · Greg KH

bit-banging an ir decoder, ugh, you are in for a world of hurt. Can't you put a chip on the device that does this for you in hardware?

OMAP has DM timer which can be externally trigered on edge. Perfect for that purpose. But I cannot pinmux its input as hw designers did poor job. And there are thousands of devices deployed.

So it is about a lot of soldering or providing software solution.

Quoted 7 lines

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

Anyway, good luck!

A little pointer would increase "luck" by several order of magnitudes.

Hmm did you already try limiting cpuidle to C1 only in /sys?

I have CONFIG_CPU_IDLE=n, which should be the same. Is that right?

You will then use the omap3_pm_idle() that does not know much anything about latencies.

Quoted 4 lines

Quoted 3 lines

From what I recall you just set the latency to less than C2 has. The cpuidle latencies are in struct omap3_idle_statedata omap3_idle_data[].

Quoted 2 lines

I disabled cpuidle and frequency scaling completely. The only thing that make jitter difference is CONFIG_PM (see original thread).

Right as then omap3_pm_idle() is disabled and only WFI is done :)

Limiting things to C1 with cpuidle is probably what you need for having USB also working.

Quoted 2 lines

There's lot of pm_wkup interrupts with CONFIG_PM - order of magnitude more than gp_timer.

Hmm yeah that is true. And idling and waking up devices also takes some time.

Quoted 2 lines · Tony Lindgren

Limiting things to C1 with cpuidle is probably what you need for having USB also working.

With echo 1 > /sys/devices/system/cpu/cpu0/cpuidle/state{1-6}/disable jitter is about 100us which is about 3x worse than with CONFIG_PM disabled (and much better when idling), but decoder works with occassional errors.

Anyway, it would be nice to find out why USB does not work with CONFIG_PM disabled :)

Quoted 11 lines · Alan Stern

Quoted 9 lines · Greg KH

Quoted 7 lines · Ladislav Michl

Hi there,

USB hosts do not discover any connected device on OMAP3 based board with CONFIG_PM=n. Just enabling this option is enough to restore working behaviour. Nothing unusual in log. Tested 4.14.2 and 4.15-rc1. I know a lot of stuff depends on CONFIG_PM, but is this expected behaviour? Neither EHCI nor MUSB is working without CONFIG_PM.

Quoted 7 lines

Quoted 4 lines

What bus type is your controllers on? PCI? platform? Something else?

And yes, perhaps this is to be expected, why would you not want CONFIG_PM to be enabled? :)

Well, no, it's not expected. Systems are supposed to work correctly with CONFIG_PM=n -- just not at an optimum power level.

Here's relevant part of bootlog:

Quoted 4 lines

EHCI certainly should work without CONFIG_PM. When a device is plugged in to the EHCI controller, what shows up in /sys/kernel/debug/usb/ehci/*/registers (fill in the '*' with the correct bus ID)?

$ ls /sys/kernel/debug/usb
devices  ohci

So no ehci.

For ohci it is the same. Any hint why there's no ehco file?

The EHCI debugging files require CONFIG_DYNAMIC_DEBUG to be enabled. Oddly enough, the OHCI debugging files do not have the same requirement. I don't know the reason for this difference.

Quoted 3 lines · Alan Stern

The EHCI debugging files require CONFIG_DYNAMIC_DEBUG to be enabled. Oddly enough, the OHCI debugging files do not have the same requirement. I don't know the reason for this difference.

I see, thanks for suggestion.

USB cable unplugged:

$ cat /sys/kernel/debug/usb/ehci/48064800.ehci/registers 
bus platform, device 48064800.ehci
EHCI Host Controller
EHCI 1.00, rh state running
structural params 0x00001313
capability params 0x00000016
status 0000
command 0010005 (park)=0 ithresh=1 period=512 RUN
intrenable 37 IAA FATAL PCD ERR INT
uframe 0000
port:1 status 001000 0  ACK POWER sig=se0
port:2 status 001000 0  ACK POWER sig=se0
port:3 status 001000 0  ACK POWER sig=se0
irq normal 0 err 0 iaa 0 (lost 0)
complete 0 unlink 0

Plugged:

$ cat /sys/kernel/debug/usb/ehci/48064800.ehci/registers 
bus platform, device 48064800.ehci
EHCI Host Controller
EHCI 1.00, rh state running
structural params 0x00001313
capability params 0x00000016
status 0000
command 0010005 (park)=0 ithresh=1 period=512 RUN
intrenable 37 IAA FATAL PCD ERR INT
uframe 0000
port:1 status 001000 0  ACK POWER sig=se0
port:2 status 001000 0  ACK POWER sig=se0
port:3 status 001000 0  ACK POWER sig=se0
irq normal 0 err 0 iaa 0 (lost 0)
complete 0 unlink 0

Quoted 25 lines · Ladislav Michl

Quoted 3 lines · Alan Stern

The EHCI debugging files require CONFIG_DYNAMIC_DEBUG to be enabled. Oddly enough, the OHCI debugging files do not have the same requirement. I don't know the reason for this difference.

I see, thanks for suggestion.

USB cable unplugged:

$ cat /sys/kernel/debug/usb/ehci/48064800.ehci/registers 
bus platform, device 48064800.ehci
EHCI Host Controller
EHCI 1.00, rh state running
structural params 0x00001313
capability params 0x00000016
status 0000
command 0010005 (park)=0 ithresh=1 period=512 RUN
intrenable 37 IAA FATAL PCD ERR INT
uframe 0000
port:1 status 001000 0  ACK POWER sig=se0
port:2 status 001000 0  ACK POWER sig=se0
port:3 status 001000 0  ACK POWER sig=se0
irq normal 0 err 0 iaa 0 (lost 0)
complete 0 unlink 0

Plugged:

Quoted 15 lines

$ cat /sys/kernel/debug/usb/ehci/48064800.ehci/registers 
bus platform, device 48064800.ehci
EHCI Host Controller
EHCI 1.00, rh state running
structural params 0x00001313
capability params 0x00000016
status 0000
command 0010005 (park)=0 ithresh=1 period=512 RUN
intrenable 37 IAA FATAL PCD ERR INT
uframe 0000
port:1 status 001000 0  ACK POWER sig=se0
port:2 status 001000 0  ACK POWER sig=se0
port:3 status 001000 0  ACK POWER sig=se0
irq normal 0 err 0 iaa 0 (lost 0)
complete 0 unlink 0

So no change at all. In particular, no change to the port statuses. This suggests the hardware isn't configured properly; maybe a phy isn't detecting the new connection.

I don't know anything about the phy drivers, however. You should bring this to the attention of the maintainer for whichever phy is on your board.

By the way, the behavior when you plug in a device with CONFIG_PM=n should be just about the same as the behavior with CONFIG_PM=y when you plug in a _second_ device. Have you tried doing that, say with two flash drives? (I'm assuming your board has more than one EHCI port available.)