EHCI and MUSB do not discover devices without CONFIG_PM

DISCUSSION Ladislav Michl 5 participants 18 messages Nov 27, 2017 – Nov 28, 2017 8 messages not in the archive

Share & tools

Ladislav Michl

author

2017-11-27 22:08 UTC #0 lore raw

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.

Thank you,
ladis
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Greg KH

2017-11-28 07:33 UTC #1 lore raw

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

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): [email protected]

Ladislav Michl

author

2017-11-28 08:57 UTC #3 lore raw

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.

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

Felipe Balbi

2017-11-28 09:03 UTC #4 lore raw

Hi,

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

Quoted 7 lines

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

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
@@ -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 · 1 line

balbi

A message that is not in the archive (sent off-list or not yet received): 87induzseh.fsf-VuQAYsv1563Yd54FQh9/[email protected]

Ladislav Michl

author

2017-11-28 09:42 UTC #6 lore raw

Quoted 29 lines · Felipe Balbi

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

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:

That does not help. And I already have Tony's hack in the patch stack:
https://patchwork.kernel.org/patch/9643499/
So this part of SoC is not powered off at all.

Quoted 14 lines

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

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

Greg KH

2017-11-28 09:30 UTC #7 lore raw

In reply to Ladislav Michl

Quoted 14 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?

Quoted 7 lines

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.

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!

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): [email protected]

Ladislav Michl

author

2017-11-28 09:39 UTC #9 lore raw

Quoted 17 lines · Greg KH

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

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

Indeed, with CONFIG_PM=n... And that makes it the only OS without USB support out there :)

Quoted 3 lines

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.

That will not help, as jitter is comming from some part of SoC sleeping...

Quoted 10 lines

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?

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.

Tony Lindgren

2017-11-28 14:11 UTC #10 lore raw

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?

Quoted 1 line

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

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): [email protected]

Ladislav Michl

author

2017-11-28 14:28 UTC #12 lore raw

Quoted 9 lines · Tony Lindgren

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

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?

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.

ladis
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Tony Lindgren

2017-11-28 14:39 UTC #13 lore raw

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 6 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[].
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.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): [email protected]

Ladislav Michl

author

2017-11-28 16:58 UTC #15 lore raw

Quoted 28 lines · Tony Lindgren

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

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.

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

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.

Tony Lindgren

2017-11-28 17:16 UTC #16 lore raw

Quoted 8 lines · Ladislav Michl

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.

OK sounds like there is still something happening in the idle path beyond WFI then.

Quoted 2 lines

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

Sure.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Alan Stern

2017-11-28 15:00 UTC #17 lore raw

In reply to a message not in the archive

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

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

A message that is not in the archive (sent off-list or not yet received): Pine.LNX.4.44L0.1711280956560.1467-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org

Ladislav Michl

author

2017-11-28 16:05 UTC #19 lore raw

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:

