From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1D807C433EF for ; Thu, 18 Nov 2021 09:26:38 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 41A7061B30 for ; Thu, 18 Nov 2021 09:26:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 41A7061B30 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=sntech.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id AFB6F6ECFD; Thu, 18 Nov 2021 09:26:35 +0000 (UTC) Received: from gloria.sntech.de (gloria.sntech.de [185.11.138.130]) by gabe.freedesktop.org (Postfix) with ESMTPS id C430E6ECFD for ; Thu, 18 Nov 2021 09:26:34 +0000 (UTC) Received: from ip5f5a6e92.dynamic.kabel-deutschland.de ([95.90.110.146] helo=diego.localnet) by gloria.sntech.de with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mndgc-0000UD-Nv; Thu, 18 Nov 2021 10:26:30 +0100 From: Heiko =?ISO-8859-1?Q?St=FCbner?= To: Sascha Hauer , dri-devel@lists.freedesktop.org, Kever Yang Subject: Re: [PATCH v1 00/12] drm/rockchip: RK356x VOP2 support Date: Thu, 18 Nov 2021 10:26:29 +0100 Message-ID: <4310886.V3yF0ifEZO@diego> In-Reply-To: <3bbf42f3-bd9c-ed66-e421-8d78fbeb22ad@rock-chips.com> References: <20211117143347.314294-1-s.hauer@pengutronix.de> <3bbf42f3-bd9c-ed66-e421-8d78fbeb22ad@rock-chips.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, Benjamin Gaignard , Peter Geis , Sandy Huang , linux-rockchip@lists.infradead.org, Michael Riesch , kernel@pengutronix.de, =?utf-8?B?6Zer5a2d5Yab?= , linux-arm-kernel@lists.infradead.org Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi Kever, Am Donnerstag, 18. November 2021, 02:27:10 CET schrieb Kever Yang: > Hi Sascha Hauer, >=20 > On 2021/11/17 =E4=B8=8B=E5=8D=8810:33, Sascha Hauer wrote: > > This series adds initial graphics support for the Rockchip RK356[68] > > SoCs. Graphics support is based around the VOP2 controller which > > replaces the VOP controller found on earlier Rockchip SoCs. The driver > > has been tested with HDMI support included in this series and MIPI-DSI > > which is not included because it needs some more work. The driver is > > taken from the downstream Rockchip kernel >=20 > Yes, you do know this is from Rockchip kernel. >=20 > Could you point me out where is the information about original author =20 > in your commit? The copyrights for added files seem to have stayed intact. =46or example the added rockchip_drm_vop2.c file in patch12 does contain the copyright as Copyright (c) 2020 Rockchip Electronics Co., Ltd. Author: Andy Yan We can of course debate if the commit-author should also be set to Andy or another Rockchip engineer, with Sascha adding a=20 "Co-developed-by" with his credentials. That's probably a nice compromise, I guess. > > and heavily polished, most non > > standard features have been removed for now. >=20 > I don't agree with this, we do believe you have do some clean up to meet= =20 > the requirement >=20 > of upstream, but all the framework and feature implement are from=20 > Rockchip engineer, >=20 > we have made a great effort to make everything work which block us to=20 > 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 suppo= rt 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. =2D-> Most likely even in real products! 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. Heiko