Hi Sakari
On Thu, 4 Apr 2019 at 09:49, Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx> wrote:
>
> Hi Dave,
>
> On Mon, Mar 18, 2019 at 03:29:55PM +0000, Dave Stevenson wrote:
> > Hi Jacopo.
> >
> > Sorry, for some reason linux-media messages aren't coming through to
> > me at the moment.
> >
> > I'm interested mainly for tc358743 rather than adv748x, but they want
> > the very similar functionality.
> > I'll try to create patches for that source as well.
> >
> > On Mon, 18 Mar 2019 at 08:30, Jacopo Mondi <jacopo@xxxxxxxxxx> wrote:
> > >
> > > Hi Sakari,
> > > +Maxime because of it's D-PHY work in the phy framework.
> > >
> > > On Sat, Mar 16, 2019 at 07:51:21PM +0200, Sakari Ailus wrote:
> > > > Hi Jacopo,
> > > >
> > > > On Sat, Mar 16, 2019 at 04:47:57PM +0100, Jacopo Mondi wrote:
> > > > > Add PHY-specific parameters to MIPI CSI-2 frame descriptor.
> > > > >
> > > > > Signed-off-by: Jacopo Mondi <jacopo+renesas@xxxxxxxxxx>
> > > > > ---
> > > > > include/media/v4l2-subdev.h | 42 +++++++++++++++++++++++++++++++------
> > > > > 1 file changed, 36 insertions(+), 6 deletions(-)
> > > > >
> > > > > diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
> > > > > index 6311f670de3c..eca9633c83bf 100644
> > > > > --- a/include/media/v4l2-subdev.h
> > > > > +++ b/include/media/v4l2-subdev.h
> > > > > @@ -317,11 +317,33 @@ struct v4l2_subdev_audio_ops {
> > > > > int (*s_stream)(struct v4l2_subdev *sd, int enable);
> > > > > };
> > > > >
> > > > > +#define V4L2_FRAME_DESC_ENTRY_DPHY_DATA_LANES 4
> > > > > +
> > > > > +/**
> > > > > + * struct v4l2_mbus_frame_desc_entry_csi2_dphy - MIPI D-PHY bus configuration
> > > > > + *
> > > > > + * @clock_lane: physical lane index of the clock lane
> > > > > + * @data_lanes: an array of physical data lane indexes
> > > > > + * @num_data_lanes: number of data lanes
> > > > > + */
> > > > > +struct v4l2_mbus_frame_desc_entry_csi2_dphy {
> > > > > + u8 clock_lane;
> > > > > + u8 data_lanes[V4L2_FRAME_DESC_ENTRY_DPHY_DATA_LANES];
> > > > > + u8 num_data_lanes;
> > > >
> > > > Do you need more than the number of the data lanes? I'd expect few devices
> > > > to be able to do more than that. The PHY type comes already from the
> > > > firmware but I guess it's good to do the separation here as well.
> > >
> > > Indeed lane reordering at run time seems like a quite unusual
> > > operation. I would say I could drop that, but then, a structure and a
> > > new field in v4l2_mbus_frame_desc for just an u8, isn't it an
> > > overkill (unless we know it could be expanded, with say, D-PHY timings
> > > as in Maxime's D-PHY phy support implementation. Again, not sure they
> > > should be run-time negotiated, but...)
> >
> > If we're adding extra information, then can I suggest that the
> > clock-noncontinuous flag is also added?
> > If you've got muxed CSI2 buses (eg via the FSA642 [1] as a trivial
> > CSI2 switch), then there is nothing stopping one source wanting
> > continuous clocks, and one not. Encoding it in the receiver's DT node
> > therefore doesn't work for one of the sources. Duplication of that
> > definition between source and receiver has always seemed a likely
> > source of errors to me, but I'm the relative newcomer here.
>
> Do you have such a case somewhere?
There are boards available for the Pi that use the FSA642 to switch
between multiple camera modules [1].
They haven't written any clever drivers as their intended use is
against the (closed) firmware, therefore they currently have to be
identical sensors on each input.
The use of those boards seems to fit pretty cleanly into this
multiplexed CSI bus framework, and there needn't be the limitation of
them being the same sensor.
I acknowledge that the Pi CSI2 receiver driver isn't upstream yet. I
put that on hold as the TC358743 was one of the main devices to be
supported, and without the rest of this patch set passing the number
of lanes in use through then that was pretty dead in the water. It was
less effort to keep the driver in the Pi vendor tree using the
g_mbus_config mechanism that was rejected, rather than holding patches
on an upstreamed driver. Once this set is merged and I can therefore
support TC358743 cleanly I'll be looking again at upstreaming it.
[1] http://www.ivmech.com/magaza/en/development-modules-c-4/ivport-dual-raspberry-pi-camera-module-multiplexer-p-104
> As this is typically up to a device configuration (for those that support
> it), it should be possible to use the same setting for both the sensors.
Are you meaning CSI transmitter or receiver for device configuration?
Most receivers support either, but often have to be told which mode to expect.
TC358743 seems to be one of the few CSI drivers that actually supports
both. None of the others appear to quote the use of
clock-noncontinuous in their DT bindings, but that doesn't guarantee
that that is the actual truth.
So there's no issue at the moment, but there will be issues when you
get the first driver that only supports clock-noncontinuous and
someone wants to mux it.
As I said, having the potential for the two ends to be set differently
in device tree and no way to check at runtime seems like an
unnecessary trap for the unwary. You're now adding a config path from
source to receiver, therefore adding that information removes that
confusion. Just a suggestion.
Dave
