Exynos 3830 Driver Work -

Feature Title: Implementation and Stabilization of Exynos 3830 SoC Drivers

6. Risks & Mitigations

| Risk | Impact | Mitigation | | :--- | :--- | :--- | | Undocumented Hardware Changes | High; blocks may not function or hang the system. | Cross-reference with similar SoC drivers (e.g., Exynos 850/990) and maintain close contact with hardware vendor FAE. | | Clock Tree Complexity | Medium; incorrect rates may break peripherals. | Implement strict clock validation in the driver; test UART rates early to verify PLL logic. | | GPL License Compliance | Legal; violation of open-source licenses. | Ensure all imported code is properly attributed and licensed; run license scanner on new files. |

1. The CMU (Clock Management Unit) Overhaul

The most prolific work has been in drivers/clk/samsung/. The Exynos 3830’s clock tree is complex, requiring precise gating to save battery life.

• Patches submitted: A series of 14 patches reworking the clk-exynos3830.c driver.
• Key fix: Correcting the PLL (Phase-Locked Loop) locking sequence for the Cortex-A73 cluster. Previous generic drivers caused race conditions during frequency scaling, leading to spontaneous reboots on the Tab A. The new work introduces dedicated clk_pll_ops for the 3830’s specific PLL types.

Conclusion

The Exynos 3830 is not a hero chip. It is a workhorse. The driver work currently underway is a testament to the principle that good hardware should not become e-waste just because the vendor stopped providing Android updates.

By fixing the clocks, stabilizing the USB PHY, and silencing the memory controller errors, the open-source community is slowly turning the Exynos 3830 from a proprietary brick into a standard Linux platform. exynos 3830 driver work

Call to action: If you own a device with this chip, consider setting up a serial UART connection. The developers need testers to confirm if the new clk-exynos3830 driver finally stops the random reboots on suspend.

The silicon is five years old, but thanks to this driver work, its life is just beginning.

1. Did you mean the Exynos 1380?

The Exynos 1380 is a popular mid-range chipset found in the Samsung Galaxy A54 5G and Galaxy M54 5G. Patches submitted: A series of 14 patches reworking

Driver Work & Development Status:

• Mainline Linux Kernel: As of recent kernel releases (6.1+), support for the Exynos 1380 is gradually being upstreamed. Key components include the pinctrl, clock management, and UART drivers.
• Device Tree Overlay: If you are porting a custom ROM or Linux distro, the device tree source (DTS) files are often based on the exynos850 or exynosautov9 architecture due to similarities in the peripheral layout.
• GPU Drivers: The Xclipse 920 GPU (based on AMD RDNA2 architecture) requires specific panfrost or proprietary binary blob drivers. Open-source work is ongoing, but hardware acceleration can be tricky to implement without the correct binary shader compiler.
• Modem/RIL: The Shannon modem interface usually requires proprietary RIL (Radio Interface Layer) libraries lifted from stock Android firmware to function correctly in non-Android environments (like postmarketOS).

Step 3: The "Dirty" DMA

This is where I am currently stuck (or, "making progress slowly").

The Exynos 3830 uses a PL330 DMA controller. In mainline Linux, the pl330 driver works, but the peri_id mapping for the I2S (audio) and SPI ports is wrong. Practical debugging checklist (order)

When the audio driver tries to allocate a DMA channel, the kernel crashes with: pl330_get_chan_id: Invalid peripheral id: 0xff

It turns out the 3830 repurposed peripheral IDs 0x34 and 0x35 for the second I2S bus, while the standard Exynos uses 0x32. I am currently building a small "quirk" table in the device tree to remap these IDs.

2.1. Platform Driver Registration

static struct platform_driver exynos3830_driver = 
    .probe  = exynos3830_probe,
    .remove = exynos3830_remove,
    .driver = 
        .name = "exynos3830",
        .of_match_table = exynos3830_dt_match,
        .pm = &exynos3830_pm_ops,
    ,
;

Why Open Source Matters Here

Samsung ships the Exynos 3830 in millions of tablets running Android 9, 10, and 11. However, those devices use out-of-tree (OOT) vendor kernels (typically Linux 4.14 or 4.19). These kernels are stale, insecure, and incompatible with mainline Linux distributions.

The current driver work aims to mainline support. This means:

• Long-term security: The device can run a modern kernel (6.x) instead of a dead 4.14 branch.
• Desktop Linux: A tablet like the Galaxy Tab A could one day run mainline Linux with GNOME Mobile or KDE Plasma Mobile.
• Debugging: When drivers are upstreamed, the entire Linux community can audit and improve them.

Practical debugging checklist (order)

1. Serial console: capture boot logs.
2. Confirm kernel has expected drivers built as modules or built-in.
3. dmesg for probe failures and call traces.
4. Check DT for missing properties compared to binding docs.
5. Verify clocks with debugfs (clk framework) and toggle as needed.
6. Check pinmux state with pinctrl debugfs.
7. Use devm_add_action and dev_dbg to trace resource acquisition order.
8. Try forcing driver probe after enabling dependencies (echo driver > /sys/bus/.../drivers_probe).