On 03/04/2025, Maxime Ripard wrote: > On Tue, Mar 04, 2025 at 06:15:28PM +0800, Liu Ying wrote: >> A DPI color encoder, as a simple display bridge, converts input DPI color >> coding to output DPI color coding, like Adafruit Kippah DPI hat[1] which >> converts input 18-bit pixel data to 24-bit pixel data(with 2 low padding >> bits in every color component though). Document the DPI color encoder. >> >> [1] https://learn.adafruit.com/adafruit-dpi-display-kippah-ttl-tft/downloads >> >> Signed-off-by: Liu Ying <victor.liu@xxxxxxx> > > So it's just a bunch of signals that aren't wired / set to the ground? I > assume to free a few GPIOs? Yes. Freed pins could work as GPIOs or other functions. > > I guess that makes sense. > >> --- >> .../display/bridge/simple-bridge.yaml | 89 ++++++++++++++++++- >> 1 file changed, 87 insertions(+), 2 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml >> index 43cf4df9811a..c1747c033040 100644 >> --- a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml >> +++ b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml >> @@ -27,6 +27,7 @@ properties: >> - const: adi,adv7123 >> - enum: >> - adi,adv7123 >> + - dpi-color-encoder > > I don't think we can claim that there's a generic DPI color encoder. > Maybe we can add the prefix dumb or transparent? TBH, I don't have a best compatible string and open to suggestions. "dpi-color-encoder" came up to my mind just because the MIPI DPI standard documentation mentions *color coding* and this bridge changes the coding, hence *encoder*. If folks think "dumb-dpi-color-encoder" or "transparent-dpi-color-encoder" are good enough, I'd use it. Just let me know which one to use. > >> - dumb-vga-dac >> - ti,opa362 >> - ti,ths8134 >> @@ -37,13 +38,31 @@ properties: >> >> properties: >> port@0: >> - $ref: /schemas/graph.yaml#/properties/port >> + $ref: /schemas/graph.yaml#/$defs/port-base >> + unevaluatedProperties: false >> description: The bridge input >> >> + properties: >> + endpoint: >> + $ref: /schemas/media/video-interfaces.yaml# >> + unevaluatedProperties: false >> + >> + properties: >> + dpi-color-coding: true >> + >> port@1: >> - $ref: /schemas/graph.yaml#/properties/port >> + $ref: /schemas/graph.yaml#/$defs/port-base >> + unevaluatedProperties: false >> description: The bridge output >> >> + properties: >> + endpoint: >> + $ref: /schemas/media/video-interfaces.yaml# >> + unevaluatedProperties: false >> + >> + properties: >> + dpi-color-coding: true >> + >> required: >> - port@0 >> - port@1 >> @@ -61,6 +80,44 @@ required: >> >> additionalProperties: false >> >> +allOf: >> + - $ref: /schemas/display/dpi-color-coding.yaml# >> + - if: >> + properties: >> + compatible: >> + contains: >> + const: dpi-color-encoder >> + then: >> + properties: >> + ports: >> + properties: >> + port@0: >> + properties: >> + endpoint: >> + required: >> + - dpi-color-coding >> + >> + port@1: >> + properties: >> + endpoint: >> + required: >> + - dpi-color-coding >> + else: >> + properties: >> + ports: >> + properties: >> + port@0: >> + properties: >> + endpoint: >> + properties: >> + dpi-color-coding: false >> + >> + port@1: >> + properties: >> + endpoint: >> + properties: >> + dpi-color-coding: false >> + > > Also it complicates the binding enough to warrant for another binding for > that specific "component". Do you suggest to write a separate/new DT binding for this bridge? > >> examples: >> - | >> bridge { >> @@ -88,4 +145,32 @@ examples: >> }; >> }; >> >> + - | >> + bridge { >> + compatible = "dpi-color-enoder"; > > You have a typo in the compatible. Hmm, good catch! I did upgrade dtschema to version 2025.2 with pip3 and didn't see any warnings/errors reported by dt_binding_check, weird... > > Maxime -- Regards, Liu Ying
