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: dri-devel@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.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 20/23] drm/rockchip: Make VOP driver optional
Date: Wed, 6 Apr 2022 09:04:03 +0200	[thread overview]
Message-ID: <20220406070403.GS4012@pengutronix.de> (raw)
In-Reply-To: <93001a4c-b009-202f-7b04-34e1a9e617ec@rock-chips.com>

On Wed, Apr 06, 2022 at 09:43:49AM +0800, Andy Yan wrote:
> Hi Sacha:
> 
> On 4/5/22 17:05, Sascha Hauer wrote:
> > On Sat, Apr 02, 2022 at 09:25:33AM +0800, Andy Yan wrote:
> > > Hi Sascha:
> > > 
> > > On 4/1/22 20:55, Sascha Hauer wrote:
> > > > On Thu, Mar 31, 2022 at 07:00:34PM +0800, Andy Yan wrote:
> > > > > Hi:
> > > > > 
> > > > > On 3/31/22 16:18, Sascha Hauer wrote:
> > > > > > On Thu, Mar 31, 2022 at 03:20:37PM +0800, Andy Yan wrote:
> > > > > > > Hi Sascha:
> > > > > > > 
> > > > > > > On 3/31/22 15:06, Sascha Hauer wrote:
> > > > > > > > On Wed, Mar 30, 2022 at 08:50:09PM +0800, Andy Yan wrote:
> > > > > > > > > Hi Sascha:
> > > > > > > > > 
> > > > > > > > > On 3/30/22 14:39, Sascha Hauer wrote:
> > > > > > > > > > Hi Andy,
> > > > > > > > > > 
> > > > > > > > > > On Tue, Mar 29, 2022 at 07:56:27PM +0800, Andy Yan wrote:
> > > > > > > > > > > Hi Sascha:
> > > > > > > > > > > 
> > > > > > > > > > > On 3/28/22 23:11, Sascha Hauer wrote:
> > > > > > > > > > > > With upcoming VOP2 support VOP won't be the only choice anymore, so make
> > > > > > > > > > > > the VOP driver optional.
> > > > > > > > > > > > 
> > > > > > > > > > > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > > > > > > > > > > ---
> > > > > > > > > > > >        drivers/gpu/drm/rockchip/Kconfig            | 8 ++++++++
> > > > > > > > > > > >        drivers/gpu/drm/rockchip/Makefile           | 3 ++-
> > > > > > > > > > > >        drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
> > > > > > > > > > > >        3 files changed, 11 insertions(+), 2 deletions(-)
> > > > > > > > > > > > 
> > > > > > > > > > > > diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
> > > > > > > > > > > > index fa5cfda4e90e3..7d22e2997a571 100644
> > > > > > > > > > > > --- a/drivers/gpu/drm/rockchip/Kconfig
> > > > > > > > > > > > +++ b/drivers/gpu/drm/rockchip/Kconfig
> > > > > > > > > > > > @@ -23,8 +23,16 @@ config DRM_ROCKCHIP
> > > > > > > > > > > >        if DRM_ROCKCHIP
> > > > > > > > > > > > +config ROCKCHIP_VOP
> > > > > > > > > > > > +	bool "Rockchip VOP driver"
> > > > > > > > > > > > +	default y
> > > > > > > > > > > > +	help
> > > > > > > > > > > > +	  This selects support for the VOP driver. You should enable it
> > > > > > > > > > > > +	  on all older SoCs up to RK3399.
> > > > > > > > > > That reminds me that I wanted to rephrase this. Will change in next
> > > > > > > > > > round.
> > > > > > > > > > 
> > > > > > > > > > > > +
> > > > > > > > > > > >        config ROCKCHIP_ANALOGIX_DP
> > > > > > > > > > > >        	bool "Rockchip specific extensions for Analogix DP driver"
> > > > > > > > > > > > +	depends on ROCKCHIP_VOP
> > > > > > > > > > > Aanlogix dp is also on vop2 base soc such as  rk356x and rk3588.
> > > > > > > > BTW I just looked at the downstream driver. Here we have the same
> > > > > > > > situation that the analogix dp driver calls rockchip_drm_wait_vact_end()
> > > > > > > > which is implemented in the VOP driver, so when the analogix dp driver
> > > > > > > > is actually used on a VOP2 SoC then it is either used in a way that
> > > > > > > > rockchip_drm_wait_vact_end() will never be called or it explodes in all
> > > > > > > > colours.
> > > > > > > > 
> > > > > > > > > > I added the dependency because analogix_dp-rockchip.c calls
> > > > > > > > > > rockchip_drm_wait_vact_end() which is implemented in the VOP driver,
> > > > > > > > > > so this driver currenty can't work with the VOP2 driver and can't
> > > > > > > > > > be linked without the VOP driver being present.
> > > > > > > > > > I'll add a few words to the commit message.
> > > > > > > > > Maybe a better direction is move rockchip_drm_wait_vact_end from the VOP
> > > > > > > > > driver to rockchip_drm_drv.c
> > > > > > > > I am not sure if that's really worth it. Yes, the direction might be the
> > > > > > > > right one, but I would really prefer when somebody does the change who
> > > > > > > > can test and confirm that the analogix dp really works with VOP2 in the
> > > > > > > > end.
> > > > > > > If follow this point, the current DW_MIPI also has not been tested for
> > > > > > > confirm that it
> > > > > > > 
> > > > > > > can really work with VOP2, so you should also make it depends on
> > > > > > > ROCKCHIP_VOP.
> > Here you are suggesting to add even more Kconfig dependencies.
> > 
> > > > > > Well at least I have patches here which make DW_MIPI work with VOP2 ;)
> > > > > But you DW_MIPI patches for rk356x didn't come. So this is not keep
> > > > > consistency with this point.
> > > > > 
> > > > > > What about the others, like LVDS and RGB?
> > > > > Yes, we also have other interface , RK356X has LVDS/RGB/BT1120/BT656, RK3588
> > > > > has BT1120/BT656, no LVDS or RGB.
> > > > > 
> > > > > > > I think the current solution is just a workaround to make your patch pass
> > > > > > > the kernel compile
> > > > > > Indeed.
> > > > > > 
> > > > > > I agree that it would be good to add a note somewhere which outputs
> > > > > > work with the VOP2 driver (currently only HDMI), but I wonder if Kconfig
> > > > > > dependencies is the right place for it, because only people who deliberately
> > > > > > disable VOP support will see this information.
> > > > > > Maybe we should rather add it to the Kconfig help text?
> > > > > If a device is supported for this soc, we will add dt node at the dtsi file.
> > > > > 
> > > > > A Kconfig dependencies don't seems a good idea.
> > Here you say Kconfig dependencies are no good idea.
> 
> 
> Yes. It's not a good idea. So I don't want to see you use a Kcofig
> dependence
> 
> to disable a module to avoid compile which introduced by your patch.
> 
> > 
> > > > Ok, this means we can keep my current approach with just letting
> > > > ROCKCHIP_ANALOGIX_DP depend on ROCKCHIP_VOP to avoid having a non
> > > Excuse me? How do you get this conclusion ?
> > Given that you say that you want to have both more and less Kconfig
> > dependencies I came to the conclusion that I only add one where it's
> > necessary to compile the driver.
> > 
> > > I said before,  vop and vop2 based platforms both have ROCKCHIP_ANALOGIX_DP.
> > Maybe, but vop2 with ROCKCHIP_ANALOGIX_DP doesn't even work in the
> > Rockchip downstream kernel, so I wonder how relevant this usecase really
> > is.
> 
> 
> No, this is not the truth. Rockchip_ANALOGIX_DP of course work with the
> vendor kernel. We have many rk356x based products shipped with edp.
> Even the VGA output interface on RK3568_EVB1 is drived by
> ROCKCHIP_ANALOGIX_DP with a RTD2166 eDP to VGA convert
> chip.
> 
> 
> So how do you get conclusion that ROCKCHIP_ANALOGIX_DP can't work with
> the Rockchip downstream kernel? Is it because you can't make the DP work on
> your board? If it is, please contact the supplier who gave you the board.

