Patchwork [GIT,PULL] omap dss board clean-up for v3.10 merge window

login
register
mail settings
Submitter Tony Lindgren
Date April 18, 2013, 3:39 a.m.
Message ID <20130418033936.GC10155@atomide.com>
Download mbox
Permalink /patch/237427/
State New
Headers show

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/dss-signed

Comments

Tony Lindgren - April 18, 2013, 3:39 a.m.
The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:

  Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/dss-signed

for you to fetch changes up to 4de2a2b4aeabe5c8b11ab8655ad59c55b3d91962:

  Merge branch '3.10-lo/board-cleanup' of git://gitorious.org/linux-omap-dss2/linux into omap-for-v3.10/dss (2013-04-17 17:09:04 -0700)

----------------------------------------------------------------

Display related clean-up from Tomi Valkeinen.

These were separated from the DSS driver changes to leave out
a dependency between the driver and arch/arm related code.

As agreed on the mailing lists, these are based on Tomi's
platform_data header branch at:

git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers

Note that these patches have already been in Linux next via
Tomi's tree. As Tomi's driver changes are getting merged via
the drm tree because of another dependency, these should get
merged via the ARM SoC tree.

Apologies for the late pull request on this one, this dependency
should have been cleared away earlier.

----------------------------------------------------------------
Archit Taneja (14):
      OMAPDSS: panels: keep platform data of all panels in a single header
      arm: omap: board-2430: use generic dpi panel's gpio handling
      arm: omap: board-devkit8000: use generic dpi panel's gpio handling
      arm: omap: board-am3517: use generic dpi panel's gpio handling
      arm: omap: board-ldp: use generic dpi panel's gpio handling
      arm: omap: board-overo: use lb035q02 dpi panel's gpio handling
      arm: omap: board-omap3evm: use sharp panel's gpio handling
      arm: omap: board-sdp3430: use sharp panel's gpio handling
      arm: omap: board-rx-51: use acx565akm panel's gpio handling
      arm: omap: board-zoom: use NEC panel's gpio handling
      arm: omap: board-omap3pandora: use tpo panel's gpio handling
      arm: omap: dss-common: use picodlp panel's gpio handling
      arm: omap boards: Remove unnecessary platform_enable/disable callbacks for VENC devices
      arm: dss-common: don't use reset_gpio from omap4_panda_dvi_device

Peter Ujfalusi (1):
      ARM: OMAP: zoom: Use pwm stack for lcd and keyboard backlight

Tomi Valkeinen (2):
      OMAPDSS: add fields to panels' platform data
      arm: omap: board-cm-t35: use generic dpi panel's gpio handling

Tony Lindgren (1):
      Merge branch '3.10-lo/board-cleanup' of git://gitorious.org/linux-omap-dss2/linux into omap-for-v3.10/dss

 arch/arm/mach-omap2/board-2430sdp.c              |  45 ++-----
 arch/arm/mach-omap2/board-3430sdp.c              |  55 +++-----
 arch/arm/mach-omap2/board-am3517evm.c            |  77 ++----------
 arch/arm/mach-omap2/board-cm-t35.c               |  63 ++--------
 arch/arm/mach-omap2/board-devkit8000.c           |  30 +----
 arch/arm/mach-omap2/board-h4.c                   |   2 +-
 arch/arm/mach-omap2/board-igep0020.c             |   2 +-
 arch/arm/mach-omap2/board-ldp.c                  |  63 ++--------
 arch/arm/mach-omap2/board-omap3beagle.c          |   2 +-
 arch/arm/mach-omap2/board-omap3evm.c             |  72 ++++-------
 arch/arm/mach-omap2/board-omap3pandora.c         |   7 +-
 arch/arm/mach-omap2/board-omap3stalker.c         |  14 +--
 arch/arm/mach-omap2/board-overo.c                |  61 +++------
 arch/arm/mach-omap2/board-rx51-video.c           |  26 ++--
 arch/arm/mach-omap2/board-zoom-display.c         |  94 ++------------
 arch/arm/mach-omap2/board-zoom-peripherals.c     |  53 +++++++-
 arch/arm/mach-omap2/dss-common.c                 |  58 +++------
 drivers/video/omap2/displays/panel-generic-dpi.c |   2 +-
 drivers/video/omap2/displays/panel-n8x0.c        |   2 +-
 drivers/video/omap2/displays/panel-picodlp.c     |   2 +-
 drivers/video/omap2/displays/panel-taal.c        |   2 +-
 drivers/video/omap2/displays/panel-tfp410.c      |   2 +-
 include/video/omap-panel-data.h                  | 152 +++++++++++++++++++++++
 include/video/omap-panel-generic-dpi.h           |  37 ------
 include/video/omap-panel-n8x0.h                  |  15 ---
 include/video/omap-panel-nokia-dsi.h             |  32 -----
 include/video/omap-panel-picodlp.h               |  23 ----
 include/video/omap-panel-tfp410.h                |  35 ------
 28 files changed, 349 insertions(+), 679 deletions(-)
 create mode 100644 include/video/omap-panel-data.h
 delete mode 100644 include/video/omap-panel-generic-dpi.h
 delete mode 100644 include/video/omap-panel-n8x0.h
 delete mode 100644 include/video/omap-panel-nokia-dsi.h
 delete mode 100644 include/video/omap-panel-picodlp.h
 delete mode 100644 include/video/omap-panel-tfp410.h
