[PATCH v1 00/12] drm/rockchip: RK356x VOP2 support

[Kever Yang]

On 2021/11/18 下午5:53, Daniel Stone wrote:
> Hi,
>
> 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
>> 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