Hi, Ladislav Michl <ladis@xxxxxxxxxxxxxx> 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:
signature.asc
Description: PGP signature
