similar to: [PATCH] drm/nouveau: fix acpi related kbuild warnings

Currently when X86 && ACPI && !X86_PLATFORM_DEVICES kbuild spits: 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) and goes on, which leaves a situation where ACPI_WMI

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

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 no longer run into those related warnings. If everyone agrees on the general direction, I hope we can

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> ---

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

Am 15.10.20 um 14:38 schrieb Thomas Zimmermann: > 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.

The newly introduced LED handling for nouveau fails to link when the driver is built-in but the LED subsystem is a loadable module: drivers/gpu/drm/nouveau/nouveau.o: In function `nouveau_do_suspend': tvnv17.c:(.text.nouveau_do_suspend+0x10): undefined reference to `nouveau_led_suspend' drivers/gpu/drm/nouveau/nouveau.o: In function `nouveau_do_resume':

From: YueHaibing <yuehaibing at huawei.com> During randconfig builds, I occasionally run into an invalid configuration WARNING: unmet direct dependencies detected for DEVICE_PRIVATE Depends on [n]: ARCH_HAS_HMM_DEVICE [=n] && ZONE_DEVICE [=n] Selected by [y]: - DRM_NOUVEAU_SVM [=y] && HAS_IOMEM [=y] && ARCH_HAS_HMM [=y] && DRM_NOUVEAU [=y] &&

On Tuesday, November 8, 2016 10:46:07 AM CET Ilia Mirkin wrote: > > diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig > > index 78631fb61adf..715cd6f4dc31 100644 > > --- a/drivers/gpu/drm/nouveau/Kconfig > > +++ b/drivers/gpu/drm/nouveau/Kconfig > > @@ -46,6 +46,14 @@ config NOUVEAU_DEBUG > > The paranoia and spam levels

On Tue, Nov 8, 2016 at 8:56 AM, Arnd Bergmann <arnd at arndb.de> wrote: > The newly introduced LED handling for nouveau fails to link when the > driver is built-in but the LED subsystem is a loadable module: > > drivers/gpu/drm/nouveau/nouveau.o: In function `nouveau_do_suspend': > tvnv17.c:(.text.nouveau_do_suspend+0x10): undefined reference to `nouveau_led_suspend'

CONFIG_DEVICE_PRIVATE cannot be selected in configurations without ZONE_DEVICE: WARNING: unmet direct dependencies detected for DEVICE_PRIVATE Depends on [n]: ZONE_DEVICE [=n] Selected by [y]: - DRM_NOUVEAU_SVM [=y] && HAS_IOMEM [=y] && DRM_NOUVEAU [=y] && MMU [=y] && STAGING [=y] kernel/resource.c:1653:28: error: use of undeclared identifier

This fixes the auto-magic detection of LEDS_CLASS by fixing the case where nouveau would be built-in and the LEDS_CLASS would be built as as module. Cc: <stable at vger.kernel.org> # 4.9.x- Reported-by: Intel's 0-DAY Signed-off-by: Martin Peres <martin.peres at free.fr> --- drivers/gpu/drm/nouveau/Kbuild | 2 +- drivers/gpu/drm/nouveau/Kconfig | 9 +++++++++ 2 files changed, 10

On Thu, Jun 13, 2019 at 11:43:21AM +0200, Christoph Hellwig wrote: > The code hasn't been used since it was added to the tree, and doesn't > appear to actually be usable. Mark it as BROKEN until either a user > comes along or we finally give up on it. > > Signed-off-by: Christoph Hellwig <hch at lst.de> > mm/Kconfig | 1 + > 1 file changed, 1 insertion(+) >

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 at nvidia.com> --- Vince, with this you won't have to export

From: Matt Parnell <mparnell at gmail.com> Sometimes we have DEBUG_FS enabled, but don't want output from certain modules. Most modules make this an option, so I figured that Nouveau needed it too. Signed-off-by: Matt Parnell <mparnell at gmail.com> --- drivers/gpu/drm/Kconfig | 11 +++++++++++ drivers/gpu/drm/nouveau/Makefile | 2 +-

op 26-06-14 07:33, Alexandre Courbot schreef: > 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

On Wed, Apr 17, 2019 at 10:26:32PM +0800, Yue Haibing wrote: > From: YueHaibing <yuehaibing at huawei.com> > > During randconfig builds, I occasionally run into an invalid configuration > > WARNING: unmet direct dependencies detected for DEVICE_PRIVATE > Depends on [n]: ARCH_HAS_HMM_DEVICE [=n] && ZONE_DEVICE [=n] > Selected by [y]: > - DRM_NOUVEAU_SVM

Hi all, Friendly ping: Who can take this? On 2019/4/17 22:26, Yue Haibing wrote: > From: YueHaibing <yuehaibing at huawei.com> > > During randconfig builds, I occasionally run into an invalid configuration > > WARNING: unmet direct dependencies detected for DEVICE_PRIVATE > Depends on [n]: ARCH_HAS_HMM_DEVICE [=n] && ZONE_DEVICE [=n] > Selected by [y]:

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 at kernel.org> --- drivers/gpu/drm/nouveau/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig index

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: