lkml.org 
[lkml]   [2023]   [Apr]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] drm/msm/dpu: always program dsc active bits
From


On 4/12/2023 12:24 AM, Marijn Suijten wrote:
> On 2023-04-11 16:45:34, Abhinav Kumar wrote:
> [..]
>>> Does this flush all DSCs programmed in CTL_DSC_FLUSH as set above? That
>>> is currently still in `if (cfg->dsc)` and never overwritten if all DSCs
>>> are disabled, should it be taken out of the `if` to make sure no DSCs
>>> are inadvertently flushed, or otherwise cache the "previous mask" to
>>> make sure we flush exactly the right DSC blocks?
>>>
>>
>> Yes, DSC flush is hierarchical. This is the main DSC flush which will
>> enforce the flush of the DSC's we are trying to flush in the
>> CTL_DSC_FLUSH register.
>
> That's what I was thinking, thanks for confirming.
>
>> So if DSC was active, the CTL_FLUSH will only enforce the flush of the
>> DSC's programmed in CTL_DSC_FLUSH
>>
>> If DSC is not active, we still need to flush that as well (that was the
>> missing bit).
>>
>> No need to cache previous mask. That programming should be accurate in
>> cfg->dsc already.
>
> This kind of implicit dependency warrants a comment at the very least.
>

Sure.

> What happens if a device boots without DSC panel connected? Will
> CTL_DSC_FLUSH be zero and not (unnecessarily, I assume) flush any of the
> DSC blocks? Or could this flush uninitialized state to the block?
>

If we bootup without DSC panel connected, the kernel's cfg->dsc will be
0 and default register value of CTL_DSC_FLUSH will be 0 so it wont flush
any DSC blocks. Sure, as I wrote in the other response, we can move this
to reset_intf_cfg later when the other pieces are fixed. And leave a
FIXME here.

> - Marijn

\
 
 \ /
  Last update: 2023-04-12 19:33    [W:0.085 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site