Re: [RFC 1/5] v4l: subdev: Add MIPI CSI-2 PHY to frame desc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

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.

-- 
Regards,

Sakari Ailus
sakari.ailus@xxxxxxxxxxxxxxx



[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux