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

[Yakir Yang]

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