Steps for Porting a Driver

I know this is not an easy question, however, can someone, maybe @mrlambchop, give me the 20,000 ft. level view of what it would take to port my own display driver? I would like to try my hand at it myself.

I just need names and locations of files I would need to modify. I am attempting to do this without reimaging the Tachyon. I know enough to be dangerous, such as the bootloader being of an android-esq flavor and that the tachyon doesn’t use display overlays such as the Raspberry Pi does.

I really want my screen (unsupported driver IC) to work as it is perfect for my project. I am willing to do the work and report back once I have anything worth reporting.

I have done a 7 inch AMOLED with in-cell touch proof-of-concept working with RPi 5 (which uses the same, I think, 22-pin DSI connector)

To answer your question, you need (very briefly):

  • a CORRECT data-sheet giving you the information of TCON, electronic characteristics, pin descriptions, MIPI DSI commands (DCS) to start the panel etc.
  • Setup a test environment with lots of jumper wire, connector boards and FPC cables (lots of panels 39-pin MIPI DSI, only RPi / Tachyon uses 22-pin to my knowledge); bench power, logic analyser, oscilloscope and a multimeter (to observe / debug the power on timings of your panel)
  • Write a driver based on the panel display driver IC as well as the touch panel IC, that will involve device source tree, compiling and loading a kernel module
  • Lots of patience

To be honest it’s quite a specific skill set but I managed to get the basics in about 6 weeks on-and-off with a bit of luck.

There’s a lot of trivial details of MIPI specific knowledge one needs to know before getting started. One critical point is that you have to squeeze as much information from the vendor of the panel as possible (I assume it’s a Chinese vendor / manufacturer) from a random working device-source-tree to some .txt for DCS commands and some outdated / wrong data-sheet to piece together all the information needed to write the driver.

If you are still keen, you can ping me on DM.

As for the ‘file to edit’: you need to write a Linux kernel driver for the panel and you can look into drivers/gpu/drm/panel from the Linux kernel source tree, inside there are a few .c that you can use as a template to start. And then you need to write and compile a .dts file to load your driver.

Some folks contribute to write the driver for some panel IC and upstream the source code while there are some display manufacturers that only put binary blobs in (perhaps to ‘protect’ their interest). If I remember correctly, waveshare and RPi display both don’t have their drivers in the form of source code so they will then have to re-compile and maintain it themselves. There’s some changes (if I remember correctly) of the DRM API and also a few changes in MIPI DSI driver between kernel 5.x and 6.x so sometimes even if you are given a ‘driver’ by the vendor, it will probably not work with Particle’s effort with Qualcomm on mainline Linux - as lots of displays are produced to aid the Rockchip / Mediatek SBC / tablet which they are very behind mainline on kernel 5.x.