| Message ID | 20220328195936.82552-13-nicolas.dufresne@collabora.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v1,01/24] media: h264: Increase reference lists size to 32 | expand |
Hey Nicolas, On 28.03.2022 15:59, Nicolas Dufresne wrote: >While this overclock hack seems to works on some implementation (some s/implementation/implementations/ >ChromeBooks, RockPi4) it is also causing instability on other s/causing/causes/ >implementation (notably LibreComputer Renegade, but saw more reports in s/implementation/implementations/ s/but saw more reports/but there were more reports/ >the LibreELEC project, were this is already removed). While performance is s/were this is/where this is/ >indeed affectied (tested with GStreamer), 4K playback still works as long s/affectied/affected/ >as you don't operate in lock step and keep at least 1 frame ahead of time s/lock step/lock step mode/ >in the decode queue. > >After discussion with ChromeOS members, it would seem that their >implementation indeed synchronously decode each frames, so this hack was s/decode each frames/decodes each frame/ >simply compensating for their code being less efficienti. This hack s/efficienti/efficient/ >should in my opinion have stayed downstream and I'm removing it to ensure s/This hack should in my opinion have stayed downstream/ In my opinion, this hack should not have been included upstream/ >stability across all RK3399 variants. > >Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by: Sebastian Fricke <sebastian.fricke@collabora.com> Greetings, Sebastian >--- > drivers/staging/media/rkvdec/rkvdec.c | 6 ------ > 1 file changed, 6 deletions(-) > >diff --git a/drivers/staging/media/rkvdec/rkvdec.c b/drivers/staging/media/rkvdec/rkvdec.c >index c0cf3488f970..2df8cf4883e2 100644 >--- a/drivers/staging/media/rkvdec/rkvdec.c >+++ b/drivers/staging/media/rkvdec/rkvdec.c >@@ -1027,12 +1027,6 @@ static int rkvdec_probe(struct platform_device *pdev) > if (ret) > return ret; > >- /* >- * Bump ACLK to max. possible freq. (500 MHz) to improve performance >- * When 4k video playback. >- */ >- clk_set_rate(rkvdec->clocks[0].clk, 500 * 1000 * 1000); >- > rkvdec->regs = devm_platform_ioremap_resource(pdev, 0); > if (IS_ERR(rkvdec->regs)) > return PTR_ERR(rkvdec->regs); >-- >2.34.1 >
diff --git a/drivers/staging/media/rkvdec/rkvdec.c b/drivers/staging/media/rkvdec/rkvdec.c index c0cf3488f970..2df8cf4883e2 100644 --- a/drivers/staging/media/rkvdec/rkvdec.c +++ b/drivers/staging/media/rkvdec/rkvdec.c @@ -1027,12 +1027,6 @@ static int rkvdec_probe(struct platform_device *pdev) if (ret) return ret; - /* - * Bump ACLK to max. possible freq. (500 MHz) to improve performance - * When 4k video playback. - */ - clk_set_rate(rkvdec->clocks[0].clk, 500 * 1000 * 1000); - rkvdec->regs = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(rkvdec->regs)) return PTR_ERR(rkvdec->regs);
While this overclock hack seems to works on some implementation (some ChromeBooks, RockPi4) it is also causing instability on other implementation (notably LibreComputer Renegade, but saw more reports in the LibreELEC project, were this is already removed). While performance is indeed affectied (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 synchronously decode each frames, so this hack was simply compensating for their code being less efficienti. This hack should in my opinion have stayed downstream and I'm removing it to ensure stability across all RK3399 variants. Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> --- drivers/staging/media/rkvdec/rkvdec.c | 6 ------ 1 file changed, 6 deletions(-)