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:
signature.asc
Description: This is a digitally signed message part
