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
Attachment:
signature.asc
Description: OpenPGP digital signature
