From: Janusz Krzysztofik <jmkrzyszt@gmail.com>
To: Jacopo Mondi <jacopo+renesas@jmondi.org>,
mchehab@kernel.org, sakari.ailus@linux.intel.com,
laurent.pinchart@ideasonboard.com,
Hans Verkuil <hverkuil-cisco@xs4all.nl>
Cc: niklas.soderlund+renesas@ragnatech.se,
kieran.bingham@ideasonboard.com, dave.stevenson@raspberrypi.com,
hyun.kwon@xilinx.com, robert.jarzmik@free.fr,
linux-media@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
Janusz Krzysztofik <jmkrzyszt@gmail.com>
Subject: Re: [PATCH v6 1/9] media: v4l2-subdev: Introduce [get|set]_mbus_config pad ops
Date: Sun, 19 Jul 2020 13:18:44 +0200 [thread overview]
Message-ID: <4043309.ejJDZkT8p0@z50> (raw)
In-Reply-To: <750089f9-0e7f-3b2a-ec85-38452cb64fa1@xs4all.nl>
Hi Hans,
On Wednesday, July 15, 2020 5:08:05 P.M. CEST Hans Verkuil wrote:
> On 14/07/2020 15:58, Jacopo Mondi wrote:
> > Introduce two new pad operations to allow retrieving and configuring the
> > media bus parameters on a subdevice pad.
> >
> > The newly introduced operations aims to replace the s/g_mbus_config video
> > operations, which have been on their way for deprecation since a long
> > time.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > ---
> > include/media/v4l2-subdev.h | 27 +++++++++++++++++++++++++++
> > 1 file changed, 27 insertions(+)
> >
> > diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
> > index f7fe78a6f65a..d8b9d5735307 100644
> > --- a/include/media/v4l2-subdev.h
> > +++ b/include/media/v4l2-subdev.h
> > @@ -670,6 +670,29 @@ struct v4l2_subdev_pad_config {
> > *
> > * @set_frame_desc: set the low level media bus frame parameters, @fd array
> > * may be adjusted by the subdev driver to device capabilities.
> > + *
> > + * @get_mbus_config: get the media bus configuration of a remote sub-device.
> > + * The media bus configuration is usually retrieved from the
> > + * firmware interface at sub-device probe time, immediately
> > + * applied to the hardware and eventually adjusted by the
> > + * driver. Remote sub-devices (usually video receivers) shall
> > + * use this operation to query the transmitting end bus
> > + * configuration in order to adjust their own one accordingly.
> > + * Callers should make sure they get the most up-to-date as
> > + * possible configuration from the remote end, likely calling
> > + * this operation as close as possible to stream on time. The
> > + * operation shall fail if the pad index it has been called on
> > + * is not valid.
> > + *
> > + * @set_mbus_config: set the media bus configuration of a remote sub-device.
> > + * This operations is intended to allow, in combination with
> > + * the get_mbus_config operation, the negotiation of media bus
> > + * configuration parameters between media sub-devices. The
> > + * operation shall not fail if the requested configuration is
> > + * not supported, but the driver shall update the content of
> > + * the %config argument to reflect what has been actually
> > + * applied to the hardware. The operation shall fail if the
> > + * pad index it has been called on is not valid.
> > */
>
> Hm, I'd hoped I could merge this, but I think include/media/v4l2-mediabus.h
> also needs to be updated.
>
> So the old g_mbus_config returned all supported configurations, while the
> new get_mbus_config returns the *current* configuration.
>
> That's fine, but that means that the meaning of the struct v4l2_mbus_config
> flags field changes as well and several comments in v4l2-mediabus.h need to
> be updated to reflect this.
>
> E.g. instead of '/* How many lanes the client can use */' it becomes
> '/* How many lanes the client uses */'.
>
> Frankly, these flags can be redesigned now since you only need a single
> e.g. V4L2_MBUS_HSYNC_ACTIVE_HIGH flag since if it is not set, then that
> means ACTIVE_LOW. And since it is now a single bit, it is also easy to
> make each flag a bit field.
Even if this makes sense for .get_mbus_config() which returns current
configuration, how about keeping the old semantics of the flags and let
.set_mbus_config() accept a potentially incomplete or redundant set of flags
specified by the caller to select a supported configuration from? That approach
was actually proposed before by Jacopo when he argued against my suggestion to
add a wrapper with a check for mutually exclusive flags[1], and I found it a
very good alternative to my other rejected suggestion of adding TRY support.
[1] https://www.spinics.net/lists/linux-media/msg171878.html
Thanks,
Janusz
>
> The CSI2 lanes/channels can just be a bit field for the number of lanes/channels,
> which is much easier to read. I strongly recommend making this change at the minimum.
>
> Now all this can be done in a follow-up series, but the v4l2-mediabus.h
> definitely needs to be updated to reflect the new code.
>
> This can be done as a v6 5.5/9 patch (since it should come right after the
> g/s_mbus_config removal).
>
> Regards,
>
> Hans
>
> > struct v4l2_subdev_pad_ops {
> > int (*init_cfg)(struct v4l2_subdev *sd,
> > @@ -710,6 +733,10 @@ struct v4l2_subdev_pad_ops {
> > struct v4l2_mbus_frame_desc *fd);
> > int (*set_frame_desc)(struct v4l2_subdev *sd, unsigned int pad,
> > struct v4l2_mbus_frame_desc *fd);
> > + int (*get_mbus_config)(struct v4l2_subdev *sd, unsigned int pad,
> > + struct v4l2_mbus_config *config);
> > + int (*set_mbus_config)(struct v4l2_subdev *sd, unsigned int pad,
> > + struct v4l2_mbus_config *config);
> > };
> >
> > /**
> >
>
>
next prev parent reply other threads:[~2020-07-19 11:18 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-14 13:58 [PATCH v6 0/9] v4l2-subdev: Introduce [g|s]et_mbus_format pad op Jacopo Mondi
2020-07-14 13:58 ` [PATCH v6 1/9] media: v4l2-subdev: Introduce [get|set]_mbus_config pad ops Jacopo Mondi
2020-07-15 15:08 ` Hans Verkuil
2020-07-19 11:18 ` Janusz Krzysztofik [this message]
2020-07-20 8:48 ` Hans Verkuil
2020-07-20 18:44 ` Janusz Krzysztofik
2020-07-21 7:46 ` Hans Verkuil
2020-07-29 7:35 ` Robert Jarzmik
2020-07-14 13:58 ` [PATCH v6 2/9] media: i2c: Use the new get_mbus_config pad op Jacopo Mondi
2020-07-14 13:58 ` [PATCH v6 3/9] media: i2c: ov6650: Use new [get|set]_mbus_config ops Jacopo Mondi
2020-07-14 13:58 ` [PATCH v6 4/9] media: pxa_camera: Use the new set_mbus_config op Jacopo Mondi
2020-07-14 13:58 ` [PATCH v6 5/9] media: v4l2-subdev: Remove [s|g]_mbus_config video ops Jacopo Mondi
2020-07-14 13:58 ` [PATCH v6 6/9] staging: media: imx: Update TODO entry Jacopo Mondi
2020-07-14 13:58 ` [PATCH v6 7/9] media: i2c: adv748x: Adjust TXA data lanes number Jacopo Mondi
2020-07-14 13:58 ` [PATCH v6 8/9] media: i2c: adv748x: Implement get_mbus_config Jacopo Mondi
2020-07-14 13:58 ` [PATCH v6 9/9] media: rcar-csi2: Negotiate data lanes number Jacopo Mondi
2020-07-15 6:55 ` Niklas Söderlund
2020-07-15 7:13 ` Jacopo Mondi
2020-07-15 8:20 ` Niklas Söderlund
2020-07-15 14:38 ` [PATCH v6.1 " Jacopo Mondi
2020-07-15 15:14 ` Niklas Söderlund
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=4043309.ejJDZkT8p0@z50 \
--to=jmkrzyszt@gmail.com \
--cc=dave.stevenson@raspberrypi.com \
--cc=hverkuil-cisco@xs4all.nl \
--cc=hyun.kwon@xilinx.com \
--cc=jacopo+renesas@jmondi.org \
--cc=kieran.bingham@ideasonboard.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=niklas.soderlund+renesas@ragnatech.se \
--cc=robert.jarzmik@free.fr \
--cc=sakari.ailus@linux.intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).