It's an option if the vendor makes an HDMI interface for your panel.This would be interesting to look into!In one case we resorted to taking the HDMI to MIPI bridge board that the vendor also sold, and decoding the MIPI signals that it used to initialise the display. That only vaguely matched the data we'd been given, but replicate that in the kernel driver and it worked fine. Decoding MIPI LP comms is relatively simple (it only uses data lane 0 and at a few 10's MHz), and if you're lucky your scope may have an option for decoding it.
For reference I think it was on one of our Rohde and Schwarz scopes. The full decode package was https://www.rohde-schwarz.com/uk/produc ... 05472.html, but I seem to recall resorting to manual decoding (it's non-differential, so an edge on one half of the pair is a 1, and on the other half is a 0, hence doesn't need a clock line).
Oops. Easily done though.I actually may have found the error as I was powering the IC with IOVCC = 3.3V to allow the reset signal to be 3.3V also. This worked fine for ILI9881 as it had a max IOVCC = 3.3V.
Now I found that ST7703 has a max IOVCC = 2.0V. So maybe I fried both of the two display samples I have![:shock:]( "Shocked")
Strange though that I can still write/read registers from ST7703, but I guess a part of the IC circuit could still be fried from the overvoltage.
Now I'm waiting for new samples of the ST7703 based display to see if it works with IOVCC = 1.8V. I'm curious to know though if the IC can accept 3.3V on reset without breaking. Otherwise I guess I need to logic shift the signal.
If it was an overvoltage on IOVCC and the reset line, then I would have expected that to be fairly fundamental and break most of the chip.
Statistics: Posted by 6by9 — Mon Jul 22, 2024 2:32 pm