Den 25.05.2020 04.05, skrev Paul Cercueil: > > > Le lun. 25 mai 2020 à 2:46, Noralf Trønnes <noralf@xxxxxxxxxxx> a écrit : >> >> >> 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? > > What I had in mind was a generic tinydrm driver that fetched the > drm_panel from devicetree. Which is what you were working on, right? > Ok, I guess was confused by the DBI SPI bridge term and figured this was a DBI device that panel devices was attached to. My proposal was turning a DRM panel driver into a full blown DRM driver which AFAIR was what I was not allowed to do when working on tinydrm. The reason I didn't take my work any further is because Thierry didn't take interest in it, he would need to be ok with turning drm_panel drivers into regular DRM drivers. Noralf. >> (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. > > I'm not sure the number of pins changes that much between the two, does > it? Here I have 16 pins for command/data, one pin for command/data > signal, and the pixel clock. > > DBI has advantages over DPI, e.g. you don't need a separate SPI/I2C to > configure the panel, and data is only transferred when a new frame is > available, which means power savings when displaying still images, or a > variable refresh rate when displaying video. > > -Paul > >>> >>> >>>> 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
