On Friday, October 23, 2026 11:14 PM Svyatoslav Ryhel wrote: > пт, 23 жовт. 2026 р. о 11:26 Svyatoslav Ryhel <[email protected]> пише: > > > > пт, 23 жовт. 2026 р. о 10:53 Mikko Perttunen <[email protected]> пише: > > > > ... > > > > +MODULE_ALIAS("platform:tegra-dbi"); > > > > +MODULE_AUTHOR("Svyatoslav Ryhel <[email protected]>"); > > > > +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.
