The T-head TH1520 SoC supports a hardware mailbox that enables two cores within the SoC to communicate and coordinate [1]. One example of such coordination would be cooperation with the T-Head E902 core, which is responsible for power, clock, and resource management. For example, in the specific case of the BXM-4-64 GPU, it needs to be powered on by the E902 core, and the kernel running on the E910 needs to 'ask' the firmware running on the E902 core to enable power to the GPU island. Given recent advancements in work on the upstream GPU driver [2], there is an emerging need to get this code in the mainline kernel. Link: https://openbeagle.org/beaglev-ahead/beaglev-ahead/-/blob/main/docs/TH1520%20System%20User%20Manual.pdf [1] Link: https://gitlab.freedesktop.org/imagination/linux-firmware/-/issues/1 [2] Thanks everyone for taking the time to review this series ! To test this, I've prepared a diff that includes the missing drivers utilizing the mailbox and enabled the GPU node in the device tree to use the drm/imagination driver. I’ve created two branches. Both contain the same code, including this patch series and some extra commits with mailbox consumers. The only difference is that one branch has an additional commit that switches ON calls to OFF calls (and vice versa) to observe the behavior when the GPU is turned off via the mailbox. To reproduce, simply clone the repository, add the following extra options in the config: CONFIG_THEAD_TH1520_MBOX=y #(this series) CONFIG_DRM_POWERVR=y CONFIG_LIGHT_AON=y CONFIG_LIGHT_AON_PD=y Then build and deploy on the target. In case [1], the output should be: [ 2.478394] light_aon_probe: virtual_log_mem=0x000000005faf564a, phy base=0x33600000, size:2097152 [ 2.488589] succeed to create power domain debugfs direntry [ 2.494987] powervr ffef400000.gpu: Before reading BVNC At this point, the system will hang because the driver is trying to read memory-mapped registers while the GPU isn’t powered on. In case [2], the GPU powers on correctly, and the BVNC can be read without issues. If the specific firmware file isn’t available, the output would look like this: root@revyos-lpi4a:~# dmesg | grep gpu [ 2.408207] powervr ffef400000.gpu: Before reading BVNC [ 2.413533] powervr ffef400000.gpu: After reading BVNC [ 2.418930] powervr ffef400000.gpu: Direct firmware load for powervr/rogue_36.52.104.182_v1.fw failed with error -2 [ 2.429568] powervr ffef400000.gpu: [drm] *ERROR* failed to load firmware powervr/rogue_36.52.104.182_v1.fw (err=-2) [ 2.440403] powervr ffef400000.gpu: probe with driver powervr failed with error -2 Here are the links: [1] - https://github.com/mwilczy/linux/tree/31_october_demonstrate_mailbox_not_working [2] - https://github.com/mwilczy/linux/tree/31_october_demonstrate_mailbox_working Note: U-Boot must load the AON firmware at startup to the address mapped for AON for this to work properly. v5: - removed 'type' mbox-cell, which isn't really necessary for the use-cases of the series, but desribes SW protocol instead of the HW, adjust driver code logic to account for this, simplifying it - change the register mappings in the device tree node to reflect the manual - adjust the driver code to compensate for irregularities in the mappings, do this by modifying th1520_map_mmio() with extra argument 'offset' - add support for enabling/disabling MBOX clocks in the driver - add clocks in the dt-binding/device tree node - rebase and retest v4: - fixed warning of unused variable - added Reviewed-by from Krzysztof - fixed minor cosmetic issues in dt-binding v3: - added a comment about mixing devm_ and non-devm resources in the context of shared interrupts and explained why it's safe to do so in this particular case - changed the order of resource freeing in the .shutdown callback - used a wrapper function for register mapping - since the only conceivable use case for this mailbox driver is communication with cores not managed by the kernel, I’ve hard-coded this by removing the thead,icu-cpu-id property and adjusted the mailbox driver code accordingly. - added a more detailed description for mbox-cells. - made some cosmetic changes. - retested by applying the patch with non-yet-upstreamed patches, confirming that the drm/imagination driver can read the registers correctly. v2: - fixed thead,th1520-mbox.yaml binding file by dropping redundant descriptions, renaming reg-names, removing unnecessary clocks, providing constraints and defining ICU's - fixed the mailbox driver code to work well with updated binding-file, removed clocks support, as it's not necessary for mailbox to work - adjusted the device tree node instance of mbox_910t so it will work with updated bindings file Michal Wilczynski (3): mailbox: Introduce support for T-head TH1520 Mailbox driver dt-bindings: mailbox: Add thead,th1520-mailbox bindings riscv: dts: thead: Add mailbox node .../bindings/mailbox/thead,th1520-mbox.yaml | 89 +++ MAINTAINERS | 2 + arch/riscv/boot/dts/thead/th1520.dtsi | 16 + drivers/mailbox/Kconfig | 10 + drivers/mailbox/Makefile | 2 + drivers/mailbox/mailbox-th1520.c | 592 ++++++++++++++++++ 6 files changed, 711 insertions(+) create mode 100644 Documentation/devicetree/bindings/mailbox/thead,th1520-mbox.yaml create mode 100644 drivers/mailbox/mailbox-th1520.c -- 2.34.1
