Re: [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


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