Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44 |
|
#
b88baab8 |
| 04-Aug-2023 |
Danilo Krummrich <dakr@redhat.com> |
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 addr
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
show more ...
|
Revision tags: v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6 |
|
#
cf8698df |
| 12-Jan-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/nouveau: Remove support for legacy contexts/buffers
Remove nouveau's support for legacy contexts and buffers. It was required by libdrm earlier than 2.4.33, released in March 2012. A previous at
drm/nouveau: Remove support for legacy contexts/buffers
Remove nouveau's support for legacy contexts and buffers. It was required by libdrm earlier than 2.4.33, released in March 2012. A previous attempt in 2013 to remove the functionality [1] had to be reverted [2] as there were still users left. Libdrm 2.4.33 is now almost 11 years old and it is time for userspace to move on.
With the nouveau code gone, we can also remove the driver-feature bit DRIVER_KMS_LEGACY_CONTEXT.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Karol Herbst <kherbst@redhat.com> Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7c510133d93dd6f15ca040733ba7b2891ed61fd1 # 1 Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095 # 2 Link: https://patchwork.freedesktop.org/patch/msgid/20230112133858.17087-1-tzimmermann@suse.de
show more ...
|
Revision tags: v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14 |
|
#
000458b5 |
| 19-Dec-2022 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
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 a
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
show more ...
|
Revision tags: v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49 |
|
#
7ac20b3a |
| 20-Jun-2022 |
Hans de Goede <hdegoede@redhat.com> |
drm/nouveau/Kconfig: Drop duplicate "select ACPI_VIDEO"
Before this change nouveau's Kconfig section had 2 "select ACPI_VIDEO" statements:
select ACPI_VIDEO if ACPI && X86 && BACKLIGHT_CLASS_DEVICE
drm/nouveau/Kconfig: Drop duplicate "select ACPI_VIDEO"
Before this change nouveau's Kconfig section had 2 "select ACPI_VIDEO" statements:
select ACPI_VIDEO if ACPI && X86 && BACKLIGHT_CLASS_DEVICE && INPUT select ACPI_VIDEO if ACPI && X86
Drop the one with the extra conditions, if the conditions for that one are true then the second statement will always select ACPI_VIDEO already.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220620094627.9730-1-hdegoede@redhat.com
show more ...
|
Revision tags: v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36 |
|
#
644edf52 |
| 21-Apr-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
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 help
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
show more ...
|
#
1e0f6642 |
| 21-Apr-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
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. Upda
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
show more ...
|
Revision tags: v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15 |
|
#
adb9d5a2 |
| 14-Jan-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/dp: Move DisplayPort helpers into separate helper module
Move DisplayPort functions into a separate module to reduce the size of the KMS helpers. Select DRM_DP_HELPER for all users of the code.
drm/dp: Move DisplayPort helpers into separate helper module
Move DisplayPort functions into a separate module to reduce the size of the KMS helpers. Select DRM_DP_HELPER for all users of the code. To avoid naming conflicts, rename drm_dp_helper.c to drm_dp.c
This change can help to reduce the size of the kernel binary. Some numbers from a x86-64 test build:
Before: drm_kms_helper.ko: 447480 bytes
After: drm_dp_helper.ko: 216632 bytes drm_kms_helper.ko: 239424 bytes
For early-boot graphics, generic DRM drivers, such as simpledrm, require DRM KMS helpers to be built into the kernel. Generic helper functions for DisplayPort take up a significant portion of DRM KMS helper library. These functions are not used by generic drivers and can be loaded as a module.
v3: * fix include statement in DRM selftests v2: * move DP helper code into dp/ (Jani)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Lyude Paul <lyude@redhat.com> Acked-by: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220114114535.29157-4-tzimmermann@suse.de
show more ...
|
Revision tags: v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10 |
|
#
49a3f51d |
| 03-Nov-2020 |
Thomas Zimmermann <tzimmermann@suse.de> |
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 b
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
show more ...
|
Revision tags: v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48 |
|
#
2853ccf0 |
| 19-Jun-2020 |
Ben Skeggs <bskeggs@redhat.com> |
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 mo
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>
show more ...
|
Revision tags: v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12 |
|
#
742db30c |
| 13-Jan-2020 |
Takashi Iwai <tiwai@suse.de> |
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
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>
show more ...
|
#
ee864216 |
| 16-Jan-2020 |
Chen Zhou <chenzhou10@huawei.com> |
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_fws
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>
show more ...
|
Revision tags: v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12 |
|
#
ee4c9d20 |
| 20-Nov-2019 |
Krzysztof Kozlowski <krzk@kernel.org> |
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: Krzys
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
show more ...
|
Revision tags: v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9 |
|
#
9b2ed9cb |
| 14-Aug-2019 |
Christoph Hellwig <hch@lst.de> |
mm: remove CONFIG_MIGRATE_VMA_HELPER
CONFIG_MIGRATE_VMA_HELPER guards helpers that are required for proper devic private memory support. Remove the option and just check for CONFIG_DEVICE_PRIVATE i
mm: remove CONFIG_MIGRATE_VMA_HELPER
CONFIG_MIGRATE_VMA_HELPER guards helpers that are required for proper devic private memory support. Remove the option and just check for CONFIG_DEVICE_PRIVATE instead.
Link: https://lore.kernel.org/r/20190814075928.23766-11-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Jason Gunthorpe <jgg@mellanox.com> Tested-by: Ralph Campbell <rcampbell@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
show more ...
|
Revision tags: v5.2.8, v5.2.7 |
|
#
9c240a7b |
| 06-Aug-2019 |
Christoph Hellwig <hch@lst.de> |
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.
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>
show more ...
|
Revision tags: v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16 |
|
#
b6b346a0 |
| 26-Jun-2019 |
Christoph Hellwig <hch@lst.de> |
mm: don't select MIGRATE_VMA_HELPER from HMM_MIRROR
The migrate_vma helper is only used by noveau to migrate device private pages around. Other HMM_MIRROR users like amdgpu or infiniband don't need
mm: don't select MIGRATE_VMA_HELPER from HMM_MIRROR
The migrate_vma helper is only used by noveau to migrate device private pages around. Other HMM_MIRROR users like amdgpu or infiniband don't need it.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Jason Gunthorpe <jgg@mellanox.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
show more ...
|
#
43535b0a |
| 26-Jun-2019 |
Christoph Hellwig <hch@lst.de> |
mm: remove the HMM config option
All the mm/hmm.c code is better keyed off HMM_MIRROR. Also let nouveau depend on it instead of the mix of a dummy dependency symbol plus the actually selected one.
mm: remove the HMM config option
All the mm/hmm.c code is better keyed off HMM_MIRROR. Also let nouveau depend on it instead of the mix of a dummy dependency symbol plus the actually selected one. Drop various odd dependencies, as the code is pretty portable.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Jason Gunthorpe <jgg@mellanox.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
show more ...
|
#
7328d9cc |
| 26-Jun-2019 |
Christoph Hellwig <hch@lst.de> |
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
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>
show more ...
|
Revision tags: v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4 |
|
#
ec8f24b7 |
| 19-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
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
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>
show more ...
|
Revision tags: v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18, v4.19.17 |
|
#
8c5dc8d9 |
| 17-Jan-2019 |
Alexander Shiyan <shc_work@mail.ru> |
video: backlight: Remove useless BACKLIGHT_LCD_SUPPORT kernel symbol
We have two *_CLASS_DEVICE kernel config options (LCD_CLASS_DEVICE and BACKLIGHT_LCD_DEVICE) that do the same job. The patch remo
video: backlight: Remove useless BACKLIGHT_LCD_SUPPORT kernel symbol
We have two *_CLASS_DEVICE kernel config options (LCD_CLASS_DEVICE and BACKLIGHT_LCD_DEVICE) that do the same job. The patch removes useless BACKLIGHT_LCD_SUPPORT option and converts LCD_CLASS_DEVICE into a menu.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
show more ...
|
#
61ae2270 |
| 18-Apr-2019 |
Dave Airlie <airlied@redhat.com> |
drm: allow removal of legacy codepaths (v4.1)
If you don't want the legacy drivers, then lets get rid of all the legacy codepaths from the core module.
This drop the size of drm.ko for me by about
drm: allow removal of legacy codepaths (v4.1)
If you don't want the legacy drivers, then lets get rid of all the legacy codepaths from the core module.
This drop the size of drm.ko for me by about 10%. 380515 7422 4192 392129 5fbc1 ../../drm-next-build/drivers/gpu/drm/drm.ko 351736 7298 4192 363226 58ada ../../drm-next-build/drivers/gpu/drm/drm.ko
v2: drop drm_lock as well, fix some DMA->DRM typos v3: avoid ifdefs in mainline code v4: rework ioctl defs v4.1: fix nouveau Kconfig
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
show more ...
|
#
b30a43ac |
| 18-Apr-2019 |
Dave Airlie <airlied@redhat.com> |
drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v3)
There was a nouveau DDX that relied on legacy context ioctls to work, but we fixed it years ago, give distros that have a mo
drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v3)
There was a nouveau DDX that relied on legacy context ioctls to work, but we fixed it years ago, give distros that have a modern DDX the option to break the uAPI and close the mess of holes that legacy context support is.
Full context of the story:
commit 0e975980d435d58df2d430d688b8c18778b42218 Author: Peter Antoine <peter.antoine@intel.com> Date: Tue Jun 23 08:18:49 2015 +0100
drm: Turn off Legacy Context Functions
The context functions are not used by the i915 driver and should not be used by modeset drivers. These driver functions contain several bugs and security holes. This change makes these functions optional can be turned on by a setting, they are turned off by default for modeset driver with the exception of the nouvea driver that may require them with an old version of libdrm.
The previous attempt was
commit 7c510133d93dd6f15ca040733ba7b2891ed61fd1 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Aug 8 15:41:21 2013 +0200
drm: mark context support as a legacy subsystem
but this had to be reverted
commit c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095 Author: Dave Airlie <airlied@redhat.com> Date: Fri Sep 20 08:32:59 2013 +1000
Revert "drm: mark context support as a legacy subsystem"
v2: remove returns from void function, and formatting (Daniel Vetter)
v3: - s/Nova/nouveau/ in the commit message, and add references to the previous attempts - drop the part touching the drm hw lock, that should be a separate patch.
Signed-off-by: Peter Antoine <peter.antoine@intel.com> (v2) Cc: Peter Antoine <peter.antoine@intel.com> (v2) Reviewed-by: Peter Antoine <peter.antoine@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: move DRM_VM dependency into legacy config. v3: fix missing dep (kbuild robot)
Cc: stable@vger.kernel.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
show more ...
|
Revision tags: v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11 |
|
#
5be73b69 |
| 26-Jul-2018 |
Jérôme Glisse <jglisse@redhat.com> |
drm/nouveau/dmem: device memory helpers for SVM
Device memory can be use in SVM, in which case we do not have any of the existing buffer object. This commit add infrastructure to allow use of device
drm/nouveau/dmem: device memory helpers for SVM
Device memory can be use in SVM, in which case we do not have any of the existing buffer object. This commit add infrastructure to allow use of device memory without nouveau_bo. Again this is a temporary solution until a rework of GPU memory management.
Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
show more ...
|
Revision tags: v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5 |
|
#
eeaf06ac |
| 04-Jul-2018 |
Ben Skeggs <bskeggs@redhat.com> |
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 ar
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>
show more ...
|
#
399382f8 |
| 02-Jan-2019 |
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> |
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:
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>
show more ...
|
Revision tags: v4.17.4, v4.17.3, v4.17.2, v4.17.1, v4.17, v4.16, v4.15, v4.13.16, v4.14 |
|
#
eb813999 |
| 31-Oct-2017 |
Ben Skeggs <bskeggs@redhat.com> |
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 abl
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>
show more ...
|