In the downstream kernel I have available (which is a 5.10.66)
analogix_dp-rockchip.c calls rockchip_drm_wait_vact_end() which is
implemented in rockchip_drm_vop.c and assumes that the passed struct
drm_crtc * can be converted to a struct vop *. Basically it's the same
situation we have right now with the mainline kernel, just that the
linker issues won't show up because the VOP driver can't be disabled
in the downstream kernel.

> 
> 
> Do you have a RK3568_EVB1 that has a VGA output interface on board?
> 
> If you have it, I can offer you image to verify the DP.
> 
> 
> > > If this patch will cause the compile error, please do a real fix, not a
> > I can't, because I don't have any hardware to test the Analogix DP on a
> > VOP hardware, and given that Analogix DP in conjunction with VOP2 hardware is
> > not even supported in the downstream Kernel I am not sure if it's really
> > worth doing that.
> 
> 
> Again, this is not the truth, see above.
> I am not ask you support the ROCKCHIP_ANALOGIX_DP on upstream, I just
> want you can give a better solution when you patch cause the compile error.
> Disable a module when it conflict with your patch is too rough.

It does not conflict with my patch. The dependency only means that you can't
enable the Analogix DP driver when the VOP driver is disabled. That
doesn't hurt, because currently you can't do anything with the Analogix
DP driver without the VOP driver. With the added dependency the Analogix DP
driver can still be used with the VOP driver, even when the VOP2 driver
is enabled. I really can't see a problem with that.

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: devicetree@vger.kernel.org,
	Benjamin Gaignard <benjamin.gaignard@collabora.com>,
	Sandy Huang <hjc@rock-chips.com>,
	dri-devel@lists.freedesktop.org,
	Kever Yang <Kever.yang@rock-chips.com>,
	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
