All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacopo Mondi <jacopo@jmondi.org>
To: Daniel Scally <djrscally@gmail.com>
Cc: linux-media@vger.kernel.org, linux-rockchip@lists.infradead.org,
	dafna@fastmail.com, heiko@sntech.de, foss+kernel@0leil.net
Subject: Re: [PATCH] media: rkisp1: Don't create data links for non-sensor subdevs
Date: Wed, 8 Jun 2022 17:34:16 +0200	[thread overview]
Message-ID: <20220608153416.ciwiwg4tbfyetprh@uno.localdomain> (raw)
In-Reply-To: <c328e7e6-8d22-2480-38f0-f05528c548dc@gmail.com>

Hi Dan,

On Wed, Jun 08, 2022 at 03:25:36PM +0100, Daniel Scally wrote:
> Hi Jacopo
>
> On 07/06/2022 17:41, Jacopo Mondi wrote:
> > Hi Dan
> >
> > On Mon, Jun 06, 2022 at 11:51:49PM +0100, Daniel Scally wrote:
> >> With the introduction of ancillary links, not all subdevs linked to
> >> the ISP's v4l2_dev necessarily represent sensors / bridges. Check the
> >> function for the subdevs and skip any that represent lens or flash
> >> controllers before creating data links.
> >>
> >> Signed-off-by: Daniel Scally <djrscally@gmail.com>
> >> ---
> >>
> >> This should fix the issues that have been noticed, but perhaps a new flag like
> >> MEDIA_ENT_FL_HAS_SOURCE or something would be a better way to denote subdevs
> >> that need data links?
> >>
> > I agree this a bit fragile...
> >
> > I noticed ancillary links are only created for subdev notifiers,
> > which have a populated 'sd' and consequentially an entity. Could an
> > helper that walks the links of the notifier's subdev links and checks
> > if the subdev at hand is already linked, help ? Maybe with an optional
> > set of link flags to match on ?

This is actually a mess, as the list of links to be walked is the list
of the sensor's notifier, not the one of the rkisp1. Bad advice,
sorry..

>
>
> Or maybe just check if the subdev's notifier is the same as the rkisp1's
> notifier? Like:
>
>
> if(sd->notifier!= &rkisp1->notifier)

Not all subdevs will have a notifier, won't they ? In facts only
sensor that registers a notifier for their connected lenses/flashes
will have one.

Anyway, I think the issue here is that we walk the list of all subdevs
registered to the root notifier's v4l2_dev.

All async subdevices matched in the notifiers chain will end up being
registered to the root notifier's v4l2_dev, hence also lenses and
flashes will appear in this list.

        list_for_each_entry(sd, &rkisp1->v4l2_dev.subdevs, list) {

        }

Can't we do like the CIO2 does, by walking the list of async subdevs
registered to the root notifier only ? This list should not include
lenses and flashes if I'm not mistaken.

	list_for_each_entry(asd, &rkisp1->notifier.asd_list, asd_list) {

        }

You can cast the struct v4l2_async_subdev back to the wrapping struct
rkisp1_sensor_async and from there get the sd to create the links on.
Could this work in your opinion ? I'm sorry I can't test it right
away...



