Den 24.05.2020 23.33, skrev Paul Cercueil: > > > Le dim. 24 mai 2020 à 23:24, Noralf Trønnes <noralf@xxxxxxxxxxx> a écrit : >> >> >> Den 24.05.2020 22.42, skrev Paul Cercueil: >>> >>> >>> 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. >> >> How do you attach a panel to the DBI device if it doesn't appear in DT? > > When probed from a DBI host controller, the panel's devicetree binding > would look like this: > > &dbi_host { > > panel { > compatible = "my,dbi-device"; > }; > }; > > When probed from SPI it would appear in DT like this: > > &spi { > > panel@0 { > reg = <0>; > compatible = "my,dbi-device-spi"; > }; > }; > > In that case, the driver would create a SPI-DBI bridge, but that is an > implementation detail that doesn't belong in devicetree. You said that you want to turn the tinydrm drivers into regular drm_panel drivers. If this is a drm_panel driver, who calls drm_of_find_panel_or_bridge() to make use of it? Or is this drm_panel driver a full blown DRM driver? (btw. tinydrm.ko is gone now, all drivers in tiny/ are regular DRM drivers) I'm curious, what kind of device is going to use this? It's a bit strange to spend so many pins on the display interface and choose DBI instead of DPI. Noralf. > > >> Another problem is that the DBI panel uses SPI both for framebuffer >> upload and controller initialization. How shall this be handled when the >> panel driver needs SPI for init and the DBI bridge needs SPI for frame >> upload? > > Does the panel driver need SPI for init? I don't think so. It needs to > send DBI commands over SPI, yes. Only the DBI-SPI bridge would control > the SPI device. > > -Paul > >>> >>> 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
