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>
Showing
Please register or sign in to comment