[PATCH v6, 02/14] drm/mediatek: move dsi/dpi select input into mtk_ddp_sel_in

Yongqiang Niu yongqiang.niu at mediatek.com
Wed Jan 1 23:00:04 PST 2020


On Thu, 2020-01-02 at 14:40 +0800, CK Hu wrote:
> Hi, Yongqiang:
> 
> On Thu, 2020-01-02 at 14:21 +0800, Yongqiang Niu wrote:
> > On Thu, 2020-01-02 at 14:02 +0800, CK Hu wrote:
> > > Hi, Yongqiang:
> > > 
> > > On Thu, 2020-01-02 at 13:39 +0800, Yongqiang Niu wrote:
> > > > On Thu, 2020-01-02 at 13:03 +0800, CK Hu wrote:
> > > > > Hi, Yongqiang:
> > > > > 
> > > > > On Thu, 2020-01-02 at 12:00 +0800, Yongqiang Niu wrote:
> > > > > > move dsi/dpi select input into mtk_ddp_sel_in
> > > > > > 
> > > > > > Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
> > > > > > ---
> > > > > >  drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 10 ++++++----
> > > > > >  1 file changed, 6 insertions(+), 4 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > > > > index 39700b9..91c9b19 100644
> > > > > > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > > > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > > > > @@ -376,6 +376,12 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
> > > > > >  	} else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0) {
> > > > > >  		*addr = DISP_REG_CONFIG_DSI_SEL;
> > > > > >  		value = DSI_SEL_IN_BLS;
> > > > > > +	} else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI0) {
> > > > > > +		*addr = DISP_REG_CONFIG_DSI_SEL;
> > > > > > +		value = DSI_SEL_IN_RDMA;
> > > > > 
> > > > > In original code, this is set when cur == DDP_COMPONENT_BLS and next ==
> > > > > DDP_COMPONENT_DPI0. Why do you change the condition?
> > > > > 
> > > > > Regards,
> > > > > CK
> > > > 
> > > > if bls connect with dpi0, rdma1 should connect with dsi0, the condition
> > > > is same with before.
> > > 
> > > You suggest that two crtcs are both enabled. If only one crtc is
> > > enabled, just one of these two would be set.
> > > 
> > > Regards,
> > > CK
> > 
> > OK, i will modify like this
> > else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DPI0) {
> > 		*addr = DISP_REG_CONFIG_DSI_SEL;
> > 		value = DPI_SEL_IN_RDMA;
> > 	}
> > in mtk_ddp_sel_in.
> > 
> > don't set DISP_REG_CONFIG_DPI_SEL to DPI_SEL_IN_BLS anymore, because
> > DPI_SEL_IN_BLS is zero, it is same with hardware default setting.
> 
> In Bibby's case, there is only the path from BLS to DPI0 and has no path
> from RDMA1 to DSI0, but it need to set these two register. Maybe its
> setting is just for some SoC, so you may use the compatible name to
> judge how to set this two register.
> 
> Regards,
> CK
> 

it the original use case, if bls->dpi0, it set 3 register,
DISP_REG_CONFIG_DPI_SEL set to DPI_SEL_IN_BLS ,and this is 
0, so this is useless setting.

then are only 2 useful setting.
in this patch i have upload, i keep DISP_REG_CONFIG_OUT_SEL
still in mtk_ddp_sout_sel.
and only move DISP_REG_CONFIG_DSI_SEL into mtk_ddp_sel_in.
i suppose this is enough for this use case.
and no need compatible name to control this.
please double confirm.

and there will more and more SOC upstream in the future.
these function will be more complex.
there should be coding one more suitable function to 
handle these connection

> > > 
> > > > > 
> > > > > > +	} else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DPI0) {
> > > > > > +		*addr = DISP_REG_CONFIG_DPI_SEL;
> > > > > > +		value = DPI_SEL_IN_BLS;
> > > > > >  	} else {
> > > > > >  		value = 0;
> > > > > >  	}
> > > > > > @@ -393,10 +399,6 @@ static void mtk_ddp_sout_sel(struct regmap *config_regs,
> > > > > >  	} else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DPI0) {
> > > > > >  		regmap_write(config_regs, DISP_REG_CONFIG_OUT_SEL,
> > > > > >  				BLS_TO_DPI_RDMA1_TO_DSI);
> > > > > > -		regmap_write(config_regs, DISP_REG_CONFIG_DSI_SEL,
> > > > > > -				DSI_SEL_IN_RDMA);
> > > > > > -		regmap_write(config_regs, DISP_REG_CONFIG_DPI_SEL,
> > > > > > -				DPI_SEL_IN_BLS);
> > > > > >  	}
> > > > > >  }
> > > > > >  
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > 
> > > 
> > 
> > 
> 
> 



More information about the linux-arm-kernel mailing list