[Freedreno] [PATCH 1/3] drm/msm/mdp5: Configure PP_SYNC_HEIGHT to double the vtotal
Marijn Suijten
marijn.suijten at somainline.org
Fri Apr 9 08:22:05 UTC 2021
Hi Abhinav, Angelo, Rob,
On 4/9/21 2:08 AM, Rob Clark wrote:
> On Thu, Apr 8, 2021 at 4:16 PM AngeloGioacchino Del Regno
> <angelogioacchino.delregno at somainline.org> wrote:
>>
>>
>> Il gio 8 apr 2021, 21:05 Rob Clark <robdclark at gmail.com> ha scritto:
>>>
>>> On Wed, Apr 7, 2021 at 12:11 PM AngeloGioacchino Del Regno
>>> <angelogioacchino.delregno at somainline.org> wrote:
>>>>
>>>> Il 07/04/21 20:19, abhinavk at codeaurora.org ha scritto:
>>>>> Hi Marijn
>>>>>
>>>>> On 2021-04-06 14:47, Marijn Suijten wrote:
>>>>>> Leaving this at a close-to-maximum register value 0xFFF0 means it takes
>>>>>> very long for the MDSS to generate a software vsync interrupt when the
>>>>>> hardware TE interrupt doesn't arrive. Configuring this to double the
>>>>>> vtotal (like some downstream kernels) leads to a frame to take at most
>>>>>> twice before the vsync signal, until hardware TE comes up.
>>>>>>
>>>>>> In this case the hardware interrupt responsible for providing this
>>>>>> signal - "disp-te" gpio - is not hooked up to the mdp5 vsync/pp logic at
>>>>>> all. This solves severe panel update issues observed on at least the
>>>>>> Xperia Loire and Tone series, until said gpio is properly hooked up to
>>>>>> an irq.
>>>>>
>>>>> The reason the CONFIG_HEIGHT was at such a high value is to make sure that
>>>>> we always get the TE only from the panel vsync and not false positives
>>>>> coming
>>>>> from the tear check logic itself.
Correct, most CAF kernels mention such behaviour in comments, with
fallbacks to vtotal*2 for safety or vtotal when an emulated panel does
not support hardware TE at all. We don't seem to (need to) support the
latter case but one might at some point want to configure the tearcheck
logic to emit a signal for every frame, by means of a DT property or
automatically when disp-te is not defined.
>>>>>
>>>>> When you say that disp-te gpio is not hooked up, is it something
>>>>> incorrect with
>>>>> the schematic OR panel is not generating the TE correctly?
>>>>>
The GPIO is currently not used at all by this kernel driver besides a
call to devm_gpiod_get_optional. As mentioned in the cover letter we
have patches in progress to hook up this interrupt line to the pp_done
infrastructure and complete vsync requests that way instead of waiting
for this "simulated" interrupt from the MDP.
>>> Currently I have this patch in msm-next-staging but I guess we need to
>>> decide in the next day or so whether to drop it or smash in a comment?
>>
>> Marijn, can you please urgently throw a comment in, reminding that these timers are interacting with TE and send a fast V2?
>
> Or just reply on list w/ a comment to smash in, if that is easier
How about a comment along the lines of:
Tearcheck emits a blanking signal every vclks_line * vtotal * 2 ticks on
the vsync_clk equating to roughly half the desired panel refresh rate.
This is only necessary as stability fallback if interrupts from the
panel arrive too late or not at all, but is currently used by default
because these panel interrupts are not wired up yet.
I'd place this comment right above REG_MDP5_PP_SYNC_CONFIG_VSYNC, and
perhaps add a newline after REG_MDP5_PP_SYNC_CONFIG_HEIGHT to make it
clear this applies to those two registers specifically. We can also
involve MDP5_PP_SYNC_CONFIG_VSYNC_COUNT(vclks_line) in the mix.
Then, when the panel TE is wired up we can be smarter about the
situation and print warnings when the user has disp-te hooked up but is
receiving interrupts from the MDSS block instead of the panel directly
(except if incidentally). This likely means that SET_TEAR_ON was not
sent to the panel or the GPIO is wrong. In that sense this patch
(together with x100 removal) is concealing configuration mistakes, but
we might also revert back to 0xfff0 if the GPIO is specified in DT and
accept the timeout+recovery which did not seem to hamper devices on
downstream kernels anyway.
- Marijn
More information about the dri-devel
mailing list