You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I knew it was possible for the controller to have the initialisation builtin, but in my 9 years of dealing with these SPI displays I have never actually heard of one, until now.
We can't have a generic compatible for these displays, the DT maintainer was very specific that the compatible should have 2 values, the first should be for a specific display and the second should be panel-mipi-dbi-spi.
I did consider making the firmware file optional, but decided against it since I hadn't seen such a display in the wild and having it mandatory would give the user an error message should it be forgotten. I made the driver for the maker community and the majority of those are not kernel savvy people. You know where to look (or someone tells you where) if the DRM device doesn't show up, it's harder for novices to troubleshoot if the display doesn't work but the DRM device is present. At least this is my thinking, I have seen people struggle getting their displays to work.
In your driver you do set INVERT_MODE and ADDRESS_MODE for the display, so it looks like not all configuration is pre-programmed?
I'm also not sure how PIXEL_FORMAT should have been handled, the DBI spec supports RGB666 so the driver should not block support for that in my opinion.
Sipeed MaixSense has a LCD panel that does not need any vendor-specific commands to initialize (because all configuration is programmed into OTP).
For this kind of panels, only MIPI DCS commands are needed.
Should we implement the generation of MIPI DCS control stream in panel-mipi-dbi and drop the need of command file?
See sipeed/linux@b0038b7 for an example.
The text was updated successfully, but these errors were encountered: