On Wed, Sep 30, 2026 at 02:10:15PM +0300, Svyatoslav Ryhel wrote: > ср, 30 вер. 2026 р. о 13:54 Thierry Reding <[email protected]> пише: > > > > On Wed, Sep 30, 2026 at 01:42:17PM +0300, Svyatoslav Ryhel wrote: > > > ср, 30 вер. 2026 р. о 13:34 Thierry Reding <[email protected]> > > > пише: > > > > > > > > On Wed, Sep 30, 2026 at 12:00:21PM +0300, Svyatoslav Ryhel wrote: > > > > > ср, 30 вер. 2026 р. о 11:47 Thierry Reding > > > > > <[email protected]> пише: > > > > > > > > > > > > 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 <[email protected]> > > > > > > > --- > > > > > > > .../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 <[email protected]> > > > > > > > + > > > > > > > +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
signature.asc
Description: PGP signature
