From: Michael Riesch <michael.riesch@wolfvision.net>
To: "Kever Yang" <kever.yang@rock-chips.com>,
"Daniel Stone" <daniel@fooishbar.org>,
"Heiko Stübner" <heiko@sntech.de>
Cc: "Sascha Hauer" <s.hauer@pengutronix.de>,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
"Benjamin Gaignard" <benjamin.gaignard@collabora.com>,
"Peter Geis" <pgwipeout@gmail.com>,
"Sandy Huang" <hjc@rock-chips.com>,
linux-rockchip@lists.infradead.org, kernel@pengutronix.de,
闫孝军 <andy.yan@rock-chips.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v1 00/12] drm/rockchip: RK356x VOP2 support
Date: Thu, 18 Nov 2021 12:08:47 +0100 [thread overview]
Message-ID: <b6ab5d5b-53fb-8c07-07c5-644f79cb3277@wolfvision.net> (raw)
In-Reply-To: <fba695b7-863a-c492-0209-41bc07c7baee@rock-chips.com>
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@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
next prev parent reply other threads:[~2021-11-18 11:10 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-17 14:33 [PATCH v1 00/12] drm/rockchip: RK356x VOP2 support Sascha Hauer
2021-11-17 14:33 ` [PATCH 01/12] dt-bindings: display: rockchip: Add compatible for rk3568 HDMI Sascha Hauer
2021-11-27 15:07 ` Heiko Stuebner
2021-11-17 14:33 ` [PATCH 02/12] drm/rockchip: dw_hdmi: Do not leave clock enabled in error case Sascha Hauer
2021-11-17 14:33 ` [PATCH 03/12] drm/rockchip: dw_hdmi: add rk3568 support Sascha Hauer
2021-11-17 14:33 ` [PATCH 04/12] drm/rockchip: dw_hdmi: add regulator support Sascha Hauer
2021-11-29 22:46 ` Rob Herring
2021-12-07 17:01 ` Robin Murphy
2021-11-17 14:33 ` [PATCH 05/12] of: graph: Allow disabled endpoints Sascha Hauer
2021-11-17 14:33 ` [PATCH 06/12] dt-bindings: " Sascha Hauer
2021-11-17 14:33 ` [PATCH 07/12] dt-bindings: display: rockchip: Add binding for VOP2 Sascha Hauer
2021-11-17 16:10 ` Rob Herring
2021-11-17 14:33 ` [PATCH 08/12] arm64: dts: rockchip: rk356x: Add VOP2 nodes Sascha Hauer
2021-11-25 20:25 ` Johan Jonker
2021-11-26 7:40 ` Sascha Hauer
2021-11-26 8:15 ` Heiko Stübner
2021-11-17 14:33 ` [PATCH 09/12] arm64: dts: rockchip: rk356x: Add HDMI nodes Sascha Hauer
2021-11-17 15:13 ` Rob Herring
2021-12-01 16:04 ` Sascha Hauer
2021-11-17 14:33 ` [PATCH 10/12] arm64: dts: rockchip: rk3568-evb: Enable VOP2 and hdmi Sascha Hauer
2021-11-17 15:19 ` Rob Herring
2021-12-02 15:34 ` Sascha Hauer
2021-12-02 15:41 ` Heiko Stübner
2021-12-02 16:09 ` Sascha Hauer
2021-11-17 15:20 ` Michael Riesch
2021-11-17 15:44 ` [PATCH] arm64: dts: rockchip: enable vop2 and hdmi tx on quartz64a Michael Riesch
2021-11-25 19:44 ` Johan Jonker
2021-11-17 14:33 ` [PATCH 11/12] drm/rockchip: Make VOP driver optional Sascha Hauer
2021-11-17 14:40 ` Heiko Stübner
2021-11-17 14:50 ` Sascha Hauer
2021-11-17 15:16 ` Heiko Stübner
2021-11-17 14:33 ` [PATCH 12/12] drm: rockchip: Add VOP2 driver Sascha Hauer
2021-11-17 18:05 ` Nicolas Frattaroli
2021-11-17 19:45 ` Sascha Hauer
2021-11-26 6:44 ` kernel test robot
2021-11-17 14:54 ` [PATCH v1 00/12] drm/rockchip: RK356x VOP2 support Rob Herring
2021-11-17 15:41 ` Sascha Hauer
2021-11-18 1:27 ` Kever Yang
2021-11-18 9:26 ` Heiko Stübner
2021-11-18 9:53 ` Daniel Stone
2021-11-18 10:50 ` Kever Yang
2021-11-18 11:08 ` Michael Riesch [this message]
2021-11-18 12:07 ` Daniel Stone
2021-11-18 13:14 ` Andy Yan
2021-11-18 13:24 ` Daniel Stone
2021-11-18 10:03 ` Sascha Hauer
2021-11-21 23:18 ` Alex Bee
2021-11-22 8:10 ` Sascha Hauer
2021-11-22 17:47 ` Alex Bee
2021-11-22 19:21 ` Robin Murphy
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=b6ab5d5b-53fb-8c07-07c5-644f79cb3277@wolfvision.net \
--to=michael.riesch@wolfvision.net \
--cc=andy.yan@rock-chips.com \
--cc=benjamin.gaignard@collabora.com \
--cc=daniel@fooishbar.org \
--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=kever.yang@rock-chips.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=pgwipeout@gmail.com \
--cc=s.hauer@pengutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).