From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754021AbbIBIfH (ORCPT ); Wed, 2 Sep 2015 04:35:07 -0400 Received: from hqemgate14.nvidia.com ([216.228.121.143]:5133 "EHLO hqemgate14.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752590AbbIBIfA (ORCPT ); Wed, 2 Sep 2015 04:35:00 -0400 X-PGP-Universal: processed; by hqnvupgp08.nvidia.com on Wed, 02 Sep 2015 01:34:58 -0700 Date: Wed, 2 Sep 2015 10:34:46 +0200 From: Thierry Reding To: Yakir Yang CC: Heiko Stuebner , Jingoo Han , "Inki Dae" , , Kukjin Kim , Krzysztof Kozlowski , Mark Yao , Russell King , , , , , Andrzej Hajda , Kyungmin Park , David Airlie , Gustavo Padovan , Andy Yan , "Kumar Gala" , Ian Campbell , Rob Herring , Pawel Moll , "Kishon Vijay Abraham I" , , , , , , , , , , Mark Yao Subject: Re: [PATCH v4 09/16] drm: rockchip: add bpc and color mode setting Message-ID: <20150902083445.GA24654@ulmo.nvidia.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> MIME-Version: 1.0 In-Reply-To: <55E659AC.9000402@rock-chips.com> X-NVConfidentiality: public User-Agent: Mutt/1.5.23+102 (2ca89bed6448) (2014-03-12) X-Originating-IP: [10.2.70.198] X-ClientProxiedBy: UKMAIL101.nvidia.com (10.26.138.13) To UKMAIL101.nvidia.com (10.26.138.13) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 02, 2015 at 10:06:36AM +0800, Yakir Yang wrote: > =E5=9C=A8 09/02/2015 05:00 AM, Heiko Stuebner =E5=86=99=E9=81=93: > >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 10= 0644 > >>--- 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_fun= cs =3D > >>{ > >> > >> int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc, > >> int connector_type, > >>- int out_mode) > >>+ int bpc, int color) > >> { > >> struct vop *vop =3D to_vop(crtc); > >>- > >> vop->connector_type =3D connector_type; > >> vop->connector_out_mode =3D 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. >=20 > Sorry for the failed, there are must be a problem when I backport those c= ode > to chrome-3.14 to verify. >=20 > 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. 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. 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. Thierry --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJV5rSiAAoJEN0jrNd/PrOh6MAP/iyH9u6icnoveJighTWuyBZU hZKI/TpTPFLN1tPJnUdbpdtCfx0K6Dq22hnyB6XNWMPKaI0nTdUS/MZh8QicxNVa C3jk153jouiiMq8BbsbibVuXRnYCe6mpLZ5rPRer93TURgduu7lclOHfvLj5+vRg PMb5vRcG0JTANDeE9GBgaSH73DqFzH9Lhb+dj+fQlcyZvOJrq2i5ZkRVR36bLRzm pPxWYN7sVsSmN4GDlqZreXBVE3GEPkpnXq98O9OE5z/Ih3c7oO+CBBlVdv+APxD+ Rj7Ae0YShdJrnFw0W48/nUwMBpFg4otnuXMRm/2DX2KVPjsTPYDBbPuodwFIIaci ocwmdAS5JYBg4SFt5lIFF3cAC51Y5xvqgMAeorhFHcqCHU4gveJqzCno4I54zpIk YdnDGomi4qXoa6AE/9BnuJgzVuIXBEm2B2jIJyAj0mB5doPc2sy3+23fEFCbL/4E hJdVcMZAid+Sm4l5wULW2prYu9EH6gaYiX8/x5j6nEO5XKwV8URcKVouikW7D+BG n73qVvpveOcnBMZMmr0DRMQORVlOWTGssXwzdEkEqGc7GViFTfF3ZWBzkLg2ys+U I0/lMYn7cMDZnrlVl/a+ck7SqELkKP0Th6QK15tCkpGd/skH1V0DrV+XmN2ftlPn w7elaisXMdZXkpk2kYL9 =4CKn -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [PATCH v4 09/16] drm: rockchip: add bpc and color mode setting Date: Wed, 2 Sep 2015 10:34:46 +0200 Message-ID: <20150902083445.GA24654@ulmo.nvidia.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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Return-path: In-Reply-To: <55E659AC.9000402@rock-chips.com> Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org To: Yakir Yang 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.kern List-Id: devicetree@vger.kernel.org --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 02, 2015 at 10:06:36AM +0800, Yakir Yang wrote: > =E5=9C=A8 09/02/2015 05:00 AM, Heiko Stuebner =E5=86=99=E9=81=93: > >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 10= 0644 > >>--- 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_fun= cs =3D > >>{ > >> > >> int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc, > >> int connector_type, > >>- int out_mode) > >>+ int bpc, int color) > >> { > >> struct vop *vop =3D to_vop(crtc); > >>- > >> vop->connector_type =3D connector_type; > >> vop->connector_out_mode =3D 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. >=20 > Sorry for the failed, there are must be a problem when I backport those c= ode > to chrome-3.14 to verify. >=20 > 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. 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. 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. Thierry --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJV5rSiAAoJEN0jrNd/PrOh6MAP/iyH9u6icnoveJighTWuyBZU hZKI/TpTPFLN1tPJnUdbpdtCfx0K6Dq22hnyB6XNWMPKaI0nTdUS/MZh8QicxNVa C3jk153jouiiMq8BbsbibVuXRnYCe6mpLZ5rPRer93TURgduu7lclOHfvLj5+vRg PMb5vRcG0JTANDeE9GBgaSH73DqFzH9Lhb+dj+fQlcyZvOJrq2i5ZkRVR36bLRzm pPxWYN7sVsSmN4GDlqZreXBVE3GEPkpnXq98O9OE5z/Ih3c7oO+CBBlVdv+APxD+ Rj7Ae0YShdJrnFw0W48/nUwMBpFg4otnuXMRm/2DX2KVPjsTPYDBbPuodwFIIaci ocwmdAS5JYBg4SFt5lIFF3cAC51Y5xvqgMAeorhFHcqCHU4gveJqzCno4I54zpIk YdnDGomi4qXoa6AE/9BnuJgzVuIXBEm2B2jIJyAj0mB5doPc2sy3+23fEFCbL/4E hJdVcMZAid+Sm4l5wULW2prYu9EH6gaYiX8/x5j6nEO5XKwV8URcKVouikW7D+BG n73qVvpveOcnBMZMmr0DRMQORVlOWTGssXwzdEkEqGc7GViFTfF3ZWBzkLg2ys+U I0/lMYn7cMDZnrlVl/a+ck7SqELkKP0Th6QK15tCkpGd/skH1V0DrV+XmN2ftlPn w7elaisXMdZXkpk2kYL9 =4CKn -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND--