Hi Heiko,
On 1/4/24 17:58, Heiko Stübner wrote:
> Hi Christian, Andy,
>
> Am Donnerstag, 4. Januar 2024, 15:39:50 CET schrieb Cristian Ciocaltea:
>> Commit 5a028e8f062f ("drm/rockchip: vop2: Add support for rk3588")
>> introduced a variable which ended up being unused. Remove it.
>>
>> rockchip_drm_vop2.c:1688:23: warning: variable ‘if_dclk_rate’ set but not used [-Wunused-but-set-variable]
>>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@xxxxxxxxxxxxx>
>
> in general, please don't send non-series patches as replies to other patches.
> It confuses tooling like b4 way too often, as this patch is not designated
> as a 2/2 (similar to the first one not being 1/2).
That was unintentional, sorry! I wrongly assumed 'git send-email' is
able to correctly handle multiple patches which are not part of a
series. I'm not sure if the '--no-thread' flag would have helped.
>> ---
>> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
>> index 44508c2dd614..923985d4161b 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
>> @@ -1685,7 +1685,6 @@ static unsigned long rk3588_calc_cru_cfg(struct vop2_video_port *vp, int id,
>> unsigned long dclk_core_rate = v_pixclk >> 2;
>> unsigned long dclk_rate = v_pixclk;
>> unsigned long dclk_out_rate;
>> - unsigned long if_dclk_rate;
>> unsigned long if_pixclk_rate;
>> int K = 1;
>>
>> @@ -1700,7 +1699,6 @@ static unsigned long rk3588_calc_cru_cfg(struct vop2_video_port *vp, int id,
>> }
>>
>> if_pixclk_rate = (dclk_core_rate << 1) / K;
>> - if_dclk_rate = dclk_core_rate / K;
>> /*
>> * *if_pixclk_div = dclk_rate / if_pixclk_rate;
>> * *if_dclk_div = dclk_rate / if_dclk_rate;
>> */
> *if_pixclk_div = 2;
> *if_dclk_div = 4;
>
> with the code continuing with those static constants but the comment
> showing a forumula, I do hope Andy can provide a bit of insight into
> what is happening here.
>
> I.e. I'd really like to understand if that really is just a remnant or
> something different is needed.
The current implementation is not able to handle all display modes
supported by connected displays, e.g. in my testing environment I
encountered issues with 2560x1440-75.00Hz, 2048x1152-60.00Hz,
1024x768-60.00Hz. Additionally, it doesn't seem to cope well with
non-integer refresh rates like 59.94, 29.97, 23.98, etc.
My temporary workaround relies on using the HDMI PHY PLL in conjunction
with a downstream-based hack to compute the clock rates. I'm not sure
that would be an upstreamable solution, so I would let Andy shed some
light on the topic.
Thanks,
Cristian
>
> Heiko
>
>
