ср, 30 вер. 2026 р. о 15:58 Thierry Reding <[email protected]> пише: > > On Wed, Sep 30, 2026 at 02:56:26PM +0300, Svyatoslav Ryhel wrote: > > ср, 30 вер. 2026 р. о 14:46 Thierry Reding <[email protected]> пише: > > > > > > 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? > > > > > > > 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. > > My concern was that somebody might try to use these pins as GPIOs, in > which case the GPIO and pin controllers are going to interoperate and > reprogram the pin functions, potentially making the DBI interface > malfunction. >
If 8bit interface is in use these gpios cannot be used for anything else. You can be sure of that. > Or is there some other hardware mechanism to prevent this from > happening? > yes, pins are physically linked to the panel > Thierry
