Message-ID: <20190322155519.fi3ypbomdqgz3am4@paasikivi.fi.intel.com>
Date:   Fri, 22 Mar 2019 17:55:19 +0200
From:   Sakari Ailus <sakari.ailus@...ux.intel.com>
To:     Vishal Sagar <vsagar@...inx.com>
Cc:     Vishal Sagar <vishal.sagar@...inx.com>,
        Hyun Kwon <hyunk@...inx.com>,
        "laurent.pinchart@...asonboard.com" 
        <laurent.pinchart@...asonboard.com>,
        "mchehab@...nel.org" <mchehab@...nel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        Michal Simek <michals@...inx.com>,
        "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "hans.verkuil@...co.com" <hans.verkuil@...co.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Dinesh Kumar <dineshk@...inx.com>,
        Sandip Kothari <sandipk@...inx.com>
Subject: Re: [PATCH v6 1/2] media: dt-bindings: media: xilinx: Add Xilinx
 MIPI CSI-2 Rx Subsystem

Hi Vishal,

On Tue, Mar 12, 2019 at 02:45:06PM +0000, Vishal Sagar wrote:
> 
> Hi Sakari,
> 
> Thanks for reviewing this.
> 
> > -----Original Message-----
> > From: linux-media-owner@...r.kernel.org [mailto:linux-media-
> > owner@...r.kernel.org] On Behalf Of Sakari Ailus
> > Sent: Tuesday, March 12, 2019 3:51 PM
> > To: Vishal Sagar <vishal.sagar@...inx.com>
> > Cc: Hyun Kwon <hyunk@...inx.com>; laurent.pinchart@...asonboard.com;
> > mchehab@...nel.org; robh+dt@...nel.org; mark.rutland@....com; Michal
> > Simek <michals@...inx.com>; linux-media@...r.kernel.org;
> > devicetree@...r.kernel.org; hans.verkuil@...co.com; linux-arm-
> > kernel@...ts.infradead.org; linux-kernel@...r.kernel.org; Dinesh Kumar
> > <dineshk@...inx.com>; Sandip Kothari <sandipk@...inx.com>
> > Subject: Re: [PATCH v6 1/2] media: dt-bindings: media: xilinx: Add Xilinx MIPI
> > CSI-2 Rx Subsystem
> > 
> > EXTERNAL EMAIL
> > 
> > Hi Vishal,
> > 
> > Thanks for the update. This looks pretty good, please see a few comments
> > below.
> > 
> > On Tue, Mar 12, 2019 at 10:05:29AM +0530, Vishal Sagar wrote:
> > > Add bindings documentation for Xilinx MIPI CSI-2 Rx Subsystem.
> > >
> > > The Xilinx MIPI CSI-2 Rx Subsystem consists of a CSI-2 Rx controller, a
> > > DPHY in Rx mode, an optional I2C controller and a Video Format Bridge.
> > >
> > > Signed-off-by: Vishal Sagar <vishal.sagar@...inx.com>
> > > Reviewed-by: Hyun Kwon <hyun.kwon@...inx.com>
> > > Reviewed-by: Rob Herring <robh@...nel.org>
> > > ---
> > > v6
> > > - Added "control" after V4L2_CID_XILINX_MIPICSISS_ACT_LANES as suggested
> > by Luca
> > > - Added reviewed by Rob Herring
> > >
> > > v5
> > > - Incorporated comments by Luca Cersoli
> > > - Removed DPHY clock from description and example
> > > - Removed bayer pattern from device tree MIPI CSI IP
> > >   doesn't deal with bayer pattern.
> > >
> > > v4
> > > - Added reviewed by Hyun Kwon
> > >
> > > v3
> > > - removed interrupt parent as suggested by Rob
> > > - removed dphy clock
> > > - moved vfb to optional properties
> > > - Added required and optional port properties section
> > > - Added endpoint property section
> > >
> > > v2
> > > - updated the compatible string to latest version supported
> > > - removed DPHY related parameters
> > > - added CSI v2.0 related property (including VCX for supporting upto 16
> > >   virtual channels).
> > > - modified csi-pxl-format from string to unsigned int type where the value
> > >   is as per the CSI specification
> > > - Defined port 0 and port 1 as sink and source ports.
> > > - Removed max-lanes property as suggested by Rob and Sakari
> > >
> > >  .../bindings/media/xilinx/xlnx,csi2rxss.txt        | 118
> > +++++++++++++++++++++
> > >  1 file changed, 118 insertions(+)
> > >  create mode 100644
> > Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.txt
> > b/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.txt
> > > new file mode 100644
> > > index 0000000..5b8170f
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.txt
> > > @@ -0,0 +1,118 @@
> > > +Xilinx MIPI CSI2 Receiver Subsystem Device Tree Bindings
> > > +--------------------------------------------------------
> > > +
> > > +The Xilinx MIPI CSI2 Receiver Subsystem is used to capture MIPI CSI2 traffic
> > > +from compliant camera sensors and send the output as AXI4 Stream video
> > data
> > > +for image processing.
> > > +
> > > +The subsystem consists of a MIPI DPHY in slave mode which captures the
> > > +data packets. This is passed along the MIPI CSI2 Rx IP which extracts the
> > > +packet data. The optional Video Format Bridge (VFB) converts this data to
> > > +AXI4 Stream video data.
> > > +
> > > +For more details, please refer to PG232 Xilinx MIPI CSI-2 Receiver Subsystem.
> > > +
> > > +Required properties:
> > > +--------------------
> > > +- compatible: Must contain "xlnx,mipi-csi2-rx-subsystem-4.0".
> > > +- reg: Physical base address and length of the registers set for the device.
> > > +- interrupts: Property with a value describing the interrupt number.
> > > +- clocks: List of phandles to AXI Lite and Video clocks.
> > > +- clock-names: Must contain "lite_aclk" and "video_aclk" in the same order
> > > +  as clocks listed in clocks property.
> > > +- xlnx,csi-pxl-format: This denotes the CSI Data type selected in hw design.
> > > +  Packets other than this data type (except for RAW8 and User defined data
> > > +  types) will be filtered out. Possible values are as below -
> > > +  0x1E - YUV4228B
> > > +  0x1F - YUV42210B
> > > +  0x20 - RGB444
> > > +  0x21 - RGB555
> > > +  0x22 - RGB565
> > > +  0x23 - RGB666
> > > +  0x24 - RGB888
> > > +  0x28 - RAW6
> > > +  0x29 - RAW7
> > > +  0x2A - RAW8
> > > +  0x2B - RAW10
> > > +  0x2C - RAW12
> > > +  0x2D - RAW14
> > > +  0x2E - RAW16
> > > +  0x2F - RAW20
> > > +
> > > +
> > > +Optional properties:
> > > +--------------------
> > > +- xlnx,vfb: This is present when Video Format Bridge is enabled.
> > > +  Without this property the driver won't be loaded as IP won't be able to
> > generate
> > > +  media bus format compliant stream output.
> > 
> > What's the use case for this? I read in an earlier thread that this is
> > used to prevent the driver from loading.
> > 
> 
> This property ensures that the data being sent on the media bus complies with
> existing formats. If Video Format Bridge (VFB) is disabled, then the data is sent on the bus in the
> same way as it is received. For e.g. with RAW10 with bus width of 32 bits, the first clock
> cycle will contain the MSB 8bits of 4 pixels.
> The lower 2 bits of each pixel will be sent on the next clock.
> 
> When VFB is enabled, the input data stream is processed based on the CSI Data Type and
> Pixels per clock selected in design and then sent out.
> For e.g. for RAW10 with 2 pixels per clock and VFB enabled, the bus will have pixel 0 data 
> on 9:0 and pixel 1 data on 19:10. Upper bits on the bus will be zeros.

So... should I read this as if it determines whether the IP block unpacks
the pixels? If so, the description is at least inaccurate: remember this
isn't specific to Linux.

There's nothing wrong in not unpacking it; it just means the formats will
be different. The property name seems sensible IMO.

Please wrap your lines at 76 or so characters.

> 
> > > +- xlnx,en-csi-v2-0: Present if CSI v2 is enabled in IP configuration.
> > > +- xlnx,en-vcx: When present, there are maximum 16 virtual channels, else
> > > +  only 4. This is present only if xlnx,en-csi-v2-0 is present.
> > > +- xlnx,en-active-lanes: present if the number of active lanes can be
> > > +  reconfigured at runtime in the Protocol Configuration Register.
> > > +  If present, the V4L2_CID_XILINX_MIPICSISS_ACT_LANES control is added.
> > > +  Otherwise all lanes, as set in IP configuration, are always active.
> > 
> > The bindings document hardware, therefore a V4L2 control name doesn't
> > belong here.
> > 
> Ok. I will remove this and revert to original description as below -
> 
> xlnx,en-active-lanes: present if the number of active lanes can be
> re-configured at runtime in the Protocol Configuration Register

Seems good to me.

> 
> > If you want to set the number of lanes at runtime, the frame descriptors
> > are probably the best way to do that. The patchset will be merged in the
> > near future. Jacopo sent the last iteration of it recently. I'd leave that
> > feature out for now though: few transmitter drivers support the feature
> > (using an old API).
> > 
> 
> I had a look at Jacopo's patch set
> 
> [PATCH v3 15/31] v4l: Add bus type to frame descriptors
> [PATCH v3 16/31] v4l: Add CSI-2 bus configuration to frame descriptors
> [PATCH v3 17/31] v4l: Add stream to frame descriptor
> [PATCH v3 29/31] rcar-csi2: use frame description information to configure CSI-2 bus
> 
> +/**
> + * struct v4l2_mbus_frame_desc_entry_csi2
> + *
> + * @channel: CSI-2 virtual channel
> + * @data_type: CSI-2 data type ID
> + */
> +struct v4l2_mbus_frame_desc_entry_csi2 {
> +       u8 channel;
> +       u8 data_type;
> +};
> 
> It looks like this patch set is trying to add support for virtual channel number and data type association.
> This is different from controlling number of lanes on which CSI Rx will receive data.
> Please correct my understanding if not right.

