[PATCH v4 0/3] Introduce support for T-head TH1520 Mailbox

[Michal Wilczynski]

On 10/14/24 20:31, Drew Fustini wrote:
> On Mon, Oct 14, 2024 at 02:33:11PM +0200, Michal Wilczynski wrote:
>> 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://protect2.fireeye.com/v1/url?k=2021d256-7fbdfb7c-20205919-000babe598f7-ca654d1a9bc866ac&q=1&e=11e97355-e6e9-4aac-a996-cc475156b3c8&u=https%3A%2F%2Fopenbeagle.org%2Fbeaglev-ahead%2Fbeaglev-ahead%2F-%2Fblob%2Fmain%2Fdocs%2FTH1520%2520System%2520User%2520Manual.pdf [1]
>> Link: https://gitlab.freedesktop.org/imagination/linux-firmware/-/issues/1 [2]
>>
>> Thanks, Krzysztof and Rob, for your review! Since this series is gaining
>> some interest, I've dropped the RFC prefix with the v3 update.
> 
> I've applied this series and booted okay. I see the driver loaded:
> 
>  /sys/devices/platform/soc/ffffc38000.mailbox/driver points to
>  /sys/bus/platform/drivers/th1520-mbox
> 
> How do you test that the communication with the E902 is working
> correctly?

Thank you for your interest. 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 observed that when the power was turned off through the E902 core
using the mailbox, the drm/imagination driver would hang in
pvr_load_gpu_id() while attempting to read its BVNC from the register.
However, when the GPU was turned on via the mailbox, the BVNC could be
read correctly. Still, the firmware fails to boot due to some missing
programming in the drm/imagination driver, which is currently being
worked on. I've briefly explained this in the first commit of this
series.

If you'd like to try this yourself, I'd be happy to push these setups to
a GitHub repository and provide you with a link, so you can see the
setup in action.

Michał

> 
> Thanks,
> Drew
>