Hi Sakari, On Tue, Aug 20, 2019 at 02:48:49PM +0300, Sakari Ailus wrote: > Hi Maxime, > > On Tue, Aug 20, 2019 at 01:24:32PM +0200, Maxime Ripard wrote: > > From: Maxime Ripard <maxime.ripard@xxxxxxxxxxx> > > > > The Allwinner A10 CMOS Sensor Interface is a camera capture interface also > > used in later (A10s, A13, A20, R8 and GR8) SoCs. > > > > On some SoCs, like the A10, there's multiple instances of that controller, > > with one instance supporting more channels and having an ISP. > > > > Reviewed-by: Rob Herring <robh@xxxxxxxxxx> > > Signed-off-by: Maxime Ripard <maxime.ripard@xxxxxxxxxxx> > > --- > > Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml | 107 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- > > 1 file changed, 107 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml > > > > diff --git a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml > > new file mode 100644 > > index 000000000000..9000bca344f9 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml > > @@ -0,0 +1,107 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/arm/allwinner,sun4i-a10-csi.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Allwinner A10 CMOS Sensor Interface (CSI) Device Tree Bindings > > + > > +maintainers: > > + - Chen-Yu Tsai <wens@xxxxxxxx> > > + - Maxime Ripard <maxime.ripard@xxxxxxxxxxx> > > + > > +description: |- > > + The Allwinner A10 and later has a CMOS Sensor Interface to retrieve > > + frames from a parallel or BT656 sensor. > > + > > +properties: > > + compatible: > > + const: allwinner,sun7i-a20-csi0 > > + > > + reg: > > + maxItems: 1 > > + > > + interrupts: > > + maxItems: 1 > > + > > + clocks: > > + items: > > + - description: The CSI interface clock > > + - description: The CSI module clock > > + - description: The CSI ISP clock > > + - description: The CSI DRAM clock > > + > > + clock-names: > > + items: > > + - const: bus > > + - const: mod > > + - const: isp > > + - const: ram > > + > > + resets: > > + maxItems: 1 > > + > > + port: > > + type: object > > + additionalProperties: false > > + > > + properties: > > + endpoint: > > + properties: > > + bus-width: > > + const: 8 > > + description: Number of data lines actively used. > > Are other values supported? If not, you could omit this. It can also support 16 bits data input, but this description is redundant anyway, I'll remove it. > > + > > + data-active: true > > + hsync-active: true > > + pclk-sample: true > > + remote-endpoint: true > > + vsync-active: true > > + > > + required: > > + - bus-width > > + - data-active > > + - hsync-active > > + - pclk-sample > > + - remote-endpoint > > + - vsync-active > > Some of these are not allowed in the Bt.656 mode (vsync-active and > hsync-active) while they're required in Bt.601 mode. Is there a way to tell > that in YAML-based bindings? You could, but that would be more suited in another schemas. The way schemas works is that you can have several layers of them, and each being validated in isolation from the others. Here, we're just listing the values usable by that binding, and it will be used only to validate that binding. Eventually, we'll want to have a video-interfaces schemas that will apply to all the OF graph users, with those constraints defined. This way, we can avoid a lot of duplication and just have the binding description. I guess I could just have the remote endpoint being required, and the rest will be in the generic part. > Similarly, video-interfaces.txt should be referenced from here, shouldn't > it? Sure. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Attachment:
signature.asc
Description: PGP signature
