On Thursday 12 December 2013 01:00 PM, Tomi Valkeinen wrote:
On 2013-12-12 01:10, Laurent Pinchart wrote:
Hi Tomi,
On Wednesday 04 December 2013 14:28:32 Tomi Valkeinen wrote:
omapdss driver uses a omapdss platform device to pass platform specific
function pointers and DSS hardware version from the arch code to the
driver. This device is needed also when booting with DT.
This patch adds omapdss_init_of() function, called from board-generic at
init time, which creates the omapdss device.
Is this a temporary solution that you plan to later replace with DT-only
device instantiation ?
It's a long term task to remove the "virtual" omapdss device. Removing
the platform data that we pass has been very difficult.
Even if we remove the platform data, what would be the right place to
register the drm, fb and vout devices? We need to make sure their
drivers are probed only after omapdss is initialised.
For example, we need to get the OMAP revision to know which OMAP DSS
hardware we have. We can't get that information from the DSS hardware
(thank you, HW designers! ;).
Another is DSI pin muxing. I think we need a new pinmuxing driver for
that, or maybe change pinmux-single quite a bit. The DSI pinmuxing is
very simple, but the register fields are varying lengths and at varying
positions, so pinmux-single doesn't work for it.
I have seen other OMAP drivers passing control module register info to
their DT node. Instead of having a pinmux driver for a single register,
we might want to consider just passing the control module register, and
take care of the reg fields and masks in the OMAP DSI driver itself.
The parsing of the DSI pins from DT, however, can be kept generic.
Archit
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
