On Wed, May 24, 2023 at 2:34 AM Kevin Hilman <khilman@xxxxxxxxxxxx> wrote: > > Jeffrey Hugo <quic_jhugo@xxxxxxxxxxx> writes: > > > On 5/17/2023 8:52 AM, Alexandre Bailon wrote: > >> This adds a DRM driver that implements communication between the CPU and an > >> APU. The driver target embedded device that usually run inference using some > >> prebuilt models. The goal is to provide common infrastructure that could be > >> re-used to support many accelerators. Both kernel, userspace and firmware tries > >> to use standard and existing to leverage the development and maintenance effort. > >> The series implements two platform drivers, one for simulation and another one for > >> the mt8183 (compatible with mt8365). > > > > This looks like the 3 existing Accel drivers. Why is this in DRM? > > Yes, this belongs in accel. I think Alex had some issues around the > infra in accel with device nodes not appearing/opening properly, but > I'll let him comment there. But either way, the right approach should > be to fix any issues in accel and move it there. > > [...] > > >> .../devicetree/bindings/gpu/mtk,apu-drm.yaml | 38 ++ > >> drivers/gpu/drm/Kconfig | 2 + > >> drivers/gpu/drm/Makefile | 1 + > >> drivers/gpu/drm/apu/Kconfig | 22 + > >> drivers/gpu/drm/apu/Makefile | 10 + > >> drivers/gpu/drm/apu/apu_drv.c | 282 +++++++++ > >> drivers/gpu/drm/apu/apu_gem.c | 230 +++++++ > >> drivers/gpu/drm/apu/apu_internal.h | 205 ++++++ > >> drivers/gpu/drm/apu/apu_sched.c | 592 ++++++++++++++++++ > >> drivers/gpu/drm/apu/simu_apu.c | 313 +++++++++ > >> include/uapi/drm/apu_drm.h | 81 +++ > > > > "apu" seems too generic. We already have 3 "AI processing units" over > > in drivers/accel already... > > Indeed, it is generic, but that's kind of the point for this driver > since it's targetted at generalizing the interface with "AI processing > units" on a growing number of embedded SoCs (ARM, RISC-V, etc.) In > addition, the generic naming is intentional because the goal is bigger > than the kernel and is working towards a generic, shared "libAPU" > userspace[1], but also common firmware for DSP-style inference engines > (e.g. analgous Sound Open Firmware for audio DSPs.) > > As usual, the various SoC vendors use different names (APU, NPU, NN > unit, etc.) but we'd like a generic name for the class of devices > targetted by this driver. And unfortunately, it looks like the equally > generic "Versatile processing unit" is already taken Intel's > drivers/accel/ivpu. :) > > Maybe since this is more about generalizing the interface between the > CPU running linux and the APU, what about the name apu_if? But I guess > that applies to the other 3 drivers in drivers/accell also. Hmmm... > > Naming things is hard[2], so we're definitly open to other ideas. Any > suggestions? Maybe model it according to the tiny driver in drm display ? You can then call it tiny_apu :-) Disclosure: It was Daniel's suggestion, he can chime in with more details on the tiny driver concept. Oded > > Kevin > > [1] https://gitlab.baylibre.com/baylibre/libapu/libapu > > [2] > "There are 2 hard problems in computer science: cache invalidation, > naming things and off-by-1 errors." > -- https://twitter.com/secretGeek/status/7269997868 >
