* Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
From: Tomi Valkeinen @ 2014-04-28 6:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140425153150.GA20807@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 479 bytes --]
On 25/04/14 18:31, Tony Lindgren wrote:
> Chances are any mux register in the syscon area already works with
> pinctrl-single,pins or pinctrl-single,bits option. The ones in the
> padconf area should be already mapped so the driver just has to
> request them.
If using the padconf (say omap4_padconf_global for omap4), doesn't that
mean we need to have platform specific bits in the driver? Isn't that
something we've been trying to remove all the time?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 08/13] video/backlight: LM3630A needs PWM
From: Lee Jones @ 2014-04-28 10:14 UTC (permalink / raw)
To: Peter Griffin
Cc: linux-kernel, linaro-kernel, Arnd Bergmann, Jingoo Han, Bryan Wu,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev
In-Reply-To: <1398342509-10243-9-git-send-email-peter.griffin@linaro.org>
> The LM3630A driver cannot be successfully built if we don't
> enable the PWM subsystem. This patch makes that dependency
> explicit in Kconfig and prevents broken randconfig builds.
>
> Based on Arnd Bergmann patch but split out into seperate
> commits per driver based on feedback.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Cc: Bryan Wu <cooloney@gmail.com>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: linux-fbdev@vger.kernel.org
> ---
> drivers/video/backlight/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied thanks.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 10/13] video/pxa: LCD_CORGI needs BACKLIGHT_CLASS_DEVICE
From: Lee Jones @ 2014-04-28 10:15 UTC (permalink / raw)
To: Peter Griffin
Cc: linux-kernel, linaro-kernel, Arnd Bergmann, Jingoo Han, Bryan Wu,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev
In-Reply-To: <1398342509-10243-11-git-send-email-peter.griffin@linaro.org>
> From: Arnd Bergmann <arnd@arndb.de>
>
> This fixes a randconfig build error when BACKLIGHT_CLASS_DEVICE
> is disabled, by describing the dependency in Kconfig,
> as we do for the other drivers in this directory.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Cc: Bryan Wu <cooloney@gmail.com>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: linux-fbdev@vger.kernel.org
> ---
> drivers/video/backlight/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 12/13] video/backlight: LP855X needs PWM
From: Lee Jones @ 2014-04-28 10:16 UTC (permalink / raw)
To: Peter Griffin
Cc: linux-kernel, linaro-kernel, Arnd Bergmann, Jingoo Han, Milo Kim,
Bryan Wu, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
linux-fbdev
In-Reply-To: <1398342509-10243-13-git-send-email-peter.griffin@linaro.org>
> From: Arnd Bergmann <arnd@arndb.de>
>
> The LP855X driver cannot be successfully built if we don't
> enable the PWM subsystem. This patch makes that dependency
> explicit in Kconfig and prevents broken randconfig builds.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Cc: Milo Kim <milo.kim@ti.com>
> Cc: Bryan Wu <cooloney@gmail.com>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: linux-fbdev@vger.kernel.org
> ---
> drivers/video/backlight/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 09/13] video/backlight: LP8788 needs PWM
From: Lee Jones @ 2014-04-28 10:16 UTC (permalink / raw)
To: Peter Griffin
Cc: linux-kernel, linaro-kernel, Arnd Bergmann, Milo Kim, Jingoo Han,
Bryan Wu, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
linux-fbdev
In-Reply-To: <1398342509-10243-10-git-send-email-peter.griffin@linaro.org>
> The LP8788 driver cannot be successfully built if we don't
> enable the PWM subsystem. This patch makes that dependency
> explicit in Kconfig and prevents broken randconfig builds.
>
> Based on Arnd Bergmann patch but split out into seperate
> commits per driver based on feedback.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Cc: Milo Kim <milo.kim@ti.com>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Cc: Bryan Wu <cooloney@gmail.com>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: linux-fbdev@vger.kernel.org
> ---
> drivers/video/backlight/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH] video/backlight: Fix string type mismatch in s6e63m0.c
From: Lee Jones @ 2014-04-28 10:27 UTC (permalink / raw)
To: Masanari Iida; +Cc: jg1.han, cooloney, linux-fbdev, linux-kernel
In-Reply-To: <1398354436-25467-1-git-send-email-standby24x7@gmail.com>
> Fix string type mismatch in s6e63m0_sysfs_show_gamma_table().
> gamma_table_count is defined as unsigned int.
>
> Signed-off-by: Masanari Iida <standby24x7@gmail.com>
> ---
> drivers/video/backlight/s6e63m0.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCHv3 19/41] OMAPDSS: panel-dpi: Add DT support
From: Tomi Valkeinen @ 2014-04-28 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140425235348.GH20807@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 2889 bytes --]
On 26/04/14 02:53, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140424 02:53]:
>> On 18/04/14 18:51, Tony Lindgren wrote:
>>
>>>> + gpio = of_get_gpio(node, 0);
>>>> + if (gpio_is_valid(gpio) || gpio == -ENOENT) {
>>>> + ddata->enable_gpio = gpio;
>>>> + } else {
>>>> + dev_err(&pdev->dev, "failed to parse enable gpio\n");
>>>> + return gpio;
>>>> + }
>>>
>>> We should set the GPIO polarity based on the OF_GPIO_ACTIVE_LOW like
>>> gpio_backlight_probe_dt is doing.
>>
>> Instead of doing it with the old gpio API, and checking the 'active'
>> flag everywhere, I think we can use the new gpiod API which handles the
>> polarity automatically.
>>
>> I attached prototype patches (based on -rc2) for panel dpi using that
>> approach. It's a bit messier than I'd like, because for non-DT boot we
>> need to request the gpio using the old API, and then convert it to
>> gpio_desc. We can remove that code when all the boards use DT.
>>
>> I've compiled tested this only, as I don't have DPI panels I could use.
>> I did try similar approach for TFP410, and it seemed to work fine.
>
> Got these working by updating my test patch to use enable-gpios instead
> of gpios, and had to change from GPIO_ACTIVE_LOW to GPIO_ACTIVE_HIGH.
> Are we now also breaking legacy booting by reversing the polarity?
I don't think so. The GPIOs should be active-high by default, if I'm not
mistaken, so the polarities should be the same for legacy boot with or
without those patches. Of course, I don't have the boards so I have no
idea if the polarities have been correct even before.
debugfs/gpio shows the actual value of the gpio, so you could check from
there what it is.
> In any case, looks like we have some duplicate panel code.. Turns
> out most panel dpi users for omap3 board-*.c files are just
> sharp-ls037v7dw01 panels but configured in QVGA mode. At least for
> EVM and and LDP based on looking at the pictures and the configuration
Hmm, true, board-ldp.c's panel looks very much like sharp-ls037v7dw01.
Which EVM are you talking about?
> pins (using the names kernel):
>
> QVGA = lcd MO
> reset = lcd RESB
> ...
>
> Then the enable_gpio should be just a GPIO controlled 3.3V regulator
> in most cases. I suggest we move them over to ls037v7dw01 and allow
> configuring them both for VGA and QVGA depending on the orientation.
Looking at the panel spec, it has the following pins:
RESB - reset
MO - VGA/QVGA
UD - vertical scanning direction
LR - horizontal scanning direction
INI - power on control
And it needs 3.3V power.
Are you saying that on some boards the gpio used for enable_gpio is
actually used to switch on a 3.3V regulator?
> I guess you do have some device with ls037v7dw01 since you've been
> patching it?
No, I don't have any boards with that panel.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] fbdev: omap2: Fix format string mismatch in display-sysfs.c
From: Masanari Iida @ 2014-04-28 10:54 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen, linux-fbdev, linux-omap; +Cc: Masanari Iida
Fix two format string mismatch in display-sysfs.c
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
---
drivers/video/fbdev/omap2/dss/display-sysfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/display-sysfs.c b/drivers/video/fbdev/omap2/dss/display-sysfs.c
index 5a2095a..5928bc9 100644
--- a/drivers/video/fbdev/omap2/dss/display-sysfs.c
+++ b/drivers/video/fbdev/omap2/dss/display-sysfs.c
@@ -184,7 +184,7 @@ static ssize_t display_rotate_show(struct device *dev,
if (!dssdev->driver->get_rotate)
return -ENOENT;
rotate = dssdev->driver->get_rotate(dssdev);
- return snprintf(buf, PAGE_SIZE, "%u\n", rotate);
+ return snprintf(buf, PAGE_SIZE, "%d\n", rotate);
}
static ssize_t display_rotate_store(struct device *dev,
@@ -215,7 +215,7 @@ static ssize_t display_mirror_show(struct device *dev,
if (!dssdev->driver->get_mirror)
return -ENOENT;
mirror = dssdev->driver->get_mirror(dssdev);
- return snprintf(buf, PAGE_SIZE, "%u\n", mirror);
+ return snprintf(buf, PAGE_SIZE, "%d\n", mirror);
}
static ssize_t display_mirror_store(struct device *dev,
--
2.0.0.rc1
^ permalink raw reply related
* Re: [PATCH] fbdev: omap2: Fix format string mismatch in display-sysfs.c
From: Jingoo Han @ 2014-04-28 11:17 UTC (permalink / raw)
To: 'Masanari Iida', 'Tomi Valkeinen'
Cc: 'Jean-Christophe Plagniol-Villard', linux-fbdev,
linux-omap, 'Jingoo Han'
In-Reply-To: <1398682455-21043-1-git-send-email-standby24x7@gmail.com>
On Monday, April 28, 2014 7:54 PM, Masanari Iida wrote:
>
> Fix two format string mismatch in display-sysfs.c
>
> Signed-off-by: Masanari Iida <standby24x7@gmail.com>
> ---
> drivers/video/fbdev/omap2/dss/display-sysfs.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/dss/display-sysfs.c b/drivers/video/fbdev/omap2/dss/display-
> sysfs.c
> index 5a2095a..5928bc9 100644
> --- a/drivers/video/fbdev/omap2/dss/display-sysfs.c
> +++ b/drivers/video/fbdev/omap2/dss/display-sysfs.c
> @@ -184,7 +184,7 @@ static ssize_t display_rotate_show(struct device *dev,
> if (!dssdev->driver->get_rotate)
> return -ENOENT;
> rotate = dssdev->driver->get_rotate(dssdev);
According to 'struct omap_dss_driver', get_rotate() returns 'u8'.
Then, how about changing the type of 'rotate' variable from 'int'
to 'u8' as below?
--- a/drivers/video/fbdev/omap2/dss/display-sysfs.c
+++ b/drivers/video/fbdev/omap2/dss/display-sysfs.c
@@ -180,7 +180,7 @@ static ssize_t display_rotate_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct omap_dss_device *dssdev = to_dss_device_sysfs(dev);
- int rotate;
+ u8 rotate;
if (!dssdev->driver->get_rotate)
return -ENOENT;
rotate = dssdev->driver->get_rotate(dssdev);
Best regards,
Jingoo Han
> - return snprintf(buf, PAGE_SIZE, "%u\n", rotate);
> + return snprintf(buf, PAGE_SIZE, "%d\n", rotate);
> }
>
> static ssize_t display_rotate_store(struct device *dev,
> @@ -215,7 +215,7 @@ static ssize_t display_mirror_show(struct device *dev,
> if (!dssdev->driver->get_mirror)
> return -ENOENT;
> mirror = dssdev->driver->get_mirror(dssdev);
> - return snprintf(buf, PAGE_SIZE, "%u\n", mirror);
> + return snprintf(buf, PAGE_SIZE, "%d\n", mirror);
> }
>
> static ssize_t display_mirror_store(struct device *dev,
> --
> 2.0.0.rc1
^ permalink raw reply
* Re: [PATCHv3 19/41] OMAPDSS: panel-dpi: Add DT support
From: Tony Lindgren @ 2014-04-28 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <535E30ED.10903@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140428 03:44]:
> On 26/04/14 02:53, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [140424 02:53]:
> >> On 18/04/14 18:51, Tony Lindgren wrote:
> >>
> >>>> + gpio = of_get_gpio(node, 0);
> >>>> + if (gpio_is_valid(gpio) || gpio = -ENOENT) {
> >>>> + ddata->enable_gpio = gpio;
> >>>> + } else {
> >>>> + dev_err(&pdev->dev, "failed to parse enable gpio\n");
> >>>> + return gpio;
> >>>> + }
> >>>
> >>> We should set the GPIO polarity based on the OF_GPIO_ACTIVE_LOW like
> >>> gpio_backlight_probe_dt is doing.
> >>
> >> Instead of doing it with the old gpio API, and checking the 'active'
> >> flag everywhere, I think we can use the new gpiod API which handles the
> >> polarity automatically.
> >>
> >> I attached prototype patches (based on -rc2) for panel dpi using that
> >> approach. It's a bit messier than I'd like, because for non-DT boot we
> >> need to request the gpio using the old API, and then convert it to
> >> gpio_desc. We can remove that code when all the boards use DT.
> >>
> >> I've compiled tested this only, as I don't have DPI panels I could use.
> >> I did try similar approach for TFP410, and it seemed to work fine.
> >
> > Got these working by updating my test patch to use enable-gpios instead
> > of gpios, and had to change from GPIO_ACTIVE_LOW to GPIO_ACTIVE_HIGH.
> > Are we now also breaking legacy booting by reversing the polarity?
>
> I don't think so. The GPIOs should be active-high by default, if I'm not
> mistaken, so the polarities should be the same for legacy boot with or
> without those patches. Of course, I don't have the boards so I have no
> idea if the polarities have been correct even before.
OK
> debugfs/gpio shows the actual value of the gpio, so you could check from
> there what it is.
Yeah that should be checked.
> > In any case, looks like we have some duplicate panel code.. Turns
> > out most panel dpi users for omap3 board-*.c files are just
> > sharp-ls037v7dw01 panels but configured in QVGA mode. At least for
> > EVM and and LDP based on looking at the pictures and the configuration
>
> Hmm, true, board-ldp.c's panel looks very much like sharp-ls037v7dw01.
Yes it seems so also based on the photos of the LCD panel. And 3430sdp
also seems to have something similar but it's upside down.
> Which EVM are you talking about?
The LogicPD omap3 EVMs TMDSEVM3530 and TMDSEVM3730. The am335x EVM
has a different larger panel.
> > pins (using the names kernel):
> >
> > QVGA = lcd MO
> > reset = lcd RESB
> > ...
> >
> > Then the enable_gpio should be just a GPIO controlled 3.3V regulator
> > in most cases. I suggest we move them over to ls037v7dw01 and allow
> > configuring them both for VGA and QVGA depending on the orientation.
>
> Looking at the panel spec, it has the following pins:
>
> RESB - reset
> MO - VGA/QVGA
> UD - vertical scanning direction
> LR - horizontal scanning direction
> INI - power on control
>
> And it needs 3.3V power.
>
> Are you saying that on some boards the gpio used for enable_gpio is
> actually used to switch on a 3.3V regulator?
The 3.3V GPIO regulator is needed in addition to the configurable pins,
I guess some ls037v7dw01 panels only have a subset of the pins
controllable by GPIOs, and the GPIO regulator may be used instead of
the INI. But that's hard to know without schematics.
> > I guess you do have some device with ls037v7dw01 since you've been
> > patching it?
>
> No, I don't have any boards with that panel.
OK. I'll move my boards over to ls037v7dw01 and do a DT conversion
patch for it that just sets a standard gpios property for panel
ls037v7dw01. The gpios entry can have 0 entries in the middle
depending on wiring configuration and there should not be any need
to name each GPIO.
As far as I'm concerned, your panel-dpi patch is fine with me,
and we should not add more configuration to it for the ls037v7dw01
panels.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
From: Tony Lindgren @ 2014-04-28 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <535DFAAE.1010606@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140427 23:53]:
> On 25/04/14 18:31, Tony Lindgren wrote:
>
> > Chances are any mux register in the syscon area already works with
> > pinctrl-single,pins or pinctrl-single,bits option. The ones in the
> > padconf area should be already mapped so the driver just has to
> > request them.
>
> If using the padconf (say omap4_padconf_global for omap4), doesn't that
> mean we need to have platform specific bits in the driver? Isn't that
> something we've been trying to remove all the time?
No, it's all done in a Linux generic way during driver probe, see
drivers/base/pinctrl.c. You just need to define the default pins
in the .dts files. If you need dynamic remuxing in the driver,
you can define other named states that the driver can then toggle
with pinctrl_select_state().
Regards,
Tony
^ permalink raw reply
* LOAN
From: Bakker, K. @ 2014-04-28 17:30 UTC (permalink / raw)
Dear valued customer,
Do you need an urgent loan to pay of your bills, invest more on your business, if yes PREMIUM CAPITAL LOAN offer loan at 3% interest rate. We are fast and reliable when it comes to loan lending contact email: premiumcapitalloan@hotmail.co.uk for more information.
Contact email: premiumcapitalloan@hotmail.co.uk
^ permalink raw reply
* Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
From: Tomi Valkeinen @ 2014-04-29 5:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140428164528.GM20807@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]
On 28/04/14 19:45, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140427 23:53]:
>> On 25/04/14 18:31, Tony Lindgren wrote:
>>
>>> Chances are any mux register in the syscon area already works with
>>> pinctrl-single,pins or pinctrl-single,bits option. The ones in the
>>> padconf area should be already mapped so the driver just has to
>>> request them.
>>
>> If using the padconf (say omap4_padconf_global for omap4), doesn't that
>> mean we need to have platform specific bits in the driver? Isn't that
>> something we've been trying to remove all the time?
>
> No, it's all done in a Linux generic way during driver probe, see
> drivers/base/pinctrl.c. You just need to define the default pins
> in the .dts files. If you need dynamic remuxing in the driver,
> you can define other named states that the driver can then toggle
> with pinctrl_select_state().
omap4_padconf_global is a syscon node, not pinctrl. As syscon just gives
a raw regmap to its memory area, the driver needs to know about the OMAP
control registers to use it.
Pinctrl-single cannot be used for CONTROL_DSIPHY register, as the
register contents are a bit funny and DSI1 and DSI2 bits are mixed
together. And CONTROL_DSIPHY is already in the memory region defined by
the omap4_padconf_global, so I guess it wouldn't be good to map parts of
the same memory region in a pinctrl node.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH 1/2] video: fbdev: Fix format string mismatch in wm8505fb.c
From: Masanari Iida @ 2014-04-29 12:21 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen, linux-fbdev, linux-kernel; +Cc: Masanari Iida
Fix format string mismatch in contrast_show().
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
---
drivers/video/fbdev/wm8505fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/wm8505fb.c b/drivers/video/fbdev/wm8505fb.c
index 537d199..d2fafbb 100644
--- a/drivers/video/fbdev/wm8505fb.c
+++ b/drivers/video/fbdev/wm8505fb.c
@@ -162,7 +162,7 @@ static ssize_t contrast_show(struct device *dev,
struct fb_info *info = dev_get_drvdata(dev);
struct wm8505fb_info *fbi = to_wm8505fb_info(info);
- return sprintf(buf, "%d\n", fbi->contrast);
+ return sprintf(buf, "%u\n", fbi->contrast);
}
static ssize_t contrast_store(struct device *dev,
--
2.0.0.rc1
^ permalink raw reply related
* [PATCH 2/2] video: fbdev: Fix format string mismatch in gbefb.c
From: Masanari Iida @ 2014-04-29 12:21 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen, linux-fbdev, linux-kernel; +Cc: Masanari Iida
In-Reply-To: <1398774115-15353-1-git-send-email-standby24x7@gmail.com>
Fix format string mismatch in gbefb_show_memsize().
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
---
drivers/video/fbdev/gbefb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/gbefb.c b/drivers/video/fbdev/gbefb.c
index 3ec65a8..4aa56ba 100644
--- a/drivers/video/fbdev/gbefb.c
+++ b/drivers/video/fbdev/gbefb.c
@@ -1068,7 +1068,7 @@ static struct fb_ops gbefb_ops = {
static ssize_t gbefb_show_memsize(struct device *dev, struct device_attribute *attr, char *buf)
{
- return snprintf(buf, PAGE_SIZE, "%d\n", gbe_mem_size);
+ return snprintf(buf, PAGE_SIZE, "%u\n", gbe_mem_size);
}
static DEVICE_ATTR(size, S_IRUGO, gbefb_show_memsize, NULL);
--
2.0.0.rc1
^ permalink raw reply related
* Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
From: Tony Lindgren @ 2014-04-29 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <535F37E9.8090609@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140428 22:26]:
> On 28/04/14 19:45, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [140427 23:53]:
> >> On 25/04/14 18:31, Tony Lindgren wrote:
> >>
> >>> Chances are any mux register in the syscon area already works with
> >>> pinctrl-single,pins or pinctrl-single,bits option. The ones in the
> >>> padconf area should be already mapped so the driver just has to
> >>> request them.
> >>
> >> If using the padconf (say omap4_padconf_global for omap4), doesn't that
> >> mean we need to have platform specific bits in the driver? Isn't that
> >> something we've been trying to remove all the time?
> >
> > No, it's all done in a Linux generic way during driver probe, see
> > drivers/base/pinctrl.c. You just need to define the default pins
> > in the .dts files. If you need dynamic remuxing in the driver,
> > you can define other named states that the driver can then toggle
> > with pinctrl_select_state().
>
> omap4_padconf_global is a syscon node, not pinctrl. As syscon just gives
> a raw regmap to its memory area, the driver needs to know about the OMAP
> control registers to use it.
That would be probably best set up the same way we have already set up
for example omap4_padconf_global: tisyscon@4a1005a0. Then drivers can
access it using regmap, see how drivers/regulator/pbias-regulator.c
sets up the pbias regulator with regmap for MMC.
> Pinctrl-single cannot be used for CONTROL_DSIPHY register, as the
> register contents are a bit funny and DSI1 and DSI2 bits are mixed
> together. And CONTROL_DSIPHY is already in the memory region defined by
> the omap4_padconf_global, so I guess it wouldn't be good to map parts of
> the same memory region in a pinctrl node.
If it's more than a mux, then it should not be set up as a pinctrl
register. Looks like CONTROL_DSIPHY is already available for drivers
via regmap as it falls into the *_padconf_global mappings for omap4
and omap5.
Regards,
Tony
^ permalink raw reply
* [PATCH 1/3] drm/dsi: Support device shutdown
From: Thierry Reding @ 2014-04-29 15:28 UTC (permalink / raw)
To: dri-devel, linux-fbdev; +Cc: Stephen Warren
From: Thierry Reding <treding@nvidia.com>
Hook up the MIPI DSI bus's .shutdown() function to allow drivers to
implement code that should be run when a device is shut down.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
drivers/gpu/drm/drm_mipi_dsi.c | 10 ++++++++++
include/drm/drm_mipi_dsi.h | 2 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 09821f46d768..e633df2f68d8 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -282,6 +282,14 @@ static int mipi_dsi_drv_remove(struct device *dev)
return drv->remove(dsi);
}
+static void mipi_dsi_drv_shutdown(struct device *dev)
+{
+ struct mipi_dsi_driver *drv = to_mipi_dsi_driver(dev->driver);
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(dev);
+
+ drv->shutdown(dsi);
+}
+
/**
* mipi_dsi_driver_register - register a driver for DSI devices
* @drv: DSI driver structure
@@ -293,6 +301,8 @@ int mipi_dsi_driver_register(struct mipi_dsi_driver *drv)
drv->driver.probe = mipi_dsi_drv_probe;
if (drv->remove)
drv->driver.remove = mipi_dsi_drv_remove;
+ if (drv->shutdown)
+ drv->driver.shutdown = mipi_dsi_drv_shutdown;
return driver_register(&drv->driver);
}
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 7209df15a3cd..944f33f8ba38 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -135,11 +135,13 @@ ssize_t mipi_dsi_dcs_read(struct mipi_dsi_device *dsi, unsigned int channel,
* @driver: device driver model driver
* @probe: callback for device binding
* @remove: callback for device unbinding
+ * @shutdown: called at shutdown time to quiesce the device
*/
struct mipi_dsi_driver {
struct device_driver driver;
int(*probe)(struct mipi_dsi_device *dsi);
int(*remove)(struct mipi_dsi_device *dsi);
+ void (*shutdown)(struct mipi_dsi_device *dsi);
};
#define to_mipi_dsi_driver(d) container_of(d, struct mipi_dsi_driver, driver)
--
1.9.2
^ permalink raw reply related
* [PATCH 2/3] drm/panel: simple - Disable panel on shutdown
From: Thierry Reding @ 2014-04-29 15:28 UTC (permalink / raw)
To: dri-devel, linux-fbdev; +Cc: Stephen Warren
In-Reply-To: <1398785339-8107-1-git-send-email-thierry.reding@gmail.com>
From: Thierry Reding <treding@nvidia.com>
When a device is shut down, disable the panel to make sure the display
backlight doesn't stay lit.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
drivers/gpu/drm/panel/panel-simple.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 309f29e9234a..a790f4c337cf 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -262,6 +262,13 @@ static int panel_simple_remove(struct device *dev)
return 0;
}
+static void panel_simple_shutdown(struct device *dev)
+{
+ struct panel_simple *panel = dev_get_drvdata(dev);
+
+ panel_simple_disable(&panel->base);
+}
+
static const struct drm_display_mode auo_b101aw03_mode = {
.clock = 51450,
.hdisplay = 1024,
@@ -412,6 +419,11 @@ static int panel_simple_platform_remove(struct platform_device *pdev)
return panel_simple_remove(&pdev->dev);
}
+static void panel_simple_platform_shutdown(struct platform_device *pdev)
+{
+ panel_simple_shutdown(&pdev->dev);
+}
+
static struct platform_driver panel_simple_platform_driver = {
.driver = {
.name = "panel-simple",
@@ -420,6 +432,7 @@ static struct platform_driver panel_simple_platform_driver = {
},
.probe = panel_simple_platform_probe,
.remove = panel_simple_platform_remove,
+ .shutdown = panel_simple_platform_shutdown,
};
struct panel_desc_dsi {
@@ -561,6 +574,11 @@ static int panel_simple_dsi_remove(struct mipi_dsi_device *dsi)
return panel_simple_remove(&dsi->dev);
}
+static void panel_simple_dsi_shutdown(struct mipi_dsi_device *dsi)
+{
+ panel_simple_shutdown(&dsi->dev);
+}
+
static struct mipi_dsi_driver panel_simple_dsi_driver = {
.driver = {
.name = "panel-simple-dsi",
@@ -569,6 +587,7 @@ static struct mipi_dsi_driver panel_simple_dsi_driver = {
},
.probe = panel_simple_dsi_probe,
.remove = panel_simple_dsi_remove,
+ .shutdown = panel_simple_dsi_shutdown,
};
static int __init panel_simple_init(void)
--
1.9.2
^ permalink raw reply related
* [PATCH 3/3] pwm-backlight: Disable backlight on shutdown
From: Thierry Reding @ 2014-04-29 15:28 UTC (permalink / raw)
To: dri-devel, linux-fbdev; +Cc: Stephen Warren
In-Reply-To: <1398785339-8107-1-git-send-email-thierry.reding@gmail.com>
From: Thierry Reding <treding@nvidia.com>
When a device is shut down, make sure to disable the backlight. If it
stays lit, it gives the impression that the device hasn't turned off.
Furthermore keeping the backlight on may consume power, which is not
what users expect when they shut down a device.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
drivers/video/backlight/pwm_bl.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 994f424eb289..b85479b14971 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -368,6 +368,14 @@ static int pwm_backlight_remove(struct platform_device *pdev)
return 0;
}
+static void pwm_backlight_shutdown(struct platform_device *pdev)
+{
+ struct backlight_device *bl = platform_get_drvdata(pdev);
+ struct pwm_bl_data *pb = bl_get_data(bl);
+
+ pwm_backlight_power_off(pb);
+}
+
#ifdef CONFIG_PM_SLEEP
static int pwm_backlight_suspend(struct device *dev)
{
@@ -413,6 +421,7 @@ static struct platform_driver pwm_backlight_driver = {
},
.probe = pwm_backlight_probe,
.remove = pwm_backlight_remove,
+ .shutdown = pwm_backlight_shutdown,
};
module_platform_driver(pwm_backlight_driver);
--
1.9.2
^ permalink raw reply related
* Re: [PATCH 1/3] drm/dsi: Support device shutdown
From: Stephen Warren @ 2014-04-29 15:59 UTC (permalink / raw)
To: Thierry Reding, dri-devel, linux-fbdev
In-Reply-To: <1398785339-8107-1-git-send-email-thierry.reding@gmail.com>
On 04/29/2014 09:28 AM, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Hook up the MIPI DSI bus's .shutdown() function to allow drivers to
> implement code that should be run when a device is shut down.
The series,
Tested-by: Stephen Warren <swarren@nvidia.com>
(On an NVIDIA Tegra Dalmore board. Now, the backlight actually turns off
when the system is shut down. Note that the backlight power on this
system is directly sourced from the AC adapter for some strange reason,
rather than passing through the main system PMIC, and hence backlight
power isn't shut off even when the rest of the system really is powered off)
^ permalink raw reply
* Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
From: Tomi Valkeinen @ 2014-04-29 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140429150529.GA27571@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 816 bytes --]
On 29/04/14 18:05, Tony Lindgren wrote:
>> omap4_padconf_global is a syscon node, not pinctrl. As syscon just gives
>> a raw regmap to its memory area, the driver needs to know about the OMAP
>> control registers to use it.
>
> That would be probably best set up the same way we have already set up
> for example omap4_padconf_global: tisyscon@4a1005a0. Then drivers can
> access it using regmap, see how drivers/regulator/pbias-regulator.c
> sets up the pbias regulator with regmap for MMC.
Right, but it means that the driver will contain platform specific code
for all the omap revisions it supports. Isn't that wrong?
I already have a patch for DSI that uses the syscon-method, and it works
fine. But it's quite ugly, imo, to fiddle with the OMAP control
registers in a driver.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
From: Tomi Valkeinen @ 2014-04-29 16:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <535FD10B.4020108@ti.com>
[-- Attachment #1: Type: text/plain, Size: 982 bytes --]
On 29/04/14 19:19, Tomi Valkeinen wrote:
> On 29/04/14 18:05, Tony Lindgren wrote:
>
>>> omap4_padconf_global is a syscon node, not pinctrl. As syscon just gives
>>> a raw regmap to its memory area, the driver needs to know about the OMAP
>>> control registers to use it.
>>
>> That would be probably best set up the same way we have already set up
>> for example omap4_padconf_global: tisyscon@4a1005a0. Then drivers can
>> access it using regmap, see how drivers/regulator/pbias-regulator.c
>> sets up the pbias regulator with regmap for MMC.
>
> Right, but it means that the driver will contain platform specific code
> for all the omap revisions it supports. Isn't that wrong?
>
> I already have a patch for DSI that uses the syscon-method, and it works
> fine. But it's quite ugly, imo, to fiddle with the OMAP control
> registers in a driver.
Oh, also, if I do that, I need to know both the SoC version and the DSS
version in the driver.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
From: Tony Lindgren @ 2014-04-29 17:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <535FD43B.3030102@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140429 09:33]:
> On 29/04/14 19:19, Tomi Valkeinen wrote:
> > On 29/04/14 18:05, Tony Lindgren wrote:
> >
> >>> omap4_padconf_global is a syscon node, not pinctrl. As syscon just gives
> >>> a raw regmap to its memory area, the driver needs to know about the OMAP
> >>> control registers to use it.
> >>
> >> That would be probably best set up the same way we have already set up
> >> for example omap4_padconf_global: tisyscon@4a1005a0. Then drivers can
> >> access it using regmap, see how drivers/regulator/pbias-regulator.c
> >> sets up the pbias regulator with regmap for MMC.
> >
> > Right, but it means that the driver will contain platform specific code
> > for all the omap revisions it supports. Isn't that wrong?
> >
> > I already have a patch for DSI that uses the syscon-method, and it works
> > fine. But it's quite ugly, imo, to fiddle with the OMAP control
> > registers in a driver.
Anything using the system control module registers should be a separate
driver. And it should ideally be implemeting some Linux generic framework
that the consumer driver can then use. That leaves out the need to export
custom functions.
I guess we don't have a PHY framework for displays though, so how about
just a separate minimal driver under drivers/video/omap2 that uses the
syscon?
> Oh, also, if I do that, I need to know both the SoC version and the DSS
> version in the driver.
Don't you get all you need in the compatible string? Something like
compatible ti,dss-phy-omap5?
Regards,
Tony
^ permalink raw reply
* [PATCH 0/4] OMAPDSS: Add support for panel ls037v7dw01
From: Tony Lindgren @ 2014-04-29 23:52 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Here are few patches to add devicetree support for panel ls037v7dw01
that's found on many omap3 boards. They seem to be often mis-configured
as various panel dpi entries, but really should be move to use panel
ls037v7dw01 instead. This panel is found at least on the omap3 sdp,
ldp, omap3 evm and few other development boards.
Regards,
Tony
Tony Lindgren (4):
OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
OMAPDSS: panel-sharp-ls037v7dw01: update to use gpiod
OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and
ldp
.../bindings/panel/sharp,ls037v7dw01.txt | 53 +++++++
.../arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi | 82 ++++++++++
arch/arm/boot/dts/omap3-evm-37xx.dts | 50 ++++++
arch/arm/boot/dts/omap3-evm-common.dtsi | 47 ++++++
arch/arm/boot/dts/omap3-ldp.dts | 31 +++-
.../omap2/displays-new/panel-sharp-ls037v7dw01.c | 176 ++++++++++++++-------
drivers/video/fbdev/omap2/dss/dss.c | 5 +-
7 files changed, 379 insertions(+), 65 deletions(-)
create mode 100644 Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
create mode 100644 arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
--
1.8.1.1
^ permalink raw reply
* [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
From: Tony Lindgren @ 2014-04-29 23:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1398815562-24113-1-git-send-email-tony@atomide.com>
Otherwise we can get often errors like the following and the
display won't come on:
omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
omapdss APPLY error: SYNC_LOST on channel lcd, restarting
the output with video overlays disabled
There are some earlier references to this issue:
http://www.spinics.net/lists/linux-omap/msg59511.html
http://www.spinics.net/lists/linux-omap/msg59724.html
It seems that it's safe to set the lower values even for 3630.
If we can confirm that 3630 works with the higher values
reliably we can add further detection.
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
drivers/video/fbdev/omap2/dss/dss.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c
index d55266c..ad6561f 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -707,9 +707,10 @@ static const struct dss_features omap34xx_dss_feats __initconst = {
.dpi_select_source = &dss_dpi_select_source_omap2_omap3,
};
+/* Supposedly 3630 can use div 32 mult 2, but that needs to be rechecked */
static const struct dss_features omap3630_dss_feats __initconst = {
- .fck_div_max = 32,
- .dss_fck_multiplier = 1,
+ .fck_div_max = 16,
+ .dss_fck_multiplier = 2,
.parent_clk_name = "dpll4_ck",
.dpi_select_source = &dss_dpi_select_source_omap2_omap3,
};
--
1.8.1.1
^ 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