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.
ladis
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
