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. Current dss driver: ------------------- 1. Omapdss platform driver - initialises necessary Ips dss, dispc. - also initialises Ips like sdi, dsi, venc, rfbi - creates a custom bus and registers the display devices/drivers connected on the board to the custom bus. 2. Suspend/resume of omapdss - in turn sends suspend/resume calls for each of the display devices registered to it. Proposed change: ---------------- Omapdss platform driver - initialises necessary Ips dss, dispc. - continues to have a custom bus and registers the display devices and drivers connected on the board to the custom bus. - continues to handle suspend/resume of the display devices registerd to the custom bus. Dsi platform driver - initialises DSI IP alone - handles suspend/resume as a platform driver. The implementation gets tricky on how to know that the panels connected to it is also in suspended/resumed state. SDI platform driver - initialises SDI IP alone - handles suspend/resume as a platform driver. The implementation gets tricky on how to know that the panels connected to it is also in suspended/resumed state. RFBI platform driver - initialises RFBI IP alone - handles suspend/resume as a platform driver. The implementation gets tricky on how to know that the panels connected to it is also in suspended/resumed state. DPI platform driver - initialises DPI IP - should also take care of dsi pll inits from the dsi platform driver. - handles suspend/resume as a platform driver. The implementation gets tricky on how to know that the panels connected to it is also in suspended/resumed state. Regards, Senthil-- 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