> continue
> That's a bit less clunky than both other solutions I think
> >
> >
> >>  drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 4 ++++
> >>  1 file changed, 4 insertions(+)
> >>
> >> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> >> index 3f5cfa7eb937..e90f0216cb06 100644
> >> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> >> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> >> @@ -134,6 +134,10 @@ static int rkisp1_create_links(struct rkisp1_device *rkisp1)
> >>  		    sd == &rkisp1->resizer_devs[RKISP1_SELFPATH].sd)
> >>  			continue;
> >>
> >> +		if (sd->entity.function == MEDIA_ENT_F_LENS ||
> >> +		    sd->entity.function == MEDIA_ENT_F_FLASH)
> >> +			continue;
> >> +
> >>  		ret = media_entity_get_fwnode_pad(&sd->entity, sd->fwnode,
> >>  						  MEDIA_PAD_FL_SOURCE);
> >>  		if (ret < 0) {
> >> --
> >> 2.25.1
> >>

WARNING: multiple messages have this Message-ID (diff)
From: Jacopo Mondi <jacopo@jmondi.org>
To: Daniel Scally <djrscally@gmail.com>
Cc: linux-media@vger.kernel.org, linux-rockchip@lists.infradead.org,
	dafna@fastmail.com, heiko@sntech.de, foss+kernel@0leil.net
Subject: Re: [PATCH] media: rkisp1: Don't create data links for non-sensor subdevs
Date: Wed, 8 Jun 2022 17:34:16 +0200	[thread overview]
Message-ID: <20220608153416.ciwiwg4tbfyetprh@uno.localdomain> (raw)
In-Reply-To: <c328e7e6-8d22-2480-38f0-f05528c548dc@gmail.com>

Hi Dan,

On Wed, Jun 08, 2022 at 03:25:36PM +0100, Daniel Scally wrote:
> Hi Jacopo
>
> On 07/06/2022 17:41, Jacopo Mondi wrote:
> > Hi Dan
> >
> > On Mon, Jun 06, 2022 at 11:51:49PM +0100, Daniel Scally wrote:
> >> With the introduction of ancillary links, not all subdevs linked to
> >> the ISP's v4l2_dev necessarily represent sensors / bridges. Check the
> >> function for the subdevs and skip any that represent lens or flash
> >> controllers before creating data links.
> >>
> >> Signed-off-by: Daniel Scally <djrscally@gmail.com>
> >> ---
> >>
> >> This should fix the issues that have been noticed, but perhaps a new flag like
> >> MEDIA_ENT_FL_HAS_SOURCE or something would be a better way to denote subdevs
> >> that need data links?
> >>
> > I agree this a bit fragile...
> >
> > I noticed ancillary links are only created for subdev notifiers,
> > which have a populated 'sd' and consequentially an entity. Could an
> > helper that walks the links of the notifier's subdev links and checks
> > if the subdev at hand is already linked, help ? Maybe with an optional
> > set of link flags to match on ?

This is actually a mess, as the list of links to be walked is the list
of the sensor's notifier, not the one of the rkisp1. Bad advice,
sorry..

>
>
> Or maybe just check if the subdev's notifier is the same as the rkisp1's
> notifier? Like:
>
>
> if(sd->notifier!= &rkisp1->notifier)

Not all subdevs will have a notifier, won't they ? In facts only
sensor that registers a notifier for their connected lenses/flashes
will have one.

Anyway, I think the issue here is that we walk the list of all subdevs
registered to the root notifier's v4l2_dev.

All async subdevices matched in the notifiers chain will end up being
registered to the root notifier's v4l2_dev, hence also lenses and
flashes will appear in this list.

        list_for_each_entry(sd, &rkisp1->v4l2_dev.subdevs, list) {

        }

Can't we do like the CIO2 does, by walking the list of async subdevs
registered to the root notifier only ? This list should not include
lenses and flashes if I'm not mistaken.

	list_for_each_entry(asd, &rkisp1->notifier.asd_list, asd_list) {

        }

You can cast the struct v4l2_async_subdev back to the wrapping struct
rkisp1_sensor_async and from there get the sd to create the links on.
Could this work in your opinion ? I'm sorry I can't test it right
away...



> continue
> That's a bit less clunky than both other solutions I think
> >
> >
> >>  drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 4 ++++
> >>  1 file changed, 4 insertions(+)
> >>
> >> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> >> index 3f5cfa7eb937..e90f0216cb06 100644
> >> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> >> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> >> @@ -134,6 +134,10 @@ static int rkisp1_create_links(struct rkisp1_device *rkisp1)
> >>  		    sd == &rkisp1->resizer_devs[RKISP1_SELFPATH].sd)
> >>  			continue;
> >>
> >> +		if (sd->entity.function == MEDIA_ENT_F_LENS ||
> >> +		    sd->entity.function == MEDIA_ENT_F_FLASH)
> >> +			continue;
> >> +
> >>  		ret = media_entity_get_fwnode_pad(&sd->entity, sd->fwnode,
> >>  						  MEDIA_PAD_FL_SOURCE);
> >>  		if (ret < 0) {
> >> --
> >> 2.25.1
> >>

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  reply	other threads:[~2022-06-08 15:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-06 22:51 [PATCH] media: rkisp1: Don't create data links for non-sensor subdevs Daniel Scally
2022-06-06 22:51 ` Daniel Scally
2022-06-07 16:41 ` Jacopo Mondi
2022-06-07 16:41   ` Jacopo Mondi
2022-06-08 14:25   ` Daniel Scally
2022-06-08 14:25     ` Daniel Scally
2022-06-08 15:34     ` Jacopo Mondi [this message]
2022-06-08 15:34       ` Jacopo Mondi
2022-06-08 20:43       ` Daniel Scally
2022-06-08 20:43         ` Daniel Scally

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220608153416.ciwiwg4tbfyetprh@uno.localdomain \
    --to=jacopo@jmondi.org \
    --cc=dafna@fastmail.com \
    --cc=djrscally@gmail.com \
    --cc=foss+kernel@0leil.net \
    --cc=heiko@sntech.de \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.