Olof Johansson - April 19, 2013, 6:45 p.m.
Hi,

On Wed, Apr 17, 2013 at 08:39:37PM -0700, Tony Lindgren wrote:
> The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
> 
>   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/dss-signed


Merged, but not happy about it.

As mentioned on IRC, I was going to let this one be until 3.11, but it sounds
like it will cause regressions in DSS if we don't merge it.

This is an indication that the work wasn't done right on the DSS rework.
Ideally the old configurations through platform_data should have been left in
for a release to give the boards a window to convert over without regressing
functionality. Tomi, please don't do it this way in the future since it's
painful for everybody to deal with.

I've queued this with late/cleanup. I noticed some conflicts with the previous
omap/fixes-non-critical and omap/boards branches that I brought in as a base so
I could fix it up in my merge instead of having it go all the way up to Linus
to resolve.


-Olof
Tony Lindgren - April 19, 2013, 7:33 p.m.
* Olof Johansson <olof@lixom.net> [130419 11:50]:
> Hi,
> 
> On Wed, Apr 17, 2013 at 08:39:37PM -0700, Tony Lindgren wrote:
> > The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
> > 
> >   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
> > 
> > are available in the git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/dss-signed
> 
> 
> Merged, but not happy about it.
> 
> As mentioned on IRC, I was going to let this one be until 3.11, but it sounds
> like it will cause regressions in DSS if we don't merge it.
> 
> This is an indication that the work wasn't done right on the DSS rework.
> Ideally the old configurations through platform_data should have been left in
> for a release to give the boards a window to convert over without regressing
> functionality. Tomi, please don't do it this way in the future since it's
> painful for everybody to deal with.

Yes sorry this should have been done already few weeks ago when these
patches hit linux next via Tomi's tree. In the future, let's plan on doing
the shared branches early on between -rc2 and -rc4 so we don't all have to
scramble just before the merge window.

> I've queued this with late/cleanup. I noticed some conflicts with the previous
> omap/fixes-non-critical and omap/boards branches that I brought in as a base so
> I could fix it up in my merge instead of having it go all the way up to Linus
> to resolve.

OK thanks.

Tony
Tomi Valkeinen - April 22, 2013, 8:32 a.m.
On 2013-04-19 21:45, Olof Johansson wrote:
> Hi,
> 
> On Wed, Apr 17, 2013 at 08:39:37PM -0700, Tony Lindgren wrote:
>> The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
>>
>>   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/dss-signed
> 
> 
> Merged, but not happy about it.

Thanks.

> As mentioned on IRC, I was going to let this one be until 3.11, but it sounds
> like it will cause regressions in DSS if we don't merge it.

Yes, that's true. The branch has been unchanged and in linux-next, so
merging it late shouldn't cause any bigger issues. But I understand it's
quite late, and I should've pushed the branch forward much earlier.
Sorry about that.

> This is an indication that the work wasn't done right on the DSS rework.
> Ideally the old configurations through platform_data should have been left in
> for a release to give the boards a window to convert over without regressing
> functionality. Tomi, please don't do it this way in the future since it's
> painful for everybody to deal with.

I've been trying to keep everything working even if parts of the whole
series go through different trees. I've been very strict on that things
must compile, but keeping display working if only half of the series is
merged is rather difficult at times.

For this series, I think it could've been done, but it would have
required adding hacks, or some kind of "bool new_pdata" fields so that
the driver understand what to do. And duplicate code to manage the
different platform data versions.

In the near future we'll get rid of the current custom omapdss panel
device, and use the standard platform/i2c/etc devices for the panel. The
only way to do that while keeping everything running is to clone the
panel drivers, one handling the old one and the other handling the new one.

All this makes me spend lots of time doing extra work, that in no way
improves the driver. Its only for the purpose of getting arch changes
through one tree, and driver changes through the other. And this makes
the patches much more difficult to follow, as the related changes are in
separate series, and there may be extra crud just to handle this separation.

So while I think it is a good habit to push the arch changes and driver
changes separately, my question is, should that rule be followed to the
extreme? Can I just keep all the changes in one branch if separating the
arch and driver changes would end up with cloning files or lots of extra
code?

Of course, I don't know what DRM maintainer thinks of merging arch
changes through his tree, so that's also open.

 Tomi
Tony Lindgren - April 23, 2013, 5:14 p.m.
* Tomi Valkeinen <tomi.valkeinen@ti.com> [130422 01:37]:
> On 2013-04-19 21:45, Olof Johansson wrote:
> > Hi,
> > 
> > On Wed, Apr 17, 2013 at 08:39:37PM -0700, Tony Lindgren wrote:
> >> The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
> >>
> >>   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
> >>
> >> are available in the git repository at:
> >>
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/dss-signed
> > 
> > 
> > Merged, but not happy about it.
> 
> Thanks.
> 
> > As mentioned on IRC, I was going to let this one be until 3.11, but it sounds
> > like it will cause regressions in DSS if we don't merge it.
> 
> Yes, that's true. The branch has been unchanged and in linux-next, so
> merging it late shouldn't cause any bigger issues. But I understand it's
> quite late, and I should've pushed the branch forward much earlier.
> Sorry about that.
> 
> > This is an indication that the work wasn't done right on the DSS rework.
> > Ideally the old configurations through platform_data should have been left in
> > for a release to give the boards a window to convert over without regressing
> > functionality. Tomi, please don't do it this way in the future since it's
> > painful for everybody to deal with.
> 
> I've been trying to keep everything working even if parts of the whole
> series go through different trees. I've been very strict on that things
> must compile, but keeping display working if only half of the series is
> merged is rather difficult at times.
> 
> For this series, I think it could've been done, but it would have
> required adding hacks, or some kind of "bool new_pdata" fields so that
> the driver understand what to do. And duplicate code to manage the
> different platform data versions.
> 
> In the near future we'll get rid of the current custom omapdss panel
> device, and use the standard platform/i2c/etc devices for the panel. The
> only way to do that while keeping everything running is to clone the
> panel drivers, one handling the old one and the other handling the new one.
> 
> All this makes me spend lots of time doing extra work, that in no way
> improves the driver. Its only for the purpose of getting arch changes
> through one tree, and driver changes through the other. And this makes
> the patches much more difficult to follow, as the related changes are in
> separate series, and there may be extra crud just to handle this separation.
> 
> So while I think it is a good habit to push the arch changes and driver
> changes separately, my question is, should that rule be followed to the
> extreme? Can I just keep all the changes in one branch if separating the
> arch and driver changes would end up with cloning files or lots of extra
> code?

Shread branches are just fine. In most cases it's possible to add new
pdata and then remove the old pdata later on with follow-up patches.
 
> Of course, I don't know what DRM maintainer thinks of merging arch
> changes through his tree, so that's also open.

No let's not go there, Linus T already complained about the conflicts
between drivers/net and arch/arm/*omap*/ code few merge windows ago.
We need to remove the driver dependencies to the arch/arm code, otherwise
the merging requires way too much work from multiple maintainers. That
does not scale well and often leads into merge errors that could have
been avoided in the first place.

Of course the real solution here is to get things moved over to DT
based booting and then we don't have any of these dependencies as the
.dts changes can get merged separately from the driver changes.

Regards,

Tony
Tomi Valkeinen - April 24, 2013, 7:56 a.m.
On 2013-04-23 20:14, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [130422 01:37]:

>> So while I think it is a good habit to push the arch changes and driver
>> changes separately, my question is, should that rule be followed to the
>> extreme? Can I just keep all the changes in one branch if separating the
>> arch and driver changes would end up with cloning files or lots of extra
>> code?
> 
> Shread branches are just fine. In most cases it's possible to add new
> pdata and then remove the old pdata later on with follow-up patches.

Yes, that's what I've been doing. But it's not possible in all cases,
and in some cases it's just really difficult/laborious.

I'll soon need to change the dss panel device model, and the only way I
can see that would allow us to keep everything running if only arch or
driver changes are merged, is to create a copy of all the omap display
drivers, and change the copy for the new dss device model.

And that's obviously a terrible way to do it.

