On Wed, Sep 30, 2026 at 02:10:15PM +0300, Svyatoslav Ryhel wrote:
> ср, 30 вер. 2026 р. о 13:54 Thierry Reding <thierry.reding@kernel.org> пише:
> >
> > On Wed, Sep 30, 2026 at 01:42:17PM +0300, Svyatoslav Ryhel wrote:
> > > ср, 30 вер. 2026 р. о 13:34 Thierry Reding <thierry.reding@kernel.org> пише:
> > > >
> > > > On Wed, Sep 30, 2026 at 12:00:21PM +0300, Svyatoslav Ryhel wrote:
> > > > > ср, 30 вер. 2026 р. о 11:47 Thierry Reding <thierry.reding@kernel.org> пише:
> > > > > >
> > > > > > On Wed, Sep 30, 2026 at 10:05:32AM +0300, Svyatoslav Ryhel wrote:
> > > > > > > Document 8-bit CPU parallel MIPI DBI Type B interface provided by
> > > > > > > Tegra20/30 SoCs display controller.
> > > > > > >
> > > > > > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > > > > > ---
> > > > > > >  .../display/tegra/nvidia,tegra-8bit-cpu.yaml  | 138 ++++++++++++++++++
> > > > > > >  1 file changed, 138 insertions(+)
> > > > > > >  create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > > > >
> > > > > > > diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > > > > new file mode 100644
> > > > > > > index 0000000000000..f0dab608b2936
> > > > > > > --- /dev/null
> > > > > > > +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> > > > > > > @@ -0,0 +1,138 @@
> > > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > > > +%YAML 1.2
> > > > > > > +---
> > > > > > > +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra-8bit-cpu.yaml#
> > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > +
> > > > > > > +title: Nvidia Tegra DC based MIPI DBI Type B bridge
> > > > > > > +
> > > > > > > +maintainers:
> > > > > > > +  - Svyatoslav Ryhel <clamor95@gmail.com>
> > > > > > > +
> > > > > > > +description: The display controller in Tegra20/30 SoCs features an
> > > > > > > +  8-bit SPI interface that closely resembles the MIPI DBI Type B
> > > > > > > +  protocol and is referred to as '8-bit CPU'. Each display controller
> > > > > > > +  provides two such interfaces, which can be used to send MIPI DCS
> > > > > > > +  commands to initialize and control the panel while image data is
> > > > > > > +  transmitted via 16/18/24-line RGB.
> > > > > > > +
> > > > > > > +properties:
> > > > > > > +  compatible:
> > > > > > > +    const: nvidia,tegra-8bit-cpu
> > > > > >
> > > > > > The description says that this is a feature of the display controller,
> > > > > > so adding a new binding and compatible string for this is not the right
> > > > > > move. This is all covered by the "nvidia,tegra{20,30}-dc" already, just
> > > > > > need to extend that with whatever is new.
> > > > > >
> > > > >
> > > > > How would you model it? I have tried to model 8bit-cpu as a bridge, similar
> > > > > to how DSI bridges are modeled. This reflects interface used to link RGB and
> > > > > panel, without inflating existing DC binding. If you have any ideas in modelling
> > > > > this, I am open to any suggestions.
> > > >
> > > > My suggestion is to integrate this into the existing "rgb" node, or, if
> > >
> > > Not an option since it is not clean RGB and there will be no way to
> > > distinguish RGB from 8bit-CPU.
> > >
> > > > that becomes too convoluted, a separate "lcd" node (or "dbi", whatever).
> > >
> > > This is fine by me but nesting nodes without compatible feels weird. Oh well.
> > >
> > > dc {
> > >   compatible = "...";
> > >   rgb {
> > >     dbi {
> > >       ...
> > >     };
> > >   };
> > > };
> >
> > That's one option, but there's also many other ways you could
> > differentiate between RGB and DBI. Could be a simple "nvidia,interface"
> > property in the "rgb" node (that defaults to RGB if absent). It could
> > also be a node that is a sibling to "rgb" (rather than a child). Or the
> > child could work, too.
> >
> > Ultimately we're still describing aspects of the display controller here
> > since this is all registers within the display controller's MMIO region.
> > Nested nodes are purely for adding some logical structure for the
> > description that makes sense.
> >
> 
> From my understanding data is sent basically as RGB, at least RGB
> configuration is still used in downstream. Panel commands are sent via
> DBI
> 
> dc {
>    compatible = "...";
> 
>    rgb {
>     port...
>    };
> 
>    dbi {
>       ...
>    };
> };
> 
> This would work nicely if DBI is modeled using bridge framework. I
> would strongly insist on keeping it as a stand-alone configuration
> separated from RGB and DC.

Okay, maybe give that a try then. But to clarify: this should all be
part of the Tegra DC driver and not need an extra compatible string or
separate driver. The DC itself should be able to function as a bridge.

Thierry