linux-kernel - Re: [PATCH v4 09/16] drm: rockchip: add bpc and color mode setting

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 2 Sep 2015 18:02:25 +0800
From:	Yakir Yang <ykk@...k-chips.com>
To:	Thierry Reding <treding@...dia.com>
Cc:	Heiko Stuebner <heiko@...ech.de>,
	Jingoo Han <jingoohan1@...il.com>,
	Inki Dae <inki.dae@...sung.com>, joe@...ches.com,
	Kukjin Kim <kgene@...nel.org>,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	Mark Yao <mark.yao@...k-chips.com>,
	Russell King <rmk+kernel@....linux.org.uk>,
	djkurtz@...omium.com, dianders@...omium.com, seanpaul@...omium.com,
	ajaynumb@...il.com, Andrzej Hajda <a.hajda@...sung.com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	David Airlie <airlied@...ux.ie>,
	Gustavo Padovan <gustavo.padovan@...labora.co.uk>,
	Andy Yan <andy.yan@...k-chips.com>,
	Kumar Gala <galak@...eaurora.org>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Kishon Vijay Abraham I <kishon@...com>,
	architt@...eaurora.org, robherring2@...il.com,
	dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-samsung-soc@...r.kernel.org,
	linux-rockchip@...ts.infradead.org,
	linux-arm-kernel@...t.NULL.NULL, s.infradead.org@...L.NULL,
	Mark Yao <yzq@...k-chips.com>
Subject: Re: [PATCH v4 09/16] drm: rockchip: add bpc and color mode setting

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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/