Subject: Re: [PATCH v9 20/23] drm/rockchip: Make VOP driver optional
Date: Wed, 6 Apr 2022 09:04:03 +0200	[thread overview]
Message-ID: <20220406070403.GS4012@pengutronix.de> (raw)
In-Reply-To: <93001a4c-b009-202f-7b04-34e1a9e617ec@rock-chips.com>

On Wed, Apr 06, 2022 at 09:43:49AM +0800, Andy Yan wrote:
> Hi Sacha:
> 
> On 4/5/22 17:05, Sascha Hauer wrote:
> > On Sat, Apr 02, 2022 at 09:25:33AM +0800, Andy Yan wrote:
> > > Hi Sascha:
> > > 
> > > On 4/1/22 20:55, Sascha Hauer wrote:
> > > > On Thu, Mar 31, 2022 at 07:00:34PM +0800, Andy Yan wrote:
> > > > > Hi:
> > > > > 
> > > > > On 3/31/22 16:18, Sascha Hauer wrote:
> > > > > > On Thu, Mar 31, 2022 at 03:20:37PM +0800, Andy Yan wrote:
> > > > > > > Hi Sascha:
> > > > > > > 
> > > > > > > On 3/31/22 15:06, Sascha Hauer wrote:
> > > > > > > > On Wed, Mar 30, 2022 at 08:50:09PM +0800, Andy Yan wrote:
> > > > > > > > > Hi Sascha:
> > > > > > > > > 
> > > > > > > > > On 3/30/22 14:39, Sascha Hauer wrote:
> > > > > > > > > > Hi Andy,
> > > > > > > > > > 
> > > > > > > > > > On Tue, Mar 29, 2022 at 07:56:27PM +0800, Andy Yan wrote:
> > > > > > > > > > > Hi Sascha:
> > > > > > > > > > > 
> > > > > > > > > > > On 3/28/22 23:11, Sascha Hauer wrote:
> > > > > > > > > > > > With upcoming VOP2 support VOP won't be the only choice anymore, so make
> > > > > > > > > > > > the VOP driver optional.
> > > > > > > > > > > > 
> > > > > > > > > > > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > > > > > > > > > > ---
> > > > > > > > > > > >        drivers/gpu/drm/rockchip/Kconfig            | 8 ++++++++
> > > > > > > > > > > >        drivers/gpu/drm/rockchip/Makefile           | 3 ++-
> > > > > > > > > > > >        drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
> > > > > > > > > > > >        3 files changed, 11 insertions(+), 2 deletions(-)
> > > > > > > > > > > > 
> > > > > > > > > > > > diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
> > > > > > > > > > > > index fa5cfda4e90e3..7d22e2997a571 100644
> > > > > > > > > > > > --- a/drivers/gpu/drm/rockchip/Kconfig
> > > > > > > > > > > > +++ b/drivers/gpu/drm/rockchip/Kconfig
> > > > > > > > > > > > @@ -23,8 +23,16 @@ config DRM_ROCKCHIP
> > > > > > > > > > > >        if DRM_ROCKCHIP
> > > > > > > > > > > > +config ROCKCHIP_VOP
> > > > > > > > > > > > +	bool "Rockchip VOP driver"
> > > > > > > > > > > > +	default y
> > > > > > > > > > > > +	help
> > > > > > > > > > > > +	  This selects support for the VOP driver. You should enable it
> > > > > > > > > > > > +	  on all older SoCs up to RK3399.
> > > > > > > > > > That reminds me that I wanted to rephrase this. Will change in next
> > > > > > > > > > round.
> > > > > > > > > > 
> > > > > > > > > > > > +
> > > > > > > > > > > >        config ROCKCHIP_ANALOGIX_DP
> > > > > > > > > > > >        	bool "Rockchip specific extensions for Analogix DP driver"
> > > > > > > > > > > > +	depends on ROCKCHIP_VOP
> > > > > > > > > > > Aanlogix dp is also on vop2 base soc such as  rk356x and rk3588.
> > > > > > > > BTW I just looked at the downstream driver. Here we have the same
> > > > > > > > situation that the analogix dp driver calls rockchip_drm_wait_vact_end()
> > > > > > > > which is implemented in the VOP driver, so when the analogix dp driver
> > > > > > > > is actually used on a VOP2 SoC then it is either used in a way that
> > > > > > > > rockchip_drm_wait_vact_end() will never be called or it explodes in all
> > > > > > > > colours.
> > > > > > > > 
> > > > > > > > > > I added the dependency because analogix_dp-rockchip.c calls
> > > > > > > > > > rockchip_drm_wait_vact_end() which is implemented in the VOP driver,
> > > > > > > > > > so this driver currenty can't work with the VOP2 driver and can't
> > > > > > > > > > be linked without the VOP driver being present.
> > > > > > > > > > I'll add a few words to the commit message.
> > > > > > > > > Maybe a better direction is move rockchip_drm_wait_vact_end from the VOP
> > > > > > > > > driver to rockchip_drm_drv.c
> > > > > > > > I am not sure if that's really worth it. Yes, the direction might be the
> > > > > > > > right one, but I would really prefer when somebody does the change who
> > > > > > > > can test and confirm that the analogix dp really works with VOP2 in the
> > > > > > > > end.
> > > > > > > If follow this point, the current DW_MIPI also has not been tested for
> > > > > > > confirm that it
> > > > > > > 
> > > > > > > can really work with VOP2, so you should also make it depends on
> > > > > > > ROCKCHIP_VOP.
> > Here you are suggesting to add even more Kconfig dependencies.
> > 
> > > > > > Well at least I have patches here which make DW_MIPI work with VOP2 ;)
> > > > > But you DW_MIPI patches for rk356x didn't come. So this is not keep
> > > > > consistency with this point.
> > > > > 
> > > > > > What about the others, like LVDS and RGB?
> > > > > Yes, we also have other interface , RK356X has LVDS/RGB/BT1120/BT656, RK3588
> > > > > has BT1120/BT656, no LVDS or RGB.
> > > > > 
> > > > > > > I think the current solution is just a workaround to make your patch pass
> > > > > > > the kernel compile
> > > > > > Indeed.
> > > > > > 
> > > > > > I agree that it would be good to add a note somewhere which outputs
> > > > > > work with the VOP2 driver (currently only HDMI), but I wonder if Kconfig
> > > > > > dependencies is the right place for it, because only people who deliberately
> > > > > > disable VOP support will see this information.
> > > > > > Maybe we should rather add it to the Kconfig help text?
> > > > > If a device is supported for this soc, we will add dt node at the dtsi file.
> > > > > 
> > > > > A Kconfig dependencies don't seems a good idea.
> > Here you say Kconfig dependencies are no good idea.
> 
> 
> Yes. It's not a good idea. So I don't want to see you use a Kcofig
> dependence
> 
> to disable a module to avoid compile which introduced by your patch.
> 
> > 
> > > > Ok, this means we can keep my current approach with just letting
> > > > ROCKCHIP_ANALOGIX_DP depend on ROCKCHIP_VOP to avoid having a non
> > > Excuse me? How do you get this conclusion ?
> > Given that you say that you want to have both more and less Kconfig
> > dependencies I came to the conclusion that I only add one where it's
> > necessary to compile the driver.
> > 
> > > I said before,  vop and vop2 based platforms both have ROCKCHIP_ANALOGIX_DP.
> > Maybe, but vop2 with ROCKCHIP_ANALOGIX_DP doesn't even work in the
> > Rockchip downstream kernel, so I wonder how relevant this usecase really
> > is.
> 
> 
> No, this is not the truth. Rockchip_ANALOGIX_DP of course work with the
> vendor kernel. We have many rk356x based products shipped with edp.
> Even the VGA output interface on RK3568_EVB1 is drived by
> ROCKCHIP_ANALOGIX_DP with a RTD2166 eDP to VGA convert
> chip.
> 
> 
> So how do you get conclusion that ROCKCHIP_ANALOGIX_DP can't work with
> the Rockchip downstream kernel? Is it because you can't make the DP work on
> your board? If it is, please contact the supplier who gave you the board.

