On Wed, 2010-06-16 at 12:52 +0200, ext Guruswamy, Senthilvadivu wrote: > Hi, > > When I started with RFC patch "DSS: Movement of base addr, silicon specific > data from driver to platform_device", I see a lot of encapsulation of OMAP > DSS IPs into the "omapdss" driver. > > The previous RFC patch would only be good enough to handle base address and > IRQ for multi-omap. But it won't address the PRCM power management handled > in HWMOD APIs. > > The encapsulation of all the DSS IPs like RFBI, DSI, SDI, VENC into omapdss > driver would prevent these drivers being handled from the platform database. > > For Eg: > HWMOD adaptation to DSS would not be possible unless these libraries are made > as platform drivers. > HWMOD would provide dynamic usage of multi-omap data like base addr,irq. > HWMOD would also manage the PRCM clocks needed for the dss. > > I would make an RFC patch by introducing these IPs as platform drivers which > would comply and ease for HWMOD adpatation. > > Before I go ahead make the changes in the code, I would like to get opinions > on this proposed changes. I haven't looked at how HWMODs work, but I don't see any downsides to having the DSS HW modules as platform devices, if that is required. But the interface modules (DSI/DPI/RFBI/SDI) will still be tightly connected to the core DSS module, even if they are separate drivers. I'm not sure what complexities this may bring. This also raises the question that should the interface modules each have a bus of their own? This is something I've pondered for a long time, and sounds to me to be a cleaner architecture, but it may be a bigger change. Tomi -- 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
