* Re: [PATCH 1/3] arm: omap2: Export devconf1 bypass and acbias.
From: Tony Lindgren @ 2013-11-11 23:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAfyv37LRb_Q=UZVgtKdOAz_r6_qThewAU90W7nrqHdB5fDA_g@mail.gmail.com>
* Belisko Marek <marek.belisko@gmail.com> [131111 14:01]:
> Hi Tony,
>
> On Mon, Nov 11, 2013 at 5:49 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Marek Belisko <marek@goldelico.com> [131014 14:11]:
> >> devconf1 reg access is localized only in mach-omap2 and we need to export
> >> updating of devconf1 from omapdss venc driver (bypass and acbias bits).
> >> Add simple api call which update only necessary bits.
> > ...
> >
> >> +void update_bypass_acbias(bool bypass, bool acbias)
> >> +{
> >> +#ifdef CONFIG_ARCH_OMAP3
> >> + int val = omap_ctrl_readl(OMAP343X_CONTROL_DEVCONF1);
> >> +
> >> + if (bypass)
> >> + val |= OMAP2_TVOUTBYPASS;
> >> + else
> >> + val &= ~OMAP2_TVOUTBYPASS;
> >> +
> >> + if (acbias)
> >> + val |= OMAP2_TVACEN;
> >> + else
> >> + val &= ~OMAP2_TVACEN;
> >> +
> >> + omap_ctrl_writel(val, OMAP343X_CONTROL_DEVCONF1);
> >> +#endif
> >
> > If this is truly a pinmux, you could already access this
> > using pinctrl-single,bits device tree driver.
> >
> > But I guess that won't work yet, so it's best to set this
> > up as a separate driver like we've done for the USB PHY
> > registers.
>
> Can you please point me to that driver directly? I cannot see benefit
> of new driver as as it will be only dummy driver
> with export_symbol_gpl of upper function. Can it sit then in dss
> directory or somewhere else? Thanks.
You can take a look at drivers/usb/phy/phy-omap-control.c.
Then there's a device tree using example for control_devconf0 in
Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt.
Looks like CONTROL_DEVCONF1 contains a bunch of misc registers,
and arch/arm/mach-omap2/hsmmc.c seems to be tinkering with it too.
It would be best to set it up as omap-ctrl.c driver under drivers
somewhere with few functions exported for DSS and MMC drivers.
The reason why it should be a separate driver is that the system
control module can live a separate runtime PM life from the
drivers using the CONTROL_DEVCONF register bits.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 1/3] arm: omap2: Export devconf1 bypass and acbias.
From: Tony Lindgren @ 2013-11-11 23:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAfyv34CyviSt_Jaygr-CYSQdZOBHz14awT3U8=2ZBT14s896g@mail.gmail.com>
* Belisko Marek <marek.belisko@gmail.com> [131111 14:21]:
> AFAIK it's not pinmux it's register where we update bits. Or am I
> missing something?
Most of the omap control module registers seem to affect either
external pin configuration or internal signal muxes. So a big
chunk of them can already be handled with pinctrl-single,bits
for device tree.
But some of the control module registers also have regulator
and clock like features, and those are better exposed as
regulators and clocks to the consumer drivers.
Regards,
Tony
^ permalink raw reply
* [PATCH] video: backlight: Remove backlight sysfs uevent
From: Kyungmin Park @ 2013-11-11 23:57 UTC (permalink / raw)
To: Richard Purdie, Jingoo Han; +Cc: linux-fbdev, linux-kernel, kay
From: Kyungmin Park <kyungmin.park@samsung.com>
The most mobile phones have Ambient Light Sensors and it changes brightness according lux.
It means it changes backlight brightness frequently by just writing sysfs node, so it generates uevent.
Usually there's no user to use this backlight changes. But it forks udev worker threads and it takes about 5ms. The main problem is that it hurts other process activities. so remove it.
Kay said
"Uevents are for the major, low-frequent, global device state-changes,
not for carrying-out any sort of measurement data. Subsystems which
need that should use other facilities like poll()-able sysfs file or
any other subscription-based, client-tracking interface which does not
cause overhead if it isn't used. Uevents are not the right thing to
use here, and upstream udev should not paper-over broken kernel
subsystems."
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
index 94a403a..441272d 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -88,9 +88,6 @@ static void backlight_generate_event(struct backlight_device *bd,
char *envp[2];
switch (reason) {
- case BACKLIGHT_UPDATE_SYSFS:
- envp[0] = "SOURCE=sysfs";
- break;
case BACKLIGHT_UPDATE_HOTKEY:
envp[0] = "SOURCE=hotkey";
break;
@@ -172,8 +169,6 @@ static ssize_t brightness_store(struct device *dev,
}
mutex_unlock(&bd->ops_lock);
- backlight_generate_event(bd, BACKLIGHT_UPDATE_SYSFS);
-
return rc;
}
static DEVICE_ATTR_RW(brightness);
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 53b7794..d2a27dd 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -29,7 +29,6 @@
enum backlight_update_reason {
BACKLIGHT_UPDATE_HOTKEY,
- BACKLIGHT_UPDATE_SYSFS,
};
enum backlight_type {
^ permalink raw reply related
* Re: [PATCH] video: backlight: Remove backlight sysfs uevent
From: Jingoo Han @ 2013-11-12 0:18 UTC (permalink / raw)
To: 'Kyungmin Park', 'Henrique de Moraes Holschuh'
Cc: linux-fbdev, linux-kernel, kay, 'Richard Purdie',
'Jingoo Han', ibm-acpi-devel, platform-driver-x86
In-Reply-To: <20131111235700.GA29987@july>
On Tuesday, November 12, 2013 8:57 AM, Kyungmin Park wrote:
>
> From: Kyungmin Park <kyungmin.park@samsung.com>
>
> The most mobile phones have Ambient Light Sensors and it changes brightness according lux.
> It means it changes backlight brightness frequently by just writing sysfs node, so it generates uevent.
>
> Usually there's no user to use this backlight changes. But it forks udev worker threads and it takes
> about 5ms. The main problem is that it hurts other process activities. so remove it.
>
> Kay said
> "Uevents are for the major, low-frequent, global device state-changes,
> not for carrying-out any sort of measurement data. Subsystems which
> need that should use other facilities like poll()-able sysfs file or
> any other subscription-based, client-tracking interface which does not
> cause overhead if it isn't used. Uevents are not the right thing to
> use here, and upstream udev should not paper-over broken kernel
> subsystems."
>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
> diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
> index 94a403a..441272d 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -88,9 +88,6 @@ static void backlight_generate_event(struct backlight_device *bd,
> char *envp[2];
>
> switch (reason) {
> - case BACKLIGHT_UPDATE_SYSFS:
> - envp[0] = "SOURCE=sysfs";
> - break;
> case BACKLIGHT_UPDATE_HOTKEY:
> envp[0] = "SOURCE=hotkey";
> break;
> @@ -172,8 +169,6 @@ static ssize_t brightness_store(struct device *dev,
> }
> mutex_unlock(&bd->ops_lock);
>
> - backlight_generate_event(bd, BACKLIGHT_UPDATE_SYSFS);
> -
> return rc;
> }
> static DEVICE_ATTR_RW(brightness);
> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> index 53b7794..d2a27dd 100644
> --- a/include/linux/backlight.h
> +++ b/include/linux/backlight.h
> @@ -29,7 +29,6 @@
>
> enum backlight_update_reason {
> BACKLIGHT_UPDATE_HOTKEY,
> - BACKLIGHT_UPDATE_SYSFS,
+cc Henrique de Moraes Holschuh (Maintainer of thinkpad_acpi)
Hi Henrique de Moraes Holschuh,
'thinkpad_acpi.c' uses the 'BACKLIGHT_UPDATE_SYSFS'.
Henrique, can we remove it?
drivers/platform/x86/thinkpad_acpi.c
if (!rc && ibm_backlight_device)
backlight_force_update(ibm_backlight_device,
BACKLIGHT_UPDATE_SYSFS);
Best regards,
Jingoo Han
> };
>
> enum backlight_type {
^ permalink raw reply
* [PATCH] video: backlight: Remove backlight sysfs uevent
From: Kyungmin Park @ 2013-11-12 0:44 UTC (permalink / raw)
To: Richard Purdie, Jingoo Han; +Cc: linux-fbdev, linux-kernel, kay
In-Reply-To: <20131111235700.GA29987@july>
From: Kyungmin Park <kyungmin.park@samsung.com>
The most mobile phones have Ambient Light Sensors and it changes brightness according lux.
It means it changes backlight brightness frequently by just writing sysfs node, so it generates uevent.
Usually there's no user to use this backlight changes. But it forks udev worker threads and it takes about 5ms. The main problem is that it hurts other process activities. so remove it.
Kay said
"Uevents are for the major, low-frequent, global device state-changes,
not for carrying-out any sort of measurement data. Subsystems which
need that should use other facilities like poll()-able sysfs file or
any other subscription-based, client-tracking interface which does not
cause overhead if it isn't used. Uevents are not the right thing to
use here, and upstream udev should not paper-over broken kernel
subsystems."
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
index 94a403a..441272d 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -88,9 +88,6 @@ static void backlight_generate_event(struct backlight_device *bd,
char *envp[2];
switch (reason) {
- case BACKLIGHT_UPDATE_SYSFS:
- envp[0] = "SOURCE=sysfs";
- break;
case BACKLIGHT_UPDATE_HOTKEY:
envp[0] = "SOURCE=hotkey";
break;
@@ -172,8 +169,6 @@ static ssize_t brightness_store(struct device *dev,
}
mutex_unlock(&bd->ops_lock);
- backlight_generate_event(bd, BACKLIGHT_UPDATE_SYSFS);
-
return rc;
}
static DEVICE_ATTR_RW(brightness);
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 53b7794..d2a27dd 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -29,7 +29,6 @@
enum backlight_update_reason {
BACKLIGHT_UPDATE_HOTKEY,
- BACKLIGHT_UPDATE_SYSFS,
};
enum backlight_type {
^ permalink raw reply related
* Re: [PATCH] video: backlight: Remove backlight sysfs uevent
From: Kyungmin Park @ 2013-11-12 0:54 UTC (permalink / raw)
To: Richard Purdie, Jingoo Han; +Cc: linux-fbdev, linux-kernel, kay
In-Reply-To: <20131112004436.GA30125@july>
Please ignore it. strange mail system.
After feedback from previous mail, I'll re-send it.
Thank you,
Kyungmin Park
On Tue, Nov 12, 2013 at 9:44 AM, Kyungmin Park <kmpark@infradead.org> wrote:
> From: Kyungmin Park <kyungmin.park@samsung.com>
>
> The most mobile phones have Ambient Light Sensors and it changes brightness according lux.
> It means it changes backlight brightness frequently by just writing sysfs node, so it generates uevent.
>
> Usually there's no user to use this backlight changes. But it forks udev worker threads and it takes about 5ms. The main problem is that it hurts other process activities. so remove it.
>
> Kay said
> "Uevents are for the major, low-frequent, global device state-changes,
> not for carrying-out any sort of measurement data. Subsystems which
> need that should use other facilities like poll()-able sysfs file or
> any other subscription-based, client-tracking interface which does not
> cause overhead if it isn't used. Uevents are not the right thing to
> use here, and upstream udev should not paper-over broken kernel
> subsystems."
>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
> diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
> index 94a403a..441272d 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -88,9 +88,6 @@ static void backlight_generate_event(struct backlight_device *bd,
> char *envp[2];
>
> switch (reason) {
> - case BACKLIGHT_UPDATE_SYSFS:
> - envp[0] = "SOURCE=sysfs";
> - break;
> case BACKLIGHT_UPDATE_HOTKEY:
> envp[0] = "SOURCE=hotkey";
> break;
> @@ -172,8 +169,6 @@ static ssize_t brightness_store(struct device *dev,
> }
> mutex_unlock(&bd->ops_lock);
>
> - backlight_generate_event(bd, BACKLIGHT_UPDATE_SYSFS);
> -
> return rc;
> }
> static DEVICE_ATTR_RW(brightness);
> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> index 53b7794..d2a27dd 100644
> --- a/include/linux/backlight.h
> +++ b/include/linux/backlight.h
> @@ -29,7 +29,6 @@
>
> enum backlight_update_reason {
> BACKLIGHT_UPDATE_HOTKEY,
> - BACKLIGHT_UPDATE_SYSFS,
> };
>
> enum backlight_type {
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH] video: backlight: Remove backlight sysfs uevent
From: Henrique de Moraes Holschuh @ 2013-11-12 0:56 UTC (permalink / raw)
To: Jingoo Han
Cc: 'Kyungmin Park', 'Henrique de Moraes Holschuh',
linux-fbdev, linux-kernel, kay, 'Richard Purdie',
ibm-acpi-devel, platform-driver-x86
In-Reply-To: <002901cedf3c$a7e77a00$f7b66e00$%han@samsung.com>
On Tue, 12 Nov 2013, Jingoo Han wrote:
> On Tuesday, November 12, 2013 8:57 AM, Kyungmin Park wrote:
> > From: Kyungmin Park <kyungmin.park@samsung.com>
> >
> > The most mobile phones have Ambient Light Sensors and it changes brightness according lux.
> > It means it changes backlight brightness frequently by just writing sysfs node, so it generates uevent.
> >
> > Usually there's no user to use this backlight changes. But it forks udev worker threads and it takes
> > about 5ms. The main problem is that it hurts other process activities. so remove it.
> >
> > Kay said
> > "Uevents are for the major, low-frequent, global device state-changes,
> > not for carrying-out any sort of measurement data. Subsystems which
> > need that should use other facilities like poll()-able sysfs file or
> > any other subscription-based, client-tracking interface which does not
> > cause overhead if it isn't used. Uevents are not the right thing to
> > use here, and upstream udev should not paper-over broken kernel
> > subsystems."
True.
Now, let's take a look at reality: should you poll()/select() on a sysfs
node that doesn't suport it, it will wait until the poll/select timeout
happens (or EINTR happens), and userspace has absolutely NO way to detect
whether a sysfs node has poll/select support.
What happens if the sysfs interface did not provide poll/select support
since day one, but rather added it later? Nobody will use it for a *long*
time, if ever... unless you actually took pains to version the sysfs
interface, and people actually care.
> 'thinkpad_acpi.c' uses the 'BACKLIGHT_UPDATE_SYSFS'.
> Henrique, can we remove it?
Can't you fix this by rate-limiting, or otherwise adding an attribute that
backlight devices should set when they need to supress change events?
Is there a proper on-screen-display support path for the backlight class
nowadays? Otherwise, you'd be removing the only way userspace ever had to
do proper OSD of backlight changes...
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply
* Re: [RESEND PATCH 1/2] fb: reorder the lock sequence to fix potential dead lock
From: Gu Zheng @ 2013-11-12 1:06 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Jean-Christophe PLAGNIOL-VILLARD, Linux Fbdev development list,
linux-kernel
In-Reply-To: <5280E2BF.7040602@ti.com>
Hi Tomi,
On 11/11/2013 09:59 PM, Tomi Valkeinen wrote:
> On 2013-11-05 12:00, Gu Zheng wrote:
>> Following commits:
>> 50e244cc79 fb: rework locking to fix lock ordering on takeover
>> e93a9a8687 fb: Yet another band-aid for fixing lockdep mess
>> 054430e773 fbcon: fix locking harder
>> reworked locking to fix related lock ordering on takeover, and introduced console_lock
>> into fbmem, but it seems that the new lock sequence(fb_info->lock ---> console_lock)
>> is against with the one in console_callback(console_lock ---> fb_info->lock), and leads to
>> a potential dead lock as following:
>
> <snip>
>
>> so we reorder the lock sequence the same as it in console_callback() to
>> avoid this issue. And following Tomi's suggestion, fix these similar
>> issues all in fb subsystem.
>>
>> Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
>> ---
>> drivers/video/fbmem.c | 50 ++++++++++++++++++++++++-------------
>> drivers/video/fbsysfs.c | 19 ++++++++++----
>> drivers/video/sh_mobile_lcdcfb.c | 10 ++++---
>> 3 files changed, 51 insertions(+), 28 deletions(-)
>
> I'll apply this for 3.13. It's a bit difficult to verify if the locking
> is now correct, but looks fine to me. And we can revert this easily if
> things break badly.
Thanks very munch.:)
Regards,
Gu
>
> Tomi
>
>
^ permalink raw reply
* Re: [PATCH] video: backlight: Remove backlight sysfs uevent
From: Kyungmin Park @ 2013-11-12 1:07 UTC (permalink / raw)
To: Henrique de Moraes Holschuh
Cc: Jingoo Han, Henrique de Moraes Holschuh, linux-fbdev,
linux-kernel, kay, Richard Purdie, ibm-acpi-devel,
platform-driver-x86
In-Reply-To: <20131112005628.GA2914@khazad-dum.debian.net>
On Tue, Nov 12, 2013 at 9:56 AM, Henrique de Moraes Holschuh
<hmh@hmh.eng.br> wrote:
> On Tue, 12 Nov 2013, Jingoo Han wrote:
>> On Tuesday, November 12, 2013 8:57 AM, Kyungmin Park wrote:
>> > From: Kyungmin Park <kyungmin.park@samsung.com>
>> >
>> > The most mobile phones have Ambient Light Sensors and it changes brightness according lux.
>> > It means it changes backlight brightness frequently by just writing sysfs node, so it generates uevent.
>> >
>> > Usually there's no user to use this backlight changes. But it forks udev worker threads and it takes
>> > about 5ms. The main problem is that it hurts other process activities. so remove it.
>> >
>> > Kay said
>> > "Uevents are for the major, low-frequent, global device state-changes,
>> > not for carrying-out any sort of measurement data. Subsystems which
>> > need that should use other facilities like poll()-able sysfs file or
>> > any other subscription-based, client-tracking interface which does not
>> > cause overhead if it isn't used. Uevents are not the right thing to
>> > use here, and upstream udev should not paper-over broken kernel
>> > subsystems."
>
> True.
>
> Now, let's take a look at reality: should you poll()/select() on a sysfs
> node that doesn't suport it, it will wait until the poll/select timeout
> happens (or EINTR happens), and userspace has absolutely NO way to detect
> whether a sysfs node has poll/select support.
>
> What happens if the sysfs interface did not provide poll/select support
> since day one, but rather added it later? Nobody will use it for a *long*
> time, if ever... unless you actually took pains to version the sysfs
> interface, and people actually care.
>
>> 'thinkpad_acpi.c' uses the 'BACKLIGHT_UPDATE_SYSFS'.
>> Henrique, can we remove it?
>
> Can't you fix this by rate-limiting, or otherwise adding an attribute that
> backlight devices should set when they need to supress change events?
other way is that just remove sysfs node store update then you can use
current API, force_update as is.
are there any other good ideas?
Thank you,
Kyungmin Park
>
> Is there a proper on-screen-display support path for the backlight class
> nowadays? Otherwise, you'd be removing the only way userspace ever had to
> do proper OSD of backlight changes...
>
> --
> "One disk to rule them all, One disk to find them. One disk to bring
> them all and in the darkness grind them. In the Land of Redmond
> where the shadows lie." -- The Silicon Valley Tarot
> Henrique Holschuh
^ permalink raw reply
* Re: [PATCH] video: backlight: Remove backlight sysfs uevent
From: Kay Sievers @ 2013-11-12 1:19 UTC (permalink / raw)
To: Henrique de Moraes Holschuh
Cc: Jingoo Han, Kyungmin Park, Henrique de Moraes Holschuh,
linux-fbdev, LKML, Richard Purdie, ibm-acpi-devel,
platform-driver-x86
In-Reply-To: <20131112005628.GA2914@khazad-dum.debian.net>
On Tue, Nov 12, 2013 at 1:56 AM, Henrique de Moraes Holschuh
<hmh@hmh.eng.br> wrote:
> On Tue, 12 Nov 2013, Jingoo Han wrote:
>> On Tuesday, November 12, 2013 8:57 AM, Kyungmin Park wrote:
>> > From: Kyungmin Park <kyungmin.park@samsung.com>
>> >
>> > The most mobile phones have Ambient Light Sensors and it changes brightness according lux.
>> > It means it changes backlight brightness frequently by just writing sysfs node, so it generates uevent.
>> >
>> > Usually there's no user to use this backlight changes. But it forks udev worker threads and it takes
>> > about 5ms. The main problem is that it hurts other process activities. so remove it.
>> >
>> > Kay said
>> > "Uevents are for the major, low-frequent, global device state-changes,
>> > not for carrying-out any sort of measurement data. Subsystems which
>> > need that should use other facilities like poll()-able sysfs file or
>> > any other subscription-based, client-tracking interface which does not
>> > cause overhead if it isn't used. Uevents are not the right thing to
>> > use here, and upstream udev should not paper-over broken kernel
>> > subsystems."
>
> True.
>
> Now, let's take a look at reality: should you poll()/select() on a sysfs
> node that doesn't suport it, it will wait until the poll/select timeout
> happens (or EINTR happens), and userspace has absolutely NO way to detect
> whether a sysfs node has poll/select support.
>
> What happens if the sysfs interface did not provide poll/select support
> since day one, but rather added it later? Nobody will use it for a *long*
> time, if ever... unless you actually took pains to version the sysfs
> interface, and people actually care.
If that's an issue, we can add a new "event" file, just for that.
>> 'thinkpad_acpi.c' uses the 'BACKLIGHT_UPDATE_SYSFS'.
>> Henrique, can we remove it?
>
> Can't you fix this by rate-limiting, or otherwise adding an attribute that
> backlight devices should set when they need to supress change events?
Yeah, great idea, fix a bad hack with another bad one on top. :)
Passing measurement data through uevents is just an utterly broken
idea which cannot be fixed.
> Is there a proper on-screen-display support path for the backlight class
> nowadays? Otherwise, you'd be removing the only way userspace ever had to
> do proper OSD of backlight changes...
OSD drawing and event sounds usually happen as a fedback for
keypresses of brightness control, it would be weird to show up when
something else, like a light-sensor, adjusts the brightness in the
background.
Anyway, there might be the need for coordination and a new interface,
but uevents for measurement data need to die entirely; they make no
sense, never made any; and the sooner they are gone the better.
Kay
^ permalink raw reply
* Re: [PATCH] video: backlight: Remove backlight sysfs uevent
From: Kyungmin Park @ 2013-11-12 2:08 UTC (permalink / raw)
To: Kay Sievers
Cc: Henrique de Moraes Holschuh, Jingoo Han,
Henrique de Moraes Holschuh, linux-fbdev, LKML, Richard Purdie,
ibm-acpi-devel, platform-driver-x86
In-Reply-To: <CAPXgP11oHZXbzCt72yutmeF-P=GudzPb9whTpWe5n9LDqOMM+g@mail.gmail.com>
On Tue, Nov 12, 2013 at 10:19 AM, Kay Sievers <kay@vrfy.org> wrote:
> On Tue, Nov 12, 2013 at 1:56 AM, Henrique de Moraes Holschuh
> <hmh@hmh.eng.br> wrote:
>> On Tue, 12 Nov 2013, Jingoo Han wrote:
>>> On Tuesday, November 12, 2013 8:57 AM, Kyungmin Park wrote:
>>> > From: Kyungmin Park <kyungmin.park@samsung.com>
>>> >
>>> > The most mobile phones have Ambient Light Sensors and it changes brightness according lux.
>>> > It means it changes backlight brightness frequently by just writing sysfs node, so it generates uevent.
>>> >
>>> > Usually there's no user to use this backlight changes. But it forks udev worker threads and it takes
>>> > about 5ms. The main problem is that it hurts other process activities. so remove it.
>>> >
>>> > Kay said
>>> > "Uevents are for the major, low-frequent, global device state-changes,
>>> > not for carrying-out any sort of measurement data. Subsystems which
>>> > need that should use other facilities like poll()-able sysfs file or
>>> > any other subscription-based, client-tracking interface which does not
>>> > cause overhead if it isn't used. Uevents are not the right thing to
>>> > use here, and upstream udev should not paper-over broken kernel
>>> > subsystems."
>>
>> True.
>>
>> Now, let's take a look at reality: should you poll()/select() on a sysfs
>> node that doesn't suport it, it will wait until the poll/select timeout
>> happens (or EINTR happens), and userspace has absolutely NO way to detect
>> whether a sysfs node has poll/select support.
>>
>> What happens if the sysfs interface did not provide poll/select support
>> since day one, but rather added it later? Nobody will use it for a *long*
>> time, if ever... unless you actually took pains to version the sysfs
>> interface, and people actually care.
>
> If that's an issue, we can add a new "event" file, just for that.
>
>>> 'thinkpad_acpi.c' uses the 'BACKLIGHT_UPDATE_SYSFS'.
>>> Henrique, can we remove it?
>>
>> Can't you fix this by rate-limiting, or otherwise adding an attribute that
>> backlight devices should set when they need to supress change events?
>
> Yeah, great idea, fix a bad hack with another bad one on top. :)
> Passing measurement data through uevents is just an utterly broken
> idea which cannot be fixed.
>
>> Is there a proper on-screen-display support path for the backlight class
>> nowadays? Otherwise, you'd be removing the only way userspace ever had to
>> do proper OSD of backlight changes...
>
> OSD drawing and event sounds usually happen as a fedback for
> keypresses of brightness control, it would be weird to show up when
> something else, like a light-sensor, adjusts the brightness in the
> background.
>
> Anyway, there might be the need for coordination and a new interface,
> but uevents for measurement data need to die entirely; they make no
> sense, never made any; and the sooner they are gone the better.
Now power_supply, especially battery uses this scheme. it passes
battery data using uevent.
do you have any idea to kill it?
Thank you,
Kyungmin Park
^ permalink raw reply
* Re: [PATCH] video: backlight: Remove backlight sysfs uevent
From: Kay Sievers @ 2013-11-12 2:22 UTC (permalink / raw)
To: Kyungmin Park
Cc: Henrique de Moraes Holschuh, Jingoo Han,
Henrique de Moraes Holschuh, linux-fbdev, LKML, Richard Purdie,
ibm-acpi-devel, platform-driver-x86
In-Reply-To: <CAH9JG2VuqQoo3Xv9ED94w34Te97hmz-4tNxUQdbBJTLMM4OLOg@mail.gmail.com>
On Tue, Nov 12, 2013 at 3:08 AM, Kyungmin Park <kmpark@infradead.org> wrote:
> On Tue, Nov 12, 2013 at 10:19 AM, Kay Sievers <kay@vrfy.org> wrote:
>> On Tue, Nov 12, 2013 at 1:56 AM, Henrique de Moraes Holschuh
>> <hmh@hmh.eng.br> wrote:
>>> On Tue, 12 Nov 2013, Jingoo Han wrote:
>>>> On Tuesday, November 12, 2013 8:57 AM, Kyungmin Park wrote:
>>>> > From: Kyungmin Park <kyungmin.park@samsung.com>
>>>> >
>>>> > The most mobile phones have Ambient Light Sensors and it changes brightness according lux.
>>>> > It means it changes backlight brightness frequently by just writing sysfs node, so it generates uevent.
>>>> >
>>>> > Usually there's no user to use this backlight changes. But it forks udev worker threads and it takes
>>>> > about 5ms. The main problem is that it hurts other process activities. so remove it.
>>>> >
>>>> > Kay said
>>>> > "Uevents are for the major, low-frequent, global device state-changes,
>>>> > not for carrying-out any sort of measurement data. Subsystems which
>>>> > need that should use other facilities like poll()-able sysfs file or
>>>> > any other subscription-based, client-tracking interface which does not
>>>> > cause overhead if it isn't used. Uevents are not the right thing to
>>>> > use here, and upstream udev should not paper-over broken kernel
>>>> > subsystems."
>>>
>>> True.
>>>
>>> Now, let's take a look at reality: should you poll()/select() on a sysfs
>>> node that doesn't suport it, it will wait until the poll/select timeout
>>> happens (or EINTR happens), and userspace has absolutely NO way to detect
>>> whether a sysfs node has poll/select support.
>>>
>>> What happens if the sysfs interface did not provide poll/select support
>>> since day one, but rather added it later? Nobody will use it for a *long*
>>> time, if ever... unless you actually took pains to version the sysfs
>>> interface, and people actually care.
>>
>> If that's an issue, we can add a new "event" file, just for that.
>>
>>>> 'thinkpad_acpi.c' uses the 'BACKLIGHT_UPDATE_SYSFS'.
>>>> Henrique, can we remove it?
>>>
>>> Can't you fix this by rate-limiting, or otherwise adding an attribute that
>>> backlight devices should set when they need to supress change events?
>>
>> Yeah, great idea, fix a bad hack with another bad one on top. :)
>> Passing measurement data through uevents is just an utterly broken
>> idea which cannot be fixed.
>>
>>> Is there a proper on-screen-display support path for the backlight class
>>> nowadays? Otherwise, you'd be removing the only way userspace ever had to
>>> do proper OSD of backlight changes...
>>
>> OSD drawing and event sounds usually happen as a fedback for
>> keypresses of brightness control, it would be weird to show up when
>> something else, like a light-sensor, adjusts the brightness in the
>> background.
>>
>> Anyway, there might be the need for coordination and a new interface,
>> but uevents for measurement data need to die entirely; they make no
>> sense, never made any; and the sooner they are gone the better.
>
> Now power_supply, especially battery uses this scheme. it passes
> battery data using uevent.
> do you have any idea to kill it?
It should be removed too, the same applies to power_supply as to everything
else; uevents are a broken interface for any kind of device data which
is not meant as a trigger to re-configure the device itself.
But power_supply events are at least not as unfixable as backlight,
the number of events can be kept relatively low during normal
operation. So it can happen after the backlight thing is sorted out.
Note: The same rule as for generating uevents applies also to device
properties exported in the environment too; measurement data has no
place there. Reading the "uevent" file of a battery in sysfs (we need to
do that at bootup) sometimes synchronously blocks 1 second to return,
just because it tries to add measurement data reading it live from the
hardware to add it to the event itself.
Kay
^ permalink raw reply
* [PATCH 1/5] arm: sa1100: add cpu clock
From: Dmitry Eremin-Solenikov @ 2013-11-12 3:32 UTC (permalink / raw)
To: linux-arm-kernel
Both SA1100 framebuffer and PCMCIA drivers require knowledge of cpu
frequency to correctly program timings. Currently they receive timing
information by calling cpufreq_get(0). However if cpu frequency driver
is not enabled (e.g. due to unsupported DRAM chip/board on sa1110)
cpufreq_get(0) returns 0, causing incorrect timings to be programmed.
Add cpu clock returning cpu frequency, to be used by sa11x0 fb and
pcmcia drivers.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
arch/arm/mach-sa1100/clock.c | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/mach-sa1100/clock.c b/arch/arm/mach-sa1100/clock.c
index 172ebd0..abf1dc1 100644
--- a/arch/arm/mach-sa1100/clock.c
+++ b/arch/arm/mach-sa1100/clock.c
@@ -15,10 +15,12 @@
#include <linux/clkdev.h>
#include <mach/hardware.h>
+#include <mach/generic.h>
struct clkops {
void (*enable)(struct clk *);
void (*disable)(struct clk *);
+ unsigned long (*get_rate)(struct clk *);
};
struct clk {
@@ -51,6 +53,19 @@ static void clk_gpio27_disable(struct clk *clk)
GAFR &= ~GPIO_32_768kHz;
}
+static void clk_cpu_enable(struct clk *clk)
+{
+}
+
+static void clk_cpu_disable(struct clk *clk)
+{
+}
+
+static unsigned long clk_cpu_get_rate(struct clk *clk)
+{
+ return sa11x0_getspeed(0) * 1000;
+}
+
int clk_enable(struct clk *clk)
{
unsigned long flags;
@@ -80,16 +95,35 @@ void clk_disable(struct clk *clk)
}
EXPORT_SYMBOL(clk_disable);
+unsigned long clk_get_rate(struct clk *clk)
+{
+ if (clk && clk->ops && clk->ops->get_rate)
+ return clk->ops->get_rate(clk);
+ else
+ return 0;
+}
+EXPORT_SYMBOL(clk_get_rate);
+
const struct clkops clk_gpio27_ops = {
.enable = clk_gpio27_enable,
.disable = clk_gpio27_disable,
};
+const struct clkops clk_cpu_ops = {
+ .enable = clk_cpu_enable,
+ .disable = clk_cpu_disable,
+ .get_rate = clk_cpu_get_rate,
+};
+
static DEFINE_CLK(gpio27, &clk_gpio27_ops);
+static DEFINE_CLK(cpu, &clk_cpu_ops);
+
static struct clk_lookup sa11xx_clkregs[] = {
CLKDEV_INIT("sa1111.0", NULL, &clk_gpio27),
CLKDEV_INIT("sa1100-rtc", NULL, NULL),
+ CLKDEV_INIT("sa11x0-fb", NULL, &clk_cpu),
+ CLKDEV_INIT("sa11x0-pcmcia", NULL, &clk_cpu),
};
static int __init sa11xx_clk_init(void)
--
1.8.4.2
^ permalink raw reply related
* [PATCH 2/5] fbdev: sa1100fb: make use of device clock
From: Dmitry Eremin-Solenikov @ 2013-11-12 3:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1384227132-10501-1-git-send-email-dbaryshkov@gmail.com>
Use per-device clock (instead of calling cpufreq_get(0), which can
return 0 if no cpu frequency driver is selected) to program timings.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
drivers/video/sa1100fb.c | 24 +++++++++++++++++-------
drivers/video/sa1100fb.h | 1 +
2 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/video/sa1100fb.c b/drivers/video/sa1100fb.c
index de76da0..05d1b37 100644
--- a/drivers/video/sa1100fb.c
+++ b/drivers/video/sa1100fb.c
@@ -178,6 +178,7 @@
#include <linux/dma-mapping.h>
#include <linux/mutex.h>
#include <linux/io.h>
+#include <linux/clk.h>
#include <video/sa1100fb.h>
@@ -413,9 +414,9 @@ sa1100fb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
var->transp.offset);
#ifdef CONFIG_CPU_FREQ
- dev_dbg(fbi->dev, "dma period = %d ps, clock = %d kHz\n",
+ dev_dbg(fbi->dev, "dma period = %d ps, clock = %ld kHz\n",
sa1100fb_display_dma_period(var),
- cpufreq_get(smp_processor_id()));
+ clk_get_rate(fbi->clk) / 1000);
#endif
return 0;
@@ -586,9 +587,10 @@ static struct fb_ops sa1100fb_ops = {
* Calculate the PCD value from the clock rate (in picoseconds).
* We take account of the PPCR clock setting.
*/
-static inline unsigned int get_pcd(unsigned int pixclock, unsigned int cpuclock)
+static inline unsigned int get_pcd(struct sa1100fb_info *fbi,
+ unsigned int pixclock)
{
- unsigned int pcd = cpuclock / 100;
+ unsigned int pcd = clk_get_rate(fbi->clk) / 100 / 1000;
pcd *= pixclock;
pcd /= 10000000;
@@ -667,7 +669,7 @@ static int sa1100fb_activate_var(struct fb_var_screeninfo *var, struct sa1100fb_
LCCR2_BegFrmDel(var->upper_margin) +
LCCR2_EndFrmDel(var->lower_margin);
- pcd = get_pcd(var->pixclock, cpufreq_get(0));
+ pcd = get_pcd(fbi, var->pixclock);
new_regs.lccr3 = LCCR3_PixClkDiv(pcd) | fbi->inf->lccr3 |
(var->sync & FB_SYNC_HOR_HIGH_ACT ? LCCR3_HorSnchH : LCCR3_HorSnchL) |
(var->sync & FB_SYNC_VERT_HIGH_ACT ? LCCR3_VrtSnchH : LCCR3_VrtSnchL);
@@ -1003,7 +1005,6 @@ sa1100fb_freq_transition(struct notifier_block *nb, unsigned long val,
void *data)
{
struct sa1100fb_info *fbi = TO_INF(nb, freq_transition);
- struct cpufreq_freqs *f = data;
u_int pcd;
switch (val) {
@@ -1012,7 +1013,7 @@ sa1100fb_freq_transition(struct notifier_block *nb, unsigned long val,
break;
case CPUFREQ_POSTCHANGE:
- pcd = get_pcd(fbi->fb.var.pixclock, f->new);
+ pcd = get_pcd(fbi, fbi->fb.var.pixclock);
fbi->reg_lccr3 = (fbi->reg_lccr3 & ~0xff) | LCCR3_PixClkDiv(pcd);
set_ctrlr_state(fbi, C_ENABLE_CLKCHANGE);
break;
@@ -1219,6 +1220,13 @@ static int sa1100fb_probe(struct platform_device *pdev)
if (!fbi)
goto failed;
+ fbi->clk = clk_get(&pdev->dev, NULL);
+ if (IS_ERR(fbi->clk)) {
+ ret = PTR_ERR(fbi->clk);
+ fbi->clk = NULL;
+ goto failed;
+ }
+
fbi->base = ioremap(res->start, resource_size(res));
if (!fbi->base)
goto failed;
@@ -1271,6 +1279,8 @@ static int sa1100fb_probe(struct platform_device *pdev)
failed:
if (fbi)
iounmap(fbi->base);
+ if (fbi->clk)
+ clk_put(fbi->clk);
kfree(fbi);
release_mem_region(res->start, resource_size(res));
return ret;
diff --git a/drivers/video/sa1100fb.h b/drivers/video/sa1100fb.h
index fc5d429..0139d13 100644
--- a/drivers/video/sa1100fb.h
+++ b/drivers/video/sa1100fb.h
@@ -68,6 +68,7 @@ struct sa1100fb_info {
#endif
const struct sa1100fb_mach_info *inf;
+ struct clk *clk;
};
#define TO_INF(ptr,member) container_of(ptr,struct sa1100fb_info,member)
--
1.8.4.2
^ permalink raw reply related
* [PATCH 3/5] pcmcia: sa1100: make use of device clock
From: Dmitry Eremin-Solenikov @ 2013-11-12 3:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1384227132-10501-1-git-send-email-dbaryshkov@gmail.com>
Use per-device clock (instead of calling cpufreq_get(0), which can
return 0 if no cpu frequency driver is selected) to program timings.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
drivers/pcmcia/sa1100_generic.c | 1 +
drivers/pcmcia/sa11xx_base.c | 14 ++++++++++++--
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/pcmcia/sa1100_generic.c b/drivers/pcmcia/sa1100_generic.c
index ff8a027..d2ab060 100644
--- a/drivers/pcmcia/sa1100_generic.c
+++ b/drivers/pcmcia/sa1100_generic.c
@@ -93,6 +93,7 @@ static int sa11x0_drv_pcmcia_remove(struct platform_device *dev)
for (i = 0; i < sinfo->nskt; i++)
soc_pcmcia_remove_one(&sinfo->skt[i]);
+ clk_put(sinfo->clk);
kfree(sinfo);
return 0;
}
diff --git a/drivers/pcmcia/sa11xx_base.c b/drivers/pcmcia/sa11xx_base.c
index 6eecd7c..aef0e69 100644
--- a/drivers/pcmcia/sa11xx_base.c
+++ b/drivers/pcmcia/sa11xx_base.c
@@ -38,6 +38,7 @@
#include <linux/spinlock.h>
#include <linux/io.h>
#include <linux/slab.h>
+#include <linux/clk.h>
#include <mach/hardware.h>
#include <asm/irq.h>
@@ -138,14 +139,15 @@ sa1100_pcmcia_frequency_change(struct soc_pcmcia_socket *skt,
static int
sa1100_pcmcia_set_timing(struct soc_pcmcia_socket *skt)
{
- return sa1100_pcmcia_set_mecr(skt, cpufreq_get(0));
+ unsigned long clk = clk_get_rate(skt->clk);
+ return sa1100_pcmcia_set_mecr(skt, clk / 1000);
}
static int
sa1100_pcmcia_show_timing(struct soc_pcmcia_socket *skt, char *buf)
{
struct soc_pcmcia_timing timing;
- unsigned int clock = cpufreq_get(0);
+ unsigned int clock = clk_get_rate(skt->clk);
unsigned long mecr = MECR;
char *p = buf;
@@ -221,6 +223,11 @@ int sa11xx_drv_pcmcia_probe(struct device *dev, struct pcmcia_low_level *ops,
struct skt_dev_info *sinfo;
struct soc_pcmcia_socket *skt;
int i, ret = 0;
+ struct clk *clk;
+
+ clk = clk_get(dev, NULL);
+ if (IS_ERR(clk))
+ return -ENODEV;
sa11xx_drv_pcmcia_ops(ops);
@@ -229,12 +236,14 @@ int sa11xx_drv_pcmcia_probe(struct device *dev, struct pcmcia_low_level *ops,
return -ENOMEM;
sinfo->nskt = nr;
+ sinfo->clk = clk;
/* Initialize processor specific parameters */
for (i = 0; i < nr; i++) {
skt = &sinfo->skt[i];
skt->nr = first + i;
+ skt->clk = clk;
soc_pcmcia_init_one(skt, ops, dev);
ret = sa11xx_drv_pcmcia_add_one(skt);
@@ -245,6 +254,7 @@ int sa11xx_drv_pcmcia_probe(struct device *dev, struct pcmcia_low_level *ops,
if (ret) {
while (--i >= 0)
soc_pcmcia_remove_one(&sinfo->skt[i]);
+ clk_put(clk);
kfree(sinfo);
} else {
dev_set_drvdata(dev, sinfo);
--
1.8.4.2
^ permalink raw reply related
* [PATCH 4/5] arm: sa1100: add a clock alias for sa1111 pcmcia device
From: Dmitry Eremin-Solenikov @ 2013-11-12 3:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1384227132-10501-1-git-send-email-dbaryshkov@gmail.com>
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
arch/arm/mach-sa1100/clock.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-sa1100/clock.c b/arch/arm/mach-sa1100/clock.c
index abf1dc1..cd4762d 100644
--- a/arch/arm/mach-sa1100/clock.c
+++ b/arch/arm/mach-sa1100/clock.c
@@ -124,6 +124,7 @@ static struct clk_lookup sa11xx_clkregs[] = {
CLKDEV_INIT("sa1100-rtc", NULL, NULL),
CLKDEV_INIT("sa11x0-fb", NULL, &clk_cpu),
CLKDEV_INIT("sa11x0-pcmcia", NULL, &clk_cpu),
+ CLKDEV_INIT("1600", NULL, &clk_cpu), /* sa1111 pcmcia */
};
static int __init sa11xx_clk_init(void)
--
1.8.4.2
^ permalink raw reply related
* [PATCH 5/5] pcmcia: sa1111: make use of device clock
From: Dmitry Eremin-Solenikov @ 2013-11-12 3:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1384227132-10501-1-git-send-email-dbaryshkov@gmail.com>
Use per-device clock (instead of calling cpufreq_get(0), which can
return 0 if no cpu frequency driver is selected) to program timings.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
drivers/pcmcia/sa1111_generic.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/pcmcia/sa1111_generic.c b/drivers/pcmcia/sa1111_generic.c
index 65b02c3..c5988be 100644
--- a/drivers/pcmcia/sa1111_generic.c
+++ b/drivers/pcmcia/sa1111_generic.c
@@ -145,6 +145,9 @@ int sa1111_pcmcia_add(struct sa1111_dev *dev, struct pcmcia_low_level *ops,
return -ENOMEM;
s->soc.nr = ops->first + i;
+ s->soc.clk = clk_get(&dev->dev, NULL);
+ if (IS_ERR(s->soc.clk))
+ return -ENODEV;
soc_pcmcia_init_one(&s->soc, ops, &dev->dev);
s->dev = dev;
if (s->soc.nr) {
@@ -220,6 +223,7 @@ static int pcmcia_remove(struct sa1111_dev *dev)
for (; s; s = next) {
next = s->next;
soc_pcmcia_remove_one(&s->soc);
+ clk_put(s->soc.clk);
kfree(s);
}
--
1.8.4.2
^ permalink raw reply related
* [PATCH v2] video: backlight: Remove backlight sysfs uevent
From: Kyungmin Park @ 2013-11-12 3:39 UTC (permalink / raw)
To: Richard Purdie, Jingoo Han; +Cc: linux-fbdev, linux-kernel, kay
From: Kyungmin Park <kyungmin.park@samsung.com>
The most mobile phones have Ambient Light Sensors and it changes brightness according lux.
It means it changes backlight brightness frequently by just writing sysfs node, so it generates uevent.
Usually there's no user to use this backlight changes. But it forks udev worker threads and it takes about 5ms. The main problem is that it hurts other process activities. so remove it.
Kay said
"Uevents are for the major, low-frequent, global device state-changes,
not for carrying-out any sort of measurement data. Subsystems which
need that should use other facilities like poll()-able sysfs file or
any other subscription-based, client-tracking interface which does not
cause overhead if it isn't used. Uevents are not the right thing to
use here, and upstream udev should not paper-over broken kernel
subsystems."
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
v1: there's still user to use BACKLIGHT_UPDATE_SYSFS. so just remove store sysfs node uevent
---
diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
index 94a403a..292cf99 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -172,8 +172,6 @@ static ssize_t brightness_store(struct device *dev,
}
mutex_unlock(&bd->ops_lock);
- backlight_generate_event(bd, BACKLIGHT_UPDATE_SYSFS);
-
return rc;
}
static DEVICE_ATTR_RW(brightness);
^ permalink raw reply related
* Re: [PATCH 1/5] arm: sa1100: add cpu clock
From: Russell King - ARM Linux @ 2013-11-12 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1384227132-10501-1-git-send-email-dbaryshkov@gmail.com>
On Tue, Nov 12, 2013 at 07:32:08AM +0400, Dmitry Eremin-Solenikov wrote:
> Both SA1100 framebuffer and PCMCIA drivers require knowledge of cpu
> frequency to correctly program timings. Currently they receive timing
> information by calling cpufreq_get(0). However if cpu frequency driver
> is not enabled (e.g. due to unsupported DRAM chip/board on sa1110)
> cpufreq_get(0) returns 0, causing incorrect timings to be programmed.
I added a select statement back in 1937f5b91833e2e8e53bcc821fc7a5fbe6ccb9b5
which avoids this problem. Does this not work?
^ permalink raw reply
* Re: [PATCH 1/5] arm: sa1100: add cpu clock
From: Dmitry Eremin-Solenikov @ 2013-11-12 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20131112095706.GE16735@n2100.arm.linux.org.uk>
On 11/12/2013 01:57 PM, Russell King - ARM Linux wrote:
> On Tue, Nov 12, 2013 at 07:32:08AM +0400, Dmitry Eremin-Solenikov wrote:
>> Both SA1100 framebuffer and PCMCIA drivers require knowledge of cpu
>> frequency to correctly program timings. Currently they receive timing
>> information by calling cpufreq_get(0). However if cpu frequency driver
>> is not enabled (e.g. due to unsupported DRAM chip/board on sa1110)
>> cpufreq_get(0) returns 0, causing incorrect timings to be programmed.
>
> I added a select statement back in 1937f5b91833e2e8e53bcc821fc7a5fbe6ccb9b5
> which avoids this problem. Does this not work?
No, it does not.
1) For collie (sa1110) we don't have dram chip timings in table, so the
cpufreq driver is not registered and cpufreq_get() returns 0
2) What if I want to build a kernel w/o cpu freq? We have clocks exactly
for this reasons - to let drivers get frequency information.
3) And last but not least - PXA uses clocks in this place.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 4/5] arm: sa1100: add a clock alias for sa1111 pcmcia device
From: Dmitry Artamonow @ 2013-11-12 12:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1384227132-10501-4-git-send-email-dbaryshkov@gmail.com>
12.11.2013 07:32, Dmitry Eremin-Solenikov wrote:
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> ---
> arch/arm/mach-sa1100/clock.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-sa1100/clock.c b/arch/arm/mach-sa1100/clock.c
> index abf1dc1..cd4762d 100644
> --- a/arch/arm/mach-sa1100/clock.c
> +++ b/arch/arm/mach-sa1100/clock.c
> @@ -124,6 +124,7 @@ static struct clk_lookup sa11xx_clkregs[] = {
> CLKDEV_INIT("sa1100-rtc", NULL, NULL),
> CLKDEV_INIT("sa11x0-fb", NULL, &clk_cpu),
> CLKDEV_INIT("sa11x0-pcmcia", NULL, &clk_cpu),
> + CLKDEV_INIT("1600", NULL, &clk_cpu), /* sa1111 pcmcia */
Shouldn't it be "1800" here? As I can see device name for sa1111 devices is
initialized from offset in sa1111_init_one_child():
dev_set_name(&dev->dev, "%4.4lx", info->offset);
And the offset for SA1111_PCMCIA is 0x1800:
{
.offset = 0x1800,
.skpcr_mask = 0,
.devid = SA1111_DEVID_PCMCIA,
.irq = {
IRQ_S0_READY_NINT,
IRQ_S0_CD_VALID,
IRQ_S0_BVD1_STSCHG,
IRQ_S1_READY_NINT,
IRQ_S1_CD_VALID,
IRQ_S1_BVD1_STSCHG,
},
},
Also it would be nice if you could add some words about this strange
sa1111 device
naming convention in commit changelog. It's really puzzling to see
string like
"1600" in clock's devid.
--
Best regards,
Dmitry
^ permalink raw reply
* [GIT PULL] fbdev changes for 3.13
From: Tomi Valkeinen @ 2013-11-13 12:08 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-fbdev, linux-kernel, Jean-Christophe PLAGNIOL-VILLARD
[-- Attachment #1: Type: text/plain, Size: 21565 bytes --]
Hi Linus,
The following changes since commit 272b98c6455f00884f0350f775c5342358ebb73f:
Linux 3.12-rc1 (2013-09-16 16:17:51 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git tags/fbdev-3.13
for you to fetch changes up to 3a41c5dbe8bc396a7fb16ca8739e945bb003342e:
fb: reorder the lock sequence to fix potential dead lock (2013-11-11 15:52:59 +0200)
----------------------------------------------------------------
fbdev changes for 3.13
Nothing particularly stands out in this pull request. The biggest part of the
changes are cleanups.
Maybe one fix to mention is the "fb: reorder the lock sequence to fix potential
dead lock" which hopefully fixes the fb locking issues reported by multiple
persons.
There are also a few commits that have changes to arch/arm/mach-at91 and
arch/avr32, which have been acked by the maintainers.
----------------------------------------------------------------
Archit Taneja (10):
omapdss: HDMI: create a Wrapper library
omapdss: HDMI: create a PLL library
omapdss: HDMI: create a PHY library
omapdss: HDMI: Use OMAP4 HDMI core functions directly and remove hdmi_ip_ops
omapdss: HDMI: remove hdmi_ip_data struct
omapdss: HDMI: Clean up the header files
omapdss: HDMI: add HDMI wrapper IRQ flags
omapdss: HDMI: Rename hdmi driver files to nicer names
omapdss: OMAP4: HDMI: remove unnecessary edid macros
omapdss: HDMI: move common functions to a separate file
David Herrmann (2):
simplefb: fix unmapping fb during destruction
simplefb: use write-combined remapping
Gerd Hoffmann (2):
hyperv-fb: add pci stub
hyperv-fb: add blanking support
Gu Zheng (1):
fb: reorder the lock sequence to fix potential dead lock
Guoqing Li (2):
video: mmp: rb swap setting update for mmp display
video: mmp: optimize some register setting code
Hanjun Guo (10):
Video / hecubafb: Use module_platform_driver() to simplify code
Video / bfin-t350mcqb-fb: Use module_platform_driver() to simplify code
Video / metronomefb: Use module_platform_driver() to simplify code
Video / jz4740_fb: Use module_platform_driver() to simplify code
Video / da8xx-fb: Use module_platform_driver() to simplify code
Video / cobalt_lcdfb: Use module_platform_driver() to simplify code
Video / broadsheetfb: Use module_platform_driver() to simplify code
Video / bf54x-lq043fb: Use module_platform_driver() to simplify code
Video / au1200fb: Use module_platform_driver() to simplify code
Video / au1100fb: Use module_platform_driver() to simplify code
James Bates (1):
efifb: prevent null-deref when iterating dmi_list
Jean-Christophe PLAGNIOL-VILLARD (4):
video: atmel_lcdfb: fix platform data struct
video: atmel_lcdfb: introduce atmel_lcdfb_power_control
video: atmel_lcdfb: pass the pdata as params
video: atmel_lcdfb: add device tree suport
Jett.Zhou (1):
ARM: mmp: remove the legacy rbswap setting for ttc_dkb platform
Jing Xiang (2):
video: mmp: calculate pitch value when fb set win
video: mmp: add pitch info in mmp_win structure
Jingoo Han (41):
video: au1100fb: Remove casting the return value which is a void pointer
video: arkfb: remove unnecessary pci_set_drvdata()
video: carminefb: remove unnecessary pci_set_drvdata()
video: cirrusfb: remove unnecessary pci_set_drvdata()
video: cyber2000fb: remove unnecessary pci_set_drvdata()
video: lxfb: remove unnecessary pci_set_drvdata()
video: gx1fb: remove unnecessary pci_set_drvdata()
video: gxfb: remove unnecessary pci_set_drvdata()
video: i740fb: remove unnecessary pci_set_drvdata()
video: i810fb: remove unnecessary pci_set_drvdata()
video: intelfb: remove unnecessary pci_set_drvdata()
video: kyrofb: remove unnecessary pci_set_drvdata()
video: mb862xxfb: remove unnecessary pci_set_drvdata()
video: neofb: remove unnecessary pci_set_drvdata()
video: pm2fb: remove unnecessary pci_set_drvdata()
video: pm3fb: remove unnecessary pci_set_drvdata()
video: s3fb: remove unnecessary pci_set_drvdata()
video: savagefb: remove unnecessary pci_set_drvdata()
video: sisfb: remove unnecessary pci_set_drvdata()
video: tdfxfb: remove unnecessary pci_set_drvdata()
video: tridentfb: remove unnecessary pci_set_drvdata()
video: vt8623fb: remove unnecessary pci_set_drvdata()
video: atmel_lcdfb: use dev_get_platdata()
video: mx3fb: use dev_get_platdata()
video: nuc900fb: use dev_get_platdata()
video: omapfb: use dev_get_platdata()
video: pxa168fb: use dev_get_platdata()
video: pxafb: use dev_get_platdata()
video: s3c2410: use dev_get_platdata()
video: sa1100fb: use dev_get_platdata()
video: sh_mobile_hdmi: use dev_get_platdata()
video: amba-clcd: use dev_get_platdata()
video: da8xx-fb: use dev_get_platdata()
video: ep93xx-fb: use dev_get_platdata()
video: imxfb: use dev_get_platdata()
video: mbxfb: use dev_get_platdata()
video: s1d13xxxfb: use dev_get_platdata()
video: s3c-fb: use dev_get_platdata()
video: simplefb: use dev_get_platdata()
video: tmiofb: use dev_get_platdata()
video: w100fb: use dev_get_platdata()
Joe Perches (4):
framebuffer: arkfb: Fix framebugger typo
framebuffer: Add fb_<level> convenience logging macros
framebuffer: Use fb_<level>
video: Remove unnecessary semicolons
Jon Mason (2):
aty128fb: Use pci_dev pm_cap
radeonfb: Use pci_dev pm_cap
Lars-Peter Clausen (2):
video: jz4740-fb: Fix LCD_CMD bit definitions
video: jz4740-fb: Use clk_prepare_enable/clk_disable_unprepare
Laurent Pinchart (2):
fbdev: shmobile-hdmi: Convert to clk_prepare/unprepare
fbdev: shmobile-lcdcfb: Convert to clk_prepare/unprepare
Manish Badarkhe (1):
video: da8xx-fb: remove unwanted define
Marek Belisko (1):
omapdss: Add new panel driver for Topolly td028ttec1 LCD.
Michal Simek (4):
video: amba-clcd: Remove unnecessary amba_set_drvdata()
video: xilinxfb: Use standard variable name convention
video: xilinxfb: Use devm_kzalloc instead of kzalloc
video: xilinxfb: Simplify error path
Peter Huewe (1):
video/matrox/matroxfb_maven: Use module_i2c_driver to register driver
Peter Senna Tschudin (1):
OMAPDSS: DISPC: Fix assignment of 0/1 to bool variables
Ricardo Neri (7):
OMAPDSS: HDMI: OMAP4: Complete register definitions for wrapper
OMAPDSS: HDMI: OMAP4: Complete dumping of wrapper registers
OMAPDSS: HDMI: OMAP4: Complete register definitions for DPLL
OMAPDSS: HDMI: OMAP4: Complete dumping of DPLL registers
OMAPDSS: HDMI: OMAP4: Rename the HDMI_CORE_CTRL1 register
OMAPDSS: HDMI: OMAP4: Complete register definitions for core
OMAPDSS: HDMI: OMAP4: Complete dumping of core registers
Richard Röjfors (1):
OMAPDSS: HDMI: Correctly compare timings
Roel Kluin (1):
OMAPDSS: Fix de_level in videomode_to_omap_video_timings()
Sachin Kamat (33):
video: grvga: Use module_platform_driver
backlight: l4f00242t03: Remove redundant spi_set_drvdata
backlight: tosa: Remove redundant spi_set_drvdata
video: udlfb: Use NULL instead of 0
video: smscufx: Use NULL instead of 0
video: da8xx-fb: Staticize reg_context
video: aty: Remove redundant break
video: kyro: Remove redundant break
video: uvesafb: Remove redundant NULL check
video: vfb: Remove incorrect check
video: cirrusfb: Remove incorrect checks
video: aty: Remove incorrect checks
video: riva: Remove incorrect checks
video: atmel_lcdfb: Remove redundant dev_set_drvdata
video: grvga: Remove redundant dev_set_drvdata
video: leo: Remove redundant dev_set_drvdata
video: mb862xx: Remove redundant dev_set_drvdata
video: amifb: Remove redundant dev_set_drvdata
video: bw2: Remove redundant dev_set_drvdata
video: cg14: Remove redundant dev_set_drvdata
video: cg3: Remove redundant dev_set_drvdata
video: cg6: Remove redundant dev_set_drvdata
video: ffb: Remove redundant dev_set_drvdata
video: p9100: Remove redundant dev_set_drvdata
video: platinumfb: Remove redundant dev_set_drvdata
video: sunxvr1000: Remove redundant dev_set_drvdata
video: tcx: Remove redundant dev_set_drvdata
video: xilinxfb: Remove redundant dev_set_drvdata
video: ssd1307fb: Remove redundant of_match_ptr
video: wm8505fb: Remove redundant of_match_ptr
video: wmt_ge_rops: Remove redundant of_match_ptr
video: wmt_ge_rops: Fix a trivial typo
video: exynos_mipi_dsi: Unlock the mutex before returning
Sangjung Woo (1):
fbdev: sh_mobile_hdmi: Use devm_kzalloc()
Stephen Rothwell (1):
video: xilinxfb: Fix for "Use standard variable name convention"
Thierry Reding (1):
radeon: Conditionally compile PM code
Tom Gundersen (1):
simplefb: print some info about the registered fb
Tomi Valkeinen (2):
OMAPDSS: DSI: fix perf measuring ifdefs
OMAPDSS: connector-dvi: fix releasing i2c_adapter
Wei Yongjun (1):
fbdev: fix error return code in metronomefb_probe()
.../devicetree/bindings/video/atmel,lcdc.txt | 75 ++
arch/arm/mach-at91/at91sam9261_devices.c | 6 +-
arch/arm/mach-at91/at91sam9263_devices.c | 6 +-
arch/arm/mach-at91/at91sam9g45_devices.c | 6 +-
arch/arm/mach-at91/at91sam9rl_devices.c | 6 +-
arch/arm/mach-at91/board-sam9261ek.c | 10 +-
arch/arm/mach-at91/board-sam9263ek.c | 6 +-
arch/arm/mach-at91/board-sam9m10g45ek.c | 4 +-
arch/arm/mach-at91/board-sam9rlek.c | 6 +-
arch/arm/mach-at91/board.h | 4 +-
arch/arm/mach-mmp/ttc_dkb.c | 4 +-
arch/avr32/boards/atngw100/evklcd10x.c | 8 +-
arch/avr32/boards/atngw100/mrmt.c | 4 +-
arch/avr32/boards/atstk1000/atstk1000.h | 2 +-
arch/avr32/boards/atstk1000/setup.c | 2 +-
arch/avr32/boards/favr-32/setup.c | 2 +-
arch/avr32/boards/hammerhead/setup.c | 2 +-
arch/avr32/boards/merisc/display.c | 2 +-
arch/avr32/boards/mimc200/setup.c | 4 +-
arch/avr32/mach-at32ap/at32ap700x.c | 8 +-
arch/avr32/mach-at32ap/include/mach/board.h | 4 +-
drivers/auxdisplay/cfag12864bfb.c | 3 +-
drivers/video/68328fb.c | 9 +-
drivers/video/Kconfig | 2 +
drivers/video/amba-clcd.c | 4 +-
drivers/video/amifb.c | 6 +-
drivers/video/arcfb.c | 8 +-
drivers/video/arkfb.c | 49 +-
drivers/video/asiliantfb.c | 4 +-
drivers/video/atafb.c | 7 +-
drivers/video/atmel_lcdfb.c | 344 ++++--
drivers/video/aty/aty128fb.c | 8 +-
drivers/video/aty/atyfb_base.c | 1 -
drivers/video/aty/radeon_base.c | 5 -
drivers/video/aty/radeon_pm.c | 22 +-
drivers/video/aty/radeonfb.h | 1 -
drivers/video/au1100fb.c | 16 +-
drivers/video/au1200fb.c | 16 +-
drivers/video/backlight/l4f00242t03.c | 1 -
drivers/video/backlight/tosa_lcd.c | 6 +-
drivers/video/bf54x-lq043fb.c | 14 +-
drivers/video/bfin-t350mcqb-fb.c | 14 +-
drivers/video/broadsheetfb.c | 19 +-
drivers/video/bw2.c | 2 -
drivers/video/carminefb.c | 4 +-
drivers/video/cfbimgblt.c | 2 +-
drivers/video/cg14.c | 6 +-
drivers/video/cg3.c | 2 -
drivers/video/cg6.c | 4 +-
drivers/video/cirrusfb.c | 6 -
drivers/video/cobalt_lcdfb.c | 17 +-
drivers/video/controlfb.c | 4 +-
drivers/video/cyber2000fb.c | 5 -
drivers/video/da8xx-fb.c | 21 +-
drivers/video/efifb.c | 7 +-
drivers/video/ep93xx-fb.c | 2 +-
drivers/video/exynos/exynos_mipi_dsi_common.c | 3 +-
drivers/video/fb-puv3.c | 5 +-
drivers/video/fbmem.c | 50 +-
drivers/video/fbsysfs.c | 19 +-
drivers/video/ffb.c | 2 -
drivers/video/fm2fb.c | 2 +-
drivers/video/fsl-diu-fb.c | 2 +-
drivers/video/gbefb.c | 6 +-
drivers/video/geode/gx1fb_core.c | 3 +-
drivers/video/geode/gxfb_core.c | 3 +-
drivers/video/geode/lxfb_core.c | 4 +-
drivers/video/grvga.c | 16 +-
drivers/video/gxt4500.c | 3 +-
drivers/video/hecubafb.c | 19 +-
drivers/video/hgafb.c | 3 +-
drivers/video/hitfb.c | 3 +-
drivers/video/hpfb.c | 3 +-
drivers/video/hyperv_fb.c | 45 +-
drivers/video/i740fb.c | 9 +-
drivers/video/i810/i810_main.c | 1 -
drivers/video/igafb.c | 5 +-
drivers/video/imsttfb.c | 4 +-
drivers/video/imxfb.c | 6 +-
drivers/video/intelfb/intelfbdrv.c | 2 -
drivers/video/jz4740_fb.c | 29 +-
drivers/video/kyro/fbdev.c | 10 +-
drivers/video/leo.c | 4 +-
drivers/video/macfb.c | 3 +-
drivers/video/matrox/matroxfb_DAC1064.c | 4 +-
drivers/video/matrox/matroxfb_Ti3026.c | 2 +-
drivers/video/matrox/matroxfb_base.c | 6 +-
drivers/video/matrox/matroxfb_maven.c | 14 +-
drivers/video/mb862xx/mb862xxfbdrv.c | 3 -
drivers/video/mbx/mbxfb.c | 4 +-
drivers/video/metronomefb.c | 17 +-
drivers/video/mmp/fb/mmpfb.c | 34 +-
drivers/video/mmp/hw/mmp_ctrl.c | 71 +-
drivers/video/mmp/hw/mmp_ctrl.h | 5 +
drivers/video/mx3fb.c | 4 +-
drivers/video/neofb.c | 9 +-
drivers/video/nuc900fb.c | 9 +-
drivers/video/nvidia/nv_hw.c | 2 +-
drivers/video/offb.c | 3 +-
drivers/video/omap/hwa742.c | 2 +-
drivers/video/omap/omapfb_main.c | 4 +-
drivers/video/omap2/displays-new/Kconfig | 6 +
drivers/video/omap2/displays-new/Makefile | 1 +
drivers/video/omap2/displays-new/connector-dvi.c | 7 +
drivers/video/omap2/displays-new/panel-dsi-cm.c | 2 +-
.../omap2/displays-new/panel-tpo-td028ttec1.c | 480 ++++++++
drivers/video/omap2/dss/Makefile | 3 +-
drivers/video/omap2/dss/core.c | 4 +-
drivers/video/omap2/dss/dispc.c | 10 +-
drivers/video/omap2/dss/display.c | 2 +-
drivers/video/omap2/dss/dsi.c | 12 +-
drivers/video/omap2/dss/dss.h | 4 +-
drivers/video/omap2/dss/dss_features.c | 44 -
drivers/video/omap2/dss/dss_features.h | 8 -
drivers/video/omap2/dss/hdmi.c | 1184 --------------------
drivers/video/omap2/dss/hdmi.h | 444 ++++++++
drivers/video/omap2/dss/hdmi4.c | 696 ++++++++++++
.../omap2/dss/{ti_hdmi_4xxx_ip.c => hdmi4_core.c} | 771 ++++---------
.../omap2/dss/{ti_hdmi_4xxx_ip.h => hdmi4_core.h} | 303 ++---
drivers/video/omap2/dss/hdmi_common.c | 423 +++++++
drivers/video/omap2/dss/hdmi_phy.c | 160 +++
drivers/video/omap2/dss/hdmi_pll.c | 230 ++++
drivers/video/omap2/dss/hdmi_wp.c | 271 +++++
drivers/video/omap2/dss/ti_hdmi.h | 187 ----
drivers/video/p9100.c | 2 -
drivers/video/platinumfb.c | 3 +-
drivers/video/pm2fb.c | 5 +-
drivers/video/pm3fb.c | 4 +-
drivers/video/pmag-ba-fb.c | 4 +-
drivers/video/pmagb-b-fb.c | 9 +-
drivers/video/pvr2fb.c | 25 +-
drivers/video/pxa168fb.c | 6 +-
drivers/video/pxafb.c | 16 +-
drivers/video/q40fb.c | 3 +-
drivers/video/riva/fbdev.c | 5 -
drivers/video/s1d13xxxfb.c | 15 +-
drivers/video/s3c-fb.c | 2 +-
drivers/video/s3c2410fb.c | 6 +-
drivers/video/s3fb.c | 63 +-
drivers/video/sa1100fb.c | 4 +-
drivers/video/savage/savagefb_driver.c | 6 -
drivers/video/sbuslib.c | 2 +-
drivers/video/sgivwfb.c | 4 +-
drivers/video/sh_mobile_hdmi.c | 19 +-
drivers/video/sh_mobile_lcdcfb.c | 14 +-
drivers/video/simplefb.c | 24 +-
drivers/video/sis/sis_main.c | 8 +-
drivers/video/skeletonfb.c | 3 +-
drivers/video/smscufx.c | 2 +-
drivers/video/ssd1307fb.c | 2 +-
drivers/video/sstfb.c | 8 +-
drivers/video/stifb.c | 4 +-
drivers/video/sunxvr1000.c | 2 -
drivers/video/svgalib.c | 4 +-
drivers/video/sysimgblt.c | 2 +-
drivers/video/tcx.c | 6 +-
drivers/video/tdfxfb.c | 1 -
drivers/video/tgafb.c | 4 +-
drivers/video/tmiofb.c | 13 +-
drivers/video/tridentfb.c | 1 -
drivers/video/udlfb.c | 2 +-
drivers/video/uvesafb.c | 25 +-
drivers/video/valkyriefb.c | 2 +-
drivers/video/vesafb.c | 3 +-
drivers/video/vfb.c | 10 +-
drivers/video/vga16fb.c | 3 +-
drivers/video/vt8500lcdfb.c | 2 +-
drivers/video/vt8623fb.c | 41 +-
drivers/video/w100fb.c | 7 +-
drivers/video/wm8505fb.c | 14 +-
drivers/video/wmt_ge_rops.c | 4 +-
drivers/video/xilinxfb.c | 61 +-
include/linux/fb.h | 12 +
include/video/atmel_lcdc.h | 25 +-
include/video/mmp_disp.h | 6 +
include/video/omap-panel-data.h | 13 +
176 files changed, 3948 insertions(+), 3104 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/atmel,lcdc.txt
create mode 100644 drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
delete mode 100644 drivers/video/omap2/dss/hdmi.c
create mode 100644 drivers/video/omap2/dss/hdmi.h
create mode 100644 drivers/video/omap2/dss/hdmi4.c
rename drivers/video/omap2/dss/{ti_hdmi_4xxx_ip.c => hdmi4_core.c} (55%)
rename drivers/video/omap2/dss/{ti_hdmi_4xxx_ip.h => hdmi4_core.h} (51%)
create mode 100644 drivers/video/omap2/dss/hdmi_common.c
create mode 100644 drivers/video/omap2/dss/hdmi_phy.c
create mode 100644 drivers/video/omap2/dss/hdmi_pll.c
create mode 100644 drivers/video/omap2/dss/hdmi_wp.c
delete mode 100644 drivers/video/omap2/dss/ti_hdmi.h
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [GIT PULL] fbdev changes for 3.13
From: Peter Hurley @ 2013-11-13 14:24 UTC (permalink / raw)
To: John Tapsell
Cc: Tomi Valkeinen, Linus Torvalds, linux-fbdev, linux-kernel,
Jean-Christophe PLAGNIOL-VILLARD
In-Reply-To: <52836BBB.4010502@ti.com>
On 11/13/2013 07:08 AM, Tomi Valkeinen wrote:
> Hi Linus,
>
> The following changes since commit 272b98c6455f00884f0350f775c5342358ebb73f:
>
> Linux 3.12-rc1 (2013-09-16 16:17:51 -0400)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git tags/fbdev-3.13
>
> for you to fetch changes up to 3a41c5dbe8bc396a7fb16ca8739e945bb003342e:
>
> fb: reorder the lock sequence to fix potential dead lock (2013-11-11 15:52:59 +0200)
>
> ----------------------------------------------------------------
> fbdev changes for 3.13
>
> Nothing particularly stands out in this pull request. The biggest part of the
> changes are cleanups.
>
> Maybe one fix to mention is the "fb: reorder the lock sequence to fix potential
> dead lock" which hopefully fixes the fb locking issues reported by multiple
> persons.
>
...<snip>
>
> Gu Zheng (1):
> fb: reorder the lock sequence to fix potential dead lock
John,
The above patch should fix the deadlock you found in fbcon_generic_blank().
Please re-test 3.13-rc1 when released [or Tomi's for-next branch now].
Regards,
Peter Hurley
^ permalink raw reply
* Re: [PATCH 1/1] video: exynos_mipi_dsi: Remove unused variable
From: Sachin Kamat @ 2013-11-14 6:25 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1382333533-32740-1-git-send-email-sachin.kamat@linaro.org>
Hi Tomi,
On 24 October 2013 21:25, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> On Monday 21 October 2013 11:02 AM, Sachin Kamat wrote:
>> 'pdev' is not used anymore (Removed vide commit 7e0be9f9 "video:
>> exynos_mipi_dsim: Use the generic PHY driver"). Remove it and
>> silence the following compilation warning:
>> drivers/video/exynos/exynos_mipi_dsi.c:144:26: warning:
>> unused variable ‘pdev’ [-Wunused-variable]
>>
>> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
Now that phy patchset and your tree is already merged into Linus' tree,
please queue this patch in your tree.
--
With warm regards,
Sachin
^ permalink raw reply
* [patch 1/2] video: mmp: delete a stray mutex_unlock()
From: Dan Carpenter @ 2013-11-14 8:19 UTC (permalink / raw)
To: linux-fbdev
We aren't holding the disp_lock so we shouldn't release it.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/video/mmp/core.c b/drivers/video/mmp/core.c
index 84de263..c8d4265 100644
--- a/drivers/video/mmp/core.c
+++ b/drivers/video/mmp/core.c
@@ -173,7 +173,7 @@ struct mmp_path *mmp_register_path(struct mmp_path_info *info)
+ sizeof(struct mmp_overlay) * info->overlay_num;
path = kzalloc(size, GFP_KERNEL);
if (!path)
- goto failed;
+ return NULL;
/* path set */
mutex_init(&path->access_ok);
@@ -219,11 +219,6 @@ struct mmp_path *mmp_register_path(struct mmp_path_info *info)
mutex_unlock(&disp_lock);
return path;
-
-failed:
- kfree(path);
- mutex_unlock(&disp_lock);
- return NULL;
}
EXPORT_SYMBOL_GPL(mmp_register_path);
^ 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