EHCI and MUSB do not discover devices without CONFIG_PM

EHCI and MUSB do not discover devices without CONFIG_PM

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

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

Re: EHCI and MUSB do not discover devices without CONFIG_PM

[Greg KH]

On Mon, Nov 27, 2017 at 11:08:33PM +0100, Ladislav Michl wrote:
> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: EHCI and MUSB do not discover devices without CONFIG_PM

[Ladislav Michl]

Hi Greg,

On Tue, Nov 28, 2017 at 08:33:28AM +0100, Greg KH wrote:
> On Mon, Nov 27, 2017 at 11:08:33PM +0100, Ladislav Michl wrote:
> > 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.

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

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

Re: EHCI and MUSB do not discover devices without CONFIG_PM

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2023 bytes --]


Hi,

Ladislav Michl <ladis-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org> writes:
> On Tue, Nov 28, 2017 at 08:33:28AM +0100, Greg KH wrote:
>> On Mon, Nov 27, 2017 at 11:08:33PM +0100, Ladislav Michl wrote:
>> > 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.
>
>> 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...

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


-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: EHCI and MUSB do not discover devices without CONFIG_PM

[Greg KH]

On Tue, Nov 28, 2017 at 09:57:51AM +0100, Ladislav Michl wrote:
> Hi Greg,
> 
> On Tue, Nov 28, 2017 at 08:33:28AM +0100, Greg KH wrote:
> > On Mon, Nov 27, 2017 at 11:08:33PM +0100, Ladislav Michl wrote:
> > > 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.
> 
> > 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.

> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: EHCI and MUSB do not discover devices without CONFIG_PM

[Ladislav Michl]

On Tue, Nov 28, 2017 at 10:30:54AM +0100, Greg KH wrote:
> On Tue, Nov 28, 2017 at 09:57:51AM +0100, Ladislav Michl wrote:
> > Hi Greg,
> > 
> > On Tue, Nov 28, 2017 at 08:33:28AM +0100, Greg KH wrote:
> > > On Mon, Nov 27, 2017 at 11:08:33PM +0100, Ladislav Michl wrote:
> > > > 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.
> > 
> > > 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 :)

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

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

> Anyway, good luck!

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

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

Re: EHCI and MUSB do not discover devices without CONFIG_PM

[Ladislav Michl]

On Tue, Nov 28, 2017 at 11:03:50AM +0200, Felipe Balbi wrote:
> Ladislav Michl <ladis-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org> writes:
> > On Tue, Nov 28, 2017 at 08:33:28AM +0100, Greg KH wrote:
> >> On Mon, Nov 27, 2017 at 11:08:33PM +0100, Ladislav Michl wrote:
> >> > 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.
> >
> >> 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...
> 
> 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.

> 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);
> 
> 
> -- 
> balbi


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

Re: EHCI and MUSB do not discover devices without CONFIG_PM

[Tony Lindgren]

* Ladislav Michl <ladis-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org> [171128 09:42]:
> On Tue, Nov 28, 2017 at 10:30:54AM +0100, Greg KH wrote:
> > 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.
> 
> > 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[].

Regards,

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

Re: EHCI and MUSB do not discover devices without CONFIG_PM

[Ladislav Michl]

On Tue, Nov 28, 2017 at 06:11:31AM -0800, Tony Lindgren wrote:
> * Ladislav Michl <ladis-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org> [171128 09:42]:
> > On Tue, Nov 28, 2017 at 10:30:54AM +0100, Greg KH wrote:
> > > 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.
> > 
> > > 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?

> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: EHCI and MUSB do not discover devices without CONFIG_PM

[Tony Lindgren]

* Ladislav Michl <ladis-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org> [171128 14:31]:
> On Tue, Nov 28, 2017 at 06:11:31AM -0800, Tony Lindgren wrote:
> > * Ladislav Michl <ladis-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org> [171128 09:42]:
> > > On Tue, Nov 28, 2017 at 10:30:54AM +0100, Greg KH wrote:
> > > > 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.
> > > 
> > > > 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.

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

> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: EHCI and MUSB do not discover devices without CONFIG_PM

[Alan Stern]

On Tue, 28 Nov 2017, Greg KH wrote:

> On Mon, Nov 27, 2017 at 11:08:33PM +0100, Ladislav Michl wrote:
> > 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?  :)

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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: EHCI and MUSB do not discover devices without CONFIG_PM

[Ladislav Michl]

On Tue, Nov 28, 2017 at 10:00:32AM -0500, Alan Stern wrote:
> On Tue, 28 Nov 2017, Greg KH wrote:
> 
> > On Mon, Nov 27, 2017 at 11:08:33PM +0100, Ladislav Michl wrote:
> > > 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?  :)
> 
> 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

> 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

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

> Alan Stern

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

Re: EHCI and MUSB do not discover devices without CONFIG_PM

[Ladislav Michl]

On Tue, Nov 28, 2017 at 06:39:13AM -0800, Tony Lindgren wrote:
> * Ladislav Michl <ladis-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org> [171128 14:31]:
> > On Tue, Nov 28, 2017 at 06:11:31AM -0800, Tony Lindgren wrote:
> > > * Ladislav Michl <ladis-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org> [171128 09:42]:
> > > > On Tue, Nov 28, 2017 at 10:30:54AM +0100, Greg KH wrote:
> > > > > 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.
> > > > 
> > > > > 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.
> 
> > > 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.

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

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

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

Re: EHCI and MUSB do not discover devices without CONFIG_PM

[Tony Lindgren]

* Ladislav Michl <ladis-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org> [171128 17:01]:
> On Tue, Nov 28, 2017 at 06:39:13AM -0800, Tony Lindgren wrote:
> > 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.

> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: EHCI and MUSB do not discover devices without CONFIG_PM

[Alan Stern]

On Tue, 28 Nov 2017, Ladislav Michl wrote:

> On Tue, Nov 28, 2017 at 10:00:32AM -0500, Alan Stern wrote:
> > On Tue, 28 Nov 2017, Greg KH wrote:
> > 
> > > On Mon, Nov 27, 2017 at 11:08:33PM +0100, Ladislav Michl wrote:
> > > > 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?  :)
> > 
> > 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:
...

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

Alan Stern

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

Re: EHCI and MUSB do not discover devices without CONFIG_PM

[Ladislav Michl]

On Tue, Nov 28, 2017 at 01:09:45PM -0500, Alan Stern wrote:
> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: EHCI and MUSB do not discover devices without CONFIG_PM

[Alan Stern]

On Tue, 28 Nov 2017, Ladislav Michl wrote:

> On Tue, Nov 28, 2017 at 01:09:45PM -0500, Alan Stern wrote:
> > 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

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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: EHCI and MUSB do not discover devices without CONFIG_PM

[Ladislav Michl]

On Tue, Nov 28, 2017 at 02:59:32PM -0500, Alan Stern wrote:
> On Tue, 28 Nov 2017, Ladislav Michl wrote:
> 
> > On Tue, Nov 28, 2017 at 01:09:45PM -0500, Alan Stern wrote:
> > > 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
> 
> 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.

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

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