* [PATCH resend 0/4] Make video.use_native_backlight=1 work properly with nouveau
From: Hans de Goede @ 2014-05-21 13:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Aaron Lu, Jingoo Han, Bryan Wu, Lee Jones,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Ben Skeggs,
David Airlie
Cc: Zhang Rui, Len Brown, linux-acpi, linux-fbdev, dri-devel
Hi All,
I know it has not been that long since the last send of this series, but
it has been very quiet, and I would like to see some discussion on it
(or it being applied at once, that is fine too :)
This patch-set adds backlight device (un)registration notification and
makes acpi-video listen to it, so that video.use_native_backlight=1 still
works if a raw interface gets loaded *after* acpi-video has been initialized.
It also changes nouveau to always register its raw interface, as all the other
kms drivers do, acpi_video_backlight_support() is only intended to avoid the
loading of multiple (possibly conflicting) firmware drivers, not to avoid
loading raw drivers.
In the mean time I've gotten feedback from a user with a laptop which needs
video.use_native_backlight=1 and uses nouveau, and he has confirmed that this
patch-set works as advertised, see:
https://bugzilla.redhat.com/show_bug.cgi?id\x1093171
Regards,
Hans
^ permalink raw reply
* [PATCH resend 1/4] nouveau: Don't check acpi_video_backlight_support() before registering backlight
From: Hans de Goede @ 2014-05-21 13:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Aaron Lu, Jingoo Han, Bryan Wu, Lee Jones,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Ben Skeggs,
David Airlie
Cc: Zhang Rui, Len Brown, linux-acpi, linux-fbdev, dri-devel,
Hans de Goede
In-Reply-To: <1400679596-19663-1-git-send-email-hdegoede@redhat.com>
acpi_video_backlight_support() is supposed to be called by other (vendor
specific) firmware backlight controls, not by native / raw backlight controls
like nv_backlight.
Userspace will normally prefer firmware interfaces over raw interfaces, so
if acpi_video backlight support is present it will use that even if
nv_backlight is registered as well.
Except when video.use_native_backlight is present on the kernel cmdline
(or enabled through a dmi based quirk). As the name indicates the goal here
is to make only the raw interface available to userspace so that it will use
that (it only does this when it sees a win8 compliant bios).
This is done by:
1) Not registering any acpi_video# backlight devices; and
2) Making acpi_video_backlight_support() return true so that other firmware
drivers, ie acer_wmi, thinkpad_acpi, dell_laptop, etc. Don't register their
own vender specific interfaces.
Currently nouveau breaks this setup, as when acpi_video_backlight_support()
returns true, it does not register itself, resulting in no backlight control
at all.
This is esp. going to be a problem with 3.16 which will default to
video.use_native_backlight=1, and thus nouveau based laptops with a win8 bios
will get no backlight control at all.
This also likely explains why the previous attempt to make
video.use_native_backlight=1 the default was not a success, as without this
patch having a default of video.use_native_backlight=1 will cause regressions.
Note this effectively reverts commit 5bead799
Also see: https://bugzilla.redhat.com/show_bug.cgi?id\x1093171
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index 630f6e8..2c1e4aa 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -31,7 +31,6 @@
*/
#include <linux/backlight.h>
-#include <linux/acpi.h>
#include "nouveau_drm.h"
#include "nouveau_reg.h"
@@ -222,14 +221,6 @@ nouveau_backlight_init(struct drm_device *dev)
struct nouveau_device *device = nv_device(drm->device);
struct drm_connector *connector;
-#ifdef CONFIG_ACPI
- if (acpi_video_backlight_support()) {
- NV_INFO(drm, "ACPI backlight interface available, "
- "not registering our own\n");
- return 0;
- }
-#endif
-
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
if (connector->connector_type != DRM_MODE_CONNECTOR_LVDS &&
connector->connector_type != DRM_MODE_CONNECTOR_eDP)
--
1.9.0
^ permalink raw reply related
* [PATCH resend 2/4] backlight: Add backlight device (un)registration notification
From: Hans de Goede @ 2014-05-21 13:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Aaron Lu, Jingoo Han, Bryan Wu, Lee Jones,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Ben Skeggs,
David Airlie
Cc: Zhang Rui, Len Brown, linux-acpi, linux-fbdev, dri-devel,
Hans de Goede
In-Reply-To: <1400679596-19663-1-git-send-email-hdegoede@redhat.com>
Some firmware drivers, ie acpi-video want to get themselves out of the
way (in some cases) when their also is a raw backlight device available.
Due to module loading ordering being unknown, acpi-video cannot be certain
that the backlight_device_registered(BACKLIGHT_RAW) it does for this is
the final verdict wrt there being a BACKLIGHT_RAW device.
By adding notification acpi-video can listen for backlight devices showing
up after it has loaded, and unregister its backlight device if desired.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/video/backlight/backlight.c | 40 +++++++++++++++++++++++++++++++++++++
include/linux/backlight.h | 7 +++++++
2 files changed, 47 insertions(+)
diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
index bd2172c..4280890 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -23,6 +23,7 @@
static struct list_head backlight_dev_list;
static struct mutex backlight_dev_list_mutex;
+static struct blocking_notifier_head backlight_notifier;
static const char *const backlight_types[] = {
[BACKLIGHT_RAW] = "raw",
@@ -370,6 +371,9 @@ struct backlight_device *backlight_device_register(const char *name,
list_add(&new_bd->entry, &backlight_dev_list);
mutex_unlock(&backlight_dev_list_mutex);
+ blocking_notifier_call_chain(&backlight_notifier,
+ BACKLIGHT_REGISTERED, new_bd);
+
return new_bd;
}
EXPORT_SYMBOL(backlight_device_register);
@@ -413,6 +417,10 @@ void backlight_device_unregister(struct backlight_device *bd)
pmac_backlight = NULL;
mutex_unlock(&pmac_backlight_mutex);
#endif
+
+ blocking_notifier_call_chain(&backlight_notifier,
+ BACKLIGHT_UNREGISTERED, bd);
+
mutex_lock(&bd->ops_lock);
bd->ops = NULL;
mutex_unlock(&bd->ops_lock);
@@ -438,6 +446,36 @@ static int devm_backlight_device_match(struct device *dev, void *res,
}
/**
+ * backlight_register_notifier - get notified of backlight (un)registration
+ * @nb: notifier block with the notifier to call on backlight (un)registration
+ *
+ * @return 0 on success, otherwise a negative error code
+ *
+ * Register a notifier to get notified when backlight devices get registered
+ * or unregistered.
+ */
+int backlight_register_notifier(struct notifier_block *nb)
+{
+ return blocking_notifier_chain_register(&backlight_notifier, nb);
+}
+EXPORT_SYMBOL(backlight_register_notifier);
+
+/**
+ * backlight_unregister_notifier - unregister a backlight notifier
+ * @nb: notifier block to unregister
+ *
+ * @return 0 on success, otherwise a negative error code
+ *
+ * Register a notifier to get notified when backlight devices get registered
+ * or unregistered.
+ */
+int backlight_unregister_notifier(struct notifier_block *nb)
+{
+ return blocking_notifier_chain_unregister(&backlight_notifier, nb);
+}
+EXPORT_SYMBOL(backlight_unregister_notifier);
+
+/**
* devm_backlight_device_register - resource managed backlight_device_register()
* @dev: the device to register
* @name: the name of the device
@@ -544,6 +582,8 @@ static int __init backlight_class_init(void)
backlight_class->pm = &backlight_class_dev_pm_ops;
INIT_LIST_HEAD(&backlight_dev_list);
mutex_init(&backlight_dev_list_mutex);
+ BLOCKING_INIT_NOTIFIER_HEAD(&backlight_notifier);
+
return 0;
}
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 7264742..adb14a8 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -40,6 +40,11 @@ enum backlight_type {
BACKLIGHT_TYPE_MAX,
};
+enum backlight_notification {
+ BACKLIGHT_REGISTERED,
+ BACKLIGHT_UNREGISTERED,
+};
+
struct backlight_device;
struct fb_info;
@@ -133,6 +138,8 @@ extern void devm_backlight_device_unregister(struct device *dev,
extern void backlight_force_update(struct backlight_device *bd,
enum backlight_update_reason reason);
extern bool backlight_device_registered(enum backlight_type type);
+extern int backlight_register_notifier(struct notifier_block *nb);
+extern int backlight_unregister_notifier(struct notifier_block *nb);
#define to_backlight_device(obj) container_of(obj, struct backlight_device, dev)
--
1.9.0
^ permalink raw reply related
* [PATCH resend 3/4] acpi-video: Unregister the backlight device if a raw one shows up later
From: Hans de Goede @ 2014-05-21 13:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Aaron Lu, Jingoo Han, Bryan Wu, Lee Jones,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Ben Skeggs,
David Airlie
Cc: Zhang Rui, Len Brown, linux-acpi, linux-fbdev, dri-devel,
Hans de Goede
In-Reply-To: <1400679596-19663-1-git-send-email-hdegoede@redhat.com>
When video.use_native_backlight=1 and non intel gfx are in use, the raw
backlight device of the gfx driver will show up after acpi-video has done its
acpi_video_verify_backlight_support() check.
This causes video.use_native_backlight=1 to not have the desired result.
This patch fixes this by adding a backlight notifier and when a raw
backlight is registered or unregistered re-doing the
acpi_video_verify_backlight_support() check.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/acpi/video.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 57 insertions(+)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index ba6e4d7..47b7e21 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -151,6 +151,7 @@ struct acpi_video_enumerated_device {
struct acpi_video_bus {
struct acpi_device *device;
bool backlight_registered;
+ bool backlight_notifier_registered;
u8 dos_setting;
struct acpi_video_enumerated_device *attached_array;
u8 attached_count;
@@ -162,6 +163,7 @@ struct acpi_video_bus {
struct input_dev *input;
char phys[32]; /* for input device */
struct notifier_block pm_nb;
+ struct notifier_block backlight_nb;
};
struct acpi_video_device_flags {
@@ -1828,6 +1830,9 @@ static int acpi_video_bus_register_backlight(struct acpi_video_bus *video)
{
struct acpi_video_device *dev;
+ if (video->backlight_registered)
+ return 0;
+
if (!acpi_video_verify_backlight_support())
return 0;
@@ -1972,6 +1977,56 @@ static void acpi_video_bus_remove_notify_handler(struct acpi_video_bus *video)
video->input = NULL;
}
+static int acpi_video_backlight_notify(struct notifier_block *nb,
+ unsigned long val, void *bd)
+{
+ struct backlight_device *backlight = bd;
+ struct acpi_video_bus *video;
+
+ /* acpi_video_verify_backlight_support only cares about raw devices */
+ if (backlight->props.type != BACKLIGHT_RAW)
+ return NOTIFY_DONE;
+
+ video = container_of(nb, struct acpi_video_bus, backlight_nb);
+
+ switch (val) {
+ case BACKLIGHT_REGISTERED:
+ if (!acpi_video_verify_backlight_support())
+ acpi_video_bus_unregister_backlight(video);
+ break;
+ case BACKLIGHT_UNREGISTERED:
+ acpi_video_bus_register_backlight(video);
+ break;
+ }
+
+ return NOTIFY_OK;
+}
+
+static int acpi_video_bus_add_backlight_notify_handler(
+ struct acpi_video_bus *video)
+{
+ int error;
+
+ video->backlight_nb.notifier_call = acpi_video_backlight_notify;
+ video->backlight_nb.priority = 0;
+ error = backlight_register_notifier(&video->backlight_nb);
+ if (error = 0)
+ video->backlight_notifier_registered = true;
+
+ return error;
+}
+
+static int acpi_video_bus_remove_backlight_notify_handler(
+ struct acpi_video_bus *video)
+{
+ if (!video->backlight_notifier_registered)
+ return 0;
+
+ video->backlight_notifier_registered = false;
+
+ return backlight_unregister_notifier(&video->backlight_nb);
+}
+
static int acpi_video_bus_put_devices(struct acpi_video_bus *video)
{
struct acpi_video_device *dev, *next;
@@ -2053,6 +2108,7 @@ static int acpi_video_bus_add(struct acpi_device *device)
acpi_video_bus_register_backlight(video);
acpi_video_bus_add_notify_handler(video);
+ acpi_video_bus_add_backlight_notify_handler(video);
return 0;
@@ -2076,6 +2132,7 @@ static int acpi_video_bus_remove(struct acpi_device *device)
video = acpi_driver_data(device);
+ acpi_video_bus_remove_backlight_notify_handler(video);
acpi_video_bus_remove_notify_handler(video);
acpi_video_bus_unregister_backlight(video);
acpi_video_bus_put_devices(video);
--
1.9.0
^ permalink raw reply related
* [PATCH resend 4/4] acpi-video: Add use native backlight quirk for the ThinkPad W530
From: Hans de Goede @ 2014-05-21 13:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Aaron Lu, Jingoo Han, Bryan Wu, Lee Jones,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Ben Skeggs,
David Airlie
Cc: Zhang Rui, Len Brown, linux-acpi, linux-fbdev, dri-devel,
Hans de Goede, stable
In-Reply-To: <1400679596-19663-1-git-send-email-hdegoede@redhat.com>
Like all of the other *30 ThinkPad models, the W530 has a broken acpi-video
backlight control. Note in order for this to actually fix things on the
ThinkPad W530 the commit titled:
"nouveau: Don't check acpi_video_backlight_support() before registering backlight"
is also needed.
https://bugzilla.redhat.com/show_bug.cgi?id\x1093171
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/acpi/video.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 47b7e21..8309100 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -515,6 +515,14 @@ static struct dmi_system_id video_dmi_table[] __initdata = {
},
},
{
+ .callback = video_set_use_native_backlight,
+ .ident = "ThinkPad W530",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad W530"),
+ },
+ },
+ {
.callback = video_set_use_native_backlight,
.ident = "ThinkPad X1 Carbon",
.matches = {
--
1.9.0
^ permalink raw reply related
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Sebastian Reichel @ 2014-05-21 14:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <537CA4B4.2040001@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]
Hi,
On Wed, May 21, 2014 at 04:05:56PM +0300, Tomi Valkeinen wrote:
> I'll try and see how the other options work, which are:
>
> - Bailing out from module_init in each display driver. The reason I
> don't like this (although I haven't tried it) is that all the display
> drivers need the modification, and because I need to catch the
> module_init, I cannot use the helpers like module_platform_driver(), so
> it adds multiple lines to every driver.
You could create your own omapdss_driver() define for that.
This can be replaced more simply once no longer needed and
creates less bloat.
I see one more disadvantage for this approach:
assumed situation (some future 3.16+x kernel):
* The kernel has an common display framework (CDF)
* The kernel has an panel driver using CDF
* There also exists omapdss driver for the same panel
* omapdss does not (yet) adopt CDF
* CDF and omapdss are enabled in .config
* Kernel is booted from an OMAP system
This would result in both drivers being loaded using the same
DT compatible string. The same scenario works using the rewriting
method, since the common display framework would only see the
rewritten compatible string.
Of course this scenario only happens when omapdss is not adopted
to the common display framework from the start on.
> - Traveling the video graph, starting from omapdss. This one is possibly
> better performance-wise than my original version, as we only need to
> search for the omapdss node and can then follow the links. But the code
> will be more complex.
I think the main advantage is the missing lookup table/whitelist,
which adds redundancy. Not having it has some advantages:
* new drivers don't need to touch any existing files (making
rebasing etc. easier)
* table can get out of sync (though that shouldn't happen anyway,
since the binding is supposed to be stable)
-- Sebastian
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
From: Tony Lindgren @ 2014-05-21 14:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <537C9FC6.8020104@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140521 05:45]:
> On 14/05/14 00:32, Tony Lindgren wrote:
>
> > +&dss {
> > + status = "ok";
> > + vdds_dsi-supply = <&vpll2>;
> > + port {
> > + dpi_out: endpoint {
> > + remote-endpoint = <&lcd_in>;
> > + data-lines = <18>;
> > + };
> > + };
> > +};
>
> I just noticed the vdds_dsi-supply there. While the driver currently
> uses that if available, I think it should be removed, and done the same
> way Florian did with his overo patches:
>
> /* Needed to power the DPI pins */
> &vpll2 {
> regulator-always-on;
> };
>
> That supply is not DSS's supply, but it's used to power up the pins. If
> the pins were used as GPIOs, that power should be enabled.
OK thanks for catching it.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH resend 1/4] nouveau: Don't check acpi_video_backlight_support() before registering backli
From: Rafael J. Wysocki @ 2014-05-21 23:30 UTC (permalink / raw)
To: Hans de Goede
Cc: Aaron Lu, Jingoo Han, Bryan Wu, Lee Jones,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Ben Skeggs,
David Airlie, Zhang Rui, Len Brown, linux-acpi, linux-fbdev,
dri-devel
In-Reply-To: <1400679596-19663-2-git-send-email-hdegoede@redhat.com>
On Wednesday, May 21, 2014 03:39:53 PM Hans de Goede wrote:
> acpi_video_backlight_support() is supposed to be called by other (vendor
> specific) firmware backlight controls, not by native / raw backlight controls
> like nv_backlight.
>
> Userspace will normally prefer firmware interfaces over raw interfaces, so
> if acpi_video backlight support is present it will use that even if
> nv_backlight is registered as well.
>
> Except when video.use_native_backlight is present on the kernel cmdline
> (or enabled through a dmi based quirk). As the name indicates the goal here
> is to make only the raw interface available to userspace so that it will use
> that (it only does this when it sees a win8 compliant bios).
>
> This is done by:
> 1) Not registering any acpi_video# backlight devices; and
> 2) Making acpi_video_backlight_support() return true so that other firmware
> drivers, ie acer_wmi, thinkpad_acpi, dell_laptop, etc. Don't register their
> own vender specific interfaces.
>
> Currently nouveau breaks this setup, as when acpi_video_backlight_support()
> returns true, it does not register itself, resulting in no backlight control
> at all.
>
> This is esp. going to be a problem with 3.16 which will default to
> video.use_native_backlight=1, and thus nouveau based laptops with a win8 bios
> will get no backlight control at all.
>
> This also likely explains why the previous attempt to make
> video.use_native_backlight=1 the default was not a success, as without this
> patch having a default of video.use_native_backlight=1 will cause regressions.
>
> Note this effectively reverts commit 5bead799
>
> Also see: https://bugzilla.redhat.com/show_bug.cgi?id\x1093171
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
It would be good to have an ACK from the nouveau people for this one.
> ---
> drivers/gpu/drm/nouveau/nouveau_backlight.c | 9 ---------
> 1 file changed, 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> index 630f6e8..2c1e4aa 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> @@ -31,7 +31,6 @@
> */
>
> #include <linux/backlight.h>
> -#include <linux/acpi.h>
>
> #include "nouveau_drm.h"
> #include "nouveau_reg.h"
> @@ -222,14 +221,6 @@ nouveau_backlight_init(struct drm_device *dev)
> struct nouveau_device *device = nv_device(drm->device);
> struct drm_connector *connector;
>
> -#ifdef CONFIG_ACPI
> - if (acpi_video_backlight_support()) {
> - NV_INFO(drm, "ACPI backlight interface available, "
> - "not registering our own\n");
> - return 0;
> - }
> -#endif
> -
> list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
> if (connector->connector_type != DRM_MODE_CONNECTOR_LVDS &&
> connector->connector_type != DRM_MODE_CONNECTOR_eDP)
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH resend 2/4] backlight: Add backlight device (un)registration notification
From: Rafael J. Wysocki @ 2014-05-21 23:31 UTC (permalink / raw)
To: Hans de Goede
Cc: Aaron Lu, Jingoo Han, Bryan Wu, Lee Jones,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Ben Skeggs,
David Airlie, Zhang Rui, Len Brown, linux-acpi, linux-fbdev,
dri-devel
In-Reply-To: <1400679596-19663-3-git-send-email-hdegoede@redhat.com>
On Wednesday, May 21, 2014 03:39:54 PM Hans de Goede wrote:
> Some firmware drivers, ie acpi-video want to get themselves out of the
> way (in some cases) when their also is a raw backlight device available.
>
> Due to module loading ordering being unknown, acpi-video cannot be certain
> that the backlight_device_registered(BACKLIGHT_RAW) it does for this is
> the final verdict wrt there being a BACKLIGHT_RAW device.
>
> By adding notification acpi-video can listen for backlight devices showing
> up after it has loaded, and unregister its backlight device if desired.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Backlight maintainer's ACK is requisite here.
> ---
> drivers/video/backlight/backlight.c | 40 +++++++++++++++++++++++++++++++++++++
> include/linux/backlight.h | 7 +++++++
> 2 files changed, 47 insertions(+)
>
> diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
> index bd2172c..4280890 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -23,6 +23,7 @@
>
> static struct list_head backlight_dev_list;
> static struct mutex backlight_dev_list_mutex;
> +static struct blocking_notifier_head backlight_notifier;
>
> static const char *const backlight_types[] = {
> [BACKLIGHT_RAW] = "raw",
> @@ -370,6 +371,9 @@ struct backlight_device *backlight_device_register(const char *name,
> list_add(&new_bd->entry, &backlight_dev_list);
> mutex_unlock(&backlight_dev_list_mutex);
>
> + blocking_notifier_call_chain(&backlight_notifier,
> + BACKLIGHT_REGISTERED, new_bd);
> +
> return new_bd;
> }
> EXPORT_SYMBOL(backlight_device_register);
> @@ -413,6 +417,10 @@ void backlight_device_unregister(struct backlight_device *bd)
> pmac_backlight = NULL;
> mutex_unlock(&pmac_backlight_mutex);
> #endif
> +
> + blocking_notifier_call_chain(&backlight_notifier,
> + BACKLIGHT_UNREGISTERED, bd);
> +
> mutex_lock(&bd->ops_lock);
> bd->ops = NULL;
> mutex_unlock(&bd->ops_lock);
> @@ -438,6 +446,36 @@ static int devm_backlight_device_match(struct device *dev, void *res,
> }
>
> /**
> + * backlight_register_notifier - get notified of backlight (un)registration
> + * @nb: notifier block with the notifier to call on backlight (un)registration
> + *
> + * @return 0 on success, otherwise a negative error code
> + *
> + * Register a notifier to get notified when backlight devices get registered
> + * or unregistered.
> + */
> +int backlight_register_notifier(struct notifier_block *nb)
> +{
> + return blocking_notifier_chain_register(&backlight_notifier, nb);
> +}
> +EXPORT_SYMBOL(backlight_register_notifier);
> +
> +/**
> + * backlight_unregister_notifier - unregister a backlight notifier
> + * @nb: notifier block to unregister
> + *
> + * @return 0 on success, otherwise a negative error code
> + *
> + * Register a notifier to get notified when backlight devices get registered
> + * or unregistered.
> + */
> +int backlight_unregister_notifier(struct notifier_block *nb)
> +{
> + return blocking_notifier_chain_unregister(&backlight_notifier, nb);
> +}
> +EXPORT_SYMBOL(backlight_unregister_notifier);
> +
> +/**
> * devm_backlight_device_register - resource managed backlight_device_register()
> * @dev: the device to register
> * @name: the name of the device
> @@ -544,6 +582,8 @@ static int __init backlight_class_init(void)
> backlight_class->pm = &backlight_class_dev_pm_ops;
> INIT_LIST_HEAD(&backlight_dev_list);
> mutex_init(&backlight_dev_list_mutex);
> + BLOCKING_INIT_NOTIFIER_HEAD(&backlight_notifier);
> +
> return 0;
> }
>
> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> index 7264742..adb14a8 100644
> --- a/include/linux/backlight.h
> +++ b/include/linux/backlight.h
> @@ -40,6 +40,11 @@ enum backlight_type {
> BACKLIGHT_TYPE_MAX,
> };
>
> +enum backlight_notification {
> + BACKLIGHT_REGISTERED,
> + BACKLIGHT_UNREGISTERED,
> +};
> +
> struct backlight_device;
> struct fb_info;
>
> @@ -133,6 +138,8 @@ extern void devm_backlight_device_unregister(struct device *dev,
> extern void backlight_force_update(struct backlight_device *bd,
> enum backlight_update_reason reason);
> extern bool backlight_device_registered(enum backlight_type type);
> +extern int backlight_register_notifier(struct notifier_block *nb);
> +extern int backlight_unregister_notifier(struct notifier_block *nb);
>
> #define to_backlight_device(obj) container_of(obj, struct backlight_device, dev)
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH resend 1/4] nouveau: Don't check acpi_video_backlight_support() before registering backli
From: Hans de Goede @ 2014-05-22 8:41 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Aaron Lu, Jingoo Han, Bryan Wu, Lee Jones,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Ben Skeggs,
David Airlie, Zhang Rui, Len Brown, linux-acpi, linux-fbdev,
dri-devel
In-Reply-To: <2450872.0pLqjZcv9y@vostro.rjw.lan>
Hi,
On 05/22/2014 01:30 AM, Rafael J. Wysocki wrote:
> On Wednesday, May 21, 2014 03:39:53 PM Hans de Goede wrote:
>> acpi_video_backlight_support() is supposed to be called by other (vendor
>> specific) firmware backlight controls, not by native / raw backlight controls
>> like nv_backlight.
>>
>> Userspace will normally prefer firmware interfaces over raw interfaces, so
>> if acpi_video backlight support is present it will use that even if
>> nv_backlight is registered as well.
>>
>> Except when video.use_native_backlight is present on the kernel cmdline
>> (or enabled through a dmi based quirk). As the name indicates the goal here
>> is to make only the raw interface available to userspace so that it will use
>> that (it only does this when it sees a win8 compliant bios).
>>
>> This is done by:
>> 1) Not registering any acpi_video# backlight devices; and
>> 2) Making acpi_video_backlight_support() return true so that other firmware
>> drivers, ie acer_wmi, thinkpad_acpi, dell_laptop, etc. Don't register their
>> own vender specific interfaces.
>>
>> Currently nouveau breaks this setup, as when acpi_video_backlight_support()
>> returns true, it does not register itself, resulting in no backlight control
>> at all.
>>
>> This is esp. going to be a problem with 3.16 which will default to
>> video.use_native_backlight=1, and thus nouveau based laptops with a win8 bios
>> will get no backlight control at all.
>>
>> This also likely explains why the previous attempt to make
>> video.use_native_backlight=1 the default was not a success, as without this
>> patch having a default of video.use_native_backlight=1 will cause regressions.
>>
>> Note this effectively reverts commit 5bead799
>>
>> Also see: https://bugzilla.redhat.com/show_bug.cgi?id\x1093171
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>
> It would be good to have an ACK from the nouveau people for this one.
Right, it could / should even go in through the drm tree I guess.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH resend 2/4] backlight: Add backlight device (un)registration notification
From: Hans de Goede @ 2014-05-22 8:44 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Aaron Lu, Jingoo Han, Bryan Wu, Lee Jones,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Ben Skeggs,
David Airlie, Zhang Rui, Len Brown, linux-acpi, linux-fbdev,
dri-devel
In-Reply-To: <82426680.ILvbY8i4gL@vostro.rjw.lan>
Hi,
On 05/22/2014 01:31 AM, Rafael J. Wysocki wrote:
> On Wednesday, May 21, 2014 03:39:54 PM Hans de Goede wrote:
>> Some firmware drivers, ie acpi-video want to get themselves out of the
>> way (in some cases) when their also is a raw backlight device available.
>>
>> Due to module loading ordering being unknown, acpi-video cannot be certain
>> that the backlight_device_registered(BACKLIGHT_RAW) it does for this is
>> the final verdict wrt there being a BACKLIGHT_RAW device.
>>
>> By adding notification acpi-video can listen for backlight devices showing
>> up after it has loaded, and unregister its backlight device if desired.
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>
> Backlight maintainer's ACK is requisite here.
Agreed, which is why I send this set to all 3 the backlight maintainers
directly on both postings.
What may be helpful for them is to hear from you if you're ok with the
acpi-video bits which are actually going to use this, since those will
be the only user of the new backlight api (for now).
Thanks & Regardsm
Hans
>
>> ---
>> drivers/video/backlight/backlight.c | 40 +++++++++++++++++++++++++++++++++++++
>> include/linux/backlight.h | 7 +++++++
>> 2 files changed, 47 insertions(+)
>>
>> diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
>> index bd2172c..4280890 100644
>> --- a/drivers/video/backlight/backlight.c
>> +++ b/drivers/video/backlight/backlight.c
>> @@ -23,6 +23,7 @@
>>
>> static struct list_head backlight_dev_list;
>> static struct mutex backlight_dev_list_mutex;
>> +static struct blocking_notifier_head backlight_notifier;
>>
>> static const char *const backlight_types[] = {
>> [BACKLIGHT_RAW] = "raw",
>> @@ -370,6 +371,9 @@ struct backlight_device *backlight_device_register(const char *name,
>> list_add(&new_bd->entry, &backlight_dev_list);
>> mutex_unlock(&backlight_dev_list_mutex);
>>
>> + blocking_notifier_call_chain(&backlight_notifier,
>> + BACKLIGHT_REGISTERED, new_bd);
>> +
>> return new_bd;
>> }
>> EXPORT_SYMBOL(backlight_device_register);
>> @@ -413,6 +417,10 @@ void backlight_device_unregister(struct backlight_device *bd)
>> pmac_backlight = NULL;
>> mutex_unlock(&pmac_backlight_mutex);
>> #endif
>> +
>> + blocking_notifier_call_chain(&backlight_notifier,
>> + BACKLIGHT_UNREGISTERED, bd);
>> +
>> mutex_lock(&bd->ops_lock);
>> bd->ops = NULL;
>> mutex_unlock(&bd->ops_lock);
>> @@ -438,6 +446,36 @@ static int devm_backlight_device_match(struct device *dev, void *res,
>> }
>>
>> /**
>> + * backlight_register_notifier - get notified of backlight (un)registration
>> + * @nb: notifier block with the notifier to call on backlight (un)registration
>> + *
>> + * @return 0 on success, otherwise a negative error code
>> + *
>> + * Register a notifier to get notified when backlight devices get registered
>> + * or unregistered.
>> + */
>> +int backlight_register_notifier(struct notifier_block *nb)
>> +{
>> + return blocking_notifier_chain_register(&backlight_notifier, nb);
>> +}
>> +EXPORT_SYMBOL(backlight_register_notifier);
>> +
>> +/**
>> + * backlight_unregister_notifier - unregister a backlight notifier
>> + * @nb: notifier block to unregister
>> + *
>> + * @return 0 on success, otherwise a negative error code
>> + *
>> + * Register a notifier to get notified when backlight devices get registered
>> + * or unregistered.
>> + */
>> +int backlight_unregister_notifier(struct notifier_block *nb)
>> +{
>> + return blocking_notifier_chain_unregister(&backlight_notifier, nb);
>> +}
>> +EXPORT_SYMBOL(backlight_unregister_notifier);
>> +
>> +/**
>> * devm_backlight_device_register - resource managed backlight_device_register()
>> * @dev: the device to register
>> * @name: the name of the device
>> @@ -544,6 +582,8 @@ static int __init backlight_class_init(void)
>> backlight_class->pm = &backlight_class_dev_pm_ops;
>> INIT_LIST_HEAD(&backlight_dev_list);
>> mutex_init(&backlight_dev_list_mutex);
>> + BLOCKING_INIT_NOTIFIER_HEAD(&backlight_notifier);
>> +
>> return 0;
>> }
>>
>> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
>> index 7264742..adb14a8 100644
>> --- a/include/linux/backlight.h
>> +++ b/include/linux/backlight.h
>> @@ -40,6 +40,11 @@ enum backlight_type {
>> BACKLIGHT_TYPE_MAX,
>> };
>>
>> +enum backlight_notification {
>> + BACKLIGHT_REGISTERED,
>> + BACKLIGHT_UNREGISTERED,
>> +};
>> +
>> struct backlight_device;
>> struct fb_info;
>>
>> @@ -133,6 +138,8 @@ extern void devm_backlight_device_unregister(struct device *dev,
>> extern void backlight_force_update(struct backlight_device *bd,
>> enum backlight_update_reason reason);
>> extern bool backlight_device_registered(enum backlight_type type);
>> +extern int backlight_register_notifier(struct notifier_block *nb);
>> +extern int backlight_unregister_notifier(struct notifier_block *nb);
>>
>> #define to_backlight_device(obj) container_of(obj, struct backlight_device, dev)
>>
>>
>
^ permalink raw reply
* Re: [PATCH resend 2/4] backlight: Add backlight device (un)registration notification
From: Lee Jones @ 2014-05-22 9:02 UTC (permalink / raw)
To: Hans de Goede
Cc: Rafael J. Wysocki, Aaron Lu, Jingoo Han, Bryan Wu,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Ben Skeggs,
David Airlie, Zhang Rui, Len Brown, linux-acpi, linux-fbdev,
dri-devel
In-Reply-To: <537DB904.50901@redhat.com>
> >> Some firmware drivers, ie acpi-video want to get themselves out of the
> >> way (in some cases) when their also is a raw backlight device available.
> >>
> >> Due to module loading ordering being unknown, acpi-video cannot be certain
> >> that the backlight_device_registered(BACKLIGHT_RAW) it does for this is
> >> the final verdict wrt there being a BACKLIGHT_RAW device.
> >>
> >> By adding notification acpi-video can listen for backlight devices showing
> >> up after it has loaded, and unregister its backlight device if desired.
> >>
> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> >
> > Backlight maintainer's ACK is requisite here.
>
> Agreed, which is why I send this set to all 3 the backlight maintainers
> directly on both postings.
>
> What may be helpful for them is to hear from you if you're ok with the
> acpi-video bits which are actually going to use this, since those will
> be the only user of the new backlight api (for now).
I'm happy to apply any Backlight patches which have either Bryan or
Jingoo's Ack, as they are the reviewers for the BL subsystem.
> >> ---
> >> drivers/video/backlight/backlight.c | 40 +++++++++++++++++++++++++++++++++++++
> >> include/linux/backlight.h | 7 +++++++
> >> 2 files changed, 47 insertions(+)
> >>
> >> diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
> >> index bd2172c..4280890 100644
> >> --- a/drivers/video/backlight/backlight.c
> >> +++ b/drivers/video/backlight/backlight.c
> >> @@ -23,6 +23,7 @@
> >>
> >> static struct list_head backlight_dev_list;
> >> static struct mutex backlight_dev_list_mutex;
> >> +static struct blocking_notifier_head backlight_notifier;
> >>
> >> static const char *const backlight_types[] = {
> >> [BACKLIGHT_RAW] = "raw",
> >> @@ -370,6 +371,9 @@ struct backlight_device *backlight_device_register(const char *name,
> >> list_add(&new_bd->entry, &backlight_dev_list);
> >> mutex_unlock(&backlight_dev_list_mutex);
> >>
> >> + blocking_notifier_call_chain(&backlight_notifier,
> >> + BACKLIGHT_REGISTERED, new_bd);
> >> +
> >> return new_bd;
> >> }
> >> EXPORT_SYMBOL(backlight_device_register);
> >> @@ -413,6 +417,10 @@ void backlight_device_unregister(struct backlight_device *bd)
> >> pmac_backlight = NULL;
> >> mutex_unlock(&pmac_backlight_mutex);
> >> #endif
> >> +
> >> + blocking_notifier_call_chain(&backlight_notifier,
> >> + BACKLIGHT_UNREGISTERED, bd);
> >> +
> >> mutex_lock(&bd->ops_lock);
> >> bd->ops = NULL;
> >> mutex_unlock(&bd->ops_lock);
> >> @@ -438,6 +446,36 @@ static int devm_backlight_device_match(struct device *dev, void *res,
> >> }
> >>
> >> /**
> >> + * backlight_register_notifier - get notified of backlight (un)registration
> >> + * @nb: notifier block with the notifier to call on backlight (un)registration
> >> + *
> >> + * @return 0 on success, otherwise a negative error code
> >> + *
> >> + * Register a notifier to get notified when backlight devices get registered
> >> + * or unregistered.
> >> + */
> >> +int backlight_register_notifier(struct notifier_block *nb)
> >> +{
> >> + return blocking_notifier_chain_register(&backlight_notifier, nb);
> >> +}
> >> +EXPORT_SYMBOL(backlight_register_notifier);
> >> +
> >> +/**
> >> + * backlight_unregister_notifier - unregister a backlight notifier
> >> + * @nb: notifier block to unregister
> >> + *
> >> + * @return 0 on success, otherwise a negative error code
> >> + *
> >> + * Register a notifier to get notified when backlight devices get registered
> >> + * or unregistered.
> >> + */
> >> +int backlight_unregister_notifier(struct notifier_block *nb)
> >> +{
> >> + return blocking_notifier_chain_unregister(&backlight_notifier, nb);
> >> +}
> >> +EXPORT_SYMBOL(backlight_unregister_notifier);
> >> +
> >> +/**
> >> * devm_backlight_device_register - resource managed backlight_device_register()
> >> * @dev: the device to register
> >> * @name: the name of the device
> >> @@ -544,6 +582,8 @@ static int __init backlight_class_init(void)
> >> backlight_class->pm = &backlight_class_dev_pm_ops;
> >> INIT_LIST_HEAD(&backlight_dev_list);
> >> mutex_init(&backlight_dev_list_mutex);
> >> + BLOCKING_INIT_NOTIFIER_HEAD(&backlight_notifier);
> >> +
> >> return 0;
> >> }
> >>
> >> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> >> index 7264742..adb14a8 100644
> >> --- a/include/linux/backlight.h
> >> +++ b/include/linux/backlight.h
> >> @@ -40,6 +40,11 @@ enum backlight_type {
> >> BACKLIGHT_TYPE_MAX,
> >> };
> >>
> >> +enum backlight_notification {
> >> + BACKLIGHT_REGISTERED,
> >> + BACKLIGHT_UNREGISTERED,
> >> +};
> >> +
> >> struct backlight_device;
> >> struct fb_info;
> >>
> >> @@ -133,6 +138,8 @@ extern void devm_backlight_device_unregister(struct device *dev,
> >> extern void backlight_force_update(struct backlight_device *bd,
> >> enum backlight_update_reason reason);
> >> extern bool backlight_device_registered(enum backlight_type type);
> >> +extern int backlight_register_notifier(struct notifier_block *nb);
> >> +extern int backlight_unregister_notifier(struct notifier_block *nb);
> >>
> >> #define to_backlight_device(obj) container_of(obj, struct backlight_device, dev)
> >>
> >>
> >
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] OMAPDSS: move 'compatible' converter to omapdss driver
From: Tomi Valkeinen @ 2014-05-22 12:10 UTC (permalink / raw)
To: linux-omap, linux-fbdev, Sebastian Reichel, Tony Lindgren
Cc: Javier Martinez Canillas, Tomi Valkeinen
In-Reply-To: <1400141136-25358-1-git-send-email-tomi.valkeinen@ti.com>
Move the panel/encoder driver compatible-string converter from
arch/arm/mach-omap2/display.c to omapdss driver. That is a more logical
place for it, as it's really an omapdss internal hack.
The code is rewritten to follow the video node graph, starting from
omapdss. This removes the need to have the device compatible-string
database.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/display.c | 56 ------
drivers/video/fbdev/omap2/Makefile | 2 +-
drivers/video/fbdev/omap2/dss/Kconfig | 4 +
drivers/video/fbdev/omap2/dss/Makefile | 1 +
drivers/video/fbdev/omap2/dss/omapdss-boot-init.c | 229 ++++++++++++++++++++++
5 files changed, 235 insertions(+), 57 deletions(-)
create mode 100644 drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 16d33d831287..519a20fc0432 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -555,65 +555,9 @@ int omap_dss_reset(struct omap_hwmod *oh)
return r;
}
-/* list of 'compatible' nodes to convert to omapdss specific */
-static const char * const dss_compat_conv_list[] __initconst = {
- "composite-connector",
- "dvi-connector",
- "hdmi-connector",
- "panel-dpi",
- "panel-dsi-cm",
- "sony,acx565akm",
- "svideo-connector",
- "ti,tfp410",
- "ti,tpd12s015",
-};
-
-/* prepend compatible string with "omapdss," */
-static __init void omapdss_omapify_node(struct device_node *node,
- const char *compat)
-{
- char *new_compat;
- struct property *prop;
-
- new_compat = kasprintf(GFP_KERNEL, "omapdss,%s", compat);
-
- prop = kzalloc(sizeof(*prop), GFP_KERNEL);
-
- if (!prop) {
- pr_err("omapdss_omapify_node: kzalloc failed\n");
- return;
- }
-
- prop->name = "compatible";
- prop->value = new_compat;
- prop->length = strlen(new_compat) + 1;
-
- of_update_property(node, prop);
-}
-
-/*
- * As omapdss panel drivers are omapdss specific, but we want to define the
- * DT-data in generic manner, we convert the compatible strings of the panel
- * nodes from "panel-foo" to "omapdss,panel-foo". This way we can have both
- * correct DT data and omapdss specific drivers.
- *
- * When we get generic panel drivers to the kernel, this will be removed.
- */
void __init omapdss_early_init_of(void)
{
- int i;
-
- for (i = 0; i < ARRAY_SIZE(dss_compat_conv_list); ++i) {
- const char *compat = dss_compat_conv_list[i];
- struct device_node *node = NULL;
-
- while ((node = of_find_compatible_node(node, NULL, compat))) {
- if (!of_device_is_available(node))
- continue;
- omapdss_omapify_node(node, compat);
- }
- }
}
struct device_node * __init omapdss_find_dss_of_node(void)
diff --git a/drivers/video/fbdev/omap2/Makefile b/drivers/video/fbdev/omap2/Makefile
index bf8127df8c71..f8745ec369cc 100644
--- a/drivers/video/fbdev/omap2/Makefile
+++ b/drivers/video/fbdev/omap2/Makefile
@@ -1,5 +1,5 @@
obj-$(CONFIG_OMAP2_VRFB) += vrfb.o
-obj-$(CONFIG_OMAP2_DSS) += dss/
+obj-y += dss/
obj-y += displays-new/
obj-$(CONFIG_FB_OMAP2) += omapfb/
diff --git a/drivers/video/fbdev/omap2/dss/Kconfig b/drivers/video/fbdev/omap2/dss/Kconfig
index dde4281663b1..a28f3a39ab1b 100644
--- a/drivers/video/fbdev/omap2/dss/Kconfig
+++ b/drivers/video/fbdev/omap2/dss/Kconfig
@@ -1,6 +1,10 @@
+config OMAP2_DSS_INIT
+ bool
+
menuconfig OMAP2_DSS
tristate "OMAP2+ Display Subsystem support"
select VIDEOMODE_HELPERS
+ select OMAP2_DSS_INIT
help
OMAP2+ Display Subsystem support.
diff --git a/drivers/video/fbdev/omap2/dss/Makefile b/drivers/video/fbdev/omap2/dss/Makefile
index 8aec8bda27cc..3b79ad74f2e1 100644
--- a/drivers/video/fbdev/omap2/dss/Makefile
+++ b/drivers/video/fbdev/omap2/dss/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_OMAP2_DSS_INIT) += omapdss-boot-init.o
obj-$(CONFIG_OMAP2_DSS) += omapdss.o
# Core DSS files
omapdss-y := core.o dss.o dss_features.o dispc.o dispc_coefs.o display.o \
diff --git a/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c b/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
new file mode 100644
index 000000000000..99af9e88b2d8
--- /dev/null
+++ b/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
@@ -0,0 +1,229 @@
+/*
+ * Copyright (C) 2014 Texas Instruments
+ * Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+/*
+ * As omapdss panel drivers are omapdss specific, but we want to define the
+ * DT-data in generic manner, we convert the compatible strings of the panel and
+ * encoder nodes from "panel-foo" to "omapdss,panel-foo". This way we can have
+ * both correct DT data and omapdss specific drivers.
+ *
+ * When we get generic panel drivers to the kernel, this file will be removed.
+ */
+
+#include <linux/kernel.h>
+#include <linux/of.h>
+#include <linux/of_graph.h>
+#include <linux/slab.h>
+#include <linux/list.h>
+
+static struct list_head dss_conv_list __initdata;
+
+static const char prefix[] __initconst = "omapdss,";
+
+struct dss_conv_node {
+ struct list_head list;
+ struct device_node *node;
+ bool root;
+};
+
+static int __init omapdss_count_strings(const struct property *prop)
+{
+ const char *p = prop->value;
+ int l = 0, total = 0;
+ int i;
+
+ for (i = 0; total < prop->length; total += l, p += l, i++)
+ l = strlen(p) + 1;
+
+ return i;
+}
+
+static void __init omapdss_update_prop(struct device_node *node, char *compat,
+ int len)
+{
+ struct property *prop;
+
+ prop = kzalloc(sizeof(*prop), GFP_KERNEL);
+ if (!prop)
+ return;
+
+ prop->name = "compatible";
+ prop->value = compat;
+ prop->length = len;
+
+ of_update_property(node, prop);
+}
+
+static void __init omapdss_prefix_strcpy(char *dst, int dst_len,
+ const char *src, int src_len)
+{
+ size_t total = 0;
+
+ while (total < src_len) {
+ size_t l = strlen(src) + 1;
+
+ strcpy(dst, prefix);
+ dst += strlen(prefix);
+
+ strcpy(dst, src);
+ dst += l;
+
+ src += l;
+ total += l;
+ }
+}
+
+/* prepend compatible property strings with "omapdss," */
+static void __init omapdss_omapify_node(struct device_node *node)
+{
+ struct property *prop;
+ char *new_compat;
+ int num_strs;
+ int new_len;
+
+ prop = of_find_property(node, "compatible", NULL);
+
+ if (!prop || !prop->value)
+ return;
+
+ if (strnlen(prop->value, prop->length) >= prop->length)
+ return;
+
+ /* is it already prefixed? */
+ if (strncmp(prefix, prop->value, strlen(prefix)) = 0)
+ return;
+
+ num_strs = omapdss_count_strings(prop);
+
+ new_len = prop->length + strlen(prefix) * num_strs;
+ new_compat = kmalloc(new_len, GFP_KERNEL);
+
+ omapdss_prefix_strcpy(new_compat, new_len, prop->value, prop->length);
+
+ omapdss_update_prop(node, new_compat, new_len);
+}
+
+static void __init omapdss_add_to_list(struct device_node *node, bool root)
+{
+ struct dss_conv_node *n = kmalloc(sizeof(struct dss_conv_node),
+ GFP_KERNEL);
+ n->node = node;
+ n->root = root;
+ list_add(&n->list, &dss_conv_list);
+}
+
+static bool __init omapdss_list_contains(const struct device_node *node)
+{
+ struct dss_conv_node *n;
+
+ list_for_each_entry(n, &dss_conv_list, list) {
+ if (n->node = node)
+ return true;
+ }
+
+ return false;
+}
+
+static void __init omapdss_walk_device(struct device_node *node, bool root)
+{
+ struct device_node *n;
+
+ omapdss_add_to_list(node, root);
+
+ /*
+ * of_graph_get_remote_port_parent() prints an error if there is no
+ * port/ports node. To avoid that, check first that there's the node.
+ */
+ n = of_get_child_by_name(node, "ports");
+ if (!n)
+ n = of_get_child_by_name(node, "port");
+ if (!n)
+ return;
+
+ of_node_put(n);
+
+ n = NULL;
+ while ((n = of_graph_get_next_endpoint(node, n)) != NULL) {
+ struct device_node *pn;
+
+ pn = of_graph_get_remote_port_parent(n);
+
+ if (!pn) {
+ of_node_put(n);
+ continue;
+ }
+
+ if (!of_device_is_available(pn) || omapdss_list_contains(pn)) {
+ of_node_put(pn);
+ of_node_put(n);
+ continue;
+ }
+
+ omapdss_walk_device(pn, false);
+
+ of_node_put(n);
+ }
+}
+
+static const struct of_device_id omapdss_of_match[] __initconst = {
+ { .compatible = "ti,omap2-dss", },
+ { .compatible = "ti,omap3-dss", },
+ { .compatible = "ti,omap4-dss", },
+ { .compatible = "ti,omap5-dss", },
+ {},
+};
+
+static int __init omapdss_boot_init(void)
+{
+ struct device_node *dss, *child;
+
+ INIT_LIST_HEAD(&dss_conv_list);
+
+ dss = of_find_matching_node(NULL, omapdss_of_match);
+
+ if (dss = NULL || !of_device_is_available(dss))
+ return 0;
+
+ omapdss_walk_device(dss, true);
+
+ for_each_available_child_of_node(dss, child) {
+ if (!of_find_property(child, "compatible", NULL)) {
+ of_node_put(child);
+ continue;
+ }
+
+ omapdss_walk_device(child, true);
+ }
+
+ while (!list_empty(&dss_conv_list)) {
+ struct dss_conv_node *n;
+
+ n = list_first_entry(&dss_conv_list, struct dss_conv_node,
+ list);
+
+ if (!n->root)
+ omapdss_omapify_node(n->node);
+
+ list_del(&n->list);
+ of_node_put(n->node);
+ kfree(n);
+ }
+
+ return 0;
+}
+
+subsys_initcall(omapdss_boot_init);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH resend 1/4] nouveau: Don't check acpi_video_backlight_support() before registering backli
From: Ben Skeggs @ 2014-05-23 4:13 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Hans de Goede, Aaron Lu, linux-fbdev,
Jean-Christophe Plagniol-Villard, Bryan Wu,
dri-devel@lists.freedesktop.org, linux-acpi, Tomi Valkeinen,
Ben Skeggs, Zhang Rui, Lee Jones, Len Brown
In-Reply-To: <2450872.0pLqjZcv9y@vostro.rjw.lan>
On Thu, May 22, 2014 at 9:30 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Wednesday, May 21, 2014 03:39:53 PM Hans de Goede wrote:
>> acpi_video_backlight_support() is supposed to be called by other (vendor
>> specific) firmware backlight controls, not by native / raw backlight controls
>> like nv_backlight.
>>
>> Userspace will normally prefer firmware interfaces over raw interfaces, so
>> if acpi_video backlight support is present it will use that even if
>> nv_backlight is registered as well.
>>
>> Except when video.use_native_backlight is present on the kernel cmdline
>> (or enabled through a dmi based quirk). As the name indicates the goal here
>> is to make only the raw interface available to userspace so that it will use
>> that (it only does this when it sees a win8 compliant bios).
>>
>> This is done by:
>> 1) Not registering any acpi_video# backlight devices; and
>> 2) Making acpi_video_backlight_support() return true so that other firmware
>> drivers, ie acer_wmi, thinkpad_acpi, dell_laptop, etc. Don't register their
>> own vender specific interfaces.
>>
>> Currently nouveau breaks this setup, as when acpi_video_backlight_support()
>> returns true, it does not register itself, resulting in no backlight control
>> at all.
>>
>> This is esp. going to be a problem with 3.16 which will default to
>> video.use_native_backlight=1, and thus nouveau based laptops with a win8 bios
>> will get no backlight control at all.
>>
>> This also likely explains why the previous attempt to make
>> video.use_native_backlight=1 the default was not a success, as without this
>> patch having a default of video.use_native_backlight=1 will cause regressions.
>>
>> Note this effectively reverts commit 5bead799
>>
>> Also see: https://bugzilla.redhat.com/show_bug.cgi?id\x1093171
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>
> It would be good to have an ACK from the nouveau people for this one.
Acked-by: Ben Skeggs <bskeggs@redhat.com>
;)
>
>> ---
>> drivers/gpu/drm/nouveau/nouveau_backlight.c | 9 ---------
>> 1 file changed, 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c b/drivers/gpu/drm/nouveau/nouveau_backlight.c
>> index 630f6e8..2c1e4aa 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
>> @@ -31,7 +31,6 @@
>> */
>>
>> #include <linux/backlight.h>
>> -#include <linux/acpi.h>
>>
>> #include "nouveau_drm.h"
>> #include "nouveau_reg.h"
>> @@ -222,14 +221,6 @@ nouveau_backlight_init(struct drm_device *dev)
>> struct nouveau_device *device = nv_device(drm->device);
>> struct drm_connector *connector;
>>
>> -#ifdef CONFIG_ACPI
>> - if (acpi_video_backlight_support()) {
>> - NV_INFO(drm, "ACPI backlight interface available, "
>> - "not registering our own\n");
>> - return 0;
>> - }
>> -#endif
>> -
>> list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
>> if (connector->connector_type != DRM_MODE_CONNECTOR_LVDS &&
>> connector->connector_type != DRM_MODE_CONNECTOR_eDP)
>>
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v3 2/3] ARM: dts: oma3-gta04: Add display support
From: Tomi Valkeinen @ 2014-05-23 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1399580212-5183-3-git-send-email-marek@goldelico.com>
[-- Attachment #1: Type: text/plain, Size: 433 bytes --]
On 08/05/14 23:16, Marek Belisko wrote:
> This patch add support for lcd display on gta04 board. Display control
> is connected to spi (used spi bitbang driver).
>
> Signed-off-by: Marek Belisko <marek@goldelico.com>
> ---
> arch/arm/boot/dts/omap3-gta04.dts | 87 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 87 insertions(+)
I can take this via my tree.
Tony, can I have your ack on this?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] video: of: display_timing: fix default native-mode setting
From: Tomi Valkeinen @ 2014-05-23 10:31 UTC (permalink / raw)
To: Boris BREZILLON
Cc: Jean-Christophe Plagniol-Villard, linux-fbdev, linux-kernel
In-Reply-To: <1399643592-17125-1-git-send-email-boris.brezillon@free-electrons.com>
[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]
On 09/05/14 16:53, Boris BREZILLON wrote:
> Set native mode to the first child node of the display-timings node and not
> the first child node of the display-timings parent node.
>
> Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
> ---
> drivers/video/of_display_timing.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/of_display_timing.c b/drivers/video/of_display_timing.c
> index ba5b40f..19dd752 100644
> --- a/drivers/video/of_display_timing.c
> +++ b/drivers/video/of_display_timing.c
> @@ -164,7 +164,7 @@ struct display_timings *of_get_display_timings(struct device_node *np)
> entry = of_parse_phandle(timings_np, "native-mode", 0);
> /* assume first child as native mode if none provided */
> if (!entry)
> - entry = of_get_next_child(np, NULL);
> + entry = of_get_next_child(timings_np, NULL);
> /* if there is no child, it is useless to go on */
> if (!entry) {
> pr_err("%s: no timing specifications given\n",
>
Queued for 3.16.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] matroxfb: perform a dummy read of M_STATUS
From: Tomi Valkeinen @ 2014-05-23 10:45 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <alpine.LRH.2.02.1405150652270.19101@file01.intranet.prod.int.rdu2.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 794 bytes --]
On 15/05/14 13:58, Mikulas Patocka wrote:
> I had occasional screen corruption with the matrox framebuffer driver and
> I found out that the reason for the corruption is that the hardware
> blitter accesses the videoram while it is being written to.
>
> The matrox driver has a macro WaitTillIdle() that should wait until the
> blitter is idle, but it sometimes doesn't work. I added a dummy read
> mga_inl(M_STATUS) to WaitTillIdle() to fix the problem. The dummy read
> will flush the write buffer in the PCI chipset, and the next read of
> M_STATUS will return the hardware status.
>
> Since applying this patch, I had no screen corruption at all.
>
> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
> Cc: stable@vger.kernel.org
>
Queued for 3.16.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] video: fbdev: grvga.c: Fix for possible null pointer dereference
From: Tomi Valkeinen @ 2014-05-23 10:49 UTC (permalink / raw)
To: Rickard Strandqvist
Cc: Jean-Christophe Plagniol-Villard, Grant Likely, Rob Herring,
Sachin Kamat, Jingoo Han, Daniel Vetter, linux-fbdev,
linux-kernel, devicetree
In-Reply-To: <1400621759-7814-1-git-send-email-rickard_strandqvist@spectrumdigital.se>
[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]
On 21/05/14 00:35, Rickard Strandqvist wrote:
> There is otherwise a risk of a possible null pointer dereference.
>
> Was largely found by using a static code analysis program called cppcheck.
>
> Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
> ---
> drivers/video/fbdev/grvga.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/grvga.c b/drivers/video/fbdev/grvga.c
> index c078701..2db5bb1 100644
> --- a/drivers/video/fbdev/grvga.c
> +++ b/drivers/video/fbdev/grvga.c
> @@ -514,9 +514,10 @@ free_fb:
> static int grvga_remove(struct platform_device *device)
> {
> struct fb_info *info = dev_get_drvdata(&device->dev);
> - struct grvga_par *par = info->par;
> + struct grvga_par *par;
>
> if (info) {
> + par = info->par;
> unregister_framebuffer(info);
> fb_dealloc_cmap(&info->cmap);
>
Thanks, queued this and the next one (video: fbdev: s3fb.c: Fix for
possible null pointer dereference) for 3.16.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] drivers/video/fbdev/fb-puv3.c: Add header files for function unifb_mmap
From: Tomi Valkeinen @ 2014-05-23 10:51 UTC (permalink / raw)
To: sunzc522
Cc: linux-kernel, gxt, gang.chen.5i5j,
Jean-Christophe Plagniol-Villard, Jingoo Han, Daniel Vetter,
Joe Perches, Laurent Pinchart, linux-fbdev
In-Reply-To: <1400652811-5206-1-git-send-email-sunzc522@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 622 bytes --]
On 21/05/14 09:13, sunzc522@gmail.com wrote:
> From: Zhichuang SUN <sunzc522@gmail.com>
>
> Function unifb_mmap calls functions which are defined in linux/mm.h
> and asm/pgtable.h
>
> The related error (for unicore32 with unicore32_defconfig):
> CC drivers/video/fbdev/fb-puv3.o
> drivers/video/fbdev/fb-puv3.c: In function 'unifb_mmap':
> drivers/video/fbdev/fb-puv3.c:646: error: implicit declaration of
> function 'vm_iomap_memory'
> drivers/video/fbdev/fb-puv3.c:646: error: implicit declaration of
> function 'pgprot_noncached'
>
Thanks, queued for 3.16.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 00/19] Rework OMAP4+ HDMI audio support
From: Tomi Valkeinen @ 2014-05-23 11:02 UTC (permalink / raw)
To: Tony Lindgren, Jyri Sarha
Cc: alsa-devel, linux-fbdev, devicetree, linux-omap, peter.ujfalusi,
broonie, liam.r.girdwood, bcousson, detheridge
In-Reply-To: <20140512150616.GF31772@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]
On 12/05/14 18:06, Tony Lindgren wrote:
> * Jyri Sarha <jsarha@ti.com> [140512 02:13]:
>> Since RFC version of the patch set:
>> - Split callbacks removal patch away from "Integrated ASoC DAI
>> component driver implementation" patches for easier reading
>>
>> This set of patches fixes OMAP4+ HDMI audio. The structure of the
>> implementatin looks a bit different than before. Instead of creating a
>> driver specific API for a separate ASoC component driver to connect
>> to, this implementation integrates an the component driver into the
>> HDMI driver.
>>
>> The idea is to use an existing ASoC component driver API instead of
>> creating a new custom API for each HDMI IP and to avoid splitting the
>> driver to half for separate video and audio parts connected with the
>> API.
>>
>> The new implementation also uses simple-audio-card for a machine
>> driver instead of having its own HW specific machine driver.
>
> Can you guys please post this split into the following separate
> parts for the maintainers to merge:
>
> - ASoC changes
> - DSS changes
> - DTS changes
>
> And once those are all in, please post the defconfig changes.
Tony, this series will get delayed until 3.17, but I'd like to merge the
HDMI DMA channel changes to omap4/omap5.dtsi already to 3.16. They are
patches 13 and 15.
Those are very trivial, but I'd rather have acks from you for all the
.dts changes I'll be sending.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] video: clps711x: Add new Cirrus Logic CLPS711X framebuffer driver
From: Tomi Valkeinen @ 2014-05-23 12:31 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1397285583-15187-1-git-send-email-shc_work@mail.ru>
[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]
On 12/04/14 09:53, Alexander Shiyan wrote:
> This adds support for the framebuffer available in the Cirrus
> Logic CLPS711X CPUs.
> FB features:
> - 1-2-4 bits per pixel.
> - Programmable panel size to a maximum of 1024x256 at 4 bps.
> - Relocatible Frame Buffer (SRAM or SDRAM).
> - Programmable refresh rates.
> - 16 gray scale values.
> This new driver supports usage with devicetree and as a general
> change it removes last user of <mach/hardware.h> for CLPS711X targets,
> so this subarch will fully prepared to switch to multiplatform.
> The driver have been tested with custom board equipped Cirrus Logic
> EP7312 in DT and non-DT mode.
>
> Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
> ---
> drivers/video/fbdev/clps711x-fb.c | 456 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 456 insertions(+)
> create mode 100644 drivers/video/fbdev/clps711x-fb.c
<snip>
> +
> +static int clps711x_fb_get_mode_dt(struct platform_device *pdev)
> +{
> + struct device_node *disp, *np = pdev->dev.of_node;
> + struct fb_info *info = platform_get_drvdata(pdev);
> + struct clps711x_fb_info *cfb = info->par;
> + int ret;
> +
> + cfb->syscon =
> + syscon_regmap_lookup_by_compatible("cirrus,clps711x-syscon1");
> + if (IS_ERR(cfb->syscon))
> + return PTR_ERR(cfb->syscon);
Hmm, what's the syscon stuff about? Looks like it's required, but the DT
documentation patch doesn't mention it at all.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] video: clps711x: Add new Cirrus Logic CLPS711X framebuffer driver
From: Tomi Valkeinen @ 2014-05-23 12:43 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1397285583-15187-1-git-send-email-shc_work@mail.ru>
[-- Attachment #1: Type: text/plain, Size: 2884 bytes --]
On 18/05/14 15:01, Alexander Shiyan wrote:
> Fri, 16 May 2014 15:56:26 -0700 от Olof Johansson <olof@lixom.net>:
>> On Thu, May 08, 2014 at 01:14:40PM +0300, Tomi Valkeinen wrote:
>>> On 08/05/14 11:27, Alexander Shiyan wrote:
>>>
>>>>>> At this time the driver has three user.
>>>>>> Only one of them should theoretically work.
>>>>>> clps711x-autcpu12 should not work in the absence of memblock_reserve().
>>>>>> clps711x-p720t should not work due to physical address limitation as i
>>>>>> noticed before. Board means to use SRAM instead of SDRAM.
>>>>>> Only clps711x-edb7211 should work fine (in theory).
>>>>>> Is this a good reason to replace the driver? I think yes.
>>>>>
>>>>> Ok, if the situation is that bad, maybe we can just switch to the new
>>>>> driver. Have you verified that those boards do not work from anyone? Or
>>>>> asked someone to test the new driver with those boards?
>>>>
>>>> I'm not familiar with other users of this platform .
>>>> I am do not have these boards, all that I have written before that it's just a theory.
>>>> Firm in which I work, uses its own board with CLPS711X CPU , this board is the
>>>> only way to check for changes on real hardware .
>>>
>>> Ok. That makes me a bit nervous... You're removing a driver, which may
>>> (or may not) have been working for other users. And adding a new one,
>>> which may not (or may) work for the other users.
>>
>> Keep the old one around under another Kconfig name, mark it BROKEN,
>> and if nobody speaks up in a couple of releases, remove it?
>
> I like this variant, Tomi are you agree with this?
I don't know. All options sound somewhat bad to me, except if it's clear
nobody uses the old driver.
Anyway, it's rather late for 3.16. I'd like the removal of the old
driver to sit in the linux-next for a while.
Would it be possible to add the new driver along the old driver, and use
the new driver only for the boards you have, and for boards for which
it's clear the the old driver is not working? This could be merged for 3.16.
It's not so nice to have two drivers for the same hardware, but in this
case maybe that's not an issue. The old driver doesn't support DT, so no
conflicts there, and for non-DT the driver names seem to be different.
For 3.17, we could remove the old driver, and push that change to
linux-next right after the 3.16 merge window has closed.
Or, if you're fine with it, we can also delay adding the new driver to
3.17, and do both right after the 3.16 merge window has closed. I
personally like this most, so that we have both removal of the old and
adding the new sitting in the linux-next longer, but you might possibly
want the new driver in sooner.
Maybe I'm being overly cautious here, but as I don't have any idea about
the driver and its users, I rather be too cautious than not.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] video: clps711x: Add new C =?UTF-8?B?aXJydXMgTG9naWMgQ
From: Alexander Shiyan @ 2014-05-23 13:13 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1398327006.501536964@f133.i.mail.ru>
RnJpLCAyMyBNYXkgMjAxNCAxNTo0Mzo0MCArMDMwMCDQvtGCIFRvbWkgVmFsa2VpbmVuIDx0b21p
LnZhbGtlaW5lbkB0aS5jb20+Ogo+IE9uIDE4LzA1LzE0IDE1OjAxLCBBbGV4YW5kZXIgU2hpeWFu
IHdyb3RlOgo+ID4gRnJpLCAxNiBNYXkgMjAxNCAxNTo1NjoyNiAtMDcwMCDQvtGCIE9sb2YgSm9o
YW5zc29uIDxvbG9mQGxpeG9tLm5ldD46Cj4gPj4gT24gVGh1LCBNYXkgMDgsIDIwMTQgYXQgMDE6
MTQ6NDBQTSArMDMwMCwgVG9taSBWYWxrZWluZW4gd3JvdGU6Cj4gPj4+IE9uIDA4LzA1LzE0IDEx
OjI3LCBBbGV4YW5kZXIgU2hpeWFuIHdyb3RlOgo+ID4+Pgo+ID4+Pj4+PiBBdCB0aGlzIHRpbWUg
dGhlIGRyaXZlciBoYXMgdGhyZWUgdXNlci4KPiA+Pj4+Pj4gT25seSBvbmUgb2YgdGhlbSBzaG91
bGQgdGhlb3JldGljYWxseSB3b3JrLgo+ID4+Pj4+PiBjbHBzNzExeC1hdXRjcHUxMiBzaG91bGQg
bm90IHdvcmsgaW4gdGhlIGFic2VuY2Ugb2YgbWVtYmxvY2tfcmVzZXJ2ZSgpLgo+ID4+Pj4+PiBj
bHBzNzExeC1wNzIwdCBzaG91bGQgbm90IHdvcmsgZHVlIHRvIHBoeXNpY2FsIGFkZHJlc3MgbGlt
aXRhdGlvbiBhcyBpCj4gPj4+Pj4+IG5vdGljZWQgYmVmb3JlLiBCb2FyZCBtZWFucyB0byB1c2Ug
U1JBTSBpbnN0ZWFkIG9mIFNEUkFNLgo+ID4+Pj4+PiBPbmx5IGNscHM3MTF4LWVkYjcyMTEgc2hv
dWxkIHdvcmsgZmluZSAoaW4gdGhlb3J5KS4KPiA+Pj4+Pj4gSXMgdGhpcyBhIGdvb2QgcmVhc29u
IHRvIHJlcGxhY2UgdGhlIGRyaXZlcj8gSSB0aGluayB5ZXMuCj4gPj4+Pj4KPiA+Pj4+PiBPaywg
aWYgdGhlIHNpdHVhdGlvbiBpcyB0aGF0IGJhZCwgbWF5YmUgd2UgY2FuIGp1c3Qgc3dpdGNoIHRv
IHRoZSBuZXcKPiA+Pj4+PiBkcml2ZXIuIEhhdmUgeW91IHZlcmlmaWVkIHRoYXQgdGhvc2UgYm9h
cmRzIGRvIG5vdCB3b3JrIGZyb20gYW55b25lPyBPcgo+ID4+Pj4+IGFza2VkIHNvbWVvbmUgdG8g
dGVzdCB0aGUgbmV3IGRyaXZlciB3aXRoIHRob3NlIGJvYXJkcz8KPiA+Pj4+Cj4gPj4+PiBJJ20g
bm90IGZhbWlsaWFyIHdpdGggb3RoZXIgdXNlcnMgb2YgdGhpcyBwbGF0Zm9ybSAuCj4gPj4+PiBJ
IGFtIGRvIG5vdCBoYXZlIHRoZXNlIGJvYXJkcywgYWxsIHRoYXQgSSBoYXZlIHdyaXR0ZW4gYmVm
b3JlIHRoYXQgaXQncyBqdXN0IGEgdGhlb3J5Lgo+ID4+Pj4gRmlybSBpbiB3aGljaCBJIHdvcmss
IHVzZXMgaXRzIG93biBib2FyZCB3aXRoIENMUFM3MTFYIENQVSAsIHRoaXMgYm9hcmQgaXMgdGhl
Cj4gPj4+PiBvbmx5IHdheSB0byBjaGVjayBmb3IgY2hhbmdlcyBvbiByZWFsIGhhcmR3YXJlIC4K
PiA+Pj4KPiA+Pj4gT2suIFRoYXQgbWFrZXMgbWUgYSBiaXQgbmVydm91cy4uLiBZb3UncmUgcmVt
b3ZpbmcgYSBkcml2ZXIsIHdoaWNoIG1heQo+ID4+PiAob3IgbWF5IG5vdCkgaGF2ZSBiZWVuIHdv
cmtpbmcgZm9yIG90aGVyIHVzZXJzLiBBbmQgYWRkaW5nIGEgbmV3IG9uZSwKPiA+Pj4gd2hpY2gg
bWF5IG5vdCAob3IgbWF5KSB3b3JrIGZvciB0aGUgb3RoZXIgdXNlcnMuCj4gPj4KPiA+PiBLZWVw
IHRoZSBvbGQgb25lIGFyb3VuZCB1bmRlciBhbm90aGVyIEtjb25maWcgbmFtZSwgbWFyayBpdCBC
Uk9LRU4sCj4gPj4gYW5kIGlmIG5vYm9keSBzcGVha3MgdXAgaW4gYSBjb3VwbGUgb2YgcmVsZWFz
ZXMsIHJlbW92ZSBpdD8KPiA+IAo+ID4gSSBsaWtlIHRoaXMgdmFyaWFudCwgVG9taSBhcmUgeW91
IGFncmVlIHdpdGggdGhpcz8KPiAKPiBJIGRvbid0IGtub3cuIEFsbCBvcHRpb25zIHNvdW5kIHNv
bWV3aGF0IGJhZCB0byBtZSwgZXhjZXB0IGlmIGl0J3MgY2xlYXIKPiBub2JvZHkgdXNlcyB0aGUg
b2xkIGRyaXZlci4KPiAKPiBBbnl3YXksIGl0J3MgcmF0aGVyIGxhdGUgZm9yIDMuMTYuIEknZCBs
aWtlIHRoZSByZW1vdmFsIG9mIHRoZSBvbGQKPiBkcml2ZXIgdG8gc2l0IGluIHRoZSBsaW51eC1u
ZXh0IGZvciBhIHdoaWxlLgo+IAo+IFdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIGFkZCB0aGUgbmV3
IGRyaXZlciBhbG9uZyB0aGUgb2xkIGRyaXZlciwgYW5kIHVzZQo+IHRoZSBuZXcgZHJpdmVyIG9u
bHkgZm9yIHRoZSBib2FyZHMgeW91IGhhdmUsIGFuZCBmb3IgYm9hcmRzIGZvciB3aGljaAo+IGl0
J3MgY2xlYXIgdGhlIHRoZSBvbGQgZHJpdmVyIGlzIG5vdCB3b3JraW5nPyBUaGlzIGNvdWxkIGJl
IG1lcmdlZCBmb3IgMy4xNi4KCkF0IHRoaXMgdGltZSB5ZXMsIHdlIGNhbi4gQnV0IHNpbmNlIEkg
cGxhbiB0byBhZGQgbXVsdGlwbGF0Zm9ybSBzdXBwb3J0CmZvciB0aGlzIFNPQywgdGhpcyBzZWVt
cyBub3QgcG9zc2libGUuCkkgY2FuIHRyeSB0byBtYWtlIG11bHRpcGxhdGZvcm0gc3VwcG9ydCBv
cHRpb25hbCwgdGhlbiBpdCBjb3VsZCBiZSBkb25lLi4uCgo+IEl0J3Mgbm90IHNvIG5pY2UgdG8g
aGF2ZSB0d28gZHJpdmVycyBmb3IgdGhlIHNhbWUgaGFyZHdhcmUsIGJ1dCBpbiB0aGlzCj4gY2Fz
ZSBtYXliZSB0aGF0J3Mgbm90IGFuIGlzc3VlLiBUaGUgb2xkIGRyaXZlciBkb2Vzbid0IHN1cHBv
cnQgRFQsIHNvIG5vCj4gY29uZmxpY3RzIHRoZXJlLCBhbmQgZm9yIG5vbi1EVCB0aGUgZHJpdmVy
IG5hbWVzIHNlZW0gdG8gYmUgZGlmZmVyZW50Lgo+IAo+IEZvciAzLjE3LCB3ZSBjb3VsZCByZW1v
dmUgdGhlIG9sZCBkcml2ZXIsIGFuZCBwdXNoIHRoYXQgY2hhbmdlIHRvCj4gbGludXgtbmV4dCBy
aWdodCBhZnRlciB0aGUgMy4xNiBtZXJnZSB3aW5kb3cgaGFzIGNsb3NlZC4KPiAKPiBPciwgaWYg
eW91J3JlIGZpbmUgd2l0aCBpdCwgd2UgY2FuIGFsc28gZGVsYXkgYWRkaW5nIHRoZSBuZXcgZHJp
dmVyIHRvCj4gMy4xNywgYW5kIGRvIGJvdGggcmlnaHQgYWZ0ZXIgdGhlIDMuMTYgbWVyZ2Ugd2lu
ZG93IGhhcyBjbG9zZWQuIEkKPiBwZXJzb25hbGx5IGxpa2UgdGhpcyBtb3N0LCBzbyB0aGF0IHdl
IGhhdmUgYm90aCByZW1vdmFsIG9mIHRoZSBvbGQgYW5kCj4gYWRkaW5nIHRoZSBuZXcgc2l0dGlu
ZyBpbiB0aGUgbGludXgtbmV4dCBsb25nZXIsIGJ1dCB5b3UgbWlnaHQgcG9zc2libHkKPiB3YW50
IHRoZSBuZXcgZHJpdmVyIGluIHNvb25lci4KCklmIHRoZXJlIHdpbGwgYmUgdHdvIGRyaXZlcnMs
IEkgd2lsbCBkbyB0aGUgZm9sbG93aW5nOiByZW1vdmUgdGhlIG5vbi1EVApzdXBwb3J0IChmb3Ig
bmV3IGRyaXZlcikgYW5kIHdpbGwgY3JlYXRlIGEgcGF0Y2ggZm9yIDMuMTYgKHRoaXMgcGF0Y2gg
d2lsbApubyBhZmZlY3QgdG8gYXJtLXNvYykuCkFmdGVyIHRoYXQsIEkgd2lsbCBkbyBvcHRpb25h
bCBtdWx0aXBsYXRmb3JtIHN1cHBvcnQgZm9yIHRoaXMgQ1BVIGFuZCBtb3ZlCnRoZSBib2FyZHMs
IHdoaWNoIGRvIG5vdCB1c2UgRkIuCkFmdGVyIHRoaXMgYXJjaGl0ZWN0dXJlIHdpbGwgYmUgcmVh
ZHkgdG8gYWRkIERUIHN1cHBvcnQsIGFuZCBhZnRlciBhbGwgYm9hcmRzCndpbGwgYmUgY29udmVy
dGVkLCBJJ2xsIHJlbW92ZSB0aGUgb2xkIHZlcnNpb24gb2YgdGhlIGRyaXZlci4KCk9LPwoKLS0t
Cgo
^ permalink raw reply
* Re: [PATCH v2 1/3] video: clps711x: Add new C =?UTF-8?B?aXJydXMgTG9naWMgQ
From: Alexander Shiyan @ 2014-05-23 13:18 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1398327006.501536964@f133.i.mail.ru>
RnJpLCAyMyBNYXkgMjAxNCAxNTozMTo0NCArMDMwMCDQvtGCIFRvbWkgVmFsa2VpbmVuIDx0b21p
LnZhbGtlaW5lbkB0aS5jb20+Ogo+IE9uIDEyLzA0LzE0IDA5OjUzLCBBbGV4YW5kZXIgU2hpeWFu
IHdyb3RlOgo+ID4gVGhpcyBhZGRzIHN1cHBvcnQgZm9yIHRoZSBmcmFtZWJ1ZmZlciBhdmFpbGFi
bGUgaW4gdGhlIENpcnJ1cwo+ID4gTG9naWMgQ0xQUzcxMVggQ1BVcy4KPiA+IEZCIGZlYXR1cmVz
Ogo+ID4gLSAxLTItNCBiaXRzIHBlciBwaXhlbC4KPiA+IC0gUHJvZ3JhbW1hYmxlIHBhbmVsIHNp
emUgdG8gYSBtYXhpbXVtIG9mIDEwMjR4MjU2IGF0IDQgYnBzLgo+ID4gLSBSZWxvY2F0aWJsZSBG
cmFtZSBCdWZmZXIgKFNSQU0gb3IgU0RSQU0pLgo+ID4gLSBQcm9ncmFtbWFibGUgcmVmcmVzaCBy
YXRlcy4KPiA+IC0gMTYgZ3JheSBzY2FsZSB2YWx1ZXMuCj4gPiBUaGlzIG5ldyBkcml2ZXIgc3Vw
cG9ydHMgdXNhZ2Ugd2l0aCBkZXZpY2V0cmVlIGFuZCBhcyBhIGdlbmVyYWwKPiA+IGNoYW5nZSBp
dCByZW1vdmVzIGxhc3QgdXNlciBvZiA8bWFjaC9oYXJkd2FyZS5oPiBmb3IgQ0xQUzcxMVggdGFy
Z2V0cywKPiA+IHNvIHRoaXMgc3ViYXJjaCB3aWxsIGZ1bGx5IHByZXBhcmVkIHRvIHN3aXRjaCB0
byBtdWx0aXBsYXRmb3JtLgo+ID4gVGhlIGRyaXZlciBoYXZlIGJlZW4gdGVzdGVkIHdpdGggY3Vz
dG9tIGJvYXJkIGVxdWlwcGVkIENpcnJ1cyBMb2dpYwo+ID4gRVA3MzEyIGluIERUIGFuZCBub24t
RFQgbW9kZS4KPiA+IAo+ID4gU2lnbmVkLW9mZi1ieTogQWxleGFuZGVyIFNoaXlhbiA8c2hjX3dv
cmtAbWFpbC5ydT4KPiA+IC0tLQo+ID4gIGRyaXZlcnMvdmlkZW8vZmJkZXYvY2xwczcxMXgtZmIu
YyB8IDQ1NiArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKwo+ID4gIDEgZmls
ZSBjaGFuZ2VkLCA0NTYgaW5zZXJ0aW9ucygrKQo+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCBkcml2
ZXJzL3ZpZGVvL2ZiZGV2L2NscHM3MTF4LWZiLmMKPiAKPiA8c25pcD4KPiAKPiA+ICsKPiA+ICtz
dGF0aWMgaW50IGNscHM3MTF4X2ZiX2dldF9tb2RlX2R0KHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2Ug
KnBkZXYpCj4gPiArewo+ID4gKwlzdHJ1Y3QgZGV2aWNlX25vZGUgKmRpc3AsICpucCA9IHBkZXYt
PmRldi5vZl9ub2RlOwo+ID4gKwlzdHJ1Y3QgZmJfaW5mbyAqaW5mbyA9IHBsYXRmb3JtX2dldF9k
cnZkYXRhKHBkZXYpOwo+ID4gKwlzdHJ1Y3QgY2xwczcxMXhfZmJfaW5mbyAqY2ZiID0gaW5mby0+
cGFyOwo+ID4gKwlpbnQgcmV0Owo+ID4gKwo+ID4gKwljZmItPnN5c2NvbiA9Cj4gPiArCQlzeXNj
b25fcmVnbWFwX2xvb2t1cF9ieV9jb21wYXRpYmxlKCJjaXJydXMsY2xwczcxMXgtc3lzY29uMSIp
Owo+ID4gKwlpZiAoSVNfRVJSKGNmYi0+c3lzY29uKSkKPiA+ICsJCXJldHVybiBQVFJfRVJSKGNm
Yi0+c3lzY29uKTsKPiAKPiBIbW0sIHdoYXQncyB0aGUgc3lzY29uIHN0dWZmIGFib3V0PyBMb29r
cyBsaWtlIGl0J3MgcmVxdWlyZWQsIGJ1dCB0aGUgRFQKPiBkb2N1bWVudGF0aW9uIHBhdGNoIGRv
ZXNuJ3QgbWVudGlvbiBpdCBhdCBhbGwuCgpUaGlzIGRvZXMgbm90IHJlcXVpcmUgYW55IHNlcGFy
YXRlIHByb3BlcnR5IGZvciBGQi4KVGhlIHN5c2NvbiByZWdpc3RlcnMgaXMgZ2xvYmFsIHRvIHBs
YXRmb3JtLgoKLS0tCgo
^ permalink raw reply
* Re: [PATCH v2 1/3] video: clps711x: Add new Cirrus Logic CLPS711X framebuffer driver
From: Arnd Bergmann @ 2014-05-23 13:48 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1397285583-15187-1-git-send-email-shc_work@mail.ru>
On Friday 23 May 2014 17:13:58 Alexander Shiyan wrote:
> If there will be two drivers, I will do the following: remove the non-DT
> support (for new driver) and will create a patch for 3.16 (this patch will
> no affect to arm-soc).
> After that, I will do optional multiplatform support for this CPU and move
> the boards, which do not use FB.
> After this architecture will be ready to add DT support, and after all boards
> will be converted, I'll remove the old version of the driver.
>
> OK?
>
Sounds good to me.
Arnd
^ permalink raw reply
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