Laurent Pinchart wrote:
> Hi Hans,
Hi,
> On Saturday 24 July 2010 14:18:11 Hans Verkuil wrote:
>> On Wednesday 21 July 2010 16:35:28 Laurent Pinchart wrote:
...
>>> +
>>> +#define MEDIA_LINK_FLAG_ACTIVE (1 << 0)
>>> +#define MEDIA_LINK_FLAG_IMMUTABLE (1 << 1)
>>> +
>>> +#define MEDIA_PAD_DIR_INPUT 1
>>> +#define MEDIA_PAD_DIR_OUTPUT 2
>>> +
>>> +struct media_entity_link {
>>> + struct media_entity_pad *source;/* Source pad */
>>> + struct media_entity_pad *sink; /* Sink pad */
>>> + struct media_entity_link *other;/* Link in the reverse direction */
>>> + u32 flags; /* Link flags (MEDIA_LINK_FLAG_*) */
>>> +};
>>> +
>>> +struct media_entity_pad {
>>> + struct media_entity *entity; /* Entity this pad belongs to */
>>> + u32 direction; /* Pad direction (MEDIA_PAD_DIR_*) */
>>> + u8 index; /* Pad index in the entity pads array */
>>
>> We can use bitfields for direction and index. That way we can also easily
>> add other flags/attributes.
>
> You proposed to merge the direction field into a new flags field, I suppose
> that should be done here too for consistency. Having 16 flags might be a bit
> low though, 32 would be better. If you want to keep 16 bits for now, maybe we
> should have 2 reserved __u32 instead of one.
I think we could have some more reserved fields than just one or two.
Nothing can replace reserved fields when you do need them.
Think of supporting dynamic format changes across a streaming pipeline,
for example. That might not happen ever, but once the hardware support
is there it might be something to think about.
Haven't exactly heard of problems of having too many of the reserved
fields, too few, yes! :-)
Regards,
--
Sakari Ailus
sakari.ailus@xxxxxxxxxxxxxxxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
