Switch OLED panel above 64 Hz: a full map of what blocks it (and a request for the DDIC register map)

I've spent a while trying to push the Switch OLED panel (Samsung AMS699VC01, ID 0x2050) past 60 Hz. 64 Hz works. Above that it breaks, and I now know a lot about why — but not everything. Posting all of it, including the dead ends, so nobody has to repeat them.

Everything below was verified by reading hardware back or by counting vsync pulses. Mode queries to the driver don't count as measurement — I lost a week to a log line that reported 90 Hz while the panel was running at 60.

What works: 64 Hz, via an exefs patch of the pixel clock in nvservices at mapped 0xF28FC (78000 → 83200 kHz).

What I found along the way:

The Switch display driver computes DSI D-PHY timings with the same algorithm as the L4T kernel — its constants sit in the nvservices image at 0x3A090..0x3A17C. My reimplementation reproduces live hardware registers byte for byte at both 60 and 64 Hz.
The mode structure lives at mapped 0xF2A08, right next to the pixel clock. Ten fields, from which DSI_PHY_TIMING_0/1/2 are assembled by code at +0x39FD4.
HS-PREPARE is hard-coded, not computed: mov w24, #0x3 at 0x39F58. The formula with the picosecond constants sits in a branch that never runs in the normal configuration. This silently forces 60 Hz timings at any clock. Patching the instruction works and is verified by reading memory back.
The driver blanks VIDEO_ENABLE while sending DCS packets (function at +0x3A2E0). That's why the common belief "you can't write to the panel under HOS" is wrong — you can, you just have to do it the way the driver does.
Panel side: the 0xE2 lock has five 16-bit groups; level 3 needs a 7-byte packet (hekate only sends 5). Write channel confirmed by readback. Panel reset is GPIO port V pin 2. Full panel re-init under HOS works — reset, resend the init sequence from the device tree, restore video.
Refuted by hardware, so you don't have to: preemphasis to max, pad drive to max, D-PHY recomputation, horizontal blanking, cold start from the bootloader, the S6E3FC3 and S6E3HC4 frequency-select encodings, MAUCCTR, the B1 scan table (it truncates the frame, doesn't speed it up), and holding registers against the driver (unwinnable — 7 clock takeovers in 30 seconds).

Also: the "working 90 Hz L4T build" that gets mentioned around is not what people think. I disassembled it. Its bootloader has stock panel timings byte for byte, and its device tree says nvidia,dsi-refresh-rate = <0x3C> — sixty. The L4T panel driver contains no frequency commands at all, only brightness and colour mode.

Where the wall is: line rate. 1280 active lines at 12.82 µs is 16.4 ms even with zero blanking — about 61 Hz of physical ceiling, and the ~8% margin runs out at 64. For 120 Hz the line has to take 6.4 µs, which is a different operating mode of the line driver, not a tuning parameter.

What I need: the register map of this panel's DDIC. A code search across all of GitHub for the 0xE2, 0x5A, 0x5A unlock idiom returns zero results — no known Samsung family uses it (FC3/HC4/HA8 all use F0/FC). This panel doesn't match anything published.

Everything else is ready: confirmed write channel, honest frequency measurement, a file-driven probe tool that needs no rebuilds, working panel re-init, timings verified against hardware. One document turns brute force into work.

Full writeup, patches and the timing algorithm: https://github.com/Dimasick-git/switch-oled-refresh-rate
Panel register dump and the level-3 lock unlock: https://github.com/Dimasick-git/switch-oled-panel-lvl3

If you have the register map, or even just know which DDIC is in this panel — open an issue. Happy to be told I'm wrong about the wall, too, as long as it's with a measurement.

 

[masagrator]

That's why the common belief "you can't write to the panel under HOS" is wrong

Common? Color correction in SaltyNX debunked that over a year ago.

And tl;dr for noobs - no, it's not about showing 120 FPS on OLED panel. It's about switching internal refresh mode from 60 to 120 Hz. Many OLEDs have no tolerancy for showing anything above 75 FPS, ~90 FPS being the best case.

 

[Dimasick]

@masagrator — you're right, and I'll fix the wording. SaltyNX's colour correction already showed panel writes work under HOS; calling it a "common belief" was sloppy of me. The part that's actually worth keeping from that section is narrower: the driver blanks VIDEO_ENABLE for the duration of a DCS packet (0x3A2E0), and that specific detail is what made my own writes land reliably during video

 

[Nagaa]

The "working 90 Hz L4T build" has never been a thing, that's just a false assumption made by idiotic people like Souls and Cooler

I tried to get 90 Hz working on L4T in the past and ran into the same ~64 Hz limit, beyond which the panel would become unresponsive/dead.
I don't know what build you "disassembled," but probably not the right one since it wasn't shared if i remember and all of this didn't even worked anyway, it was just some very basic increase on PCLK and timings adjustement.

Anyway, good luck with your research on this

 

[Dimasick]

@Nagaa — that's the most useful reply in the thread, thank you. You hitting the same ~64 Hz wall on L4T independently is stronger evidence than anything in my writeup, because we got there by completely different routes and without knowing about each other.

And you're right to push back on the disassembly. What I had was a build someone passed along as "the 90 Hz one" — its bootloader had stock panel timings byte for byte and its device tree said nvidia,dsi-refresh-rate = <0x3C>. So it matches your description exactly: a basic PCLK bump with timing adjustments, not a panel mode change. I should have said "the build I was given" rather than implying it was the build. Corrected.

So we now have two independent measurements of the same ceiling, from two different software stacks. That's worth more than either of us getting to 90.