| Message ID | 20171115222807.bfptned3323bjdkr@lenoch (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
* Ladislav Michl <ladis@linux-mips.org> [171115 22:30]: > On Thu, Nov 09, 2017 at 02:37:40PM -0800, Tony Lindgren wrote: > > * Ladislav Michl <ladis@linux-mips.org> [171109 22:33]: > > > On Thu, Nov 09, 2017 at 01:57:07PM -0800, Tony Lindgren wrote: > > > > Maybe you can block idle states from your driver with PM QoS? > > > > > > > > Just add some latency requirement. See for example what was done > > > > earlier for omap3 audio in commit 9834ffd1ecc3 ("ASoC: omap-mcbsp: Add PM > > > > QoS support for McBSP to prevent glitches"). > > > > > > > > Not sure if we can do this in a generic way.. But maybe it's doable for > > > > things like PWM drivers. > > > > > > That seems to be rather problematic as I need this for generic driver: > > > drivers/media/rc/gpio-ir-recv.c > > > I need to be able to detect key presses of various remotes, so protocol > > > is unknown in advance. Having such a big jitter leads to false positives > > > when guessing protocol or decoding errors. > > > > > > I was also considering using FIQ handler, but it probably won't help in > > > this case. > > > > Hmm to me it seems that PM QoS would be totally justified for a driver > > like that. > > So, looked at above mentioned commit and tried patch bellow without any > noticeable change. Also PM QoS seems to handle DMA and network latency only. > I need to handle IRQ latency. Any other options? Hmm well did you check what idle states your system hits after doing it? # cat /sys/kernel/debug/pm_debug/count The value needs to be lower than max cpuidle limit for the state you need as you probably figured. Hmm maybe request hardware debounce for the GPIOs you're using? That should block deeper idle states as the optional GPIO clocks will stay enabled. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Nov 15, 2017 at 03:32:13PM -0800, Tony Lindgren wrote: > * Ladislav Michl <ladis@linux-mips.org> [171115 22:30]: > > On Thu, Nov 09, 2017 at 02:37:40PM -0800, Tony Lindgren wrote: > > > * Ladislav Michl <ladis@linux-mips.org> [171109 22:33]: > > > > On Thu, Nov 09, 2017 at 01:57:07PM -0800, Tony Lindgren wrote: > > > > > Maybe you can block idle states from your driver with PM QoS? > > > > > > > > > > Just add some latency requirement. See for example what was done > > > > > earlier for omap3 audio in commit 9834ffd1ecc3 ("ASoC: omap-mcbsp: Add PM > > > > > QoS support for McBSP to prevent glitches"). As a note, since 4.9 I'm getting kernel long flooded with: [10197.328124] omap-mcbsp 49022000.mcbsp: RX Buffer Underflow! [11106.458984] omap-mcbsp 49022000.mcbsp: RX Buffer Underflow! [11114.252593] omap-mcbsp 49022000.mcbsp: RX Buffer Underflow! [11207.431762] omap-mcbsp 49022000.mcbsp: RX Buffer Underflow! [11510.249572] omap-mcbsp 49022000.mcbsp: RX Buffer Underflow! [11734.923339] omap-mcbsp 49022000.mcbsp: RX Buffer Underflow! [12176.473205] omap-mcbsp 49022000.mcbsp: RX Buffer Underflow! [12295.900238] omap-mcbsp 49022000.mcbsp: RX Buffer Underflow! [12382.461242] omap-mcbsp 49022000.mcbsp: RX Buffer Underflow! So perhaps there's some other issue? > > > > > Not sure if we can do this in a generic way.. But maybe it's doable for > > > > > things like PWM drivers. > > > > > > > > That seems to be rather problematic as I need this for generic driver: > > > > drivers/media/rc/gpio-ir-recv.c > > > > I need to be able to detect key presses of various remotes, so protocol > > > > is unknown in advance. Having such a big jitter leads to false positives > > > > when guessing protocol or decoding errors. > > > > > > > > I was also considering using FIQ handler, but it probably won't help in > > > > this case. > > > > > > Hmm to me it seems that PM QoS would be totally justified for a driver > > > like that. > > > > So, looked at above mentioned commit and tried patch bellow without any > > noticeable change. Also PM QoS seems to handle DMA and network latency only. > > I need to handle IRQ latency. Any other options? > > Hmm well did you check what idle states your system hits after doing it? > > # cat /sys/kernel/debug/pm_debug/count usbhost_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 dss_pwrdm (ON),OFF:0,RET:3004,INA:0,ON:3005,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 neon_pwrdm (ON),OFF:0,RET:2997,INA:8,ON:3006,RET-LOGIC-OFF:0 mpu_pwrdm (ON),OFF:0,RET:2996,INA:8,ON:3005,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0 usbhost_clkdm->usbhost_pwrdm (3) sgx_clkdm->sgx_pwrdm (0) per_clkdm->per_pwrdm (18) cam_clkdm->cam_pwrdm (0) dss_clkdm->dss_pwrdm (1) d2d_clkdm->core_pwrdm (0) iva2_clkdm->iva2_pwrdm (0) mpu_clkdm->mpu_pwrdm (0) core_l4_clkdm->core_pwrdm (23) core_l3_clkdm->core_pwrdm (2) neon_clkdm->neon_pwrdm (0) > The value needs to be lower than max cpuidle limit for the state you need > as you probably figured. > > Hmm maybe request hardware debounce for the GPIOs you're using? That should > block deeper idle states as the optional GPIO clocks will stay enabled. Tried this as well, no change. Old 2.6.32-ti behaves better, but board drains about 500mA more :-) I hope to get some more time soon to investigate. ladis -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/16/2017 06:29 AM, Ladislav Michl wrote: > On Wed, Nov 15, 2017 at 03:32:13PM -0800, Tony Lindgren wrote: >> * Ladislav Michl <ladis@linux-mips.org> [171115 22:30]: >>> On Thu, Nov 09, 2017 at 02:37:40PM -0800, Tony Lindgren wrote: >>>> * Ladislav Michl <ladis@linux-mips.org> [171109 22:33]: >>>>> On Thu, Nov 09, 2017 at 01:57:07PM -0800, Tony Lindgren wrote: >>>>>> Maybe you can block idle states from your driver with PM QoS? >>>>>> >>>>>> Just add some latency requirement. See for example what was done >>>>>> earlier for omap3 audio in commit 9834ffd1ecc3 ("ASoC: omap-mcbsp: Add PM >>>>>> QoS support for McBSP to prevent glitches"). > > As a note, since 4.9 I'm getting kernel long flooded with: > [10197.328124] omap-mcbsp 49022000.mcbsp: RX Buffer Underflow! > [11106.458984] omap-mcbsp 49022000.mcbsp: RX Buffer Underflow! > [11114.252593] omap-mcbsp 49022000.mcbsp: RX Buffer Underflow! > [11207.431762] omap-mcbsp 49022000.mcbsp: RX Buffer Underflow! > [11510.249572] omap-mcbsp 49022000.mcbsp: RX Buffer Underflow! > [11734.923339] omap-mcbsp 49022000.mcbsp: RX Buffer Underflow! > [12176.473205] omap-mcbsp 49022000.mcbsp: RX Buffer Underflow! > [12295.900238] omap-mcbsp 49022000.mcbsp: RX Buffer Underflow! > [12382.461242] omap-mcbsp 49022000.mcbsp: RX Buffer Underflow! > > So perhaps there's some other issue? > >>>>>> Not sure if we can do this in a generic way.. But maybe it's doable for >>>>>> things like PWM drivers. >>>>> >>>>> That seems to be rather problematic as I need this for generic driver: >>>>> drivers/media/rc/gpio-ir-recv.c >>>>> I need to be able to detect key presses of various remotes, so protocol >>>>> is unknown in advance. Having such a big jitter leads to false positives >>>>> when guessing protocol or decoding errors. >>>>> >>>>> I was also considering using FIQ handler, but it probably won't help in >>>>> this case. >>>> >>>> Hmm to me it seems that PM QoS would be totally justified for a driver >>>> like that. >>> >>> So, looked at above mentioned commit and tried patch bellow without any >>> noticeable change. Also PM QoS seems to handle DMA and network latency only. >>> I need to handle IRQ latency. Any other options? >> >> Hmm well did you check what idle states your system hits after doing it? >> >> # cat /sys/kernel/debug/pm_debug/count > > usbhost_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 > sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 > core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 > per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 > dss_pwrdm (ON),OFF:0,RET:3004,INA:0,ON:3005,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 > cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 > neon_pwrdm (ON),OFF:0,RET:2997,INA:8,ON:3006,RET-LOGIC-OFF:0 > mpu_pwrdm (ON),OFF:0,RET:2996,INA:8,ON:3005,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 > iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0 > usbhost_clkdm->usbhost_pwrdm (3) > sgx_clkdm->sgx_pwrdm (0) > per_clkdm->per_pwrdm (18) > cam_clkdm->cam_pwrdm (0) > dss_clkdm->dss_pwrdm (1) > d2d_clkdm->core_pwrdm (0) > iva2_clkdm->iva2_pwrdm (0) > mpu_clkdm->mpu_pwrdm (0) > core_l4_clkdm->core_pwrdm (23) > core_l3_clkdm->core_pwrdm (2) > neon_clkdm->neon_pwrdm (0) > >> The value needs to be lower than max cpuidle limit for the state you need >> as you probably figured. >> >> Hmm maybe request hardware debounce for the GPIOs you're using? That should >> block deeper idle states as the optional GPIO clocks will stay enabled. > > Tried this as well, no change. Old 2.6.32-ti behaves better, but board drains > about 500mA more :-) I hope to get some more time soon to investigate. > I recommend to disable CPU idle completely in config and re-check test, before continue with other things.
On Thu, Nov 16, 2017 at 03:04:48PM -0600, Grygorii Strashko wrote: [snip] > I recommend to disable CPU idle completely in config and re-check test, > before continue with other things. Strangely enough latency is much worse with CONFIG_CPU_IDLE disabled. ladis -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Nov 23, 2017 at 10:35:42AM +0100, Ladislav Michl wrote: > On Thu, Nov 16, 2017 at 03:04:48PM -0600, Grygorii Strashko wrote: > [snip] > > I recommend to disable CPU idle completely in config and re-check test, > > before continue with other things. > > Strangely enough latency is much worse with CONFIG_CPU_IDLE disabled. While it is better with: CONFIG_HZ_PERIODIC=y CONFIG_CPU_FREQ=n CONFIG_PM=n But both ehci and musb does not see any device connected and: IRQ: Found an INTC at 0xfa200000 (revision 4.0) with 96 interrupts Clocking rate (Crystal/Core/MPU): 26.0/400/600 MHz ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at arch/arm/mach-omap2/omap_hwmod.c:2098 _enable+0x48/0x234 omap_hwmod: timer1: enabled state can only be entered from initialized, idle, or disabled state Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 4.14.1-00048-gfa283847c99a #12 Hardware name: Generic OMAP36xx (Flattened Device Tree) [<c010c304>] (unwind_backtrace) from [<c010a708>] (show_stack+0x10/0x14) [<c010a708>] (show_stack) from [<c012395c>] (__warn+0xdc/0xf8) [<c012395c>] (__warn) from [<c01239ac>] (warn_slowpath_fmt+0x34/0x44) [<c01239ac>] (warn_slowpath_fmt) from [<c0117e50>] (_enable+0x48/0x234) [<c0117e50>] (_enable) from [<c01184e0>] (omap_hwmod_enable+0x18/0x28) [<c01184e0>] (omap_hwmod_enable) from [<c07083a8>] (omap_dm_timer_init_one+0x150/0x248) [<c07083a8>] (omap_dm_timer_init_one) from [<c0708550>] (__omap_sync32k_timer_init.constprop.1+0x74/0x234) [<c0708550>] (__omap_sync32k_timer_init.constprop.1) from [<c0708734>] (omap_init_time+0x24/0x38) [<c0708734>] (omap_init_time) from [<c0700abc>] (start_kernel+0x208/0x378) [<c0700abc>] (start_kernel) from [<80008078>] (0x80008078) ---[ end trace 6bf4eb748e85f1ee ]--- OMAP clockevent source: timer1 at 32768 Hz ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at arch/arm/mach-omap2/omap_hwmod.c:2098 _enable+0x48/0x234 omap_hwmod: counter_32k: enabled state can only be entered from initialized, idle, or disabled state Modules linked in: CPU: 0 PID: 0 Comm: swapper Tainted: G W 4.14.1-00048-gfa283847c99a #12 Hardware name: Generic OMAP36xx (Flattened Device Tree) [<c010c304>] (unwind_backtrace) from [<c010a708>] (show_stack+0x10/0x14) [<c010a708>] (show_stack) from [<c012395c>] (__warn+0xdc/0xf8) [<c012395c>] (__warn) from [<c01239ac>] (warn_slowpath_fmt+0x34/0x44) [<c01239ac>] (warn_slowpath_fmt) from [<c0117e50>] (_enable+0x48/0x234) [<c0117e50>] (_enable) from [<c01184e0>] (omap_hwmod_enable+0x18/0x28) [<c01184e0>] (omap_hwmod_enable) from [<c07086bc>] (__omap_sync32k_timer_init.constprop.1+0x1e0/0x234) [<c07086bc>] (__omap_sync32k_timer_init.constprop.1) from [<c0708734>] (omap_init_time+0x24/0x38) [<c0708734>] (omap_init_time) from [<c0700abc>] (start_kernel+0x208/0x378) [<c0700abc>] (start_kernel) from [<80008078>] (0x80008078) ---[ end trace 6bf4eb748e85f1ef ]--- omap2_sync32k_clocksource_init: failed to enable counter_32k module (-22) Is it expected? ladis -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Nov 23, 2017 at 11:26:04AM +0100, Ladislav Michl wrote: > On Thu, Nov 23, 2017 at 10:35:42AM +0100, Ladislav Michl wrote: > > On Thu, Nov 16, 2017 at 03:04:48PM -0600, Grygorii Strashko wrote: > > [snip] > > > I recommend to disable CPU idle completely in config and re-check test, > > > before continue with other things. > > > > Strangely enough latency is much worse with CONFIG_CPU_IDLE disabled. > > While it is better with: > CONFIG_HZ_PERIODIC=y > CONFIG_CPU_FREQ=n > CONFIG_PM=n > > But both ehci and musb does not see any device connected and: [snip] The culprit here is CONFIG_PM. With CONFIG_PM disabled latency jitter is about 30us, which is pretty good for general purpose OS. But some drivers do not work without CONFIG_PM. Suggestions? Thank you, ladis -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Nov 23, 2017 at 11:26:04AM +0100, Ladislav Michl wrote: > On Thu, Nov 23, 2017 at 10:35:42AM +0100, Ladislav Michl wrote: > > On Thu, Nov 16, 2017 at 03:04:48PM -0600, Grygorii Strashko wrote: > > [snip] > > > I recommend to disable CPU idle completely in config and re-check test, > > > before continue with other things. > > > > Strangely enough latency is much worse with CONFIG_CPU_IDLE disabled. > > While it is better with: > CONFIG_HZ_PERIODIC=y > CONFIG_CPU_FREQ=n > CONFIG_PM=n > > But both ehci and musb does not see any device connected and: > > IRQ: Found an INTC at 0xfa200000 (revision 4.0) with 96 interrupts > Clocking rate (Crystal/Core/MPU): 26.0/400/600 MHz > ------------[ cut here ]------------ > WARNING: CPU: 0 PID: 0 at arch/arm/mach-omap2/omap_hwmod.c:2098 _enable+0x48/0x234 > omap_hwmod: timer1: enabled state can only be entered from initialized, idle, or disabled state The state is _HWMOD_STATE_ENABLED here and it cames from: static void __init __maybe_unused omap_hwmod_init_postsetup(void) { u8 postsetup_state; /* Set the default postsetup state for all hwmods */ #ifdef CONFIG_PM postsetup_state = _HWMOD_STATE_IDLE; #else postsetup_state = _HWMOD_STATE_ENABLED; #endif omap_hwmod_for_each(_set_hwmod_postsetup_state, &postsetup_state); omap_pm_if_early_init(); } in arch/arm/mach-omap2/io.c Just in case someone has time to look at this. > Modules linked in: > CPU: 0 PID: 0 Comm: swapper Not tainted 4.14.1-00048-gfa283847c99a #12 > Hardware name: Generic OMAP36xx (Flattened Device Tree) > [<c010c304>] (unwind_backtrace) from [<c010a708>] (show_stack+0x10/0x14) > [<c010a708>] (show_stack) from [<c012395c>] (__warn+0xdc/0xf8) > [<c012395c>] (__warn) from [<c01239ac>] (warn_slowpath_fmt+0x34/0x44) > [<c01239ac>] (warn_slowpath_fmt) from [<c0117e50>] (_enable+0x48/0x234) > [<c0117e50>] (_enable) from [<c01184e0>] (omap_hwmod_enable+0x18/0x28) > [<c01184e0>] (omap_hwmod_enable) from [<c07083a8>] (omap_dm_timer_init_one+0x150/0x248) > [<c07083a8>] (omap_dm_timer_init_one) from [<c0708550>] (__omap_sync32k_timer_init.constprop.1+0x74/0x234) > [<c0708550>] (__omap_sync32k_timer_init.constprop.1) from [<c0708734>] (omap_init_time+0x24/0x38) > [<c0708734>] (omap_init_time) from [<c0700abc>] (start_kernel+0x208/0x378) > [<c0700abc>] (start_kernel) from [<80008078>] (0x80008078) > ---[ end trace 6bf4eb748e85f1ee ]--- > OMAP clockevent source: timer1 at 32768 Hz > ------------[ cut here ]------------ > WARNING: CPU: 0 PID: 0 at arch/arm/mach-omap2/omap_hwmod.c:2098 _enable+0x48/0x234 > omap_hwmod: counter_32k: enabled state can only be entered from initialized, idle, or disabled state > Modules linked in: > CPU: 0 PID: 0 Comm: swapper Tainted: G W 4.14.1-00048-gfa283847c99a #12 > Hardware name: Generic OMAP36xx (Flattened Device Tree) > [<c010c304>] (unwind_backtrace) from [<c010a708>] (show_stack+0x10/0x14) > [<c010a708>] (show_stack) from [<c012395c>] (__warn+0xdc/0xf8) > [<c012395c>] (__warn) from [<c01239ac>] (warn_slowpath_fmt+0x34/0x44) > [<c01239ac>] (warn_slowpath_fmt) from [<c0117e50>] (_enable+0x48/0x234) > [<c0117e50>] (_enable) from [<c01184e0>] (omap_hwmod_enable+0x18/0x28) > [<c01184e0>] (omap_hwmod_enable) from [<c07086bc>] (__omap_sync32k_timer_init.constprop.1+0x1e0/0x234) > [<c07086bc>] (__omap_sync32k_timer_init.constprop.1) from [<c0708734>] (omap_init_time+0x24/0x38) > [<c0708734>] (omap_init_time) from [<c0700abc>] (start_kernel+0x208/0x378) > [<c0700abc>] (start_kernel) from [<80008078>] (0x80008078) > ---[ end trace 6bf4eb748e85f1ef ]--- > omap2_sync32k_clocksource_init: failed to enable counter_32k module (-22) > > Is it expected? > > ladis > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/23/2017 05:06 AM, Ladislav Michl wrote: > On Thu, Nov 23, 2017 at 11:26:04AM +0100, Ladislav Michl wrote: >> On Thu, Nov 23, 2017 at 10:35:42AM +0100, Ladislav Michl wrote: >>> On Thu, Nov 16, 2017 at 03:04:48PM -0600, Grygorii Strashko wrote: >>> [snip] >>>> I recommend to disable CPU idle completely in config and re-check test, >>>> before continue with other things. >>> >>> Strangely enough latency is much worse with CONFIG_CPU_IDLE disabled. >> >> While it is better with: >> CONFIG_HZ_PERIODIC=y >> CONFIG_CPU_FREQ=n >> CONFIG_PM=n >> >> But both ehci and musb does not see any device connected and: > [snip] > > The culprit here is CONFIG_PM. With CONFIG_PM disabled latency jitter is > about 30us, which is pretty good for general purpose OS. But some drivers > do not work without CONFIG_PM. Suggestions? Not sure OMAP ever expected to fully work with CONFIG_PM=n You can try play with HWMOD props, like add flags to gpio hwmods: HWMOD_NO_OCP_AUTOIDLE HWMOD_NO_IDLE HWMOD_CLKDM_NOAUTO
On Tue, Nov 28, 2017 at 12:09:06PM -0600, Grygorii Strashko wrote: > > > On 11/23/2017 05:06 AM, Ladislav Michl wrote: > > On Thu, Nov 23, 2017 at 11:26:04AM +0100, Ladislav Michl wrote: > > > On Thu, Nov 23, 2017 at 10:35:42AM +0100, Ladislav Michl wrote: > > > > On Thu, Nov 16, 2017 at 03:04:48PM -0600, Grygorii Strashko wrote: > > > > [snip] > > > > > I recommend to disable CPU idle completely in config and re-check test, > > > > > before continue with other things. > > > > > > > > Strangely enough latency is much worse with CONFIG_CPU_IDLE disabled. > > > > > > While it is better with: > > > CONFIG_HZ_PERIODIC=y > > > CONFIG_CPU_FREQ=n > > > CONFIG_PM=n > > > > > > But both ehci and musb does not see any device connected and: > > [snip] > > > > The culprit here is CONFIG_PM. With CONFIG_PM disabled latency jitter is > > about 30us, which is pretty good for general purpose OS. But some drivers > > do not work without CONFIG_PM. Suggestions? > > Not sure OMAP ever expected to fully work with CONFIG_PM=n > > You can try play with HWMOD props, like add flags to gpio hwmods: > HWMOD_NO_OCP_AUTOIDLE > HWMOD_NO_IDLE > HWMOD_CLKDM_NOAUTO And that did the trick! Well, almost. 'ti,no-idle' to gpio5 node and Tony's suggestion to allow only C1 cpuidle state gives almost as good jitter as with CONFIG_PM disabled. Just out of curiosity, I'll try with -rt patch. Thank you, ladis -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 28, 2017 at 09:02:52PM +0100, Ladislav Michl wrote: > On Tue, Nov 28, 2017 at 12:09:06PM -0600, Grygorii Strashko wrote: > > > > > > On 11/23/2017 05:06 AM, Ladislav Michl wrote: > > > On Thu, Nov 23, 2017 at 11:26:04AM +0100, Ladislav Michl wrote: > > > > On Thu, Nov 23, 2017 at 10:35:42AM +0100, Ladislav Michl wrote: > > > > > On Thu, Nov 16, 2017 at 03:04:48PM -0600, Grygorii Strashko wrote: > > > > > [snip] > > > > > > I recommend to disable CPU idle completely in config and re-check test, > > > > > > before continue with other things. > > > > > > > > > > Strangely enough latency is much worse with CONFIG_CPU_IDLE disabled. > > > > > > > > While it is better with: > > > > CONFIG_HZ_PERIODIC=y > > > > CONFIG_CPU_FREQ=n > > > > CONFIG_PM=n > > > > > > > > But both ehci and musb does not see any device connected and: > > > [snip] > > > > > > The culprit here is CONFIG_PM. With CONFIG_PM disabled latency jitter is > > > about 30us, which is pretty good for general purpose OS. But some drivers > > > do not work without CONFIG_PM. Suggestions? > > > > Not sure OMAP ever expected to fully work with CONFIG_PM=n > > > > You can try play with HWMOD props, like add flags to gpio hwmods: > > HWMOD_NO_OCP_AUTOIDLE > > HWMOD_NO_IDLE > > HWMOD_CLKDM_NOAUTO > > And that did the trick! Well, almost. 'ti,no-idle' to gpio5 node and Tony's > suggestion to allow only C1 cpuidle state gives almost as good jitter as > with CONFIG_PM disabled. > > Just out of curiosity, I'll try with -rt patch. So after more testing it seems GPIO is a dead end. The jitter is just too big to diferentiate all those IR protocols. Options are to use FIQ, read timestamp from hw timer and queue it using ringbuffer or something similar. Or solder wire on board and connect it to dmtimer capture input. This was tested and seems to get very reasonable results (as one would expect from hw dedicated for that purpose). As later solution will be most likely used, I'd like to thank everyone who helped with suggestions and will have more questions in Keerthy's dmtimer patch series. Best regards, ladis -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Welcome to the next episode of the OMAP interrupt latency saga... On Tue, Nov 28, 2017 at 12:09:06PM -0600, Grygorii Strashko wrote: > On 11/23/2017 05:06 AM, Ladislav Michl wrote: > > On Thu, Nov 23, 2017 at 11:26:04AM +0100, Ladislav Michl wrote: > > > On Thu, Nov 23, 2017 at 10:35:42AM +0100, Ladislav Michl wrote: > > > > On Thu, Nov 16, 2017 at 03:04:48PM -0600, Grygorii Strashko wrote: > > > > [snip] > > > > > I recommend to disable CPU idle completely in config and re-check test, > > > > > before continue with other things. > > > > > > > > Strangely enough latency is much worse with CONFIG_CPU_IDLE disabled. > > > > > > While it is better with: > > > CONFIG_HZ_PERIODIC=y > > > CONFIG_CPU_FREQ=n > > > CONFIG_PM=n > > > > > > But both ehci and musb does not see any device connected and: > > [snip] > > > > The culprit here is CONFIG_PM. With CONFIG_PM disabled latency jitter is > > about 30us, which is pretty good for general purpose OS. But some drivers > > do not work without CONFIG_PM. Suggestions? > > Not sure OMAP ever expected to fully work with CONFIG_PM=n > > You can try play with HWMOD props, like add flags to gpio hwmods: > HWMOD_NO_OCP_AUTOIDLE > HWMOD_NO_IDLE > HWMOD_CLKDM_NOAUTO I have at91sam9g20 board on my table (ARM926EJ-S, yes indeed), so I did similar measurements and got average latency about 15us (with CONFIG_PM, CONFIG_CPU_IDLE enabled). And as OMAP's DM timer event capture is now working, simple test was run: DM timer can capture event on I/O pin, it stores counter value into dedicated register once configured edge is detected and fires interrupt. In that interrupt handler, actual counter value is read and compared to the value stored in dedicated register. Latency found this way is 100~300us, so no matter interrupt source, we are just a bit slow :) For this particular testcase omap3 performs order of magnitude worse than ancient at91sam9g20. I prepared few a bit more sophisticated testcases I'm going to run during next week, so this is just a gentle ping if anyone comes with an idea what else to try to get lower latencies :-) Thank you, ladis -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/media/rc/gpio-ir-recv.c b/drivers/media/rc/gpio-ir-recv.c index b6c4a2d2b696..5c580bf70ff8 100644 --- a/drivers/media/rc/gpio-ir-recv.c +++ b/drivers/media/rc/gpio-ir-recv.c @@ -19,6 +19,7 @@ #include <linux/of.h> #include <linux/of_gpio.h> #include <linux/platform_device.h> +#include <linux/pm_qos.h> #include <linux/irq.h> #include <media/rc-core.h> @@ -92,6 +93,10 @@ static int gpio_ir_recv_probe(struct platform_device *pdev) gpio_dev->rcdev = rcdev; + rc = dev_pm_qos_expose_latency_limit(dev, 10); + if (rc < 0) + return rc; + rc = devm_rc_register_device(dev, rcdev); if (rc < 0) { dev_err(dev, "failed to register rc device (%d)\n", rc);