In the downstream kernel I have available (which is a 5.10.66)
analogix_dp-rockchip.c calls rockchip_drm_wait_vact_end() which is
implemented in rockchip_drm_vop.c and assumes that the passed struct
drm_crtc * can be converted to a struct vop *. Basically it's the same
situation we have right now with the mainline kernel, just that the
linker issues won't show up because the VOP driver can't be disabled
in the downstream kernel.

> 
> 
> Do you have a RK3568_EVB1 that has a VGA output interface on board?
> 
> If you have it, I can offer you image to verify the DP.
> 
> 
> > > If this patch will cause the compile error, please do a real fix, not a
> > I can't, because I don't have any hardware to test the Analogix DP on a
> > VOP hardware, and given that Analogix DP in conjunction with VOP2 hardware is
> > not even supported in the downstream Kernel I am not sure if it's really
> > worth doing that.
> 
> 
> Again, this is not the truth, see above.
> I am not ask you support the ROCKCHIP_ANALOGIX_DP on upstream, I just
> want you can give a better solution when you patch cause the compile error.
> Disable a module when it conflict with your patch is too rough.

It does not conflict with my patch. The dependency only means that you can't
enable the Analogix DP driver when the VOP driver is disabled. That
doesn't hurt, because currently you can't do anything with the Analogix
DP driver without the VOP driver. With the added dependency the Analogix DP
driver can still be used with the VOP driver, even when the VOP2 driver
is enabled. I really can't see a problem with that.

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: dri-devel@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.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 20/23] drm/rockchip: Make VOP driver optional
Date: Wed, 6 Apr 2022 09:04:03 +0200	[thread overview]
Message-ID: <20220406070403.GS4012@pengutronix.de> (raw)
In-Reply-To: <93001a4c-b009-202f-7b04-34e1a9e617ec@rock-chips.com>

