Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

Sascha Hauer
2022-04-06T14:54:26Z

On Wed, Apr 06, 2022 at 04:36:42PM +0800, Andy Yan wrote:
> Hi:
>
> On 4/6/22 16:13, Sascha Hauer wrote:
> > On Wed, Apr 06, 2022 at 10:02:59AM +0800, Andy Yan wrote:
> > > Hi:
> > >
> > > On 4/5/22 17:37, Sascha Hauer wrote:
> > > > On Sat, Apr 02, 2022 at 09:37:17AM +0800, Andy Yan wrote:
> > > > > Hi Sacha:
> > > > >
> > > > > On 4/1/22 20:52, Sascha Hauer wrote:
> > > > > > --
> > > > > > >From cbc03073623a7180243331ac24c3afaf9dec7522 Mon Sep 17 00:00:00 2001
> > > > > > From: Sascha Hauer<s.hauer@pengutronix.de>
> > > > > > Date: Fri, 1 Apr 2022 14:48:49 +0200
> > > > > > Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver
> > > > > >
> > > > > > ---
> > > > > > drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 14 ++++++++++++++
> > > > > > 1 file changed, 14 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > > > > > index 7dba7b9b63dc6..1421bf2f133f1 100644
> > > > > > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > > > > > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > > > > > @@ -2287,6 +2287,20 @@ static int vop2_create_crtc(struct vop2 *vop2)
> > > > > > }
> > > > > > }
> > > > > > + if (vop2->data->soc_id == 3566) {
> > > > > > + /*
> > > > > > + * On RK3566 these windows don't have an independent
> > > > > > + * framebuffer. They share the framebuffer with smart0,
> > > > > > + * esmart0 and cluster0 respectively.
> > > > > > + */
> > > > > > + switch (win->data->phys_id) {
> > > > > > + case ROCKCHIP_VOP2_SMART1:
> > > > > > + case ROCKCHIP_VOP2_ESMART1:
> > > > > > + case ROCKCHIP_VOP2_CLUSTER1:
> > > > > > + continue;
> > > > > > + }
> > > > > Think about this , there maybe other upcoming vop2 base soc, they may only
> > > > > have
> > > > >
> > > > > mirror window Smart1 Esmart1, or Smart1, Esmart1, Esmart2, Cluster1.
> > > > >
> > > > > I think this should add WIN_FEATURE at the platform description file
> > > > > rockchip_vop2_reg.c, then
> > > > >
> > > > > check the FEATURE to decide whether the driver should give this window a
> > > > > special treatment.
> > > > >
> > > > > this can make one code run for different soc with different platform
> > > > > description. or we should add
> > > > >
> > > > > the same code logic for different soc again and again.
> > > > You mean like done in the downstream Kernel? Here indeed we have a
> > > > WIN_FEATURE_MIRROR flag added to the platform description. This is then
> > > > evaluated with:
> > > >
> > > > static bool vop2_is_mirror_win(struct vop2_win *win)
> > > > {
> > > > return soc_is_rk3566() && (win->feature & WIN_FEATURE_MIRROR);
> > > > }
> > > >
> > > > So a flag is added and afterwards its evaluation is SoC specific. That
> > > > doesn't help at all and only obfuscates things.
> > > >
> > > > Besides, experience shows that you can't predict a good abstraction for
> > > This is not a  predict,  this is an IP feature, so it will appeared on
> > > upcoming SOC.
> > >
> > > We have rk3588 with 8 windows(4 Cluster + 4 Esmart, no Smart window), and
> > >
> > > also have a entry level soc which only have 4 windows, they both have this
> > > feature.
> > Same as with the other discussion: Please let's solve this once we are
> > there.
>
>
> I am not sure if this is the suitable way for upstream, this sound like
>
> just solve the issue appeared at the front of eyes and not think any
>
> thing about make this driver easy to support new hardware in the future.

Oh come on, we are not talking about any major design decisions here,
this is merely a small implementation detail that can be refactored
anytime.

I would change it when all it takes is to add a feature (or better:
nonfeature) flag to the window data, but the combination of the flag
*and* testing on which SoC the flag shall be honoured makes me feel
that the feature flag is still not the best abstraction.

Sascha

--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |