Hi Sakari, On 2017-06-14 13:45:58 +0300, Sakari Ailus wrote: > Hi Niklas, > > On Tue, Jun 13, 2017 at 06:50:14PM +0200, Niklas Söderlund wrote: > > Hi Sakari, > > > > Thanks for your feedback. > > > > On 2017-05-29 14:16:25 +0300, Sakari Ailus wrote: > > > Hi Niklas, > > > > > > On Wed, May 24, 2017 at 02:13:52AM +0200, Niklas Söderlund wrote: > > > > From: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se> > > > > > > > > Documentation for Renesas R-Car MIPI CSI-2 receiver. The CSI-2 receivers > > > > are located between the video sources (CSI-2 transmitters) and the video > > > > grabbers (VIN) on Gen3 of Renesas R-Car SoC. > > > > > > > > Each CSI-2 device is connected to more then one VIN device which > > > > simultaneously can receive video from the same CSI-2 device. Each VIN > > > > device can also be connected to more then one CSI-2 device. The routing > > > > of which link are used are controlled by the VIN devices. There are only > > > > a few possible routes which are set by hardware limitations, which are > > > > different for each SoC in the Gen3 family. > > > > > > > > To work with the limitations of routing possibilities it is necessary > > > > for the DT bindings to describe which VIN device is connected to which > > > > CSI-2 device. This is why port 1 needs to to assign reg numbers for each > > > > VIN device that be connected to it. To setup and to know which links are > > > > valid for each SoC is the responsibility of the VIN driver since the > > > > register to configure it belongs to the VIN hardware. > > > > > > > > Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se> > > > > --- > > > > .../devicetree/bindings/media/rcar-csi2.txt | 116 > > > > +++++++++++++++++++++ > > > > 1 file changed, 116 insertions(+) > > > > create mode 100644 > > > > Documentation/devicetree/bindings/media/rcar-csi2.txt > > > > > > > > diff --git a/Documentation/devicetree/bindings/media/rcar-csi2.txt > > > > b/Documentation/devicetree/bindings/media/rcar-csi2.txt > > > > new file mode 100644 > > > > index 0000000000000000..f6e2027ee92b171a > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/media/rcar-csi2.txt > > > > @@ -0,0 +1,116 @@ > > > > +Renesas R-Car MIPI CSI-2 > > > > +------------------------ > > > > + > > > > +The rcar-csi2 device provides MIPI CSI-2 capabilities for the Renesas > > > > R-Car > > > > +family of devices. It is to be used in conjunction with the R-Car VIN > > > > module, > > > > +which provides the video capture capabilities. > > > > + > > > > + - compatible: Must be one or more of the following > > > > + - "renesas,r8a7795-csi2" for the R8A7795 device. > > > > + - "renesas,r8a7796-csi2" for the R8A7796 device. > > > > + - "renesas,rcar-gen3-csi2" for a generic R-Car Gen3 compatible > > > > device. > > > > + > > > > + When compatible with a generic version nodes must list the > > > > + SoC-specific version corresponding to the platform first > > > > + followed by the generic version. > > > > + > > > > + - reg: the register base and size for the device registers > > > > + - interrupts: the interrupt for the device > > > > + - clocks: Reference to the parent clock > > > > + > > > > +The device node should contain two 'port' child nodes according to the > > > > +bindings defined in Documentation/devicetree/bindings/media/ > > > > +video-interfaces.txt. Port 0 should connect the node that is the video > > > > +source for to the CSI-2. Port 1 should connect all the R-Car VIN > > > > +modules, which can make use of the CSI-2 module. > > > > > > Should or shall? > > > > > > I guess you could add that it is possible to leave them unconnected, too. > > > > Which ports/endpoints are you talking about? In my mind it's not allowed > > to leave them unconnected. > > > > If there ever is a system with only 4 VIN instances (I'm not aware of > > any such system) then yes the endpoints for those VIN not present in the > > system in port 1 should be left unconnected but other then that they > > should all be mandatory right? Or am I missing something? > > I think so, yes. Then "shall" is right, isn't it?
Yes shall is then the correct term, will update for next version. > > > > > > > > > > + > > > > +- Port 0 - Video source > > > > + - Reg 0 - sub-node describing the endpoint that is the video > > > > source > > > > > > Which endpoint properties are mandatory for the receiver? Which ones are > > > optional? (I.e. it shouldn't be necessary to read driver code to write > > > board > > > description.) > > > > I will add a note that all endpoints in port 0 are mandatory and that > > all endpoints that represents a connection to a VIN instance in the > > system is mandatory for next version. Thanks I did not think about this > > possibility. > > Please list the mandatory and optional properties, too. Not just the > endpoints. Good point, will do so. > > -- > Hälsningar, > > Sakari Ailus > e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- Regards, Niklas Söderlund
