Hi Neil,
Le lun. 25 mai 2020 à 16:58, Neil Armstrong <narmstrong@xxxxxxxxxxxx>
a écrit :
Hi,
On 24/05/2020 21:50, Paul Cercueil wrote:
Hi Daniel,
Le dim. 24 mai 2020 à 20:35, Daniel Vetter <daniel@xxxxxxxx> a
écrit :
On Sun, May 24, 2020 at 7:46 PM Noralf Trønnes
<noralf@xxxxxxxxxxx> wrote:
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.
Do we have drivers with dbi support that actually want to reuse the
tinydrm drivers? Good clean is all good, but we need a solid reason
for changing stuff. Plus we need to make sure we're not just
rediscovering all the old reasons for why we ended up where we are
right now in the first place.
I'm trying to interface a ILI9331 based panel that has a DBI/8080
interface. The ILI9331 is very similar to the ILI9341 which already
has a tinydrm driver. My SoC has a dedicated DBI/DSI controller, and
I have currently no way to make it work with the ingenic-drm driver.
The idea of a generic drm_panel tinydrm driver was to avoid
duplicating code between regular panel and tinydrm drivers, but the
focus of my email was more to point that right now there is no way
to interface a DBI panel with a regular DRM driver. Unlike DSI,
there are currently no drivers with DBI support as there is no API
to register a host DBI driver or a DBI panel driver. This is what's
really missing here.
Did you have a look at "Enable ili9341 and l3gd20 on stm32f429-disco"
(http://lkml.kernel.org/r/1590378062-7965-1-git-send-email-dillon.minfei@xxxxxxxxx)
from dillon.minfei@xxxxxxxxx,
it uses the STM32 DPI engine to feed a ili9341. Seems it would match
your issue.
Note that DBI and DPI are different things. Here the ILI9341 uses SPI
directly instead of a DBI API for sending its commands, which means the
driver won't work on e.g. a 8080 bus.
-Paul
> 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.
My initial tinydrm work used drm_panel, but I was not allowed to
use it
(at least not the way I had done it).
Hm, do we have a summary of all the discussions/reasons from back
then? All I remember is that it's all that simple, you've done a
lot
of work exploring all the options, I'm fairly sure I suggested
drm_panel even back then but somehow it didn't really work. Would
be
good if we make sure we don't at least repeat history too much :-)
Cheers, Daniel
Noralf.
>
> Cheers,
> -Paul
>
>
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
