linux-stable.git/drivers/video/fbdev/Kconfig, branch v3.16.78

video: mx3fb: always enable BACKLIGHT_LCD_SUPPORT

2017-11-11T13:33:55+00:00

commit 9c8ee3c7341393811d5be5eb61b815e76f92c799 upstream.

Commit 7edaa761ee81b ("video: mx3fb: Add backlight control support")
changed the mx3fb driver so it always selects the BACKLIGHT_CLASS_DEVICE
symbol, but that is hidden behind BACKLIGHT_LCD_SUPPORT in Kconfig, so
we get a Kconfig warning for multi_v5_defconfig, which doesn't have that:

Warning: (DRM_RADEON && DRM_NOUVEAU && DRM_I915 && DRM_GMA500 &&
DRM_SHMOBILE && DRM_TILCDC && FB_BACKLIGHT && FB_MX3 && USB_APPLEDISPLAY
&& FB_OLPC_DCON && ASUS_LAPTOP && SONY_LAPTOP && THINKPAD_ACPI &&
EEEPC_LAPTOP && ACPI_CMPC && SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE
which has unmet direct dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT)

This makes sure we always enable both symbols together for mx3fb, like
we do for the other drivers that can't be built without backlight
support. Note that a better solution would be to ensure the driver can
work with or without backlight support.

Signed-off-by: Arnd Bergmann 
Cc: Alexander Stein 
Cc: Tomi Valkeinen 
Cc: linux-fbdev@vger.kernel.org
Cc: Jean-Christophe Plagniol-Villard 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Ben Hutchings

fbdev: sti: don't select CONFIG_VT

2017-08-26T01:14:46+00:00

commit 34bf129a7f068e3108dbb051b4b05674e2a270e7 upstream.

While working on another build error, I ran into several variations of
this dependency loop:

subsection "Kconfig recursive dependency limitations"
drivers/input/Kconfig:8:	symbol INPUT is selected by VT
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/tty/Kconfig:12:	symbol VT is selected by FB_STI
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:677:	symbol FB_STI depends on FB
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:5:	symbol FB is selected by DRM_KMS_FB_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:72:	symbol DRM_KMS_FB_HELPER is selected by DRM_KMS_CMA_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:137:	symbol DRM_KMS_CMA_HELPER is selected by DRM_HDLCD
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/arm/Kconfig:6:	symbol DRM_HDLCD depends on OF
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/of/Kconfig:4:	symbol OF is selected by X86_INTEL_CE
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
arch/x86/Kconfig:523:	symbol X86_INTEL_CE depends on X86_IO_APIC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
arch/x86/Kconfig:1011:	symbol X86_IO_APIC depends on X86_LOCAL_APIC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
arch/x86/Kconfig:1005:	symbol X86_LOCAL_APIC depends on X86_UP_APIC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
arch/x86/Kconfig:980:	symbol X86_UP_APIC depends on PCI_MSI
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/pci/Kconfig:11:	symbol PCI_MSI is selected by AMD_IOMMU
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/iommu/Kconfig:106:	symbol AMD_IOMMU depends on IOMMU_SUPPORT
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/iommu/Kconfig:5:	symbol IOMMU_SUPPORT is selected by DRM_ETNAVIV
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/etnaviv/Kconfig:2:	symbol DRM_ETNAVIV depends on THERMAL
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/thermal/Kconfig:5:	symbol THERMAL is selected by ACPI_VIDEO
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/acpi/Kconfig:183:	symbol ACPI_VIDEO is selected by INPUT

This doesn't currently show up as I fixed the 'THERMAL' part of it,
but I noticed that the FB_STI dependency should not be there but
was introduced by slightly incorrect bug-fix patch that tried to
fix a link error.

Instead of selecting 'VT' to make us enter the drivers/video/console
directory at compile-time, it's sufficient to build the
drivers/video/console/sticore.c file by adding its directory
to when CONFIG_FB_STI is enabled. Alternatively, we could move the
sticore code to another directory that is always built when we
have at STI_CONSOLE or FB_STI enabled.