On Wed, Apr 06, 2022 at 09:43:49AM +0800, Andy Yan wrote:
> Hi Sacha:
> 
> On 4/5/22 17:05, Sascha Hauer wrote:
> > On Sat, Apr 02, 2022 at 09:25:33AM +0800, Andy Yan wrote:
> > > Hi Sascha:
> > > 
> > > On 4/1/22 20:55, Sascha Hauer wrote:
> > > > On Thu, Mar 31, 2022 at 07:00:34PM +0800, Andy Yan wrote:
> > > > > Hi:
> > > > > 
> > > > > On 3/31/22 16:18, Sascha Hauer wrote:
> > > > > > On Thu, Mar 31, 2022 at 03:20:37PM +0800, Andy Yan wrote:
> > > > > > > Hi Sascha:
> > > > > > > 
> > > > > > > On 3/31/22 15:06, Sascha Hauer wrote:
> > > > > > > > On Wed, Mar 30, 2022 at 08:50:09PM +0800, Andy Yan wrote:
> > > > > > > > > Hi Sascha:
> > > > > > > > > 
> > > > > > > > > On 3/30/22 14:39, Sascha Hauer wrote:
> > > > > > > > > > Hi Andy,
> > > > > > > > > > 
> > > > > > > > > > On Tue, Mar 29, 2022 at 07:56:27PM +0800, Andy Yan wrote:
> > > > > > > > > > > Hi Sascha:
> > > > > > > > > > > 
> > > > > > > > > > > On 3/28/22 23:11, Sascha Hauer wrote:
> > > > > > > > > > > > With upcoming VOP2 support VOP won't be the only choice anymore, so make
> > > > > > > > > > > > the VOP driver optional.
> > > > > > > > > > > > 
> > > > > > > > > > > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > > > > > > > > > > ---
> > > > > > > > > > > >        drivers/gpu/drm/rockchip/Kconfig            | 8 ++++++++
> > > > > > > > > > > >        drivers/gpu/drm/rockchip/Makefile           | 3 ++-
> > > > > > > > > > > >        drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
> > > > > > > > > > > >        3 files changed, 11 insertions(+), 2 deletions(-)
> > > > > > > > > > > > 
> > > > > > > > > > > > diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
> > > > > > > > > > > > index fa5cfda4e90e3..7d22e2997a571 100644
> > > > > > > > > > > > --- a/drivers/gpu/drm/rockchip/Kconfig
> > > > > > > > > > > > +++ b/drivers/gpu/drm/rockchip/Kconfig
> > > > > > > > > > > > @@ -23,8 +23,16 @@ config DRM_ROCKCHIP
> > > > > > > > > > > >        if DRM_ROCKCHIP
> > > > > > > > > > > > +config ROCKCHIP_VOP
> > > > > > > > > > > > +	bool "Rockchip VOP driver"
> > > > > > > > > > > > +	default y
> > > > > > > > > > > > +	help
> > > > > > > > > > > > +	  This selects support for the VOP driver. You should enable it
> > > > > > > > > > > > +	  on all older SoCs up to RK3399.
> > > > > > > > > > That reminds me that I wanted to rephrase this. Will change in next
> > > > > > > > > > round.
> > > > > > > > > > 
> > > > > > > > > > > > +
> > > > > > > > > > > >        config ROCKCHIP_ANALOGIX_DP
> > > > > > > > > > > >        	bool "Rockchip specific extensions for Analogix DP driver"
> > > > > > > > > > > > +	depends on ROCKCHIP_VOP
> > > > > > > > > > > Aanlogix dp is also on vop2 base soc such as  rk356x and rk3588.
> > > > > > > > BTW I just looked at the downstream driver. Here we have the same
> > > > > > > > situation that the analogix dp driver calls rockchip_drm_wait_vact_end()
> > > > > > > > which is implemented in the VOP driver, so when the analogix dp driver
> > > > > > > > is actually used on a VOP2 SoC then it is either used in a way that
> > > > > > > > rockchip_drm_wait_vact_end() will never be called or it explodes in all
> > > > > > > > colours.
> > > > > > > > 
> > > > > > > > > > I added the dependency because analogix_dp-rockchip.c calls
> > > > > > > > > > rockchip_drm_wait_vact_end() which is implemented in the VOP driver,
> > > > > > > > > > so this driver currenty can't work with the VOP2 driver and can't
> > > > > > > > > > be linked without the VOP driver being present.
> > > > > > > > > > I'll add a few words to the commit message.
> > > > > > > > > Maybe a better direction is move rockchip_drm_wait_vact_end from the VOP
> > > > > > > > > driver to rockchip_drm_drv.c
> > > > > > > > I am not sure if that's really worth it. Yes, the direction might be the
> > > > > > > > right one, but I would really prefer when somebody does the change who
> > > > > > > > can test and confirm that the analogix dp really works with VOP2 in the
> > > > > > > > end.
> > > > > > > If follow this point, the current DW_MIPI also has not been tested for
> > > > > > > confirm that it
> > > > > > > 
> > > > > > > can really work with VOP2, so you should also make it depends on
> > > > > > > ROCKCHIP_VOP.
> > Here you are suggesting to add even more Kconfig dependencies.
> > 
> > > > > > Well at least I have patches here which make DW_MIPI work with VOP2 ;)
> > > > > But you DW_MIPI patches for rk356x didn't come. So this is not keep
> > > > > consistency with this point.
> > > > > 
> > > > > > What about the others, like LVDS and RGB?
> > > > > Yes, we also have other interface , RK356X has LVDS/RGB/BT1120/BT656, RK3588
> > > > > has BT1120/BT656, no LVDS or RGB.
> > > > > 
> > > > > > > I think the current solution is just a workaround to make your patch pass
> > > > > > > the kernel compile
> > > > > > Indeed.
> > > > > > 
> > > > > > I agree that it would be good to add a note somewhere which outputs
> > > > > > work with the VOP2 driver (currently only HDMI), but I wonder if Kconfig
> > > > > > dependencies is the right place for it, because only people who deliberately
> > > > > > disable VOP support will see this information.
> > > > > > Maybe we should rather add it to the Kconfig help text?
> > > > > If a device is supported for this soc, we will add dt node at the dtsi file.
> > > > > 
> > > > > A Kconfig dependencies don't seems a good idea.
> > Here you say Kconfig dependencies are no good idea.
> 
> 
> Yes. It's not a good idea. So I don't want to see you use a Kcofig
> dependence
> 
> to disable a module to avoid compile which introduced by your patch.
> 
> > 
> > > > Ok, this means we can keep my current approach with just letting
> > > > ROCKCHIP_ANALOGIX_DP depend on ROCKCHIP_VOP to avoid having a non
> > > Excuse me? How do you get this conclusion ?
> > Given that you say that you want to have both more and less Kconfig
> > dependencies I came to the conclusion that I only add one where it's
> > necessary to compile the driver.
> > 
> > > I said before,  vop and vop2 based platforms both have ROCKCHIP_ANALOGIX_DP.
> > Maybe, but vop2 with ROCKCHIP_ANALOGIX_DP doesn't even work in the
> > Rockchip downstream kernel, so I wonder how relevant this usecase really
> > is.
> 
> 
> No, this is not the truth. Rockchip_ANALOGIX_DP of course work with the
> vendor kernel. We have many rk356x based products shipped with edp.
> Even the VGA output interface on RK3568_EVB1 is drived by
> ROCKCHIP_ANALOGIX_DP with a RTD2166 eDP to VGA convert
> chip.
> 
> 
> So how do you get conclusion that ROCKCHIP_ANALOGIX_DP can't work with
> the Rockchip downstream kernel? Is it because you can't make the DP work on
> your board? If it is, please contact the supplier who gave you the board.

