From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751513AbbIFCHN (ORCPT ); Sat, 5 Sep 2015 22:07:13 -0400 Received: from lucky1.263xmail.com ([211.157.147.132]:41975 "EHLO lucky1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750893AbbIFCHH (ORCPT ); Sat, 5 Sep 2015 22:07:07 -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: 58.22.7.114 X-LOGIN-NAME: ykk@rock-chips.com X-UNIQUE-TAG: <128ecfe4c82521cfed8dfe5f6184b283> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Message-ID: <55EB9FB4.3020201@rock-chips.com> Date: Sun, 06 Sep 2015 10:06:44 +0800 From: Yakir Yang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Thierry Reding , Mark Yao CC: Heiko Stuebner , Jingoo Han , Inki Dae , joe@perches.com, Kukjin Kim , Krzysztof Kozlowski , 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 Subject: Re: [PATCH v4 09/16] drm: rockchip: add bpc and color mode setting 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> <55E6C931.9090306@rock-chips.com> <20150903083857.GA3784@ulmo.nvidia.com> In-Reply-To: <20150903083857.GA3784@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 Hi Thierry, 在 09/03/2015 04:38 PM, Thierry Reding 写道: > On Wed, Sep 02, 2015 at 06:02:25PM +0800, Yakir Yang wrote: >> 在 2015/9/2 16:34, Thierry Reding 写道: > [...] >>> 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. > It's usually not necessary to rebase on a specific platform tree. Most > platform trees should feed into linux-next anyway, so linux-next would > be the appropriate base in almost all cases. > > Note, though, that that's only true if you expect somebody else to merge > your code. The reason is that whoever will end up applying your patches > will likely apply to a tree that feeds into linux-next, and that way you > both end up having roughly the same base. > > On the other hand if you are a maintainer yourself you should be keeping > a branch based on the latest -rc1. That's especially important if your > tree feeds into linux-next, because basing on linux-next will break very > horribly that way. > > So for this particular case I would expect either Mark or Inki to apply > these patches when they're ready. Their trees should be based on the > latest -rc1. At least the Exynos DRM tree feeds into linux-next, so you > should be fine if you use linux-next as a base. Glad to know this, thanks, - Yakir > > Mark, have you ever considered having your tree added to linux-next? > > I'm beginning to think that we need to make that a requirement for all > DRM drivers so that we can resolve integration issues early on rather > than Dave having to deal with them when he pulls code in. > > Thierry From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yakir Yang Subject: Re: [PATCH v4 09/16] drm: rockchip: add bpc and color mode setting Date: Sun, 06 Sep 2015 10:06:44 +0800 Message-ID: <55EB9FB4.3020201@rock-chips.com> 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> <55E6C931.9090306@rock-chips.com> <20150903083857.GA3784@ulmo.nvidia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20150903083857.GA3784@ulmo.nvidia.com> Sender: linux-samsung-soc-owner@vger.kernel.org To: Thierry Reding , Mark Yao Cc: Heiko Stuebner , Jingoo Han , Inki Dae , joe@perches.com, Kukjin Kim , Krzysztof Kozlowski , 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 List-Id: devicetree@vger.kernel.org Hi Thierry, =E5=9C=A8 09/03/2015 04:38 PM, Thierry Reding =E5=86=99=E9=81=93: > On Wed, Sep 02, 2015 at 06:02:25PM +0800, Yakir Yang wrote: >> =E5=9C=A8 2015/9/2 16:34, Thierry Reding =E5=86=99=E9=81=93: > [...] >>> At the very least your code must compile when applied against a rec= ent >>> upstream tree. I would also expect you to make sure the code works = at >>> runtime, though, contrary to build testing, not everybody will be a= ble >>> to verify that you've actually done so. It is ultimately your platf= orm >>> maintainer's (i.e. Heiko's) responsibility to ensure that because t= hey >>> will get to deal with user complaints if people can't run an upstre= am >>> 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. > It's usually not necessary to rebase on a specific platform tree. Mos= t > platform trees should feed into linux-next anyway, so linux-next woul= d > be the appropriate base in almost all cases. > > Note, though, that that's only true if you expect somebody else to me= rge > your code. The reason is that whoever will end up applying your patch= es > will likely apply to a tree that feeds into linux-next, and that way = you > both end up having roughly the same base. > > On the other hand if you are a maintainer yourself you should be keep= ing > a branch based on the latest -rc1. That's especially important if you= r > tree feeds into linux-next, because basing on linux-next will break v= ery > horribly that way. > > So for this particular case I would expect either Mark or Inki to app= ly > these patches when they're ready. Their trees should be based on the > latest -rc1. At least the Exynos DRM tree feeds into linux-next, so y= ou > should be fine if you use linux-next as a base. Glad to know this, thanks, - Yakir > > Mark, have you ever considered having your tree added to linux-next? > > I'm beginning to think that we need to make that a requirement for al= l > DRM drivers so that we can resolve integration issues early on rather > than Dave having to deal with them when he pulls code in. > > Thierry