rk3399 issue: no DMA in Linux with mainline TF-A and U-Boot SPL

[Christoph Fritz]

On Mon, 2023-04-03 at 14:17 +0100, Russell King (Oracle) wrote:
> On Mon, Apr 03, 2023 at 12:11:40PM +0200, Christoph Fritz wrote:
> > > 
> > >      The ARM PL330 DMA driver in kernel only relate to:
> > > 
> > > - DTS kernel used, can be check in /proc/device-tree/
> > > 
> > > - kernel driver which should mach the compatible name.
> > 
> > drivers/dma/pl330.c needs also a successfully matched amba, but this
> > fails when using mainline TF-A and U-Boot SPL.
> > 
> > I'm using the same kernel and devicetree on both tests, the only thing
> > changed is TF-A and U-Boot SPL   vs   mini-loader and rk3399_bl31.
> > 
> > > This driver should has nothing to do with U-Boot SPL or TF-A, because we 
> > > don't have any special setting for PL330 in loader stage.
> > 
> > It is drivers/amba/bus.c, which is unable to find an AMBA_CID on the
> > ARM bus. The DMA driver not loading is just a symptom of this issue.
> 
> That brings up the obvious question: why is it unable to find the AMBA
> CID? Is that because some resource needed to read it hasn't been
> enabled yet?

That's my guess too, and that's why I'm asking Kever from Rockchip. To
me, it seems that their closed-source BL31 and/or mini-loader is
enabling something that is missing in upstream TF-A and/or U-Boot SPL.
On top of that, the registers responsible for that are undocumented.

But I could be wrong, and it's possible that I'm missing something
else. Maybe dumping the syscon-registers and comparing them might help,
but as far as I can see, it's a bit of an effort because they require
special treatment to be accessed.

>  If the AMBA CID is not accessible, presumably the rest of
> the PL330 also isn't accessible, so even if we could bind the driver,
> it still wouldn't work?

The PL330 driver attempted to probe, but was deferred due to a missing
AMBA_CID. It's in the bootlog that I attached in my first email in this
thread.

Thanks
  -- Christoph