* [PATCH 16/16] OMAPFB: remove remaining OMAP arch checks
From: Tomi Valkeinen @ 2012-01-24 10:00 UTC (permalink / raw)
To: linux-omap, linux-fbdev; +Cc: archit, tony, Tomi Valkeinen
In-Reply-To: <1327399231-20826-1-git-send-email-tomi.valkeinen@ti.com>
Now that the old omapfb driver is only omap1 display driver, there's no
need to check if the arch is omap1. This patch removes the few remaining
checks for the arch.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap/Makefile | 6 ++----
drivers/video/omap/omapfb.h | 4 ----
drivers/video/omap/omapfb_main.c | 3 +--
3 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile
index 7965375..1927faf 100644
--- a/drivers/video/omap/Makefile
+++ b/drivers/video/omap/Makefile
@@ -4,11 +4,9 @@
obj-$(CONFIG_FB_OMAP) += omapfb.o
-objs-yy := omapfb_main.o
+objs-yy := omapfb_main.o lcdc.o
-objs-y$(CONFIG_ARCH_OMAP1) += lcdc.o
-
-objs-$(CONFIG_ARCH_OMAP1)$(CONFIG_FB_OMAP_LCDC_EXTERNAL) += sossi.o
+objs-y$(CONFIG_FB_OMAP_LCDC_EXTERNAL) += sossi.o
objs-y$(CONFIG_FB_OMAP_LCDC_HWA742) += hwa742.o
diff --git a/drivers/video/omap/omapfb.h b/drivers/video/omap/omapfb.h
index 07fe498..2921d20 100644
--- a/drivers/video/omap/omapfb.h
+++ b/drivers/video/omap/omapfb.h
@@ -47,11 +47,7 @@
struct omapfb_device;
-#ifdef CONFIG_ARCH_OMAP1
#define OMAPFB_PLANE_NUM 1
-#else
-#define OMAPFB_PLANE_NUM 3
-#endif
struct omapfb_mem_region {
u32 paddr;
diff --git a/drivers/video/omap/omapfb_main.c b/drivers/video/omap/omapfb_main.c
index 3d2e147..f54b463 100644
--- a/drivers/video/omap/omapfb_main.c
+++ b/drivers/video/omap/omapfb_main.c
@@ -1741,8 +1741,7 @@ static int omapfb_do_probe(struct platform_device *pdev,
#ifdef CONFIG_FB_OMAP_DMA_TUNE
/* Set DMA priority for EMIFF access to highest */
- if (cpu_class_is_omap1())
- omap_set_dma_priority(0, OMAP_DMA_PORT_EMIFF, 15);
+ omap_set_dma_priority(0, OMAP_DMA_PORT_EMIFF, 15);
#endif
r = ctrl_change_mode(fbdev->fb_info[0]);
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH] fbdev: sh_mipi_dsi: add extra settings method for platform
From: Laurent Pinchart @ 2012-01-24 10:09 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <874nvnhupd.wl%kuninori.morimoto.gx@renesas.com>
On Tuesday 24 January 2012 01:48:55 Kuninori Morimoto wrote:
> Hi Laurent
> Cc Magnus, Guennadi
>
> Thank you for checking patch
You're welcome.
> > > + void (*set_dcs)(int handle,
> > > + int (*mipi_dcs)(int handle, u8 cmd),
> > > + int (*mipi_dcs_param)(int handle, u8 cmd, u8 param));
> >
> > I don't think this is a good idea. First of all, we should reduce the
> > number of board code callbacks to make transition to the device tree
> > easier. Then, passing two functions to board code to read and write any
> > device register without the driver having any knowledge about that is a
> > clear violation of the device model, and will result in problems sooner
> > or later.
> >
> > What MIPI settings do platforms need to modify ? Can those settings be
> > expressed as data in the sh_mipi_dsi_info structure instead ?
>
> Hmm... now I'm in dilemma.
> Actually this is v2 patch for mipi display.
> (v1 patch was dropped since merge window issue)
>
> The v1 patch was data-table style for mipi display initialization.
> (if platform had init data-table, driver used it)
>
> But someone reviewed it and teach me that it is not-good idea.
> So, I created this style in v2.
>
> Now platform needs "backlight ON" and "memory write ON" command,
> but I could not find these command on include/video/mipi_display.h.
> So, I thought it is platform specific command.
Why does the platform need that ? Please correct me if I'm wrong, but it seems
to me that what you're trying to do is configure and control the display
panel. I don't think that's platform-specific, it should be panel-specific
instead. It looks to me like the right solution would be to write a display
panel driver, similar to what is done for the OMAP2+ platform
(drivers/video/omap2/displays).
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] fbdev: sh_mipi_dsi: add extra settings method for platform
From: Magnus Damm @ 2012-01-24 10:44 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <874nvnhupd.wl%kuninori.morimoto.gx@renesas.com>
On Tue, Jan 24, 2012 at 7:09 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Tuesday 24 January 2012 01:48:55 Kuninori Morimoto wrote:
>> Hi Laurent
>> Cc Magnus, Guennadi
>>
>> Thank you for checking patch
>
> You're welcome.
>
>> > > + void (*set_dcs)(int handle,
>> > > + int (*mipi_dcs)(int handle, u8 cmd),
>> > > + int (*mipi_dcs_param)(int handle, u8 cmd, u8 param));
>> >
>> > I don't think this is a good idea. First of all, we should reduce the
>> > number of board code callbacks to make transition to the device tree
>> > easier. Then, passing two functions to board code to read and write any
>> > device register without the driver having any knowledge about that is a
>> > clear violation of the device model, and will result in problems sooner
>> > or later.
>> >
>> > What MIPI settings do platforms need to modify ? Can those settings be
>> > expressed as data in the sh_mipi_dsi_info structure instead ?
>>
>> Hmm... now I'm in dilemma.
>> Actually this is v2 patch for mipi display.
>> (v1 patch was dropped since merge window issue)
>>
>> The v1 patch was data-table style for mipi display initialization.
>> (if platform had init data-table, driver used it)
>>
>> But someone reviewed it and teach me that it is not-good idea.
>> So, I created this style in v2.
>>
>> Now platform needs "backlight ON" and "memory write ON" command,
>> but I could not find these command on include/video/mipi_display.h.
>> So, I thought it is platform specific command.
>
> Why does the platform need that ? Please correct me if I'm wrong, but it seems
> to me that what you're trying to do is configure and control the display
> panel. I don't think that's platform-specific, it should be panel-specific
> instead. It looks to me like the right solution would be to write a display
> panel driver, similar to what is done for the OMAP2+ platform
> (drivers/video/omap2/displays).
I think that it is a very good recommendation to solve this in theory,
but in practice we've never really seen anyone use the same LCD module
and/or on-glass LCD controller for another board. What I've done so
far is to write the part number of the LCD module together with LCD
controller part number and hopefully also LCD panel configuration
together with the register settings so it is possible to search and
consolidate at some point when we have multiple users.
I'm not sure about this particular case, but I've seen quite much code
that just has a set of LCD controller register settings without
documentation, and it's kind of hard to turn that into a proper
driver. Especially since these register settings are both related to
the on-module LCD controller and LCD panel that together form a LCD
module. We usually don't know which setting is for what part. And we
probably would like to abstract the module into separate pieces of
code for different parts. I've seen some data sheet of a on-module LCD
controller and it was about 800 pages I believe, so it's not exactly
something you can cook up in an afternoon. And add closed MIPI specs
and all sorts of fun and this can take forever. =)
That aside, it would be really nice to see some proper drivers for LCD modules.
Cheers,
/ magnus
^ permalink raw reply
* [PATCH 0/3]: ARM: OMAP2/3: HWMOD fixes for DSS
From: Tomi Valkeinen @ 2012-01-24 10:45 UTC (permalink / raw)
To: linux-omap, linux-fbdev, paul; +Cc: archit, Tomi Valkeinen
There are some sysconfig flags missing for OMAP2/3 DSS hwmods. This series adds
those.
This series is based on the earlier series "[PATCH 0/3] OMAP: DSS PM fixes",
but is sent separately here as the first series is inteded to go into the next
rc, and this can be left to next merge window.
Tested on OMAP3 Overo. I don't have OMAP3 DSI or RFBI boards, so I haven't been
able to test those.
Tomi
Tomi Valkeinen (3):
ARM: OMAP2/3: HWMOD: Add missing flags for dispc class
ARM: OMAP2/3: HWMOD: Add missing flag for rfbi class
ARM: OMAP3: HWMOD: Add omap_hwmod_class_sysconfig for dsi
.../mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c | 2 +-
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 3 ++-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 15 ++++++++++++++-
3 files changed, 17 insertions(+), 3 deletions(-)
--
1.7.4.1
^ permalink raw reply
* [PATCH 1/3] ARM: OMAP2/3: HWMOD: Add missing flags for dispc class
From: Tomi Valkeinen @ 2012-01-24 10:45 UTC (permalink / raw)
To: linux-omap, linux-fbdev, paul; +Cc: archit, Tomi Valkeinen
In-Reply-To: <1327401920-5617-1-git-send-email-tomi.valkeinen@ti.com>
hwmod class for dispc is missing sysc flags, which this patch adds.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 3 ++-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index 2a67297..7d1f71a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -39,7 +39,8 @@ static struct omap_hwmod_class_sysconfig omap2_dispc_sysc = {
.sysc_offs = 0x0010,
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE |
- SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE |
+ SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
.sysc_fields = &omap_hwmod_sysc_type1,
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index b176d44..76e6498 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1491,7 +1491,8 @@ static struct omap_hwmod_class_sysconfig omap3_dispc_sysc = {
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE |
SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE |
- SYSC_HAS_ENAWAKEUP),
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_CLOCKACTIVITY |
+ SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
.sysc_fields = &omap_hwmod_sysc_type1,
--
1.7.4.1
^ permalink raw reply related
* [PATCH 2/3] ARM: OMAP2/3: HWMOD: Add missing flag for rfbi class
From: Tomi Valkeinen @ 2012-01-24 10:45 UTC (permalink / raw)
To: linux-omap, linux-fbdev, paul; +Cc: archit, Tomi Valkeinen
In-Reply-To: <1327401920-5617-1-git-send-email-tomi.valkeinen@ti.com>
hwmod class for rfbi is missing SYSS_HAS_RESET_STATUS, which this patch
adds.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
.../mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c b/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c
index f08e442..bae4afd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c
@@ -65,7 +65,7 @@ static struct omap_hwmod_class_sysconfig omap2_rfbi_sysc = {
.sysc_offs = 0x0010,
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
- SYSC_HAS_AUTOIDLE),
+ SYSC_HAS_AUTOIDLE | SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields = &omap_hwmod_sysc_type1,
};
--
1.7.4.1
^ permalink raw reply related
* [PATCH 3/3] ARM: OMAP3: HWMOD: Add omap_hwmod_class_sysconfig for dsi
From: Tomi Valkeinen @ 2012-01-24 10:45 UTC (permalink / raw)
To: linux-omap, linux-fbdev, paul; +Cc: archit, Tomi Valkeinen
In-Reply-To: <1327401920-5617-1-git-send-email-tomi.valkeinen@ti.com>
hwmod data for OMAP3 does not define sysconfig for DSI. This patch adds
it.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 76e6498..c3ab5e4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1547,8 +1547,20 @@ static struct omap_hwmod omap3xxx_dss_dispc_hwmod = {
* display serial interface controller
*/
+static struct omap_hwmod_class_sysconfig omap3xxx_dsi_sysc = {
+ .rev_offs = 0x0000,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields = &omap_hwmod_sysc_type1,
+};
+
static struct omap_hwmod_class omap3xxx_dsi_hwmod_class = {
.name = "dsi",
+ .sysc = &omap3xxx_dsi_sysc,
};
static struct omap_hwmod_irq_info omap3xxx_dsi1_irqs[] = {
--
1.7.4.1
^ permalink raw reply related
* [PATCH] use devm_ functions
From: Julia Lawall @ 2012-01-24 13:00 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: kernel-janitors, Florian Tobias Schandinat, linux-omap,
linux-fbdev, linux-kernel
The semantic patch (http://coccinelle.lip6.fr/) used in generating this
patch is as follows. Some manual cleanup was required.
virtual after_start
virtual returned
virtual arg
virtual get
virtual drop_labels
// ---------------------------------------------------------------------
// find functions
@plat depends on !after_start@
identifier i,pfn,rfn;
position p;
@@
struct platform_driver i@p = {
.probe = pfn,
.remove = (<+...rfn...+>),
};
// ---------------------------------------------------------------------
// set up iteration
@initialize:ocaml@
let drop_labels = ref false
type ret = UseReturned | UseReturned2 of string | UseArg | UseGet
let add pfn rfn alloc free devm_alloc file rule let it = new iteration() in
it#set_files [file];
it#add_virtual_rule After_start;
(if !drop_labels then it#add_virtual_rule Drop_labels);
(match rule with
UseReturned -> it#add_virtual_rule Returned
| UseReturned2(free) -> it#add_virtual_rule Returned;
it#add_virtual_identifier Second_free free
| UseArg -> it#add_virtual_rule Arg
| UseGet -> it#add_virtual_rule Get);
it#add_virtual_identifier Pfn pfn;
it#add_virtual_identifier Rfn rfn;
it#add_virtual_identifier Alloc alloc;
it#add_virtual_identifier Free free;
it#add_virtual_identifier Devm_alloc devm_alloc;
it#register()
@script:ocaml depends on drop_labels@
@@
drop_labels := true
@script:ocaml@
pfn << plat.pfn;
rfn << plat.rfn;
p << plat.p;
@@
let file = (List.hd p).file in
add pfn rfn "kmalloc" "kfree" "devm_kzalloc" file UseReturned;
add pfn rfn "kzalloc" "kfree" "devm_kzalloc" file UseReturned;
add pfn rfn "ioremap" "iounmap" "devm_ioremap" file UseReturned;
add pfn rfn "ioremap_nocache" "iounmap" "devm_ioremap_nocache" file
UseReturned;
add pfn rfn "request_irq" "free_irq" "devm_request_irq" file UseArg;
add pfn rfn "request_threaded_irq" "free_irq" "devm_request_threaded_irq" file
UseArg;
add pfn rfn "dma_alloc_coherent" "dma_free_coherent" "dmam_alloc_coherent"
file UseArg;
add pfn rfn "dma_alloc_noncoherent" "dma_free_noncoherent"
"dmam_alloc_noncoherent" file UseArg;
(* several possibilities... *)
add pfn rfn "request_region" "release_region" "devm_request_region" file
UseGet;
add pfn rfn "request_mem_region" "release_mem_region"
"devm_request_mem_region" file UseGet;
add pfn rfn "request_region" "release_region" "devm_request_region" file
UseArg;
add pfn rfn "request_mem_region" "release_mem_region"
"devm_request_mem_region" file UseArg;
(* fix a bug at the same time *)
add pfn rfn "request_region" "release_resource" "devm_request_region" file
(UseReturned2("kfree"));
add pfn rfn "request_mem_region" "release_resource"
"devm_request_mem_region" file (UseReturned2("kfree"));
add pfn rfn "ioport_map" "ioport_unmap" "devm_ioport_map" file UseReturned
// ---------------------------------------------------------------------
// process the initial definition of the probe function
@preprobe@
identifier virtual.pfn;
position p;
@@
pfn@p(...) { ... }
@probe@
identifier pfn;
position preprobe.p;
@@
pfn@p(...) { ... }
@labelled_return@
identifier probe.pfn,l;
expression e;
@@
pfn(...) { <+... l: return e; ...+> }
// ---------------------------------------------------------------------
// transform functions where free uses the result
@prb depends on returned exists@
identifier probe.pfn,pdev,virtual.alloc,virtual.free,virtual.second_free;
expression x;
expression list args;
position p1,p2,p3;
type T1,T2,T3;
@@
pfn(struct platform_device *pdev) { ... when any
x = (T1)alloc@p1(args)
<... when strict
when any
when forall
(
free@p2((T2)x,...);
... when != x
second_free@p3((T3)x,...);
|
free@p2((T2)x,...);
)
...>
}
@reme exists@
identifier virtual.rfn,virtual.free;
expression prb.x;
type T;
@@
rfn(...) { ... free((T)x,...); ... }
@rem depends on reme@
identifier virtual.rfn,virtual.free,virtual.second_free;
expression prb.x;
position p4,p5;
type T,T1;
@@
rfn(...) {
<... when strict
(
free@p4((T)x,...);
... when != x
second_free@p5((T1)x,...);
|
free@p4((T)x,...);
)
...>
}
@bad@
identifier virtual.free;
expression prb.x;
position p != {prb.p2,rem.p4};
type T;
@@
free@p((T)x,...)
@modif depends on rem && !bad@
expression x;
identifier prb.pdev,virtual.alloc,virtual.free,virtual.devm_alloc;
identifier virtual.second_free;
expression list args;
position prb.p1,prb.p2,prb.p3,rem.p4,rem.p5;
type T;
@@
(
- free@p2(...);
|
- second_free@p3(...);
|
- free@p4(...);
|
- second_free@p5(...);
|
x - alloc@p1(
+ devm_alloc(&pdev->dev,
args)
|
x =
- (T)alloc@p1(
+ (T)devm_alloc(&pdev->dev,
args)
)
// ---------------------------------------------------------------------
// transform functions where free uses the first argument
@prbx depends on arg exists@
identifier probe.pfn,pdev,virtual.alloc,virtual.free;
expression x;
expression list args;
position p1,p2;
@@
pfn(struct platform_device *pdev) { ... when any
alloc@p1(x,args)
<... when strict
when any
when forall
free@p2(x,...)
...>
}
@remxe exists@
identifier virtual.rfn, virtual.free;
expression prbx.x;
@@
rfn(...) { ... free(x,...); ... }
@remx depends on remxe@
identifier virtual.rfn, virtual.free;
expression prbx.x;
position p3;
@@
rfn(...) {
<... when strict
free@p3(x,...)
...>
}
@badx@
identifier virtual.free;
expression prbx.x;
position p != {prbx.p2,remx.p3};
@@
free@p(x,...)
@modifx depends on remx && !badx@
expression x;
identifier prbx.pdev,virtual.alloc,virtual.free,virtual.devm_alloc;
expression list args;
position prbx.p1,prbx.p2,remx.p3;
@@
(
- free@p2(...);
|
- free@p3(...);
|
- alloc@p1(
+ devm_alloc(&pdev->dev,
x,args)
)
// ---------------------------------------------------------------------
// transform functions where free uses the result of platform_get_resource
@prbg depends on get exists@
identifier probe.pfn,pdev,virtual.alloc,virtual.free;
expression x;
expression list args;
position p1,p2;
@@
pfn(struct platform_device *pdev) { ... when any
alloc@p1(x,args)
<... when strict
when any
when forall
free@p2(x,...)
...>
}
@remge exists@
identifier virtual.rfn, virtual.free;
identifier y;
identifier pdev;
@@
rfn(struct platform_device *pdev) { ... when any
y = platform_get_resource(pdev, IORESOURCE_MEM, 0)
...
free(y->start,...)
...
}
@remg depends on remge@
identifier virtual.rfn, virtual.free;
identifier y;
identifier pdev;
position p3;
@@
rfn(struct platform_device *pdev) {
<... when strict
y = platform_get_resource(pdev, IORESOURCE_MEM, 0)
... when strict
free@p3(y->start,...)
...>
}
@badg@
identifier virtual.free;
position p != {prbg.p2,remg.p3};
@@
free@p(...)
@modifg depends on remg && !badg@
expression x;
identifier prbg.pdev,virtual.alloc,virtual.free,virtual.devm_alloc;
expression list args;
position prbg.p1,prbg.p2,remg.p3;
@@
(
- free@p2(...);
|
- free@p3(...);
|
- alloc@p1(
+ devm_alloc(&pdev->dev,
x,args)
)
// ---------------------------------------------------------------------
// cleanup, if the drvdata was only used to enable the free
// probably only relevant for kmalloc/kzalloc
@dclean depends on modif || modifx || modifg@
identifier virtual.rfn, pdev, i;
type T;
@@
rfn(struct platform_device *pdev) { ...
(
- T i = platform_get_drvdata(pdev);
|
- T i = dev_get_drvdata(&pdev->drv);
|
- T i;
... when != i
(
- i = platform_get_drvdata(pdev);
|
- i = dev_get_drvdata(&pdev->drv);
)
)
... when != i
}
@rclean depends on modif || modifx || modifg@
identifier virtual.rfn, pdev, i;
type T;
@@
rfn(struct platform_device *pdev) { ...
(
- T i = platform_get_resource(pdev,...);
|
- T i;
... when != i
- i = platform_get_resource(pdev,...);
)
... when != i
}
// ---------------------------------------------------------------------
// cleanup empty ifs, etc
@depends on modif || modifx || modifg@
identifier probe.pfn;
@@
pfn(...) { <...
- if (...) {}
...> }
@depends on modif || modifx || modifg@
identifier virtual.rfn;
@@
rfn(...) { <...
- if (...) {}
...> }
@depends on modif || modifx || modifg@
identifier probe.pfn;
expression ret,e;
@@
pfn(...) { <...
+ return
- ret e;
- return ret;
...> }
@depends on modif || modifx || modifg@
identifier virtual.rfn;
expression ret,e;
@@
rfn(...) { <...
+ return
- ret e;
- return ret;
...> }
// ---------------------------------------------------------------------
// this is likely to leave dead code, if l: is preceded by a return
// because we are control-flow based, there is no way to match on that
@depends on drop_labels && labelled_return && (modif || modifx || modifg)@
identifier l,l1,l2;
expression e;
statement S;
identifier probe.pfn;
identifier i;
statement S1,S2;
@@
pfn(...) { <...
- goto l;
+ goto l2;
...
-l:
<... when != S
when any
l1:
...>
l2:
(
(<+...i...+>);
|
if (...) S1 else S2
|
while (...) S1
|
for (...;...;...) S1
|
return e;
)
...> }
@depends on drop_labels && !labelled_return && (modif || modifx || modifg)@
identifier l,l1,l2;
expression e;
statement S;
identifier probe.pfn;
identifier i;
statement S1,S2;
@@
pfn(...) { <...
(
- goto l;
+ goto l2;
...
-l:
<... when != S
when any
l1:
...>
l2:
(
(<+...i...+>);
|
if (...) S1 else S2
|
while (...) S1
|
for (...;...;...) S1
)
|
- goto l;
+ return e;
...
-l:
<... when != S
when any
l1:
...>
return e;
)
...> }
^ permalink raw reply
* [PATCH] drivers/video/omap2/dss: use devm_ functions
From: Julia Lawall @ 2012-01-24 13:00 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: kernel-janitors, Florian Tobias Schandinat, linux-omap,
linux-fbdev, linux-kernel
In-Reply-To: <1327410045-3906-1-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
drivers/video/omap2/dss/dispc.c | 16 ++++++----------
drivers/video/omap2/dss/dsi.c | 28 +++++++++-------------------
drivers/video/omap2/dss/dss.c | 9 +++------
drivers/video/omap2/dss/rfbi.c | 5 ++---
drivers/video/omap2/dss/venc.c | 8 +++-----
5 files changed, 23 insertions(+), 43 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index a5ec7f3..6fa866a 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3322,7 +3322,8 @@ static int omap_dispchw_probe(struct platform_device *pdev)
r = -EINVAL;
goto err_ioremap;
}
- dispc.base = ioremap(dispc_mem->start, resource_size(dispc_mem));
+ dispc.base = devm_ioremap(&pdev->dev, dispc_mem->start,
+ resource_size(dispc_mem));
if (!dispc.base) {
DSSERR("can't ioremap DISPC\n");
r = -ENOMEM;
@@ -3332,14 +3333,14 @@ static int omap_dispchw_probe(struct platform_device *pdev)
if (dispc.irq < 0) {
DSSERR("platform_get_irq failed\n");
r = -ENODEV;
- goto err_irq;
+ goto err_ioremap;
}
- r = request_irq(dispc.irq, omap_dispc_irq_handler, IRQF_SHARED,
- "OMAP DISPC", dispc.pdev);
+ r = devm_request_irq(&pdev->dev, dispc.irq, omap_dispc_irq_handler,
+ IRQF_SHARED, "OMAP DISPC", dispc.pdev);
if (r < 0) {
DSSERR("request_irq failed\n");
- goto err_irq;
+ goto err_ioremap;
}
pm_runtime_enable(&pdev->dev);
@@ -3362,9 +3363,6 @@ static int omap_dispchw_probe(struct platform_device *pdev)
err_runtime_get:
pm_runtime_disable(&pdev->dev);
- free_irq(dispc.irq, dispc.pdev);
-err_irq:
- iounmap(dispc.base);
err_ioremap:
clk_put(dispc.dss_clk);
err_get_clk:
@@ -3377,8 +3375,6 @@ static int omap_dispchw_remove(struct platform_device *pdev)
clk_put(dispc.dss_clk);
- free_irq(dispc.irq, dispc.pdev);
- iounmap(dispc.base);
return 0;
}
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index d4d676c..52b9359 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4695,7 +4695,7 @@ static int omap_dsihw_probe(struct platform_device *dsidev)
struct resource *dsi_mem;
struct dsi_data *dsi;
- dsi = kzalloc(sizeof(*dsi), GFP_KERNEL);
+ dsi = devm_kzalloc(&dsidev->dev, sizeof(*dsi), GFP_KERNEL);
if (!dsi) {
r = -ENOMEM;
goto err_alloc;
@@ -4724,7 +4724,7 @@ static int omap_dsihw_probe(struct platform_device *dsidev)
r = dsi_get_clocks(dsidev);
if (r)
- goto err_get_clk;
+ goto err_alloc;
pm_runtime_enable(&dsidev->dev);
@@ -4742,7 +4742,8 @@ static int omap_dsihw_probe(struct platform_device *dsidev)
r = -EINVAL;
goto err_ioremap;
}
- dsi->base = ioremap(dsi_mem->start, resource_size(dsi_mem));
+ dsi->base = devm_ioremap(&dsidev->dev, dsi_mem->start,
+ resource_size(dsi_mem));
if (!dsi->base) {
DSSERR("can't ioremap DSI\n");
r = -ENOMEM;
@@ -4752,14 +4753,14 @@ static int omap_dsihw_probe(struct platform_device *dsidev)
if (dsi->irq < 0) {
DSSERR("platform_get_irq failed\n");
r = -ENODEV;
- goto err_get_irq;
+ goto err_ioremap;
}
- r = request_irq(dsi->irq, omap_dsi_irq_handler, IRQF_SHARED,
- dev_name(&dsidev->dev), dsi->pdev);
+ r = devm_request_irq(&dsidev->dev, dsi->irq, omap_dsi_irq_handler,
+ IRQF_SHARED, dev_name(&dsidev->dev), dsi->pdev);
if (r < 0) {
DSSERR("request_irq failed\n");
- goto err_get_irq;
+ goto err_ioremap;
}
/* DSI VCs initialization */
@@ -4773,7 +4774,7 @@ static int omap_dsihw_probe(struct platform_device *dsidev)
r = dsi_runtime_get(dsidev);
if (r)
- goto err_get_dsi;
+ goto err_ioremap;
rev = dsi_read_reg(dsidev, DSI_REVISION);
dev_dbg(&dsidev->dev, "OMAP DSI rev %d.%d\n",
@@ -4791,14 +4792,8 @@ static int omap_dsihw_probe(struct platform_device *dsidev)
return 0;
-err_get_dsi:
- free_irq(dsi->irq, dsi->pdev);
-err_get_irq:
- iounmap(dsi->base);
err_ioremap:
pm_runtime_disable(&dsidev->dev);
-err_get_clk:
- kfree(dsi);
err_alloc:
return r;
}
@@ -4823,11 +4818,6 @@ static int omap_dsihw_remove(struct platform_device *dsidev)
dsi->vdds_dsi_reg = NULL;
}
- free_irq(dsi->irq, dsi->pdev);
- iounmap(dsi->base);
-
- kfree(dsi);
-
return 0;
}
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 1703345..e75f837 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -751,7 +751,8 @@ static int omap_dsshw_probe(struct platform_device *pdev)
r = -EINVAL;
goto err_ioremap;
}
- dss.base = ioremap(dss_mem->start, resource_size(dss_mem));
+ dss.base = devm_ioremap(&pdev->dev, dss_mem->start,
+ resource_size(dss_mem));
if (!dss.base) {
DSSERR("can't ioremap DSS\n");
r = -ENOMEM;
@@ -760,7 +761,7 @@ static int omap_dsshw_probe(struct platform_device *pdev)
r = dss_get_clocks();
if (r)
- goto err_clocks;
+ goto err_ioremap;
pm_runtime_enable(&pdev->dev);
@@ -808,8 +809,6 @@ err_dpi:
err_runtime_get:
pm_runtime_disable(&pdev->dev);
dss_put_clocks();
-err_clocks:
- iounmap(dss.base);
err_ioremap:
return r;
}
@@ -819,8 +818,6 @@ static int omap_dsshw_remove(struct platform_device *pdev)
dpi_exit();
sdi_exit();
- iounmap(dss.base);
-
pm_runtime_disable(&pdev->dev);
dss_put_clocks();
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 814bb95..159e914 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -925,7 +925,8 @@ static int omap_rfbihw_probe(struct platform_device *pdev)
r = -EINVAL;
goto err_ioremap;
}
- rfbi.base = ioremap(rfbi_mem->start, resource_size(rfbi_mem));
+ rfbi.base = devm_ioremap(&pdev->dev, rfbi_mem->start,
+ resource_size(rfbi_mem));
if (!rfbi.base) {
DSSERR("can't ioremap RFBI\n");
r = -ENOMEM;
@@ -963,7 +964,6 @@ err_get_ick:
rfbi_runtime_put();
err_get_rfbi:
pm_runtime_disable(&pdev->dev);
- iounmap(rfbi.base);
err_ioremap:
return r;
}
@@ -971,7 +971,6 @@ err_ioremap:
static int omap_rfbihw_remove(struct platform_device *pdev)
{
pm_runtime_disable(&pdev->dev);
- iounmap(rfbi.base);
return 0;
}
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index b3e9f90..1dfdde1 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -793,7 +793,8 @@ static int omap_venchw_probe(struct platform_device *pdev)
r = -EINVAL;
goto err_ioremap;
}
- venc.base = ioremap(venc_mem->start, resource_size(venc_mem));
+ venc.base = devm_ioremap(&pdev->dev, venc_mem->start,
+ resource_size(venc_mem));
if (!venc.base) {
DSSERR("can't ioremap VENC\n");
r = -ENOMEM;
@@ -802,7 +803,7 @@ static int omap_venchw_probe(struct platform_device *pdev)
r = venc_get_clocks(pdev);
if (r)
- goto err_get_clk;
+ goto err_ioremap;
pm_runtime_enable(&pdev->dev);
@@ -820,8 +821,6 @@ static int omap_venchw_probe(struct platform_device *pdev)
err_get_venc:
pm_runtime_disable(&pdev->dev);
venc_put_clocks();
-err_get_clk:
- iounmap(venc.base);
err_ioremap:
return r;
}
@@ -837,7 +836,6 @@ static int omap_venchw_remove(struct platform_device *pdev)
pm_runtime_disable(&pdev->dev);
venc_put_clocks();
- iounmap(venc.base);
return 0;
}
^ permalink raw reply related
* Re: [PATCH] fbdev: sh_mipi_dsi: add extra settings method for platform
From: Laurent Pinchart @ 2012-01-24 14:11 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <874nvnhupd.wl%kuninori.morimoto.gx@renesas.com>
Hi Magnus,
On Tuesday 24 January 2012 11:44:13 Magnus Damm wrote:
> On Tue, Jan 24, 2012 at 7:09 PM, Laurent Pinchart wrote:
> > On Tuesday 24 January 2012 01:48:55 Kuninori Morimoto wrote:
> >> Hi Laurent
> >> Cc Magnus, Guennadi
> >>
> >> Thank you for checking patch
> >
> > You're welcome.
> >
> >> > > + void (*set_dcs)(int handle,
> >> > > + int (*mipi_dcs)(int handle, u8 cmd),
> >> > > + int (*mipi_dcs_param)(int handle, u8 cmd, u8
> >> > > param));
> >> >
> >> > I don't think this is a good idea. First of all, we should reduce the
> >> > number of board code callbacks to make transition to the device tree
> >> > easier. Then, passing two functions to board code to read and write
> >> > any device register without the driver having any knowledge about
> >> > that is a clear violation of the device model, and will result in
> >> > problems sooner or later.
> >> >
> >> > What MIPI settings do platforms need to modify ? Can those settings be
> >> > expressed as data in the sh_mipi_dsi_info structure instead ?
> >>
> >> Hmm... now I'm in dilemma.
> >> Actually this is v2 patch for mipi display.
> >> (v1 patch was dropped since merge window issue)
> >>
> >> The v1 patch was data-table style for mipi display initialization.
> >> (if platform had init data-table, driver used it)
> >>
> >> But someone reviewed it and teach me that it is not-good idea.
> >> So, I created this style in v2.
> >>
> >> Now platform needs "backlight ON" and "memory write ON" command,
> >> but I could not find these command on include/video/mipi_display.h.
> >> So, I thought it is platform specific command.
> >
> > Why does the platform need that ? Please correct me if I'm wrong, but it
> > seems to me that what you're trying to do is configure and control the
> > display panel. I don't think that's platform-specific, it should be
> > panel-specific instead. It looks to me like the right solution would be
> > to write a display panel driver, similar to what is done for the OMAP2+
> > platform
> > (drivers/video/omap2/displays).
>
> I think that it is a very good recommendation to solve this in theory,
> but in practice we've never really seen anyone use the same LCD module
> and/or on-glass LCD controller for another board. What I've done so
> far is to write the part number of the LCD module together with LCD
> controller part number and hopefully also LCD panel configuration
> together with the register settings so it is possible to search and
> consolidate at some point when we have multiple users.
>
> I'm not sure about this particular case, but I've seen quite much code
> that just has a set of LCD controller register settings without
> documentation, and it's kind of hard to turn that into a proper
> driver. Especially since these register settings are both related to
> the on-module LCD controller and LCD panel that together form a LCD
> module. We usually don't know which setting is for what part. And we
> probably would like to abstract the module into separate pieces of
> code for different parts. I've seen some data sheet of a on-module LCD
> controller and it was about 800 pages I believe, so it's not exactly
> something you can cook up in an afternoon. And add closed MIPI specs
> and all sorts of fun and this can take forever. =)
How does TI handle that for the OMAP platform ? I don't think they configure
the LCD module/panel in board code. Maybe we should ask them if they have a
solution, or even plans to handle the problem ? Tomi Valkeinen is probably the
right person to ask.
> That aside, it would be really nice to see some proper drivers for LCD
> modules.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] fix NULL pointer dereference in DSS2 VENC sysfs debug attr on OMAP4
From: Danny Kukawka @ 2012-01-24 15:44 UTC (permalink / raw)
To: linux-omap, linux-fbdev
Commit ba02fa37de80bea10d706f39f076dd848348320a disabled the
venc driver registration on OMAP4. Since the driver never gets
probed/initialised your get a dereferenceed NULL pointer if you
try to get info from /sys/kernel/debug/omapdss/venc
Return info message about disabled venc if venc_dump_regs() gets called.
Signed-off-by: Danny Kukawka <danny.kukawka@bisect.de>
---
drivers/video/omap2/dss/venc.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index b3e9f90..82865be 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -699,6 +699,11 @@ void venc_dump_regs(struct seq_file *s)
{
#define DUMPREG(r) seq_printf(s, "%-35s %08x\n", #r, venc_read_reg(r))
+ if (cpu_is_omap44xx()) {
+ seq_printf(s, "VENC currently disabled on OMAP44xx\n");
+ return;
+ }
+
if (venc_runtime_get())
return;
--
1.7.7.3
^ permalink raw reply related
* Re: [PATCH v7 1/2] video: support MIPI-DSI controller driver
From: Donghwa Lee @ 2012-01-25 0:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120120155121.18880dff.akpm@linux-foundation.org>
On Sat, 21 Jan 2012 08:51, Andrew Morton wrote:
> On Thu, 19 Jan 2012 20:08:07 +0530
> Archit <a0393947@ti.com> wrote:
>
>> On Thursday 19 January 2012 10:58 AM, Donghwa Lee wrote:
>>> Samsung S5PC210 and EXYNOS SoC platform has MIPI-DSI controller and MIPI-DSI
>>> based LCD Panel could be used with it. This patch supports MIPI-DSI driver
>>> based Samsung SoC chip.
>>>
>>> LCD panel driver based MIPI-DSI should be registered to MIPI-DSI driver at
>>> machine code and LCD panel driver specific function registered to mipi_dsim_ddi
>>> structure at lcd panel init function called system init.
>>> In the MIPI-DSI driver, find lcd panel driver by using registered
>>> lcd panel name, and then initialize lcd panel driver.
>>>
>>> Changes since v6:
>>> - remove obscure compile problems.
>>> - remove useless codes.
>>> - modify return errno codes properly
>>
>> One more comment about 'mipi_dsim.h', it would be better to put it in
>> include/video and not 'include/linux'.
>
> Yes, that is desirable.
>
>>> ---
>>> drivers/video/Kconfig | 6 +
>>> drivers/video/Makefile | 2 +
>>> drivers/video/s5p_mipi_dsi.c | 599 ++++++++++++++++++++++
>>> drivers/video/s5p_mipi_dsi_common.c | 896 +++++++++++++++++++++++++++++++++
>>> drivers/video/s5p_mipi_dsi_common.h | 46 ++
>>> drivers/video/s5p_mipi_dsi_lowlevel.c | 617 +++++++++++++++++++++++
>>> drivers/video/s5p_mipi_dsi_lowlevel.h | 112 ++++
>>> drivers/video/s5p_mipi_dsi_regs.h | 149 ++++++
>>> include/linux/mipi_dsim.h | 359 +++++++++++++
>>> 9 files changed, 2786 insertions(+), 0 deletions(-)
>
> or we could put it in drivers/video/. It all depends on which other
> drivers we expect will need access to this header.
>
No, mipi_dsim.h file includes global interface data, callback function called by machine
file, platform data for mipi-dsi driver and so on. So I think it would be better to put
in 'include/video' or 'include/linux'.
Of course it is much better to change name to 's5p_mipi_dsim.h'
Thank you,
Donghwa Lee
^ permalink raw reply
* Re: [PATCH 0/3] OMAP: DSS PM fixes
From: Tomi Valkeinen @ 2012-01-25 8:04 UTC (permalink / raw)
To: Paul Walmsley
Cc: linux-fbdev, archit, neilb, jean.pihet, khilman, jw,
linux-omap mailing list
In-Reply-To: <1327320930-14550-1-git-send-email-tomi.valkeinen@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]
Hi Paul,
On Mon, 2012-01-23 at 14:15 +0200, Tomi Valkeinen wrote:
> Here are two fixes to get DSS work better with PM on OMAP3.
>
> The first two patches fix the missing SYSC_HAS_ENAWAKEUP flag, which removes
> the SYNC_LOST problem.
>
> The third patch changes omapdss to use pm_runtime_put_sync functions, which
> fixes the system suspend.
>
> I've tested both only on v3.3-rc1, OMAP3 Overo. I get problems on system
> suspend from TWL and MTD drivers (also without my patches =), but disabling MTD
> and ignoring TWL errors shows that the warning from omapdss has disappeared,
> and I get an image on the screen on resume.
>
> The two fixes are independent, so either I can take them through dss tree (with
> appropriate Acks), or the hwmod patches can go through some other tree.
Ping. Sorry to be hurrying with this, but I'd like to get these into the
next rc. Can you ack these (perhaps the first two patches?) or do you
want to take them through your tree?
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] drivers/video/omap2/dss: use devm_ functions
From: Tomi Valkeinen @ 2012-01-25 8:30 UTC (permalink / raw)
To: Julia Lawall
Cc: kernel-janitors, Florian Tobias Schandinat, linux-omap,
linux-fbdev, linux-kernel
In-Reply-To: <1327410045-3906-2-git-send-email-Julia.Lawall@lip6.fr>
[-- Attachment #1: Type: text/plain, Size: 493 bytes --]
Hi,
On Tue, 2012-01-24 at 14:00 +0100, Julia Lawall wrote:
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> The various devm_ functions allocate memory that is released when a
> driver
> detaches. This patch uses these functions for data that is allocated
> in
> the probe function of a platform device and is only freed in the
> remove
> function.
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Thanks, this looks very good. I'll apply to omapdss tree.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] fix NULL pointer dereference in DSS2 VENC sysfs debug attr on OMAP4
From: Tomi Valkeinen @ 2012-01-25 10:49 UTC (permalink / raw)
To: Danny Kukawka; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1327419882-13578-1-git-send-email-danny.kukawka@bisect.de>
[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]
On Tue, 2012-01-24 at 16:44 +0100, Danny Kukawka wrote:
> Commit ba02fa37de80bea10d706f39f076dd848348320a disabled the
> venc driver registration on OMAP4. Since the driver never gets
> probed/initialised your get a dereferenceed NULL pointer if you
> try to get info from /sys/kernel/debug/omapdss/venc
>
> Return info message about disabled venc if venc_dump_regs() gets called.
>
> Signed-off-by: Danny Kukawka <danny.kukawka@bisect.de>
> ---
> drivers/video/omap2/dss/venc.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
> index b3e9f90..82865be 100644
> --- a/drivers/video/omap2/dss/venc.c
> +++ b/drivers/video/omap2/dss/venc.c
> @@ -699,6 +699,11 @@ void venc_dump_regs(struct seq_file *s)
> {
> #define DUMPREG(r) seq_printf(s, "%-35s %08x\n", #r, venc_read_reg(r))
>
> + if (cpu_is_omap44xx()) {
> + seq_printf(s, "VENC currently disabled on OMAP44xx\n");
> + return;
> + }
> +
> if (venc_runtime_get())
> return;
>
Thanks. A bit hacky, but so is the whole omap4/venc problem. I'll apply
to dss tree.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Length of pseudo_palette
From: hubert-b @ 2012-01-25 13:40 UTC (permalink / raw)
To: linux-fbdev
Hi frame buffer developers,
I'm wondering about the size of the pseudo_palette: In [1] it is stated
that it always has 17 entries - 16 for the console colors and the last
one for the cursor. But googling around I found this posts [2] [3] from
January 2003 that mention that this is not true anymore. So the question
is are 16 entries enough for fbcon? Or did I miss something else here?
Because I saw a lot of frame buffer drivers allocating 256 and I don't
know what this might be good for.
Thanks in advance!
[1] http://www.linux-fbdev.org/HOWTO/4.html
[2] http://permalink.gmane.org/gmane.linux.fbdev.devel/946
[3] http://permalink.gmane.org/gmane.linux.fbdev.devel/978
^ permalink raw reply
* Re: [PATCH 0/3] OMAP: DSS PM fixes
From: Paul Walmsley @ 2012-01-25 18:55 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev, archit, neilb, jean.pihet, khilman, jw,
linux-omap mailing list
In-Reply-To: <1327478645.1858.17.camel@deskari>
Hi Tomi,
sorry about the delay,
On Wed, 25 Jan 2012, Tomi Valkeinen wrote:
> On Mon, 2012-01-23 at 14:15 +0200, Tomi Valkeinen wrote:
> > Here are two fixes to get DSS work better with PM on OMAP3.
...
> > The two fixes are independent, so either I can take them through dss tree (with
> > appropriate Acks), or the hwmod patches can go through some other tree.
>
> Ping. Sorry to be hurrying with this, but I'd like to get these into the
> next rc. Can you ack these (perhaps the first two patches?) or do you
> want to take them through your tree?
I'll take the two hwmod data changes through my tree here & will plan to
send a pull request today.
regards
- Paul
^ permalink raw reply
* Re: [PATCH 1/3] ARM: OMAP: HWMOD: split omap2/3 dispc hwmod class
From: Paul Walmsley @ 2012-01-25 19:02 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, archit, neilb, jean.pihet, khilman, jw
In-Reply-To: <1327320930-14550-2-git-send-email-tomi.valkeinen@ti.com>
On Mon, 23 Jan 2012, Tomi Valkeinen wrote:
> Currently OMAP2 and 3 share the same omap_hwmod_class and
> omap_hwmod_class_sysconfig for dispc. However, OMAP3 has sysconfig
> bits that OMAP2 doesn't have, so we need to split those structs into
> OMAP2 and OMAP3 specific versions.
>
> This patch only splits the structs, without changing the contents.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Thanks, queued for 3.3-rc.
- Paul
^ permalink raw reply
* Re: [PATCH 2/3] ARM: OMAP3: HWMOD: add SYSC_HAS_ENAWAKEUP for dispc
From: Paul Walmsley @ 2012-01-25 19:02 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, archit, neilb, jean.pihet, khilman, jw
In-Reply-To: <1327320930-14550-3-git-send-email-tomi.valkeinen@ti.com>
On Mon, 23 Jan 2012, Tomi Valkeinen wrote:
> dispc's sysc_flags is missing SYSC_HAS_ENAWAKEUP flag. This seems to
> cause SYNC_LOST errors from the DSS when the power management is
> enabled.
>
> This patch adds the missing SYSC_HAS_ENAWAKEUP flag. Note that there are
> other flags missing also (clock activity, DSI's sysc flags), but as they
> are not critical, they will be fixed in the next merge window.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Thanks, queued for 3.3-rc.
- Paul
^ permalink raw reply
* [PATCH] video: use gpio_request_one
From: Jingoo Han @ 2012-01-26 10:32 UTC (permalink / raw)
To: linux-fbdev
Using gpio_request_one can make the code simpler because it can
set the direction and initial value in one shot.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/bf537-lq035.c | 12 +++---------
drivers/video/bf54x-lq043fb.c | 4 +---
drivers/video/bfin-lq035q1-fb.c | 8 ++++----
drivers/video/bfin_adv7393fb.c | 5 +++--
drivers/video/msm/mddi_client_nt35399.c | 7 +------
drivers/video/msm/mddi_client_toshiba.c | 7 +------
drivers/video/omap/lcd_inn1610.c | 10 ++++------
drivers/video/omap2/displays/panel-taal.c | 4 +---
.../video/omap2/displays/panel-tpo-td043mtea1.c | 11 ++---------
9 files changed, 20 insertions(+), 48 deletions(-)
diff --git a/drivers/video/bf537-lq035.c b/drivers/video/bf537-lq035.c
index bea53c1..befbc80 100644
--- a/drivers/video/bf537-lq035.c
+++ b/drivers/video/bf537-lq035.c
@@ -383,23 +383,19 @@ static int __devinit request_ports(void)
}
#if (defined(UD) && defined(LBR))
- if (gpio_request(UD, KBUILD_MODNAME)) {
+ if (gpio_request_one(UD, GPIOF_OUT_INIT_LOW, KBUILD_MODNAME)) {
pr_err("requesting GPIO %d failed\n", UD);
return -EBUSY;
}
- if (gpio_request(LBR, KBUILD_MODNAME)) {
+ if (gpio_request_one(LBR, GPIOF_OUT_INIT_HIGH, KBUILD_MODNAME)) {
pr_err("requesting GPIO %d failed\n", LBR);
gpio_free(UD);
return -EBUSY;
}
-
- gpio_direction_output(UD, 0);
- gpio_direction_output(LBR, 1);
-
#endif
- if (gpio_request(MOD, KBUILD_MODNAME)) {
+ if (gpio_request_one(MOD, GPIOF_OUT_INIT_HIGH, KBUILD_MODNAME)) {
pr_err("requesting GPIO %d failed\n", MOD);
#if (defined(UD) && defined(LBR))
gpio_free(LBR);
@@ -408,8 +404,6 @@ static int __devinit request_ports(void)
return -EBUSY;
}
- gpio_direction_output(MOD, 1);
-
SSYNC();
return 0;
}
diff --git a/drivers/video/bf54x-lq043fb.c b/drivers/video/bf54x-lq043fb.c
index 46b03f5..dc2f004 100644
--- a/drivers/video/bf54x-lq043fb.c
+++ b/drivers/video/bf54x-lq043fb.c
@@ -240,7 +240,7 @@ static int request_ports(struct bfin_bf54xfb_info *fbi)
u16 eppi_req_18[] = EPPI0_18;
u16 disp = fbi->mach_info->disp;
- if (gpio_request(disp, DRIVER_NAME)) {
+ if (gpio_request_one(disp, GPIOF_OUT_INIT_HIGH, DRIVER_NAME)) {
printk(KERN_ERR "Requesting GPIO %d failed\n", disp);
return -EFAULT;
}
@@ -263,8 +263,6 @@ static int request_ports(struct bfin_bf54xfb_info *fbi)
}
}
- gpio_direction_output(disp, 1);
-
return 0;
}
diff --git a/drivers/video/bfin-lq035q1-fb.c b/drivers/video/bfin-lq035q1-fb.c
index c633068..86922ac 100644
--- a/drivers/video/bfin-lq035q1-fb.c
+++ b/drivers/video/bfin-lq035q1-fb.c
@@ -365,10 +365,10 @@ static int __devinit bfin_lq035q1_request_ports(struct platform_device *pdev,
* Drive PPI_FS3 Low
*/
if (ANOMALY_05000400) {
- int ret = gpio_request(P_IDENT(P_PPI0_FS3), "PPI_FS3");
+ int ret = gpio_request_one(P_IDENT(P_PPI0_FS3),
+ GPIOF_OUT_INIT_LOW, "PPI_FS3");
if (ret)
return ret;
- gpio_direction_output(P_IDENT(P_PPI0_FS3), 0);
}
if (ppi16)
@@ -716,14 +716,14 @@ static int __devinit bfin_lq035q1_probe(struct platform_device *pdev)
}
if (info->disp_info->use_bl) {
- ret = gpio_request(info->disp_info->gpio_bl, "LQ035 Backlight");
+ ret = gpio_request_one(info->disp_info->gpio_bl,
+ GPIOF_OUT_INIT_LOW, "LQ035 Backlight");
if (ret) {
dev_err(&pdev->dev, "failed to request GPIO %d\n",
info->disp_info->gpio_bl);
goto out9;
}
- gpio_direction_output(info->disp_info->gpio_bl, 0);
}
ret = register_framebuffer(fbinfo);
diff --git a/drivers/video/bfin_adv7393fb.c b/drivers/video/bfin_adv7393fb.c
index 811dd7f..c992814 100644
--- a/drivers/video/bfin_adv7393fb.c
+++ b/drivers/video/bfin_adv7393fb.c
@@ -411,12 +411,13 @@ static int __devinit bfin_adv7393_fb_probe(struct i2c_client *client,
/* Workaround "PPI Does Not Start Properly In Specific Mode" */
if (ANOMALY_05000400) {
- if (gpio_request(P_IDENT(P_PPI0_FS3), "PPI0_FS3")) {
+ ret = gpio_request_one(P_IDENT(P_PPI0_FS3), GPIOF_OUT_INIT_LOW,
+ "PPI0_FS3")
+ if (ret) {
dev_err(&client->dev, "PPI0_FS3 GPIO request failed\n");
ret = -EBUSY;
goto out_8;
}
- gpio_direction_output(P_IDENT(P_PPI0_FS3), 0);
}
if (peripheral_request_list(ppi_pins, DRIVER_NAME)) {
diff --git a/drivers/video/msm/mddi_client_nt35399.c b/drivers/video/msm/mddi_client_nt35399.c
index f239f4a..7fcd67e 100644
--- a/drivers/video/msm/mddi_client_nt35399.c
+++ b/drivers/video/msm/mddi_client_nt35399.c
@@ -155,14 +155,10 @@ static int setup_vsync(struct panel_info *panel, int init)
ret = 0;
goto uninit;
}
- ret = gpio_request(gpio, "vsync");
+ ret = gpio_request_one(gpio, GPIOF_IN, "vsync");
if (ret)
goto err_request_gpio_failed;
- ret = gpio_direction_input(gpio);
- if (ret)
- goto err_gpio_direction_input_failed;
-
ret = irq = gpio_to_irq(gpio);
if (ret < 0)
goto err_get_irq_num_failed;
@@ -180,7 +176,6 @@ uninit:
free_irq(gpio_to_irq(gpio), panel->client_data);
err_request_irq_failed:
err_get_irq_num_failed:
-err_gpio_direction_input_failed:
gpio_free(gpio);
err_request_gpio_failed:
return ret;
diff --git a/drivers/video/msm/mddi_client_toshiba.c b/drivers/video/msm/mddi_client_toshiba.c
index f9bc932..053eb68 100644
--- a/drivers/video/msm/mddi_client_toshiba.c
+++ b/drivers/video/msm/mddi_client_toshiba.c
@@ -186,14 +186,10 @@ static int setup_vsync(struct panel_info *panel,
ret = 0;
goto uninit;
}
- ret = gpio_request(gpio, "vsync");
+ ret = gpio_request_one(gpio, GPIOF_IN, "vsync");
if (ret)
goto err_request_gpio_failed;
- ret = gpio_direction_input(gpio);
- if (ret)
- goto err_gpio_direction_input_failed;
-
ret = irq = gpio_to_irq(gpio);
if (ret < 0)
goto err_get_irq_num_failed;
@@ -210,7 +206,6 @@ uninit:
free_irq(gpio_to_irq(gpio), panel);
err_request_irq_failed:
err_get_irq_num_failed:
-err_gpio_direction_input_failed:
gpio_free(gpio);
err_request_gpio_failed:
return ret;
diff --git a/drivers/video/omap/lcd_inn1610.c b/drivers/video/omap/lcd_inn1610.c
index 7e8bd8e..e3d3d13 100644
--- a/drivers/video/omap/lcd_inn1610.c
+++ b/drivers/video/omap/lcd_inn1610.c
@@ -22,7 +22,7 @@
#include <linux/module.h>
#include <linux/platform_device.h>
-#include <asm/gpio.h>
+#include <linux/gpio.h>
#include "omapfb.h"
#define MODULE_NAME "omapfb-lcd_h3"
@@ -32,20 +32,18 @@ static int innovator1610_panel_init(struct lcd_panel *panel,
{
int r = 0;
- if (gpio_request(14, "lcd_en0")) {
+ /* configure GPIO(14, 15) as outputs */
+ if (gpio_request_one(14, GPIOF_OUT_INIT_LOW, "lcd_en0")) {
pr_err(MODULE_NAME ": can't request GPIO 14\n");
r = -1;
goto exit;
}
- if (gpio_request(15, "lcd_en1")) {
+ if (gpio_request_one(15, GPIOF_OUT_INIT_LOW, "lcd_en1")) {
pr_err(MODULE_NAME ": can't request GPIO 15\n");
gpio_free(14);
r = -1;
goto exit;
}
- /* configure GPIO(14, 15) as outputs */
- gpio_direction_output(14, 0);
- gpio_direction_output(15, 0);
exit:
return r;
}
diff --git a/drivers/video/omap2/displays/panel-taal.c b/drivers/video/omap2/displays/panel-taal.c
index 00c5c61..0f21fa5 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -1019,14 +1019,12 @@ static int taal_probe(struct omap_dss_device *dssdev)
if (panel_data->use_ext_te) {
int gpio = panel_data->ext_te_gpio;
- r = gpio_request(gpio, "taal irq");
+ r = gpio_request_one(gpio, GPIOF_IN, "taal irq");
if (r) {
dev_err(&dssdev->dev, "GPIO request failed\n");
goto err_gpio;
}
- gpio_direction_input(gpio);
-
r = request_irq(gpio_to_irq(gpio), taal_te_isr,
IRQF_TRIGGER_RISING,
"taal vsync", dssdev);
diff --git a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
index e6649aa..880c313 100644
--- a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
+++ b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
@@ -408,17 +408,12 @@ static int tpo_td043_probe(struct omap_dss_device *dssdev)
}
if (gpio_is_valid(nreset_gpio)) {
- ret = gpio_request(nreset_gpio, "lcd reset");
+ ret = gpio_request_one(nreset_gpio, GPIOF_OUT_INIT_LOW,
+ "lcd reset");
if (ret < 0) {
dev_err(&dssdev->dev, "couldn't request reset GPIO\n");
goto fail_gpio_req;
}
-
- ret = gpio_direction_output(nreset_gpio, 0);
- if (ret < 0) {
- dev_err(&dssdev->dev, "couldn't set GPIO direction\n");
- goto fail_gpio_direction;
- }
}
ret = sysfs_create_group(&dssdev->dev.kobj, &tpo_td043_attr_group);
@@ -427,8 +422,6 @@ static int tpo_td043_probe(struct omap_dss_device *dssdev)
return 0;
-fail_gpio_direction:
- gpio_free(nreset_gpio);
fail_gpio_req:
regulator_put(tpo_td043->vcc_reg);
fail_regulator:
--
1.7.1
^ permalink raw reply related
* [PATCH] video: s3c-fb: fix checkpatch error
From: Jingoo Han @ 2012-01-26 10:38 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1301642247-20926-1-git-send-email-jg1.han@samsung.com>
This patch fixes the checkpatch error listed below:
ERROR: trailing statements should be on next line
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/s3c-fb.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 7c5158d..389189a 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -48,7 +48,8 @@
#undef writel
#define writel(v, r) do { \
printk(KERN_DEBUG "%s: %08x => %p\n", __func__, (unsigned int)v, r); \
- __raw_writel(v, r); } while (0)
+ __raw_writel(v, r); \
+} while (0)
#endif /* FB_S3C_DEBUG_REGWRITE */
/* irq_flags bits */
--
1.7.1
^ permalink raw reply related
* [GIT PULL] OMAP DSS fixes for 3.3-rc
From: Tomi Valkeinen @ 2012-01-26 12:07 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: linux-fbdev@vger.kernel.org, linux-omap mailing list
[-- Attachment #1: Type: text/plain, Size: 2031 bytes --]
Hi Florian,
Here are two major fixes for OMAP DSS driver.
The first (OMAPDSS: use sync versions...) fixes problem with system
suspend, which causes omapdss power management to give WARNs and
generally malfunction on system suspend/resume.
The second (the rest of the patches) implements a workaround for HW bug,
which causes physical damage to the board if the HDMI cable is
disconnected at a "wrong" time. The actual fix is in the last patch, but
the board files needed some cleanups and a new GPIO, which is what the
smaller patches do.
The branch is based on fbdev/fbdev-next. Is that ok?
Tomi
The following changes since commit f787f32e67e00b072f46b2ae3c454d2c0a1fcdb7:
module_param: make bool parameters really bool (drivers/video/i810) (2012-01-12 23:28:59 +0000)
are available in the git repository at:
git://gitorious.org/linux-omap-dss2/linux.git for-3.3-rc
Tomi Valkeinen (7):
OMAPDSS: use sync versions of pm_runtime_put
OMAP: 4430SDP/Panda: use gpio_free_array to free HDMI gpios
OMAP: 4430SDP/Panda: rename HPD GPIO to CT_CP_HPD
OMAPDSS: remove wrong HDMI HPD muxing
OMAP: 4430SDP/Panda: setup HDMI GPIO muxes
OMAP: 4430SDP/Panda: add HDMI HPD gpio
OMAPDSS: HDMI: PHY burnout fix
arch/arm/mach-omap2/board-4430sdp.c | 18 ++++++--
arch/arm/mach-omap2/board-omap4panda.c | 18 ++++++--
arch/arm/mach-omap2/display.c | 4 --
drivers/video/omap2/dss/dispc.c | 2 +-
drivers/video/omap2/dss/dsi.c | 2 +-
drivers/video/omap2/dss/dss.c | 2 +-
drivers/video/omap2/dss/hdmi.c | 5 ++-
drivers/video/omap2/dss/rfbi.c | 2 +-
drivers/video/omap2/dss/ti_hdmi.h | 4 ++
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 68 +++++++++++++++++++++++++++--
drivers/video/omap2/dss/venc.c | 2 +-
include/video/omapdss.h | 5 ++
12 files changed, 110 insertions(+), 22 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] video: use gpio_request_one
From: Tomi Valkeinen @ 2012-01-26 12:11 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <000d01ccdc15$d0e2a500$72a7ef00$%han@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 1166 bytes --]
On Thu, 2012-01-26 at 19:32 +0900, Jingoo Han wrote:
> Using gpio_request_one can make the code simpler because it can
> set the direction and initial value in one shot.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> Cc: Michael Hennerich <michael.hennerich@analog.com>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/bf537-lq035.c | 12 +++---------
> drivers/video/bf54x-lq043fb.c | 4 +---
> drivers/video/bfin-lq035q1-fb.c | 8 ++++----
> drivers/video/bfin_adv7393fb.c | 5 +++--
> drivers/video/msm/mddi_client_nt35399.c | 7 +------
> drivers/video/msm/mddi_client_toshiba.c | 7 +------
> drivers/video/omap/lcd_inn1610.c | 10 ++++------
> drivers/video/omap2/displays/panel-taal.c | 4 +---
> .../video/omap2/displays/panel-tpo-td043mtea1.c | 11 ++---------
> 9 files changed, 20 insertions(+), 48 deletions(-)
Looks good to me. For the OMAP parts:
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v7 1/2] video: support MIPI-DSI controller driver
From: Tomi Valkeinen @ 2012-01-26 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4F1F4982.5050000@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 2451 bytes --]
Hi,
On Wed, 2012-01-25 at 09:14 +0900, Donghwa Lee wrote:
> On Sat, 21 Jan 2012 08:51, Andrew Morton wrote:
>
> > On Thu, 19 Jan 2012 20:08:07 +0530
> > Archit <a0393947@ti.com> wrote:
> >
> >> On Thursday 19 January 2012 10:58 AM, Donghwa Lee wrote:
> >>> Samsung S5PC210 and EXYNOS SoC platform has MIPI-DSI controller and MIPI-DSI
> >>> based LCD Panel could be used with it. This patch supports MIPI-DSI driver
> >>> based Samsung SoC chip.
> >>>
> >>> LCD panel driver based MIPI-DSI should be registered to MIPI-DSI driver at
> >>> machine code and LCD panel driver specific function registered to mipi_dsim_ddi
> >>> structure at lcd panel init function called system init.
> >>> In the MIPI-DSI driver, find lcd panel driver by using registered
> >>> lcd panel name, and then initialize lcd panel driver.
> >>>
> >>> Changes since v6:
> >>> - remove obscure compile problems.
> >>> - remove useless codes.
> >>> - modify return errno codes properly
> >>
> >> One more comment about 'mipi_dsim.h', it would be better to put it in
> >> include/video and not 'include/linux'.
> >
> > Yes, that is desirable.
> >
> >>> ---
> >>> drivers/video/Kconfig | 6 +
> >>> drivers/video/Makefile | 2 +
> >>> drivers/video/s5p_mipi_dsi.c | 599 ++++++++++++++++++++++
> >>> drivers/video/s5p_mipi_dsi_common.c | 896 +++++++++++++++++++++++++++++++++
> >>> drivers/video/s5p_mipi_dsi_common.h | 46 ++
> >>> drivers/video/s5p_mipi_dsi_lowlevel.c | 617 +++++++++++++++++++++++
> >>> drivers/video/s5p_mipi_dsi_lowlevel.h | 112 ++++
> >>> drivers/video/s5p_mipi_dsi_regs.h | 149 ++++++
> >>> include/linux/mipi_dsim.h | 359 +++++++++++++
> >>> 9 files changed, 2786 insertions(+), 0 deletions(-)
> >
> > or we could put it in drivers/video/. It all depends on which other
> > drivers we expect will need access to this header.
> >
>
> No, mipi_dsim.h file includes global interface data, callback function called by machine
> file, platform data for mipi-dsi driver and so on. So I think it would be better to put
> in 'include/video' or 'include/linux'.
> Of course it is much better to change name to 's5p_mipi_dsim.h'
The header file looks like a platform specific header, so I agree that
it should start with s5p.
I think we should finally start working on a common DSI framework =).
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v7 2/2] video: backlight: support s6e8ax0 panel driver based on MIPI DSI
From: Tomi Valkeinen @ 2012-01-26 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4F17AA14.8030100@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 1331 bytes --]
Hi,
On Thu, 2012-01-19 at 14:28 +0900, Donghwa Lee wrote:
> This patch is amoled panel driver based MIPI DSI interface.
> S6E8AX0 means it may includes many other ldi controllers, for example,
> S6E8AA0, S6E8AB0, and so on.
>
> This patch can be modified depending on each panel properites. For example,
> second parameter of panel condition register can be changed depending on
> ldi controller or amoled type.
>
> Changes since v6:
> - change data type from const to static const
>
> Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
> Signed-off-by: Inki Dae <inki.dae@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
> drivers/video/backlight/Kconfig | 7 +
> drivers/video/backlight/Makefile | 1 +
> drivers/video/backlight/s6e8ax0.c | 898 +++++++++++++++++++++++++++++++++++++
> drivers/video/backlight/s6e8ax0.h | 21 +
> 4 files changed, 927 insertions(+), 0 deletions(-)
> create mode 100644 drivers/video/backlight/s6e8ax0.c
> create mode 100644 drivers/video/backlight/s6e8ax0.h
Why is this in backlight directory? It's a panel driver, not a backlight
driver.
And the driver is s5p specific, wouldn't a directory like
drivers/video/s5p/, where both the s5p DSI driver from the previous
patch and this panel driver could be?
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox