Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information

On 2013-12-13 05:24, Laurent Pinchart wrote:

Right. The real question is whether the DSI or HDMI IPs can be used in a 
system without the DSS core. If not, it might make sense to just merge the 
drivers into a single module (of course with a clear interface between the 
different parts to avoid spaghetti code).

The drivers are already in single kernel module, omapdss.ko.

The HDMI IP is used on another SoC, without DSS. They have their own
display architecture. DSI IP might need some small modifications to work
without DSS, but not much. It doesn't have any strict DSS/DISPC
dependencies.

Given that the DSS core has a set of registers not dedicated to any of the 
submodules I believe it should be represented by a device. The omapdss driver 
thus doesn't look virtual to me, it supports a real piece of hardware.

As noted in another mail, dss_core and omapdss devices are different
things. dss_core is not virtual, omapdss is.

quoted

But then, I feel that they are quite independent and probably should be
separate devices.

Even if they're separate devices they could be instantiated by DSS core based 
on DT nodes. I'm not sure whether that's the best idea, but it might be worth 
thinking about it.

What would be the difference to the one in this series? In this series,
the submodules are instantiated automatically by the driver framework.
The only difference I see is that the submodule devices would
appear/disappear dynamically, but... what would be the benefit?

 Tomi