Re: [PATCH v2 09/23] OMAPDSS: Create links between managers, outputs and devices

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

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

On Fri, 2012-08-31 at 17:45 +0300, Tomi Valkeinen wrote:

> So I'm not really against having the enum. It just would've been neat to
> have the output type and instance number encoded into this enum, so that
> it'd be easy to extract either one. But that kinda ruins the possibility
> to use it in a bit mask.

Hmm, this is just a non-finished idea (and it's late Friday... =) that
came to my mind:

I had a brief look at TRMs for different OMAPs (omap4/5/6), and it looks
like the maximum output options for one manager is 4 (LCD2 on omap4460).
Usually there are just 2 or 3.

So, we could trust that the above holds and do this so that we use a u32
field to hold four 8 bit output options. In 8 bits we can combine two
values from 0 to 15. 15 should be more than enough for output display
types and output instances.

Then with helpers like these:

/* second DSI instance */
#define DSI1 ((1 << 4) | DISPLAY_TYPE_DSI)
/* first DPI instance */
#define DPI0 ((0 << 4) | DISPLAY_TYPE_DPI)

an example output options for a manager that can be connected to DSI1
and DPI0 could be:

(DSI1 << 8) | (DPI0)

This could be parsed with a for loop, going though the 4 bytes of the
u32 value. This would allow us to avoid managing a real list, and we
could extract the instance and the type from the value. Of course we
could also extend the field to u64 to hold 8 outputs if need be.

Whether this would be worth it compared to simple bitmask, I'm not sure
=). Depends how much we need to extract the ID and type.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]