On Wed, Oct 16, 2024 at 12:03:05AM +0200, Michal Wilczynski wrote: > > > 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. I think that would be helpful for myself and others to be able to see the interaction. Thanks, Drew