So far I'm familiar with two cases. In the firstc case, the number of lanes
is determined by what is connected on the board. This is naturally
supported. The second one is that in some cases, a device is not able to
use all the connected lanes. This can be supported using the frame
descriptors through the receiver querying the transmitter device's frame
descriptor.

> 
> > > +
> > > +Ports
> > > +-----
> > > +The device node shall contain two 'port' child nodes as defined in
> > > +Documentation/devicetree/bindings/media/video-interfaces.txt.
> > > +
> > > +The port@0 is a sink port and shall connect to CSI2 source like camera.
> > > +It must have the data-lanes property.
> > > +
> > > +The port@1 is a source port and can be connected to any video processing IP
> > > +which can work with AXI4 Stream data.
> > > +
> > > +Required port properties:
> > > +--------------------
> > > +- reg: 0 - for sink port.
> > > +       1 - for source port.
> > > +
> > > +Optional endpoint property:
> > > +---------------------------
> > > +- data-lanes: specifies MIPI CSI-2 data lanes as covered in video-
> > interfaces.txt.
> > > +  This should be in the sink port endpoint which connects to MIPI CSI2 source
> > > +  like sensor. The possible values are:
> > > +  1       - For 1 lane enabled in IP.
> > > +  1 2     - For 2 lanes enabled in IP.
> > > +  1 2 3   - For 3 lanes enabled in IP.
> > > +  1 2 3 4 - For 4 lanes enabled in IP.
> > > +
> > > +Example:
> > > +
> > > +     csiss_1: csiss@...20000 {
> > 
> > The node name should be generic, a Cadence device uses csi2rx which seems
> > like a good fit here, too.
> > 
> 
> Ok. I will change it to xcsi2rxss_1:csi2rx@...20000. 
> 
> > > +             compatible = "xlnx,mipi-csi2-rx-subsystem-4.0";
> > > +             reg = <0x0 0xa0020000 0x0 0x10000>;
> > > +             interrupt-parent = <&gic>;
> > > +             interrupts = <0 95 4>;
> > > +             xlnx,csi-pxl-format = <0x2a>;
> > > +             xlnx,vfb;
> > > +             xlnx,en-active-lanes;
> > > +             xlnx,en-csi-v2-0;
> > > +             xlnx,en-vcx;
> > > +             clock-names = "lite_aclk", "video_aclk";
> > > +             clocks = <&misc_clk_0>, <&misc_clk_1>;
> > > +
> > > +             ports {
> > > +                     #address-cells = <1>;
> > > +                     #size-cells = <0>;
> > > +
> > > +                     port@0 {
> > > +                             /* Sink port */
> > > +                             reg = <0>;
> > > +                             csiss_in: endpoint {
> > > +                                     data-lanes = <1 2 3 4>;
> > > +                                     /* MIPI CSI2 Camera handle */
> > > +                                     remote-endpoint = <&camera_out>;
> > > +                             };
> > > +                     };
> > > +                     port@1 {
> > > +                             /* Source port */
> > > +                             reg = <1>;
> > > +                             csiss_out: endpoint {
> > > +                                     remote-endpoint = <&vproc_in>;
> > > +                             };
> > > +                     };
> > > +             };
> > > +     };

-- 
Regards,

Sakari Ailus
sakari.ailus@...ux.intel.com

Powered by blists - more mailing lists