So presuming I need to have the dss changes in separate arch and driver
series, and everything should run fine even if only the other half is
merged, then, well, I have no idea how to proceed. I'll continue looking
at this, but it's a bit frustrating to spend most of my time trying to
twist the code to accommodate the merging process, instead of making the
code work.

That said, this dss device model change should be a one time thing.
After it's done, these merging-problems should be greatly reduced.

>> Of course, I don't know what DRM maintainer thinks of merging arch
>> changes through his tree, so that's also open.
> 
> No let's not go there, Linus T already complained about the conflicts
> between drivers/net and arch/arm/*omap*/ code few merge windows ago.
> We need to remove the driver dependencies to the arch/arm code, otherwise
> the merging requires way too much work from multiple maintainers. That
> does not scale well and often leads into merge errors that could have
> been avoided in the first place.
> 
> Of course the real solution here is to get things moved over to DT
> based booting and then we don't have any of these dependencies as the
> .dts changes can get merged separately from the driver changes.

It will remove compile time dependencies, but we'll still have runtime
dependencies just like we do now.

 Tomi
Tony Lindgren - April 24, 2013, 4:50 p.m.
* Tomi Valkeinen <tomi.valkeinen@ti.com> [130424 01:01]:
> On 2013-04-23 20:14, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [130422 01:37]:
> 
> >> So while I think it is a good habit to push the arch changes and driver
> >> changes separately, my question is, should that rule be followed to the
> >> extreme? Can I just keep all the changes in one branch if separating the
> >> arch and driver changes would end up with cloning files or lots of extra
> >> code?
> > 
> > Shread branches are just fine. In most cases it's possible to add new
> > pdata and then remove the old pdata later on with follow-up patches.
> 
> Yes, that's what I've been doing. But it's not possible in all cases,
> and in some cases it's just really difficult/laborious.
> 
> I'll soon need to change the dss panel device model, and the only way I
> can see that would allow us to keep everything running if only arch or
> driver changes are merged, is to create a copy of all the omap display
> drivers, and change the copy for the new dss device model.
>
> And that's obviously a terrible way to do it.

Yes that is the case if you have to completely redo the pdata and
cannot get away by just changing the existing pdata.
 
> So presuming I need to have the dss changes in separate arch and driver
> series, and everything should run fine even if only the other half is
> merged, then, well, I have no idea how to proceed. I'll continue looking
> at this, but it's a bit frustrating to spend most of my time trying to
> twist the code to accommodate the merging process, instead of making the
> code work.
>
> That said, this dss device model change should be a one time thing.
> After it's done, these merging-problems should be greatly reduced.

Right, if it's more complex than just changing the pdata then what you've
been doing is probably the best approach. Just needs to be done earlier :)
 
> >> Of course, I don't know what DRM maintainer thinks of merging arch
> >> changes through his tree, so that's also open.
> > 
> > No let's not go there, Linus T already complained about the conflicts
> > between drivers/net and arch/arm/*omap*/ code few merge windows ago.
> > We need to remove the driver dependencies to the arch/arm code, otherwise
> > the merging requires way too much work from multiple maintainers. That
> > does not scale well and often leads into merge errors that could have
> > been avoided in the first place.
> > 
> > Of course the real solution here is to get things moved over to DT
> > based booting and then we don't have any of these dependencies as the
> > .dts changes can get merged separately from the driver changes.
> 
> It will remove compile time dependencies, but we'll still have runtime
> dependencies just like we do now.

Only for adding new features. If the new features are missing from the
.dts changes, the driver should still work with limited features. The
idea is to support DT bindings in the long term.

Regards,

Tony
Tomi Valkeinen - June 3, 2013, 12:20 p.m.
Hi,

On 19/04/13 21:45, Olof Johansson wrote:
> Hi,
> 
> On Wed, Apr 17, 2013 at 08:39:37PM -0700, Tony Lindgren wrote:
>> The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
>>
>>   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/dss-signed
> 
> 
> Merged, but not happy about it.
> 
> As mentioned on IRC, I was going to let this one be until 3.11, but it sounds
> like it will cause regressions in DSS if we don't merge it.
> 
> This is an indication that the work wasn't done right on the DSS rework.
> Ideally the old configurations through platform_data should have been left in
> for a release to give the boards a window to convert over without regressing
> functionality. Tomi, please don't do it this way in the future since it's
> painful for everybody to deal with.

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
Tomi Valkeinen - June 13, 2013, 7:56 a.m.
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.

 tomi

> 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
> 
>
Tony Lindgren - June 13, 2013, 10:54 a.m.
* 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
> > 
> > 
> 
>