On 2021/11/18 下午5:53, Daniel Stone wrote:
Hi,
On Thu, 18 Nov 2021 at 09:26, Heiko Stübner <heiko@xxxxxxxxx> 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
timeframe.
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.
First of all, we never stop any one to doing there work on upstream if
the source code is write totally by themselves.
Second, there are also many modules are upstream by developers based on
Rockchip source code, please note that
all of them have basic respect to our work, they do communicate with us
first.
But this committer do not take any respect to our engineers and their
hard working:
- He didn't contact with us;
- There isn't any information about original author in the commit message;
As I have known, if I use source code from another developer, I
need to at least add a "Signed-off-by" with original author;
- This commit and mail does not even have a 'CC' to original author.
I NAK because I think this is not part of the open source spirit, and
this kind of behavior should not be encouraged.
Thanks,
- Kever
