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

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 1551 bytes --]

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.

>> 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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]