In the downstream kernel I have available (which is a 5.10.66)
analogix_dp-rockchip.c calls rockchip_drm_wait_vact_end() which is
implemented in rockchip_drm_vop.c and assumes that the passed struct
drm_crtc * can be converted to a struct vop *. Basically it's the same
situation we have right now with the mainline kernel, just that the
linker issues won't show up because the VOP driver can't be disabled
in the downstream kernel.

> 
> 
> Do you have a RK3568_EVB1 that has a VGA output interface on board?
> 
> If you have it, I can offer you image to verify the DP.
> 
> 
> > > If this patch will cause the compile error, please do a real fix, not a
> > I can't, because I don't have any hardware to test the Analogix DP on a
> > VOP hardware, and given that Analogix DP in conjunction with VOP2 hardware is
> > not even supported in the downstream Kernel I am not sure if it's really
> > worth doing that.
> 
> 
> Again, this is not the truth, see above.
> I am not ask you support the ROCKCHIP_ANALOGIX_DP on upstream, I just
> want you can give a better solution when you patch cause the compile error.
> Disable a module when it conflict with your patch is too rough.

It does not conflict with my patch. The dependency only means that you can't
enable the Analogix DP driver when the VOP driver is disabled. That
doesn't hurt, because currently you can't do anything with the Analogix
DP driver without the VOP driver. With the added dependency the Analogix DP
driver can still be used with the VOP driver, even when the VOP2 driver
is enabled. I really can't see a problem with that.

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: dri-devel@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.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 20/23] drm/rockchip: Make VOP driver optional
Date: Wed, 6 Apr 2022 09:04:03 +0200	[thread overview]
Message-ID: <20220406070403.GS4012@pengutronix.de> (raw)
In-Reply-To: <93001a4c-b009-202f-7b04-34e1a9e617ec@rock-chips.com>

