Re: [PATCH v1 3/6] dt-bindings: display: tegra: Document 8-bit CPU parallel interface

[Svyatoslav Ryhel]

ср, 30 вер. 2026 р. о 14:46 Thierry Reding <thierry.reding@xxxxxxxxxx> пише:
>
> On Wed, Sep 30, 2026 at 01:56:40PM +0300, Svyatoslav Ryhel wrote:
> > ср, 30 вер. 2026 р. о 13:50 Thierry Reding <thierry.reding@xxxxxxxxxx> пише:
> > >
> > > On Wed, Sep 30, 2026 at 12:52:18PM +0300, Svyatoslav Ryhel wrote:
> > > > ср, 30 вер. 2026 р. о 12:19 Mikko Perttunen <mperttunen@xxxxxxxxxx> пише:
> > > > >
> > > > > 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 <clamor95@xxxxxxxxx>
> > > > > > ---
> > > > > >  .../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@xxxxxxxxx>
> > > > > > +
> > > > > > +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?
>

No, gpios are used for dbi communcation while their sfio versions are
used to transfer RGB data. So there is no risk in external
intereference.

> 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?
>

NO! These gpios can be used for random purposes on devices with non-RGB setups.

> 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.
>

Well, defining them in the schema as it is now and adding a note that
gpios specified in the binding cannot be re-used/shared may be a
solution. But overall it is impossible to reuse gpios dedicated for
dbi by hw design. They cannot be shared or used for other purposes if
dbi is used.

> > > 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