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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
