[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3fb3359e-fc19-1ffd-47d1-e79744981bcd@linaro.org>
Date: Mon, 2 Jan 2023 11:19:44 +0100
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Marijn Suijten <marijn.suijten@...ainline.org>
Cc: phone-devel@...r.kernel.org,
Abhinav Kumar <quic_abhinavk@...cinc.com>,
Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Neil Armstrong <neil.armstrong@...aro.org>,
~postmarketos/upstreaming@...ts.sr.ht,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@...ainline.org>,
Martin Botka <martin.botka@...ainline.org>,
Jami Kettunen <jami.kettunen@...ainline.org>,
Rob Clark <robdclark@...il.com>, Sean Paul <sean@...rly.run>,
David Airlie <airlied@...il.com>,
Daniel Vetter <daniel@...ll.ch>,
Stephen Boyd <swboyd@...omium.org>,
Vinod Koul <vkoul@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Kuogee Hsieh <quic_khsieh@...cinc.com>,
Jessica Zhang <quic_jesszhan@...cinc.com>,
Konrad Dybcio <konrad.dybcio@...ainline.org>,
Loic Poulain <loic.poulain@...aro.org>,
Vinod Polimera <quic_vpolimer@...cinc.com>,
Adam Skladowski <a39.skl@...il.com>,
linux-arm-msm@...r.kernel.org, dri-devel@...ts.freedesktop.org,
freedreno@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
Kalyan Thota <quic_kalyant@...cinc.com>
Subject: Re: [RFC PATCH 3/7] drm/msm/dpu: Disable MDP vsync source selection
on DPU 5.0.0 and above
On 2.01.2023 11:18, Marijn Suijten wrote:
> On 2023-01-02 10:30:58, Konrad Dybcio wrote:
>>
>>
>> On 31.12.2022 22:52, Marijn Suijten wrote:
>>> On 2022-12-31 22:50:02, Marijn Suijten wrote:
>>>> Since hardware revision 5.0.0 the TE configuration moved out of the
>>>> PINGPONG block into the INTF block, including vsync source selection
>>>> that was previously part of MDP top. Writing to the MDP_VSYNC_SEL
>>>> register has no effect anymore and is omitted downstream via the
>>>> DPU/SDE_MDP_VSYNC_SEL feature flag. This flag is only added to INTF
>>>> blocks used by hardware prior to 5.0.0.
>>>>
>>>> The code that writes to these registers in the INTF block will follow in
>>>> subsequent patches.
>>>>
>>>> Signed-off-by: Marijn Suijten <marijn.suijten@...ainline.org>
>>>> ---
>>>> .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 33 ++++++++++--
>>>> .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 1 +
>>>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c | 52 +++++++++++++------
>>>> 3 files changed, 66 insertions(+), 20 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
>>>> index 39d4b293710c..1cfe94494135 100644
>>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
>>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
>>>> @@ -407,7 +407,7 @@ static const struct dpu_mdp_cfg msm8998_mdp[] = {
>>>> {
>>>> .name = "top_0", .id = MDP_TOP,
>>>> .base = 0x0, .len = 0x458,
>>>> - .features = 0,
>>>> + .features = BIT(DPU_MDP_VSYNC_SEL),
>>>> .highest_bank_bit = 0x2,
>>>> .clk_ctrls[DPU_CLK_CTRL_VIG0] = {
>>>> .reg_off = 0x2AC, .bit_off = 0},
>>>> @@ -436,7 +436,7 @@ static const struct dpu_mdp_cfg sdm845_mdp[] = {
>>>> {
>>>> .name = "top_0", .id = MDP_TOP,
>>>> .base = 0x0, .len = 0x45C,
>>>> - .features = BIT(DPU_MDP_AUDIO_SELECT),
>>>> + .features = BIT(DPU_MDP_AUDIO_SELECT) | BIT(DPU_MDP_VSYNC_SEL),
>>>> .highest_bank_bit = 0x2,
>>>> .clk_ctrls[DPU_CLK_CTRL_VIG0] = {
>>>> .reg_off = 0x2AC, .bit_off = 0},
>>>> @@ -512,6 +512,31 @@ static const struct dpu_mdp_cfg sm6115_mdp[] = {
>>>> },
>>>> };
>>>>
>>>> +static const struct dpu_mdp_cfg sdm8150_mdp[] = {
>>>
>>> Sometimes it is only possible to spot such things _after_ sending,
>>> probably the thing that makes us human :)
>>>
>>> sm8150_mdp*, not sdm.
>>>
>>> - Marijn
>>>
>>>> + {
>>>> + .name = "top_0", .id = MDP_TOP,
>>>> + .base = 0x0, .len = 0x45C,
>>>> + .features = BIT(DPU_MDP_AUDIO_SELECT),
>>>> + .highest_bank_bit = 0x2,
>>>> + .clk_ctrls[DPU_CLK_CTRL_VIG0] = {
>>>> + .reg_off = 0x2AC, .bit_off = 0},
>> Keeping the hex values lowercase would be nice.
>
> Ack, this was copied verbatim from sdm845_mdp but will cleanup as we go.
> Looks like this file has a mixed approach towards lower and uppercase,
> when does the normalization patch land?
Rob was against changing everything in one commit, as that would mess
with git blame, so we settled on preventing adding new uppercase hex
for now (outside of #defines ofc).
Konrad
>
> - Marijn
Powered by blists - more mailing lists