omap dss board clean-up for v3.10 merge window
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
Hi,
Quoted 7 lines · Tony Lindgren
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-omaptags/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
Quoted 14 lines · Olof Johansson
Hi,
Quoted 7 lines · Tony Lindgren
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-omaptags/omap-for-v3.10/dss-signedMerged, but not happy about it.
Quoted 8 lines
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_datashould 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.
Quoted 4 lines
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
Quoted 5 lines · Olof Johansson
Hi,
Quoted 2 lines · Tony Lindgren
The following changes since commit
07961ac7c0ee8b546658717034fe692fd12eefa9:
Quoted 8 lines
Quoted 5 lines
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-omaptags/omap-for-v3.10/dss-signedMerged, but not happy about it.
Thanks.
Quoted 2 lines
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.
Quoted 5 lines
This is an indication that the work wasn't done right on the DSS rework. Ideally the old configurations through
platform_datashould 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130422/a5bb66d4/attachment.sig>
Quoted 52 lines · Tomi Valkeinen
Quoted 5 lines · Olof Johansson
Hi,
Quoted 2 lines · Tony Lindgren
The following changes since commit
07961ac7c0ee8b546658717034fe692fd12eefa9:Quoted 8 lines
Quoted 5 lines
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-omaptags/omap-for-v3.10/dss-signedMerged, but not happy about it.
Thanks.
Quoted 2 lines
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.
Quoted 5 lines
This is an indication that the work wasn't done right on the DSS rework. Ideally the old configurations through
platform_datashould 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.
Quoted 5 lines
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.
Quoted 2 lines
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
Quoted 10 lines · Tony Lindgren
Quoted 5 lines · Tomi Valkeinen
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.
Quoted 10 lines
Quoted 2 lines
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/netandarch/arm/*omap*/code few merge windows ago. We need to remove the driver dependencies to thearch/armcode, 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.
Quoted 3 lines
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130424/dfaf82bb/attachment.sig>
Quoted 15 lines · Tomi Valkeinen
Quoted 10 lines · Tony Lindgren
Quoted 5 lines · Tomi Valkeinen
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.
Quoted 6 lines
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.
Quoted 9 lines
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 :)
Quoted 10 lines
Quoted 10 lines
Quoted 2 lines
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/netandarch/arm/*omap*/code few merge windows ago. We need to remove the driver dependencies to thearch/armcode, 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.
Quoted 6 lines
Quoted 3 lines
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
Hi,
Quoted 14 lines · Olof Johansson
Hi,
Quoted 7 lines · Tony Lindgren
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-omaptags/omap-for-v3.10/dss-signedMerged, but not happy about it.
Quoted 8 lines
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_datashould 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130603/d2027662/attachment.sig>
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
Quoted 40 lines
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).
Quoted 7 lines
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130613/5bbd01d1/attachment.sig>
Quoted 7 lines · Tomi Valkeinen
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/armchanges.
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
Quoted 49 lines
Quoted 47 lines
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