Re: [PATCH v2 07/13] drm/msm/dpu: Add SM6350 support

[Marijn Suijten]

On 2023-05-05 15:11:44, Dmitry Baryshkov wrote:
> On 27/04/2023 18:37, Marijn Suijten wrote:
> > On 2023-04-21 00:31:16, Konrad Dybcio wrote:
> >> Add SM6350 support to the DPU1 driver to enable display output.
> >>
> >> Signed-off-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxx>
> >> Signed-off-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxx>
> > 
> > After addressing the comments from Dmitry (CURSOR0->DMA1 and
> > CURSOR1->DMA2), this is:
> > 
> > Reviewed-by: Marijn Suijten <marijn.suijten@xxxxxxxxxxxxxx>
> > 
> > See below for some nits.
> 
> [...]
> 
> >> +static const struct dpu_mdp_cfg sm6350_mdp[] = {
> >> +	{
> >> +	.name = "top_0", .id = MDP_TOP,
> >> +	.base = 0x0, .len = 0x494,
> >> +	.features = 0,
> >> +	.clk_ctrls[DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .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_DMA2] = { .reg_off = 0x2c4, .bit_off = 8 },
> >> +	.clk_ctrls[DPU_CLK_CTRL_REG_DMA] = { .reg_off = 0x2bc, .bit_off = 20 },
> >> +	},
> >> +};
> >> +
> >> +static const struct dpu_ctl_cfg sm6350_ctl[] = {
> >> +	{
> >> +	.name = "ctl_0", .id = CTL_0,
> >> +	.base = 0x1000, .len = 0x1dc,
> >> +	.features = BIT(DPU_CTL_ACTIVE_CFG),
> >> +	.intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 9),
> >> +	},
> >> +	{
> >> +	.name = "ctl_1", .id = CTL_1,
> >> +	.base = 0x1200, .len = 0x1dc,
> >> +	.features = BIT(DPU_CTL_ACTIVE_CFG),
> >> +	.intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 10),
> >> +	},
> >> +	{
> >> +	.name = "ctl_2", .id = CTL_2,
> >> +	.base = 0x1400, .len = 0x1dc,
> >> +	.features = BIT(DPU_CTL_ACTIVE_CFG),
> >> +	.intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 11),
> >> +	},
> >> +	{
> >> +	.name = "ctl_3", .id = CTL_3,
> >> +	.base = 0x1600, .len = 0x1dc,
> >> +	.features = BIT(DPU_CTL_ACTIVE_CFG),
> >> +	.intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 12),
> >> +	},
> >> +};
> >> +
> >> +static const struct dpu_sspp_cfg sm6350_sspp[] = {
> >> +	SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, 0x1f8, VIG_SC7180_MASK,
> >> +		 sc7180_vig_sblk_0, 0,  SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG0),
> >> +	SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000, 0x1f8, DMA_SDM845_MASK,
> >> +		 sdm845_dma_sblk_0, 1, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA0),
> >> +	SSPP_BLK("sspp_9", SSPP_DMA1, 0x26000, 0x1f8, DMA_CURSOR_SDM845_MASK,
> >> +		 sdm845_dma_sblk_1, 5, SSPP_TYPE_DMA, DPU_CLK_CTRL_CURSOR0),
> >> +	SSPP_BLK("sspp_10", SSPP_DMA2, 0x28000, 0x1f8, DMA_CURSOR_SDM845_MASK,
> >> +		 sdm845_dma_sblk_2, 9, SSPP_TYPE_DMA, DPU_CLK_CTRL_CURSOR1),
> >> +};
> >> +
> >> +static const struct dpu_lm_cfg sm6350_lm[] = {
> >> +	LM_BLK("lm_0", LM_0, 0x44000, MIXER_SDM845_MASK,
> >> +		&sc7180_lm_sblk, PINGPONG_0, LM_1, DSPP_0),
> >> +	LM_BLK("lm_1", LM_1, 0x45000, MIXER_SDM845_MASK,
> >> +		&sc7180_lm_sblk, PINGPONG_1, LM_0, 0),
> > 
> > These two entries are indented with two tabs and have one character too
> > many to align with the opening parenthesis on the previous line.  Can we
> > please settle on a single style, as this commit mostly uses tabs+spaces
> > to align with the opening parenthesis?
> > 
> > Dmitry vouched for `cino=(0` (when in unclosed parenthesis, align next
> > line with zero extra characters to the opening parenthesis), but I find
> > double tabs more convenient as it doesn't require reindenting when
> > changing the name of the macro (which happened too often in my INTF TE
> > series).
> 
> I mainly vote for 'cino=(0' for indenting conditions (where double tab 
> is confusing) and for function calls. I do not have a strong opinion 
> about macros expansions. We have been using double-tab there, which is 
> fine with me.

Agreed on both.  `cino=(0` looks nice but double-tab in the catalog has
been easier to work with.

> Another option (which I personally find more appealing, but it doesn't 
> play well with the current guidelines) is to have all macro arguments in 
> a single line. It makes it easier to compare things.

Single line would be superb especially for current array tables.
> 
> And another option would be to expand these macros up to some point. 
> Previous experience with clock and interconnect drivers showed that 
> expanding such multi-arg acros makes it _easier_ to handle the data. 
> Counterintuitive, but true.

Fully agree, as well as inlining some flag constants.

<snip>

- Marijn