drivers: mipi_dbi: add support for parallel 8080/6800 modes using GPIO #78453
Conversation
|
Hello @stgloorious, and thank you very much for your first pull request to the Zephyr project! |
zephyrbot
requested review from
danieldegrasse,
decsny,
galak and
jfischer-no
Instead of always using the SPI MIPI DBI mode (type C), look up the mipi-mode from the device tree and only set the mode to MIPI_DBI_MODE_SPI_4WIRE as a fallback in case the property is not given. Signed-off-by: Stefan Gloor <code@stefan-gloor.ch>
stgloorious
force-pushed
the
stgloorious/mipi-dbi-gpio
branch
2 times, most recently
from
e273b49
to
5f4758c
Compare
stgloorious
force-pushed
the
stgloorious/mipi-dbi-gpio
branch
from
5f4758c
to
5c42e61
Compare
|
Hi @danieldegrasse, thank you very much for your review. I should have addressed all the issues mentioned by you or the CI. I'll update again if there are still CI problems once it runs through. Let me know what you think about the changes and if you think anything else could be improved. |
stgloorious
force-pushed
the
stgloorious/mipi-dbi-gpio
branch
from
5c42e61
to
30aa0d4
Compare
The MIPI DBI API supports MIPI DBI controllers type A, B, and C (except with 16 write clocks). Update the documentation accordingly. Signed-off-by: Stefan Gloor <code@stefan-gloor.ch>
Introduce GPIO-based driver for MIPI DBI class that allows MIPI DBI type A and B displays to be used on general platforms. Since each data pin GPIO can be selected individually, the bus pins are set in a loop, which has a significant negative impact on performance. When using 8-bit mode and all the data GPIO pins are on the same port, a look-up table is generated to set the whole port at once as a performance optimization. This creates a ROM overhead of about 1 kiB. Tested 8-bit 8080 mode with ILI9486 display on nRF52840-DK board. Signed-off-by: Stefan Gloor <code@stefan-gloor.ch>
stgloorious
force-pushed
the
stgloorious/mipi-dbi-gpio
branch
from
30aa0d4
to
61130c7
Compare
|
The CI doesn't like the documentation change. What am I doing wrong? |
|
It failed again with the new forced push in check-valid-pr. For some reason it checks the old commit 30aa0d4 against the current HEAD 61130c7, and that seems to fail because probably |
That is odd, I haven't seen this check fail before. I'll investigate if it fails again there |
|
Hi @stgloorious! To celebrate this milestone and showcase your contribution, we'd love to award you the Zephyr Technical Contributor badge. If you're interested, please claim your badge by filling out this form: Claim Your Zephyr Badge. Thank you for your valuable input, and we look forward to seeing more of your contributions in the future! 🪁 |
Introduce GPIO-based driver for MIPI DBI class that allows MIPI DBI type A and B displays to be used on general platforms. Until now, only Type C (SPI-based) MIPI DBI displays and some SoC-specific peripherals are supported for the mipi-dpi driver class.
Since each data pin GPIO can be selected individually in the device tree, the data bus pins are set in a loop for each transmitted byte. Obviously this has a significant negative impact on performance, however, it enables maximum flexbility and compatibility with all kinds of systems.
When using 8-bit mode and all the data GPIO pins are on the same port, a data port look-up table is generated automatically to set the whole port at once as a performance optimization. This creates a RAM overhead of about 1 kiB, and is only implemented for 8-bit mode as the table grows exponentially with bus width. To me, it seems like a reasonable tradeoff between RAM overhead and performance as MCUs beefy enough to run a such a TFT display usually have enough RAM to spare.
I tested the 8-bit 8080 mode with a ILI9486 display shield on a Nordic nRF52840-DK board. The other modes are untested.
Any comments or feedback are appreciated.