Re: [PATCH v4 7/7] drm/tegra: Add support for 8-bit CPU interface

[Svyatoslav Ryhel]

нд, 25 жовт. 2026 р. о 03:46 Mikko Perttunen <mperttunen@xxxxxxxxxx> пише:
>
> On Friday, October 23, 2026 11:14 PM Svyatoslav Ryhel wrote:
> > пт, 23 жовт. 2026 р. о 11:26 Svyatoslav Ryhel <clamor95@xxxxxxxxx> пише:
> > >
> > > пт, 23 жовт. 2026 р. о 10:53 Mikko Perttunen <mperttunen@xxxxxxxxxx> пише:
> > > >
> > ...
> > > > > +MODULE_ALIAS("platform:tegra-dbi");
> > > > > +MODULE_AUTHOR("Svyatoslav Ryhel <clamor95@xxxxxxxxx>");
> > > > > +MODULE_DESCRIPTION("Nvidia Tegra20/30 MIPI-DBI Type B driver");
> > > > > +MODULE_LICENSE("GPL");
> > > >
> > > > No separate platform driver or device. If a separate struct device is
> > > > needed for some technical purpose, we need to create a minimal separate
> > > > virtual device, but unless there is a strong reason to have that we
> > > > should be fine with just the dc device.
> > > >
> > > > Thank you
> > > > Mikko
> > > >
> > >
> > > ATM, I use bridge framework to describe interface and I am attaching
> > > it to RGB since it basically uses RGB to transfer video data. It works
> > > pretty nice so far.
> > >
> > > You propose to replicate how RGB works just for DBI?
> > >
> >
> > One of the reasons I used separate pdev was to be able get mipi_dbi
> > from it using dev_get_drvdata() from patent (dbi bridge in this case).
> > DBI framework seems to not have a way to pass it in any other way,
> > unless you know smth I don't.
>
> Right, I think using a bridge is fine; passing the mipi_dbi interface is
> properly done in other ways. The direct parent devdata link is a bit of
> a "poor man's bus", and sometimes it breaks down, such as here.
>
> MIPI DBI is comparable to MIPI DSI -- both have a hardware channel that
> sends both pixel data and commands. I think we should follow DSI's
> example and have a DBI bus and devices while keeping it as simple as
> possible.
>
> The DC driver would register a DBI host and the panel would bind as a
> DBI device. The DC driver can then supply the mipi_dbi object in a field
> of the mipi_dbi_device.
>
> This is a bit more complicated than a parent devdata pointer but much
> cleaner, and follows the existing DSI pattern.
>

I understand your intentions, but ATM kernel lacks any DBI type B
framework. No hosts, ho devices, noting granular. Implementing
everything just not worth my time to support 2 panels of device based
on Tegra 20. And I am talking not about time to actually implement
this in the code, but to upstream. DSI framework is huge, copying even
part of it to wrap legacy DBI interface and ustreaming it does not
worth hassle. And yes, I am a poor man, I use a parent devdata bus.

>
>