media: rc: gpio-ir-recv: add QoS support for cpuidle system
authorJoakim Zhang <qiangqing.zhang@nxp.com>
Tue, 22 Sep 2020 19:08:07 +0000 (21:08 +0200)
committerMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Sun, 27 Sep 2020 09:27:23 +0000 (11:27 +0200)
commitff1c9223b7b8cb3a7e6d06a1997e91a0368bbd02
treee479f85ba574d9ce7a9e5f27e4adc6f97f25742a
parent2d4ffef1de00c883649b934bcc20109e28d2c9b4
media: rc: gpio-ir-recv: add QoS support for cpuidle system

GPIO IR receive is much rely on interrupt response, uneven interrupt
latency will lead to incorrect timing, so the decoder fails to decode
it. The issue is particularly acute on some systems which support
cpuidle, not all, dynamically disable and enable cpuidle can solve this
problem to a great extent.

However, there is a downside to this approach, the measurement of header
on the first frame may incorrect. Test on i.MX8M serials, when enable
cpuidle, interrupt latency could be about 500us.

With this patch:
1. has no side effect on non-cpuidle system, even runtime pm api won't
be invoked to avoid a bunch of pm busy work for devices that do not need
it, including spinlocks, ktime, etc.
2. latency is still much longer for the first gpio interrupt on cpuidle
system, so the first frame may not be decoded. Generally, RC would transmit
multiple frames at once press, we can sacrifice the first frame.
3. add "linux,autosuspend-period" property in device tree if you also
suffer this cpuidle issue.

Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
drivers/media/rc/gpio-ir-recv.c