On Wed, Nov 15, 2017 at 03:32:13PM -0800, Tony Lindgren wrote:
* Ladislav Michl <ladis@xxxxxxxxxxxxxx> [171115 22:30]:
On Thu, Nov 09, 2017 at 02:37:40PM -0800, Tony Lindgren wrote:
* Ladislav Michl <ladis@xxxxxxxxxxxxxx> [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.
