From: Dave Stevenson <dave.stevenson@raspberrypi.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Jacopo Mondi <jacopo.mondi@ideasonboard.com>,
Francesco Dolcini <francesco@dolcini.it>,
Sakari Ailus <sakari.ailus@iki.fi>,
Marcel Ziswiler <marcel@ziswiler.com>,
linux-media@vger.kernel.org, kernel@pengutronix.de,
Francesco Dolcini <francesco.dolcini@toradex.com>,
Aishwarya Kothari <aishwarya.kothari@toradex.com>,
Marcel Ziswiler <marcel.ziswiler@toradex.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Steve Longerbeam <slongerbeam@gmail.com>,
linux-kernel@vger.kernel.org,
Marco Felsch <m.felsch@pengutronix.de>
Subject: Re: [PATCH v2] media: i2c: ov5640: Implement get_mbus_config
Date: Mon, 20 Mar 2023 18:31:04 +0000 [thread overview]
Message-ID: <CAPY8ntCnX9uFbyfKnJCH6+8yLWwX1ZieYqzZq6qs9uvAPh9Eyw@mail.gmail.com> (raw)
In-Reply-To: <20230320140012.GB9535@pendragon.ideasonboard.com>
On Mon, 20 Mar 2023 at 14:00, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> On Mon, Mar 20, 2023 at 02:32:25PM +0100, Philipp Zabel wrote:
> > On Mo, 2023-03-20 at 12:15 +0200, Sakari Ailus wrote:
> > > On Mon, Mar 20, 2023 at 11:55:14AM +0200, Laurent Pinchart wrote:
> > > > On Mon, Mar 20, 2023 at 11:37:33AM +0200, Sakari Ailus wrote:
> > > > > On Mon, Mar 20, 2023 at 11:26:02AM +0200, Laurent Pinchart wrote:
> > > > > > In a (simplified) nutshell,
> > > > > >
> > > > > > ---------+ +----------+ +---------+ +-----+ +-----+
> > > > > > > Camera | --> | CSI-2 RX | --> | CSI2IPU | --> | Mux | --> | IPU |
> > > > > > > Sensor | | | | Gasket | | | | |
> > > > > > ---------+ +----------+ +---------+ +-----+ +-----+
> > > > >
> > > > > Thank you, this is helpful.
> > > > >
> > > > > I suppose the mux here at least won't actively do anything to the data. So
> > > > > presumably its endpoint won't contain the active configuration, but its
> > > > > superset.
> > > > >
> > > > > >
> > > > > > All those blocks, except for the gasket, have a node in DT.
> > > > > >
> > > > > > The IPU driver needs to know the number of CSI-2 data lanes, which is
> > > > > > encoded in the data-lanes DT property present in both the sensor output
> > > > > > endpoint and the CSI-2 RX input endpoint, but not the other endpoints in
> > > > > > the pipeline.
> > > > >
> > > > > This doesn't yet explain why the sensor would need to implement
> > > > > get_mbus_config if its bus configuration remains constant.
> > > >
> > > > If I recall correctly, the IPU driver calls .g_mbus_config() on the
> > > > camera sensor to get the number of lanes, as it can't get it from its
> > > > own endpoint. That's a hack, and as Jacopo proposed, calling
> > > > .g_mbus_config() on the CSI-2 RX would be better, as the CSI-2 RX driver
> > > > can then get the value from its own endpoint, without requiring all
> > > > sensor drivers to implement .g_mbus_config().
> > >
> > > The g_mbus_config op could be implemented by the CSI2IPU and mux, by simply
> > > requesting the information from the upstream sub-device. No hacks would be
> > > needed.
> >
> > I think implementing get_mbus_config on the mux might be enough. The
> > IPU driver already recognizes the CSI-2 RX by its grp_id and could
> > infer that it has to use MIPI CSI-2 mode from that.
> >
> > The video-mux would have to forward get_mbus_config to its active
> > upstream port and if the upstream sensor does not implement it read bus
> > width from the active upstream endpoint.
>
> I'm fine with implementing it in the mux as well, but I think we can
> take a shortcut here and call it on the CSI-2 RX from the IPU driver, as
> the IPU driver knows about the architecture of the whole pipeline.
FWIW I have made use of video-mux and implementing g_mbus_config on it
for D-PHY switch chips[1] where the different input ports may have
different configurations. I'll admit that I've made the easy
assumption that it's CSI-2 D-PHY in and out, when it could quite
legitimately be working with any of the other bus types.
I had been intending to send this[2] upstream when I get a chance, but
am I reading imx6q.dtsi[3] correctly in that the mux is accepting
parallel on some ports and CSI-2 on others? The mux hardware is
therefore far more than just a simple switch between inputs? Although
as this is after the CSI2 rx block, this is effectively parallel data
within the SoC, therefore is the configuration and get_mbus_config
really relevant?
I'd like to understand how this is being used on imx6 before trying to
rework my patch into a generic solution.
Thanks
Dave
[1] eg Arducam's 2 and 4 port muxes -
https://www.arducam.com/product-category/camera-multiplexers/, which
IIRC use OnSemi's FSA644
https://www.onsemi.com/products/interfaces/analog-switches/fsa644
[2] https://github.com/raspberrypi/linux/commit/bf653318475cf4db0ec59e92139f477f7cc0a544
[3] https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/imx6q.dtsi#L349
next prev parent reply other threads:[~2023-03-20 18:40 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-06 6:36 [PATCH v2] media: i2c: ov5640: Implement get_mbus_config Marcel Ziswiler
2023-03-14 12:13 ` Sakari Ailus
2023-03-14 12:32 ` Francesco Dolcini
2023-03-14 12:45 ` Sakari Ailus
2023-03-14 12:59 ` Francesco Dolcini
2023-03-20 8:48 ` Jacopo Mondi
2023-03-20 9:00 ` Sakari Ailus
2023-03-20 9:26 ` Laurent Pinchart
2023-03-20 9:37 ` Sakari Ailus
2023-03-20 9:55 ` Laurent Pinchart
2023-03-20 10:15 ` Sakari Ailus
2023-03-20 13:32 ` Philipp Zabel
2023-03-20 14:00 ` Laurent Pinchart
2023-03-20 18:31 ` Dave Stevenson [this message]
2023-03-20 21:53 ` Laurent Pinchart
2023-03-20 21:53 ` Sakari Ailus
2023-03-20 11:26 ` Philipp Zabel
2023-03-20 12:47 ` Jacopo Mondi
2023-03-20 13:28 ` Philipp Zabel
2023-03-20 11:13 ` Francesco Dolcini
2023-03-22 13:53 ` Aishwarya Kothari
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=CAPY8ntCnX9uFbyfKnJCH6+8yLWwX1ZieYqzZq6qs9uvAPh9Eyw@mail.gmail.com \
--to=dave.stevenson@raspberrypi.com \
--cc=aishwarya.kothari@toradex.com \
--cc=francesco.dolcini@toradex.com \
--cc=francesco@dolcini.it \
--cc=jacopo.mondi@ideasonboard.com \
--cc=kernel@pengutronix.de \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=m.felsch@pengutronix.de \
--cc=marcel.ziswiler@toradex.com \
--cc=marcel@ziswiler.com \
--cc=mchehab@kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=sakari.ailus@iki.fi \
--cc=sakari.ailus@linux.intel.com \
--cc=slongerbeam@gmail.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).