similar to: [PATCH 0/3] Kconfig dependencies: acpi-video, backlight and thermal

randconfig builds occasionally produce this Kconfig warning: warning: (DRM_RADEON && DRM_AMDGPU && DRM_NOUVEAU && DRM_I915 && DRM_GMA500 && DRM_SHMOBILE && DRM_TILCDC && DRM_FSL_DCU && DRM_TINYDRM && DRM_PARADE_PS8622 && FB_BACKLIGHT && FB_ARMCLCD && FB_MX3 && USB_APPLEDISPLAY &&

When CONFIG_THERMAL is enabled as a loadable module, and etnaviv is built-in, we get a link error: drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_bind': etnaviv_gpu.c:(.text.etnaviv_gpu_bind+0x34): undefined reference to `thermal_of_cooling_device_register' etnaviv_gpu.c:(.text.etnaviv_gpu_bind+0xe0): undefined reference to `thermal_cooling_device_unregister'

ACPI_VIDEO keeps causing problems with circular Kconfig dependencies, as it depends on a couple of other symbols, and it gets selected by drivers that may end up being depending on others. This is an attempt to simplify this by changing all drivers that currently 'select ACPI_VIDEO' to use 'depends on'. This by itself simplifies the dependency lists for the other drivers. We make

On Wed, Jul 26, 2017 at 03:53:09PM +0200, Arnd Bergmann wrote: > Hi everyone, > > It took me a while to figure this out properly, as I kept getting > circular or missing dependencies with video drivers. > > This set of three patches should simplify the situation a bit, > mostly by cleaning up the dependencies around CONFIG_ACPI_VIDEO. > With all three patches applied, I

On Wed, 26 Jul 2017, Daniel Vetter <daniel at ffwll.ch> wrote: > On Wed, Jul 26, 2017 at 03:53:09PM +0200, Arnd Bergmann wrote: >> Hi everyone, >> >> It took me a while to figure this out properly, as I kept getting >> circular or missing dependencies with video drivers. >> >> This set of three patches should simplify the situation a bit, >>

Backlights controlled by i915.ko and only associated with its connectors and also only associated with the intel_drmfb fbcon, controlled by i915.ko. In this situation, we already handle adjusting the backlight when the fbcon is blanked/unblanked and do not require backlight trying to do the same. Attempting to register with the fbdev as a client causes lockdep to warn about a dependency cycle: [

On Tue, 12 Jul 2016, Daniel Vetter <daniel at ffwll.ch> wrote: > On Thu, Jun 30, 2016 at 12:30:56PM +0100, Chris Wilson wrote: >> Backlights controlled by i915.ko and only associated with its connectors >> and also only associated with the intel_drmfb fbcon, controlled by >> i915.ko. In this situation, we already handle adjusting the backlight >> when the fbcon is

The GEM and PRIME related callbacks in struct drm_driver are deprecated in favor of GEM object functions in struct drm_gem_object_funcs. This patchset converts the remaining drivers to object functions and removes most of the obsolete interfaces. Patches #1 to #16 and #18 to #19 convert DRM drivers to GEM object functions, one by one. Each patch moves existing callbacks from struct drm_driver to

On Wed, Jul 26, 2017 at 4:53 PM, Arnd Bergmann <arnd at arndb.de> wrote: > randconfig builds occasionally produce this Kconfig warning: > > warning: (DRM_RADEON && DRM_AMDGPU && DRM_NOUVEAU && DRM_I915 && DRM_GMA500 && DRM_SHMOBILE && DRM_TILCDC && DRM_FSL_DCU && DRM_TINYDRM && DRM_PARADE_PS8622 &&

The GEM and PRIME related callbacks in struct drm_driver are deprecated in favor of GEM object functions in struct drm_gem_object_funcs. This patchset converts the remaining drivers to object functions and removes most of the obsolete interfaces. Version 3 of this patchset mostly fixes drm_gem_prime_handle_to_fd and updates i.MX's dcss driver. The driver was missing from earlier versions and

Pointer variables of (void*) type do not require type cast. Signed-off-by: Su Hui <suhui at nfschina.com> --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 2 +- drivers/gpu/drm/amd/pm/amdgpu_pm.c | 2 +- drivers/gpu/drm/etnaviv/etnaviv_drv.c | 4 ++-- drivers/gpu/drm/nouveau/nouveau_debugfs.c | 2 +-

Pointer variables of (void*) type do not require type cast. Signed-off-by: Su Hui <suhui at nfschina.com> --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 2 +- drivers/gpu/drm/amd/pm/amdgpu_pm.c | 2 +- drivers/gpu/drm/etnaviv/etnaviv_drv.c | 4 ++-- drivers/gpu/drm/nouveau/nouveau_debugfs.c | 2 +-

The GEM and PRIME related callbacks in struct drm_driver are deprecated in favor of GEM object functions in struct drm_gem_object_funcs. This patchset converts the remaining drivers to object functions and removes most of the obsolete interfaces. Patches #1 to #18 convert DRM drivers to GEM object functions, one by one. Each patch moves existing callbacks from struct drm_driver to an instance of

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 at pengutronix.de> ---

DRM's fbdev console uses regular load and store operations to update framebuffer memory. The bochs driver on sparc64 requires the use of I/O-specific load and store operations. We have a workaround, but need a long-term solution to the problem. This patchset changes GEM's vmap/vunmap interfaces to forward pointers of type struct dma_buf_map and updates the generic fbdev emulation to use

DRM's fbdev console uses regular load and store operations to update framebuffer memory. The bochs driver on sparc64 requires the use of I/O-specific load and store operations. We have a workaround, but need a long-term solution to the problem. This patchset changes GEM's vmap/vunmap interfaces to forward pointers of type struct dma_buf_map and updates the generic fbdev emulation to use

DRM's fbdev console uses regular load and store operations to update framebuffer memory. The bochs driver on sparc64 requires the use of I/O-specific load and store operations. We have a workaround, but need a long-term solution to the problem. This patchset changes GEM's vmap/vunmap interfaces to forward pointers of type struct dma_buf_map and updates the generic fbdev emulation to use

DRM's fbdev console uses regular load and store operations to update framebuffer memory. The bochs driver on sparc64 requires the use of I/O-specific load and store operations. We have a workaround, but need a long-term solution to the problem. This patchset changes GEM's vmap/vunmap interfaces to forward pointers of type struct dma_buf_map and updates the generic fbdev emulation to use

DRM's fbdev console uses regular load and store operations to update framebuffer memory. The bochs driver on sparc64 requires the use of I/O-specific load and store operations. We have a workaround, but need a long-term solution to the problem. This patchset changes GEM's vmap/vunmap interfaces to forward pointers of type struct dma_buf_map and updates the generic fbdev emulation to use

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