| Message ID | 20130418033936.GC10155@atomide.com |
|---|---|
| State | New |
| Headers | show |
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
* 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
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
* 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
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
* 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
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
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 > >
* 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 > > > > > >
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