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?
(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