[    6.466369] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    6.710723] ehci-omap: OMAP-EHCI Host Controller driver
[    7.027862] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    7.336120] ohci-platform: OHCI generic platform driver
[    7.336791] ohci-platform 48064400.ohci: Generic Platform OHCI controller
[    7.336883] ohci-platform 48064400.ohci: new USB bus registered, assigned bus number 1
[    7.357177] ohci-platform 48064400.ohci: irq 92, io mem 0x48064400
[    7.402191] omap-mailbox 48094000.mailbox: omap mailbox rev 0x40
[    7.402343] omap-mailbox: probe of 48094000.mailbox failed with error -38
[    7.608337] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
[    7.608367] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    7.608367] usb usb1: Product: Generic Platform OHCI controller
[    7.608398] usb usb1: Manufacturer: Linux 4.15.0-rc1 ohci_hcd
[    7.608398] usb usb1: SerialNumber: 48064400.ohci
[    7.623779] hub 1-0:1.0: USB hub found
[    7.627380] hub 1-0:1.0: 3 ports detected
[    7.831878] omap-sham 480c3000.sham: hw accel on OMAP rev 0.9
[    8.218322] twl4030_usb 48070000.i2c:twl@48:twl4030-usb: Initialized TWL4030 USB module
[    8.224212] musb-hdrc musb-hdrc.0.auto: MUSB HDRC host driver
[    8.224304] musb-hdrc musb-hdrc.0.auto: new USB bus registered, assigned bus number 2
[    8.242736] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[    8.242767] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    8.242767] usb usb2: Product: MUSB HDRC host driver
[    8.242767] usb usb2: Manufacturer: Linux 4.15.0-rc1 musb-hcd
[    8.242797] usb usb2: SerialNumber: musb-hdrc.0.auto
[    8.246093] hub 2-0:1.0: USB hub found
[    8.246673] hub 2-0:1.0: 1 port detected
[    8.461669] omap-aes 480c5000.aes: OMAP AES hw accel rev: 2.6
[    8.463500] omap-aes 480c5000.aes: will run requests pump with realtime priority
[    8.937469] input: beeper as /devices/platform/beeper/input/input1
[    9.188262] ehci-omap 48064800.ehci: EHCI Host Controller
[    9.188323] ehci-omap 48064800.ehci: new USB bus registered, assigned bus number 3
[    9.188629] ehci-omap 48064800.ehci: irq 93, io mem 0x48064800
[    9.217407] ehci-omap 48064800.ehci: USB 2.0 started, EHCI 1.00
[    9.217803] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002
[    9.217803] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    9.217834] usb usb3: Product: EHCI Host Controller
[    9.217834] usb usb3: Manufacturer: Linux 4.15.0-rc1 ehci_hcd
[    9.217834] usb usb3: SerialNumber: 48064800.ehci
[    9.218841] hub 3-0:1.0: USB hub found
[    9.218963] hub 3-0:1.0: 3 ports detected

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.

$ cat /sys/kernel/debug/usb/ohci/48064400.ohci/registers 
bus platform, device 48064400.ohci
Generic Platform OHCI controller
ohci_hcd
OHCI 1.0, NO legacy support registers, rh state running
control 0x083 HCFS=operational CBSR=3
cmdstatus 0x00000 SOC=0
intrstatus 0x00000024 FNO SF
intrenable 0x8000005a MIE RHSC UE RD WDH
hcca frame 0xb9ae
fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf
fmremaining 0x80000857 FRT FR=0x0857
periodicstart 0x2a2f
lsthresh 0x0628
hub poll timer off
roothub.a 0a000203 POTPGT=10 NPS NDP=3(3)
roothub.b 00000000 PPCM=0000 DR=0000
roothub.status 00008000 DRWE
roothub.portstatus [0] 0x00000100 PPS
roothub.portstatus [1] 0x00000100 PPS
roothub.portstatus [2] 0x00000100 PPS

Quoted 2 lines

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

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

Quoted 1 line

Alan Stern

Alan Stern

2017-11-28 18:09 UTC #20 lore raw

Quoted 21 lines · Ladislav Michl

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

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.

...

Quoted 1 line

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.

Alan Stern

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

A message that is not in the archive (sent off-list or not yet received): Pine.LNX.4.44L0.1711281307250.1467-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org

Ladislav Michl

author

2017-11-28 19:27 UTC #22 lore raw

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

$ lsusb -t
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-omap/3p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/3p, 12M

ladis
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Alan Stern

2017-11-28 19:59 UTC #23 lore raw

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

Alan Stern

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

A message that is not in the archive (sent off-list or not yet received): Pine.LNX.4.44L0.1711281452520.1467-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org

Ladislav Michl

author

2017-11-28 20:14 UTC #25 lore raw

Quoted 43 lines · Alan Stern

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

Quoted 7 lines

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.

Thanks for suggestion, there's USB3326 ULPI PHY with nEN_USB_PWR connected to TWL4030 LEDA output.

Quoted 5 lines

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

Unfortunately there's only one EHCI port, however your suggestions are enough to start debugging.