Tomi Valkeinen wrote: > Hi, > > As discussed previously, board file changes in DSS2 tree cause conflicts > with linux-omap easily. There are currently three board file patches in > DSS2's for-next branch: > > 722a97e4594b2041bbf18d95a913ba6dfaca87f2 omap3: cm-t35: add DSS2 display support > 7a56267e775e469c64521179ccc958c8bb661dbf OMAP: AM3517: Enable DSS2 for AM3517EVM board > 40e4e67c6dabcb9897b6823cce2297d6c3e78bbd OMAP: Enable DSS2 for OMAP3EVM board > > The problem here is of course that DSS2 tree may contain unmerged panel > drivers, and those board file changes try to use these new panel > drivers. Well, the panel drivers are referenced by name in the board files, so merging board file changes through linux-omap tree should not create merge conflicts and compile problems. There just won't be display until DSS2 tree is merged. Or am I missing something? > Now, I don't think there's a perfect solution for this, but I think a > working solution would be to put all board file changes to linux-omap > tree (with the exception of some rare changes that don't compile without > new DSS2 patches), but leave the kernel config unchanged. > > This way the board file contains references to new panel drivers, but as > DSS2 nor the panel drivers are enabled in the Kconfig, the board file > code is not used and everything should work as before. > > Then either I can have Kconfig patches in my tree, which are less likely > to conflict, or the Kconfig changes can be done after both linux-omap > and dss2 patches have been merged. > > How does this sound? > > Tomi > > Ps. I haven't actually tried those board file patches on top of > linux-omap, but I don't see anything there that would cause compilation > to fail. > > -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
