Hi Rob, Sorry for the slow answer.
On Fri, Jul 07, 2017 at 11:21:05AM -0500, Rob Herring wrote: > On Mon, Jul 03, 2017 at 02:40:22PM +0200, Maxime Ripard wrote: > > The Cadence MIPI-CSI2 RX controller is a CSI2RX bridge that supports up to > > 4 CSI-2 lanes, and can route the frames to up to 4 streams, depending on > > the hardware implementation. > > Streams and lanes are separate, right? Do you need to know how many > lanes are configured/connected? Streams are the output interfaces, lanes are in input. The number of lanes used is basically defined by the device attached to the other side, and each device can use between 1 to 4 lanes, depending on the device. On those lanes, the CSI protocol defines virtual channels, usually to support multiple devices on the same set of lanes. This device is then able to route the virtual channels in input to any of its streams in output. It doesn't really matter how many lanes are configured or connected, beside some basic setup, and this is already described through the media additions to the OF-graph through a property of the link. What matters is how many streams you have in output to know your routing options, and the number of virtual channels you will have, but that's dynamic iirc. > > It can operate with an external D-PHY, an internal one or no D-PHY at all > > in some configurations. > > > > Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com> > > --- > > .../devicetree/bindings/media/cdns-csi2rx.txt | 87 > > ++++++++++++++++++++++ > > 1 file changed, 87 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/media/cdns-csi2rx.txt > > > > diff --git a/Documentation/devicetree/bindings/media/cdns-csi2rx.txt > > b/Documentation/devicetree/bindings/media/cdns-csi2rx.txt > > new file mode 100644 > > index 000000000000..b5bcb6ad18fc > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/media/cdns-csi2rx.txt > > @@ -0,0 +1,87 @@ > > +Cadence CSI2RX controller > > +========================= > > + > > +The Cadence CSI2RX controller is a CSI-2 bridge supporting up to 4 CSI > > +lanes in input, and 4 different pixel streams in output. > > + > > +Required properties: > > + - compatible: must be set to "cdns,csi2rx" > > Should have a "and an SoC specific compatible string" statement. Ok. > > + - reg: base address and size of the memory mapped region > > + - clocks: phandles to the clocks driving the controller > > + - clock-names: must contain: > > + * sys_clk: main clock > > + * p_clk: register bank clock > > + * p_free_clk: free running register bank clock > > + * pixel_ifX_clk: pixel stream output clock, one for each stream > > + implemented in hardware, between 0 and 3 > > + * dphy_rx_clk: D-PHY byte clock, if implemented in hardware > > "if implemented in hardare" means internal D-PHY? It means if we have a D-PHY, either internal or external. In the case where we don't have any D-PHY, then we'll obviously won't have that clock. > > + - phys: phandle to the external D-PHY > > + - phy-names: must contain dphy, if the implementation uses an > > + external D-PHY > > If? Should phys/phy-names be optional? Yes and no, and I don't really know how it's usually handled in the documentation. The property is mandatory if the hardware uses a D-PHY. But it shouldn't be there if it doesn't. So it's not really optional, it's mandatory in one case, and useless in the other. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
signature.asc
Description: PGP signature
