Re: MIPI DSI, DBI, and tinydrm drivers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





Le dim. 24 mai 2020 à 22:14, Noralf Trønnes <noralf@xxxxxxxxxxx> a écrit :


Den 24.05.2020 21.54, skrev Paul Cercueil:
 Hi Noralf,

Le dim. 24 mai 2020 à 19:46, Noralf Trønnes <noralf@xxxxxxxxxxx> a écrit :


 Den 24.05.2020 18.13, skrev Paul Cercueil:
  Hi list,

I'd like to open a discussion about the current support of MIPI DSI and
  DBI panels.

  Both are standards from the MIPI alliance, both are communication
protocols between a LCD controller and a LCD panel, they generally both use the same commands (DCS), the main difference is that DSI is serial
  and DBI is generally parallel.

  In the kernel right now, DSI is pretty well implemented. All the
infrastucture to register a DSI host, DSI device etc. is there. DSI
  panels are implemented as regular drm_panel instances, and their
 drivers
go through the DSI API to communicate with the panel, which makes them
  independent of the DSI host driver.

DBI, on the other hand, does not have any of this. All (?) DBI panels are implemented as tinydrm drivers, which make them impossible to use
  with regular DRM drivers. Writing a standard drm_panel driver is
  impossible, as there is no concept of host and device. All these
 tinydrm
  drivers register their own DBI host as they all do DBI over SPI.

  I think this needs a good cleanup. Given that DSI and DBI are so
similar, it would probably make sense to fuse DBI support into the current DSI code, as trying to update DBI would result in a lot of code being duplicated. With the proper host/device registration mechanism from DSI code, it would be possible to turn most of the tinydrm drivers
  into regular drm_panel drivers.

The problem then is that these should still be available as tinydrm drivers. If the DSI/DBI panels can somehow register a .update_fb() callback, it would make it possible to have a panel-agnostic tinydrm
  driver, which would then probably open a lot of doors, and help a
 lot to
  clean the mess.

I think I can help with that, I just need some guidance - I am fishing
  in exotic seas here.

  Thoughts, comments, are very welcome.

 I did look at this a few months back:

 drm/mipi-dbi: Support panel drivers
https://lists.freedesktop.org/archives/dri-devel/2019-August/228966.html

The problem with DBI is that it has reused other busses which means we don't have DBI drivers, we have SPI drivers instead (6800/8080 is not
 avail. as busses in Linux yet). DSI and DPI on the other hand has
 dedicated hw controller drivers not shared with other subsystems.

I don't think that should be much of a problem. You could have a DBI/SPI bridge, that wraps a SPI device into a DBI host, for instance. The panel drivers would just use the DBI API without having to know what's done
 behind the scene.

This will be a bridge implemented in software, are we allowed to have
software devices in the Device Tree? I though it was just allowed to
describe hardware.

It wouldn't appear in devicetree. If the panel is connected over SPI, then DBI is just the protocol it uses.

If probed as a SPI device driver, the panel's spi_driver would register an instance of the DBI/SPI host driver, then register itself as a dbi_driver. If probed from a DBI host it would just register itself as a dbi_driver.

-Paul


My initial tinydrm work used drm_panel, but I was not allowed to use it
 (at least not the way I had done it).

 Noralf.


  Cheers,
  -Paul







_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux