From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754142AbbIBKDE (ORCPT ); Wed, 2 Sep 2015 06:03:04 -0400 Received: from lucky1.263xmail.com ([211.157.147.133]:40713 "EHLO lucky1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754079AbbIBKC7 (ORCPT ); Wed, 2 Sep 2015 06:02:59 -0400 X-263anti-spam: KSV:0; X-MAIL-GRAY: 1 X-MAIL-DELIVERY: 0 X-KSVirus-check: 0 X-ABS-CHECKED: 4 X-ADDR-CHECKED: 0 X-RL-SENDER: ykk@rock-chips.com X-FST-TO: yzq@rock-chips.com X-SENDER-IP: 173.239.41.18 X-LOGIN-NAME: ykk@rock-chips.com X-UNIQUE-TAG: <7b43f4061f4c8192e8d01d413fcd6670> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 1 Subject: Re: [PATCH v4 09/16] drm: rockchip: add bpc and color mode setting To: Thierry Reding References: <1441086371-24838-1-git-send-email-ykk@rock-chips.com> <1441087308-25455-1-git-send-email-ykk@rock-chips.com> <120097760.HO2inCimVA@phil> <55E659AC.9000402@rock-chips.com> <20150902083445.GA24654@ulmo.nvidia.com> Cc: Heiko Stuebner , Jingoo Han , Inki Dae , joe@perches.com, Kukjin Kim , Krzysztof Kozlowski , Mark Yao , Russell King , djkurtz@chromium.com, dianders@chromium.com, seanpaul@chromium.com, ajaynumb@gmail.com, Andrzej Hajda , Kyungmin Park , David Airlie , Gustavo Padovan , Andy Yan , Kumar Gala , Ian Campbell , Rob Herring , Pawel Moll , Kishon Vijay Abraham I , architt@codeaurora.org, robherring2@gmail.com, dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-arm-kernel@list.NULL.NULL, s.infradead.org@NULL.NULL, Mark Yao From: Yakir Yang Message-ID: <55E6C931.9090306@rock-chips.com> Date: Wed, 2 Sep 2015 18:02:25 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150902083445.GA24654@ulmo.nvidia.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thierry, 在 2015/9/2 16:34, Thierry Reding 写道: > On Wed, Sep 02, 2015 at 10:06:36AM +0800, Yakir Yang wrote: >> 在 09/02/2015 05:00 AM, Heiko Stuebner 写道: >>> Am Dienstag, 1. September 2015, 14:01:48 schrieb Yakir Yang: > [...] >>>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c >>>> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c index 34b78e7..5d7f9b6 100644 >>>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c >>>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c >>>> @@ -811,14 +811,41 @@ static const struct drm_plane_funcs vop_plane_funcs = >>>> { >>>> >>>> int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc, >>>> int connector_type, >>>> - int out_mode) >>>> + int bpc, int color) >>>> { >>>> struct vop *vop = to_vop(crtc); >>>> - >>>> vop->connector_type = connector_type; >>>> vop->connector_out_mode = out_mode; >>> this line should probably go away, as the source var "out_mode" does not exist >>> in the function params any more, making the compilation break, and is set >>> below anyway. >> Sorry for the failed, there are must be a problem when I backport those code >> to chrome-3.14 to verify. >> >> Thanks a lot, I would update next version soon. > *sigh* > > I get the feeling that you're going about upstreaming the wrong way. If > you post patches to upstream mailing lists and you expect people to > apply those patches, then your target is the upstream kernel. So you > should be basing all of your work on top of a recent release candidate > directly from Linus or some recent version of linux-next. Yeah, do feel I am in the wrong way now. I used to write my patch on linux-next branch, then backport some head file to productor kernel, so I can check compiled failed. After that, I backport the dp driver code to normal productor kernel, start to debug the function. So I used to ensure no compiled failed on upstrean kernel, actually it's also hard to ensure, cause I just backport head file. Not even debug the function on upstream kernel. > Your current approach is already making people waste time trying to > build the patches and fail because you've been testing on something > other than mainline or linux-next. > > At the very least your code must compile when applied against a recent > upstream tree. I would also expect you to make sure the code works at > runtime, though, contrary to build testing, not everybody will be able > to verify that you've actually done so. It is ultimately your platform > maintainer's (i.e. Heiko's) responsibility to ensure that because they > will get to deal with user complaints if people can't run an upstream > kernel on the devices. Oh, first time to know this rule. So I should work on Heiko's github kernel branch at the first time to start send upstream. > I realize that the upstream kernel isn't what's going to end up in > products later on, but that doesn't change the fact that you're > submitting code for inclusion in the mainline tree. If you need to > backport code to some ChromeOS tree, then that should be done after > you've verified that things build and run upstream. Doing so makes life > a lot easier for your upstream maintainers, and that in turn makes it > more likely to get your code merged. Feel free now, I would correct those in bellow version. Thanks for your remind (or maybe complain :-D ). - Yakir > Thierry