* [PATCH v16 RESEND 1/7] viafb: rename display_timing to via_display_timing
From: Steffen Trumtrar @ 2013-01-21 11:07 UTC (permalink / raw)
To: devicetree-discuss, David Airlie
Cc: Steffen Trumtrar, Rob Herring, linux-fbdev, dri-devel,
Laurent Pinchart, Thierry Reding, Guennady Liakhovetski,
linux-media, Tomi Valkeinen, Stephen Warren,
Florian Tobias Schandinat, Rob Clark, Leela Krishna Amudala,
Mohammed, Afzal, kernel
In-Reply-To: <1358766482-6275-1-git-send-email-s.trumtrar@pengutronix.de>
The struct display_timing is specific to the via subsystem. The naming leads to
collisions with the new struct display_timing, which is supposed to be a shared
struct between different subsystems.
To clean this up, prepend the existing struct with the subsystem it is specific
to.
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
drivers/video/via/hw.c | 6 +++---
drivers/video/via/hw.h | 2 +-
drivers/video/via/lcd.c | 2 +-
drivers/video/via/share.h | 2 +-
drivers/video/via/via_modesetting.c | 8 ++++----
drivers/video/via/via_modesetting.h | 6 +++---
6 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index 898590d..5563c67 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -1467,10 +1467,10 @@ void viafb_set_vclock(u32 clk, int set_iga)
via_write_misc_reg_mask(0x0C, 0x0C); /* select external clock */
}
-struct display_timing var_to_timing(const struct fb_var_screeninfo *var,
+struct via_display_timing var_to_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres)
{
- struct display_timing timing;
+ struct via_display_timing timing;
u16 dx = (var->xres - cxres) / 2, dy = (var->yres - cyres) / 2;
timing.hor_addr = cxres;
@@ -1491,7 +1491,7 @@ struct display_timing var_to_timing(const struct fb_var_screeninfo *var,
void viafb_fill_crtc_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres, int iga)
{
- struct display_timing crt_reg = var_to_timing(var,
+ struct via_display_timing crt_reg = var_to_timing(var,
cxres ? cxres : var->xres, cyres ? cyres : var->yres);
if (iga = IGA1)
diff --git a/drivers/video/via/hw.h b/drivers/video/via/hw.h
index 6be243c..c3f2572 100644
--- a/drivers/video/via/hw.h
+++ b/drivers/video/via/hw.h
@@ -637,7 +637,7 @@ extern int viafb_LCD_ON;
extern int viafb_DVI_ON;
extern int viafb_hotplug;
-struct display_timing var_to_timing(const struct fb_var_screeninfo *var,
+struct via_display_timing var_to_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres);
void viafb_fill_crtc_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres, int iga);
diff --git a/drivers/video/via/lcd.c b/drivers/video/via/lcd.c
index 1650379..022b0df 100644
--- a/drivers/video/via/lcd.c
+++ b/drivers/video/via/lcd.c
@@ -549,7 +549,7 @@ void viafb_lcd_set_mode(const struct fb_var_screeninfo *var, u16 cxres,
int panel_hres = plvds_setting_info->lcd_panel_hres;
int panel_vres = plvds_setting_info->lcd_panel_vres;
u32 clock;
- struct display_timing timing;
+ struct via_display_timing timing;
struct fb_var_screeninfo panel_var;
const struct fb_videomode *mode_crt_table, *panel_crt_table;
diff --git a/drivers/video/via/share.h b/drivers/video/via/share.h
index 3158dfc..65c65c6 100644
--- a/drivers/video/via/share.h
+++ b/drivers/video/via/share.h
@@ -319,7 +319,7 @@ struct crt_mode_table {
int refresh_rate;
int h_sync_polarity;
int v_sync_polarity;
- struct display_timing crtc;
+ struct via_display_timing crtc;
};
struct io_reg {
diff --git a/drivers/video/via/via_modesetting.c b/drivers/video/via/via_modesetting.c
index 0e431ae..0b414b0 100644
--- a/drivers/video/via/via_modesetting.c
+++ b/drivers/video/via/via_modesetting.c
@@ -30,9 +30,9 @@
#include "debug.h"
-void via_set_primary_timing(const struct display_timing *timing)
+void via_set_primary_timing(const struct via_display_timing *timing)
{
- struct display_timing raw;
+ struct via_display_timing raw;
raw.hor_total = timing->hor_total / 8 - 5;
raw.hor_addr = timing->hor_addr / 8 - 1;
@@ -88,9 +88,9 @@ void via_set_primary_timing(const struct display_timing *timing)
via_write_reg_mask(VIACR, 0x17, 0x80, 0x80);
}
-void via_set_secondary_timing(const struct display_timing *timing)
+void via_set_secondary_timing(const struct via_display_timing *timing)
{
- struct display_timing raw;
+ struct via_display_timing raw;
raw.hor_total = timing->hor_total - 1;
raw.hor_addr = timing->hor_addr - 1;
diff --git a/drivers/video/via/via_modesetting.h b/drivers/video/via/via_modesetting.h
index 06e09fe..f6a6503 100644
--- a/drivers/video/via/via_modesetting.h
+++ b/drivers/video/via/via_modesetting.h
@@ -33,7 +33,7 @@
#define VIA_PITCH_MAX 0x3FF8
-struct display_timing {
+struct via_display_timing {
u16 hor_total;
u16 hor_addr;
u16 hor_blank_start;
@@ -49,8 +49,8 @@ struct display_timing {
};
-void via_set_primary_timing(const struct display_timing *timing);
-void via_set_secondary_timing(const struct display_timing *timing);
+void via_set_primary_timing(const struct via_display_timing *timing);
+void via_set_secondary_timing(const struct via_display_timing *timing);
void via_set_primary_address(u32 addr);
void via_set_secondary_address(u32 addr);
void via_set_primary_pitch(u32 pitch);
--
1.7.10.4
^ permalink raw reply related
* [PATCH v16 RESEND 0/7] of: add display helper
From: Steffen Trumtrar @ 2013-01-21 11:07 UTC (permalink / raw)
To: devicetree-discuss, David Airlie
Cc: Steffen Trumtrar, Rob Herring, linux-fbdev, dri-devel,
Laurent Pinchart, Thierry Reding, Guennady Liakhovetski,
linux-media, Tomi Valkeinen, Stephen Warren,
Florian Tobias Schandinat, Rob Clark, Leela Krishna Amudala,
Mohammed, Afzal, kernel
Hi!
There was still no maintainer, that commented, ack'd, nack'd, apply'd the
series. So, this is just a resend.
The patches were tested with:
- v15 on Tegra by Thierry
- sh-mobile-lcdcfb by Laurent
- MX53QSB by Marek
- Exynos: smdk5250 by Leela
- AM335X EVM & AM335X EVM-SK by Afzal
- imx6q: sabrelite, sabresd by Philipp and me
- imx53: tqma53/mba53 by me
Changes since v15:
- move include/linux/{videomode,display_timing}.h to include/video
- move include/linux/of_{videomode,display_timing}.h to include/video
- reimplement flags: add VESA flags and data flags
- let pixelclock in struct videomode be unsigned long
- rename of_display_timings_exists to of_display_timings_exist
- revise logging/error messages: replace __func__ with np->full_name
- rename pixelclk-inverted to pixelclk-active
- revise comments in code
Changes since v14:
- fix "const struct *" warning
(reported by: Leela Krishna Amudala <l.krishna@samsung.com>)
- return -EINVAL when htotal or vtotal are zero
- remove unreachable code in of_get_display_timings
- include headers in .c files and not implicit in .h
- sort includes alphabetically
- fix lower/uppercase in binding documentation
- rebase onto v3.7-rc7
Changes since v13:
- fix "const struct *" warning
(reported by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>)
- prevent division by zero in fb_videomode_from_videomode
Changes since v12:
- rename struct display_timing to via_display_timing in via subsystem
- fix refreshrate calculation
- fix "const struct *" warnings
(reported by: Manjunathappa, Prakash <prakash.pm@ti.com>)
- some CodingStyle fixes
- rewrite parts of commit messages and display-timings.txt
- let display_timing_get_value get all values instead of just typical
Changes since v11:
- make pointers const where applicable
- add reviewed-by Laurent Pinchart
Changes since v10:
- fix function name (drm_)display_mode_from_videomode
- add acked-by, reviewed-by, tested-by
Changes since v9:
- don't leak memory when previous timings were correct
- CodingStyle fixes
- move blank lines around
Changes since v8:
- fix memory leaks
- change API to be more consistent (foo_from_bar(struct bar, struct foo))
- include headers were necessary
- misc minor bugfixes
Changes since v7:
- move of_xxx to drivers/video
- remove non-binding documentation from display-timings.txt
- squash display_timings and videomode in one patch
- misc minor fixes
Changes since v6:
- get rid of some empty lines etc.
- move functions to their subsystems
- split of_ from non-of_ functions
- add at least some kerneldoc to some functions
Changes since v5:
- removed all display stuff and just describe timings
Changes since v4:
- refactored functions
Changes since v3:
- print error messages
- free alloced memory
- general cleanup
Changes since v2:
- use hardware-near property-names
- provide a videomode structure
- allow ranges for all properties (<min,typ,max>)
- functions to get display_mode or fb_videomode
Regards,
Steffen
Steffen Trumtrar (7):
viafb: rename display_timing to via_display_timing
video: add display_timing and videomode
video: add of helper for display timings/videomode
fbmon: add videomode helpers
fbmon: add of_videomode helpers
drm_modes: add videomode helpers
drm_modes: add of_videomode helpers
.../devicetree/bindings/video/display-timing.txt | 109 +++++++++
drivers/gpu/drm/drm_modes.c | 70 ++++++
drivers/video/Kconfig | 21 ++
drivers/video/Makefile | 4 +
drivers/video/display_timing.c | 24 ++
drivers/video/fbmon.c | 94 ++++++++
drivers/video/of_display_timing.c | 239 ++++++++++++++++++++
drivers/video/of_videomode.c | 54 +++++
drivers/video/via/hw.c | 6 +-
drivers/video/via/hw.h | 2 +-
drivers/video/via/lcd.c | 2 +-
drivers/video/via/share.h | 2 +-
drivers/video/via/via_modesetting.c | 8 +-
drivers/video/via/via_modesetting.h | 6 +-
drivers/video/videomode.c | 39 ++++
include/drm/drmP.h | 9 +
include/linux/fb.h | 8 +
include/video/display_timing.h | 124 ++++++++++
include/video/of_display_timing.h | 20 ++
include/video/of_videomode.h | 18 ++
include/video/videomode.h | 48 ++++
21 files changed, 894 insertions(+), 13 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/display-timing.txt
create mode 100644 drivers/video/display_timing.c
create mode 100644 drivers/video/of_display_timing.c
create mode 100644 drivers/video/of_videomode.c
create mode 100644 drivers/video/videomode.c
create mode 100644 include/video/display_timing.h
create mode 100644 include/video/of_display_timing.h
create mode 100644 include/video/of_videomode.h
create mode 100644 include/video/videomode.h
--
1.7.10.4
^ permalink raw reply
* [PATCH 30/33] video: Convert to devm_ioremap_resource()
From: Thierry Reding @ 2013-01-21 10:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, Dmitry Torokhov, Arnd Bergmann, Wolfram Sang,
Florian Tobias Schandinat, linux-fbdev
In-Reply-To: <1358762966-20791-1-git-send-email-thierry.reding@avionic-design.de>
Convert all uses of devm_request_and_ioremap() to the newly introduced
devm_ioremap_resource() which provides more consistent error handling.
devm_ioremap_resource() provides its own error messages so all explicit
error messages can be removed from the failure code paths.
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: linux-fbdev@vger.kernel.org
---
drivers/video/exynos/exynos_dp_core.c | 8 +++-----
drivers/video/jz4740_fb.c | 6 +++---
drivers/video/omap2/dss/hdmi.c | 8 +++-----
drivers/video/omap2/vrfb.c | 9 ++++-----
drivers/video/s3c-fb.c | 7 +++----
5 files changed, 16 insertions(+), 22 deletions(-)
diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
index 4ef18e2..7aae0bf 100644
--- a/drivers/video/exynos/exynos_dp_core.c
+++ b/drivers/video/exynos/exynos_dp_core.c
@@ -1076,11 +1076,9 @@ static int exynos_dp_probe(struct platform_device *pdev)
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- dp->reg_base = devm_request_and_ioremap(&pdev->dev, res);
- if (!dp->reg_base) {
- dev_err(&pdev->dev, "failed to ioremap\n");
- return -ENOMEM;
- }
+ dp->reg_base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(dp->reg_base))
+ return PTR_ERR(dp->reg_base);
dp->irq = platform_get_irq(pdev, 0);
if (dp->irq = -ENXIO) {
diff --git a/drivers/video/jz4740_fb.c b/drivers/video/jz4740_fb.c
index d999bb5..36979b4 100644
--- a/drivers/video/jz4740_fb.c
+++ b/drivers/video/jz4740_fb.c
@@ -660,9 +660,9 @@ static int jzfb_probe(struct platform_device *pdev)
}
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- jzfb->base = devm_request_and_ioremap(&pdev->dev, mem);
- if (!jzfb->base) {
- ret = -EBUSY;
+ jzfb->base = devm_ioremap_resource(&pdev->dev, mem);
+ if (IS_ERR(jzfb->base)) {
+ ret = PTR_ERR(jzfb->base);
goto err_framebuffer_release;
}
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 769d082..7292364 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -1080,11 +1080,9 @@ static int __init omapdss_hdmihw_probe(struct platform_device *pdev)
}
/* Base address taken from platform */
- hdmi.ip_data.base_wp = devm_request_and_ioremap(&pdev->dev, res);
- if (!hdmi.ip_data.base_wp) {
- DSSERR("can't ioremap WP\n");
- return -ENOMEM;
- }
+ hdmi.ip_data.base_wp = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(hdmi.ip_data.base_wp))
+ return PTR_ERR(hdmi.ip_data.base_wp);
r = hdmi_get_clocks(pdev);
if (r) {
diff --git a/drivers/video/omap2/vrfb.c b/drivers/video/omap2/vrfb.c
index 5d8fdac..10560ef 100644
--- a/drivers/video/omap2/vrfb.c
+++ b/drivers/video/omap2/vrfb.c
@@ -20,6 +20,7 @@
/*#define DEBUG*/
+#include <linux/err.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/ioport.h>
@@ -357,11 +358,9 @@ static int __init vrfb_probe(struct platform_device *pdev)
return -EINVAL;
}
- vrfb_base = devm_request_and_ioremap(&pdev->dev, mem);
- if (!vrfb_base) {
- dev_err(&pdev->dev, "can't ioremap vrfb memory\n");
- return -ENOMEM;
- }
+ vrfb_base = devm_ioremap_resource(&pdev->dev, mem);
+ if (IS_ERR(vrfb_base))
+ return PTR_ERR(vrfb_base);
num_ctxs = pdev->num_resources - 1;
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 9b57a23..968a625 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -1421,10 +1421,9 @@ static int s3c_fb_probe(struct platform_device *pdev)
pm_runtime_enable(sfb->dev);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- sfb->regs = devm_request_and_ioremap(dev, res);
- if (!sfb->regs) {
- dev_err(dev, "failed to map registers\n");
- ret = -ENXIO;
+ sfb->regs = devm_ioremap_resource(dev, res);
+ if (IS_ERR(sfb->regs)) {
+ ret = PTR_ERR(sfb->regs);
goto err_lcd_clk;
}
--
1.8.1.1
^ permalink raw reply related
* Re: [PATCH 2/3] tegra: pwm-backlight: add tegra pwm-bl driver
From: Mark Zhang @ 2013-01-21 8:55 UTC (permalink / raw)
To: Marc Dietrich
Cc: Mark Zhang, Alex Courbot, Thierry Reding, Stephen Warren,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-tegra@vger.kernel.org, gnurou@gmail.com
In-Reply-To: <2440319.UsvGAcXXBp@fb07-iapwap2>
On 01/21/2013 04:52 PM, Marc Dietrich wrote:
> Hi,
>
>>> diff --git a/drivers/video/backlight/pwm_bl_tegra.c
>>> b/drivers/video/backlight/pwm_bl_tegra.c new file mode 100644
>>> index 0000000..8f2195b
>>> --- /dev/null
>>> +++ b/drivers/video/backlight/pwm_bl_tegra.c
>>
>> So according to the filename, I think we can put all tegra boards codes
>> here, right? Just like what you do for Ventana, if I wanna add support
>> for cardhu, I can define similar functions -- let's say "init_cardhu",
>> "exit_cardhu", "notify_cardhu" and "notify_after_cardhu", right?
>>
>> But I think if we do in this way, the file will become very long soon.
>> And there are a lot of redundant codes in it. So do you have any
>> suggestions?
>
> I think we (for PAZ00) will just reuse the ventana code which is sufficient
> for us. But adding "pwm-backlight-ventana" to our DTS may look a bit strange.
> On the other hand, I guess that's why the property is called "compatible".
>
Ah, yeah, that looks strange. :)
Okay, so I know why Alex wants to use panel name while not board name...
> Marc
>
^ permalink raw reply
* Re: [PATCH 2/3] tegra: pwm-backlight: add tegra pwm-bl driver
From: Marc Dietrich @ 2013-01-21 8:52 UTC (permalink / raw)
To: Mark Zhang
Cc: Alexandre Courbot, Thierry Reding, Stephen Warren,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, Mark Zhang,
gnurou-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <50FCEFDE.8000705-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi,
> > diff --git a/drivers/video/backlight/pwm_bl_tegra.c
> > b/drivers/video/backlight/pwm_bl_tegra.c new file mode 100644
> > index 0000000..8f2195b
> > --- /dev/null
> > +++ b/drivers/video/backlight/pwm_bl_tegra.c
>
> So according to the filename, I think we can put all tegra boards codes
> here, right? Just like what you do for Ventana, if I wanna add support
> for cardhu, I can define similar functions -- let's say "init_cardhu",
> "exit_cardhu", "notify_cardhu" and "notify_after_cardhu", right?
>
> But I think if we do in this way, the file will become very long soon.
> And there are a lot of redundant codes in it. So do you have any
> suggestions?
I think we (for PAZ00) will just reuse the ventana code which is sufficient
for us. But adding "pwm-backlight-ventana" to our DTS may look a bit strange.
On the other hand, I guess that's why the property is called "compatible".
Marc
^ permalink raw reply
* Re: [PATCH 2/3] tegra: pwm-backlight: add tegra pwm-bl driver
From: Mark Zhang @ 2013-01-21 8:35 UTC (permalink / raw)
To: Alex Courbot
Cc: Thierry Reding, Stephen Warren,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mark Zhang,
gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
In-Reply-To: <1966511.aoasnExaly@percival>
On 01/21/2013 04:24 PM, Alex Courbot wrote:
> On Monday 21 January 2013 15:35:58 Mark Zhang wrote:
>>> + backlight {
>>> + compatible = "pwm-backlight-ventana";
>>> + brightness-levels = <0 16 32 48 64 80 96 112 128 144 160 176 192
> 208
>>> 224 240 255>; + default-brightness-level = <12>;
>>> +
>>> + pwms = <&pwm 2 5000000>;
>>
>> After read the codes of tegra pwm driver & pwm framework, I got to know
>> the meaning of this property. So I think we need to add a doc(e.g:
>> Documentation/devicetree/bindings/video/backlight/nvidia,tegra20-bl.txt)
>> to explain this, "Documentation/devicetree/bindings/pwm/pwm.txt" doesn't
>> explain this, because this may be different between different pwm drivers.
>
> The bindings are in Documentation/devicetree/bindings/video/backlight/pwm-
> backlight.txt . But you are right that the power supplies and GPIO will
> require a description of their own - I omitted it for this version because I
> am not sure what the driver should be called.
>
The description of this property in pwm-backlight.txt is:
"pwms: OF device-tree PWM specification (see PWM binding[0])
[0]: Documentation/devicetree/bindings/pwm/pwm.txt"
So you can't get any useful infos from that. That's why I propose to add
a tegra specific doc in
"Documentation/devicetree/bindings/video/backlight" directory.
> The panel used on Ventana is a Chunghwa CLAA101WA01A, maybe that's the name we
> should use for the compatible string instead (and rename the driver
> accordingly).
>
>> So according to the filename, I think we can put all tegra boards codes
>> here, right? Just like what you do for Ventana, if I wanna add support
>> for cardhu, I can define similar functions -- let's say "init_cardhu",
>> "exit_cardhu", "notify_cardhu" and "notify_after_cardhu", right?
>
> That was my initial intention, yes.
>
>> But I think if we do in this way, the file will become very long soon.
>> And there are a lot of redundant codes in it. So do you have any
>> suggestions?
>
> If we decide to make a "Tegra" driver, then I don't think the size of the file
> is a big issues, as long as one can easily navigate into it. It will make
> sense to do this since Tegra kernels should include support for all the
> boards.
>
> If we go and name the drivers after their actual panel names, we should
> definitely put them into separate files. The Tegra configuration could then
> include them all by default to make sure all boards are supported.
I don't think use panel name instead of board name is a good idea.
Developers may not be familiar with panel names. So if we use panel
name, we have to search and read a lot of manual to find out what the
panel is.
I'd rather putting all stuffs in pwm_bl_tegra.c than separating them.
Mark
>
> Alex.
>
^ permalink raw reply
* Re: [PATCH 2/3] tegra: pwm-backlight: add tegra pwm-bl driver
From: Alex Courbot @ 2013-01-21 8:24 UTC (permalink / raw)
To: Mark Zhang
Cc: Thierry Reding, Stephen Warren, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org,
Mark Zhang, gnurou@gmail.com
In-Reply-To: <50FCEFDE.8000705@gmail.com>
On Monday 21 January 2013 15:35:58 Mark Zhang wrote:
> > + backlight {
> > + compatible = "pwm-backlight-ventana";
> > + brightness-levels = <0 16 32 48 64 80 96 112 128 144 160 176 192
208
> > 224 240 255>; + default-brightness-level = <12>;
> > +
> > + pwms = <&pwm 2 5000000>;
>
> After read the codes of tegra pwm driver & pwm framework, I got to know
> the meaning of this property. So I think we need to add a doc(e.g:
> Documentation/devicetree/bindings/video/backlight/nvidia,tegra20-bl.txt)
> to explain this, "Documentation/devicetree/bindings/pwm/pwm.txt" doesn't
> explain this, because this may be different between different pwm drivers.
The bindings are in Documentation/devicetree/bindings/video/backlight/pwm-
backlight.txt . But you are right that the power supplies and GPIO will
require a description of their own - I omitted it for this version because I
am not sure what the driver should be called.
The panel used on Ventana is a Chunghwa CLAA101WA01A, maybe that's the name we
should use for the compatible string instead (and rename the driver
accordingly).
> So according to the filename, I think we can put all tegra boards codes
> here, right? Just like what you do for Ventana, if I wanna add support
> for cardhu, I can define similar functions -- let's say "init_cardhu",
> "exit_cardhu", "notify_cardhu" and "notify_after_cardhu", right?
That was my initial intention, yes.
> But I think if we do in this way, the file will become very long soon.
> And there are a lot of redundant codes in it. So do you have any
> suggestions?
If we decide to make a "Tegra" driver, then I don't think the size of the file
is a big issues, as long as one can easily navigate into it. It will make
sense to do this since Tegra kernels should include support for all the
boards.
If we go and name the drivers after their actual panel names, we should
definitely put them into separate files. The Tegra configuration could then
include them all by default to make sure all boards are supported.
Alex.
^ permalink raw reply
* Re: [PATCH 0/3] pwm-backlight: add subdrivers & Tegra support
From: Alex Courbot @ 2013-01-21 8:18 UTC (permalink / raw)
To: Thierry Reding
Cc: Stephen Warren,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mark Zhang,
gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
In-Reply-To: <20130121074928.GE15508-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
Hi Thierry,
On Monday 21 January 2013 15:49:28 Thierry Reding wrote:
> Eventually this should all be covered by the CDF, but since that's not
> ready yet we want something ad-hoc to get the hardware supported. As
> such I would like to see this go into some sort of minimalistic, Tegra-
> specific display/panel framework. I'd prefer to keep the pwm-backlight
> driver as simple and generic as possible, that is, a driver for a PWM-
> controlled backlight.
>
> Another advantage of moving this into a sort of display framework is
> that it may help in defining the requirements for a CDF and that moving
> the code to the CDF should be easier once it is done.
>
> Last but not least, abstracting away the panel allows other things such
> as physical dimensions and display modes to be properly encapsulated. I
> think that power-on/off timing requirements for panels also belong to
> this set since they are usually specific to a given panel.
>
> Maybe adding these drivers to tegra-drm for now would be a good option.
> That way the corresponding glue can be added without a need for inter-
> tree dependencies.
IIRC (because that was a while ago already) having a Tegra-only display
framework is exactly what we wanted to avoid in the first place. This series
does nothing but leverage the callbacks mechanism that already exists in pwm-
backlight and make it available to DT systems. If we start making a Tegra-
specific solution, then other architectures will have to reinvent the wheel
again. I really don't think we want to go that way.
These patches only makes slight changes to pwm_bl.c and do not extend its
capabilities. I agree that a suitable solution will require the CDF, but by
the meantime, let's go for the practical route instead of repeating the same
mistakes (i.e. architecture-specific frameworks) again.
There are certainly better ways to do this, but I'm not convinced at all that
a Tegra-only solution is one of them.
Alex.
^ permalink raw reply
* Re: [PATCH 0/3] pwm-backlight: add subdrivers & Tegra support
From: Thierry Reding @ 2013-01-21 7:49 UTC (permalink / raw)
To: Alexandre Courbot
Cc: Stephen Warren, linux-fbdev, linux-kernel, linux-tegra,
Mark Zhang, gnurou
In-Reply-To: <1358591420-7790-1-git-send-email-acourbot@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 2911 bytes --]
On Sat, Jan 19, 2013 at 07:30:17PM +0900, Alexandre Courbot wrote:
> This series introduces a way to use pwm-backlight hooks with platforms
> that use the device tree through a subdriver system. It also adds support
> for the Tegra-based Ventana board, adding the last missing block to enable
> its panel. Support for other Tegra board can thus be easily added.
>
> I have something else in mind to properly support this (power
> sequences), but this work relies on the GPIO subsystem redesign which will
> take some time. The pwm-backlight subdrivers can do the job by the meantime.
>
> There are a few design points that might need to be discussed:
> 1) Link order is important: subdrivers register themselves in their
> module_init function, which must be called before pwm-backlight's probe.
> This forbids linking subdrivers as separate modules from pwm-backlight.
> 2) The subdriver's data is temporarily passed through the backlight
> device's driver data. This should not hurt, but maybe there is a better way
> to do this.
> 3) Subdrivers must add themselves into pwm-backlight's own of_device_id
> table. It would be cleaner to not have to list subdrivers into
> pwm-backlight's main file, but I cannot think of a way to do otherwise.
>
> Suggestions for the 3 points listed above are very welcome - in any case,
> I hope to make this converge into something mergeable quickly.
>
> Note that these patches are the last missing block to get a functional
> panel on Tegra boards. Using 3.8rc4 and these patches, the internal panel
> on Ventana is usable out-of-the-box. Yay.
Hi Alexandre,
It's great to see you pick this up. I've been meaning to do this myself
but I just can't find the time right now. Generally I think the approach
you've chosen looks good, but I don't think doing it in pwm-backlight is
the right way.
Eventually this should all be covered by the CDF, but since that's not
ready yet we want something ad-hoc to get the hardware supported. As
such I would like to see this go into some sort of minimalistic, Tegra-
specific display/panel framework. I'd prefer to keep the pwm-backlight
driver as simple and generic as possible, that is, a driver for a PWM-
controlled backlight.
Another advantage of moving this into a sort of display framework is
that it may help in defining the requirements for a CDF and that moving
the code to the CDF should be easier once it is done.
Last but not least, abstracting away the panel allows other things such
as physical dimensions and display modes to be properly encapsulated. I
think that power-on/off timing requirements for panels also belong to
this set since they are usually specific to a given panel.
Maybe adding these drivers to tegra-drm for now would be a good option.
That way the corresponding glue can be added without a need for inter-
tree dependencies.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] tegra: pwm-backlight: add tegra pwm-bl driver
From: Mark Zhang @ 2013-01-21 7:35 UTC (permalink / raw)
To: Alexandre Courbot
Cc: Thierry Reding, Stephen Warren,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, Mark Zhang,
gnurou-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1358591420-7790-3-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On 01/19/2013 06:30 PM, Alexandre Courbot wrote:
> Add a PWM-backlight subdriver for Tegra boards, with support for
> Ventana.
>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
[...]
>
> + backlight {
> + compatible = "pwm-backlight-ventana";
> + brightness-levels = <0 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 255>;
> + default-brightness-level = <12>;
> +
> + pwms = <&pwm 2 5000000>;
After read the codes of tegra pwm driver & pwm framework, I got to know
the meaning of this property. So I think we need to add a doc(e.g:
Documentation/devicetree/bindings/video/backlight/nvidia,tegra20-bl.txt)
to explain this, "Documentation/devicetree/bindings/pwm/pwm.txt" doesn't
explain this, because this may be different between different pwm drivers.
> + pwm-names = "backlight";
> +
> + power-supply = <&vdd_bl_reg>;
> + panel-supply = <&vdd_pnl_reg>;
> + bl-gpio = <&gpio 28 0>;
> + bl-panel = <&gpio 10 0>;
> + };
> +
[...]
> diff --git a/drivers/video/backlight/pwm_bl_tegra.c b/drivers/video/backlight/pwm_bl_tegra.c
> new file mode 100644
> index 0000000..8f2195b
> --- /dev/null
> +++ b/drivers/video/backlight/pwm_bl_tegra.c
So according to the filename, I think we can put all tegra boards codes
here, right? Just like what you do for Ventana, if I wanna add support
for cardhu, I can define similar functions -- let's say "init_cardhu",
"exit_cardhu", "notify_cardhu" and "notify_after_cardhu", right?
But I think if we do in this way, the file will become very long soon.
And there are a lot of redundant codes in it. So do you have any
suggestions?
Mark
> @@ -0,0 +1,159 @@
> +/*
> + * pwm-backlight subdriver for Tegra.
> + *
> + * Copyright (c) 2013 NVIDIA CORPORATION. All rights reserved.
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
[...]
> +MODULE_DESCRIPTION("Backlight Driver for Tegra boards");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:pwm-tegra-backlight");
> +
> +
>
^ permalink raw reply
* Re: [PATCH 0/3] pwm-backlight: add subdrivers & Tegra support
From: Mark Zhang @ 2013-01-21 2:59 UTC (permalink / raw)
To: Alexandre Courbot
Cc: Thierry Reding, Stephen Warren,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, Mark Zhang,
gnurou-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <50FCA346.2070608-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Patch is applied OK on 3.8-rc4.
Hmmm.. But I think it's better to make the patch can be applied on
linux-next.
Mark
On 01/21/2013 10:09 AM, Mark Zhang wrote:
> Hi Alex,
>
> This patch set applies failed on tot linux-next(0118). Here is the log:
>
> markz@markz-hp6200:~/tegradrm/official-upstream-kernel$ git am
> ~/Desktop/*.eml
> Applying: pwm-backlight: add subdriver mechanism
> error: patch failed: drivers/video/backlight/pwm_bl.c:35
> error: drivers/video/backlight/pwm_bl.c: patch does not apply
> Patch failed at 0001 pwm-backlight: add subdriver mechanism
> When you have resolved this problem run "git am --resolved".
> If you would prefer to skip this patch, instead run "git am --skip".
> To restore the original branch and stop patching run "git am --abort".
>
> Anyway, I'll try to apply this on 3.8-rc4.
>
> Mark
> On 01/19/2013 06:30 PM, Alexandre Courbot wrote:
>> This series introduces a way to use pwm-backlight hooks with platforms
>> that use the device tree through a subdriver system. It also adds support
>> for the Tegra-based Ventana board, adding the last missing block to enable
>> its panel. Support for other Tegra board can thus be easily added.
>>
>> I have something else in mind to properly support this (power
>> sequences), but this work relies on the GPIO subsystem redesign which will
>> take some time. The pwm-backlight subdrivers can do the job by the meantime.
>>
>> There are a few design points that might need to be discussed:
>> 1) Link order is important: subdrivers register themselves in their
>> module_init function, which must be called before pwm-backlight's probe.
>> This forbids linking subdrivers as separate modules from pwm-backlight.
>> 2) The subdriver's data is temporarily passed through the backlight
>> device's driver data. This should not hurt, but maybe there is a better way
>> to do this.
>> 3) Subdrivers must add themselves into pwm-backlight's own of_device_id
>> table. It would be cleaner to not have to list subdrivers into
>> pwm-backlight's main file, but I cannot think of a way to do otherwise.
>>
>> Suggestions for the 3 points listed above are very welcome - in any case,
>> I hope to make this converge into something mergeable quickly.
>>
>> Note that these patches are the last missing block to get a functional
>> panel on Tegra boards. Using 3.8rc4 and these patches, the internal panel
>> on Ventana is usable out-of-the-box. Yay.
>>
>> Alexandre Courbot (3):
>> pwm-backlight: add subdriver mechanism
>> tegra: pwm-backlight: add tegra pwm-bl driver
>> tegra: ventana: of: add host1x device to DT
>>
>> arch/arm/boot/dts/tegra20-ventana.dts | 29 +++++-
>> arch/arm/configs/tegra_defconfig | 1 +
>> drivers/video/backlight/Kconfig | 7 ++
>> drivers/video/backlight/Makefile | 4 +
>> drivers/video/backlight/pwm_bl.c | 70 ++++++++++++++-
>> drivers/video/backlight/pwm_bl_tegra.c | 159 +++++++++++++++++++++++++++++++++
>> include/linux/pwm_backlight.h | 15 ++++
>> 7 files changed, 281 insertions(+), 4 deletions(-)
>> create mode 100644 drivers/video/backlight/pwm_bl_tegra.c
>>
^ permalink raw reply
* Re: [PATCH 0/3] pwm-backlight: add subdrivers & Tegra support
From: Mark Zhang @ 2013-01-21 2:09 UTC (permalink / raw)
To: Alexandre Courbot
Cc: Thierry Reding, Stephen Warren,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, Mark Zhang,
gnurou-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1358591420-7790-1-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Hi Alex,
This patch set applies failed on tot linux-next(0118). Here is the log:
markz@markz-hp6200:~/tegradrm/official-upstream-kernel$ git am
~/Desktop/*.eml
Applying: pwm-backlight: add subdriver mechanism
error: patch failed: drivers/video/backlight/pwm_bl.c:35
error: drivers/video/backlight/pwm_bl.c: patch does not apply
Patch failed at 0001 pwm-backlight: add subdriver mechanism
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".
Anyway, I'll try to apply this on 3.8-rc4.
Mark
On 01/19/2013 06:30 PM, Alexandre Courbot wrote:
> This series introduces a way to use pwm-backlight hooks with platforms
> that use the device tree through a subdriver system. It also adds support
> for the Tegra-based Ventana board, adding the last missing block to enable
> its panel. Support for other Tegra board can thus be easily added.
>
> I have something else in mind to properly support this (power
> sequences), but this work relies on the GPIO subsystem redesign which will
> take some time. The pwm-backlight subdrivers can do the job by the meantime.
>
> There are a few design points that might need to be discussed:
> 1) Link order is important: subdrivers register themselves in their
> module_init function, which must be called before pwm-backlight's probe.
> This forbids linking subdrivers as separate modules from pwm-backlight.
> 2) The subdriver's data is temporarily passed through the backlight
> device's driver data. This should not hurt, but maybe there is a better way
> to do this.
> 3) Subdrivers must add themselves into pwm-backlight's own of_device_id
> table. It would be cleaner to not have to list subdrivers into
> pwm-backlight's main file, but I cannot think of a way to do otherwise.
>
> Suggestions for the 3 points listed above are very welcome - in any case,
> I hope to make this converge into something mergeable quickly.
>
> Note that these patches are the last missing block to get a functional
> panel on Tegra boards. Using 3.8rc4 and these patches, the internal panel
> on Ventana is usable out-of-the-box. Yay.
>
> Alexandre Courbot (3):
> pwm-backlight: add subdriver mechanism
> tegra: pwm-backlight: add tegra pwm-bl driver
> tegra: ventana: of: add host1x device to DT
>
> arch/arm/boot/dts/tegra20-ventana.dts | 29 +++++-
> arch/arm/configs/tegra_defconfig | 1 +
> drivers/video/backlight/Kconfig | 7 ++
> drivers/video/backlight/Makefile | 4 +
> drivers/video/backlight/pwm_bl.c | 70 ++++++++++++++-
> drivers/video/backlight/pwm_bl_tegra.c | 159 +++++++++++++++++++++++++++++++++
> include/linux/pwm_backlight.h | 15 ++++
> 7 files changed, 281 insertions(+), 4 deletions(-)
> create mode 100644 drivers/video/backlight/pwm_bl_tegra.c
>
^ permalink raw reply
* Re: [PATCH 0/3] pwm-backlight: add subdrivers & Tegra support
From: Mark Zhang @ 2013-01-20 5:51 UTC (permalink / raw)
To: Alexandre Courbot
Cc: Thierry Reding, Stephen Warren, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org,
Alexandre Courbot
In-Reply-To: <CAAVeFuKkw3b-Jw1s7tc8YUyH6sg8ipqBFFxs4tUBrj9_BDsBMA@mail.gmail.com>
On 01/20/2013 01:26 PM, Alexandre Courbot wrote:
> On Sun, Jan 20, 2013 at 12:38 PM, Mark Zhang <markz@nvidia.com> wrote:
>> So this is a non power sequence version of backlight & panel enabling,
>> isn't it? I remember we talked about this several days ago and you
>> mentioned kernel guys want an ad-hoc version(power sequence logics
>> inside driver, not in DT) and I believe this is it, right?
>
> Basically, yes - I still think power-seqs could be useful here
> (especially after seeing the size of these sub-drivers if you want to
> do error checking properly) and plan to give it another shot without
> DT, but this will not happen soon since we need to do some GPIO
> redesign before. You can see what's wrong in the init() function of
> the subdriver: we call a device tree function to obtain the GPIO as
> there is no get function.
>
Okay. I think I got the picture. I'll read the codes when I'm free and I
think I'll understand this better after that.
>> I think finally I can enable Tegra30 cardhu's display after this patch
>> merged.
>
> Yes, feel free to write a subdriver for Cardhu if you like - I'd like
> to see all T20 and T30 boards supported by the time this gets merged.
>
Yep, I can try to do that. I'll let you know if I have problems.
Mark
> Thanks,
> Alex.
>
^ permalink raw reply
* Re: [PATCH 0/3] pwm-backlight: add subdrivers & Tegra support
From: Alexandre Courbot @ 2013-01-20 5:26 UTC (permalink / raw)
To: Mark Zhang
Cc: Thierry Reding, Stephen Warren, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org,
Alexandre Courbot
In-Reply-To: <50FB669C.3020704@nvidia.com>
On Sun, Jan 20, 2013 at 12:38 PM, Mark Zhang <markz@nvidia.com> wrote:
> So this is a non power sequence version of backlight & panel enabling,
> isn't it? I remember we talked about this several days ago and you
> mentioned kernel guys want an ad-hoc version(power sequence logics
> inside driver, not in DT) and I believe this is it, right?
Basically, yes - I still think power-seqs could be useful here
(especially after seeing the size of these sub-drivers if you want to
do error checking properly) and plan to give it another shot without
DT, but this will not happen soon since we need to do some GPIO
redesign before. You can see what's wrong in the init() function of
the subdriver: we call a device tree function to obtain the GPIO as
there is no get function.
> I think finally I can enable Tegra30 cardhu's display after this patch
> merged.
Yes, feel free to write a subdriver for Cardhu if you like - I'd like
to see all T20 and T30 boards supported by the time this gets merged.
Thanks,
Alex.
^ permalink raw reply
* Re: [PATCH 0/3] pwm-backlight: add subdrivers & Tegra support
From: Mark Zhang @ 2013-01-20 3:38 UTC (permalink / raw)
To: Alexandre Courbot
Cc: Thierry Reding, Stephen Warren,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
In-Reply-To: <1358591420-7790-1-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Yeah, thanks Alex. :)
So this is a non power sequence version of backlight & panel enabling,
isn't it? I remember we talked about this several days ago and you
mentioned kernel guys want an ad-hoc version(power sequence logics
inside driver, not in DT) and I believe this is it, right?
I think finally I can enable Tegra30 cardhu's display after this patch
merged.
Mark
On 01/19/2013 06:30 PM, Alexandre Courbot wrote:
> This series introduces a way to use pwm-backlight hooks with platforms
> that use the device tree through a subdriver system. It also adds support
> for the Tegra-based Ventana board, adding the last missing block to enable
> its panel. Support for other Tegra board can thus be easily added.
>
> I have something else in mind to properly support this (power
> sequences), but this work relies on the GPIO subsystem redesign which will
> take some time. The pwm-backlight subdrivers can do the job by the meantime.
>
> There are a few design points that might need to be discussed:
> 1) Link order is important: subdrivers register themselves in their
> module_init function, which must be called before pwm-backlight's probe.
> This forbids linking subdrivers as separate modules from pwm-backlight.
> 2) The subdriver's data is temporarily passed through the backlight
> device's driver data. This should not hurt, but maybe there is a better way
> to do this.
> 3) Subdrivers must add themselves into pwm-backlight's own of_device_id
> table. It would be cleaner to not have to list subdrivers into
> pwm-backlight's main file, but I cannot think of a way to do otherwise.
>
> Suggestions for the 3 points listed above are very welcome - in any case,
> I hope to make this converge into something mergeable quickly.
>
> Note that these patches are the last missing block to get a functional
> panel on Tegra boards. Using 3.8rc4 and these patches, the internal panel
> on Ventana is usable out-of-the-box. Yay.
>
> Alexandre Courbot (3):
> pwm-backlight: add subdriver mechanism
> tegra: pwm-backlight: add tegra pwm-bl driver
> tegra: ventana: of: add host1x device to DT
>
> arch/arm/boot/dts/tegra20-ventana.dts | 29 +++++-
> arch/arm/configs/tegra_defconfig | 1 +
> drivers/video/backlight/Kconfig | 7 ++
> drivers/video/backlight/Makefile | 4 +
> drivers/video/backlight/pwm_bl.c | 70 ++++++++++++++-
> drivers/video/backlight/pwm_bl_tegra.c | 159 +++++++++++++++++++++++++++++++++
> include/linux/pwm_backlight.h | 15 ++++
> 7 files changed, 281 insertions(+), 4 deletions(-)
> create mode 100644 drivers/video/backlight/pwm_bl_tegra.c
>
^ permalink raw reply
* Re: [PATCH v2 2/2] drivers/video: fsl-diu-fb: fix bugs in interrupt handling
From: Anatolij Gustschin @ 2013-01-19 14:19 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1358589550-3246-1-git-send-email-agust@denx.de>
On Sat, 19 Jan 2013 07:51:35 -0600
Timur Tabi <timur@tabi.org> wrote:
> Anatolij Gustschin wrote:
> > Disabling the interrupts in fsl_diu_release() must happen only if all
> > other AOIs are closed. Otherwise closing an overlay plane will disable
> > the interrupts even if the primary frame buffer plane is opened. Add
> > an appropriate check in the release function.
>
> I thought the release function is only called when the driver is unloaded.
> Wouldn't the framebuffers all already be closed by then?
when driver is unloaded the .remove() function is called, which is
fsl_diu_remove().
> > +static inline void fsl_diu_enable_interrupts(struct fsl_diu_data *data)
> > +{
> > + u32 int_mask = INT_UNDRUN; /* enable underrun detection */
> > +
> > + if (IS_ENABLED(CONFIG_NOT_COHERENT_CACHE))
> > + int_mask |= INT_VSYNC; /* enable vertical sync */
>
> Why did you turn this into a run-time check?
actually it is not a run-time check since this code will be optimized
away at compile in cases where CONFIG_NOT_COHERENT_CACHE is not selected
in the kernel config.
Thanks,
Anatolij
^ permalink raw reply
* Re: [PATCH v2 2/2] drivers/video: fsl-diu-fb: fix bugs in interrupt handling
From: Timur Tabi @ 2013-01-19 13:51 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1358589550-3246-1-git-send-email-agust@denx.de>
Anatolij Gustschin wrote:
> Disabling the interrupts in fsl_diu_release() must happen only if all
> other AOIs are closed. Otherwise closing an overlay plane will disable
> the interrupts even if the primary frame buffer plane is opened. Add
> an appropriate check in the release function.
I thought the release function is only called when the driver is unloaded.
Wouldn't the framebuffers all already be closed by then?
> +static inline void fsl_diu_enable_interrupts(struct fsl_diu_data *data)
> +{
> + u32 int_mask = INT_UNDRUN; /* enable underrun detection */
> +
> + if (IS_ENABLED(CONFIG_NOT_COHERENT_CACHE))
> + int_mask |= INT_VSYNC; /* enable vertical sync */
Why did you turn this into a run-time check?
--
Timur Tabi
^ permalink raw reply
* Re: linux-next: Tree for Jan 18 [ BROKEN suspend: jbd2|acpi|pm? ]
From: Sedat Dilek @ 2013-01-19 12:46 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Stephen Rothwell, linux-next, linux-kernel, Theodore Ts'o,
linux-fsdevel, Linux PM List, Linux ACPI, Greg Kroah-Hartman,
Jiri Slaby, alan, linux-fbdev, Ilya Zykov
In-Reply-To: <CA+icZUWG8R93c485zyURzat1BP+f-T0qQmKKXD9N_in1ahwZvQ@mail.gmail.com>
On Sat, Jan 19, 2013 at 3:13 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
> On Sat, Jan 19, 2013 at 2:55 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>> On Sat, Jan 19, 2013 at 12:58 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>>> On Saturday, January 19, 2013 12:41:11 AM Sedat Dilek wrote:
>>>> On Sat, Jan 19, 2013 at 12:39 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>>>> > On Saturday, January 19, 2013 12:28:55 AM Sedat Dilek wrote:
>>>> >> On Sat, Jan 19, 2013 at 12:25 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>>>> >> > On Friday, January 18, 2013 11:56:53 PM Sedat Dilek wrote:
>>>> >> >> On Fri, Jan 18, 2013 at 11:35 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>>>> >> >> > On Fri, Jan 18, 2013 at 11:20 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>>>> >> >> >> On Friday, January 18, 2013 11:11:07 PM Sedat Dilek wrote:
>>>> >> >> >>> On Fri, Jan 18, 2013 at 5:37 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>> >> >> >>> > Hi all,
>>>> >> >> >>> >
>>>> >> >> >>> > Changes since 20130117:
>>>> >> >> >>> >
>>>> >> >> >>> > Undropped tree: samung
>>>> >> >> >>> >
>>>> >> >> >>> > The powerpc tree still had a build failure.
>>>> >> >> >>> >
>>>> >> >> >>> > The driver-core tree gained a build failure for which I applied a merge
>>>> >> >> >>> > fix patch.
>>>> >> >> >>> >
>>>> >> >> >>> > The gpio-lw tree gained a build failure so I used the version from
>>>> >> >> >>> > next-20130117.
>>>> >> >> >>> >
>>>> >> >> >>> > The samsung tree lost the majority of its conflicts but gained more
>>>> >> >> >>> > against the arm-soc and slave-dma tree.
>>>> >> >> >>> >
>>>> >> >> >>> > ----------------------------------------------------------------------------
>>>> >> >> >>> >
>>>> >> >> >>>
>>>> >> >> >>> From my dmesg diff-file:
>>>> >> >> >>>
>>>> >> >> >>> +[ 288.730849] PM: Syncing filesystems ... done.
>>>> >> >> >>> +[ 294.050498] Freezing user space processes ... (elapsed 0.04 seconds) done.
>>>> >> >> >>> +[ 294.097024] Freezing remaining freezable tasks ...
>>>> >> >> >>> +[ 314.098849] Freezing of tasks failed after 20.01 seconds (1 tasks
>>>> >> >> >>> refusing to freeze, wq_busy=0):
>>>> >> >> >>> +[ 314.098862] jbd2/loop0-8 D ffffffff8180d780 0 297 2 0x00000000
>>>> >> >> >>> +[ 314.098865] ffff880117ec5b68 0000000000000046 ffff880117ec5b08
>>>> >> >> >>> ffffffff81044c29
>>>> >> >> >>> +[ 314.098868] ffff88011829dc80 ffff880117ec5fd8 ffff880117ec5fd8
>>>> >> >> >>> ffff880117ec5fd8
>>>> >> >> >>> +[ 314.098871] ffff880119b34560 ffff88011829dc80 ffff880117ec5b68
>>>> >> >> >>> ffff88011fad4738
>>>> >> >> >>> +[ 314.098873] Call Trace:
>>>> >> >> >>> +[ 314.098881] [<ffffffff81044c29>] ? default_spin_lock_flags+0x9/0x10
>>>> >> >> >>> +[ 314.098885] [<ffffffff811c63e0>] ? __wait_on_buffer+0x30/0x30
>>>> >> >> >>> +[ 314.098888] [<ffffffff816b4b59>] schedule+0x29/0x70
>>>> >> >> >>> +[ 314.098890] [<ffffffff816b4c2f>] io_schedule+0x8f/0xd0
>>>> >> >> >>> +[ 314.098892] [<ffffffff811c63ee>] sleep_on_buffer+0xe/0x20
>>>> >> >> >>> +[ 314.098896] [<ffffffff816b342f>] __wait_on_bit+0x5f/0x90
>>>> >> >> >>> +[ 314.098898] [<ffffffff811c5aa1>] ? submit_bh+0x121/0x1e0
>>>> >> >> >>> +[ 314.098900] [<ffffffff811c63e0>] ? __wait_on_buffer+0x30/0x30
>>>> >> >> >>> +[ 314.098903] [<ffffffff816b34dc>] out_of_line_wait_on_bit+0x7c/0x90
>>>> >> >> >>> +[ 314.098906] [<ffffffff8107eb00>] ? autoremove_wake_function+0x40/0x40
>>>> >> >> >>> +[ 314.098909] [<ffffffff811c63de>] __wait_on_buffer+0x2e/0x30
>>>> >> >> >>> +[ 314.098913] [<ffffffff8128a6a1>]
>>>> >> >> >>> jbd2_journal_commit_transaction+0x1791/0x1960
>>>> >> >> >>> +[ 314.098917] [<ffffffff8109269d>] ? sched_clock_cpu+0xbd/0x110
>>>> >> >> >>> +[ 314.098920] [<ffffffff8107eac0>] ? add_wait_queue+0x60/0x60
>>>> >> >> >>> +[ 314.098923] [<ffffffff81069fbf>] ? try_to_del_timer_sync+0x4f/0x70
>>>> >> >> >>> +[ 314.098925] [<ffffffff8128e4e8>] kjournald2+0xb8/0x240
>>>> >> >> >>> +[ 314.098927] [<ffffffff8107eac0>] ? add_wait_queue+0x60/0x60
>>>> >> >> >>> +[ 314.098929] [<ffffffff8128e430>] ? commit_timeout+0x10/0x10
>>>> >> >> >>> +[ 314.098931] [<ffffffff8107ded0>] kthread+0xc0/0xd0
>>>> >> >> >>> +[ 314.098933] [<ffffffff8107de10>] ? flush_kthread_worker+0xb0/0xb0
>>>> >> >> >>> +[ 314.098936] [<ffffffff816be52c>] ret_from_fork+0x7c/0xb0
>>>> >> >> >>> +[ 314.098938] [<ffffffff8107de10>] ? flush_kthread_worker+0xb0/0xb0
>>>> >> >> >>> +[ 314.098969]
>>>> >> >> >>> +[ 314.098970] Restarting kernel threads ... done.
>>>> >> >> >>> +[ 314.099052] Restarting tasks ... done.
>>>> >> >> >>>
>>>> >> >> >>> Please, have a lot at it.
>>>> >> >> >>
>>>> >> >> >> This is a freezer failure while freezing kernel threads, so I don't think it's
>>>> >> >> >> related to ACPI or PM directly.
>>>> >> >> >>
>>>> >> >> >> Does it happen on every suspend?
>>>> >> >> >>
>>>> >> >> >
>>>> >> >> > No, I only did one S/R.
>>>> >> >> >
>>>> >> >> > I have built a 2nd new kernel where I pulled-in latest pm.git#linux-next.
>>>> >> >> > With this kernel two S/Rs were fine - but that says not much.
>>>> >> >> >
>>>> >> >>
>>>> >> >> After several S/Rs on the "buggy" -1 kernel I know see in my syslogs:
>>>> >> >>
>>>> >> >> Jan 18 23:50:02 fambox kernel: [ 141.853828] Disabling non-boot CPUs ...
>>>> >> >> Jan 18 23:50:02 fambox kernel: [ 141.956943] smpboot: CPU 1 is now offline
>>>> >> >> Jan 18 23:50:02 fambox kernel: [ 141.957438] NOHZ: local_softirq_pending 02
>>>> >> >> Jan 18 23:50:02 fambox kernel: [ 141.957454] NOHZ: local_softirq_pending 02
>>>> >> >> Jan 18 23:50:02 fambox kernel: [ 142.060830] smpboot: CPU 2 is now offline
>>>> >> >> Jan 18 23:50:02 fambox kernel: [ 142.164639] smpboot: CPU 3 is now offline
>>>> >> >
>>>> >> > Are you worried about the "local_softirq_pending" messages?
>>>> >> >
>>>> >>
>>>> >> That's the only new messages I have seen after several S/Rs.
>>>> >
>>>> > They are kind of unusual.
>>>> >
>>>> > Anyway, they seem to be related to CPU hotplug (CPU offline), so you can try
>>>> > if you can trigger them through the sysfs CPU offline/online interface.
>>>> >
>>>>
>>>> Can you explain that a bit clearer or give some sample lines for testing?
>>>
>>> There is a sysfs file
>>>
>>> /sys/devices/system/cpu/cpuX/online
>>>
>>> (where X=0,1,2,3,...) for each CPU core in the system. The value read from it
>>> indicates whether or not the given core is online (1 means online). Writing 0
>>> to it means that the given core should be put offline. Writing 1 means to put
>>> it back online. You can simply write first 0s and than 1s to those files
>>> for CPUs > 0 multiple times in a row and see if that triggers messages like the
>>> above. If it does, that may mean there's been a change in kernel/cpu.c, for
>>> example, that causes it to appear. The change may have been made somewhere in
>>> arch/x86 too, though.
>>>
>>>> >> If you have a testcase for me to reproduce it here, I would be happy.
>>>> >
>>>> > Do you mean the freezer-related issue?
>>>> >
>>>>
>>>> Any one as I am still stepping in the dark.
>>>> I checked my disc-space as I built a lot of software today and run
>>>> once out of space.
>>>> But 1.7GiB should be enough on / for testing.
>>>> I wanted to run the new LTP version I built the last days.
>>>> Let's see what I get...
>>>
>>> Stress-testing the freezer is rather easy and doesn't require disk space.
>>> All it takes is to echo "freezer" to /sys/power/pm_test and then do
>>> "echo mem > /sys/power/state && sleep 1" in a loop. This is described in
>>> Documentation/power/basic-pm-debugging.txt IIRC.
>>>
>>
>> [ CCing TTY and FBDEV folks ]
>>
>> [ TESTCASE ]
>>
>> kernel-config: CONFIG_PM_DEBUG=y
>>
>> root# echo "freezer" > /sys/power/pm_test
>>
>> root# echo mem > /sys/power/state && sleep 1
>>
>> This produces several TTY call-traces...
>>
>> +[ 810.417180] ------------[ cut here ]------------
>> +[ 810.417203] WARNING: at drivers/tty/tty_buffer.c:475
>> flush_to_ldisc+0x12f/0x1f0()
>> +[ 810.417207] Hardware name: 530U3BI/530U4BI/530U4BH
>> +[ 810.417210] tty is NULL
>> +[ 791.200932] Freezing remaining freezable tasks ...
>> +[ 810.417213] Modules linked in: bnep rfcomm parport_pc ppdev
>> snd_hda_codec_hdmi snd_hda_codec_realtek coretemp kvm_intel kvm arc4
>> iwldvm ghash_clmulni_intel aesni_intel snd_hda_intel mac80211 xts
>> uvcvideo snd_hda_codec aes_x86_64 lrw snd_hwdep gf128mul
>> videobuf2_vmalloc joydev ablk_helper snd_pcm i915 videobuf2_memops
>> cryptd videobuf2_core snd_page_alloc videodev snd_seq_midi
>> snd_seq_midi_event iwlwifi snd_rawmidi snd_seq i2c_algo_bit snd_timer
>> drm_kms_helper psmouse snd_seq_device drm btusb microcode cfg80211 snd
>> bluetooth serio_raw soundcore lpc_ich samsung_laptop wmi mei mac_hid
>> video lp parport hid_generic r8169 usbhid hid
>> +[ 810.417307] Pid: 37, comm: kworker/0:1 Not tainted
>> 3.8.0-rc4-next20130118-3-iniza-generic #1
>> +[ 810.417310] Call Trace:
>> +[ 810.417325] [<ffffffff81058acf>] warn_slowpath_common+0x7f/0xc0
>> +[ 810.417332] [<ffffffff81058bc6>] warn_slowpath_fmt+0x46/0x50
>> +[ 810.417340] [<ffffffff8141b03f>] flush_to_ldisc+0x12f/0x1f0
>> +[ 810.417349] [<ffffffff81077d95>] process_one_work+0x155/0x460
>> +[ 810.417357] [<ffffffff81078a38>] worker_thread+0x168/0x410
>> +[ 810.417364] [<ffffffff810788d0>] ? manage_workers+0x2c0/0x2c0
>> +[ 810.417371] [<ffffffff8107ded0>] kthread+0xc0/0xd0
>> +[ 810.417377] [<ffffffff8107de10>] ? flush_kthread_worker+0xb0/0xb0
>> +[ 810.417385] [<ffffffff816beaec>] ret_from_fork+0x7c/0xb0
>> +[ 810.417427] [<ffffffff8107de10>] ? flush_kthread_worker+0xb0/0xb0
>> +[ 810.417438] ---[ end trace a302c76f044b14c2 ]---
>>
>> ...and my first reported call-trace is also seen afterwards...
>>
>> +[ 811.192835] Freezing of tasks failed after 20.01 seconds (1 tasks
>> refusing to freeze, wq_busy=0):
>> +[ 811.192957] jbd2/loop0-8 D ffffffff8180d780 0 289 2 0x00000000
>> +[ 811.192966] ffff880118115b68 0000000000000046 ffff880118761720
>> 0000000000000001
>> +[ 811.192974] ffff880118761720 ffff880118115fd8 ffff880118115fd8
>> ffff880118115fd8
>> +[ 811.192981] ffffffff81c15440 ffff880118761720 ffff880118115b68
>> ffff88011fa14738
>> +[ 811.192988] Call Trace:
>> +[ 811.193006] [<ffffffff811c6830>] ? __wait_on_buffer+0x30/0x30
>> +[ 811.193015] [<ffffffff816b5149>] schedule+0x29/0x70
>> +[ 811.193021] [<ffffffff816b521f>] io_schedule+0x8f/0xd0
>> +[ 811.193028] [<ffffffff811c683e>] sleep_on_buffer+0xe/0x20
>> +[ 811.193037] [<ffffffff816b3a1f>] __wait_on_bit+0x5f/0x90
>> +[ 811.193044] [<ffffffff811c5ef1>] ? submit_bh+0x121/0x1e0
>> +[ 811.193051] [<ffffffff811c6830>] ? __wait_on_buffer+0x30/0x30
>> +[ 811.193058] [<ffffffff816b3acc>] out_of_line_wait_on_bit+0x7c/0x90
>> +[ 811.193067] [<ffffffff8107eb00>] ? autoremove_wake_function+0x40/0x40
>> +[ 811.193073] [<ffffffff811c682e>] __wait_on_buffer+0x2e/0x30
>> +[ 811.193085] [<ffffffff8128aaf1>]
>> jbd2_journal_commit_transaction+0x1791/0x1960
>> +[ 811.193093] [<ffffffff816b62de>] ? _raw_spin_lock_irqsave+0x2e/0x40
>> +[ 811.193102] [<ffffffff81069fbf>] ? try_to_del_timer_sync+0x4f/0x70
>> +[ 811.193109] [<ffffffff8128e938>] kjournald2+0xb8/0x240
>> +[ 811.193115] [<ffffffff8107eac0>] ? add_wait_queue+0x60/0x60
>> +[ 811.193120] [<ffffffff8128e880>] ? commit_timeout+0x10/0x10
>> +[ 811.193126] [<ffffffff8107ded0>] kthread+0xc0/0xd0
>> +[ 811.193132] [<ffffffff8107de10>] ? flush_kthread_worker+0xb0/0xb0
>> +[ 811.193139] [<ffffffff816beaec>] ret_from_fork+0x7c/0xb0
>> +[ 811.193144] [<ffffffff8107de10>] ? flush_kthread_worker+0xb0/0xb0
>> +[ 811.193228]
>> +[ 811.193231] Restarting kernel threads ... done.
>> +[ 811.193403] Restarting tasks ... done.
>>
>> Thanks Rafael for the hints and your patience!
>>
>> Hope TTY/FBDEV folks can help.
>>
>> IMPORTANT NOTE:
>> I have tested with some patches on top of Linux-Next (next-20130118),
>> see attached patches file!
>>
>
> This looks like a typo to me...
>
> --- a/drivers/tty/tty_buffer.c
> +++ b/drivers/tty/tty_buffer.c
> @@ -471,7 +471,7 @@ static void flush_to_ldisc(struct work_struct *work)
> unsigned long flags;
> struct tty_ldisc *disc;
>
> - tty = port->itty;
> + tty = port->tty;
> if (WARN_RATELIMIT(tty = NULL, "tty is NULL\n"))
> return;
>
[ CCing Ilya Zykov ]
This was not a good idea :-)!
Sounds like I am hitting what the patch "tty: Correct tty buffer
flush." from Ilya is trying to fix.
Unfortunately, his patch needs to be refreshed against latest tty-next!
I will try it when it is ready.
- Sedat -
[1] http://marc.info/?t\x135452868300003&r=1&w=2
> - Sedat -
>
>> - Sedat -
>>
>>> Thanks,
>>> Rafael
>>>
>>>
>>> --
>>> I speak only for myself.
>>> Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* [PATCH 3/3] tegra: ventana: of: add host1x device to DT
From: Alexandre Courbot @ 2013-01-19 10:30 UTC (permalink / raw)
To: Thierry Reding, Stephen Warren
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, Mark Zhang,
gnurou-Re5JQEeQqe8AvxtiuMwx3w, Alexandre Courbot
In-Reply-To: <1358591420-7790-1-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Add the host1x device and DDC i2c bus to enable internal panel on
Ventana.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
arch/arm/boot/dts/tegra20-ventana.dts | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts b/arch/arm/boot/dts/tegra20-ventana.dts
index a77b529..4477e9c 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -10,6 +10,15 @@
reg = <0x00000000 0x40000000>;
};
+ host1x {
+ dc@54200000 {
+ rgb {
+ status = "okay";
+ nvidia,ddc-i2c-bus = <&lcd_ddc>;
+ };
+ };
+ };
+
pinmux {
pinctrl-names = "default";
pinctrl-0 = <&state_default>;
@@ -341,7 +350,7 @@
#size-cells = <0>;
};
- i2c@1 {
+ lcd_ddc: i2c@1 {
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
--
1.8.1.1
^ permalink raw reply related
* [PATCH 2/3] tegra: pwm-backlight: add tegra pwm-bl driver
From: Alexandre Courbot @ 2013-01-19 10:30 UTC (permalink / raw)
To: Thierry Reding, Stephen Warren
Cc: linux-fbdev, linux-kernel, linux-tegra, Mark Zhang, gnurou,
Alexandre Courbot
In-Reply-To: <1358591420-7790-1-git-send-email-acourbot@nvidia.com>
Add a PWM-backlight subdriver for Tegra boards, with support for
Ventana.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
arch/arm/boot/dts/tegra20-ventana.dts | 18 +++-
arch/arm/configs/tegra_defconfig | 1 +
drivers/video/backlight/Kconfig | 7 ++
drivers/video/backlight/pwm_bl.c | 3 +
drivers/video/backlight/pwm_bl_tegra.c | 159 +++++++++++++++++++++++++++++++++
5 files changed, 186 insertions(+), 2 deletions(-)
create mode 100644 drivers/video/backlight/pwm_bl_tegra.c
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts b/arch/arm/boot/dts/tegra20-ventana.dts
index adc4754..a77b529 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -516,6 +516,20 @@
bus-width = <8>;
};
+ backlight {
+ compatible = "pwm-backlight-ventana";
+ brightness-levels = <0 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 255>;
+ default-brightness-level = <12>;
+
+ pwms = <&pwm 2 5000000>;
+ pwm-names = "backlight";
+
+ power-supply = <&vdd_bl_reg>;
+ panel-supply = <&vdd_pnl_reg>;
+ bl-gpio = <&gpio 28 0>;
+ bl-panel = <&gpio 10 0>;
+ };
+
regulators {
compatible = "simple-bus";
#address-cells = <1>;
@@ -549,7 +563,7 @@
enable-active-high;
};
- regulator@3 {
+ vdd_pnl_reg: regulator@3 {
compatible = "regulator-fixed";
reg = <3>;
regulator-name = "vdd_pnl";
@@ -559,7 +573,7 @@
enable-active-high;
};
- regulator@4 {
+ vdd_bl_reg: regulator@4 {
compatible = "regulator-fixed";
reg = <4>;
regulator-name = "vdd_bl";
diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
index a7827fd..1c46602 100644
--- a/arch/arm/configs/tegra_defconfig
+++ b/arch/arm/configs/tegra_defconfig
@@ -150,6 +150,7 @@ CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
# CONFIG_BACKLIGHT_GENERIC is not set
CONFIG_BACKLIGHT_PWM=y
+CONFIG_BACKLIGHT_PWM_TEGRA=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_LOGO=y
CONFIG_SOUND=y
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 765a945..377a409 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -244,6 +244,13 @@ config BACKLIGHT_PWM
If you have a LCD backlight adjustable by PWM, say Y to enable
this driver.
+config BACKLIGHT_PWM_TEGRA
+ bool "PWM Backlight Driver for Tegra boards"
+ depends on BACKLIGHT_PWM && ARCH_TEGRA
+ help
+ Support backlight power sequencing for Tegra boards.
+ Supported boards: Ventana.
+
config BACKLIGHT_DA903X
tristate "Backlight Driver for DA9030/DA9034 using WLED"
depends on PMIC_DA903X
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index b65a797..1a4a9a3 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -217,6 +217,9 @@ static int pwm_backlight_parse_dt(struct device *dev,
static struct of_device_id pwm_backlight_of_match[] = {
{ .compatible = "pwm-backlight" },
+#ifdef CONFIG_BACKLIGHT_PWM_TEGRA
+ { .compatible = "pwm-backlight-ventana" },
+#endif
{ }
};
diff --git a/drivers/video/backlight/pwm_bl_tegra.c b/drivers/video/backlight/pwm_bl_tegra.c
new file mode 100644
index 0000000..8f2195b
--- /dev/null
+++ b/drivers/video/backlight/pwm_bl_tegra.c
@@ -0,0 +1,159 @@
+/*
+ * pwm-backlight subdriver for Tegra.
+ *
+ * Copyright (c) 2013 NVIDIA CORPORATION. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+#include <linux/err.h>
+#include <linux/module.h>
+#include <linux/pwm_backlight.h>
+#include <linux/regulator/consumer.h>
+#include <linux/gpio.h>
+#include <linux/of_gpio.h>
+#include <linux/list.h>
+#include <linux/delay.h>
+#include <linux/slab.h>
+
+struct ventana_bl_data {
+ struct regulator *vdd_power;
+ struct regulator *vdd_panel;
+ int bl_gpio;
+ int panel_gpio;
+ bool is_on;
+};
+
+static int init_ventana(struct device *dev)
+{
+ struct ventana_bl_data *data;
+ int ret;
+
+ data = devm_kzalloc(dev, sizeof(struct ventana_bl_data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->vdd_power = devm_regulator_get(dev, "power");
+ if (IS_ERR(data->vdd_power)) {
+ dev_err(dev, "cannot get power regulator!\n");
+ return PTR_ERR(data->vdd_power);
+ }
+
+ data->vdd_panel = devm_regulator_get(dev, "panel");
+ if (IS_ERR(data->vdd_panel)) {
+ dev_err(dev, "cannot get panel regulator!\n");
+ return PTR_ERR(data->vdd_panel);
+ }
+
+ ret = of_get_named_gpio(dev->of_node, "bl-gpio", 0);
+ if (ret < 0) {
+ dev_err(dev, "cannot find backlight GPIO!\n");
+ return ret;
+ }
+ data->bl_gpio = ret;
+
+ ret = of_get_named_gpio(dev->of_node, "bl-panel", 0);
+ if (ret < 0) {
+ dev_err(dev, "cannot find panel GPIO!\n");
+ return ret;
+ }
+ data->panel_gpio = ret;
+
+ ret = devm_gpio_request_one(dev, data->bl_gpio,
+ GPIOF_DIR_OUT | GPIOF_OUT_INIT_LOW,
+ "backlight");
+ if (ret < 0) {
+ dev_err(dev, "cannot request backlight GPIO!\n");
+ return ret;
+ }
+
+ ret = devm_gpio_request_one(dev, data->panel_gpio,
+ GPIOF_DIR_OUT | GPIOF_OUT_INIT_LOW,
+ "panel");
+ if (ret < 0) {
+ dev_err(dev, "cannot request panel GPIO!\n");
+ return ret;
+ }
+
+ pwm_backlight_set_subdriver_data(dev, data);
+
+ return 0;
+}
+
+static void exit_ventana(struct device *dev)
+{
+ struct ventana_bl_data *data = pwm_backlight_get_subdriver_data(dev);
+
+ devm_gpio_free(dev, data->panel_gpio);
+ devm_gpio_free(dev, data->bl_gpio);
+ devm_regulator_put(data->vdd_panel);
+ devm_regulator_put(data->vdd_power);
+ devm_kfree(dev, data);
+}
+
+static int notify_ventana(struct device *dev, int brightness)
+{
+ struct ventana_bl_data *data = pwm_backlight_get_subdriver_data(dev);
+ if (brightness && !data->is_on) {
+ regulator_enable(data->vdd_panel);
+ gpio_set_value(data->panel_gpio, 1);
+ usleep_range(200000, 200000);
+ regulator_enable(data->vdd_power);
+ usleep_range(10000, 10000);
+ } else if (!brightness && data->is_on) {
+ gpio_set_value(data->bl_gpio, 0);
+ }
+
+ return brightness;
+}
+
+static void notify_after_ventana(struct device *dev, int brightness)
+{
+ struct ventana_bl_data *data = pwm_backlight_get_subdriver_data(dev);
+ if (brightness && !data->is_on) {
+ gpio_set_value(data->bl_gpio, 1);
+ data->is_on = true;
+ } else if (!brightness && data->is_on) {
+ usleep_range(10000, 10000);
+ regulator_disable(data->vdd_power);
+ usleep_range(200000, 200000);
+ gpio_set_value(data->panel_gpio, 0);
+ regulator_disable(data->vdd_panel);
+ data->is_on = false;
+ }
+}
+
+static struct pwm_backlight_subdriver pwm_backlight_ventana_subdriver = {
+ .name = "pwm-backlight-ventana",
+ .init = init_ventana,
+ .exit = exit_ventana,
+ .notify = notify_ventana,
+ .notify_after = notify_after_ventana,
+};
+
+static int __init pwm_backlight_tegra_init(void)
+{
+ pwm_backlight_add_subdriver(&pwm_backlight_ventana_subdriver);
+ return 0;
+}
+
+static void __exit pwm_backlight_tegra_exit(void)
+{
+ pwm_backlight_remove_subdriver(&pwm_backlight_ventana_subdriver);
+}
+
+module_init(pwm_backlight_tegra_init);
+module_exit(pwm_backlight_tegra_exit);
+
+MODULE_DESCRIPTION("Backlight Driver for Tegra boards");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:pwm-tegra-backlight");
+
+
--
1.8.1.1
^ permalink raw reply related
* [PATCH 1/3] pwm-backlight: add subdriver mechanism
From: Alexandre Courbot @ 2013-01-19 10:30 UTC (permalink / raw)
To: Thierry Reding, Stephen Warren
Cc: linux-fbdev, linux-kernel, linux-tegra, Mark Zhang, gnurou,
Alexandre Courbot
In-Reply-To: <1358591420-7790-1-git-send-email-acourbot@nvidia.com>
PWM-controlled backlights often need additional power control prior
to activating the PWM, typically switching regulators or GPIOs. This has
been done so far through hooks defined in board files, but this
mechanism cannot be used on platforms that rely on the device tree.
This patch introduces a "subdriver" mechanism to the pwm-backlight
driver that allows such hooks to be defined in optionally-compiled
sub-drivers. Every subdriver has its own device tree properties, which
sets the correct hooks to the pwm-backlight driver.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
drivers/video/backlight/Makefile | 4 +++
drivers/video/backlight/pwm_bl.c | 67 +++++++++++++++++++++++++++++++++++++++-
include/linux/pwm_backlight.h | 15 +++++++++
3 files changed, 85 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index e7ce729..df97ab1 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -29,6 +29,10 @@ obj-$(CONFIG_BACKLIGHT_LP855X) += lp855x_bl.o
obj-$(CONFIG_BACKLIGHT_OMAP1) += omap1_bl.o
obj-$(CONFIG_BACKLIGHT_PANDORA) += pandora_bl.o
obj-$(CONFIG_BACKLIGHT_CARILLO_RANCH) += cr_bllcd.o
+# pwm-backlight subdrivers must be listed *before* pwm_bl.o.
+# Link order is important as subdrivers must register themselves
+# before pwm-backlight's probe function can be called.
+obj-$(CONFIG_BACKLIGHT_PWM_TEGRA) += pwm_bl_tegra.o
obj-$(CONFIG_BACKLIGHT_PWM) += pwm_bl.o
obj-$(CONFIG_BACKLIGHT_DA903X) += da903x_bl.o
obj-$(CONFIG_BACKLIGHT_DA9052) += da9052_bl.o
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 069983c..b65a797 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -22,6 +22,7 @@
#include <linux/slab.h>
struct pwm_bl_data {
+ void *subdriver_data;
struct pwm_device *pwm;
struct device *dev;
unsigned int period;
@@ -35,6 +36,54 @@ struct pwm_bl_data {
void (*exit)(struct device *);
};
+static DEFINE_MUTEX(pwm_backlight_subdrivers_mutex);
+static LIST_HEAD(pwm_backlight_subdrivers);
+
+void pwm_backlight_add_subdriver(struct pwm_backlight_subdriver *driver)
+{
+ mutex_lock(&pwm_backlight_subdrivers_mutex);
+ list_add(&driver->list, &pwm_backlight_subdrivers);
+ mutex_unlock(&pwm_backlight_subdrivers_mutex);
+}
+EXPORT_SYMBOL(pwm_backlight_add_subdriver);
+
+void pwm_backlight_remove_subdriver(struct pwm_backlight_subdriver *driver)
+{
+ mutex_lock(&pwm_backlight_subdrivers_mutex);
+ list_del(&driver->list);
+ mutex_unlock(&pwm_backlight_subdrivers_mutex);
+}
+EXPORT_SYMBOL(pwm_backlight_remove_subdriver);
+
+/**
+ * pwm_backlight_set_subdriver_data - set subdriver data
+ * @dev: backlight device which data is to be set
+ * @data: subdriver data
+ *
+ * This function can be called *only* in the init() hook of the subdriver. The
+ * data will be temporarily set as driver data before being retrieved by
+ * the probe() function and moved to its final place.
+ */
+void pwm_backlight_set_subdriver_data(struct device *dev, void *data)
+{
+ dev_set_drvdata(dev, data);
+}
+EXPORT_SYMBOL(pwm_backlight_set_subdriver_data);
+
+/**
+ * pwm_backlight_get_subdriver_data - retrieve subdriver data
+ * @dev: backlight device to get subdriver data of
+ *
+ * This function can be called in any subdriver hook, excepted init().
+ */
+void *pwm_backlight_get_subdriver_data(struct device *dev)
+{
+ struct backlight_device *bl = dev_get_drvdata(dev);
+ struct pwm_bl_data *pb = dev_get_drvdata(&bl->dev);
+ return pb->subdriver_data;
+}
+EXPORT_SYMBOL(pwm_backlight_get_subdriver_data);
+
static int pwm_backlight_update_status(struct backlight_device *bl)
{
struct pwm_bl_data *pb = dev_get_drvdata(&bl->dev);
@@ -98,6 +147,7 @@ static const struct backlight_ops pwm_backlight_ops = {
static int pwm_backlight_parse_dt(struct device *dev,
struct platform_pwm_backlight_data *data)
{
+ struct pwm_backlight_subdriver *subdriver;
struct device_node *node = dev->of_node;
struct property *prop;
int length;
@@ -150,6 +200,17 @@ static int pwm_backlight_parse_dt(struct device *dev,
* backlight power. Support for specifying these needs to be
* added.
*/
+ mutex_lock(&pwm_backlight_subdrivers_mutex);
+ list_for_each_entry(subdriver, &pwm_backlight_subdrivers, list)
+ if (of_device_is_compatible(node, subdriver->name)) {
+ data->init = subdriver->init;
+ data->exit = subdriver->exit;
+ data->notify = subdriver->notify;
+ data->notify_after = subdriver->notify_after;
+ data->check_fb = subdriver->check_fb;
+ break;
+ }
+ mutex_unlock(&pwm_backlight_subdrivers_mutex);
return 0;
}
@@ -201,6 +262,9 @@ static int pwm_backlight_probe(struct platform_device *pdev)
goto err_alloc;
}
+ /* if the init function set subdriver data, move it to correct place */
+ pb->subdriver_data = dev_get_drvdata(&pdev->dev);
+
if (data->levels) {
max = data->levels[data->max_brightness];
pb->levels = data->levels;
@@ -249,10 +313,11 @@ static int pwm_backlight_probe(struct platform_device *pdev)
goto err_alloc;
}
+ platform_set_drvdata(pdev, bl);
+
bl->props.brightness = data->dft_brightness;
backlight_update_status(bl);
- platform_set_drvdata(pdev, bl);
return 0;
err_alloc:
diff --git a/include/linux/pwm_backlight.h b/include/linux/pwm_backlight.h
index 56f4a86..6abe1ef 100644
--- a/include/linux/pwm_backlight.h
+++ b/include/linux/pwm_backlight.h
@@ -20,4 +20,19 @@ struct platform_pwm_backlight_data {
int (*check_fb)(struct device *dev, struct fb_info *info);
};
+struct pwm_backlight_subdriver {
+ struct list_head list;
+ const char *name;
+ int (*init)(struct device *dev);
+ int (*notify)(struct device *dev, int brightness);
+ void (*notify_after)(struct device *dev, int brightness);
+ void (*exit)(struct device *dev);
+ int (*check_fb)(struct device *dev, struct fb_info *info);
+};
+
+void pwm_backlight_add_subdriver(struct pwm_backlight_subdriver *driver);
+void pwm_backlight_remove_subdriver(struct pwm_backlight_subdriver *driver);
+
+void pwm_backlight_set_subdriver_data(struct device *dev, void *data);
+void *pwm_backlight_get_subdriver_data(struct device *dev);
#endif
--
1.8.1.1
^ permalink raw reply related
* [PATCH 0/3] pwm-backlight: add subdrivers & Tegra support
From: Alexandre Courbot @ 2013-01-19 10:30 UTC (permalink / raw)
To: Thierry Reding, Stephen Warren
Cc: linux-fbdev, linux-kernel, linux-tegra, Mark Zhang, gnurou,
Alexandre Courbot
This series introduces a way to use pwm-backlight hooks with platforms
that use the device tree through a subdriver system. It also adds support
for the Tegra-based Ventana board, adding the last missing block to enable
its panel. Support for other Tegra board can thus be easily added.
I have something else in mind to properly support this (power
sequences), but this work relies on the GPIO subsystem redesign which will
take some time. The pwm-backlight subdrivers can do the job by the meantime.
There are a few design points that might need to be discussed:
1) Link order is important: subdrivers register themselves in their
module_init function, which must be called before pwm-backlight's probe.
This forbids linking subdrivers as separate modules from pwm-backlight.
2) The subdriver's data is temporarily passed through the backlight
device's driver data. This should not hurt, but maybe there is a better way
to do this.
3) Subdrivers must add themselves into pwm-backlight's own of_device_id
table. It would be cleaner to not have to list subdrivers into
pwm-backlight's main file, but I cannot think of a way to do otherwise.
Suggestions for the 3 points listed above are very welcome - in any case,
I hope to make this converge into something mergeable quickly.
Note that these patches are the last missing block to get a functional
panel on Tegra boards. Using 3.8rc4 and these patches, the internal panel
on Ventana is usable out-of-the-box. Yay.
Alexandre Courbot (3):
pwm-backlight: add subdriver mechanism
tegra: pwm-backlight: add tegra pwm-bl driver
tegra: ventana: of: add host1x device to DT
arch/arm/boot/dts/tegra20-ventana.dts | 29 +++++-
arch/arm/configs/tegra_defconfig | 1 +
drivers/video/backlight/Kconfig | 7 ++
drivers/video/backlight/Makefile | 4 +
drivers/video/backlight/pwm_bl.c | 70 ++++++++++++++-
drivers/video/backlight/pwm_bl_tegra.c | 159 +++++++++++++++++++++++++++++++++
include/linux/pwm_backlight.h | 15 ++++
7 files changed, 281 insertions(+), 4 deletions(-)
create mode 100644 drivers/video/backlight/pwm_bl_tegra.c
--
1.8.1.1
^ permalink raw reply
* [PATCH v2 2/2] drivers/video: fsl-diu-fb: fix bugs in interrupt handling
From: Anatolij Gustschin @ 2013-01-19 9:59 UTC (permalink / raw)
To: linux-fbdev
Since commit f74de500 "drivers/video: fsl-diu-fb: streamline
enabling of interrupts" the interrupt handling in the driver
is broken. Enabling diu interrupt causes an interrupt storm and
results in system lockup.
The cookie for the interrupt handler function passed to request_irq()
is wrong (it must be a pointer to the diu struct, and not the address
of the pointer to the diu struct). As a result the interrupt handler
can not read diu registers and acknowledge the interrupt. Fix cookie
arguments for request_irq() and free_irq().
Registering the diu interrupt handler in probe() must happen before
install_fb() calls since this function registers framebuffer devices
and if fbcon tries to take over framebuffer after registering a frame
buffer device, it will call fb_open of the diu driver and enable the
interrupts. At this time the diu interrupt handler must be registered
already.
Disabling the interrupts in fsl_diu_release() must happen only if all
other AOIs are closed. Otherwise closing an overlay plane will disable
the interrupts even if the primary frame buffer plane is opened. Add
an appropriate check in the release function.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Cc: Timur Tabi <timur@tabi.org>
---
v2:
- don't add can_handle_irq flag and do the interrupt registration
before registering frame buffers instead.
drivers/video/fsl-diu-fb.c | 58 +++++++++++++++++++++++++-------------------
1 files changed, 33 insertions(+), 25 deletions(-)
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index 4f8a2e4..41fbd94 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -1232,6 +1232,16 @@ static int fsl_diu_ioctl(struct fb_info *info, unsigned int cmd,
return 0;
}
+static inline void fsl_diu_enable_interrupts(struct fsl_diu_data *data)
+{
+ u32 int_mask = INT_UNDRUN; /* enable underrun detection */
+
+ if (IS_ENABLED(CONFIG_NOT_COHERENT_CACHE))
+ int_mask |= INT_VSYNC; /* enable vertical sync */
+
+ clrbits32(&data->diu_reg->int_mask, int_mask);
+}
+
/* turn on fb if count = 1
*/
static int fsl_diu_open(struct fb_info *info, int user)
@@ -1251,19 +1261,7 @@ static int fsl_diu_open(struct fb_info *info, int user)
if (res < 0)
mfbi->count--;
else {
- struct fsl_diu_data *data = mfbi->parent;
-
-#ifdef CONFIG_NOT_COHERENT_CACHE
- /*
- * Enable underrun detection and vertical sync
- * interrupts.
- */
- clrbits32(&data->diu_reg->int_mask,
- INT_UNDRUN | INT_VSYNC);
-#else
- /* Enable underrun detection */
- clrbits32(&data->diu_reg->int_mask, INT_UNDRUN);
-#endif
+ fsl_diu_enable_interrupts(mfbi->parent);
fsl_diu_enable_panel(info);
}
}
@@ -1283,9 +1281,18 @@ static int fsl_diu_release(struct fb_info *info, int user)
mfbi->count--;
if (mfbi->count = 0) {
struct fsl_diu_data *data = mfbi->parent;
+ bool disable = true;
+ int i;
- /* Disable interrupts */
- out_be32(&data->diu_reg->int_mask, 0xffffffff);
+ /* Disable interrupts only if all AOIs are closed */
+ for (i = 0; i < NUM_AOIS; i++) {
+ struct mfb_info *mi = data->fsl_diu_info[i].par;
+
+ if (mi->count)
+ disable = false;
+ }
+ if (disable)
+ out_be32(&data->diu_reg->int_mask, 0xffffffff);
fsl_diu_disable_panel(info);
}
@@ -1614,14 +1621,6 @@ static int fsl_diu_probe(struct platform_device *pdev)
out_be32(&data->diu_reg->desc[1], data->dummy_ad.paddr);
out_be32(&data->diu_reg->desc[2], data->dummy_ad.paddr);
- for (i = 0; i < NUM_AOIS; i++) {
- ret = install_fb(&data->fsl_diu_info[i]);
- if (ret) {
- dev_err(&pdev->dev, "could not register fb %d\n", i);
- goto error;
- }
- }
-
/*
* Older versions of U-Boot leave interrupts enabled, so disable
* all of them and clear the status register.
@@ -1630,12 +1629,21 @@ static int fsl_diu_probe(struct platform_device *pdev)
in_be32(&data->diu_reg->int_status);
ret = request_irq(data->irq, fsl_diu_isr, 0, "fsl-diu-fb",
- &data->diu_reg);
+ data->diu_reg);
if (ret) {
dev_err(&pdev->dev, "could not claim irq\n");
goto error;
}
+ for (i = 0; i < NUM_AOIS; i++) {
+ ret = install_fb(&data->fsl_diu_info[i]);
+ if (ret) {
+ dev_err(&pdev->dev, "could not register fb %d\n", i);
+ free_irq(data->irq, data->diu_reg);
+ goto error;
+ }
+ }
+
sysfs_attr_init(&data->dev_attr.attr);
data->dev_attr.attr.name = "monitor";
data->dev_attr.attr.mode = S_IRUGO|S_IWUSR;
@@ -1667,7 +1675,7 @@ static int fsl_diu_remove(struct platform_device *pdev)
data = dev_get_drvdata(&pdev->dev);
disable_lcdc(&data->fsl_diu_info[0]);
- free_irq(data->irq, &data->diu_reg);
+ free_irq(data->irq, data->diu_reg);
for (i = 0; i < NUM_AOIS; i++)
uninstall_fb(&data->fsl_diu_info[i]);
--
1.7.5.4
^ permalink raw reply related
* [PATCH 4/4] video: vt8500: Update descriptions in video/Kconfig
From: Tony Prisk @ 2013-01-19 6:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358575377-26364-1-git-send-email-linux@prisktech.co.nz>
This patch updates the descriptions for the VIA VT8500 and
Wondermedia WM8xxx-series framebuffer drivers to correctly reflect
which hardware they support.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
---
drivers/video/Kconfig | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 6678daf..3bbb3c1 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1767,7 +1767,7 @@ config FB_AU1200
option au1200fb:panel=<name>.
config FB_VT8500
- bool "VT8500 LCD Driver"
+ bool "VIA VT8500 Framebuffer Driver"
depends on (FB = y) && ARM && ARCH_VT8500
select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS)
select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS)
@@ -1777,14 +1777,15 @@ config FB_VT8500
controller.
config FB_WM8505
- bool "WM8505 frame buffer support"
+ bool "Wondermedia WM8xxx-series framebuffer support"
depends on (FB = y) && ARM && ARCH_VT8500
select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS)
select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS)
select FB_SYS_IMAGEBLIT
help
- This is the framebuffer driver for WonderMedia WM8505/WM8650
- integrated LCD controller.
+ This is the framebuffer driver for WonderMedia WM8xxx-series
+ integrated LCD controller. This driver covers the WM8505, WM8650
+ and WM8850 SoCs.
config FB_WMT_GE_ROPS
bool "VT8500/WM8xxx accelerated raster ops support"
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/4] video: vt8500: Remove unused platform_data/video-vt8500lcdfb.h
From: Tony Prisk @ 2013-01-19 6:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358575377-26364-1-git-send-email-linux@prisktech.co.nz>
With the conversion to devicetree only for arch-vt8500, this
header is no longer required. This patch removes the #include
from the two framebuffer drivers that used it, and the header file.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
---
drivers/video/vt8500lcdfb.c | 2 --
drivers/video/wm8505fb.c | 2 --
include/linux/platform_data/video-vt8500lcdfb.h | 31 -----------------------
3 files changed, 35 deletions(-)
delete mode 100644 include/linux/platform_data/video-vt8500lcdfb.h
diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
index d8cc1f6..1c34821 100644
--- a/drivers/video/vt8500lcdfb.c
+++ b/drivers/video/vt8500lcdfb.c
@@ -30,8 +30,6 @@
#include <linux/platform_device.h>
#include <linux/wait.h>
-#include <linux/platform_data/video-vt8500lcdfb.h>
-
#include "vt8500lcdfb.h"
#ifdef CONFIG_FB_WMT_GE_ROPS
diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
index dd28c26..8c8c129 100644
--- a/drivers/video/wm8505fb.c
+++ b/drivers/video/wm8505fb.c
@@ -32,8 +32,6 @@
#include <linux/of_fdt.h>
#include <linux/memblock.h>
-#include <linux/platform_data/video-vt8500lcdfb.h>
-
#include "wm8505fb_regs.h"
#ifdef CONFIG_FB_WMT_GE_ROPS
diff --git a/include/linux/platform_data/video-vt8500lcdfb.h b/include/linux/platform_data/video-vt8500lcdfb.h
deleted file mode 100644
index 7f399c3..0000000
--- a/include/linux/platform_data/video-vt8500lcdfb.h
+++ /dev/null
@@ -1,31 +0,0 @@
-/*
- * VT8500/WM8505 Frame Buffer platform data definitions
- *
- * Copyright (C) 2010 Ed Spiridonov <edo.rus@gmail.com>
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- */
-
-#ifndef _VT8500FB_H
-#define _VT8500FB_H
-
-#include <linux/fb.h>
-
-struct vt8500fb_platform_data {
- struct fb_videomode mode;
- u32 xres_virtual;
- u32 yres_virtual;
- u32 bpp;
- unsigned long video_mem_phys;
- void *video_mem_virt;
- unsigned long video_mem_len;
-};
-
-#endif /* _VT8500FB_H */
--
1.7.9.5
^ 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