Re: Moving board patches from DSS2 to linux-omap

[Mike Rapoport <mike@compulab.co.il>]

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.