From: tony@atomide•com (Tony Lindgren)
To: linux-arm-kernel@lists•infradead.org
Subject: [GIT PULL] omap dss board clean-up for v3.10 merge window
Date: Thu, 13 Jun 2013 03:54:35 -0700 [thread overview]
Message-ID: <20130613105434.GB8164@atomide.com> (raw)
In-Reply-To: <51B97B28.3060609@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti•com> [130613 01:02]:
> Hi Tony,
>
> On 03/06/13 15:20, Tomi Valkeinen wrote:
>
> Any feeback about the below? I'm currently aiming for the option 2, and
> pushing only the driver changes for the next merge window, as that
> allows me to go forward without any arch/arm changes.
Yes that sounds good to me. Then we may be able to do a small follow-up
branch at the end of the merge window for the arch/arm changes. But
up to you how you prefer to handle it, I'm sure you're well aware of
the pains of cross tree dependencies by now :)
Regards,
Tony
> > I have a somewhat similar situation again for 3.11 (or possibly for
> > 3.12). I hope to hear from you what you think would be the best approach.
> >
> > The background is that the omap display subsystem has a bunch of panel
> > drivers, and these drivers have used an OMAP DSS specific bus and driver
> > model. For various reasons I'm now converting the panel drivers to be
> > based on the panel's control bus, i.e. a panel controlled via i2c would
> > be an i2c device/driver, a panel not controlled at all would be a
> > platform device/driver, etc.
> >
> > The work involves changing the omapdss driver, converting the panel
> > drivers to the new driver model, and changing the board files that use
> > the panel.
> >
> > I see two main approaches to this:
> >
> > 1) Convert the panel drivers "in-place", i.e. have a commit which
> > changes a panel driver to the new model. This would mean that the
> > instant the commit is in, the boards using the panel do not work until
> > the board file has been changed.
> >
> > 2) Convert the panel to a new file, i.e. basically make a copy of the
> > panel driver while converting it. This way the boards using the old
> > panel drivers will continue working. (This is how I have my patches
> > currently organized).
> >
> > Option 1) feels more natural, but if the arch and driver changes go
> > through separate trees, there's a piece of history during the merge
> > window where the displays won't work on the OMAP boards.
> >
> > Option 2) allows us to keep the boards always functional if the new
> > panel drivers are merged in 3.11, and the board file changes are merged
> > in 3.12.
> >
> > The downside is that it takes two kernel versions to get this in, and a
> > third kernel version to finally remove all the old code. 3.11 and 3.12
> > would contain unused code, some of which will be in the kernel image
> > (omapdss side changes) and some of which won't be compiled at all (the
> > new panel drivers).
> >
> > Do you think option 2 and splitting the work into three kernel versions
> > is the way to go? Do you have some other ideas how to organize the merge
> > of these kind of changes?
> >
> > Tomi
> >
> >
>
>
prev parent reply other threads:[~2013-06-13 10:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-18 3:39 [GIT PULL] omap dss board clean-up for v3.10 merge window Tony Lindgren
2013-04-19 18:45 ` Olof Johansson
2013-04-19 19:33 ` Tony Lindgren
2013-04-22 8:32 ` Tomi Valkeinen
2013-04-23 17:14 ` Tony Lindgren
2013-04-24 7:56 ` Tomi Valkeinen
2013-04-24 16:50 ` Tony Lindgren
2013-06-03 12:20 ` Tomi Valkeinen
2013-06-13 7:56 ` Tomi Valkeinen
2013-06-13 10:54 ` Tony Lindgren [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130613105434.GB8164@atomide.com \
--to=tony@atomide$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox