[Intel-gfx] [PATCH v2 03/17] drm: Nuke mode->vrefresh

[Jani Nikula]

On Fri, 03 Apr 2020, abhinavk at codeaurora.org wrote:
> On 2020-04-03 13:39, Ville Syrjala wrote:
>> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
>> index fec1c33b3045..e3d5f011f7bd 100644
>> --- a/drivers/gpu/drm/drm_modes.c
>> +++ b/drivers/gpu/drm/drm_modes.c
>> @@ -759,9 +759,7 @@ int drm_mode_vrefresh(const struct drm_display_mode 
>> *mode)
>>  {
>>  	int refresh = 0;
>> 
>> -	if (mode->vrefresh > 0)
>> -		refresh = mode->vrefresh;
>
> The mode->vrefresh has been replaced with calling this API in all its 
> usages.
> However in this API, the above if statement was returning the vrefresh 
> if it was already
> set. mode->clock is holding the pixel clock . So this will not cause any 
> issues in non-compressed cases.
> In case of compression like DSC, the pixel
> clock will be different based on the compression ratio hence the 
> mode->clock will change but fps will not.
> So we did have usages in our downstream driver where we would use this 
> API and the refresh rate
> returned will be the mode->vrefresh which did not change but after this 
> change for those cases it will end up returning the refresh rate 
> calculated using mode->clock which will result in a different value now.
> So is the recommendation that even in the case of compression 
> mode->clock should always hold
> uncompressed pixel clock value because with this part of the change we 
> will now get a different value when we call this API.

Yes. The mode remains the same regardless of compression, and
compression is just an implementation detail of the transport.

You may need to maintain separate "physical port clock" and "logical
port clock" for DSC, where the latter is a function of the former and
the DSC parameters. And then you can see if your logical port clock
provides enough bandwidth for your mode. But this is up to your driver
and encoder implementation.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center