On Wed, Sep 30, 2026 at 01:56:40PM +0300, Svyatoslav Ryhel wrote: > ср, 30 вер. 2026 р. о 13:50 Thierry Reding <[email protected]> пише: > > > > On Wed, Sep 30, 2026 at 12:52:18PM +0300, Svyatoslav Ryhel wrote: > > > ср, 30 вер. 2026 р. о 12:19 Mikko Perttunen <[email protected]> пише: > > > > > > > > On Wednesday, September 30, 2026 4:05 PM 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 > > > > > + > > > > > + dc-gpios: > > > > > + description: Data/command selection pin. > > > > > + maxItems: 1 > > > > > + > > > > > + rw-gpios: > > > > > + description: Read/write pin. > > > > > + maxItems: 1 > > > > > + > > > > > + cs-gpios: > > > > > + description: Chip select pin. > > > > > + maxItems: 1 > > > > > + > > > > > + data-gpios: > > > > > + description: Specifies a set of 8 gpio pins used to transfer > > > > > data. > > > > > + minItems: 8 > > > > > + maxItems: 8 > > > > > > > > Based on my admittedly brief research, according to the TRM the display > > > > controller can drive all of these pins - of which there are two fixed > > > > sets as you mention - directly. So we'd need to describe which interface > > > > the display is connected to in DT, but not any GPIOs (which they really > > > > aren't). > > > > > > > > > > I am perfectly fine to not expose any gpios in the binding, if this is > > > preferred. Only question, which method of interface checking would be > > > preferred. I assume if primary then nothing, if secondary - boolean > > > prop "nvidia,secondary"? Feel free to share your vision. > > > > The driver currently uses the GPIOs to program DBI commands, so I > > suspect we do need some way of controlling those pins. Or is there a way > > to have the display controller program the pins and send commands? That > > would be much preferred because it would more accurately reflect the HW > > design and possibly also simplify the driver because it doesn't need to > > parse the GPIOs and then also not use the GPIO API to set the values. > > > > From what I know, GPIOs must be used and freed after use. Sets of > GPIOs are defined and remain fixed for primary and secondary > interface.
So you're saying that we need the GPIO handling in the RGB/DBI driver to prevent anyone else from using these GPIOs and potentially messing with the DBI communication? It feels like there should be a better mechanism for that than requiring the DC driver to request all the GPIOs. Maybe these should be excluded from the range of valid GPIOs? We can make sure that device tree isn't going to use these on a given platform, but there's still the risk of users grabbing them via sysfs or the chardev API. > > As for selecting the interface to use, it could probably be just a > > simple, single-cell value with two valid values. That's a bit clearer > > than a boolean, because with a boolean you need to explicitly document > > what happens when it is absent. > > > > I can describe boolean too, but if you want set it like "nvidia,head". > Fine by me. Yeah, I'd prefer it to be explicit which mode of operation is selected. Thierry
signature.asc
Description: PGP signature