Fixes: 17085a934592 ("parisc: stifb: should depend on STI_CONSOLE")
Signed-off-by: Arnd Bergmann 
Cc: Helge Deller 
Cc: "James E.J. Bottomley" 
Cc: Alexander Beregalov 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Ben Hutchings

xen kconfig: don't "select INPUT_XEN_KBDDEV_FRONTEND"

2016-04-30T22:05:57+00:00

commit 13aa38e291bdd4e4018f40dd2f75e464814dcbf3 upstream.

The Xen framebuffer driver selects the xen keyboard driver, so the latter
will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
is a loadable module, this configuration cannot work. On mainline kernels,
the symbol will be enabled but not used, while in combination with
a patch I have to detect such useless configurations, we get the
expected link failure:

drivers/input/built-in.o: In function `xenkbd_remove':
xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device'
xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device'

This removes the extra "select", as it just causes more trouble than
it helps. In theory, some defconfig file might break if it has
XEN_FBDEV_FRONTEND in it but not INPUT_XEN_KBDDEV_FRONTEND. The Kconfig
fragment we ship in the kernel (kernel/configs/xen.config) however
already enables both, and anyone using an old .config file would
keep having both enabled.

Signed-off-by: Arnd Bergmann 
Suggested-by: David Vrabel 
Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND")
Acked-by: Stefano Stabellini 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Ben Hutchings

video: mx3fb: Add backlight control support

2014-05-16T08:58:39+00:00

This patch add backlight control support to allow dimming the backlight
using the internal PWM. Currently the brightness is set fixed to a
maximum of 255.

Signed-off-by: Alexander Stein 
Signed-off-by: Tomi Valkeinen

video: Kconfig: Add a dependency to the Goldfish framebuffer driver

2014-05-09T09:55:48+00:00

All other Goldfish drivers depend on GOLDFISH, I see no reason why the
framebuffer driver would be an exception.

Signed-off-by: Jean Delvare 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Signed-off-by: Tomi Valkeinen

video/nuc900: allow modular build

2014-05-09T09:55:47+00:00

The frame buffer core may be a loadable module, and in this
case, the nuc900 driver cannot be built-in. Turning it into
a tristate option lets Kconfig work out the dependency and
avoid broken builds.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Peter Griffin 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: linux-fbdev@vger.kernel.org
Cc: Wan ZongShun 
Signed-off-by: Tomi Valkeinen

video: atmel needs FB_BACKLIGHT

2014-05-09T09:55:47+00:00

The atmel frame buffer driver doesn't build if FB_BACKLIGHT
is disabled, so select it here as we do for lots of other
drivers.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Peter Griffin 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Tomi Valkeinen

video: clarify I2C dependencies

2014-05-09T09:55:45+00:00

We can only use I2C support in frame buffer drivers if
Either I2C is built-in, or both I2C and the driver itself
are loadable modules.

Fix this dependency for MB862XX and CyberPro frame buffers.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Peter Griffin 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: linux-fbdev@vger.kernel.org
Cc: Russell King 
Cc: Anatolij Gustschin 
Signed-off-by: Tomi Valkeinen

video: sh_mobile_lcdcfb depends on meram

2014-05-07T09:16:33+00:00

The sh_mobile_lcdcfb driver calls interfaces provided
by the corresponding "meram" helper. This fails if meram
is a module but lcdcfb is built-in.

To work around it, this uses special Kconfig magic to
only allow lcdcfb to be built if
a) both are modules,
b) meram is built-in, or
c) meram is disabled and the helpers stubbed out

Changing meram from 'y' to 'm' now forces clcd to
be a module as well, which seems to be the desired
behavior.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Peter Griffin 
Cc: Simon Horman 
Cc: Magnus Damm 
Cc: linux-sh@vger.kernel.org
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Tomi Valkeinen

fbdev: Fix tmiofb driver dependencies

2014-04-30T11:04:48+00:00

The tmiofb driver should not depend on MFD_CORE but on MFD_TMIO.
Without the tmio_core driver, tmiofb has no platform device to bind
to and is thus useless.

Signed-off-by: Jean Delvare 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Signed-off-by: Tomi Valkeinen