All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Andy Yan <andy.yan@rock-chips.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Benjamin Gaignard <benjamin.gaignard@collabora.com>,
	Piotr Oniszczuk <piotr.oniszczuk@gmail.com>,
	Sandy Huang <hjc@rock-chips.com>,
	dri-devel@lists.freedesktop.org,
	Kever Yang <Kever.yang@rock-chips.com>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	Michael Riesch <michael.riesch@wolfvision.net>,
	kernel@pengutronix.de, Peter Geis <pgwipeout@gmail.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support
Date: Wed, 6 Apr 2022 16:54:21 +0200	[thread overview]
Message-ID: <20220406145421.GW4012@pengutronix.de> (raw)
In-Reply-To: <a5e070ae-d9e1-e5ee-0871-2cdf58958203@rock-chips.com>

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 |

WARNING: multiple messages have this Message-ID (diff)
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Andy Yan <andy.yan@rock-chips.com>
Cc: "Piotr Oniszczuk" <piotr.oniszczuk@gmail.com>,
	dri-devel@lists.freedesktop.org,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	kernel@pengutronix.de,
	"Benjamin Gaignard" <benjamin.gaignard@collabora.com>,
	"Michael Riesch" <michael.riesch@wolfvision.net>,
	"Sandy Huang" <hjc@rock-chips.com>,
	"Heiko Stübner" <heiko@sntech.de>,
	"Peter Geis" <pgwipeout@gmail.com>,
	"Kever Yang" <Kever.yang@rock-chips.com>
Subject: Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support
Date: Wed, 6 Apr 2022 16:54:21 +0200	[thread overview]
Message-ID: <20220406145421.GW4012@pengutronix.de> (raw)
In-Reply-To: <a5e070ae-d9e1-e5ee-0871-2cdf58958203@rock-chips.com>

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 |

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

WARNING: multiple messages have this Message-ID (diff)
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Andy Yan <andy.yan@rock-chips.com>
Cc: "Piotr Oniszczuk" <piotr.oniszczuk@gmail.com>,
	dri-devel@lists.freedesktop.org,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	kernel@pengutronix.de,
	"Benjamin Gaignard" <benjamin.gaignard@collabora.com>,
	"Michael Riesch" <michael.riesch@wolfvision.net>,
	"Sandy Huang" <hjc@rock-chips.com>,
	"Heiko Stübner" <heiko@sntech.de>,
	"Peter Geis" <pgwipeout@gmail.com>,
	"Kever Yang" <Kever.yang@rock-chips.com>
Subject: Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support
Date: Wed, 6 Apr 2022 16:54:21 +0200	[thread overview]
Message-ID: <20220406145421.GW4012@pengutronix.de> (raw)
In-Reply-To: <a5e070ae-d9e1-e5ee-0871-2cdf58958203@rock-chips.com>

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 |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Andy Yan <andy.yan@rock-chips.com>
Cc: "Piotr Oniszczuk" <piotr.oniszczuk@gmail.com>,
	dri-devel@lists.freedesktop.org,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	kernel@pengutronix.de,
	"Benjamin Gaignard" <benjamin.gaignard@collabora.com>,
	"Michael Riesch" <michael.riesch@wolfvision.net>,
	"Sandy Huang" <hjc@rock-chips.com>,
	"Heiko Stübner" <heiko@sntech.de>,
	"Peter Geis" <pgwipeout@gmail.com>,
	"Kever Yang" <Kever.yang@rock-chips.com>
Subject: Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support
Date: Wed, 6 Apr 2022 16:54:21 +0200	[thread overview]
Message-ID: <20220406145421.GW4012@pengutronix.de> (raw)
In-Reply-To: <a5e070ae-d9e1-e5ee-0871-2cdf58958203@rock-chips.com>

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 |

  reply	other threads:[~2022-04-06 14:54 UTC|newest]

