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. 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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
