* Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep
From: Tomi Valkeinen @ 2012-05-10 6:54 UTC (permalink / raw)
To: Russ Dill; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1336601288-27848-1-git-send-email-Russ.Dill@ti.com>
[-- Attachment #1: Type: text/plain, Size: 494 bytes --]
On Wed, 2012-05-09 at 15:08 -0700, Russ Dill wrote:
> The Beagleboard xM gpio used for TFP410 powerdown is connected through
> an I2C attached chip which means setting the GPIO can sleep. Code that
> calls tfp410_power_on/off holds a mutex, so sleeping should be fine.
>
> Signed-off-by: Russ Dill <Russ.Dill@ti.com>
> ---
> drivers/video/omap2/displays/panel-tfp410.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
I'll apply this to dss tree, thanks.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 00/25] OMAPDSS: DT preparation patches v2
From: Tomi Valkeinen @ 2012-05-10 7:11 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, linux-fbdev, archit
In-Reply-To: <20120509154543.GK5088@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 2020 bytes --]
On Wed, 2012-05-09 at 08:45 -0700, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [120509 01:12]:
> >
> > Below is the pull request for board file related changes. Tested on
> > panda & 4430sdp.
>
> Thanks, I've merged that into clenaup-dss branch and will send it
> along with other still pending cleanup branches.
>
> > How should I manage my tree related to this... Should I rebase my
> > original DT preparation series on top of this new branch, or can I just
> > ignore the new branch for now, as long as I merge it at some point
> > before sending a pull request to mainline?
>
> Yes you need to rebase on this now. And not touch these commits.
>
> Otherwise we'll end up with duplicate commits in the mainline tree,
> which is a big no-no. If something shows up that needs fixing in this
> series, it must now be separate patches on top of this series.
>
> When doing pull requests we both just have to make note that there's
> a dependency to this branch, and it will find it's way to mainline
> via arm-soc pull request. Or if no conflicts need sorting out, then
> it will just get merged with your pull request.
Hmm, I'm still not totally sure how to proceed. What do you mean with
"make a note"?
I understand that I can't change the commits, but is it ok for me to now
merge the for-l-o-3.5 branch into my master branch (which is my "stable"
branch, for which I'll send a pull request)?
If the same commits are both in my tree and in l-o (or arm-soc), doesn't
it mean that the commits seem to come into Linus's tree from whoever
happens to send their pull request first? Then again, does it matter..
And if there are conflicts in the board files between for-l-o-3.5 and
some other commits, and you or Arnd resolve those for l-o or arm-soc,
what happens when the same, but unresolved, commits come from my pull
request?
Sorry if this should be obvious, but I haven't done such merging before
and I'd rather not mess it up =).
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] OMAPDSS: OMAPFB: always allow to configure overlay
From: Tomi Valkeinen @ 2012-05-10 10:28 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1336144581-25151-1-git-send-email-notasas@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1307 bytes --]
On Fri, 2012-05-04 at 18:16 +0300, Grazvydas Ignotas wrote:
> Currently when multiple overlays are active, OMAPFB_SETUP_PLANE fails.
> Instead of failing, allow it to configure the first overlay as if there
> was only one overlay, the remaining ones will have to be configured in
> other ways (sysfs).
>
> This allows overlay-controlling programs (like video players) to function
> properly when framebuffer is cloned to another display (like TV).
>
> Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
> ---
> drivers/video/omap2/omapfb/omapfb-ioctl.c | 36 ++++++++++------------------
> 1 files changed, 13 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c b/drivers/video/omap2/omapfb/omapfb-ioctl.c
> index 6a09ef8..58b7f2d 100644
> --- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
> +++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
> @@ -70,11 +70,6 @@ static int omapfb_setup_plane(struct fb_info *fbi, struct omapfb_plane_info *pi)
>
> DBG("omapfb_setup_plane\n");
>
> - if (ofbi->num_overlays != 1) {
> - r = -EINVAL;
> - goto out;
> - }
> -
> /* XXX uses only the first overlay */
> ovl = ofbi->overlays[0];
What if there are no overlays? I'm not quite sure about it, but I think
it's possible.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] OMAPDSS: OMAPFB: always allow to configure overlay
From: Grazvydas Ignotas @ 2012-05-10 10:58 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1336144581-25151-1-git-send-email-notasas@gmail.com>
On Thu, May 10, 2012 at 1:28 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On Fri, 2012-05-04 at 18:16 +0300, Grazvydas Ignotas wrote:
>> Currently when multiple overlays are active, OMAPFB_SETUP_PLANE fails.
>> Instead of failing, allow it to configure the first overlay as if there
>> was only one overlay, the remaining ones will have to be configured in
>> other ways (sysfs).
>>
>> This allows overlay-controlling programs (like video players) to function
>> properly when framebuffer is cloned to another display (like TV).
>>
>> Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
>> ---
>> drivers/video/omap2/omapfb/omapfb-ioctl.c | 36 ++++++++++------------------
>> 1 files changed, 13 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c b/drivers/video/omap2/omapfb/omapfb-ioctl.c
>> index 6a09ef8..58b7f2d 100644
>> --- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
>> +++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
>> @@ -70,11 +70,6 @@ static int omapfb_setup_plane(struct fb_info *fbi, struct omapfb_plane_info *pi)
>>
>> DBG("omapfb_setup_plane\n");
>>
>> - if (ofbi->num_overlays != 1) {
>> - r = -EINVAL;
>> - goto out;
>> - }
>> -
>> /* XXX uses only the first overlay */
>> ovl = ofbi->overlays[0];
>
> What if there are no overlays? I'm not quite sure about it, but I think
> it's possible.
Hmm, I guess you are right, will send v2.
--
Gražvydas
^ permalink raw reply
* [PATCH v2] OMAPDSS: OMAPFB: always allow to configure overlay
From: Grazvydas Ignotas @ 2012-05-10 11:19 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-omap, Tomi Valkeinen, Grazvydas Ignotas
Currently when multiple overlays are active, OMAPFB_SETUP_PLANE fails.
Instead of failing, allow it to configure the first overlay as if there
was only one overlay, the remaining ones will have to be configured in
other ways (sysfs).
This allows overlay-controlling programs (like video players) to function
properly when framebuffer is cloned to another display (like TV).
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
---
drivers/video/omap2/omapfb/omapfb-ioctl.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c b/drivers/video/omap2/omapfb/omapfb-ioctl.c
index 6a09ef8..8af7e17 100644
--- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
+++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
@@ -70,7 +70,7 @@ static int omapfb_setup_plane(struct fb_info *fbi, struct omapfb_plane_info *pi)
DBG("omapfb_setup_plane\n");
- if (ofbi->num_overlays != 1) {
+ if (ofbi->num_overlays = 0) {
r = -EINVAL;
goto out;
}
@@ -185,7 +185,7 @@ static int omapfb_query_plane(struct fb_info *fbi, struct omapfb_plane_info *pi)
{
struct omapfb_info *ofbi = FB2OFB(fbi);
- if (ofbi->num_overlays != 1) {
+ if (ofbi->num_overlays = 0) {
memset(pi, 0, sizeof(*pi));
} else {
struct omap_overlay *ovl;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH v2 1/4] mfd: add LM3533 lighting-power core driver
From: Johan Hovold @ 2012-05-10 12:07 UTC (permalink / raw)
To: Samuel Ortiz
Cc: Rob Landley, Richard Purdie, Jonathan Cameron, Greg Kroah-Hartman,
Florian Tobias Schandinat, Arnd Bergmann, Andrew Morton,
Mark Brown, linux-doc, linux-kernel, linux-iio, devel,
linux-fbdev
In-Reply-To: <20120509144218.GI1794@sortiz-mobl>
On Wed, May 09, 2012 at 04:42:18PM +0200, Samuel Ortiz wrote:
> Hi Johan
>
> On Thu, May 03, 2012 at 12:26:36PM +0200, Johan Hovold wrote:
> > Add support for National Semiconductor / TI LM3533 lighting power chips.
> >
> > This is the core driver which provides register access over I2C and
> > registers the ambient-light-sensor, LED and backlight sub-drivers.
> >
> > Signed-off-by: Johan Hovold <jhovold@gmail.com>
> > ---
> >
> > v2:
> > - add sysfs-ABI documentation
> > - merge i2c implementation with core
> > - use regmap and kill custom debugfs interface
> >
> >
> > .../ABI/testing/sysfs-bus-i2c-devices-lm3533 | 38 +
> > drivers/mfd/Kconfig | 13 +
> > drivers/mfd/Makefile | 1 +
> > drivers/mfd/lm3533-core.c | 717 ++++++++++++++++++++
> > drivers/mfd/lm3533-ctrlbank.c | 134 ++++
> > include/linux/mfd/lm3533.h | 89 +++
> > 6 files changed, 992 insertions(+), 0 deletions(-)
> > create mode 100644 Documentation/ABI/testing/sysfs-bus-i2c-devices-lm3533
> > create mode 100644 drivers/mfd/lm3533-core.c
> > create mode 100644 drivers/mfd/lm3533-ctrlbank.c
> > create mode 100644 include/linux/mfd/lm3533.h
> Patch applied to my for-next branch, thanks.
I've been travelling for a few days and didn't have time to submit a
discussed change to move two attributes to the platform data before I
left.
Could you please apply the following two patches on top of this one?
mfd: lm3533: add boost frequency and ovp to platform data
mfd: lm3533: remove boost attributes
Thanks,
Johan
^ permalink raw reply
* Re: [PATCH 00/25] OMAPDSS: DT preparation patches v2
From: Tony Lindgren @ 2012-05-10 16:13 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, archit
In-Reply-To: <1336633888.5182.19.camel@deskari>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120510 00:15]:
> On Wed, 2012-05-09 at 08:45 -0700, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [120509 01:12]:
> > >
> > > Below is the pull request for board file related changes. Tested on
> > > panda & 4430sdp.
> >
> > Thanks, I've merged that into clenaup-dss branch and will send it
> > along with other still pending cleanup branches.
> >
> > > How should I manage my tree related to this... Should I rebase my
> > > original DT preparation series on top of this new branch, or can I just
> > > ignore the new branch for now, as long as I merge it at some point
> > > before sending a pull request to mainline?
> >
> > Yes you need to rebase on this now. And not touch these commits.
> >
> > Otherwise we'll end up with duplicate commits in the mainline tree,
> > which is a big no-no. If something shows up that needs fixing in this
> > series, it must now be separate patches on top of this series.
> >
> > When doing pull requests we both just have to make note that there's
> > a dependency to this branch, and it will find it's way to mainline
> > via arm-soc pull request. Or if no conflicts need sorting out, then
> > it will just get merged with your pull request.
>
> Hmm, I'm still not totally sure how to proceed. What do you mean with
> "make a note"?
Well let's say I had some conflicting platform data clean up patches,
I would pull in your branch, then when sending a pull request I would
mention that it depends on your branch being pulled in.
> I understand that I can't change the commits, but is it ok for me to now
> merge the for-l-o-3.5 branch into my master branch (which is my "stable"
> branch, for which I'll send a pull request)?
Yes. But I suggest you first add add that panda xm gpio fix into your
for-l-o-3.5 and that way it's safer for me to merge too.
> If the same commits are both in my tree and in l-o (or arm-soc), doesn't
> it mean that the commits seem to come into Linus's tree from whoever
> happens to send their pull request first? Then again, does it matter..
Yes, that's OK.
> And if there are conflicts in the board files between for-l-o-3.5 and
> some other commits, and you or Arnd resolve those for l-o or arm-soc,
> what happens when the same, but unresolved, commits come from my pull
> request?
Well in that case it makes sense to get the arm-soc changes merged
first, who wants to resolve conflicts multiple times? Of course more
branches can be pulled into both trees as needed too.
> Sorry if this should be obvious, but I haven't done such merging before
> and I'd rather not mess it up =).
Yeah np :)
Tony
^ permalink raw reply
* Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep
From: Tony Lindgren @ 2012-05-10 16:16 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Russ Dill, linux-omap, linux-fbdev
In-Reply-To: <1336632790.5182.8.camel@deskari>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120509 23:56]:
> On Wed, 2012-05-09 at 16:37 -0700, Tony Lindgren wrote:
> > * Russ Dill <Russ.Dill@ti.com> [120509 15:53]:
> > > On Wed, May 9, 2012 at 3:14 PM, Tony Lindgren <tony@atomide.com> wrote:
> > > > * Russ Dill <Russ.Dill@ti.com> [120509 15:12]:
> > > >> The Beagleboard xM gpio used for TFP410 powerdown is connected through
> > > >> an I2C attached chip which means setting the GPIO can sleep. Code that
> > > >> calls tfp410_power_on/off holds a mutex, so sleeping should be fine.
> > > >
> > > > What's the error without this patch? Or just no display?
> > > >
> > > > Just wondering if it's safe to merge Tomi's clean up series to
> > > > arm-soc tree..
> > >
> > > The only platform that has a problem is Beagleboard xM, and that is
> > > only after 'ARM: OMAP: Cleanup Beagleboard DVI reset gpio' is applied.
> > > Since the context actually can sleep, the only consequence is a
> > > WARN_ON statement.
> > >
> > > So yes, it should be safe.
> >
> > Well since I have not actually merged it with other branches yet, I'll wait
> > for Tomi to apply that and repull his for-l-o-3.5 branch.
>
> You can pull for-l-o-3.5 as it is now, there's no need to change it.
> This _cansleep change is a separate dss specific change.
>
> So to summarize:
>
> Currently the powerdown GPIO for tfp410 is handled in the board files
> (and called reset gpio), with gpio_set_value(). My cleanup series moves
> this to the tfp410 driver.
>
> BB-xM needs to use gpio_set_value_cansleep() in tfp410 to function
> properly, so the tfp410 driver needs to be changed, as this patch does.
> I will take this patch to the dss tree.
>
> So it's safe to pull my cleanup series, but if I understood correctly,
> applying Russ's "[PATCH v4] ARM: OMAP: Cleanup Beagleboard DVI reset
> gpio" will cause WARN_ONs on BB-xM until this patch to tfp410 is also
> applied.
>
> But it doesn't sound too serious, so I think it's safe to apply the
> "cleanup beagleboard dvi" patch also. The warning will go away when both
> l-o and dss trees are pulled in the merge window.
OK thanks will use for-l-o-3.5 as it is now then.
Tony
^ permalink raw reply
* [PATCH v3] backlight: add LM3533 backlight driver
From: Johan Hovold @ 2012-05-10 18:29 UTC (permalink / raw)
To: Richard Purdie
Cc: Rob Landley, Samuel Ortiz, Jonathan Cameron, Greg Kroah-Hartman,
Florian Tobias Schandinat, Arnd Bergmann, Andrew Morton,
Mark Brown, linux-doc, linux-kernel, linux-fbdev, Johan Hovold
In-Reply-To: <1336040799-18433-5-git-send-email-jhovold@gmail.com>
Add sub-driver for the backlights on National Semiconductor / TI LM3533
lighting power chips.
The chip provides 256 brightness levels and ambient-light-sensor and pwm
input control.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
---
v2
- add sysfs-ABI documentation
- open code max_current/pwm macros
v3
- remove max_current attribute
.../testing/sysfs-class-backlight-driver-lm3533 | 41 ++
drivers/video/backlight/Kconfig | 12 +
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/lm3533_bl.c | 423 ++++++++++++++++++++
4 files changed, 477 insertions(+), 0 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-class-backlight-driver-lm3533
create mode 100644 drivers/video/backlight/lm3533_bl.c
diff --git a/Documentation/ABI/testing/sysfs-class-backlight-driver-lm3533 b/Documentation/ABI/testing/sysfs-class-backlight-driver-lm3533
new file mode 100644
index 0000000..9fda257
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-backlight-driver-lm3533
@@ -0,0 +1,41 @@
+What: /sys/class/backlight/<backlight>/als
+Date: April 2012
+KernelVersion: 3.5
+Contact: Johan Hovold <jhovold@gmail.com>
+Description:
+ Set the ALS-control mode (0,..2), where
+
+ 0 - disabled
+ 1 - ALS-mapper 1 (backlight 0)
+ 2 - ALS-mapper 2 (backlight 1)
+
+What: /sys/class/backlight/<backlight>/id
+Date: April 2012
+KernelVersion: 3.5
+Contact: Johan Hovold <jhovold@gmail.com>
+Description:
+ Get the id of this backlight (0, 1).
+
+What: /sys/class/backlight/<backlight>/linear
+Date: April 2012
+KernelVersion: 3.5
+Contact: Johan Hovold <jhovold@gmail.com>
+Description:
+ Set the brightness-mapping mode (0, 1), where
+
+ 0 - exponential mode
+ 1 - linear mode
+
+What: /sys/class/backlight/<backlight>/pwm
+Date: April 2012
+KernelVersion: 3.5
+Contact: Johan Hovold <jhovold@gmail.com>
+Description:
+ Set the PWM-input control mask (5 bits), where
+
+ bit 5 - PWM-input enabled in Zone 4
+ bit 4 - PWM-input enabled in Zone 3
+ bit 3 - PWM-input enabled in Zone 2
+ bit 2 - PWM-input enabled in Zone 1
+ bit 1 - PWM-input enabled in Zone 0
+ bit 0 - PWM-input enabled
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index af16884..fa2b037 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -184,6 +184,18 @@ config BACKLIGHT_GENERIC
known as the Corgi backlight driver. If you have a Sharp Zaurus
SL-C7xx, SL-Cxx00 or SL-6000x say y.
+config BACKLIGHT_LM3533
+ tristate "Backlight Driver for LM3533"
+ depends on BACKLIGHT_CLASS_DEVICE
+ depends on MFD_LM3533
+ help
+ Say Y to enable the backlight driver for National Semiconductor / TI
+ LM3533 Lighting Power chips.
+
+ The backlights can be controlled directly, through PWM input, or by
+ the ambient-light-sensor interface. The chip supports 256 brightness
+ levels.
+
config BACKLIGHT_LOCOMO
tristate "Sharp LOCOMO LCD/Backlight Driver"
depends on SHARP_LOCOMO
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 36855ae..a2ac9cf 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_BACKLIGHT_EP93XX) += ep93xx_bl.o
obj-$(CONFIG_BACKLIGHT_GENERIC) += generic_bl.o
obj-$(CONFIG_BACKLIGHT_HP700) += jornada720_bl.o
obj-$(CONFIG_BACKLIGHT_HP680) += hp680_bl.o
+obj-$(CONFIG_BACKLIGHT_LM3533) += lm3533_bl.o
obj-$(CONFIG_BACKLIGHT_LOCOMO) += locomolcd.o
obj-$(CONFIG_BACKLIGHT_LP855X) += lp855x_bl.o
obj-$(CONFIG_BACKLIGHT_OMAP1) += omap1_bl.o
diff --git a/drivers/video/backlight/lm3533_bl.c b/drivers/video/backlight/lm3533_bl.c
new file mode 100644
index 0000000..5abca65
--- /dev/null
+++ b/drivers/video/backlight/lm3533_bl.c
@@ -0,0 +1,423 @@
+/*
+ * lm3533-bl.c -- LM3533 Backlight driver
+ *
+ * Copyright (C) 2011-2012 Texas Instruments
+ *
+ * Author: Johan Hovold <jhovold@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/platform_device.h>
+#include <linux/backlight.h>
+#include <linux/fb.h>
+#include <linux/slab.h>
+
+#include <linux/mfd/lm3533.h>
+
+
+#define LM3533_HVCTRLBANK_COUNT 2
+#define LM3533_BL_MAX_BRIGHTNESS 255
+
+#define LM3533_REG_CTRLBANK_AB_BCONF 0x1a
+
+
+struct lm3533_bl {
+ struct lm3533 *lm3533;
+ struct lm3533_ctrlbank cb;
+ struct backlight_device *bd;
+ int id;
+};
+
+
+static inline int lm3533_bl_get_ctrlbank_id(struct lm3533_bl *bl)
+{
+ return bl->id;
+}
+
+static int lm3533_bl_update_status(struct backlight_device *bd)
+{
+ struct lm3533_bl *bl = bl_get_data(bd);
+ int brightness = bd->props.brightness;
+
+ if (bd->props.power != FB_BLANK_UNBLANK)
+ brightness = 0;
+ if (bd->props.fb_blank != FB_BLANK_UNBLANK)
+ brightness = 0;
+
+ return lm3533_ctrlbank_set_brightness(&bl->cb, (u8)brightness);
+}
+
+static int lm3533_bl_get_brightness(struct backlight_device *bd)
+{
+ struct lm3533_bl *bl = bl_get_data(bd);
+ u8 val;
+ int ret;
+
+ ret = lm3533_ctrlbank_get_brightness(&bl->cb, &val);
+ if (ret)
+ return ret;
+
+ return val;
+}
+
+static const struct backlight_ops lm3533_bl_ops = {
+ .get_brightness = lm3533_bl_get_brightness,
+ .update_status = lm3533_bl_update_status,
+};
+
+static ssize_t show_id(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct lm3533_bl *bl = dev_get_drvdata(dev);
+
+ return scnprintf(buf, PAGE_SIZE, "%d\n", bl->id);
+}
+
+/*
+ * ALS-control setting:
+ *
+ * 0 - ALS disabled
+ * 1 - ALS-mapper 1 (backlight 0)
+ * 2 - ALS-mapper 2 (backlight 1)
+ */
+static ssize_t show_als(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct lm3533_bl *bl = dev_get_drvdata(dev);
+ int ctrlbank = lm3533_bl_get_ctrlbank_id(bl);
+ u8 val;
+ u8 mask;
+ int als;
+ int ret;
+
+ ret = lm3533_read(bl->lm3533, LM3533_REG_CTRLBANK_AB_BCONF, &val);
+ if (ret)
+ return ret;
+
+ mask = 2 * ctrlbank;
+ als = val & mask;
+ if (als)
+ als = ctrlbank + 1;
+
+ return scnprintf(buf, PAGE_SIZE, "%d\n", als);
+}
+
+static ssize_t store_als(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct lm3533_bl *bl = dev_get_drvdata(dev);
+ int ctrlbank = lm3533_bl_get_ctrlbank_id(bl);
+ int als;
+ u8 val;
+ u8 mask;
+ int ret;
+
+ if (kstrtoint(buf, 0, &als))
+ return -EINVAL;
+
+ if (als != 0 && (als != ctrlbank + 1))
+ return -EINVAL;
+
+ mask = 1 << (2 * ctrlbank);
+
+ if (als)
+ val = mask;
+ else
+ val = 0;
+
+ ret = lm3533_update(bl->lm3533, LM3533_REG_CTRLBANK_AB_BCONF, val,
+ mask);
+ if (ret)
+ return ret;
+
+ return len;
+}
+
+static ssize_t show_linear(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct lm3533_bl *bl = dev_get_drvdata(dev);
+ u8 val;
+ u8 mask;
+ int linear;
+ int ret;
+
+ ret = lm3533_read(bl->lm3533, LM3533_REG_CTRLBANK_AB_BCONF, &val);
+ if (ret)
+ return ret;
+
+ mask = 1 << (2 * lm3533_bl_get_ctrlbank_id(bl) + 1);
+
+ if (val & mask)
+ linear = 1;
+ else
+ linear = 0;
+
+ return scnprintf(buf, PAGE_SIZE, "%x\n", linear);
+}
+
+static ssize_t store_linear(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct lm3533_bl *bl = dev_get_drvdata(dev);
+ unsigned long linear;
+ u8 mask;
+ u8 val;
+ int ret;
+
+ if (kstrtoul(buf, 0, &linear))
+ return -EINVAL;
+
+ mask = 1 << (2 * lm3533_bl_get_ctrlbank_id(bl) + 1);
+
+ if (linear)
+ val = mask;
+ else
+ val = 0;
+
+ ret = lm3533_update(bl->lm3533, LM3533_REG_CTRLBANK_AB_BCONF, val,
+ mask);
+ if (ret)
+ return ret;
+
+ return len;
+}
+
+static ssize_t show_pwm(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct lm3533_bl *bl = dev_get_drvdata(dev);
+ u8 val;
+ int ret;
+
+ ret = lm3533_ctrlbank_get_pwm(&bl->cb, &val);
+ if (ret)
+ return ret;
+
+ return scnprintf(buf, PAGE_SIZE, "%u\n", val);
+}
+
+static ssize_t store_pwm(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct lm3533_bl *bl = dev_get_drvdata(dev);
+ u8 val;
+ int ret;
+
+ if (kstrtou8(buf, 0, &val))
+ return -EINVAL;
+
+ ret = lm3533_ctrlbank_set_pwm(&bl->cb, val);
+ if (ret)
+ return ret;
+
+ return len;
+}
+
+static LM3533_ATTR_RW(als);
+static LM3533_ATTR_RO(id);
+static LM3533_ATTR_RW(linear);
+static LM3533_ATTR_RW(pwm);
+
+static struct attribute *lm3533_bl_attributes[] = {
+ &dev_attr_als.attr,
+ &dev_attr_id.attr,
+ &dev_attr_linear.attr,
+ &dev_attr_pwm.attr,
+ NULL,
+};
+
+static mode_t lm3533_bl_attr_is_visible(struct kobject *kobj,
+ struct attribute *attr, int n)
+{
+ struct device *dev = container_of(kobj, struct device, kobj);
+ struct lm3533_bl *bl = dev_get_drvdata(dev);
+ mode_t mode = attr->mode;
+
+ if (attr = &dev_attr_als.attr) {
+ if (!bl->lm3533->have_als)
+ mode = 0;
+ }
+
+ return mode;
+};
+
+static struct attribute_group lm3533_bl_attribute_group = {
+ .is_visible = lm3533_bl_attr_is_visible,
+ .attrs = lm3533_bl_attributes
+};
+
+static int __devinit lm3533_bl_setup(struct lm3533_bl *bl,
+ struct lm3533_bl_platform_data *pdata)
+{
+ int ret;
+
+ ret = lm3533_ctrlbank_set_max_current(&bl->cb, pdata->max_current);
+ if (ret)
+ return ret;
+
+ return lm3533_ctrlbank_set_pwm(&bl->cb, pdata->pwm);
+}
+
+static int __devinit lm3533_bl_probe(struct platform_device *pdev)
+{
+ struct lm3533 *lm3533;
+ struct lm3533_bl_platform_data *pdata;
+ struct lm3533_bl *bl;
+ struct backlight_device *bd;
+ struct backlight_properties props;
+ int ret;
+
+ dev_dbg(&pdev->dev, "%s\n", __func__);
+
+ lm3533 = dev_get_drvdata(pdev->dev.parent);
+ if (!lm3533)
+ return -EINVAL;
+
+ pdata = pdev->dev.platform_data;
+ if (!pdata) {
+ dev_err(&pdev->dev, "no platform data\n");
+ return -EINVAL;
+ }
+
+ if (pdev->id < 0 || pdev->id >= LM3533_HVCTRLBANK_COUNT) {
+ dev_err(&pdev->dev, "illegal backlight id %d\n", pdev->id);
+ return -EINVAL;
+ }
+
+ bl = kzalloc(sizeof(*bl), GFP_KERNEL);
+ if (!bl) {
+ dev_err(&pdev->dev,
+ "failed to allocate memory for backlight\n");
+ return -ENOMEM;
+ }
+
+ bl->lm3533 = lm3533;
+ bl->id = pdev->id;
+
+ bl->cb.lm3533 = lm3533;
+ bl->cb.id = lm3533_bl_get_ctrlbank_id(bl);
+ bl->cb.dev = NULL; /* until registered */
+
+ memset(&props, 0, sizeof(props));
+ props.type = BACKLIGHT_RAW;
+ props.max_brightness = LM3533_BL_MAX_BRIGHTNESS;
+ props.brightness = pdata->default_brightness;
+ bd = backlight_device_register(pdata->name, pdev->dev.parent, bl,
+ &lm3533_bl_ops, &props);
+ if (IS_ERR(bd)) {
+ dev_err(&pdev->dev, "failed to register backlight device\n");
+ ret = PTR_ERR(bd);
+ goto err_free;
+ }
+
+ bl->bd = bd;
+ bl->cb.dev = &bl->bd->dev;
+
+ platform_set_drvdata(pdev, bl);
+
+ ret = sysfs_create_group(&bd->dev.kobj, &lm3533_bl_attribute_group);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed to create sysfs attributes\n");
+ goto err_unregister;
+ }
+
+ backlight_update_status(bd);
+
+ ret = lm3533_bl_setup(bl, pdata);
+ if (ret)
+ goto err_sysfs_remove;
+
+ ret = lm3533_ctrlbank_enable(&bl->cb);
+ if (ret)
+ goto err_sysfs_remove;
+
+ return 0;
+
+err_sysfs_remove:
+ sysfs_remove_group(&bd->dev.kobj, &lm3533_bl_attribute_group);
+err_unregister:
+ backlight_device_unregister(bd);
+err_free:
+ kfree(bl);
+
+ return ret;
+}
+
+static int __devexit lm3533_bl_remove(struct platform_device *pdev)
+{
+ struct lm3533_bl *bl = platform_get_drvdata(pdev);
+ struct backlight_device *bd = bl->bd;
+
+ dev_dbg(&bd->dev, "%s\n", __func__);
+
+ bd->props.power = FB_BLANK_POWERDOWN;
+ bd->props.brightness = 0;
+
+ lm3533_ctrlbank_disable(&bl->cb);
+ sysfs_remove_group(&bd->dev.kobj, &lm3533_bl_attribute_group);
+ backlight_device_unregister(bd);
+ kfree(bl);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM
+static int lm3533_bl_suspend(struct platform_device *pdev, pm_message_t state)
+{
+ struct lm3533_bl *bl = platform_get_drvdata(pdev);
+
+ dev_dbg(&pdev->dev, "%s\n", __func__);
+
+ return lm3533_ctrlbank_disable(&bl->cb);
+}
+
+static int lm3533_bl_resume(struct platform_device *pdev)
+{
+ struct lm3533_bl *bl = platform_get_drvdata(pdev);
+
+ dev_dbg(&pdev->dev, "%s\n", __func__);
+
+ return lm3533_ctrlbank_enable(&bl->cb);
+}
+#else
+#define lm3533_bl_suspend NULL
+#define lm3533_bl_resume NULL
+#endif
+
+static void lm3533_bl_shutdown(struct platform_device *pdev)
+{
+ struct lm3533_bl *bl = platform_get_drvdata(pdev);
+
+ dev_dbg(&pdev->dev, "%s\n", __func__);
+
+ lm3533_ctrlbank_disable(&bl->cb);
+}
+
+static struct platform_driver lm3533_bl_driver = {
+ .driver = {
+ .name = "lm3533-backlight",
+ .owner = THIS_MODULE,
+ },
+ .probe = lm3533_bl_probe,
+ .remove = __devexit_p(lm3533_bl_remove),
+ .shutdown = lm3533_bl_shutdown,
+ .suspend = lm3533_bl_suspend,
+ .resume = lm3533_bl_resume,
+};
+module_platform_driver(lm3533_bl_driver);
+
+MODULE_AUTHOR("Johan Hovold <jhovold@gmail.com>");
+MODULE_DESCRIPTION("LM3533 Backlight driver");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:lm3533-backlight");
--
1.7.8.5
^ permalink raw reply related
* Re: [PATCH] video/sis: Annotate SiS_DRAMType as __devinitconst
From: Peter Hüwe @ 2012-05-10 21:39 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: Thomas Winischhofer, linux-fbdev, linux-kernel
In-Reply-To: <4FAB0986.6090006@gmx.de>
Am Donnerstag 10 Mai 2012, 02:19:18 schrieb Florian Tobias Schandinat:
> Good that you did this one, it was more to be done than I expected. I
> ignored the checkpatch errors as you didn't introduce them but maybe it
> wouldn't be a bad idea to fix things up if you touch them. Applied.
Oh sorry, usually I do checkpatch, but I missed it on this one somehow.
If you want, I can do a checkpatch cleanup for the whole sis driver as
compensation ;)
Thanks,
Peter
^ permalink raw reply
* [PATCH] drivers/video: fsl-diu-fb: don't initialize the THRESHOLDS registers
From: Timur Tabi @ 2012-05-10 21:57 UTC (permalink / raw)
To: linux-fbdev
The THRESHOLDS register configures thresholds for two interrupts, but
these interrupts are not used in the DIU driver. An early version of the
driver may have used the "lines before vsync" interrupt, which requires
the LS_BF_VS of THRESHOLDS to be initialized.
Unfortunately, the initialization of this register does not do a
read-modify-write to set only LS_BF_VS. On the MPC8610, the value
written is correct. On other chips, like the P1022, the value overwrites
some reserved bits. This results in a performance drop on the P1022.
Since the default value is acceptable as-is on all SOCs, we should just
avoid touching this register.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
drivers/video/fsl-diu-fb.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index 6af3f16..458c006 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -834,7 +834,6 @@ static void update_lcdc(struct fb_info *info)
diu_ops.set_pixel_clock(var->pixclock);
out_be32(&hw->syn_pol, 0); /* SYNC SIGNALS POLARITY */
- out_be32(&hw->thresholds, 0x00037800); /* The Thresholds */
out_be32(&hw->int_status, 0); /* INTERRUPT STATUS */
out_be32(&hw->plut, 0x01F5F666);
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH v2 1/4] mfd: add LM3533 lighting-power core driver
From: Samuel Ortiz @ 2012-05-11 13:32 UTC (permalink / raw)
To: Johan Hovold
Cc: Rob Landley, Richard Purdie, Jonathan Cameron, Greg Kroah-Hartman,
Florian Tobias Schandinat, Arnd Bergmann, Andrew Morton,
Mark Brown, linux-doc, linux-kernel, linux-iio, devel,
linux-fbdev
In-Reply-To: <20120510120742.GA29437@localhost>
Hi Johan,
On Thu, May 10, 2012 at 02:07:42PM +0200, Johan Hovold wrote:
> On Wed, May 09, 2012 at 04:42:18PM +0200, Samuel Ortiz wrote:
> > Hi Johan
> >
> > On Thu, May 03, 2012 at 12:26:36PM +0200, Johan Hovold wrote:
> > > Add support for National Semiconductor / TI LM3533 lighting power chips.
> > >
> > > This is the core driver which provides register access over I2C and
> > > registers the ambient-light-sensor, LED and backlight sub-drivers.
> > >
> > > Signed-off-by: Johan Hovold <jhovold@gmail.com>
> > > ---
> > >
> > > v2:
> > > - add sysfs-ABI documentation
> > > - merge i2c implementation with core
> > > - use regmap and kill custom debugfs interface
> > >
> > >
> > > .../ABI/testing/sysfs-bus-i2c-devices-lm3533 | 38 +
> > > drivers/mfd/Kconfig | 13 +
> > > drivers/mfd/Makefile | 1 +
> > > drivers/mfd/lm3533-core.c | 717 ++++++++++++++++++++
> > > drivers/mfd/lm3533-ctrlbank.c | 134 ++++
> > > include/linux/mfd/lm3533.h | 89 +++
> > > 6 files changed, 992 insertions(+), 0 deletions(-)
> > > create mode 100644 Documentation/ABI/testing/sysfs-bus-i2c-devices-lm3533
> > > create mode 100644 drivers/mfd/lm3533-core.c
> > > create mode 100644 drivers/mfd/lm3533-ctrlbank.c
> > > create mode 100644 include/linux/mfd/lm3533.h
> > Patch applied to my for-next branch, thanks.
>
> I've been travelling for a few days and didn't have time to submit a
> discussed change to move two attributes to the platform data before I
> left.
>
> Could you please apply the following two patches on top of this one?
All of your 4 pending patches have been applied, thanks.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* Re: ASoC: wm9712: Microphone doesn't work: Mux handling broken?
From: Christoph Fritz @ 2012-05-12 0:15 UTC (permalink / raw)
To: Mark Brown
Cc: alsa-devel, Hans J. Koch, Sascha Hauer, Liam Girdwood,
linux-fbdev
In-Reply-To: <20120508102947.GA8226@lovely.krouter>
> > Framebuffer driver mx3fb configured for a 800x600 display:
> >
> > soc-audio soc-audio: ASoC machine PhyCORE-ac97-audio should use snd_soc_register_card()
> > asoc: platform pcm constructor failed
> > asoc: can't create pcm HiFi :-12
> > asoc: failed to instantiate card PhyCORE-ac97-audio: -12
>
> When I do decrease from 800x600 to 800x594, wm9712 works.
>
> Any ideas?
It seems to be a dma problem and not directly related to wm9712.
But the not working microphone input still bothers me. I suppose this
is related to not beeing able to change some muxes:
$ amixer sset "Mic Select Source" 'Mic 2'
Simple mixer control 'Mic Select Source',0
Capabilities: enum
Items: 'Mic 1' 'Differential' 'Mic 2' 'Stereo'
Item0: 'Mic 1'
$ amixer sset "Differential Source" 'Line'
Simple mixer control 'Differential Source',0
Capabilities: enum
Items: 'Mic' 'Line'
Item0: 'Mic'
They refuse to change their Item0 because they are defined as
SND_SOC_DAPM_MUX without a correlating path->name so that
snd_soc_dapm_mux_update_power() (in sound/soc/soc-dapmc) doesn't
change anything.
It works in 2.6.33, but current kernel has different mux handling and
it seems that no one since cared that much about microphone support.
Mark, can you confirm this, purpose a fix or even come up with
a patch?
Thanks,
-- Christoph
^ permalink raw reply
* Re: ASoC: wm9712: Microphone doesn't work: Mux handling broken?
From: Mark Brown @ 2012-05-12 11:51 UTC (permalink / raw)
To: Christoph Fritz
Cc: alsa-devel, Hans J. Koch, Sascha Hauer, Liam Girdwood,
linux-fbdev
In-Reply-To: <20120512001556.GA26105@mars>
[-- Attachment #1: Type: text/plain, Size: 1187 bytes --]
On Sat, May 12, 2012 at 02:15:56AM +0200, Christoph Fritz wrote:
> They refuse to change their Item0 because they are defined as
> SND_SOC_DAPM_MUX without a correlating path->name so that
> snd_soc_dapm_mux_update_power() (in sound/soc/soc-dapmc) doesn't
> change anything.
A route into a mux without a path name (other than a supply) just isn't
meaningful and I'm surprised it ever worked.
> It works in 2.6.33, but current kernel has different mux handling and
> it seems that no one since cared that much about microphone support.
It's nothing to do with microphones really, it's more that AC'97 CODECs
are rarely used with modern kernels as the boards that use AC'97 are
mostly quite old and suffer performance issues with modern software
stacks so newer kernels haven't been getting much testing with them.
> Mark, can you confirm this, purpose a fix or even come up with
> a patch?
Just filling in the appropriate mux value in the relevant route should
do the trick. Looking at the code it looks like the widget isn't hooked
into the audio routing map at all so I'm a little surprised. I'm out of
the office at the minute and so can't readily set up a test system
myself.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* haalloo,
From: abi @ 2012-05-12 16:56 UTC (permalink / raw)
To: linux-fbdev
haalloo,
how are you doing,i hope you are fine,my name is miss abi okom i got your
contact and want us to be a good friend,
please try and write back to me so that i will give you my pictures and tell
you more about me,
^ permalink raw reply
* Re: ASoC: wm9712: Microphone doesn't work: Mux handling broken?
From: Christoph Fritz @ 2012-05-13 3:56 UTC (permalink / raw)
To: Mark Brown
Cc: alsa-devel, Hans J. Koch, Sascha Hauer, Liam Girdwood,
linux-fbdev
In-Reply-To: <20120512115130.GI1781@opensource.wolfsonmicro.com>
On Sat, May 12, 2012 at 12:51:31PM +0100, Mark Brown wrote:
> On Sat, May 12, 2012 at 02:15:56AM +0200, Christoph Fritz wrote:
>
> > They refuse to change their Item0 because they are defined as
> > SND_SOC_DAPM_MUX without a correlating path->name so that
> > snd_soc_dapm_mux_update_power() (in sound/soc/soc-dapmc) doesn't
> > change anything.
>
> A route into a mux without a path name (other than a supply) just isn't
> meaningful and I'm surprised it ever worked.
>
> > It works in 2.6.33, but current kernel has different mux handling and
> > it seems that no one since cared that much about microphone support.
>
> It's nothing to do with microphones really, it's more that AC'97 CODECs
> are rarely used with modern kernels as the boards that use AC'97 are
> mostly quite old and suffer performance issues with modern software
> stacks so newer kernels haven't been getting much testing with them.
>
> > Mark, can you confirm this, purpose a fix or even come up with
> > a patch?
>
> Just filling in the appropriate mux value in the relevant route should
> do the trick. Looking at the code it looks like the widget isn't hooked
> into the audio routing map at all so I'm a little surprised. I'm out of
> the office at the minute and so can't readily set up a test system
> myself.
Thanks Mark, I'm pretty interested in testing too :-)
-- Christoph
^ permalink raw reply
* Re: [PATCH] video/smscufx: fix line counting in fb_write
From: Florian Tobias Schandinat @ 2012-05-13 12:47 UTC (permalink / raw)
To: Alexander Holler; +Cc: linux-kernel, linux-fbdev
In-Reply-To: <4F92995B.6030805@ahsoftware.de>
Hi Alexander,
On 04/21/2012 11:26 AM, Alexander Holler wrote:
> Hello,
>
> as for the patch for udlfb, I forgot to mention that this is a candidate
> for all stable trees 3.2 and above.
>
> Btw., the address of the maintainer doesn't seem to be valid anymore.
it is better to cc me on patches to the framebuffer subsystem for such
cases. I don't have much free time so it's rare that I come around to
dig in the mailing list.
>
> Regards,
>
> Alexander
>
> Am 21.04.2012 00:11, schrieb Alexander Holler:
>> Line 0 and 1 were both written to line 0 (on the display) and all
>> subsequent
>> lines had an offset of -1. The result was that the last line on the
>> display
>> was never overwritten by writes to /dev/fbN.
>>
>> The origin of this bug seems to have been udlfb.
>>
>> Signed-off-by: Alexander Holler<holler@ahsoftware.de>
>
> Cc: stable@vger.kernel.org
Patch looks good to me but can be made simpler.
>
>> ---
>> drivers/video/smscufx.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/video/smscufx.c b/drivers/video/smscufx.c
>> index ccbfef5..1e1e2d2 100644
>> --- a/drivers/video/smscufx.c
>> +++ b/drivers/video/smscufx.c
>> @@ -904,7 +904,7 @@ static ssize_t ufx_ops_write(struct fb_info *info,
>> const char __user *buf,
>> result = fb_sys_write(info, buf, count, ppos);
>>
>> if (result> 0) {
>> - int start = max((int)(offset / info->fix.line_length) - 1, 0);
>> + int start = max((int)(offset / info->fix.line_length), 0);
the cast to int as well as the max is superfluous without the -1 as the
value can no longer be negative.
>> int lines = min((u32)((result / info->fix.line_length) + 1),
>> (u32)info->var.yres);
>>
>
Best regards,
Florian Tobias Schandinat
^ permalink raw reply
* Re: [PATCH] video/sis: Annotate SiS_DRAMType as __devinitconst
From: Florian Tobias Schandinat @ 2012-05-13 13:04 UTC (permalink / raw)
To: Peter Hüwe; +Cc: Thomas Winischhofer, linux-fbdev, linux-kernel
In-Reply-To: <201205102339.09295.PeterHuewe@gmx.de>
Hi Peter,
On 05/10/2012 09:39 PM, Peter Hüwe wrote:
> Am Donnerstag 10 Mai 2012, 02:19:18 schrieb Florian Tobias Schandinat:
>> Good that you did this one, it was more to be done than I expected. I
>> ignored the checkpatch errors as you didn't introduce them but maybe it
>> wouldn't be a bad idea to fix things up if you touch them. Applied.
>
> Oh sorry, usually I do checkpatch, but I missed it on this one somehow.
> If you want, I can do a checkpatch cleanup for the whole sis driver as
> compensation ;)
That's not necessary.
I just wanted to highlight that I prefer it if people fix the style
on-the-fly while working on things rather than sending me individual
patches for each line and not even fixing the complete line but only one
special aspect of it so that checkpatch complains about their style fixes.
btw. Special characters are allowed in sign-offs.
Best regards,
Florian Tobias Schandinat
^ permalink raw reply
* Re: [PULL for v3.5] SH Mobile LCDC overlay support
From: Florian Tobias Schandinat @ 2012-05-13 20:36 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <5022250.LOHRC1DPLO@avalon>
Hi Laurent,
On 04/24/2012 11:31 AM, Laurent Pinchart wrote:
> Hi Florian,
>
> Could you please pull the following patches that add overlay support for the
> SH Mobile LCDC ? They have been posted for review as part of a bigger series
> some time ago.
Well, besides that I dislike everyone inventing his/her own overlay API
and just not having time to propose something that fits everyone your
patch looks mostly okay. Two things:
"That's fine, but you need a Documentation/ABI entry for any new sysfs
file you create." [Greg K-H]
So as far as I understand Gregs statement and your code correct you
should add such thing.
I'm not convinced that you don't leak resources. Is the memory you
allocate with dma_alloc_coherent for the overlays really freed after
normal use and in error paths?
Best regards,
Florian Tobias Schandinat
>
> The following changes since commit d313a86d2efb2c5568832389663322e93e291c59:
>
> i.MX28: Shut down the LCD controller to avoid BootROM sampling bug
> (2012-04-21 21:53:12 +0000)
>
> are available in the git repository at:
> git://linuxtv.org/pinchartl/fbdev.git planes
>
> Laurent Pinchart (3):
> fbdev: sh_mobile_lcdc: Constify sh_mobile_lcdc_fix structure
> fbdev: sh_mobile_lcdc: Rename fb operation handlers with a common prefix
> fbdev: sh_mobile_lcdc: Implement overlays support
>
> drivers/video/sh_mobile_lcdcfb.c | 1004 +++++++++++++++++++++++++++++++++----
> include/video/sh_mobile_lcdc.h | 7 +
> 2 files changed, 915 insertions(+), 96 deletions(-)
>
^ permalink raw reply
* Re: [PATCH] drivers/video/intelfb/intelfbdrv.c: add missing agp_backend_release
From: Florian Tobias Schandinat @ 2012-05-13 20:50 UTC (permalink / raw)
To: Julia Lawall; +Cc: Maik Broemme, kernel-janitors, linux-fbdev, linux-kernel
In-Reply-To: <1334854553-30067-1-git-send-email-Julia.Lawall@lip6.fr>
On 04/19/2012 04:55 PM, Julia Lawall wrote:
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> Release bridge, as done on all other paths out of the function.
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Looks good to me, applied.
Thanks,
Florian Tobias Schandinat
>
> ---
> drivers/video/intelfb/intelfbdrv.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/video/intelfb/intelfbdrv.c b/drivers/video/intelfb/intelfbdrv.c
> index 02fd226..bdcbfba 100644
> --- a/drivers/video/intelfb/intelfbdrv.c
> +++ b/drivers/video/intelfb/intelfbdrv.c
> @@ -680,6 +680,7 @@ static int __devinit intelfb_pci_register(struct pci_dev *pdev,
> + dinfo->fb.size);
> if (!dinfo->aperture.virtual) {
> ERR_MSG("Cannot remap FB region.\n");
> + agp_backend_release(bridge);
> cleanup(dinfo);
> return -ENODEV;
> }
> @@ -689,6 +690,7 @@ static int __devinit intelfb_pci_register(struct pci_dev *pdev,
> INTEL_REG_SIZE);
> if (!dinfo->mmio_base) {
> ERR_MSG("Cannot remap MMIO region.\n");
> + agp_backend_release(bridge);
> cleanup(dinfo);
> return -ENODEV;
> }
>
>
^ permalink raw reply
* Re: [PATCH v2] video: exynos_dp: remove unnecessary header includes
From: Florian Tobias Schandinat @ 2012-05-13 20:51 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <004d01cd29be$b79eb8d0$26dc2a70$%han@samsung.com>
On 05/04/2012 06:25 AM, Jingoo Han wrote:
> Remove unnecessary headers from the file.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/exynos/exynos_dp_core.c | 2 --
> drivers/video/exynos/exynos_dp_reg.c | 2 --
> 2 files changed, 0 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
> index 6e9f3ce..ef4d1ab 100644
> --- a/drivers/video/exynos/exynos_dp_core.c
> +++ b/drivers/video/exynos/exynos_dp_core.c
> @@ -21,8 +21,6 @@
>
> #include <video/exynos_dp.h>
>
> -#include <plat/cpu.h>
> -
> #include "exynos_dp_core.h"
>
> static int exynos_dp_init_dp(struct exynos_dp_device *dp)
> diff --git a/drivers/video/exynos/exynos_dp_reg.c b/drivers/video/exynos/exynos_dp_reg.c
> index 3863726..99bafb8 100644
> --- a/drivers/video/exynos/exynos_dp_reg.c
> +++ b/drivers/video/exynos/exynos_dp_reg.c
> @@ -16,8 +16,6 @@
>
> #include <video/exynos_dp.h>
>
> -#include <plat/cpu.h>
> -
> #include "exynos_dp_core.h"
> #include "exynos_dp_reg.h"
>
^ permalink raw reply
* Re: [PATCH] video: s3c-fb: use pr_debug instead of printk
From: Florian Tobias Schandinat @ 2012-05-13 20:51 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <003701cd2be7$298eda40$7cac8ec0$%han@samsung.com>
On 05/07/2012 12:20 AM, Jingoo Han wrote:
> This patch uses pr_debug instead of printk to allow dynamic debugging.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/s3c-fb.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index ecb82bb..038546a 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -47,7 +47,7 @@
> #ifdef CONFIG_FB_S3C_DEBUG_REGWRITE
> #undef writel
> #define writel(v, r) do { \
> - printk(KERN_DEBUG "%s: %08x => %p\n", __func__, (unsigned int)v, r); \
> + pr_debug("%s: %08x => %p\n", __func__, (unsigned int)v, r); \
> __raw_writel(v, r); \
> } while (0)
> #endif /* FB_S3C_DEBUG_REGWRITE */
^ permalink raw reply
* Re: [PATCH] video: EXYNOS: changes mipi dsi regulator name from vdd10 to vdd11
From: Florian Tobias Schandinat @ 2012-05-13 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4FA71563.5050401@samsung.com>
On 05/07/2012 12:20 AM, Donghwa Lee wrote:
> MIPI DSI uses 1.1v regulator, so change its supply name.
>
> Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
> Signed-off-by: Inki Dae <inki.dae@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/exynos/exynos_mipi_dsi.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c
> index 95e33f0..2e779d3 100644
> --- a/drivers/video/exynos/exynos_mipi_dsi.c
> +++ b/drivers/video/exynos/exynos_mipi_dsi.c
> @@ -58,7 +58,7 @@ static struct mipi_dsim_platform_data *to_dsim_plat(struct platform_device
> }
>
> static struct regulator_bulk_data supplies[] = {
> - { .supply = "vdd10", },
> + { .supply = "vdd11", },
> { .supply = "vdd18", },
> };
>
^ permalink raw reply
* Re: [PATCH 0/4] fbdev: sh_mobile_hdmi: adds HDMI control register support
From: Florian Tobias Schandinat @ 2012-05-13 20:56 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <87lil3mi69.wl%kuninori.morimoto.gx@renesas.com>
Hi Morimoto-san,
On 05/08/2012 04:05 AM, Kuninori Morimoto wrote:
>
> Hi Florian
> Cc: Magnus, Guennadi, Simon
>
> These are sh_mobile_hdmi update patches to supporting
> HDMI control register on latest SuperH chip
>
> Kuninori Morimoto (4):
> fbdev: sh_mobile_hdmi: add hdmi_bit_set() function
> fbdev: sh_mobile_hdmi: add interrupt output option
> fbdev: sh_mobile_hdmi: 32bit register access support
> fbdev: sh_mobile_hdmi: add HDMI Control Register support
I applied these patches.
Thanks,
Florian Tobias Schandinat
>
> These patches add 32bit access support, and init control registers.
> These are tested on Armadillo800eva board
>
> Best regards
> ---
> Kuninori Morimoto
>
^ permalink raw reply
* Re: [PATCH 0/5] video: exynos mipi dsi: fixes some bugs and clean the codes
From: Florian Tobias Schandinat @ 2012-05-13 20:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4FAA0578.3060509@samsung.com>
On 05/09/2012 05:49 AM, Donghwa Lee wrote:
> These patches fix some bugs and clean the codes for exynos mipi dsi
> display driver.
>
> video: exynos mipi dsi: enable interrupt again after sw reset
> :I resend this patch by including this series.
> You can refer the original patch by below url.
> http://marc.info/?l=linux-fbdev&m\x133610770329570&w=2
> video: exynos mipi dsi: Do not use deprecated suspend/resume callbacks
> video: exynos mipi dsi: Avoid races in probe()
> video: exynos mipi dsi: Properly interpret the interrupt source flags
> video: exynos mipi dsi: support reverse panel type
I applied this series (2-5 as I applied the original of 1 earlier).
Thanks,
Florian Tobias Schandinat
>
> Thank you,
> Donghwa Lee
>
^ 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