RK3326/S: GKD Pixel2 Suspend, GPU power-domain, panel, and mali-bifrost fixes

[Jacob-Matthew-Cook]

Three fixes for the GameKiddy GKD Pixel2 (PX30S):

0. EDIT: CRU state would be stale following resume from memory, which would throw off the apll state feeding all of the CPUs on the RK3326s. This has been fixed in a new patch, which takes inspiration from the RK3288 which had a similar problem. Now, deep-sleep is fully supported! I have correspondingly removed the quirk setting freeze as the default sleep method!

1. GPU power-domain clock-ownership workaround (024-px30s-gpu-power-domain-workaround.patch): closes a gap where rockchip_pd_power()'s own clk_bulk_enable()/clk_bulk_disable() pair still touched SCLK_GPU independently of mali_kbase's own clock ownership on PX30S, confirmed via a live pstore/ramoops capture causing a page fault in disable_gpu_power_control()'s own clk_disable_unprepare() call during CPU overclock testing.

2. generic-dsi panel driver (panel-generic-dsi.c): don't abort the power-down sequence in generic_panel_unprepare() on a failed DCS sleep command. It used to return early before disabling the enable/reset GPIOs or vdd/iovcc regulators, and before clearing ctx->prepared - since a DSI command is more likely to fail right as the rest of the pipeline is changing state (e.g. during suspend), this could leave the panel fully powered with a stale frame, and since ctx->prepared was left true, the next prepare() call would also no-op - so a single failed command during suspend could leave the screen stuck on/corrupted until reboot. Also mirrors panel prepare/reset timing from the board's previous st7701 driver approach (prepare 2->20ms, reset 1->150ms) - this fixed a real freeze/idle screen-corruption-on-wake bug found during testing, traced to insufficient settling time before the panel's DCS init sequence starts.

3. mali-bifrost (004-devfreq-resume-flush-workqueue.patch): kbase_device_suspend() flushes its devfreq workqueue after enqueuing DEVFREQ_WORK_SUSPEND, but kbase_device_resume() never waited for the mirror-image DEVFREQ_WORK_RESUME - so system resume (and rendering) could complete before devfreq_resume_device() had actually restarted the GPU's DVFS governor polling, observed as an FPS drop right after suspend/resume from freeze/idle. Made resume symmetric with suspend by flushing the workqueue before returning.

Summary

• What is the goal of this PR? Fix miscellaneous display and GPU issues typically triggered by sleep/suspend. Also just fixed the long-standing suspend-to-mem crashes triggered by CPU clock transitions!

Testing

• How was this tested? Built and tested on the GKD Pixel2. An Alpha 1.4 will be linked here for continued testing: https://github.com/Jacob-Matthew-Cook/distribution/releases/tag/pixel2-alpha-1.4
• Test results: Screen framerate no longer stutters/reduces following suspend. The device display does not hang following freeze nor resume due to a combination of increased init times and a slight tweak to the generic display driver. Suspend to mem no longer crashes the device following resume when using dynamic CPU governors (which change the clock speed frequently).

Additional Context

Most device-trees (DT) seem to have one GPU clock. Based on what I have seen, if you suspend a device with multiple GPU clocks speeds in the DT (i.e. the Pixel2) and resume, the framerate can plummet. A patch has been implemented for this. Small tweaks were implemented to mitigate an error/warning that could sometimes appear with the GPU PMU patch (see comments)

The remaining implemented changes help prevent the screen from staying on/in a stuck state when using freeze. This is important, as these hangs have caused temporary ghosting on my display.

AI Usage

While ROCKNIX doesn't have restrictions on AI tools in contributing, please be transparent about their usage as it
helps set the right context for reviewers.

Did you use AI tools to help write this code? YES. Claude was used to identify and implement the necessary changes with as minimal extra code as possible.

[Jacob-Matthew-Cook]

IMPORTANT: Suspend to Memory has been properly fixed! It was an issue with the Clock-Reset-Unit (CRU) which manages the apll. The apll could be in a bad state following resume, which caused crashes following clock changes after resume.

A patch has just been added to save and restore the CRU state during suspend/resume. This has been tested to work, and Alpha 1.4 has been updated in-place.

[Jacob-Matthew-Cook]

@stolen @r3claimer @sunshineinabox If you three could check these changes, that would be appreciated. One patch touches the generic panel driver, and another the CPU suspend/resume. If these changes are too invasive, let me know. Most of the dtsi changes just trim the comments, but I did trim down a lot of comment blocks as well.

The linked alpha is known to work well. No screen issues, no crashing when using suspend to mem!

[stolen]

Is this the only meaningful change in this file?
Hard to figure it out among all the comment changes.

[Jacob-Matthew-Cook]

Yes, this is the main change functional change. Claude left a LOT of comments, and I wanted them trimmed down as much as possible.

I did also uncomment the highest CPU clock rate, but have labeled it as "disabled" in the device-tree in case we want to test it later.

I may want to quickly add a quirk file to reduce stuttering (deep sleep unconditionally forces all clocks to the lowest speed, which have to ramp up following resume and is noticeable mid-game). If you have any input/suggestions let me know!