summaryrefslogtreecommitdiff
path: root/drivers/accel/Kconfig
AgeCommit message (Collapse)Author
2023-04-06accel/qaic: Add qaic driver to the build systemJeffrey Hugo
Now that we have all the components of a minimum QAIC which can boot and run an AIC100 device, add the infrastructure that allows the QAIC driver to be built. Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Carl Vanderlip <quic_carlv@quicinc.com> Reviewed-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Reviewed-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Acked-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1679932497-30277-8-git-send-email-quic_jhugo@quicinc.com
2023-01-31Merge drm/drm-next into drm-misc-nextThomas Zimmermann
Backmerging to get v6.2-rc6. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2023-01-31accel: fix CONFIG_DRM dependenciesArnd Bergmann
At the moment, accel drivers can be built-in even with CONFIG_DRM=m, but this causes a link failure: x86_64-linux-ld: drivers/accel/ivpu/ivpu_drv.o: in function `ivpu_dev_init': ivpu_drv.c:(.text+0x1535): undefined reference to `drmm_kmalloc' x86_64-linux-ld: ivpu_drv.c:(.text+0x1562): undefined reference to `drmm_kmalloc' x86_64-linux-ld: drivers/accel/ivpu/ivpu_drv.o: in function `ivpu_remove': ivpu_drv.c:(.text+0x1faa): undefined reference to `drm_dev_unregister' x86_64-linux-ld: drivers/accel/ivpu/ivpu_drv.o: in function `ivpu_probe': ivpu_drv.c:(.text+0x1fef): undefined reference to `__devm_drm_dev_alloc' The problem is that DRM_ACCEL is a 'bool' symbol, so driver that only depend on DRM_ACCEL but not also on DRM do not see the restriction to =m configs. To ensure that each accel driver has an implied dependency on CONFIG_DRM, enclose the entire Kconfig file in an if/endif check. Fixes: 8bf4889762a8 ("drivers/accel: define kconfig and register a new major") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230127221504.2522909-1-arnd@kernel.org
2023-01-26habanalabs: move driver to accel subsystemOded Gabbay
Now that we have a subsystem for compute accelerators, move the habanalabs driver to it. This patch only moves the files and fixes the Makefiles. Future patches will change the existing code to register to the accel subsystem and expose the accel device char files instead of the habanalabs device char files. Update the MAINTAINERS file to reflect this change. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
2023-01-19accel/ivpu: Introduce a new DRM driver for Intel VPUJacek Lawrynowicz
VPU stands for Versatile Processing Unit and it's a CPU-integrated inference accelerator for Computer Vision and Deep Learning applications. The VPU device consist of following components: - Buttress - provides CPU to VPU integration, interrupt, frequency and power management. - Memory Management Unit (based on ARM MMU-600) - translates VPU to host DMA addresses, isolates user workloads. - RISC based microcontroller - executes firmware that provides job execution API for the kernel-mode driver - Neural Compute Subsystem (NCS) - does the actual work, provides Compute and Copy engines. - Network on Chip (NoC) - network fabric connecting all the components This driver supports VPU IP v2.7 integrated into Intel Meteor Lake client CPUs (14th generation). Module sources are at drivers/accel/ivpu and module name is "intel_vpu.ko". This patch includes only very besic functionality: - module, PCI device and IRQ initialization - register definitions and low level register manipulation functions - SET/GET_PARAM ioctls - power up without firmware Co-developed-by: Krystian Pradzynski <krystian.pradzynski@linux.intel.com> Signed-off-by: Krystian Pradzynski <krystian.pradzynski@linux.intel.com> Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20230117092723.60441-2-jacek.lawrynowicz@linux.intel.com
2022-11-22drivers/accel: define kconfig and register a new majorOded Gabbay
Add a new Kconfig for the accel subsystem. The Kconfig currently contains only the basic CONFIG_DRM_ACCEL option that will be used to decide whether to compile the accel registration code. Therefore, the kconfig option is defined as bool. The accel code will be compiled as part of drm.ko and will be called directly from the DRM core code. The reason we compile it as part of drm.ko and not as a separate module is because of cyclic dependency between drm.ko and the separate module (if it would have existed). This is due to the fact that DRM core code calls accel functions and vice-versa. The accelerator devices will be exposed to the user space with a new, dedicated major number - 261. The accel init function registers the new major number as a char device and create corresponding sysfs and debugfs root entries, similar to what is done in DRM init function. I added a new header called drm_accel.h to include/drm/, that will hold the prototypes of the drm_accel.c functions. In case CONFIG_DRM_ACCEL is set to 'N', that header will contain empty inline implementations of those functions, to allow DRM core code to compile successfully without dependency on CONFIG_DRM_ACCEL. I Updated the MAINTAINERS file accordingly with the newly added folder and I have taken the liberty to appropriate the dri-devel mailing list and the dri-devel IRC channel for the accel subsystem. Signed-off-by: Oded Gabbay <ogabbay@kernel.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Tested-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Reviewed-by: Melissa Wen <mwen@igalia.com>