Thread overview: 333+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-28 15:10 [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support Sascha Hauer
2022-03-28 15:10 ` Sascha Hauer
2022-03-28 15:10 ` Sascha Hauer
2022-03-28 15:10 ` Sascha Hauer
2022-03-28 15:10 ` [PATCH v9 01/23] clk: rk3568: Mark hclk_vo as critical Sascha Hauer
2022-03-28 15:10   ` Sascha Hauer
2022-03-28 15:10   ` Sascha Hauer
2022-03-28 15:10   ` Sascha Hauer
2022-03-29 13:22   ` Dmitry Osipenko
2022-03-29 13:22     ` Dmitry Osipenko
2022-03-29 13:22     ` Dmitry Osipenko
2022-03-29 13:22     ` Dmitry Osipenko
2022-04-06 11:15   ` Robin Murphy
2022-04-06 11:15     ` Robin Murphy
2022-04-06 11:15     ` Robin Murphy
2022-04-06 11:15     ` Robin Murphy
2022-03-28 15:10 ` [PATCH v9 02/23] drm/rockchip: Embed drm_encoder into rockchip_decoder Sascha Hauer
2022-03-28 15:10   ` Sascha Hauer
2022-03-28 15:10   ` Sascha Hauer
2022-03-28 15:10   ` Sascha Hauer
2022-03-28 15:10 ` [PATCH v9 03/23] drm/rockchip: Add crtc_endpoint_id to rockchip_encoder Sascha Hauer
2022-03-28 15:10   ` Sascha Hauer
2022-03-28 15:10   ` Sascha Hauer
2022-03-28 15:10   ` Sascha Hauer
2022-03-28 15:10 ` [PATCH v9 04/23] drm/rockchip: dw_hdmi: rename vpll clock to reference clock Sascha Hauer
2022-03-28 15:10   ` Sascha Hauer
2022-03-28 15:10   ` Sascha Hauer
2022-03-28 15:10   ` Sascha Hauer
2022-03-28 15:10 ` [PATCH v9 05/23] dt-bindings: display: rockchip: dw-hdmi: use "ref" as clock name Sascha Hauer
2022-03-28 15:10   ` Sascha Hauer
2022-03-28 15:10   ` Sascha Hauer
2022-03-28 15:10   ` Sascha Hauer
2022-03-28 15:10 ` [PATCH v9 06/23] arm64: dts: rockchip: rk3399: rename HDMI ref clock to 'ref' Sascha Hauer
2022-03-28 15:10   ` Sascha Hauer
2022-03-28 15:10   ` Sascha Hauer
2022-03-28 15:10   ` Sascha Hauer
2022-03-28 15:11 ` [PATCH v9 07/23] drm/rockchip: dw_hdmi: add rk3568 support Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11 ` [PATCH v9 08/23] dt-bindings: display: rockchip: dw-hdmi: Add compatible for rk3568 HDMI Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11 ` [PATCH v9 09/23] drm/rockchip: dw_hdmi: add regulator support Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11 ` [PATCH v9 10/23] dt-bindings: display: rockchip: dw-hdmi: Add " Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11 ` [PATCH v9 11/23] drm/rockchip: dw_hdmi: Use auto-generated tables Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11 ` [PATCH v9 12/23] drm/rockchip: dw_hdmi: drop mode_valid hook Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11 ` [PATCH v9 13/23] drm/rockchip: dw_hdmi: Set cur_ctr to 0 always Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11 ` [PATCH v9 14/23] drm/rockchip: dw_hdmi: add default 594Mhz clk for 4K@60hz Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11 ` [PATCH v9 15/23] dt-bindings: display: rockchip: dw-hdmi: Make unwedge pinctrl optional Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11 ` [PATCH v9 16/23] arm64: dts: rockchip: rk356x: Add VOP2 nodes Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11 ` [PATCH v9 17/23] arm64: dts: rockchip: rk356x: Add HDMI nodes Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11 ` [PATCH v9 18/23] arm64: dts: rockchip: rk3568-evb: Enable VOP2 and hdmi Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11 ` [PATCH v9 19/23] arm64: dts: rockchip: enable vop2 and hdmi tx on quartz64a Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11 ` [PATCH v9 20/23] drm/rockchip: Make VOP driver optional Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-29 11:56   ` Andy Yan
2022-03-29 11:56     ` Andy Yan
2022-03-29 11:56     ` Andy Yan
2022-03-29 11:56     ` Andy Yan
2022-03-30  6:39     ` Sascha Hauer
2022-03-30  6:39       ` Sascha Hauer
2022-03-30  6:39       ` Sascha Hauer
2022-03-30  6:39       ` Sascha Hauer
2022-03-30 12:50       ` Andy Yan
2022-03-30 12:50         ` Andy Yan
2022-03-30 12:50         ` Andy Yan
2022-03-30 12:50         ` Andy Yan
2022-03-31  7:06         ` Sascha Hauer
2022-03-31  7:06           ` Sascha Hauer
2022-03-31  7:06           ` Sascha Hauer
2022-03-31  7:06           ` Sascha Hauer
2022-03-31  7:20           ` Andy Yan
2022-03-31  7:20             ` Andy Yan
2022-03-31  7:20             ` Andy Yan
2022-03-31  7:20             ` Andy Yan
2022-03-31  8:18             ` Sascha Hauer
2022-03-31  8:18               ` Sascha Hauer
2022-03-31  8:18               ` Sascha Hauer
2022-03-31  8:18               ` Sascha Hauer
2022-03-31 11:00               ` Andy Yan
2022-03-31 11:00                 ` Andy Yan
2022-03-31 11:00                 ` Andy Yan
2022-03-31 11:00                 ` Andy Yan
2022-04-01 12:55                 ` Sascha Hauer
2022-04-01 12:55                   ` Sascha Hauer
2022-04-01 12:55                   ` Sascha Hauer
2022-04-01 12:55                   ` Sascha Hauer
2022-04-02  1:25                   ` Andy Yan
2022-04-02  1:25                     ` Andy Yan
2022-04-02  1:25                     ` Andy Yan
2022-04-02  1:25                     ` Andy Yan
2022-04-05  9:05                     ` Sascha Hauer
2022-04-05  9:05                       ` Sascha Hauer
2022-04-05  9:05                       ` Sascha Hauer
2022-04-05  9:05                       ` Sascha Hauer
2022-04-06  1:43                       ` Andy Yan
2022-04-06  1:43                         ` Andy Yan
2022-04-06  1:43                         ` Andy Yan
2022-04-06  1:43                         ` Andy Yan
2022-04-06  7:04                         ` Sascha Hauer
2022-04-06  7:04                           ` Sascha Hauer
2022-04-06  7:04                           ` Sascha Hauer
2022-04-06  7:04                           ` Sascha Hauer
2022-04-06  7:47                           ` Andy Yan
2022-04-06  7:47                             ` Andy Yan
2022-04-06  7:47                             ` Andy Yan
2022-04-06  7:47                             ` Andy Yan
2022-04-06  8:00                             ` Sascha Hauer
2022-04-06  8:00                               ` Sascha Hauer
2022-04-06  8:00                               ` Sascha Hauer
2022-04-06  8:00                               ` Sascha Hauer
2022-03-28 15:11 ` [PATCH v9 21/23] drm: rockchip: Add VOP2 driver Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11 ` [PATCH v9 22/23] dt-bindings: display: rockchip: Add binding for VOP2 Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11 ` [PATCH v9 23/23] dt-bindings: display: rockchip: dw-hdmi: fix ports description Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-28 15:11   ` Sascha Hauer
2022-03-29  7:31 ` [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support Piotr Oniszczuk
2022-03-29  7:31   ` Piotr Oniszczuk
2022-03-29  7:31   ` Piotr Oniszczuk
2022-03-29  7:31   ` Piotr Oniszczuk
2022-03-30  7:28   ` Sascha Hauer
2022-03-30  7:28     ` Sascha Hauer
2022-03-30  7:28     ` Sascha Hauer
2022-03-30  7:28     ` Sascha Hauer
2022-03-30  8:41     ` piotro.oniszczuk@google.com
2022-03-30  8:41       ` piotro.oniszczuk@google.com
2022-03-30  8:41       ` piotro.oniszczuk@google.com
2022-03-30  8:41       ` piotro.oniszczuk@google.com
2022-03-30  9:45       ` Sascha Hauer
2022-03-30  9:45         ` Sascha Hauer
2022-03-30  9:45         ` Sascha Hauer
2022-03-30  9:45         ` Sascha Hauer
2022-03-30 10:01         ` piotro.oniszczuk@google.com
2022-03-30 10:01           ` piotro.oniszczuk@google.com
2022-03-30 10:01           ` piotro.oniszczuk@google.com
2022-03-30 10:01           ` piotro.oniszczuk@google.com
2022-03-30 10:20           ` Sascha Hauer
2022-03-30 10:20             ` Sascha Hauer
2022-03-30 10:20             ` Sascha Hauer
2022-03-30 10:20             ` Sascha Hauer
2022-03-30 14:52             ` Piotr Oniszczuk
2022-03-30 14:52               ` Piotr Oniszczuk
2022-03-30 14:52               ` Piotr Oniszczuk
2022-03-30 14:52               ` Piotr Oniszczuk
2022-03-30 19:20               ` Sascha Hauer
2022-03-30 19:20                 ` Sascha Hauer
2022-03-30 19:20                 ` Sascha Hauer
2022-03-30 19:20                 ` Sascha Hauer
2022-03-30 19:35                 ` Piotr Oniszczuk
2022-03-30 19:35                   ` Piotr Oniszczuk
2022-03-30 19:35                   ` Piotr Oniszczuk
2022-03-30 19:35                   ` Piotr Oniszczuk
2022-03-30 19:59                   ` Sascha Hauer
2022-03-30 19:59                     ` Sascha Hauer
2022-03-30 19:59                     ` Sascha Hauer
2022-03-30 19:59                     ` Sascha Hauer
2022-03-31 12:13                 ` Andy Yan
2022-03-31 12:13                   ` Andy Yan
2022-03-31 12:13                   ` Andy Yan
2022-03-31 12:13                   ` Andy Yan
2022-03-31 12:19                   ` Sascha Hauer
2022-03-31 12:19                     ` Sascha Hauer
2022-03-31 12:19                     ` Sascha Hauer
2022-03-31 12:19                     ` Sascha Hauer
2022-03-31 14:53                   ` Piotr Oniszczuk
2022-03-31 14:53                     ` Piotr Oniszczuk
2022-03-31 14:53                     ` Piotr Oniszczuk
2022-03-31 14:53                     ` Piotr Oniszczuk
2022-03-31 15:00                     ` Sascha Hauer
2022-03-31 15:00                       ` Sascha Hauer
2022-03-31 15:00                       ` Sascha Hauer
2022-03-31 15:00                       ` Sascha Hauer
2022-03-31 15:06                       ` Piotr Oniszczuk
2022-03-31 15:06                         ` Piotr Oniszczuk
2022-03-31 15:06                         ` Piotr Oniszczuk
2022-03-31 15:06                         ` Piotr Oniszczuk
2022-03-31 15:19                         ` Piotr Oniszczuk
2022-03-31 15:19                           ` Piotr Oniszczuk
2022-03-31 15:19                           ` Piotr Oniszczuk
2022-03-31 15:19                           ` Piotr Oniszczuk
2022-04-01  1:52                     ` Andy Yan
2022-04-01  7:06                       ` Sascha Hauer
2022-04-01  7:06                         ` Sascha Hauer
2022-04-01  7:06                         ` Sascha Hauer
2022-04-01  7:06                         ` Sascha Hauer
2022-04-01 12:04                       ` Andy Yan
2022-04-01 12:53                         ` Piotr Oniszczuk
2022-04-01 12:53                           ` Piotr Oniszczuk
2022-04-01 12:53                           ` Piotr Oniszczuk
2022-04-01 12:53                           ` Piotr Oniszczuk
2022-04-01 12:52   ` Sascha Hauer
2022-04-01 12:52     ` Sascha Hauer
2022-04-01 12:52     ` Sascha Hauer
2022-04-01 12:52     ` Sascha Hauer
2022-04-01 13:05     ` Piotr Oniszczuk
2022-04-01 13:05       ` Piotr Oniszczuk
2022-04-01 13:05       ` Piotr Oniszczuk
2022-04-01 13:05       ` Piotr Oniszczuk
2022-04-06  9:47       ` Piotr Oniszczuk
2022-04-06  9:47         ` Piotr Oniszczuk
2022-04-06  9:47         ` Piotr Oniszczuk
2022-04-06  9:47         ` Piotr Oniszczuk
2022-04-06 14:58         ` Sascha Hauer
2022-04-06 14:58           ` Sascha Hauer
2022-04-06 14:58           ` Sascha Hauer
2022-04-06 14:58           ` Sascha Hauer
2022-04-06 16:00           ` Piotr Oniszczuk
2022-04-06 16:00             ` Piotr Oniszczuk
2022-04-06 16:00             ` Piotr Oniszczuk
2022-04-06 16:00             ` Piotr Oniszczuk
2022-04-07 10:16             ` Sascha Hauer
2022-04-07 10:16               ` Sascha Hauer
2022-04-07 10:16               ` Sascha Hauer
2022-04-07 10:16               ` Sascha Hauer
2022-04-07 15:02               ` Piotr Oniszczuk
2022-04-07 15:02                 ` Piotr Oniszczuk
2022-04-07 15:02                 ` Piotr Oniszczuk
2022-04-07 15:02                 ` Piotr Oniszczuk
2022-04-08  8:07         ` Sascha Hauer
2022-04-08  8:07           ` Sascha Hauer
2022-04-08  8:07           ` Sascha Hauer
2022-04-08  8:07           ` Sascha Hauer
2022-04-08 12:00           ` Sascha Hauer
2022-04-08 12:00             ` Sascha Hauer
2022-04-08 12:00             ` Sascha Hauer
2022-04-08 12:00             ` Sascha Hauer
2022-04-08 15:54             ` Piotr Oniszczuk
2022-04-08 15:54               ` Piotr Oniszczuk
2022-04-08 15:54               ` Piotr Oniszczuk
2022-04-08 15:54               ` Piotr Oniszczuk
2022-04-11  9:08               ` Sascha Hauer
2022-04-11  9:08                 ` Sascha Hauer
2022-04-11  9:08                 ` Sascha Hauer
2022-04-11  9:08                 ` Sascha Hauer
2022-04-11 11:07                 ` Piotr Oniszczuk
2022-04-11 11:07                   ` Piotr Oniszczuk
2022-04-11 11:07                   ` Piotr Oniszczuk
2022-04-11 11:07                   ` Piotr Oniszczuk
2022-04-12  7:50                   ` Sascha Hauer
2022-04-12  7:50                     ` Sascha Hauer
2022-04-12  7:50                     ` Sascha Hauer
2022-04-12  7:50                     ` Sascha Hauer
2022-04-12  8:10                     ` Lucas Stach
2022-04-12  8:10                       ` Lucas Stach
2022-04-12  8:10                       ` Lucas Stach
2022-04-12  8:10                       ` Lucas Stach
2022-04-12 10:14                       ` Piotr Oniszczuk
2022-04-12 10:14                         ` Piotr Oniszczuk
2022-04-12 10:14                         ` Piotr Oniszczuk
2022-04-12 10:14                         ` Piotr Oniszczuk
2022-04-12 11:30                         ` Daniel Stone
2022-04-12 11:30                           ` Daniel Stone
2022-04-12 11:30                           ` Daniel Stone
2022-04-12 11:30                           ` Daniel Stone
2022-04-15 11:11                           ` Piotr Oniszczuk
2022-04-15 11:11                             ` Piotr Oniszczuk
2022-04-15 11:11                             ` Piotr Oniszczuk
2022-04-15 11:11                             ` Piotr Oniszczuk
2022-04-25 14:54                             ` Daniel Stone
2022-04-25 14:54                               ` Daniel Stone
2022-04-25 14:54                               ` Daniel Stone
2022-04-25 14:54                               ` Daniel Stone
2022-04-12  9:28                     ` Piotr Oniszczuk
2022-04-12  9:28                       ` Piotr Oniszczuk
2022-04-12  9:28                       ` Piotr Oniszczuk
2022-04-12  9:28                       ` Piotr Oniszczuk
2022-04-02  1:37     ` Andy Yan
2022-04-02  1:37       ` Andy Yan
2022-04-02  1:37       ` Andy Yan
2022-04-02  1:37       ` Andy Yan
2022-04-05  9:37       ` Sascha Hauer
2022-04-05  9:37         ` Sascha Hauer
2022-04-05  9:37         ` Sascha Hauer
2022-04-05  9:37         ` Sascha Hauer
2022-04-06  2:02         ` Andy Yan
2022-04-06  2:02           ` Andy Yan
2022-04-06  2:02           ` Andy Yan
2022-04-06  2:02           ` Andy Yan
2022-04-06  8:13           ` Sascha Hauer
2022-04-06  8:13             ` Sascha Hauer
2022-04-06  8:13             ` Sascha Hauer
2022-04-06  8:13             ` Sascha Hauer
2022-04-06  8:36             ` Andy Yan
2022-04-06  8:36               ` Andy Yan
2022-04-06  8:36               ` Andy Yan
2022-04-06  8:36               ` Andy Yan
2022-04-06 14:54               ` Sascha Hauer [this message]
2022-04-06 14:54                 ` Sascha Hauer
2022-04-06 14:54                 ` Sascha Hauer
2022-04-06 14:54                 ` Sascha Hauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220406145421.GW4012@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=Kever.yang@rock-chips.com \
    --cc=andy.yan@rock-chips.com \
    --cc=benjamin.gaignard@collabora.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hjc@rock-chips.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=michael.riesch@wolfvision.net \
    --cc=pgwipeout@gmail.com \
    --cc=piotr.oniszczuk@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.