Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <de67c95a-d003-c4ef-64a4-c3565ce02b7a@linaro.org>
Date:   Wed, 7 Dec 2022 22:04:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.5.0
Subject: Re: [PATCH v4 02/13] drm/msm/dpu: Introduce SC8280XP
Content-Language: en-GB
To:     Bjorn Andersson <andersson@kernel.org>
Cc:     Bjorn Andersson <quic_bjorande@quicinc.com>,
        Rob Clark <robdclark@gmail.com>,
        Abhinav Kumar <quic_abhinavk@quicinc.com>,
        Sean Paul <sean@poorly.run>, David Airlie <airlied@gmail.com>,
        Daniel Vetter <daniel@ffwll.ch>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Konrad Dybcio <konrad.dybcio@linaro.org>,
        Kalyan Thota <quic_kalyant@quicinc.com>,
        Jessica Zhang <quic_jesszhan@quicinc.com>,
        Kuogee Hsieh <quic_khsieh@quicinc.com>,
        Johan Hovold <johan+linaro@kernel.org>,
        Sankeerth Billakanti <quic_sbillaka@quicinc.com>,
        linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org,
        freedreno@lists.freedesktop.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <20221205174433.16847-1-quic_bjorande@quicinc.com>
 <20221205174433.16847-3-quic_bjorande@quicinc.com>
 <0430d878-e0cd-3708-91a3-2eca66418386@linaro.org>
 <20221207162824.kyxecdz43v5ojatx@builder.lan>
From:   Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
In-Reply-To: <20221207162824.kyxecdz43v5ojatx@builder.lan>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 07/12/2022 18:28, Bjorn Andersson wrote:
> On Wed, Dec 07, 2022 at 04:49:07PM +0200, Dmitry Baryshkov wrote:
>> On 05/12/2022 19:44, Bjorn Andersson wrote:
>>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> [..]
>>> +static const struct dpu_mdp_cfg sc8280xp_mdp[] = {
>>> +	{
>>> +	.name = "top_0", .id = MDP_TOP,
>>> +	.base = 0x0, .len = 0x494,
>>> +	.features = 0,
>>> +	.highest_bank_bit = 0x3, /* TODO: 2 for LP_DDR4 */
>>
>> ubwc_swizzle ? I'd suppose it's 6, but I'd bet on it.
>>
> 
> I don't see ubwc_swizzle defined for any other platform, and it seems to
> be unused for DPU_HW_UBWC_VER_40. Am I perhaps missing something?

Yes, it doesn't seem to be used for VER_40, just wanted to have it for 
the sake of completeness. See 
https://lore.kernel.org/linux-arm-msm/20221207142833.204193-4-dmitry.baryshkov@linaro.org/T/#u

> 
>>> +	.clk_ctrls[DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0},
>>> +	.clk_ctrls[DPU_CLK_CTRL_VIG1] = { .reg_off = 0x2b4, .bit_off = 0},
>>> +	.clk_ctrls[DPU_CLK_CTRL_VIG2] = { .reg_off = 0x2bc, .bit_off = 0},
>>> +	.clk_ctrls[DPU_CLK_CTRL_VIG3] = { .reg_off = 0x2c4, .bit_off = 0},
>>> +	.clk_ctrls[DPU_CLK_CTRL_DMA0] = { .reg_off = 0x2ac, .bit_off = 8},
>>> +	.clk_ctrls[DPU_CLK_CTRL_DMA1] = { .reg_off = 0x2b4, .bit_off = 8},
>>> +	.clk_ctrls[DPU_CLK_CTRL_CURSOR0] = { .reg_off = 0x2bc, .bit_off = 8},
>>> +	.clk_ctrls[DPU_CLK_CTRL_CURSOR1] = { .reg_off = 0x2c4, .bit_off = 8},
>>> +	.clk_ctrls[DPU_CLK_CTRL_REG_DMA] = { .reg_off = 0x2bc, .bit_off = 20},
>>> +	},
>>> +};
>>> +
>>>    static const struct dpu_mdp_cfg qcm2290_mdp[] = {
>>>    	{
>>>    	.name = "top_0", .id = MDP_TOP,
>>> @@ -648,6 +693,45 @@ static const struct dpu_ctl_cfg sc7180_ctl[] = {
>>>    	},
>>>    };
>>> +static const struct dpu_ctl_cfg sc8280xp_ctl[] = {
>>> +	{
>>> +	.name = "ctl_0", .id = CTL_0,
>>> +	.base = 0x15000, .len = 0x204,
>>> +	.features = BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_FETCH_ACTIVE) | BIT(DPU_CTL_VM_CFG),
>>
>> Please use CTL_SC7270_MASK instead, unless you have a strong reasong not to
>> do it.
>>
> 
> No strong reason, will update.

Thanks. The logic for me is to be able to update a single mask when new 
features are added instead of going all over the code.

E.g. I think sc8280xp will benefit from hierarchical DSPP support, will 
it not?

> 
> Thanks,
> Bjorn

-- 
With best wishes
Dmitry