| Message ID | 20240221160215.484151-8-panikiel@google.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | Add Chameleon v3 video support | expand |
| Context | Check | Description |
|---|---|---|
| robh/checkpatch | success | |
| robh/patch-applied | success | |
| robh/dtbs-check | warning | build log |
| robh/dt-meta-schema | success |
On 21/02/2024 17:02, Paweł Anikiel wrote: > The Chameleon v3 uses the framebuffer IP core to take the video signal > from different sources and directly write frames into memory. > > Signed-off-by: Paweł Anikiel <panikiel@google.com> ... > + > + reg: > + items: > + - description: core registers > + - description: irq registers > + > + interrupts: > + maxItems: 1 > + > + google,legacy-format: > + type: boolean > + description: The incoming video stream is in 32-bit padded mode. Why is this a property of board DTS? Can't the input streams change depending on the usage? Who defines the incoming stream format? > + Best regards, Krzysztof
Hi, sorry for the long delay On Mon, Feb 26, 2024 at 10:10 AM Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > > On 21/02/2024 17:02, Paweł Anikiel wrote: > > The Chameleon v3 uses the framebuffer IP core to take the video signal > > from different sources and directly write frames into memory. > > > > Signed-off-by: Paweł Anikiel <panikiel@google.com> > > ... > > > + > > + reg: > > + items: > > + - description: core registers > > + - description: irq registers > > + > > + interrupts: > > + maxItems: 1 > > + > > + google,legacy-format: > > + type: boolean > > + description: The incoming video stream is in 32-bit padded mode. > > Why is this a property of board DTS? Can't the input streams change > depending on the usage? Who defines the incoming stream format? The input streams are defined by this hardware module - there are specific input lines for red, green, blue channels, h/v sync, etc. However, there are two variants of this module which behave differently - one has 60 input lines and outputs BGRX32, and the other one has 192 input lines and outputs RGB24. The "incoming 32-bit padded mode" referred to an internal bus inside of the module, which I realize isn't very meaningful. Instead, I think it would be better to have two compatibles, one for each variant of the module.
diff --git a/Documentation/devicetree/bindings/media/google,chv3-fb.yaml b/Documentation/devicetree/bindings/media/google,chv3-fb.yaml new file mode 100644 index 000000000000..7961c0ab66ec --- /dev/null +++ b/Documentation/devicetree/bindings/media/google,chv3-fb.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/google,chv3-fb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Google Chameleon v3 video framebuffer + +maintainers: + - Paweł Anikiel <panikiel@google.com> + +properties: + compatible: + const: google,chv3-fb + + reg: + items: + - description: core registers + - description: irq registers + + interrupts: + maxItems: 1 + + google,legacy-format: + type: boolean + description: The incoming video stream is in 32-bit padded mode. + + port: + $ref: /schemas/graph.yaml#/properties/port + description: + Connection to the video receiver - optional. If this isn't present, + the video interface still works on its own, but EDID control is + unavailable and DV timing information only reports the active + video width/height. + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + video@c0060500 { + compatible = "google,chv3-fb"; + reg = <0xc0060500 0x100>, + <0xc0060f20 0x10>; + interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>; + google,legacy-format; + }; + + - | + video@c0060600 { + compatible = "google,chv3-fb"; + reg = <0xc0060600 0x100>, + <0xc0060f30 0x10>; + interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>; + + port { + fb_mst0_0: endpoint { + remote-endpoint = <&dprx_mst_0>; + }; + }; + };
The Chameleon v3 uses the framebuffer IP core to take the video signal from different sources and directly write frames into memory. Signed-off-by: Paweł Anikiel <panikiel@google.com> --- .../bindings/media/google,chv3-fb.yaml | 67 +++++++++++++++++++ 1 file changed, 67 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/google,chv3-fb.yaml