On Tue, Jun 07, 2022 at 02:20:51PM -0700, Brian Norris wrote:
Hi,
On Tue, Jun 07, 2022 at 06:59:56PM +0200, Greg Kroah-Hartman wrote:
From: Nicolas Dufresne nicolas.dufresne@collabora.com
[ Upstream commit 9998943f6dfc5d5472bfab2e38527fb6ba5e9da7 ]
While this overclock hack seems to work on some implementations (some ChromeBooks, RockPi4) it also causes instability on other implementations (notably LibreComputer Renegade, but there were more reports in the LibreELEC project, where this has been removed). While performance is indeed affected (tested with GStreamer), 4K playback still works as long as you don't operate in lock step and keep at least 1 frame ahead of time in the decode queue.
After discussion with ChromeOS members, it would seem that their implementation indeed used to synchronously decode each frame, so this hack was simply compensating for their code being less efficient. In my opinion, this hack should not have been included upstream.
Fixes: cd33c830448ba ("media: rkvdec: Add the rkvdec driver") Signed-off-by: Nicolas Dufresne nicolas.dufresne@collabora.com Reviewed-by: Sebastian Fricke sebastian.fricke@collabora.com Reviewed-by: Ezequiel Garcia ezequiel@vanguardiasur.com.ar Signed-off-by: Hans Verkuil hverkuil-cisco@xs4all.nl Signed-off-by: Mauro Carvalho Chehab mchehab@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org
FWIW, I've noticed a problem that is uncovered by this patch, because the default clock rate is not currently acceptable all the time. See my fix here:
https://lore.kernel.org/all/20220607141535.1.Idafe043ffc94756a69426ec68872db... [PATCH] arm64: dts: rockchip: Assign RK3399 VDU clock rate
It might be nice if $subject patch could be delayed until the fix is in too. The 5.19 cycle is only in -rc1, after all.
(The same seems to apply for the 5.{18,15,10}.y series too.)
Thanks, will go drop this from all branches now.
greg k-h