HI Laurent, On Tue, Mar 05, 2019 at 10:04:58PM +0200, Laurent Pinchart wrote: > Hi Jacopo, > > On Mon, Mar 04, 2019 at 01:35:36PM +0100, Jacopo Mondi wrote: > > On Fri, Feb 22, 2019 at 02:18:11PM +0200, Laurent Pinchart wrote: > > > 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. > > Possibly. In any case, if we keep this operation as-is, I wouldn't try > to split the logic between the subdev drivers and the core, that would > be asking for trouble. If it gets too complex to implement for subdev > drivers, then we need a different operation with a different logic in > the subdev API, and a helper that wraps around it. In v3 I have removed support for indirect routes from the framework part. It's all on the subdevice driver for now. > > > >>>>> 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. > > I would certainly drop 15/30, and I don't think ordering by value would > help subdev drivers much. Yes, but sorting by index makes it easier to deal with the sink-sink and source-source use cases, if the subdevice supports indirect routes. I have dropped 15/30 and specified pads are passed by index in 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