On Wed, Apr 06, 2022 at 09:43:49AM +0800, Andy Yan wrote:
> Hi Sacha:
> 
> On 4/5/22 17:05, Sascha Hauer wrote:
> > On Sat, Apr 02, 2022 at 09:25:33AM +0800, Andy Yan wrote:
> > > Hi Sascha:
> > > 
> > > On 4/1/22 20:55, Sascha Hauer wrote:
> > > > On Thu, Mar 31, 2022 at 07:00:34PM +0800, Andy Yan wrote:
> > > > > Hi:
> > > > > 
> > > > > On 3/31/22 16:18, Sascha Hauer wrote:
> > > > > > On Thu, Mar 31, 2022 at 03:20:37PM +0800, Andy Yan wrote:
> > > > > > > Hi Sascha:
> > > > > > > 
> > > > > > > On 3/31/22 15:06, Sascha Hauer wrote:
> > > > > > > > On Wed, Mar 30, 2022 at 08:50:09PM +0800, Andy Yan wrote:
> > > > > > > > > Hi Sascha:
> > > > > > > > > 
> > > > > > > > > On 3/30/22 14:39, Sascha Hauer wrote:
> > > > > > > > > > Hi Andy,
> > > > > > > > > > 
> > > > > > > > > > On Tue, Mar 29, 2022 at 07:56:27PM +0800, Andy Yan wrote:
> > > > > > > > > > > Hi Sascha:
> > > > > > > > > > > 
> > > > > > > > > > > On 3/28/22 23:11, Sascha Hauer wrote:
> > > > > > > > > > > > With upcoming VOP2 support VOP won't be the only choice anymore, so make
> > > > > > > > > > > > the VOP driver optional.
> > > > > > > > > > > > 
> > > > > > > > > > > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > > > > > > > > > > ---
> > > > > > > > > > > >        drivers/gpu/drm/rockchip/Kconfig            | 8 ++++++++
> > > > > > > > > > > >        drivers/gpu/drm/rockchip/Makefile           | 3 ++-
> > > > > > > > > > > >        drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
> > > > > > > > > > > >        3 files changed, 11 insertions(+), 2 deletions(-)
> > > > > > > > > > > > 
> > > > > > > > > > > > diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
> > > > > > > > > > > > index fa5cfda4e90e3..7d22e2997a571 100644
> > > > > > > > > > > > --- a/drivers/gpu/drm/rockchip/Kconfig
> > > > > > > > > > > > +++ b/drivers/gpu/drm/rockchip/Kconfig
> > > > > > > > > > > > @@ -23,8 +23,16 @@ config DRM_ROCKCHIP
> > > > > > > > > > > >        if DRM_ROCKCHIP
> > > > > > > > > > > > +config ROCKCHIP_VOP
> > > > > > > > > > > > +	bool "Rockchip VOP driver"
> > > > > > > > > > > > +	default y
> > > > > > > > > > > > +	help
> > > > > > > > > > > > +	  This selects support for the VOP driver. You should enable it
> > > > > > > > > > > > +	  on all older SoCs up to RK3399.
> > > > > > > > > > That reminds me that I wanted to rephrase this. Will change in next
> > > > > > > > > > round.
> > > > > > > > > > 
> > > > > > > > > > > > +
> > > > > > > > > > > >        config ROCKCHIP_ANALOGIX_DP
> > > > > > > > > > > >        	bool "Rockchip specific extensions for Analogix DP driver"
> > > > > > > > > > > > +	depends on ROCKCHIP_VOP
> > > > > > > > > > > Aanlogix dp is also on vop2 base soc such as  rk356x and rk3588.
> > > > > > > > BTW I just looked at the downstream driver. Here we have the same
> > > > > > > > situation that the analogix dp driver calls rockchip_drm_wait_vact_end()
> > > > > > > > which is implemented in the VOP driver, so when the analogix dp driver
> > > > > > > > is actually used on a VOP2 SoC then it is either used in a way that
> > > > > > > > rockchip_drm_wait_vact_end() will never be called or it explodes in all
> > > > > > > > colours.
> > > > > > > > 
> > > > > > > > > > I added the dependency because analogix_dp-rockchip.c calls
> > > > > > > > > > rockchip_drm_wait_vact_end() which is implemented in the VOP driver,
> > > > > > > > > > so this driver currenty can't work with the VOP2 driver and can't
> > > > > > > > > > be linked without the VOP driver being present.
> > > > > > > > > > I'll add a few words to the commit message.
> > > > > > > > > Maybe a better direction is move rockchip_drm_wait_vact_end from the VOP
> > > > > > > > > driver to rockchip_drm_drv.c
> > > > > > > > I am not sure if that's really worth it. Yes, the direction might be the
> > > > > > > > right one, but I would really prefer when somebody does the change who
> > > > > > > > can test and confirm that the analogix dp really works with VOP2 in the
> > > > > > > > end.
> > > > > > > If follow this point, the current DW_MIPI also has not been tested for
> > > > > > > confirm that it
> > > > > > > 
> > > > > > > can really work with VOP2, so you should also make it depends on
> > > > > > > ROCKCHIP_VOP.
> > Here you are suggesting to add even more Kconfig dependencies.
> > 
> > > > > > Well at least I have patches here which make DW_MIPI work with VOP2 ;)
> > > > > But you DW_MIPI patches for rk356x didn't come. So this is not keep
> > > > > consistency with this point.
> > > > > 
> > > > > > What about the others, like LVDS and RGB?
> > > > > Yes, we also have other interface , RK356X has LVDS/RGB/BT1120/BT656, RK3588
> > > > > has BT1120/BT656, no LVDS or RGB.
> > > > > 
> > > > > > > I think the current solution is just a workaround to make your patch pass
> > > > > > > the kernel compile
> > > > > > Indeed.
> > > > > > 
> > > > > > I agree that it would be good to add a note somewhere which outputs
> > > > > > work with the VOP2 driver (currently only HDMI), but I wonder if Kconfig
> > > > > > dependencies is the right place for it, because only people who deliberately
> > > > > > disable VOP support will see this information.
> > > > > > Maybe we should rather add it to the Kconfig help text?
> > > > > If a device is supported for this soc, we will add dt node at the dtsi file.
> > > > > 
> > > > > A Kconfig dependencies don't seems a good idea.
> > Here you say Kconfig dependencies are no good idea.
> 
> 
> Yes. It's not a good idea. So I don't want to see you use a Kcofig
> dependence
> 
> to disable a module to avoid compile which introduced by your patch.
> 
> > 
> > > > Ok, this means we can keep my current approach with just letting
> > > > ROCKCHIP_ANALOGIX_DP depend on ROCKCHIP_VOP to avoid having a non
> > > Excuse me? How do you get this conclusion ?
> > Given that you say that you want to have both more and less Kconfig
> > dependencies I came to the conclusion that I only add one where it's
> > necessary to compile the driver.
> > 
> > > I said before,  vop and vop2 based platforms both have ROCKCHIP_ANALOGIX_DP.
> > Maybe, but vop2 with ROCKCHIP_ANALOGIX_DP doesn't even work in the
> > Rockchip downstream kernel, so I wonder how relevant this usecase really
> > is.
> 
> 
> No, this is not the truth. Rockchip_ANALOGIX_DP of course work with the
> vendor kernel. We have many rk356x based products shipped with edp.
> Even the VGA output interface on RK3568_EVB1 is drived by
> ROCKCHIP_ANALOGIX_DP with a RTD2166 eDP to VGA convert
> chip.
> 
> 
> So how do you get conclusion that ROCKCHIP_ANALOGIX_DP can't work with
> the Rockchip downstream kernel? Is it because you can't make the DP work on
> your board? If it is, please contact the supplier who gave you the board.

