[PATCH V2 1/2] dt-bindings: Add byteswap order to chrontel ch7033

[Chris Morgan]

On Mon, Sep 05, 2022 at 05:20:57PM +0200, Robert Foss wrote:
> Thanks Laurent,
> 
> On Sat, 3 Sept 2022 at 02:17, Laurent Pinchart
> <laurent.pinchart at ideasonboard.com> wrote:
> >
> > Hi Chris,
> >
> > Thank you for the patch.
> >
> > On Fri, Sep 02, 2022 at 10:39:05AM -0500, Chris Morgan wrote:
> > > From: Chris Morgan <macromorgan at hotmail.com>
> > >
> > > Update dt-binding documentation to add support for setting byteswap of
> > > chrontel ch7033.
> > >
> > > New property name of chrontel,byteswap added to set the byteswap order.
> > > This property is optional.
> > >
> > > Signed-off-by: Chris Morgan <macromorgan at hotmail.com>
> > > Reviewed-by: Robert Foss <robert.foss at linaro.org>
> > > ---
> > >  .../bindings/display/bridge/chrontel,ch7033.yaml    | 13 +++++++++++++
> > >  1 file changed, 13 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml b/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml
> > > index bb6289c7d375..984b90893583 100644
> > > --- a/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml
> > > +++ b/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml
> > > @@ -14,6 +14,19 @@ properties:
> > >    compatible:
> > >      const: chrontel,ch7033
> > >
> > > +  chrontel,byteswap:
> > > +    $ref: /schemas/types.yaml#/definitions/uint8
> > > +    enum:
> > > +      - 0  # BYTE_SWAP_RGB
> > > +      - 1  # BYTE_SWAP_RBG
> > > +      - 2  # BYTE_SWAP_GRB
> > > +      - 3  # BYTE_SWAP_GBR
> > > +      - 4  # BYTE_SWAP_BRG
> > > +      - 5  # BYTE_SWAP_BGR
> > > +    description: |
> > > +      Set the byteswap value of the bridge. This is optional and if not
> > > +      set value of BYTE_SWAP_BGR is used.
> >
> > I don't think this belongs to the device tree. The source of data
> > connected to the CH7033 input could use different formats. This
> > shouldn't be hardcoded, but queried at runtime, using the input and
> > output media bus formats infrastructure that the DRM bridge framework
> > includes.
> 
> Chris, will you have a look at submitting a fix for this during the coming days?
> 
> If not, we can revert this series and apply a fixed version later.

I'm not sure I understand (or know) what needs to be fixed. Presumably
using something like EDID we can predict what color format we need to
use for the connection between the bridge and the HDMI device, but
wouldn't the color format between the SoC and bridge need to be
constant?

If there's something I'm missing please let me know, I'm relatively
unfamiliar with the display subsystems as a whole. I'll be happy
to make the change once I'm clear what I need to change.

Thank you for your help.

> 
> >
> > > +
> > >    reg:
> > >      maxItems: 1
> > >      description: I2C address of the device
> >
> > --
> > Regards,
> >
> > Laurent Pinchart