On Wed, Aug 9, 2023 at 10:53 AM Boris Brezillon <boris.brezillon@xxxxxxxxxxxxx> 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
