public-mirrors/linux
1
0
Fork 0
mirror of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git synced 2025-08-05 16:54:27 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
linux/drivers/gpu/drm/nouveau/Kconfig

130 lines
3.2 KiB
Text
Raw Permalink Normal View History

treewide: Add SPDX license identifier - Makefile/Kconfig Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-19 13:07:45 +01:00
# SPDX-License-Identifier: GPL-2.0-only
drm/nouveau: Add DRM driver for NVIDIA GPUs This adds a drm/kms staging non-API stable driver for GPUs from NVIDIA. This driver is a KMS-based driver and requires a compatible nouveau userspace libdrm and nouveau X.org driver. This driver requires firmware files not available in this kernel tree, interested parties can find them via the nouveau project git archive. This driver is reverse engineered, and is in no way supported by nVidia. Support for nearly the complete range of nvidia hw from nv04->g80 (nv50) is available, and the kms driver should support driving nearly all output types (displayport is under development still) along with supporting suspend/resume. This work is all from the upstream nouveau project found at nouveau.freedesktop.org. The original authors list from nouveau git tree is: Anssi Hannula <anssi.hannula@iki.fi> Ben Skeggs <bskeggs@redhat.com> Francisco Jerez <currojerez@riseup.net> Maarten Maathuis <madman2003@gmail.com> Marcin Kościelnicki <koriakin@0x04.net> Matthew Garrett <mjg@redhat.com> Matt Parnell <mparnell@gmail.com> Patrice Mandin <patmandin@gmail.com> Pekka Paalanen <pq@iki.fi> Xavier Chantry <shiningxc@gmail.com> along with project founder Stephane Marchesin <marchesin@icps.u-strasbg.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-12-11 19:24:15 +10:00
config DRM_NOUVEAU
drm/nouveau: support for probing platform devices Add a platform driver for Nouveau devices declared using the device tree or platform data. This driver currently supports GK20A on Tegra platforms and is only compiled for these platforms if Nouveau is enabled. Nouveau will probe the chip type itself using the BOOT0 register, so all this driver really needs to do is to make sure the module is powered and its clocks active before calling nouveau_drm_platform_probe(). Heavily based on work done by Thierry Reding. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2014-06-26 14:33:32 +09:00
tristate "Nouveau (NVIDIA) cards"
PCI: Add CONFIG_MMU dependency It turns out that there are no platforms that have PCI but don't have an MMU, so adding a Kconfig dependency on CONFIG_PCI simplifies build testing kernels for those platforms a lot, and avoids a lot of inadvertent build regressions. Add a dependency for CONFIG_PCI and remove all the ones for PCI specific device drivers that are currently marked not having it. There are a few platforms that have an optional MMU, but they usually cannot have PCI at all. The one exception is Coldfire MCF54xx, but this is mainly for historic reasons, and anyone using those chips should really use the MMU these days. Link: https://lore.kernel.org/lkml/a41f1b20-a76c-43d8-8c36-f12744327a54@app.fastmail.com/ Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> # SCSI Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20250423202215.3315550-1-arnd@kernel.org
2025-04-23 22:16:32 +02:00
depends on DRM && PCI
drm/nouveau: fix build error without CONFIG_IOMMU_API If CONFIG_IOMMU_API is n, build fails: vers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c:37:9: error: implicit declaration of function dev_iommu_fwspec_get; did you mean iommu_fwspec_free? [-Werror=implicit-function-declaration] spec = dev_iommu_fwspec_get(device->dev); ^~~~~~~~~~~~~~~~~~~~ iommu_fwspec_free drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c:37:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion] spec = dev_iommu_fwspec_get(device->dev); ^ drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c:39:17: error: struct iommu_fwspec has no member named ids u32 sid = spec->ids[0] & 0xffff; Seletc IOMMU_API under config DRM_NOUVEAU to fix this. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Chen Zhou <chenzhou10@huawei.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-01-16 20:50:10 +08:00
select IOMMU_API
drm/nouveau: Fix Kconfig indentation Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^ /\t/' -i */Kconfig Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20191120133619.11415-1-krzk@kernel.org
2019-11-20 21:36:19 +08:00
select FW_LOADER
drm/nouveau: select FW caching nouveau tries to load some firmware during suspend that it loaded earlier, but with fw caching disabled it hangs suspend, so just rely on FW cache enabling instead of working around it in the driver. Fixes: 176fdcbddfd2 ("drm/nouveau/gsp/r535: add support for booting GSP-RM") Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250207012531.621369-1-airlied@gmail.com
2025-02-07 11:25:31 +10:00
select FW_CACHE if PM_SLEEP
drm/nouveau: Run DRM default client setup Call drm_client_setup() to run the kernel's default client setup for DRM. Set fbdev_probe in struct drm_driver, so that the client setup can start the common fbdev client. The nouveau driver specifies a preferred color mode depending on the available video memory, with a default of 32. Adapt this for the new client interface. v5: - select DRM_CLIENT_SELECTION v2: - style changes Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Karol Herbst <kherbst@redhat.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Danilo Krummrich <dakr@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240924071734.98201-69-tzimmermann@suse.de
2024-09-24 09:13:06 +02:00
select DRM_CLIENT_SELECTION
drm/display: Introduce a DRM display-helper module Replace the DP-helper module with a display-helper module. The support for DisplayPort becomes an internal option that drivers have to select. Update all related Kconfig and Makefile rules. Besides the existing code for DisplayPort, the new module will contain helpers for other video-output standards, such as HDMI. Drivers will have to select their required video-output helpers. Linking all display-related code into a single module avoids the proliferation of small kernel modules. The module parameters drm_dp_cec_unregister_delay, dp_aux_i2c_speed_khz, and dp_aux_i2c_transfer_size are moving from the drm_dp_helper namespace to drm_display_helper. v2: * mention module parameters in commit message (Javier) * distiguish between display module and DP support in Kconfig * update Makefile rules for DP helpers * move Kconfig rules into separate file under display/ Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220421073108.19226-4-tzimmermann@suse.de
2022-04-21 09:31:03 +02:00
select DRM_DISPLAY_DP_HELPER
drm/display: Move SCDC helpers into display-helper library SCDC is the Status and Control Data Channel for HDMI. Move the SCDC helpers into display/ and split the header into files for core and helpers. Update all affected drivers. No functional changes. To avoid the proliferation of Kconfig options, SCDC is part of DRM's support for HDMI. If necessary, a new option could make SCDC an independent feature. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220421073108.19226-9-tzimmermann@suse.de
2022-04-21 09:31:08 +02:00
select DRM_DISPLAY_HDMI_HELPER
drm/display: Introduce a DRM display-helper module Replace the DP-helper module with a display-helper module. The support for DisplayPort becomes an internal option that drivers have to select. Update all related Kconfig and Makefile rules. Besides the existing code for DisplayPort, the new module will contain helpers for other video-output standards, such as HDMI. Drivers will have to select their required video-output helpers. Linking all display-related code into a single module avoids the proliferation of small kernel modules. The module parameters drm_dp_cec_unregister_delay, dp_aux_i2c_speed_khz, and dp_aux_i2c_transfer_size are moving from the drm_dp_helper namespace to drm_display_helper. v2: * mention module parameters in commit message (Javier) * distiguish between display module and DP support in Kconfig * update Makefile rules for DP helpers * move Kconfig rules into separate file under display/ Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220421073108.19226-4-tzimmermann@suse.de
2022-04-21 09:31:03 +02:00
select DRM_DISPLAY_HELPER
drm/nouveau: Add DRM driver for NVIDIA GPUs This adds a drm/kms staging non-API stable driver for GPUs from NVIDIA. This driver is a KMS-based driver and requires a compatible nouveau userspace libdrm and nouveau X.org driver. This driver requires firmware files not available in this kernel tree, interested parties can find them via the nouveau project git archive. This driver is reverse engineered, and is in no way supported by nVidia. Support for nearly the complete range of nvidia hw from nv04->g80 (nv50) is available, and the kms driver should support driving nearly all output types (displayport is under development still) along with supporting suspend/resume. This work is all from the upstream nouveau project found at nouveau.freedesktop.org. The original authors list from nouveau git tree is: Anssi Hannula <anssi.hannula@iki.fi> Ben Skeggs <bskeggs@redhat.com> Francisco Jerez <currojerez@riseup.net> Maarten Maathuis <madman2003@gmail.com> Marcin Kościelnicki <koriakin@0x04.net> Matthew Garrett <mjg@redhat.com> Matt Parnell <mparnell@gmail.com> Patrice Mandin <patmandin@gmail.com> Pekka Paalanen <pq@iki.fi> Xavier Chantry <shiningxc@gmail.com> along with project founder Stephane Marchesin <marchesin@icps.u-strasbg.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-12-11 19:24:15 +10:00
select DRM_KMS_HELPER
select DRM_TTM
drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM backends This patch replaces the vmap/vunmap's use of raw pointers in GEM object functions with instances of struct dma_buf_map. GEM backends are converted as well. For most of them, this simply changes the returned type. TTM-based drivers now return information about the location of the memory, either system or I/O memory. GEM VRAM helpers and qxl now use ttm_bo_vmap() et al. Amdgpu, nouveau and radeon use drm_gem_ttm_vmap() et al instead of implementing their own vmap callbacks. v7: * init QXL cursor to mapped BO buffer (kernel test robot) v5: * update vkms after switch to shmem v4: * use ttm_bo_vmap(), drm_gem_ttm_vmap(), et al. (Daniel, Christian) * fix a trailing { in drm_gem_vmap() * remove several empty functions instead of converting them (Daniel) * comment uses of raw pointers with a TODO (Daniel) * TODO list: convert more helpers to use struct dma_buf_map Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Christian König <christian.koenig@amd.com> Tested-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201103093015.1063-7-tzimmermann@suse.de
2020-11-03 10:30:11 +01:00
select DRM_TTM_HELPER
drm/nouveau: implement new VM_BIND uAPI This commit provides the implementation for the new uapi motivated by the Vulkan API. It allows user mode drivers (UMDs) to: 1) Initialize a GPU virtual address (VA) space via the new DRM_IOCTL_NOUVEAU_VM_INIT ioctl for UMDs to specify the portion of VA space managed by the kernel and userspace, respectively. 2) Allocate and free a VA space region as well as bind and unbind memory to the GPUs VA space via the new DRM_IOCTL_NOUVEAU_VM_BIND ioctl. UMDs can request the named operations to be processed either synchronously or asynchronously. It supports DRM syncobjs (incl. timelines) as synchronization mechanism. The management of the GPU VA mappings is implemented with the DRM GPU VA manager. 3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC ioctl. The execution happens asynchronously. It supports DRM syncobj (incl. timelines) as synchronization mechanism. DRM GEM object locking is handled with drm_exec. Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC, use the DRM GPU scheduler for the asynchronous paths. Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230804182406.5222-12-dakr@redhat.com
2023-08-04 20:23:51 +02:00
select DRM_EXEC
drm/gpuvm: allow building as module Currently, the DRM GPUVM does not have any core dependencies preventing a module build. Also, new features from subsequent patches require helpers (namely drm_exec) which can be built as module. Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230920144343.64830-3-dakr@redhat.com
2023-09-20 16:42:35 +02:00
select DRM_GPUVM
drm/nouveau: implement new VM_BIND uAPI This commit provides the implementation for the new uapi motivated by the Vulkan API. It allows user mode drivers (UMDs) to: 1) Initialize a GPU virtual address (VA) space via the new DRM_IOCTL_NOUVEAU_VM_INIT ioctl for UMDs to specify the portion of VA space managed by the kernel and userspace, respectively. 2) Allocate and free a VA space region as well as bind and unbind memory to the GPUs VA space via the new DRM_IOCTL_NOUVEAU_VM_BIND ioctl. UMDs can request the named operations to be processed either synchronously or asynchronously. It supports DRM syncobjs (incl. timelines) as synchronization mechanism. The management of the GPU VA mappings is implemented with the DRM GPU VA manager. 3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC ioctl. The execution happens asynchronously. It supports DRM syncobj (incl. timelines) as synchronization mechanism. DRM GEM object locking is handled with drm_exec. Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC, use the DRM GPU scheduler for the asynchronous paths. Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230804182406.5222-12-dakr@redhat.com
2023-08-04 20:23:51 +02:00
select DRM_SCHED
drm: Only select I2C_ALGOBIT for drivers that actually need it While working on a drm driver that doesn't need the i2c algobit stuff I noticed that DRM selects this code even though only 8 drivers actually use it. While also only some drivers use i2c, keep the select for I2C for the next cleanup patch. Still prepare this already by also selecting I2C for the individual drivers. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221219083627.1401627-1-u.kleine-koenig@pengutronix.de
2022-12-19 09:36:27 +01:00
select I2C
select I2C_ALGOBIT
drm/nouveau: fix incorrect FB_BACKLIGHT usage in Kconfig Making FB_BACKLIGHT tristate by commit b4a1ed0cd18b ("fbdev: make FB_BACKLIGHT a tristate") caused unmet dependencies in some configurations: WARNING: unmet direct dependencies detected for FB_BACKLIGHT Depends on [m]: HAS_IOMEM [=y] && FB [=m] Selected by [y]: - DRM_NOUVEAU [=y] && HAS_IOMEM [=y] && DRM [=y] && PCI [=y] && MMU [=y] && DRM_NOUVEAU_BACKLIGHT [=y] Selected by [m]: - FB_NVIDIA [=m] && HAS_IOMEM [=y] && FB [=m] && PCI [=y] && FB_NVIDIA_BACKLIGHT [=y] Fix it by making DRM_NOUVEAU select BACKLIGHT_CLASS_DEVICE and BACKLIGHT_LCD_SUPPORT instead of FB_BACKLIGHT. Fixes: b4a1ed0cd18b ("fbdev: make FB_BACKLIGHT a tristate") Reported-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Cc: Rob Clark <robdclark@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2019-01-02 18:47:37 +01:00
select BACKLIGHT_CLASS_DEVICE if DRM_NOUVEAU_BACKLIGHT
nouveau: ACPI support depends on X86 and X86_PLATFORM_DEVICES If I build nouveau on ia64, Kconfig warns: warning: (DRM_NOUVEAU) selects ACPI_WMI which has unmet direct dependencies (X86 && X86_PLATFORM_DEVICES && ACPI) warning: (DRM_NOUVEAU) selects MXM_WMI which has unmet direct dependencies (X86 && X86_PLATFORM_DEVICES && ACPI_WMI) Make all the ACPI support depend on X86 and select X86_PLATFORM_DEVICES. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-02-20 02:57:32 +00:00
select X86_PLATFORM_DEVICES if ACPI && X86
select ACPI_WMI if ACPI && X86
select MXM_WMI if ACPI && X86
drm/nouveau: select POWER_SUPPLY Ben H. reported that building nouveau into the kernel and power supply as a module was broken. Just have nouveau select it, like radeon does. Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-04-02 10:45:49 +01:00
select POWER_SUPPLY
drm/nouveau: always select ACPI_VIDEO if ACPI is enabled. Having nouveau builtin would still allow ACPI_VIDEO to be used as external module if some of the deps for acpi_video have not been met, which would result in a linking failure. Solve this by selecting all dependencies as well. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Acked-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-06-27 13:38:23 +02:00
# Similar to i915, we need to select ACPI_VIDEO and it's dependencies
select BACKLIGHT_CLASS_DEVICE if ACPI && X86
select INPUT if ACPI && X86
select THERMAL if ACPI && X86
select ACPI_VIDEO if ACPI && X86
drm/nouveau: Add HD-audio component notifier support This patch adds the support for the notification of HD-audio hotplug via the already existing drm_audio_component framework. This allows us more reliable hotplug notification and ELD transfer without accessing HD-audio bus; it's more efficient, and more importantly, it works without waking up the runtime PM. The implementation is rather simplistic: nouveau driver provides the get_eld ops for HD-audio, and it notifies the audio hotplug via pin_eld_notify callback upon each nv50_audio_enable() and _disable() call. As the HD-audio pin assignment seems corresponding to the CRTC, the crtc->index number is passed directly as the zero-based port number. The bind and unbind callbacks handle the device-link so that it assures the PM call order. Link: https://lore.kernel.org/r/20190722143815.7339-3-tiwai@suse.de Reviewed-by: Lyude Paul <lyude@redhat.com> Cc: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-01-13 15:17:21 +01:00
select SND_HDA_COMPONENT if SND_HDA_CORE
drm/nouveau: Add DRM driver for NVIDIA GPUs This adds a drm/kms staging non-API stable driver for GPUs from NVIDIA. This driver is a KMS-based driver and requires a compatible nouveau userspace libdrm and nouveau X.org driver. This driver requires firmware files not available in this kernel tree, interested parties can find them via the nouveau project git archive. This driver is reverse engineered, and is in no way supported by nVidia. Support for nearly the complete range of nvidia hw from nv04->g80 (nv50) is available, and the kms driver should support driving nearly all output types (displayport is under development still) along with supporting suspend/resume. This work is all from the upstream nouveau project found at nouveau.freedesktop.org. The original authors list from nouveau git tree is: Anssi Hannula <anssi.hannula@iki.fi> Ben Skeggs <bskeggs@redhat.com> Francisco Jerez <currojerez@riseup.net> Maarten Maathuis <madman2003@gmail.com> Marcin Kościelnicki <koriakin@0x04.net> Matthew Garrett <mjg@redhat.com> Matt Parnell <mparnell@gmail.com> Patrice Mandin <patmandin@gmail.com> Pekka Paalanen <pq@iki.fi> Xavier Chantry <shiningxc@gmail.com> along with project founder Stephane Marchesin <marchesin@icps.u-strasbg.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-12-11 19:24:15 +10:00
help
drm/nouveau: support for probing platform devices Add a platform driver for Nouveau devices declared using the device tree or platform data. This driver currently supports GK20A on Tegra platforms and is only compiled for these platforms if Nouveau is enabled. Nouveau will probe the chip type itself using the BOOT0 register, so all this driver really needs to do is to make sure the module is powered and its clocks active before calling nouveau_drm_platform_probe(). Heavily based on work done by Thierry Reding. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2014-06-26 14:33:32 +09:00
Choose this option for open-source NVIDIA support.
config NOUVEAU_PLATFORM_DRIVER
drm/nouveau: merge nouveau_platform.ko into nouveau.ko Having the two modules separated causes various unneeded complications, including having to export symbols accessed between the modules. Make things simpler by compiling platform device support into nouveau.ko. Platform device support remains optional and is only compiled on Tegra. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Vince Hsu <vinceh@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-01-15 15:29:56 +09:00
bool "Nouveau (NVIDIA) SoC GPUs"
drm/nouveau: support for probing platform devices Add a platform driver for Nouveau devices declared using the device tree or platform data. This driver currently supports GK20A on Tegra platforms and is only compiled for these platforms if Nouveau is enabled. Nouveau will probe the chip type itself using the BOOT0 register, so all this driver really needs to do is to make sure the module is powered and its clocks active before calling nouveau_drm_platform_probe(). Heavily based on work done by Thierry Reding. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2014-06-26 14:33:32 +09:00
depends on DRM_NOUVEAU && ARCH_TEGRA
default y
help
Support for Nouveau platform driver, used for SoC GPUs as found
on NVIDIA Tegra K1.
drm/nouveau: Add DRM driver for NVIDIA GPUs This adds a drm/kms staging non-API stable driver for GPUs from NVIDIA. This driver is a KMS-based driver and requires a compatible nouveau userspace libdrm and nouveau X.org driver. This driver requires firmware files not available in this kernel tree, interested parties can find them via the nouveau project git archive. This driver is reverse engineered, and is in no way supported by nVidia. Support for nearly the complete range of nvidia hw from nv04->g80 (nv50) is available, and the kms driver should support driving nearly all output types (displayport is under development still) along with supporting suspend/resume. This work is all from the upstream nouveau project found at nouveau.freedesktop.org. The original authors list from nouveau git tree is: Anssi Hannula <anssi.hannula@iki.fi> Ben Skeggs <bskeggs@redhat.com> Francisco Jerez <currojerez@riseup.net> Maarten Maathuis <madman2003@gmail.com> Marcin Kościelnicki <koriakin@0x04.net> Matthew Garrett <mjg@redhat.com> Matt Parnell <mparnell@gmail.com> Patrice Mandin <patmandin@gmail.com> Pekka Paalanen <pq@iki.fi> Xavier Chantry <shiningxc@gmail.com> along with project founder Stephane Marchesin <marchesin@icps.u-strasbg.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-12-11 19:24:15 +10:00
drm/nouveau: add Kconfig options for debug control Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2012-08-03 14:58:10 +10:00
config NOUVEAU_DEBUG
int "Maximum debug level"
depends on DRM_NOUVEAU
range 0 7
default 5
help
Selects the maximum debug level to compile support for.
0 - fatal
1 - error
2 - warning
3 - info
4 - debug
5 - trace (recommended)
6 - paranoia
7 - spam
The paranoia and spam levels will add a lot of extra checks which
may potentially slow down driver operation.
config NOUVEAU_DEBUG_DEFAULT
int "Default debug level"
depends on DRM_NOUVEAU
range 0 7
default 3
help
Selects the default debug level
drm/nouveau/mmu: implement new vmm backend This is the common code to support a rework of the VMM backends. It adds support for more than 2 levels of page table nesting, which is required to be able to support GP100's MMU layout. Sparse mappings (that don't cause MMU faults when accessed) are now supported, where the backend provides it. Dual-PT handling had to become more sophisticated to support sparse, but this also allows us to support an optimisation the MMU provides on GK104 and newer. Certain operations can now be combined into a single page tree walk to avoid some overhead, but also enables optimsations like skipping PTE unmap writes when the PT will be destroyed anyway. The old backend has been hacked up to forward requests onto the new backend, if present, so that it's possible to bisect between issues in the backend changes vs the upcoming frontend changes. Until the new frontend has been merged, new backends will leak BAR2 page tables on module unload. This is expected, and it's not worth the effort of hacking around this as it doesn't effect runtime. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-11-01 03:56:19 +10:00
config NOUVEAU_DEBUG_MMU
bool "Enable additional MMU debugging"
depends on DRM_NOUVEAU
default n
help
Say Y here if you want to enable verbose MMU debug output.
drm/nouveau/kms/nv50-: wrap existing command submission in nvif_push interface This commit pulls in a bunch of new push buffer macros which are able to support NVIDIA's class headers, and provide more useful debug output and error checking (compile-time, where possible) than we had previously. Will incrementally transition each function over to the unified interfaces. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-06-20 07:52:26 +10:00
config NOUVEAU_DEBUG_PUSH
bool "Enable additional push buffer debugging"
depends on DRM_NOUVEAU
default n
help
Say Y here if you want to enable verbose push buffer debug output
and sanity checks.
drm/nouveau: Add DRM driver for NVIDIA GPUs This adds a drm/kms staging non-API stable driver for GPUs from NVIDIA. This driver is a KMS-based driver and requires a compatible nouveau userspace libdrm and nouveau X.org driver. This driver requires firmware files not available in this kernel tree, interested parties can find them via the nouveau project git archive. This driver is reverse engineered, and is in no way supported by nVidia. Support for nearly the complete range of nvidia hw from nv04->g80 (nv50) is available, and the kms driver should support driving nearly all output types (displayport is under development still) along with supporting suspend/resume. This work is all from the upstream nouveau project found at nouveau.freedesktop.org. The original authors list from nouveau git tree is: Anssi Hannula <anssi.hannula@iki.fi> Ben Skeggs <bskeggs@redhat.com> Francisco Jerez <currojerez@riseup.net> Maarten Maathuis <madman2003@gmail.com> Marcin Kościelnicki <koriakin@0x04.net> Matthew Garrett <mjg@redhat.com> Matt Parnell <mparnell@gmail.com> Patrice Mandin <patmandin@gmail.com> Pekka Paalanen <pq@iki.fi> Xavier Chantry <shiningxc@gmail.com> along with project founder Stephane Marchesin <marchesin@icps.u-strasbg.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-12-11 19:24:15 +10:00
config DRM_NOUVEAU_BACKLIGHT
bool "Support for backlight control"
depends on DRM_NOUVEAU
default y
help
Say Y here if you want to control the backlight of your display
(e.g. a laptop panel).
drm/nouveau/svm: initial support for shared virtual memory This uses HMM to mirror a process' CPU page tables into a channel's page tables, and keep them synchronised so that both the CPU and GPU are able to access the same memory at the same virtual address. While this code also supports Volta/Turing, it's only enabled for Pascal GPUs currently due to channel recovery being unreliable right now on the later GPUs. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-07-05 12:57:12 +10:00
config DRM_NOUVEAU_SVM
bool "(EXPERIMENTAL) Enable SVM (Shared Virtual Memory) support"
mm: sort out the DEVICE_PRIVATE Kconfig mess The ZONE_DEVICE support doesn't depend on anything HMM related, just on various bits of arch support as indicated by the architecture. Also don't select the option from nouveau as it isn't present in many setups, and depend on it instead. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-06-26 14:27:22 +02:00
depends on DEVICE_PRIVATE
drm/nouveau/svm: initial support for shared virtual memory This uses HMM to mirror a process' CPU page tables into a channel's page tables, and keep them synchronised so that both the CPU and GPU are able to access the same memory at the same virtual address. While this code also supports Volta/Turing, it's only enabled for Pascal GPUs currently due to channel recovery being unreliable right now on the later GPUs. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-07-05 12:57:12 +10:00
depends on DRM_NOUVEAU
depends on STAGING
mm/hmm: make HMM_MIRROR an implicit option Make HMM_MIRROR an option that is selected by drivers wanting to use it instead of a user visible option as it is just a low-level implementation detail. Link: https://lore.kernel.org/r/20190806160554.14046-15-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-08-06 19:05:52 +03:00
select HMM_MIRROR
select MMU_NOTIFIER
drm/nouveau/svm: initial support for shared virtual memory This uses HMM to mirror a process' CPU page tables into a channel's page tables, and keep them synchronised so that both the CPU and GPU are able to access the same memory at the same virtual address. While this code also supports Volta/Turing, it's only enabled for Pascal GPUs currently due to channel recovery being unreliable right now on the later GPUs. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-07-05 12:57:12 +10:00
default n
help
Say Y here if you want to enable experimental support for
Shared Virtual Memory (SVM).
nouveau/gsp: add kconfig option to enable GSP paths by default Turing and Ampere will continue to use the old paths by default, but we should allow distros to decide what the policy is. Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240214040632.661069-1-airlied@gmail.com
2024-02-14 14:06:32 +10:00
config DRM_NOUVEAU_GSP_DEFAULT
bool "Use GSP firmware for Turing/Ampere (needs firmware installed)"
depends on DRM_NOUVEAU
default n
help
Say Y here if you want to use the GSP codepaths by default on
Turing and Ampere GPUs.
drm/nouveau: incorporate I2C TV encoder drivers Chrontel CH7006 and Silicon Image sil164 drivers use drm_encoder_slave interface which is being used only by the nouveau driver. It doesn't make sense to keep this interface inside the DRM subsystem. In preparation to moving this set of helpers to the nouveau driver, move the only two I2C driver that use that interface to the nouveau driver too. Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250106-nouveau-encoder-slave-v3-1-1d37d2f2c67f@linaro.org
2025-01-06 01:00:13 +02:00
config DRM_NOUVEAU_CH7006
tristate "Chrontel ch7006 TV encoder"
depends on DRM_NOUVEAU
default m
help
Support for Chrontel ch7006 and similar TV encoders.
This driver is currently only useful if you're also using
the nouveau driver.
config DRM_NOUVEAU_SIL164
tristate "Silicon Image sil164 TMDS transmitter"
depends on DRM_NOUVEAU
default m
help
Support for sil164 and similar single-link (or dual-link
when used in pairs) TMDS transmitters.
Reference in a new issue Copy permalink