[RFC PATCH 0/5] drm/panthor: Protected mode support for Mali CSF GPUs

[Maxime Ripard]

Hi Nicolas,

On Thu, Jan 30, 2025 at 10:59:56AM -0500, Nicolas Dufresne wrote:
> Le jeudi 30 janvier 2025 à 14:46 +0100, Maxime Ripard a écrit :
> > Hi,
> > 
> > I started to review it, but it's probably best to discuss it here.
> > 
> > On Thu, Jan 30, 2025 at 01:08:56PM +0000, Florent Tomasin wrote:
> > > Hi,
> > > 
> > > This is a patch series covering the support for protected mode execution in
> > > Mali Panthor CSF kernel driver.
> > > 
> > > The Mali CSF GPUs come with the support for protected mode execution at the
> > > HW level. This feature requires two main changes in the kernel driver:
> > > 
> > > 1) Configure the GPU with a protected buffer. The system must provide a DMA
> > >    heap from which the driver can allocate a protected buffer.
> > >    It can be a carved-out memory or dynamically allocated protected memory region.
> > >    Some system includes a trusted FW which is in charge of the protected memory.
> > >    Since this problem is integration specific, the Mali Panthor CSF kernel
> > >    driver must import the protected memory from a device specific exporter.
> > 
> > Why do you need a heap for it in the first place? My understanding of
> > your series is that you have a carved out memory region somewhere, and
> > you want to allocate from that carved out memory region your buffers.
> > 
> > How is that any different from using a reserved-memory region, adding
> > the reserved-memory property to the GPU device and doing all your
> > allocation through the usual dma_alloc_* API?
> 
> How do you then multiplex this region so it can be shared between
> GPU/Camera/Display/Codec drivers and also userspace ?

You could point all the devices to the same reserved memory region, and
they would all allocate from there, including for their userspace-facing
allocations.

> Also, how the secure memory is allocted / obtained is a process that
> can vary a lot between SoC, so implementation details assumption
> should not be coded in the driver.

But yeah, we agree there, it's also the point I was trying to make :)

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mediatek/attachments/20250130/36ac3cf3/attachment.sig>