[PATCH v1 00/12] drm/rockchip: RK356x VOP2 support
daniel at fooishbar.org
Thu Nov 18 01:53:11 PST 2021
On Thu, 18 Nov 2021 at 09:26, Heiko Stübner <heiko at sntech.de> wrote:
> Am Donnerstag, 18. November 2021, 02:27:10 CET schrieb Kever Yang:
> > I don't agree with this, we do believe you have do some clean up to meet
> > the requirement
> > of upstream, but all the framework and feature implement are from
> > Rockchip engineer,
> > we have made a great effort to make everything work which block us to
> > upstream this driver for now.
> I don't fully understand what you mean here (language barrier probably),
> but dropping non-essential functionality in a first round is pretty common
> to at least get basic functionality working for everyone. With the special
> features getting added again in later patches over time. This happenened
> on the old vop as well.
> And of course, having a kernel that can "just" do normal graphics without
> the additional features is still preferable over having _NO_ graphics support
> at all ;-)
> > NAK for this series.
> As you might've seen from previous graphics related patches, there
> is a big number of people _and companies_ that seems to want/need
> to work with the rk3566/rk3568 with a kernel based on mainline.
> --> Most likely even in real products!
Yes, we've been trying to ship a real product based on RK356x. We
started by using the vendor VOP2 driver, but it is broken beyond
belief. The driver needs a fundamental ground-up rework, and all the
additional features get in the way of doing this core rework to make
it actually function correctly.
So, NAK to the NAK. I would like to see the VOP2 support start simple,
with more features being added one by one.
> While Rockchip did say that they want to upstream VOP2 support, there
> has been _NO_ movement or even information at all on this over at least
> the last year(!), so it's pretty understandable that developers will do this
> themself at some point, because they don't want to wait anymore for
> something that might never happen.
> So a simple "NAK" without additional information is not really helpful here.
> If you don't like Sascha's series, I really want to know _WHEN_ Rockchip
> plans on upstreaming at least basic graphis support themself.
> The kernel is often called a do-ocracy - the one who does the work, gets
> to decide. So if you really don't like Sascha's series at all, I do expect
> Rockchip to step up and provide a solution themself - and in a usable
Exactly what Heiko said. If you would like to upstream the driver then
that would be fantastic to see, but I'm afraid you do not get to
prevent someone else from doing the work themselves.
More information about the Linux-rockchip