In the downstream kernel I have available (which is a 5.10.66)
analogix_dp-rockchip.c calls rockchip_drm_wait_vact_end() which is
implemented in rockchip_drm_vop.c and assumes that the passed struct
drm_crtc * can be converted to a struct vop *. Basically it's the same
situation we have right now with the mainline kernel, just that the
linker issues won't show up because the VOP driver can't be disabled
in the downstream kernel.

> 
> 
> Do you have a RK3568_EVB1 that has a VGA output interface on board?
> 
> If you have it, I can offer you image to verify the DP.
> 
> 
> > > If this patch will cause the compile error, please do a real fix, not a
> > I can't, because I don't have any hardware to test the Analogix DP on a
> > VOP hardware, and given that Analogix DP in conjunction with VOP2 hardware is
> > not even supported in the downstream Kernel I am not sure if it's really
> > worth doing that.
> 
> 
> Again, this is not the truth, see above.
> I am not ask you support the ROCKCHIP_ANALOGIX_DP on upstream, I just
> want you can give a better solution when you patch cause the compile error.
> Disable a module when it conflict with your patch is too rough.

It does not conflict with my patch. The dependency only means that you can't
enable the Analogix DP driver when the VOP driver is disabled. That
doesn't hurt, because currently you can't do anything with the Analogix
DP driver without the VOP driver. With the added dependency the Analogix DP
driver can still be used with the VOP driver, even when the VOP2 driver
is enabled. I really can't see a problem with that.

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  7:04 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 [this message]
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
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=20220406070403.GS4012@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=heiko@sntech.de \
    --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 \
    /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.