[PATCH v2 00/15] drm: Add a driver for FW-based Mali GPUs

[Rob Herring]

On Wed, Aug 9, 2023 at 10:53 AM Boris Brezillon
<boris.brezillon at collabora.com> wrote:
>
> Hello,
>
> This is the second version of the kernel driver meant to support new Mali
> GPUs which are delegating the scheduling to a firmware.
>
> The RFC has been dropped as the major blocking points have been addressed
> (request to use drm_sched, request to implement a VM_BIND-like ioctl,
> request to use drm_gpuva_mgr for the VM logic, lack of PM/devfreq support).
>
> This series is based on drm-misc-next and depends on some drm_sched [1]
> and iommu [2] changes.
>
> A branch containing all those dependencies is available here[3], and
> here [4] is another one containing all the patches needed to have
> a working GPU on rk3588 on top. The CSF firmware binary can be found
> here[5].
>
> The mesa branch used to test this new driver is available here [6].
> It's still under development and it's just a gallium driver right now,
> but we are working on that ;-).
>
> Here is a non-exaustive changelog, check each commit for a detailed
> changelog.
>
> v2:
> - Rename the driver (pancsf -> panthor)
> - Split the commit adding the driver to ease review
> - Use drm_sched for dependency tracking/job submission
> - Add a VM_BIND ioctl
> - Add the concept of exclusive VM for BOs that are only ever mapped to a
>   single VM
> - Document the code and uAPI
> - Add a DT binding doc
>
> I tried to Cc anyone that was involved in any development of the code
> I picked from panfrost, so they can acknowledge the GPL2 -> MIT+GPL2
> change. If I missed someone, please let me know.

Panfrost was largely based on etnaviv, vc4, v3d, and msm. Those are
all GPL2 (or 2+) only. How is relicensing that code okay? Also,
panfrost depends on drm_gem_shmem_helper.c (at least) which is GPL2.
Does that get re-implemented in a MIT licensed environment?

Maybe some drivers are enough of a silo to get away with MIT
licensing, but I wouldn't be comfortable claiming it.

Rob