[RFC PATCH 1/6] media: mc: Implement shared media graph

Michael Riesch michael.riesch at collabora.com
Fri Jul 10 13:42:50 PDT 2026


Hi Paul,

On 6/25/26 10:23, Paul Elder wrote:
> [...]
>>> +// TODO figure out locking for when multiple drivers touch the media graph;
>>> +// maybe macros for shared versions?
>>
>> Do you mean for when drivers are trying to change link state directly?
> 
> I meant for all the operations that act on media device. I'm not sure what
> there is because I didn't really find anything significant, and I found some
> action point from some meeting notes somewhere that said "deprecate media_ops"
> (not assigned to me) so...

Oh yes, for some reason this ball ended up in our side of the field. But
actually I think the media_ops are not much of an issue, as you don't
set them when you create the shared media device. Problem solved, right?

> If there aren't any then it's a non-issue, but if there are then I was
> wondering if we need to return the shared media device to the driver (as
> opposed to a non-shared regular media device) and use shared versions of media
> device functions that have locking.

+1
I would recommend that just to be on the safe side. And I think I would
make the shared media device an opaque pointer to make sure that there
won't be any monkey business.

Thanks and best regards,
Michael

> 
>>
>>> +struct media_device_shared {
>>> +       struct media_device mdev;
>>> +       struct list_head members;
>>> +       struct list_head links;
>>> +
>>> +       struct list_head list;
>>> +       struct kref refcount;
>>> +
>>> +       struct device *removed_device;
>>> +};
>>> +[...]



More information about the Linux-rockchip mailing list