similar to: [PATCH v3] drm: Only select I2C_ALGOBIT for drivers that actually need it

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

select isn't recursive, so we can't turn on DRM_TTM + DRM_TTM_HELPER in config DRM_VRAM_HELPER, we have to select them on the vram users instead. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/Kconfig | 2 -- drivers/gpu/drm/ast/Kconfig | 2 ++ drivers/gpu/drm/bochs/Kconfig | 2 ++

Hello Uwe, On 12/19/22 09:36, Uwe Kleine-K?nig wrote: > 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

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

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

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

> -----Original Message----- > From: amd-gfx [mailto:amd-gfx-bounces at lists.freedesktop.org] On Behalf > Of Cihangir Akturk > Sent: Friday, August 11, 2017 8:33 AM > Cc: devel at driverdev.osuosl.org; linux-arm-msm at vger.kernel.org; intel- > gfx at lists.freedesktop.org; linux-kernel at vger.kernel.org; dri- > devel at lists.freedesktop.org; etnaviv at

Only the following drivers aren't converted: - amdgpu, because of the driver_feature mangling due to virt support - nouveau, because DRIVER_ATOMIC uapi is still not the default on the platforms where it's supported (i.e. again driver_feature mangling) - vc4, again because of driver_feature mangling - qxl, because the ioctl table is somewhere else and moving that is maybe a bit too

Hi Am 23.10.20 um 14:28 schrieb Daniel Vetter: > Only the following drivers aren't converted: > - amdgpu, because of the driver_feature mangling due to virt support > - nouveau, because DRIVER_ATOMIC uapi is still not the default on the > platforms where it's supported (i.e. again driver_feature mangling) > - vc4, again because of driver_feature mangling > - qxl,

Only the following drivers aren't converted: - amdgpu, because of the driver_feature mangling due to virt support. Subsequent patch will address this. - nouveau, because DRIVER_ATOMIC uapi is still not the default on the platforms where it's supported (i.e. again driver_feature mangling) - vc4, again because of driver_feature mangling - qxl, because the ioctl table is somewhere else

Le lun. 10 déc. 2018 à 11:24, Thierry Reding <thierry.reding at gmail.com> a écrit : > > On Mon, Dec 10, 2018 at 11:11:33AM +0100, Daniel Vetter wrote: > > Having the probe helper stuff (which pretty much everyone needs) in > > the drm_crtc_helper.h file (which atomic drivers should never need) is > > confusing. Split them out. > > > > To make sure I

Well first problem is I'm not sure if that is a good idea. Essentially we want to get rid of TTM in the long run. On the other hand this work might aid with that goal, so it might be worth a try. Second is that this might actually not work of hand. The problem is here: > + /* TODO: This test used to be performed by drivers, but can > + * this actually happen? If so, should we put

Only the following drivers aren't converted: - amdgpu, because of the driver_feature mangling due to virt support - nouveau, because DRIVER_ATOMIC uapi is still not the default on the platforms where it's supported (i.e. again driver_feature mangling) - vc4, again because of driver_feature mangling - qxl, because the ioctl table is somewhere else and moving that is maybe a bit too

On Mon, Dec 10, 2018 at 11:11:33AM +0100, Daniel Vetter wrote: > Having the probe helper stuff (which pretty much everyone needs) in > the drm_crtc_helper.h file (which atomic drivers should never need) is > confusing. Split them out. > > To make sure I actually achieved the goal here I went through all > drivers. And indeed, all atomic drivers are now free of >

Hi Daniel. On Fri, Oct 23, 2020 at 06:04:44PM +0200, Daniel Vetter wrote: > Only the following drivers aren't converted: > - amdgpu, because of the driver_feature mangling due to virt support > - nouveau, because DRIVER_ATOMIC uapi is still not the default on the > platforms where it's supported (i.e. again driver_feature mangling) > - vc4, again because of driver_feature

Hi, most of this patch set still needs reviews. If it's too large for merging or reviewing at once, I could move the driver changes into separate patch sets. The vbox driver's changes have been accepted by Hans already. So only keeping the core changes plus vbox would be an option. Best regards Thomas Am 08.05.19 um 10:26 schrieb Thomas Zimmermann: > Several simple framebuffer

Having the probe helper stuff (which pretty much everyone needs) in the drm_crtc_helper.h file (which atomic drivers should never need) is confusing. Split them out. To make sure I actually achieved the goal here I went through all drivers. And indeed, all atomic drivers are now free of drm_crtc_helper.h includes. Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> Cc:

Having the probe helper stuff (which pretty much everyone needs) in the drm_crtc_helper.h file (which atomic drivers should never need) is confusing. Split them out. To make sure I actually achieved the goal here I went through all drivers. And indeed, all atomic drivers are now free of drm_crtc_helper.h includes. Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> Cc:

Having the probe helper stuff (which pretty much everyone needs) in the drm_crtc_helper.h file (which atomic drivers should never need) is confusing. Split them out. To make sure I actually achieved the goal here I went through all drivers. And indeed, all atomic drivers are now free of drm_crtc_helper.h includes. Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> Cc: