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.
Cheers, -Paul
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.
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
On Sun, May 24, 2020 at 7:46 PM Noralf Trønnes noralf@tronnes.org 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.
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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Daniel,
Le dim. 24 mai 2020 à 20:35, Daniel Vetter daniel@ffwll.ch a écrit :
On Sun, May 24, 2020 at 7:46 PM Noralf Trønnes noralf@tronnes.org 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.
Cheers, -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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
-- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
Hi,
On 24/05/2020 21:50, Paul Cercueil wrote:
Hi Daniel,
Le dim. 24 mai 2020 à 20:35, Daniel Vetter daniel@ffwll.ch a écrit :
On Sun, May 24, 2020 at 7:46 PM Noralf Trønnes noralf@tronnes.org 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@gmai...) from dillon.minfei@gmail.com, it uses the STM32 DPI engine to feed a ili9341. Seems it would match your issue.
Neil
Cheers, -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@lists.freedesktop.org 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Neil,
Le lun. 25 mai 2020 à 16:58, Neil Armstrong narmstrong@baylibre.com a écrit :
Hi,
On 24/05/2020 21:50, Paul Cercueil wrote:
Hi Daniel,
Le dim. 24 mai 2020 à 20:35, Daniel Vetter daniel@ffwll.ch a écrit :
On Sun, May 24, 2020 at 7:46 PM Noralf Trønnes noralf@tronnes.org 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@gmai...) from dillon.minfei@gmail.com, 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@lists.freedesktop.org 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Den 24.05.2020 20.35, skrev Daniel Vetter:
On Sun, May 24, 2020 at 7:46 PM Noralf Trønnes noralf@tronnes.org 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.
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 :-)
Unfortunately I don't have the two RFC series in my inbox anymore. I can see from this coverletter that drm_panel was removed after RFC v2:
drm: Add support for tiny LCD displays https://patchwork.freedesktop.org/series/4520/
The problem is that there's no discussion in the relevant patch: https://patchwork.freedesktop.org/patch/80117/?series=4520&rev=2
What I remember is that someone said I couldn't use it, then I replied that someone suggested drm_panel to me in an earlier discussion, but I couldn't remember who. Then Emil chimed in and said he was the one that suggested it.
Anyways let's see what Paul comes up with, if he finds a way to move SPI DBI over to drm_panel than I'm all for it. If not we'll just have to live with a hybrid solution I guess, one for MIPI DBI parallel bus for his hardware type and one for MIPI DBI SPI.
The Pi also has a hw block for parallel DBI, downstream there's a driver that treats it as a generic parallel bus, since it's an 8080 compatible bus. If I'm not mistaken the BeagleBone Black also has a bus like this.
When I started on tinydrm I had the idea to try and add a parallel bus type to Linux (even had a prototype for bit banging gpio) that I could use with DBI. This would make the bus available for things like FPGA's also, not just displays. I gave up on the idea since parallel DBI uses a lot of pins to upload a frame to display GRAM, much better to drive the panel directly through MIPI DPI (better fps), which all these SoC's also support.
Noralf.
Cheers, Daniel
Noralf.
Cheers, -Paul
dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Sun, 24 May 2020 at 19:35, Daniel Vetter daniel@ffwll.ch wrote:
On Sun, May 24, 2020 at 7:46 PM Noralf Trønnes noralf@tronnes.org 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.
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
Coming late to the party - the series looks like a great step forward.
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 :-)
This pretty much ^^. Does anyone have a link/summary of the concerns?
From userspace POV - having these as panel makes sense.
Currently as new tiny drm _driver_ gets added, userspace has to be updated to deal with it ... every so often.
Additionally having both DPI and DBI code for the given panel alongside one another makes the overall picture clearer.
-Emil Aside: mipi_dbi API should grow a drm_ prefix.
Den 28.05.2020 17.27, skrev Emil Velikov:
On Sun, 24 May 2020 at 19:35, Daniel Vetter daniel@ffwll.ch wrote:
On Sun, May 24, 2020 at 7:46 PM Noralf Trønnes noralf@tronnes.org 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.
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
Coming late to the party - the series looks like a great step forward.
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 :-)
This pretty much ^^. Does anyone have a link/summary of the concerns?
I found the thread where you Emil suggested I look at drm_panel:
https://lists.freedesktop.org/archives/dri-devel/2015-September/091215.html
I used drm_panel in the tinydrm RFC's, but dropped it in version 1 according to the changelog. I think it was Thierry that didn't like how it was used, but I'm not entirely sure. Unfortunately I can't find the emails. There's nothing on the preceding RFC v2, so looks like it's gone somehow:
https://patchwork.freedesktop.org/patch/80117/?series=4520&rev=2
Noralf.
From userspace POV - having these as panel makes sense. Currently as new tiny drm _driver_ gets added, userspace has to be updated to deal with it ... every so often.
Additionally having both DPI and DBI code for the given panel alongside one another makes the overall picture clearer.
-Emil Aside: mipi_dbi API should grow a drm_ prefix.
Hi Noralf,
On Wed, 3 Jun 2020 at 13:15, Noralf Trønnes noralf@tronnes.org wrote:
Den 28.05.2020 17.27, skrev Emil Velikov:
On Sun, 24 May 2020 at 19:35, Daniel Vetter daniel@ffwll.ch wrote:
On Sun, May 24, 2020 at 7:46 PM Noralf Trønnes noralf@tronnes.org 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.
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
Coming late to the party - the series looks like a great step forward.
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 :-)
This pretty much ^^. Does anyone have a link/summary of the concerns?
I found the thread where you Emil suggested I look at drm_panel:
https://lists.freedesktop.org/archives/dri-devel/2015-September/091215.html
Guilty as charged ;-)
Guess I should ask some silly questions first: Was tinydrm modelled as a drm driver itself, because the idea of drm_panel::update() callback seemed dirty? That's the only concern raised that I can find on the list... It's effectively in the link you provided.
As far as I can tell, first RFC was already using the tiny drm driver model. https://patchwork.freedesktop.org/patch/77161/
Yet again, do we actually need the callback? The mipi-dbi(?) spi panels in panel/ get away w/o one, while pushing far more pixels onto the screen (tiny has resolutions up-to 320x480, panel up-to 480x800).
That said, I'm a fan of lifting the tiny (panel) drivers into drm-panel and exposing them via dbi-bus sounds reasonable IMHO. Seems like Paul has the DT dbi/spi bus questions covered as well.
Patches illustrating his ideas would be more than welcome.
-Emil
Hi Emil,
Den 03.06.2020 22.25, skrev Emil Velikov:
Hi Noralf,
On Wed, 3 Jun 2020 at 13:15, Noralf Trønnes noralf@tronnes.org wrote:
Den 28.05.2020 17.27, skrev Emil Velikov:
On Sun, 24 May 2020 at 19:35, Daniel Vetter daniel@ffwll.ch wrote:
On Sun, May 24, 2020 at 7:46 PM Noralf Trønnes noralf@tronnes.org 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.
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
Coming late to the party - the series looks like a great step forward.
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 :-)
This pretty much ^^. Does anyone have a link/summary of the concerns?
I found the thread where you Emil suggested I look at drm_panel:
https://lists.freedesktop.org/archives/dri-devel/2015-September/091215.html
Guilty as charged ;-)
I guess it turns out that you were right :-)
Guess I should ask some silly questions first: Was tinydrm modelled as a drm driver itself, because the idea of drm_panel::update() callback seemed dirty? That's the only concern raised that I can find on the list... It's effectively in the link you provided.
As far as I can tell, first RFC was already using the tiny drm driver model. https://patchwork.freedesktop.org/patch/77161/
Yet again, do we actually need the callback? The mipi-dbi(?) spi panels in panel/ get away w/o one, while pushing far more pixels onto the screen (tiny has resolutions up-to 320x480, panel up-to 480x800).
That said, I'm a fan of lifting the tiny (panel) drivers into drm-panel and exposing them via dbi-bus sounds reasonable IMHO. Seems like Paul has the DT dbi/spi bus questions covered as well.
Patches illustrating his ideas would be more than welcome.
+1
When Paul has found a solution for his hw we'll find a way to integrate support for these MIPI DBI SPI drivers.
Noralf.
Hi Noralf,
Le dim. 24 mai 2020 à 19:46, Noralf Trønnes noralf@tronnes.org 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.
Cheers, -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
Den 24.05.2020 21.54, skrev Paul Cercueil:
Hi Noralf,
Le dim. 24 mai 2020 à 19:46, Noralf Trønnes noralf@tronnes.org 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.
Noralf.
Cheers, -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
Le dim. 24 mai 2020 à 22:14, Noralf Trønnes noralf@tronnes.org a écrit :
Den 24.05.2020 21.54, skrev Paul Cercueil:
Hi Noralf,
Le dim. 24 mai 2020 à 19:46, Noralf Trønnes noralf@tronnes.org 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
Den 24.05.2020 22.42, skrev Paul Cercueil:
Le dim. 24 mai 2020 à 22:14, Noralf Trønnes noralf@tronnes.org a écrit :
Den 24.05.2020 21.54, skrev Paul Cercueil:
Hi Noralf,
Le dim. 24 mai 2020 à 19:46, Noralf Trønnes noralf@tronnes.org 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? 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?
Noralf.
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
Le dim. 24 mai 2020 à 23:24, Noralf Trønnes noralf@tronnes.org a écrit :
Den 24.05.2020 22.42, skrev Paul Cercueil:
Le dim. 24 mai 2020 à 22:14, Noralf Trønnes noralf@tronnes.org a écrit :
Den 24.05.2020 21.54, skrev Paul Cercueil:
Hi Noralf,
Le dim. 24 mai 2020 à 19:46, Noralf Trønnes noralf@tronnes.org 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.
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
Den 24.05.2020 23.33, skrev Paul Cercueil:
Le dim. 24 mai 2020 à 23:24, Noralf Trønnes noralf@tronnes.org a écrit :
Den 24.05.2020 22.42, skrev Paul Cercueil:
Le dim. 24 mai 2020 à 22:14, Noralf Trønnes noralf@tronnes.org a écrit :
Den 24.05.2020 21.54, skrev Paul Cercueil:
Hi Noralf,
Le dim. 24 mai 2020 à 19:46, Noralf Trønnes noralf@tronnes.org 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 > >
Le lun. 25 mai 2020 à 2:46, Noralf Trønnes noralf@tronnes.org a écrit :
Den 24.05.2020 23.33, skrev Paul Cercueil:
Le dim. 24 mai 2020 à 23:24, Noralf Trønnes noralf@tronnes.org a écrit :
Den 24.05.2020 22.42, skrev Paul Cercueil:
Le dim. 24 mai 2020 à 22:14, Noralf Trønnes noralf@tronnes.org a écrit :
Den 24.05.2020 21.54, skrev Paul Cercueil:
Hi Noralf,
Le dim. 24 mai 2020 à 19:46, Noralf Trønnes noralf@tronnes.org 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 >> >>
Den 25.05.2020 04.05, skrev Paul Cercueil:
Le lun. 25 mai 2020 à 2:46, Noralf Trønnes noralf@tronnes.org a écrit :
Den 24.05.2020 23.33, skrev Paul Cercueil:
Le dim. 24 mai 2020 à 23:24, Noralf Trønnes noralf@tronnes.org a écrit :
Den 24.05.2020 22.42, skrev Paul Cercueil:
Le dim. 24 mai 2020 à 22:14, Noralf Trønnes noralf@tronnes.org a écrit :
Den 24.05.2020 21.54, skrev Paul Cercueil: > Hi Noralf, > > Le dim. 24 mai 2020 à 19:46, Noralf Trønnes > noralf@tronnes.org 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 >>> >>> > > >
Hi Paul.
On Sun, May 24, 2020 at 06:13:16PM +0200, Paul Cercueil wrote:
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.
We could add proper support for a DBI bus, like we have today for DSI. This seems like the simple approach as we then have a DSI and a DBI bus.
But many panels implement support for both DSI and DBI and then what to do then? We could register a driver based on the configuration like we do in some drivers already. But this would push logic to the dirvers which we would like to keep simple. We could also try to extend the current DSI bus support to cover DBI too - but thats seems also to be not so elegant.
I atually started on the framework bits for implementing a DBI bus but got sidetracked so did not get far. And back then I also was concerned if we should go for a dedicated DBI bus or we should do something else.
I have attached two WIP patches from when I looked at it. The binding needs extra work and the code may not even build...
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.
We should find a clean solution for new drivers and then we can see what to do for the existing drivers. We only have a few existing tiny drivers for now - and knowing the amount of panel candidates that exist we have to make it simple to add support for new panels, both DBI, DSI and DPI variants.
And if we could then find a way to allow the user to specify the init sequence without modifying the kernel then we could make it much simpler again. Noralf have a solution for this in staging but I think we need something else in DRM. I have had in mind if we could ut something in initrd or some sort but that is down on the TODO list to look at.
Sam
Hi Sam,
Le dim. 24 mai 2020 à 22:06, Sam Ravnborg sam@ravnborg.org a écrit :
Hi Paul.
On Sun, May 24, 2020 at 06:13:16PM +0200, Paul Cercueil wrote:
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.
We could add proper support for a DBI bus, like we have today for DSI. This seems like the simple approach as we then have a DSI and a DBI bus.
But many panels implement support for both DSI and DBI and then what to do then? We could register a driver based on the configuration like we do in some drivers already. But this would push logic to the dirvers which we would like to keep simple. We could also try to extend the current DSI bus support to cover DBI too - but thats seems also to be not so elegant.
My controller supports 8/16/18-bit commands, 8/16/18-bit data, serial or parallel. There is nothing DBI-specific in that, but there is nothing DSI-specific either; it is more of a bus controller, on which the DSI and DBI protocols can be used. I think the way to go would be to separate the buses from the protocols. Ideally, I would have a bus driver, with "mipi-dsi" and "mipi-dbi-8080" flags in devicetree, and the core's DSI/DBI code would work on top of the bus API.
I atually started on the framework bits for implementing a DBI bus but got sidetracked so did not get far. And back then I also was concerned if we should go for a dedicated DBI bus or we should do something else.
I have attached two WIP patches from when I looked at it. The binding needs extra work and the code may not even build...
The code looks pretty much like what I was experimenting with before sending the email. But I think we can do better.
The binding specifies the 'mipi-dbi-type' while in practice the same hardware may be able to support several types, and specifies a bunch of GPIOs which wouldn't apply in my case (since they are handled by the controller).
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.
We should find a clean solution for new drivers and then we can see what to do for the existing drivers.
Agreed.
Cheers, -Paul
We only have a few existing tiny drivers for now - and knowing the amount of panel candidates that exist we have to make it simple to add support for new panels, both DBI, DSI and DPI variants.
And if we could then find a way to allow the user to specify the init sequence without modifying the kernel then we could make it much simpler again. Noralf have a solution for this in staging but I think we need something else in DRM. I have had in mind if we could ut something in initrd or some sort but that is down on the TODO list to look at.
Sam
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
Emil Velikov -
Neil Armstrong -
Noralf Trønnes -
Paul Cercueil -
Sam Ravnborg