* [PATCH 2/5] OMAPFB: remove wrong __exit and __exit_p()
From: Tomi Valkeinen @ 2014-10-16 9:39 UTC (permalink / raw)
To: linux-fbdev, linux-omap; +Cc: Felipe Balbi, Tomi Valkeinen
In-Reply-To: <1413452387-25452-1-git-send-email-tomi.valkeinen@ti.com>
omapfb device can be unbound, so using __exit_p() for the driver's
remove callback is wrong.
Remove __exit_p() and __exit from the driver's remove.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
index ec2d132c782d..9cbf1ced51c2 100644
--- a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
@@ -2619,7 +2619,7 @@ err0:
return r;
}
-static int __exit omapfb_remove(struct platform_device *pdev)
+static int omapfb_remove(struct platform_device *pdev)
{
struct omapfb2_device *fbdev = platform_get_drvdata(pdev);
@@ -2636,7 +2636,7 @@ static int __exit omapfb_remove(struct platform_device *pdev)
static struct platform_driver omapfb_driver = {
.probe = omapfb_probe,
- .remove = __exit_p(omapfb_remove),
+ .remove = omapfb_remove,
.driver = {
.name = "omapfb",
.owner = THIS_MODULE,
--
2.1.1
^ permalink raw reply related
* [PATCH 3/5] OMAPDSS: apply: wait pending updates on manager disable
From: Tomi Valkeinen @ 2014-10-16 9:39 UTC (permalink / raw)
To: linux-fbdev, linux-omap; +Cc: Felipe Balbi, Tomi Valkeinen
In-Reply-To: <1413452387-25452-1-git-send-email-tomi.valkeinen@ti.com>
We should wait for any pending updates when an overlay manager is
about to be disabled, because the updates will never be finished if the
manager is disabled too early.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/fbdev/omap2/dss/apply.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/apply.c b/drivers/video/fbdev/omap2/dss/apply.c
index 0a0b084ce65d..663ccc3bf4e5 100644
--- a/drivers/video/fbdev/omap2/dss/apply.c
+++ b/drivers/video/fbdev/omap2/dss/apply.c
@@ -1132,6 +1132,8 @@ static void dss_mgr_disable_compat(struct omap_overlay_manager *mgr)
if (!mp->enabled)
goto out;
+ wait_pending_extra_info_updates();
+
if (!mgr_manual_update(mgr))
dispc_mgr_disable_sync(mgr->id);
--
2.1.1
^ permalink raw reply related
* [PATCH 4/5] OMAPFB: fix overlay disable when freeing resources.
From: Tomi Valkeinen @ 2014-10-16 9:39 UTC (permalink / raw)
To: linux-fbdev, linux-omap; +Cc: Felipe Balbi, Tomi Valkeinen
In-Reply-To: <1413452387-25452-1-git-send-email-tomi.valkeinen@ti.com>
When omapfb is shutting down, it will disable all the overlays. However,
instead of actually disabling all the overlays, it disables only all the
overlays that are currently attached to framebuffers.
On OMAP4+, this leaves the fourth overlay left enabled.
Fix the loop so that we actually go through all the overlays.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
index 9cbf1ced51c2..36ffb525be73 100644
--- a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
@@ -1833,14 +1833,10 @@ static void omapfb_free_resources(struct omapfb2_device *fbdev)
if (fbdev = NULL)
return;
- for (i = 0; i < fbdev->num_fbs; i++) {
- struct omapfb_info *ofbi = FB2OFB(fbdev->fbs[i]);
- int j;
+ for (i = 0; i < fbdev->num_overlays; i++) {
+ struct omap_overlay *ovl = fbdev->overlays[i];
- for (j = 0; j < ofbi->num_overlays; j++) {
- struct omap_overlay *ovl = ofbi->overlays[j];
- ovl->disable(ovl);
- }
+ ovl->disable(ovl);
}
for (i = 0; i < fbdev->num_fbs; i++)
--
2.1.1
^ permalink raw reply related
* [PATCH 5/5] OMAPFB: fix releasing overlays
From: Tomi Valkeinen @ 2014-10-16 9:39 UTC (permalink / raw)
To: linux-fbdev, linux-omap; +Cc: Felipe Balbi, Tomi Valkeinen
In-Reply-To: <1413452387-25452-1-git-send-email-tomi.valkeinen@ti.com>
omapfb disables all the overlays when freeing resources, but it should
also remove those overlays from overlay managers.
Not doing so causes a crash if omapfb is unbound and bound, or omapfb
module is removed and loaded, while keeping omapdss around.
Fix this by calling unset_manager() for all overlays.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
index 36ffb525be73..58ffd651d2c2 100644
--- a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
@@ -1837,6 +1837,9 @@ static void omapfb_free_resources(struct omapfb2_device *fbdev)
struct omap_overlay *ovl = fbdev->overlays[i];
ovl->disable(ovl);
+
+ if (ovl->manager)
+ ovl->unset_manager(ovl);
}
for (i = 0; i < fbdev->num_fbs; i++)
--
2.1.1
^ permalink raw reply related
* Re: [PATCH 2/5] OMAPFB: remove wrong __exit and __exit_p()
From: Felipe Balbi @ 2014-10-16 13:19 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, linux-omap, Felipe Balbi
In-Reply-To: <1413452387-25452-2-git-send-email-tomi.valkeinen@ti.com>
[-- Attachment #1: Type: text/plain, Size: 394 bytes --]
On Thu, Oct 16, 2014 at 12:39:44PM +0300, Tomi Valkeinen wrote:
> omapfb device can be unbound, so using __exit_p() for the driver's
> remove callback is wrong.
>
> Remove __exit_p() and __exit from the driver's remove.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
and why was my version dropped ?
http://marc.info/?l=linux-fbdev&m=141331137230988&w=2
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 2/5] OMAPFB: remove wrong __exit and __exit_p()
From: Tomi Valkeinen @ 2014-10-16 13:23 UTC (permalink / raw)
To: balbi; +Cc: linux-fbdev, linux-omap
In-Reply-To: <20141016131939.GB3480@saruman>
[-- Attachment #1: Type: text/plain, Size: 632 bytes --]
On 16/10/14 16:19, Felipe Balbi wrote:
> On Thu, Oct 16, 2014 at 12:39:44PM +0300, Tomi Valkeinen wrote:
>> omapfb device can be unbound, so using __exit_p() for the driver's
>> remove callback is wrong.
>>
>> Remove __exit_p() and __exit from the driver's remove.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>
> and why was my version dropped ?
>
> http://marc.info/?l=linux-fbdev&m=141331137230988&w=2
Oh, sorry, for no reason. I started from scratch as there seemed to be
enough issues there, and didn't remember you had the exact same patch.
I'll use yours instead of my version.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* *** Your Money Transfer Control Number [MTCN] is: 590575410 *** 364dcyax585 ( linux-fbdev@vger.kerne
From: Western Union Online @ 2014-10-16 15:15 UTC (permalink / raw)
To: linux-fbdev
Dear customer,
Thank you for using the Western Union Money Transfer®.
Your money transfer has been authorized and is now available for pick up by the receiver.
Transfers to certain destinations may be subject to further delay or additional restrictions.
TRANSACTION DETAILS:
Your Money Transfer Control Number [MTCN] is: 590575410
Please use this number for any inquiries.
Date of Order: Th, 16 Oct 2014 11:26:48
Amount Sent: $94.50
You can cancel this transfer by using the hyperlink below:
http://hoodoola.com/WUCOMWEB.transactions.HomePage.cancel.php.session.mtcn.590575482.summ_2294.50.date.Wed.Th.16.Oct.2014.11.26.48/
Thank you for using Western Union!
————————————————————————–
DO NOT REPLY TO THIS EMAIL.
^ permalink raw reply
* [PATCH] drivers: video: fbdev: atmel_lcdfb.c: remove unnecessary header
From: Alexandre Belloni @ 2014-10-17 12:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1404440796-11090-1-git-send-email-mwelling@ieee.org>
Remove unnecessary mach/cpu.h header to be able to converge to a multiplatform
kernel.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
drivers/video/fbdev/atmel_lcdfb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/atmel_lcdfb.c b/drivers/video/fbdev/atmel_lcdfb.c
index 1d8bdb92939b..ea45a30fd4d2 100644
--- a/drivers/video/fbdev/atmel_lcdfb.c
+++ b/drivers/video/fbdev/atmel_lcdfb.c
@@ -26,7 +26,6 @@
#include <video/of_display_timing.h>
#include <video/videomode.h>
-#include <mach/cpu.h>
#include <asm/gpio.h>
#include <video/atmel_lcdc.h>
--
1.9.1
^ permalink raw reply related
* [PATCH] drivers: depend on instead of select BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO
From: Jani Nikula @ 2014-10-17 21:13 UTC (permalink / raw)
To: linux-kernel, dri-devel, linuxppc-dev, platform-driver-x86,
linux-usb, linux-fbdev
Cc: Daniel Drake, Jens Frederich, Jani Nikula, Greg Kroah-Hartman,
Jon Nettleton, Randy Dunlap, Tomi Valkeinen, Laurent Pinchart,
Daniel Vetter, Darren Hart, Jean-Christophe Plagniol-Villard
Documentation/kbuild/kconfig-language.txt warns to use select with care,
and in general use select only for non-visible symbols and for symbols
with no dependencies, because select will force a symbol to a value
without visiting the dependencies.
Select has become particularly problematic, interdependently, with the
BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO configs. For example:
scripts/kconfig/conf --randconfig Kconfig
KCONFIG_SEED=0x48312B00
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)
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)
With tristates it's possible to end up selecting FOO=y depending on
BAR=m in the config, which gets discovered at build time, not config
time, like reported in the thread referenced below.
Do the following to fix the dependencies:
* Depend on instead of select BACKLIGHT_CLASS_DEVICE everywhere. Drop
select BACKLIGHT_LCD_SUPPORT in such cases, as it's a dependency of
BACKLIGHT_CLASS_DEVICE.
* Remove config FB_BACKLIGHT altogether, and replace it with a
dependency on BACKLIGHT_CLASS_DEVICE. All configs selecting
FB_BACKLIGHT select or depend on FB anyway, so we can simplify.
* Depend on (ACPI && ACPI_VIDEO) || ACPI=n in several places instead of
selecting ACPI_VIDEO and a number of its dependencies if ACPI is
enabled. This is tied to backlight, as ACPI_VIDEO depends on
BACKLIGHT_CLASS_DEVICE.
* Replace a couple of select INPUT/VT with depends as it seemed to be
necessary.
Reference: http://lkml.kernel.org/r/CA+r1ZhhmT4DrWtf6MbRQo5EqXwx+LxCqh15Vsu_d9WpftLhnxw@mail.gmail.com
Reported-by: Jim Davis <jim.epost@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Darren Hart <dvhart@infradead.org>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Jens Frederich <jfrederich@gmail.com>
Cc: Daniel Drake <dsd@laptop.org>
Cc: Jon Nettleton <jon.nettleton@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
Sorry for the huge distribution; this is really quite hard to split up
sensibly without breaking the build!
---
drivers/gpu/drm/Kconfig | 2 +-
drivers/gpu/drm/gma500/Kconfig | 4 +---
drivers/gpu/drm/i915/Kconfig | 9 ++-------
drivers/gpu/drm/nouveau/Kconfig | 10 ++--------
drivers/gpu/drm/shmobile/Kconfig | 2 +-
drivers/gpu/drm/tilcdc/Kconfig | 3 +--
drivers/macintosh/Kconfig | 2 +-
drivers/platform/x86/Kconfig | 19 ++++++++-----------
drivers/staging/olpc_dcon/Kconfig | 2 +-
drivers/usb/misc/Kconfig | 3 +--
drivers/video/fbdev/Kconfig | 29 +++++++++++------------------
drivers/video/fbdev/core/fbsysfs.c | 8 ++++----
include/linux/fb.h | 2 +-
include/uapi/linux/fb.h | 2 +-
14 files changed, 36 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index e3b4b0f02b3d..dc789d0e293c 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -99,6 +99,7 @@ config DRM_R128
config DRM_RADEON
tristate "ATI Radeon"
depends on DRM && PCI
+ depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -108,7 +109,6 @@ config DRM_RADEON
select DRM_TTM
select POWER_SUPPLY
select HWMON
- select BACKLIGHT_CLASS_DEVICE
select INTERVAL_TREE
select MMU_NOTIFIER
help
diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
index 17f928ec84ea..a84d0a4fcc58 100644
--- a/drivers/gpu/drm/gma500/Kconfig
+++ b/drivers/gpu/drm/gma500/Kconfig
@@ -8,9 +8,7 @@ config DRM_GMA500
select DRM_KMS_FB_HELPER
select DRM_TTM
# GMA500 depends on ACPI_VIDEO when ACPI is enabled, just like i915
- select ACPI_VIDEO if ACPI
- select BACKLIGHT_CLASS_DEVICE if ACPI
- select INPUT if ACPI
+ depends on (ACPI && ACPI_VIDEO) || ACPI=n
help
Say yes for an experimental 2D KMS framebuffer driver for the
Intel GMA500 ('Poulsbo') and other Intel IMG based graphics
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 4e39ab34eb1c..75d4c52c0971 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -3,6 +3,8 @@ config DRM_I915
depends on DRM
depends on X86 && PCI
depends on (AGP || AGP=n)
+ depends on (ACPI && ACPI_VIDEO) || ACPI=n
+ depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n
select INTEL_GTT
select AGP_INTEL if AGP
select INTERVAL_TREE
@@ -11,13 +13,6 @@ config DRM_I915
select SHMEM
select TMPFS
select DRM_KMS_HELPER
- # i915 depends on ACPI_VIDEO when ACPI is enabled
- # but for select to work, need to select ACPI_VIDEO's dependencies, ick
- select BACKLIGHT_LCD_SUPPORT if ACPI
- select BACKLIGHT_CLASS_DEVICE if ACPI
- select INPUT if ACPI
- select ACPI_VIDEO if ACPI
- select ACPI_BUTTON if ACPI
help
Choose this option if you have a system that has "Intel Graphics
Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig
index 40afc69a3778..40227fc4f284 100644
--- a/drivers/gpu/drm/nouveau/Kconfig
+++ b/drivers/gpu/drm/nouveau/Kconfig
@@ -1,6 +1,7 @@
config DRM_NOUVEAU
tristate "Nouveau (NVIDIA) cards"
depends on DRM && PCI
+ depends on (ACPI && ACPI_VIDEO) || ACPI=n
select FW_LOADER
select DRM_KMS_HELPER
select DRM_KMS_FB_HELPER
@@ -10,18 +11,10 @@ config DRM_NOUVEAU
select FB_CFB_IMAGEBLIT
select FB
select FRAMEBUFFER_CONSOLE if !EXPERT
- select FB_BACKLIGHT if DRM_NOUVEAU_BACKLIGHT
- select ACPI_VIDEO if ACPI && X86 && BACKLIGHT_CLASS_DEVICE && INPUT
select X86_PLATFORM_DEVICES if ACPI && X86
select ACPI_WMI if ACPI && X86
select MXM_WMI if ACPI && X86
select POWER_SUPPLY
- # Similar to i915, we need to select ACPI_VIDEO and it's dependencies
- select BACKLIGHT_LCD_SUPPORT if ACPI && X86
- select BACKLIGHT_CLASS_DEVICE if ACPI && X86
- select INPUT if ACPI && X86
- select THERMAL if ACPI && X86
- select ACPI_VIDEO if ACPI && X86
help
Choose this option for open-source NVIDIA support.
@@ -64,6 +57,7 @@ config NOUVEAU_DEBUG_DEFAULT
config DRM_NOUVEAU_BACKLIGHT
bool "Support for backlight control"
depends on DRM_NOUVEAU
+ depends on BACKLIGHT_CLASS_DEVICE
default y
help
Say Y here if you want to control the backlight of your display
diff --git a/drivers/gpu/drm/shmobile/Kconfig b/drivers/gpu/drm/shmobile/Kconfig
index a50fe0eeaa0d..71c00f3c0fbc 100644
--- a/drivers/gpu/drm/shmobile/Kconfig
+++ b/drivers/gpu/drm/shmobile/Kconfig
@@ -2,7 +2,7 @@ config DRM_SHMOBILE
tristate "DRM Support for SH Mobile"
depends on DRM && ARM
depends on ARCH_SHMOBILE || COMPILE_TEST
- select BACKLIGHT_CLASS_DEVICE
+ depends on BACKLIGHT_CLASS_DEVICE
select DRM_KMS_HELPER
select DRM_KMS_FB_HELPER
select DRM_KMS_CMA_HELPER
diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig
index 7c3ef79fcb37..52e60feaae53 100644
--- a/drivers/gpu/drm/tilcdc/Kconfig
+++ b/drivers/gpu/drm/tilcdc/Kconfig
@@ -1,13 +1,12 @@
config DRM_TILCDC
tristate "DRM Support for TI LCDC Display Controller"
depends on DRM && OF && ARM
+ depends on BACKLIGHT_CLASS_DEVICE
select DRM_KMS_HELPER
select DRM_KMS_FB_HELPER
select DRM_KMS_CMA_HELPER
select DRM_GEM_CMA_HELPER
select VIDEOMODE_HELPERS
- select BACKLIGHT_CLASS_DEVICE
- select BACKLIGHT_LCD_SUPPORT
help
Choose this option if you have an TI SoC with LCDC display
controller, for example AM33xx in beagle-bone, DA8xx, or
diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig
index 3067d56b11a6..50cb2c3b567e 100644
--- a/drivers/macintosh/Kconfig
+++ b/drivers/macintosh/Kconfig
@@ -135,7 +135,7 @@ config PMAC_MEDIABAY
config PMAC_BACKLIGHT
bool "Backlight control for LCD screens"
depends on ADB_PMU && FB = y && (BROKEN || !PPC64)
- select FB_BACKLIGHT
+ depends on BACKLIGHT_CLASS_DEVICE
help
Say Y here to enable Macintosh specific extensions of the generic
backlight code. With this enabled, the brightness keys on older
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 4dcfb7116a04..63e99ce0e3f8 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -17,7 +17,7 @@ if X86_PLATFORM_DEVICES
config ACER_WMI
tristate "Acer WMI Laptop Extras"
- depends on ACPI
+ depends on ACPI && ACPI_VIDEO
select LEDS_CLASS
select NEW_LEDS
depends on BACKLIGHT_CLASS_DEVICE
@@ -26,8 +26,6 @@ config ACER_WMI
depends on RFKILL || RFKILL = n
depends on ACPI_WMI
select INPUT_SPARSEKMAP
- # Acer WMI depends on ACPI_VIDEO when ACPI is enabled
- select ACPI_VIDEO if ACPI
---help---
This is a driver for newer Acer (and Wistron) laptops. It adds
wireless radio and bluetooth control, and on some laptops,
@@ -70,7 +68,7 @@ config ASUS_LAPTOP
depends on ACPI
select LEDS_CLASS
select NEW_LEDS
- select BACKLIGHT_CLASS_DEVICE
+ depends on BACKLIGHT_CLASS_DEVICE
depends on INPUT
depends on RFKILL || RFKILL = n
select INPUT_SPARSEKMAP
@@ -294,7 +292,7 @@ config COMPAL_LAPTOP
config SONY_LAPTOP
tristate "Sony Laptop Extras"
depends on ACPI
- select BACKLIGHT_CLASS_DEVICE
+ depends on BACKLIGHT_CLASS_DEVICE
depends on INPUT
depends on RFKILL
---help---
@@ -329,8 +327,7 @@ config THINKPAD_ACPI
depends on ACPI
depends on INPUT
depends on RFKILL || RFKILL = n
- select BACKLIGHT_LCD_SUPPORT
- select BACKLIGHT_CLASS_DEVICE
+ depends on BACKLIGHT_CLASS_DEVICE
select HWMON
select NVRAM
select NEW_LEDS
@@ -499,7 +496,7 @@ config EEEPC_LAPTOP
depends on INPUT
depends on RFKILL || RFKILL = n
depends on HOTPLUG_PCI
- select BACKLIGHT_CLASS_DEVICE
+ depends on BACKLIGHT_CLASS_DEVICE
select HWMON
select LEDS_CLASS
select NEW_LEDS
@@ -675,8 +672,8 @@ config ACPI_CMPC
tristate "CMPC Laptop Extras"
depends on X86 && ACPI
depends on RFKILL || RFKILL=n
- select INPUT
- select BACKLIGHT_CLASS_DEVICE
+ depends on INPUT
+ depends on BACKLIGHT_CLASS_DEVICE
default n
help
Support for Intel Classmate PC ACPI devices, including some
@@ -805,7 +802,7 @@ config INTEL_OAKTRAIL
config SAMSUNG_Q10
tristate "Samsung Q10 Extras"
depends on ACPI
- select BACKLIGHT_CLASS_DEVICE
+ depends on BACKLIGHT_CLASS_DEVICE
---help---
This driver provides support for backlight control on Samsung Q10
and related laptops, including Dell Latitude X200.
diff --git a/drivers/staging/olpc_dcon/Kconfig b/drivers/staging/olpc_dcon/Kconfig
index d277f048789e..94acb4279704 100644
--- a/drivers/staging/olpc_dcon/Kconfig
+++ b/drivers/staging/olpc_dcon/Kconfig
@@ -3,7 +3,7 @@ config FB_OLPC_DCON
depends on OLPC && FB
depends on I2C
depends on (GPIO_CS5535 || GPIO_CS5535=n)
- select BACKLIGHT_CLASS_DEVICE
+ depends on BACKLIGHT_CLASS_DEVICE
---help---
In order to support very low power operation, the XO laptop uses a
secondary Display CONtroller, or DCON. This secondary controller
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index 76d77206e011..824630b09662 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -150,8 +150,7 @@ config USB_FTDI_ELAN
config USB_APPLEDISPLAY
tristate "Apple Cinema Display support"
- select BACKLIGHT_LCD_SUPPORT
- select BACKLIGHT_CLASS_DEVICE
+ depends on BACKLIGHT_CLASS_DEVICE
help
Say Y here if you want to control the backlight of Apple Cinema
Displays over USB. This driver provides a sysfs interface.
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index ccbe2ae22ac5..8cae7da2c723 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -185,13 +185,6 @@ config FB_MACMODES
depends on FB
default n
-config FB_BACKLIGHT
- bool
- depends on FB
- select BACKLIGHT_LCD_SUPPORT
- select BACKLIGHT_CLASS_DEVICE
- default n
-
config FB_MODE_HELPERS
bool "Enable Video Mode Handling Helpers"
depends on FB
@@ -323,7 +316,7 @@ config FB_CLPS711X
tristate "CLPS711X LCD support"
depends on FB && (ARCH_CLPS711X || COMPILE_TEST)
select FB_CLPS711X_OLD if ARCH_CLPS711X && !ARCH_MULTIPLATFORM
- select BACKLIGHT_LCD_SUPPORT
+ depends on BACKLIGHT_LCD_SUPPORT
select FB_MODE_HELPERS
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
@@ -351,7 +344,7 @@ config FB_SA1100
config FB_IMX
tristate "Freescale i.MX1/21/25/27 LCD support"
depends on FB && ARCH_MXC
- select BACKLIGHT_LCD_SUPPORT
+ depends on BACKLIGHT_LCD_SUPPORT
select LCD_CLASS_DEVICE
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -674,7 +667,7 @@ config FB_STI
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
select STI_CONSOLE
- select VT
+ depends on VT
default y
---help---
STI refers to the HP "Standard Text Interface" which is a set of
@@ -990,7 +983,7 @@ config FB_S1D13XXX
config FB_ATMEL
tristate "AT91/AT32 LCD Controller support"
depends on FB && HAVE_FB_ATMEL
- select FB_BACKLIGHT
+ depends on BACKLIGHT_CLASS_DEVICE
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1019,7 +1012,6 @@ config FB_ATMEL_STN
config FB_NVIDIA
tristate "nVidia Framebuffer Support"
depends on FB && PCI
- select FB_BACKLIGHT if FB_NVIDIA_BACKLIGHT
select FB_MODE_HELPERS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -1060,6 +1052,7 @@ config FB_NVIDIA_DEBUG
config FB_NVIDIA_BACKLIGHT
bool "Support for backlight control"
depends on FB_NVIDIA
+ depends on BACKLIGHT_CLASS_DEVICE
default y
help
Say Y here if you want to control the backlight of your display.
@@ -1067,7 +1060,6 @@ config FB_NVIDIA_BACKLIGHT
config FB_RIVA
tristate "nVidia Riva support"
depends on FB && PCI
- select FB_BACKLIGHT if FB_RIVA_BACKLIGHT
select FB_MODE_HELPERS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -1107,6 +1099,7 @@ config FB_RIVA_DEBUG
config FB_RIVA_BACKLIGHT
bool "Support for backlight control"
depends on FB_RIVA
+ depends on BACKLIGHT_CLASS_DEVICE
default y
help
Say Y here if you want to control the backlight of your display.
@@ -1345,7 +1338,6 @@ config FB_MATROX_MAVEN
config FB_RADEON
tristate "ATI Radeon display support"
depends on FB && PCI
- select FB_BACKLIGHT if FB_RADEON_BACKLIGHT
select FB_MODE_HELPERS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -1370,6 +1362,7 @@ config FB_RADEON_I2C
config FB_RADEON_BACKLIGHT
bool "Support for backlight control"
depends on FB_RADEON
+ depends on BACKLIGHT_CLASS_DEVICE
default y
help
Say Y here if you want to control the backlight of your display.
@@ -1389,7 +1382,6 @@ config FB_ATY128
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
- select FB_BACKLIGHT if FB_ATY128_BACKLIGHT
select FB_MACMODES if PPC_PMAC
help
This driver supports graphics boards with the ATI Rage128 chips.
@@ -1402,6 +1394,7 @@ config FB_ATY128
config FB_ATY128_BACKLIGHT
bool "Support for backlight control"
depends on FB_ATY128
+ depends on BACKLIGHT_CLASS_DEVICE
default y
help
Say Y here if you want to control the backlight of your display.
@@ -1412,7 +1405,6 @@ config FB_ATY
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
- select FB_BACKLIGHT if FB_ATY_BACKLIGHT
select FB_MACMODES if PPC
help
This driver supports graphics boards with the ATI Mach64 chips.
@@ -1452,6 +1444,7 @@ config FB_ATY_GX
config FB_ATY_BACKLIGHT
bool "Support for backlight control"
depends on FB_ATY
+ depends on BACKLIGHT_CLASS_DEVICE
default y
help
Say Y here if you want to control the backlight of your display.
@@ -1997,12 +1990,12 @@ config FB_SH_MOBILE_LCDC
tristate "SuperH Mobile LCDC framebuffer support"
depends on FB && (SUPERH || ARCH_SHMOBILE) && HAVE_CLK
depends on FB_SH_MOBILE_MERAM || !FB_SH_MOBILE_MERAM
+ depends on BACKLIGHT_CLASS_DEVICE
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
select FB_SYS_FOPS
select FB_DEFERRED_IO
- select FB_BACKLIGHT
select SH_MIPI_DSI if SH_LCD_MIPI_DSI
---help---
Frame buffer driver for the on-chip SH-Mobile LCD controller.
@@ -2356,10 +2349,10 @@ config FB_MSM
config FB_MX3
tristate "MX3 Framebuffer support"
depends on FB && MX3_IPU
+ depends on BACKLIGHT_CLASS_DEVICE
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
- select BACKLIGHT_CLASS_DEVICE
default y
help
This is a framebuffer device for the i.MX31 LCD Controller. So
diff --git a/drivers/video/fbdev/core/fbsysfs.c b/drivers/video/fbdev/core/fbsysfs.c
index 53444ac19fe0..8f766f14038e 100644
--- a/drivers/video/fbdev/core/fbsysfs.c
+++ b/drivers/video/fbdev/core/fbsysfs.c
@@ -59,7 +59,7 @@ struct fb_info *framebuffer_alloc(size_t size, struct device *dev)
info->device = dev;
-#ifdef CONFIG_FB_BACKLIGHT
+#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
mutex_init(&info->bl_curve_mutex);
#endif
@@ -428,7 +428,7 @@ static ssize_t show_fbstate(struct device *device,
return snprintf(buf, PAGE_SIZE, "%d\n", fb_info->state);
}
-#ifdef CONFIG_FB_BACKLIGHT
+#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
static ssize_t store_bl_curve(struct device *device,
struct device_attribute *attr,
const char *buf, size_t count)
@@ -517,7 +517,7 @@ static struct device_attribute device_attrs[] = {
__ATTR(stride, S_IRUGO, show_stride, NULL),
__ATTR(rotate, S_IRUGO|S_IWUSR, show_rotate, store_rotate),
__ATTR(state, S_IRUGO|S_IWUSR, show_fbstate, store_fbstate),
-#ifdef CONFIG_FB_BACKLIGHT
+#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
__ATTR(bl_curve, S_IRUGO|S_IWUSR, show_bl_curve, store_bl_curve),
#endif
};
@@ -558,7 +558,7 @@ void fb_cleanup_device(struct fb_info *fb_info)
}
}
-#ifdef CONFIG_FB_BACKLIGHT
+#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
/* This function generates a linear backlight curve
*
* 0: off
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 09bb7a18d287..47e7742fdc9e 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -461,7 +461,7 @@ struct fb_info {
struct list_head modelist; /* mode list */
struct fb_videomode *mode; /* current mode */
-#ifdef CONFIG_FB_BACKLIGHT
+#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
/* assigned backlight device */
/* set before framebuffer registration,
remove after unregister */
diff --git a/include/uapi/linux/fb.h b/include/uapi/linux/fb.h
index fb795c3b3c17..a7a4be063432 100644
--- a/include/uapi/linux/fb.h
+++ b/include/uapi/linux/fb.h
@@ -392,7 +392,7 @@ struct fb_cursor {
struct fb_image image; /* Cursor image */
};
-#ifdef CONFIG_FB_BACKLIGHT
+#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
/* Settings for the generic backlight code */
#define FB_BACKLIGHT_LEVELS 128
#define FB_BACKLIGHT_MAX 0xFF
--
2.1.1
^ permalink raw reply related
* [PATCH 3/5] video: fbdev: uvesafb.c: Cleaning up missing null-terminate by switching from strncpy t
From: Rickard Strandqvist @ 2014-10-18 22:14 UTC (permalink / raw)
To: Michal Januszewski, Jean-Christophe Plagniol-Villard
Cc: Rickard Strandqvist, Andi Kleen, Andrew Morton, Dan Carpenter,
Grant Likely, Tomi Valkeinen, linux-fbdev, linux-kernel
Ensures that the string is null-terminate in connection with the
use of strncpy, by switching from strncpy to strzcpy.
Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
---
drivers/video/fbdev/uvesafb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c
index 509d452..3383b34 100644
--- a/drivers/video/fbdev/uvesafb.c
+++ b/drivers/video/fbdev/uvesafb.c
@@ -1892,7 +1892,7 @@ static ssize_t show_v86d(struct device_driver *dev, char *buf)
static ssize_t store_v86d(struct device_driver *dev, const char *buf,
size_t count)
{
- strncpy(v86d_path, buf, PATH_MAX);
+ strzcpy(v86d_path, buf, sizeof(v86d_path));
return count;
}
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 3/5] video: fbdev: uvesafb.c: Cleaning up missing null-terminate by switching from strncp
From: Geert Uytterhoeven @ 2014-10-20 7:10 UTC (permalink / raw)
To: Rickard Strandqvist
Cc: Michal Januszewski, Jean-Christophe Plagniol-Villard, Andi Kleen,
Andrew Morton, Dan Carpenter, Grant Likely, Tomi Valkeinen,
Linux Fbdev development list, linux-kernel@vger.kernel.org
In-Reply-To: <1413670496-6387-1-git-send-email-rickard_strandqvist@spectrumdigital.se>
On Sun, Oct 19, 2014 at 12:14 AM, Rickard Strandqvist
<rickard_strandqvist@spectrumdigital.se> wrote:
> Ensures that the string is null-terminate in connection with the
> use of strncpy, by switching from strncpy to strzcpy.
>
> Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
> ---
> drivers/video/fbdev/uvesafb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c
> index 509d452..3383b34 100644
> --- a/drivers/video/fbdev/uvesafb.c
> +++ b/drivers/video/fbdev/uvesafb.c
> @@ -1892,7 +1892,7 @@ static ssize_t show_v86d(struct device_driver *dev, char *buf)
> static ssize_t store_v86d(struct device_driver *dev, const char *buf,
> size_t count)
> {
> - strncpy(v86d_path, buf, PATH_MAX);
> + strzcpy(v86d_path, buf, sizeof(v86d_path));
I think strlcpy() should be good enough here?
Or am I missing a reason why the rest of the buffer should be zero-filled?
Nevertheless, I think this (or an alternative) change should be applied to
stable, as call_usermodehelper() might crash by writing to sysfs.
> return count;
> }
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] drivers: video: fbdev: atmel_lcdfb.c: remove unnecessary header
From: Nicolas Ferre @ 2014-10-20 12:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1413548355-499-1-git-send-email-alexandre.belloni@free-electrons.com>
On 17/10/2014 14:19, Alexandre Belloni :
> Remove unnecessary mach/cpu.h header to be able to converge to a multiplatform
> kernel.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Thanks.
Tomi, can you take it?
Bye,
> ---
> drivers/video/fbdev/atmel_lcdfb.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/atmel_lcdfb.c b/drivers/video/fbdev/atmel_lcdfb.c
> index 1d8bdb92939b..ea45a30fd4d2 100644
> --- a/drivers/video/fbdev/atmel_lcdfb.c
> +++ b/drivers/video/fbdev/atmel_lcdfb.c
> @@ -26,7 +26,6 @@
> #include <video/of_display_timing.h>
> #include <video/videomode.h>
>
> -#include <mach/cpu.h>
> #include <asm/gpio.h>
>
> #include <video/atmel_lcdc.h>
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH] drivers: depend on instead of select BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO
From: Darren Hart @ 2014-10-21 20:50 UTC (permalink / raw)
To: Jani Nikula
Cc: linux-kernel, dri-devel, linuxppc-dev, platform-driver-x86,
linux-usb, linux-fbdev, Randy Dunlap, David Airlie, Daniel Vetter,
Greg Kroah-Hartman, Laurent Pinchart, Benjamin Herrenschmidt,
Jens Frederich, Daniel Drake, Jon Nettleton,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen
In-Reply-To: <1413580403-16225-1-git-send-email-jani.nikula@intel.com>
On Sat, Oct 18, 2014 at 12:13:23AM +0300, Jani Nikula wrote:
> Documentation/kbuild/kconfig-language.txt warns to use select with care,
> and in general use select only for non-visible symbols and for symbols
> with no dependencies, because select will force a symbol to a value
> without visiting the dependencies.
>
> Select has become particularly problematic, interdependently, with the
> BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO configs. For example:
>
> scripts/kconfig/conf --randconfig Kconfig
> KCONFIG_SEED=0x48312B00
> 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)
> 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)
>
> With tristates it's possible to end up selecting FOO=y depending on
> BAR=m in the config, which gets discovered at build time, not config
> time, like reported in the thread referenced below.
>
> Do the following to fix the dependencies:
>
> * Depend on instead of select BACKLIGHT_CLASS_DEVICE everywhere. Drop
> select BACKLIGHT_LCD_SUPPORT in such cases, as it's a dependency of
> BACKLIGHT_CLASS_DEVICE.
>
> * Remove config FB_BACKLIGHT altogether, and replace it with a
> dependency on BACKLIGHT_CLASS_DEVICE. All configs selecting
> FB_BACKLIGHT select or depend on FB anyway, so we can simplify.
>
> * Depend on (ACPI && ACPI_VIDEO) || ACPI=n in several places instead of
> selecting ACPI_VIDEO and a number of its dependencies if ACPI is
> enabled. This is tied to backlight, as ACPI_VIDEO depends on
> BACKLIGHT_CLASS_DEVICE.
>
> * Replace a couple of select INPUT/VT with depends as it seemed to be
> necessary.
>
> Reference: http://lkml.kernel.org/r/CA+r1ZhhmT4DrWtf6MbRQo5EqXwx+LxCqh15Vsu_d9WpftLhnxw@mail.gmail.com
> Reported-by: Jim Davis <jim.epost@gmail.com>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Cc: David Airlie <airlied@linux.ie>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Darren Hart <dvhart@infradead.org>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Jens Frederich <jfrederich@gmail.com>
> Cc: Daniel Drake <dsd@laptop.org>
> Cc: Jon Nettleton <jon.nettleton@gmail.com>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
As for the drivers/platform/x86/Kconfig:
Acked-by: Darren Hart <dvhart@linux.intel.com>
Thanks,
--
Darren Hart
Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH] fbcon: Fix option parsing control flow in fb_console_setup
From: Tomi Valkeinen @ 2014-10-22 6:53 UTC (permalink / raw)
To: Maarten ter Huurne
Cc: Jean-Christophe Plagniol-Villard, linux-fbdev, linux-kernel,
Paul Cercueil
In-Reply-To: <1412848110-12734-1-git-send-email-maarten@treewalker.org>
[-- Attachment #1: Type: text/plain, Size: 850 bytes --]
On 09/10/14 12:48, Maarten ter Huurne wrote:
> Since strsep is used to tokenize the options string, after each option
> match the code should use "continue" to get the next token from strsep.
> This patch applies this pattern consistently.
>
> Previously, for "scrollback:" and "map:" the parse code would return
> (unconditionally: strsep ensures *options != ','), causing any
> following option to be ignored, while for "vc:" the parse code would
> go on to parse further options within the same token, which could lead
> to invalid input being accepted.
>
> Signed-off-by: Maarten ter Huurne <maarten@treewalker.org>
> Acked-by: Paul Cercueil <paul@crapouillou.net>
> ---
> drivers/video/console/fbcon.c | 19 +++++++++----------
> 1 file changed, 9 insertions(+), 10 deletions(-)
Thanks, queued for 3.18 fixes.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] video/console: Resolve several shadow warnings
From: Tomi Valkeinen @ 2014-10-22 6:58 UTC (permalink / raw)
To: Jeff Kirsher, plagnioj; +Cc: Mark Rustad, linux-kernel, linux-fbdev
In-Reply-To: <1413287629-11749-1-git-send-email-jeffrey.t.kirsher@intel.com>
[-- Attachment #1: Type: text/plain, Size: 487 bytes --]
On 14/10/14 14:53, Jeff Kirsher wrote:
> From: Mark Rustad <mark.d.rustad@intel.com>
>
> Resolve shadow warnings that appear in W=2 builds by renaming
> the "state" global to "vgastate".
>
> Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> drivers/video/console/vgacon.c | 24 ++++++++++++------------
> 1 file changed, 12 insertions(+), 12 deletions(-)
Thanks, queued for 3.18 fixes.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] drivers: video: fbdev: atmel_lcdfb.c: remove unnecessary header
From: Tomi Valkeinen @ 2014-10-22 7:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5444FE2E.6030509@atmel.com>
[-- Attachment #1: Type: text/plain, Size: 411 bytes --]
On 20/10/14 15:21, Nicolas Ferre wrote:
> On 17/10/2014 14:19, Alexandre Belloni :
>> Remove unnecessary mach/cpu.h header to be able to converge to a multiplatform
>> kernel.
>>
>> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>
> Thanks.
>
> Tomi, can you take it?
Thanks, queued for 3.18 fixes.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] drivers: depend on instead of select BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO
From: Tomi Valkeinen @ 2014-10-22 8:02 UTC (permalink / raw)
To: Jani Nikula, linux-kernel, dri-devel, linuxppc-dev,
platform-driver-x86, linux-usb, linux-fbdev
Cc: Randy Dunlap, David Airlie, Daniel Vetter, Greg Kroah-Hartman,
Darren Hart, Laurent Pinchart, Benjamin Herrenschmidt,
Jens Frederich, Daniel Drake, Jon Nettleton,
Jean-Christophe Plagniol-Villard, Jingoo Han, Bryan Wu, Lee Jones
In-Reply-To: <1413580403-16225-1-git-send-email-jani.nikula@intel.com>
[-- Attachment #1: Type: text/plain, Size: 3818 bytes --]
On 18/10/14 00:13, Jani Nikula wrote:
> Documentation/kbuild/kconfig-language.txt warns to use select with care,
> and in general use select only for non-visible symbols and for symbols
> with no dependencies, because select will force a symbol to a value
> without visiting the dependencies.
>
> Select has become particularly problematic, interdependently, with the
> BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO configs. For example:
>
> scripts/kconfig/conf --randconfig Kconfig
> KCONFIG_SEED=0x48312B00
> 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)
> 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)
>
> With tristates it's possible to end up selecting FOO=y depending on
> BAR=m in the config, which gets discovered at build time, not config
> time, like reported in the thread referenced below.
>
> Do the following to fix the dependencies:
>
> * Depend on instead of select BACKLIGHT_CLASS_DEVICE everywhere. Drop
> select BACKLIGHT_LCD_SUPPORT in such cases, as it's a dependency of
> BACKLIGHT_CLASS_DEVICE.
>
> * Remove config FB_BACKLIGHT altogether, and replace it with a
> dependency on BACKLIGHT_CLASS_DEVICE. All configs selecting
> FB_BACKLIGHT select or depend on FB anyway, so we can simplify.
>
> * Depend on (ACPI && ACPI_VIDEO) || ACPI=n in several places instead of
> selecting ACPI_VIDEO and a number of its dependencies if ACPI is
> enabled. This is tied to backlight, as ACPI_VIDEO depends on
> BACKLIGHT_CLASS_DEVICE.
>
> * Replace a couple of select INPUT/VT with depends as it seemed to be
> necessary.
While doing 'depends on' instead of 'select' is an "easy" fix for this,
I do dislike it quite a bit. It's a major pain to go around the kernel
config, trying to find all the dependencies that a particular driver
wants. If I need fb-foobar, I should just be able to enable it, instead
of first searching and selecting its minor dependencies individually.
So, not a NACK, but a "isn't there an another way to fix this?".
Looking at backlight... BACKLIGHT_LCD_SUPPORT seems to be a "meta"
option, it only enables a Kconfig submenu.
So I think we could just remove the whole BACKLIGHT_LCD_SUPPORT option.
But if we do that, all the items in drivers/video/backlight/Kconfig with
default 'y' or 'm' would get enabled by default, so I think we should
remove the 'default's from that file. That makes sense in any case, as I
don't see why "HP Jornada 700 series LCD Driver" should be "default y".
BACKLIGHT_CLASS_DEVICE doesn't depend on anything except
BACKLIGHT_LCD_SUPPORT, so after removing BACKLIGHT_LCD_SUPPORT it should
be safe to 'select' BACKLIGHT_CLASS_DEVICE.
BACKLIGHT_CLASS_DEVICE could be made a hidden option, and the drivers in
drivers/video/backlight/Kconfig which are under BACKLIGHT_CLASS_DEVICE
could be made to select BACKLIGHT_CLASS_DEVICE instead.
That doesn't exactly fix anything, but I think it makes sense as
BACKLIGHT_CLASS_DEVICE is something that's selected from all around the
kernel, so it should be a selectable "library" instead of a Kconfig menu
option.
I didn't look at the ACPI_VIDEO side, so no idea how messy that is.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH 1/5] OMAPDSS: HDMI: fix PLL GO bit handling
From: Tomi Valkeinen @ 2014-10-22 8:39 UTC (permalink / raw)
To: linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
The PLL settings are committed by setting GO bit, which is then cleared
by the HW when the settings have been taken into use.
The current PLL code handles this wrong: instead of waiting for the bit
to be cleared, it waits for the bit to be set. Usually, the bit is
always set, as the CPU has just set it before. However, if the CPU takes
enough time between setting the GO bit and checking it, the HW may
already have cleared the bit and this leads to timeout error.
Fix the wait to check the bit properly.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/fbdev/omap2/dss/hdmi_pll.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi_pll.c b/drivers/video/fbdev/omap2/dss/hdmi_pll.c
index 54df12a8d744..d4ec815ba42e 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi_pll.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi_pll.c
@@ -144,8 +144,8 @@ static int hdmi_pll_config(struct hdmi_pll_data *pll)
/* wait for bit change */
if (hdmi_wait_for_bit_change(pll->base, PLLCTRL_PLL_GO,
- 0, 0, 1) != 1) {
- DSSERR("PLL GO bit not set\n");
+ 0, 0, 0) != 0) {
+ DSSERR("PLL GO bit not clearing\n");
return -ETIMEDOUT;
}
--
2.1.1
^ permalink raw reply related
* [PATCH 2/5] OMAPDSS: HDMI: fix regsd write
From: Tomi Valkeinen @ 2014-10-22 8:39 UTC (permalink / raw)
To: linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
In-Reply-To: <1413967174-28009-1-git-send-email-tomi.valkeinen@ti.com>
HDMI PLL's REGSD field is only set by the driver if the PLL's output
clock is over 1GHz. This is clearly an error, as REGSD should be set
always.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/fbdev/omap2/dss/hdmi_pll.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi_pll.c b/drivers/video/fbdev/omap2/dss/hdmi_pll.c
index d4ec815ba42e..6d92bb32fe51 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi_pll.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi_pll.c
@@ -124,16 +124,15 @@ static int hdmi_pll_config(struct hdmi_pll_data *pll)
r = FLD_MOD(r, 0x0, 14, 14); /* PHY_CLKINEN de-assert during locking */
r = FLD_MOD(r, fmt->refsel, 22, 21); /* REFSEL */
- if (fmt->dcofreq) {
- /* divider programming for frequency beyond 1000Mhz */
- REG_FLD_MOD(pll->base, PLLCTRL_CFG3, fmt->regsd, 17, 10);
+ if (fmt->dcofreq)
r = FLD_MOD(r, 0x4, 3, 1); /* 1000MHz and 2000MHz */
- } else {
+ else
r = FLD_MOD(r, 0x2, 3, 1); /* 500MHz and 1000MHz */
- }
hdmi_write_reg(pll->base, PLLCTRL_CFG2, r);
+ REG_FLD_MOD(pll->base, PLLCTRL_CFG3, fmt->regsd, 17, 10);
+
r = hdmi_read_reg(pll->base, PLLCTRL_CFG4);
r = FLD_MOD(r, fmt->regm2, 24, 18);
r = FLD_MOD(r, fmt->regmf, 17, 0);
--
2.1.1
^ permalink raw reply related
* [PATCH 3/5] OMAPDSS: DISPC: fix mflag offset
From: Tomi Valkeinen @ 2014-10-22 8:39 UTC (permalink / raw)
To: linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
In-Reply-To: <1413967174-28009-1-git-send-email-tomi.valkeinen@ti.com>
The register offset for DISPC_OVL_MFLAG_THRESHOLD is wrong, fix it.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/fbdev/omap2/dss/dispc.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dispc.h b/drivers/video/fbdev/omap2/dss/dispc.h
index 78edb449c763..3043d6e0a5f9 100644
--- a/drivers/video/fbdev/omap2/dss/dispc.h
+++ b/drivers/video/fbdev/omap2/dss/dispc.h
@@ -101,8 +101,7 @@
DISPC_FIR_COEF_V2_OFFSET(n, i))
#define DISPC_OVL_PRELOAD(n) (DISPC_OVL_BASE(n) + \
DISPC_PRELOAD_OFFSET(n))
-#define DISPC_OVL_MFLAG_THRESHOLD(n) (DISPC_OVL_BASE(n) + \
- DISPC_MFLAG_THRESHOLD_OFFSET(n))
+#define DISPC_OVL_MFLAG_THRESHOLD(n) DISPC_MFLAG_THRESHOLD_OFFSET(n)
/* DISPC up/downsampling FIR filter coefficient structure */
struct dispc_coef {
--
2.1.1
^ permalink raw reply related
* [PATCH 4/5] OMAPDSS: fix dispc register dump for preload & mflag
From: Tomi Valkeinen @ 2014-10-22 8:39 UTC (permalink / raw)
To: linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
In-Reply-To: <1413967174-28009-1-git-send-email-tomi.valkeinen@ti.com>
Preload register is dumped twice for video overlays and mflag register
is not dumped for GFX.
Fix the register dump.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/fbdev/omap2/dss/dispc.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dispc.c b/drivers/video/fbdev/omap2/dss/dispc.c
index e67976bd0627..0e9a74bb9fc2 100644
--- a/drivers/video/fbdev/omap2/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/dss/dispc.c
@@ -3290,8 +3290,11 @@ static void dispc_dump_regs(struct seq_file *s)
DUMPREG(i, DISPC_OVL_FIFO_SIZE_STATUS);
DUMPREG(i, DISPC_OVL_ROW_INC);
DUMPREG(i, DISPC_OVL_PIXEL_INC);
+
if (dss_has_feature(FEAT_PRELOAD))
DUMPREG(i, DISPC_OVL_PRELOAD);
+ if (dss_has_feature(FEAT_MFLAG))
+ DUMPREG(i, DISPC_OVL_MFLAG_THRESHOLD);
if (i = OMAP_DSS_GFX) {
DUMPREG(i, DISPC_OVL_WINDOW_SKIP);
@@ -3312,10 +3315,6 @@ static void dispc_dump_regs(struct seq_file *s)
}
if (dss_has_feature(FEAT_ATTR2))
DUMPREG(i, DISPC_OVL_ATTRIBUTES2);
- if (dss_has_feature(FEAT_PRELOAD))
- DUMPREG(i, DISPC_OVL_PRELOAD);
- if (dss_has_feature(FEAT_MFLAG))
- DUMPREG(i, DISPC_OVL_MFLAG_THRESHOLD);
}
#undef DISPC_REG
--
2.1.1
^ permalink raw reply related
* [PATCH 5/5] OMAPDSS: DSI: Fix PLL_SELFEQDCO field width
From: Tomi Valkeinen @ 2014-10-22 8:39 UTC (permalink / raw)
To: linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
In-Reply-To: <1413967174-28009-1-git-send-email-tomi.valkeinen@ti.com>
PLL_SELFREQDCO bitfield is from bit 3 to 1, but the driver writes bits
from 4 to 1. The bit 4 is 'reserved', so this probably should not cause
any issues, but it's better to fix it.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/fbdev/omap2/dss/dsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/dss/dsi.c b/drivers/video/fbdev/omap2/dss/dsi.c
index 947bd7b93375..0793bc67a275 100644
--- a/drivers/video/fbdev/omap2/dss/dsi.c
+++ b/drivers/video/fbdev/omap2/dss/dsi.c
@@ -1603,7 +1603,7 @@ int dsi_pll_set_clock_div(struct platform_device *dsidev,
} else if (dss_has_feature(FEAT_DSI_PLL_SELFREQDCO)) {
f = cinfo->clkin4ddr < 1000000000 ? 0x2 : 0x4;
- l = FLD_MOD(l, f, 4, 1); /* PLL_SELFREQDCO */
+ l = FLD_MOD(l, f, 3, 1); /* PLL_SELFREQDCO */
}
l = FLD_MOD(l, 1, 13, 13); /* DSI_PLL_REFEN */
--
2.1.1
^ permalink raw reply related
* [PATCH v4 0/5] simplefb: add clock handling code
From: Hans de Goede @ 2014-10-22 16:45 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tomi,
Here is v4 of the patch-set to add clocks support to simplefb.
Changes in v2:
-Added "simplefb: Add simplefb MAINTAINERS entry" patch
Changes in v3:
-Improved description of simplefb binding
Changes in v4:
-Change clocks in simplefb from a linked-list to a (simpler) dynamically
allocated array
v2 got some objections from some people because clocks are hardware description
and as such do not belong in a virtual device node as simplefb is. As explained
in the following thread the use of clocks in simplefb has nothing to do with
clock topology (so hardware description), but is about which clocks of a
number of possible clocks where actually chosen by the firmware to bring
of the fb, as such this clearly is state description.
AFAIK at the end of the thread no one was disagreeing with this anymore
(I did not get any replies to my last mails explaining this).
Some of us also got together at the Plumbers conference in Dusseldorf to
discuss this, present were: David Herrmann, Maxime Ripard, Geert Uytterhoeven
and Hans de Goede (me), conclusions:
-We will add a clocks property to the simplefb devicetree bindings, so
that u-boot setup framebuffers passed to the kernel (for early console
support) can properly list the clocks used, and simplefb can claim them to
avoid them getting turned off, thereby breaking the early console
-simplefb/simpledrm -> native-kms driver handoff will keep using the
linear framebuffer address to identify which simplefb platform device to
destroy during handoff, so that if their are multiple kms devices
involved, the handover happens at the right moment and we don't loose
console output anywhere (and we should be able to do a flickerfree
handover)
Since we seem to have broad agreement on how to move forward with this, I
would like to ask you to please merge this patch-set for 3.19.
I know 3.19 is still somewhat ar away, but I would like to submit the u-boot
side of this to upstream ASAP, so can you please let me know if you plan to
take this patch-set for 3.19 soon ?
Regards,
Hans
^ permalink raw reply
* [PATCH v4 1/5] simplefb: Add simplefb MAINTAINERS entry
From: Hans de Goede @ 2014-10-22 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1413996311-4287-1-git-send-email-hdegoede@redhat.com>
During the discussion about adding clock handling code to simplefb, it became
clear that simplefb currently does not have an active maintainer.
I've discussed this with Stephen Warren <swarren@wwwdotorg.org>, the original
author of simplefb, and with his permisson I'm picking up maintainership of
simplefb.
Cc: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
---
MAINTAINERS | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 73d1aef..6e92e73 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8416,6 +8416,14 @@ F: drivers/media/usb/siano/
F: drivers/media/usb/siano/
F: drivers/media/mmc/siano/
+SIMPLEFB FB DRIVER
+M: Hans de Goede <hdegoede@redhat.com>
+L: linux-fbdev@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/video/simple-framebuffer.txt
+F: drivers/video/fbdev/simplefb.c
+F: include/linux/platform_data/simplefb.h
+
SH_VEU V4L2 MEM2MEM DRIVER
L: linux-media@vger.kernel.org
S: Orphan
--
2.1.0
^ permalink raw reply related
* [PATCH v4 2/5] dt-bindings: Add a clocks property to the simple-framebuffer binding
From: Hans de Goede @ 2014-10-22 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1413996311-4287-1-git-send-email-hdegoede@redhat.com>
A simple-framebuffer node represents a framebuffer setup by the firmware /
bootloader. Such a framebuffer may have a number of clocks in use, add a
property to communicate this to the OS.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mike Turquette <mturquette@linaro.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Maxime Ripard <maxime.ripard@free-electrons.com>
--
Changes in v2:
-Added Reviewed-by: Mike Turquette <mturquette@linaro.org>
Changes in v3:
-Updated description to make clear simplefb deals with more then just memory
---
Documentation/devicetree/bindings/video/simple-framebuffer.txt | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
index 70c26f3..172ad5f 100644
--- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
+++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
@@ -1,8 +1,8 @@
Simple Framebuffer
-A simple frame-buffer describes a raw memory region that may be rendered to,
-with the assumption that the display hardware has already been set up to scan
-out from that buffer.
+A simple frame-buffer describes a frame-buffer setup by firmware or
+the bootloader, with the assumption that the display hardware has already
+been set up to scan out from the memory pointed to by the reg property.
Required properties:
- compatible: "simple-framebuffer"
@@ -14,6 +14,9 @@ Required properties:
- r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b).
- a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
+Optional properties:
+- clocks : List of clocks used by the framebuffer
+
Example:
framebuffer {
--
2.1.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox