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

[Michael Riesch]

Hello Kever,

On 11/18/21 11:50 AM, Kever Yang wrote:
> 
> 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;

I approached Andy Yan and you off-list on October 20, 2021 in this 
regard, as Andy mentioned on linux-rockchip in July 2021 some plans to 
bring the driver mainline. Since there was no response, we asked Sascha 
to make this happen.

> - 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;

As has been discussed before, this will be fixed in v2. Simple mistake, 
no harm intended.

> - 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.

It is great to hear that you care about the open source spirit. IMHO 
communication is a big part thereof. If Rockchip would communicate 
better their plans to bring things mainline including a time schedule, 
it would be a lot easier for all of us.

Best regards,
Michael