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

[abhinavk at codeaurora.org]

Hi Jani

On 2020-04-06 01:32, Jani Nikula wrote:
> 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.

Thanks for the information. We will make changes to our driver to 
accommodate the changes in the
drm_mode_vrefresh API.

Thanks

Abhinav