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
