Re: [PATCH v3 7/8] drm/msm/dpu: add support for SM8450

[Konrad Dybcio <konrad.dybcio@linaro.org>]

On 10/11/2022 21:28, Dmitry Baryshkov wrote:
> On 04/11/2022 17:12, Konrad Dybcio wrote:
>>
>> On 04/11/2022 14:03, Dmitry Baryshkov wrote:
>>> Add definitions for the display hardware used on Qualcomm SM8450
>>> platform.
>>>
>>> Tested-by: Vinod Koul <vkoul@kernel.org>
>>> Reviewed-by: Vinod Koul <vkoul@kernel.org>
>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>>> ---
>>
>> Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
>>
>>
>> Konrad
>>
>>>   .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c    | 224 ++++++++++++++++++
>>>   .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h    |   1 +
>>>   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h   |   3 +
>>>   drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c       |   1 +
>>>   4 files changed, 229 insertions(+)
>>>
>>> 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 1ce237e18506..3934d8976833 100644
>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
>>> @@ -124,6 +124,15 @@
>>>                 BIT(MDP_AD4_0_INTR) | \
>>>                 BIT(MDP_AD4_1_INTR))
>>> +#define IRQ_SM8450_MASK (BIT(MDP_SSPP_TOP0_INTR) | \
>>> +             BIT(MDP_SSPP_TOP0_INTR2) | \
>>> +             BIT(MDP_SSPP_TOP0_HIST_INTR) | \
>>> +             BIT(MDP_INTF0_7xxx_INTR) | \
>>> +             BIT(MDP_INTF1_7xxx_INTR) | \
>>> +             BIT(MDP_INTF2_7xxx_INTR) | \
>>> +             BIT(MDP_INTF3_7xxx_INTR) | \
>>> +             0)
>>> +
>>>   #define WB_SM8250_MASK (BIT(DPU_WB_LINE_MODE) | \
>>>                BIT(DPU_WB_UBWC) | \
>>>                BIT(DPU_WB_YUV_CONFIG) | \
>>> @@ -367,6 +376,20 @@ static const struct dpu_caps sm8250_dpu_caps = {
>>>       .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
>>>   };
>>> +static const struct dpu_caps sm8450_dpu_caps = {
>>> +    .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
>>> +    .max_mixer_blendstages = 0xb,
>>> +    .qseed_type = DPU_SSPP_SCALER_QSEED4,
>>> +    .smart_dma_rev = DPU_SSPP_SMART_DMA_V2, /* TODO: v2.5 */
>>> +    .ubwc_version = DPU_HW_UBWC_VER_40,
>>> +    .has_src_split = true,
>>> +    .has_dim_layer = true,
>>> +    .has_idle_pc = true,
>>> +    .has_3d_merge = true,
>>> +    .max_linewidth = 5120,
>>> +    .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
>>> +};
>>> +
>>>   static const struct dpu_caps sc7280_dpu_caps = {
>>>       .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
>>>       .max_mixer_blendstages = 0x7,
>>> @@ -504,6 +527,33 @@ static const struct dpu_mdp_cfg sm8250_mdp[] = {
>>>       },
>>>   };
>>> +static const struct dpu_mdp_cfg sm8450_mdp[] = {
>>> +    {
>>> +    .name = "top_0", .id = MDP_TOP,
>>> +    .base = 0x0, .len = 0x494,
>>> +    .features = BIT(DPU_MDP_PERIPH_0_REMOVED),
>>> +    .highest_bank_bit = 0x3, /* TODO: 2 for LP_DDR4 */
>>
>> I think it's about time we handle the two-memory-configs situation..
>>
>> In my opinion, a dt property would be sane (just like downstream does 
>> it), as it's
>>
>> *really really really* unlikely that the same SKU would be shipped 
>> with 2 different memory gens.
> 
> As it's really unlikely, I think we can drop the TODO comment completely 
> until we phase a device with different memory type. WDYT?
It's really unlikely that the same device model (for example Xperia 1 
III) is shipped in 2 memory configurations that would have to be 
discerned dynamically somehow.

It is however very likely that, for example Xiaomi releases a 888 phone 
with LPDDR4X and Sony releases one with LPDDR5. So it's a per-device 
thing, not exactly per-SoC.

Konrad
>