Hi Laurent, On Fri, Feb 22, 2019 at 02:18:11PM +0200, Laurent Pinchart wrote: > Hi Jacopo, > > On Mon, Feb 18, 2019 at 10:21:07AM +0100, Jacopo Mondi wrote: > > On Tue, Jan 22, 2019 at 05:20:30PM +0200, Laurent Pinchart wrote: > > > On Tue, Jan 22, 2019 at 05:15:06PM +0200, Sakari Ailus wrote: > > >> On Wed, Jan 16, 2019 at 12:57:43AM +0200, Laurent Pinchart wrote: > > >>>> > > >>>> This way the pads are always passed to the has_route() op sink pad first. > > >>>> Makes sense. > > >>> > > >>> Is there anything in the API that mandates one pad to be a sink and the > > >>> other pad to the a source ? I had designed the operation to allow > > >>> sink-sink and source-source connections to be checked too. > > >> > > >> Do you have a use case in mind for sink--sink or source--source routes? The > > >> routes are about flows of data, so I'd presume only source--sink or > > >> sink--source routes are meaningful. > > >> > > >> If you did, then the driver would have to handle that by itself. This still > > >> simplifies the implementation for drivers that do not. > > > > > > I don't have use cases for such routes, but we use the has_route > > > operation when traversing pipelines, and at that point we need to get > > > all the internally connected pads. In another patch in this series you > > > implement a helper function that handles this, but its implementation > > > isn't complete. I explained in my review of that patch that I fear a > > > correct generic implementation would become quite complex, while the > > > complexity should be easy to handle on the driver side as the code can > > > then be specialized for the case at hand. > > > > > > > As a compromise, in v3 I'm thinking of maintaining support for the > > most common case of two sources connected to the same sink, as > > Sakari's patch does, but let more complex cases be handled by the > > driver implementation of has_route(). > > > > Ack? > > I fear this will be confusing for subdevs, as they would have to > implement part of the operation. > > Could it be that the subdev has_route operation isn't the best API for > the job, if it gets that complex ? I wonder if it would be easier to > create another operation that takes a pad index as argument, and returns > the list of pads (possibly as a bitmask ?) or connected pads. > media_entity_has_route() could easily be implemented on top of that, and > these new semantics may be easier for subdevs to implement. > I see, but if subdevs can easily elaborate that list, they could as well easily check if the pad provided as argument is on that list. > > >>> If your goal is to simplify the implementation of the .has_route() > > >>> operation in drivers, I would instead sort pad0 and pad1 by value. > > >> > > >> That'd be another option to make the order deterministic for the driver. > > >> I'm fine with that as well. > > > > In v3 I have taken both suggestions in: try the "sink then source" order > > first, then order by index in case the pads are of the same time. This > > needs to be documented in has_route() operation definition though. > > > > Would that be fine with you? > > I think that's the worst of both worlds from a subdev point of view :-) > Possibly :) Should we drop completely the sink-source ordering in favour of ordering by value, and drop [15/30] that adds support for trivial indirect routes? Let's reach consensus so I could send v3. Thanks j > > >>>> Signed-off-by: Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx> > > >>>> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@xxxxxxxxxxxx> > > >>>> --- > > >>>> drivers/media/media-entity.c | 4 ++++ > > >>>> 1 file changed, 4 insertions(+) > > >>>> > > >>>> diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c > > >>>> index 3c0e7425c8983b45..33f00e35ccd92c6f 100644 > > >>>> --- a/drivers/media/media-entity.c > > >>>> +++ b/drivers/media/media-entity.c > > >>>> @@ -249,6 +249,10 @@ bool media_entity_has_route(struct media_entity *entity, unsigned int pad0, > > >>>> if (!entity->ops || !entity->ops->has_route) > > >>>> return true; > > >>>> > > >>>> + if (entity->pads[pad0].flags & MEDIA_PAD_FL_SOURCE > > >>>> + && entity->pads[pad1].flags & MEDIA_PAD_FL_SINK) > > >>>> + swap(pad0, pad1); > > >>>> + > > >>>> return entity->ops->has_route(entity, pad0, pad1); > > >>>> } > > >>>> EXPORT_SYMBOL_GPL(media_entity_has_route); > > -- > Regards, > > Laurent Pinchart
Attachment:
signature.asc
Description: PGP signature
