This is a new driver for ILI9225 based display panels.
There are a couple of things that stand out:
1. Despite my best efforts, I could not find a name for this display[1], so I have made up a generic name for it. If someone recognizes this and has a name for it, please speak up. The best documentation I could find was here[2].
2. There is quite a bit of one-off code copied from mipi-dbi.c. Based on the feedback from a previous patch series, I'm guessing that we don't want to modify mipi-dbi.c to accommodate the ILI9225 controller because the ILI9225 controller does not use standard MIPI commands. ILI9225 has it's own non-standard command set, but other than that, it pretty much matches the generic mipi-dbi driver in all regards.
Code that could be easily shared:
a. ili9225_buf_copy() is exactly the same as mipi_dbi_buf_copy() - ili9225_buf_copy() is used in ili9225_fb_dirty() - mipi_dbi_buf_copy() is static in mipi-dbi.c
b. ili9225_spi_cmd_max_speed() is exactly the same as mipi_dbi_spi_cmd_max_speed() - ili9225_spi_cmd_max_speed() is used in ili9225_command() below, so would not need to be copied if mipi_dbi_typec3_command() could be shared - mipi_dbi_spi_cmd_max_speed() is static in mipi-dbi.c
c. ili9225_command() is nearly the same as mipi_dbi_typec3_command() - a few unused lines were removed so I didn't have to copy even more code, but these would not be an issue if code was shared - cmd == ILI9225_WRITE_DATA_TO_GRAM instead of cmd == MIPI_DCS_WRITE_MEMORY_START
d. ili9225_spi_init() is nearly the same as mipi_dbi_spi_init() - a few unused lines were removed so I didn't have to copy even more code, but these would not be an issue if code was shared - mipi->command = ili9225_command instead of mipi->command = mipi_dbi_typec3_command - this function would not need to be copied if mipi_dbi_typec3_command() was modified to work with the ILI9225 command set too
e. ili9225_init() is nearly the same as mipi_dbi_init() - only difference is ili9225_fb_funcs instead of mipi_dbi_fb_funcs
3. I haven't tried it, but I believe that it is possible to implement DRM_FORMAT_RGB888 directly instead of simulating DRM_FORMAT_XRGB8888. I don't know if there would be any real benefit to doing this. I am not familiar enough with userspace programs/libraries to know if this mode is universally used. And, it will only physically be 18-bit color instead of 24-bit but will increase the amount of data transferred by 50% (3 bytes per pixel instead of 2). Implementing this would have a side effect of making the one-off shared code (described above) more than one-off though.
[1]: https://github.com/Nkawu/TFT_22_ILI9225 [2]: http://www.hotmcu.com/22-176x220-tft-lcd-with-spi-interface-p-316.html
David Lechner (2): dt-bindings: Add binding for Ilitek ILI9225 display panels drm/tinydrm: add driver for ILI9225 panels
.../devicetree/bindings/display/ilitek,ili9225.txt | 25 + MAINTAINERS | 6 + drivers/gpu/drm/tinydrm/Kconfig | 10 + drivers/gpu/drm/tinydrm/Makefile | 1 + drivers/gpu/drm/tinydrm/ili9225.c | 547 +++++++++++++++++++++ 5 files changed, 589 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9225.txt create mode 100644 drivers/gpu/drm/tinydrm/ili9225.c
-- 2.7.4