* [PATCH 0/3] minor console cleanup patches
From: Takashi Iwai @ 2014-05-13 10:09 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Jiri Slaby, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
linux-fbdev, linux-kernel
Hi,
here is a small series of cleanup patches for some annoyance I
stumbled during debugging the framebuffer issues:
[PATCH 1/3] vgacon: Fix & cleanup refcounting
[PATCH 2/3] console: Use explicit pointer type for vc_uni_pagedir*
[PATCH 3/3] console: Remove superfluous readonly check
There should be no functional changes by this.
Takashi
^ permalink raw reply
* [PATCH 1/3] vgacon: Fix & cleanup refcounting
From: Takashi Iwai @ 2014-05-13 10:09 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Jiri Slaby, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
linux-fbdev, linux-kernel
In-Reply-To: <1399975769-30526-1-git-send-email-tiwai@suse.de>
The vgacon driver prepares a two element array of uni_pagedir_loc and
uses the second item as its own reference counter for sharing the
uni_pagedir. And the code assumes blindly that the second item is
available if the assigned vc_uni_pagedir isn't the standard one, which
might be wrong (although currently it's so).
This patch fixes that wrong assumption, and gives a slight cleanup
along with it: namely, instead of array, just give the uni_pagedir_loc
and a separate refcount variable. It makes the code a bit more
understandable at first glance.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
drivers/video/console/vgacon.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
index 9d8feac67637..9e18770aaba6 100644
--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console/vgacon.c
@@ -87,7 +87,8 @@ static void vgacon_save_screen(struct vc_data *c);
static int vgacon_scroll(struct vc_data *c, int t, int b, int dir,
int lines);
static void vgacon_invert_region(struct vc_data *c, u16 * p, int count);
-static unsigned long vgacon_uni_pagedir[2];
+static unsigned long vgacon_uni_pagedir;
+static int vgacon_refcount;
/* Description of the hardware situation */
static int vga_init_done __read_mostly;
@@ -575,12 +576,12 @@ static void vgacon_init(struct vc_data *c, int init)
if (vga_512_chars)
c->vc_hi_font_mask = 0x0800;
p = *c->vc_uni_pagedir_loc;
- if (c->vc_uni_pagedir_loc = &c->vc_uni_pagedir ||
- !--c->vc_uni_pagedir_loc[1])
+ if (c->vc_uni_pagedir_loc != &vgacon_uni_pagedir) {
con_free_unimap(c);
- c->vc_uni_pagedir_loc = vgacon_uni_pagedir;
- vgacon_uni_pagedir[1]++;
- if (!vgacon_uni_pagedir[0] && p)
+ c->vc_uni_pagedir_loc = &vgacon_uni_pagedir;
+ vgacon_refcount++;
+ }
+ if (!vgacon_uni_pagedir && p)
con_set_default_unimap(c);
/* Only set the default if the user didn't deliberately override it */
@@ -597,7 +598,7 @@ static void vgacon_deinit(struct vc_data *c)
vga_set_mem_top(c);
}
- if (!--vgacon_uni_pagedir[1])
+ if (!--vgacon_refcount)
con_free_unimap(c);
c->vc_uni_pagedir_loc = &c->vc_uni_pagedir;
con_set_default_unimap(c);
--
1.9.2
^ permalink raw reply related
* [PATCH 2/3] console: Use explicit pointer type for vc_uni_pagedir* fields
From: Takashi Iwai @ 2014-05-13 10:09 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Jiri Slaby, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
linux-fbdev, linux-kernel
In-Reply-To: <1399975769-30526-1-git-send-email-tiwai@suse.de>
The vc_data.vc_uni_pagedir filed is currently long int, supposedly to
be served generically. This, however, leads to lots of cast to
pointer, and rather it worsens the readability significantly.
Actually, we have now only a single uni_pagedir map implementation,
and this won't change likely. So, it'd be much more simple and
error-prone to just use the exact pointer for struct uni_pagedir
instead of long.
Ditto for vc_uni_pagedir_loc. It's a pointer to the uni_pagedir, thus
it can be changed similarly to the exact type.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
drivers/tty/vt/consolemap.c | 38 +++++++++++++++++++-------------------
drivers/tty/vt/vt.c | 2 +-
drivers/video/console/vgacon.c | 4 ++--
include/linux/console_struct.h | 5 +++--
4 files changed, 25 insertions(+), 24 deletions(-)
diff --git a/drivers/tty/vt/consolemap.c b/drivers/tty/vt/consolemap.c
index 2978ca596a7f..3fdc786b6b2f 100644
--- a/drivers/tty/vt/consolemap.c
+++ b/drivers/tty/vt/consolemap.c
@@ -262,7 +262,7 @@ u16 inverse_translate(struct vc_data *conp, int glyph, int use_unicode)
int m;
if (glyph < 0 || glyph >= MAX_GLYPH)
return 0;
- else if (!(p = (struct uni_pagedir *)*conp->vc_uni_pagedir_loc))
+ else if (!(p = *conp->vc_uni_pagedir_loc))
return glyph;
else if (use_unicode) {
if (!p->inverse_trans_unicode)
@@ -287,7 +287,7 @@ static void update_user_maps(void)
for (i = 0; i < MAX_NR_CONSOLES; i++) {
if (!vc_cons_allocated(i))
continue;
- p = (struct uni_pagedir *)*vc_cons[i].d->vc_uni_pagedir_loc;
+ p = *vc_cons[i].d->vc_uni_pagedir_loc;
if (p && p != q) {
set_inverse_transl(vc_cons[i].d, p, USER_MAP);
set_inverse_trans_unicode(vc_cons[i].d, p);
@@ -418,10 +418,10 @@ void con_free_unimap(struct vc_data *vc)
{
struct uni_pagedir *p;
- p = (struct uni_pagedir *)*vc->vc_uni_pagedir_loc;
+ p = *vc->vc_uni_pagedir_loc;
if (!p)
return;
- *vc->vc_uni_pagedir_loc = 0;
+ *vc->vc_uni_pagedir_loc = NULL;
if (--p->refcount)
return;
con_release_unimap(p);
@@ -436,7 +436,7 @@ static int con_unify_unimap(struct vc_data *conp, struct uni_pagedir *p)
for (i = 0; i < MAX_NR_CONSOLES; i++) {
if (!vc_cons_allocated(i))
continue;
- q = (struct uni_pagedir *)*vc_cons[i].d->vc_uni_pagedir_loc;
+ q = *vc_cons[i].d->vc_uni_pagedir_loc;
if (!q || q = p || q->sum != p->sum)
continue;
for (j = 0; j < 32; j++) {
@@ -459,7 +459,7 @@ static int con_unify_unimap(struct vc_data *conp, struct uni_pagedir *p)
}
if (j = 32) {
q->refcount++;
- *conp->vc_uni_pagedir_loc = (unsigned long)q;
+ *conp->vc_uni_pagedir_loc = q;
con_release_unimap(p);
kfree(p);
return 1;
@@ -500,7 +500,7 @@ static int con_do_clear_unimap(struct vc_data *vc, struct unimapinit *ui)
{
struct uni_pagedir *p, *q;
- p = (struct uni_pagedir *)*vc->vc_uni_pagedir_loc;
+ p = *vc->vc_uni_pagedir_loc;
if (p && p->readonly)
return -EIO;
@@ -512,7 +512,7 @@ static int con_do_clear_unimap(struct vc_data *vc, struct unimapinit *ui)
return -ENOMEM;
}
q->refcount=1;
- *vc->vc_uni_pagedir_loc = (unsigned long)q;
+ *vc->vc_uni_pagedir_loc = q;
} else {
if (p = dflt) dflt = NULL;
p->refcount++;
@@ -539,7 +539,7 @@ int con_set_unimap(struct vc_data *vc, ushort ct, struct unipair __user *list)
console_lock();
/* Save original vc_unipagdir_loc in case we allocate a new one */
- p = (struct uni_pagedir *)*vc->vc_uni_pagedir_loc;
+ p = *vc->vc_uni_pagedir_loc;
if (p->readonly) {
console_unlock();
return -EIO;
@@ -564,7 +564,7 @@ int con_set_unimap(struct vc_data *vc, ushort ct, struct unipair __user *list)
* Since refcount was > 1, con_clear_unimap() allocated a
* a new uni_pagedir for this vc. Re: p != q
*/
- q = (struct uni_pagedir *)*vc->vc_uni_pagedir_loc;
+ q = *vc->vc_uni_pagedir_loc;
/*
* uni_pgdir is a 32*32*64 table with rows allocated
@@ -586,7 +586,7 @@ int con_set_unimap(struct vc_data *vc, ushort ct, struct unipair __user *list)
err1 = con_insert_unipair(q, l, p2[k]);
if (err1) {
p->refcount++;
- *vc->vc_uni_pagedir_loc = (unsigned long)p;
+ *vc->vc_uni_pagedir_loc = p;
con_release_unimap(q);
kfree(q);
console_unlock();
@@ -655,12 +655,12 @@ int con_set_default_unimap(struct vc_data *vc)
struct uni_pagedir *p;
if (dflt) {
- p = (struct uni_pagedir *)*vc->vc_uni_pagedir_loc;
+ p = *vc->vc_uni_pagedir_loc;
if (p = dflt)
return 0;
dflt->refcount++;
- *vc->vc_uni_pagedir_loc = (unsigned long)dflt;
+ *vc->vc_uni_pagedir_loc = dflt;
if (p && !--p->refcount) {
con_release_unimap(p);
kfree(p);
@@ -674,7 +674,7 @@ int con_set_default_unimap(struct vc_data *vc)
if (err)
return err;
- p = (struct uni_pagedir *)*vc->vc_uni_pagedir_loc;
+ p = *vc->vc_uni_pagedir_loc;
q = dfont_unitable;
for (i = 0; i < 256; i++)
@@ -685,7 +685,7 @@ int con_set_default_unimap(struct vc_data *vc)
}
if (con_unify_unimap(vc, p)) {
- dflt = (struct uni_pagedir *)*vc->vc_uni_pagedir_loc;
+ dflt = *vc->vc_uni_pagedir_loc;
return err;
}
@@ -713,9 +713,9 @@ int con_copy_unimap(struct vc_data *dst_vc, struct vc_data *src_vc)
if (*dst_vc->vc_uni_pagedir_loc = *src_vc->vc_uni_pagedir_loc)
return 0;
con_free_unimap(dst_vc);
- q = (struct uni_pagedir *)*src_vc->vc_uni_pagedir_loc;
+ q = *src_vc->vc_uni_pagedir_loc;
q->refcount++;
- *dst_vc->vc_uni_pagedir_loc = (long)q;
+ *dst_vc->vc_uni_pagedir_loc = q;
return 0;
}
EXPORT_SYMBOL(con_copy_unimap);
@@ -737,7 +737,7 @@ int con_get_unimap(struct vc_data *vc, ushort ct, ushort __user *uct, struct uni
ect = 0;
if (*vc->vc_uni_pagedir_loc) {
- p = (struct uni_pagedir *)*vc->vc_uni_pagedir_loc;
+ p = *vc->vc_uni_pagedir_loc;
for (i = 0; i < 32; i++)
if ((p1 = p->uni_pgdir[i]))
for (j = 0; j < 32; j++)
@@ -810,7 +810,7 @@ conv_uni_to_pc(struct vc_data *conp, long ucs)
if (!*conp->vc_uni_pagedir_loc)
return -3;
- p = (struct uni_pagedir *)*conp->vc_uni_pagedir_loc;
+ p = *conp->vc_uni_pagedir_loc;
if ((p1 = p->uni_pgdir[ucs >> 11]) &&
(p2 = p1[(ucs >> 6) & 0x1f]) &&
(h = p2[ucs & 0x3f]) < MAX_GLYPH)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 3ad0b61e35b4..8209bdce7f69 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -735,7 +735,7 @@ static void visual_init(struct vc_data *vc, int num, int init)
vc->vc_num = num;
vc->vc_display_fg = &master_display_fg;
vc->vc_uni_pagedir_loc = &vc->vc_uni_pagedir;
- vc->vc_uni_pagedir = 0;
+ vc->vc_uni_pagedir = NULL;
vc->vc_hi_font_mask = 0;
vc->vc_complement_mask = 0;
vc->vc_can_do_color = 0;
diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
index 9e18770aaba6..f267284b423b 100644
--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console/vgacon.c
@@ -87,7 +87,7 @@ static void vgacon_save_screen(struct vc_data *c);
static int vgacon_scroll(struct vc_data *c, int t, int b, int dir,
int lines);
static void vgacon_invert_region(struct vc_data *c, u16 * p, int count);
-static unsigned long vgacon_uni_pagedir;
+static struct uni_pagedir *vgacon_uni_pagedir;
static int vgacon_refcount;
/* Description of the hardware situation */
@@ -554,7 +554,7 @@ static const char *vgacon_startup(void)
static void vgacon_init(struct vc_data *c, int init)
{
- unsigned long p;
+ struct uni_pagedir *p;
/*
* We cannot be loaded as a module, therefore init is always 1,
diff --git a/include/linux/console_struct.h b/include/linux/console_struct.h
index 7f0c32908568..e859c98d1767 100644
--- a/include/linux/console_struct.h
+++ b/include/linux/console_struct.h
@@ -17,6 +17,7 @@
#include <linux/workqueue.h>
struct vt_struct;
+struct uni_pagedir;
#define NPAR 16
@@ -104,8 +105,8 @@ struct vc_data {
unsigned int vc_bell_pitch; /* Console bell pitch */
unsigned int vc_bell_duration; /* Console bell duration */
struct vc_data **vc_display_fg; /* [!] Ptr to var holding fg console for this display */
- unsigned long vc_uni_pagedir;
- unsigned long *vc_uni_pagedir_loc; /* [!] Location of uni_pagedir variable for this console */
+ struct uni_pagedir *vc_uni_pagedir;
+ struct uni_pagedir **vc_uni_pagedir_loc; /* [!] Location of uni_pagedir variable for this console */
bool vc_panic_force_write; /* when oops/panic this VC can accept forced output/blanking */
/* additional information is in vt_kern.h */
};
--
1.9.2
^ permalink raw reply related
* [PATCH 3/3] console: Remove superfluous readonly check
From: Takashi Iwai @ 2014-05-13 10:09 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Jiri Slaby, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
linux-fbdev, linux-kernel
In-Reply-To: <1399975769-30526-1-git-send-email-tiwai@suse.de>
uni_pagedir.readonly is never set. Let's get rid of superfluous check
codes.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
drivers/tty/vt/consolemap.c | 16 +++-------------
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/tty/vt/consolemap.c b/drivers/tty/vt/consolemap.c
index 3fdc786b6b2f..610b720d3b91 100644
--- a/drivers/tty/vt/consolemap.c
+++ b/drivers/tty/vt/consolemap.c
@@ -179,7 +179,6 @@ struct uni_pagedir {
unsigned long sum;
unsigned char *inverse_translations[4];
u16 *inverse_trans_unicode;
- int readonly;
};
static struct uni_pagedir *dflt;
@@ -501,9 +500,6 @@ static int con_do_clear_unimap(struct vc_data *vc, struct unimapinit *ui)
struct uni_pagedir *p, *q;
p = *vc->vc_uni_pagedir_loc;
- if (p && p->readonly)
- return -EIO;
-
if (!p || --p->refcount) {
q = kzalloc(sizeof(*p), GFP_KERNEL);
if (!q) {
@@ -536,19 +532,13 @@ int con_set_unimap(struct vc_data *vc, ushort ct, struct unipair __user *list)
int err = 0, err1, i;
struct uni_pagedir *p, *q;
+ if (!ct)
+ return 0;
+
console_lock();
/* Save original vc_unipagdir_loc in case we allocate a new one */
p = *vc->vc_uni_pagedir_loc;
- if (p->readonly) {
- console_unlock();
- return -EIO;
- }
-
- if (!ct) {
- console_unlock();
- return 0;
- }
if (p->refcount > 1) {
int j, k;
--
1.9.2
^ permalink raw reply related
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tomi Valkeinen @ 2014-05-13 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140512155132.GH31772@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 3806 bytes --]
On 12/05/14 18:51, Tony Lindgren wrote:
>> It's already in v3.15.
>
> Oh great.. And you dumped it into arch/arm/mach-omap2 too and I somehow
> even acked it :( Looks like there's also the custom mux hacks. And
> custom hwmod hacks. And ongoing soc_is_xxx tinkering. Now let's not add
The omap2_dss_hwmod_data, create_dss_pdev and create_simple_dss_pdev,
omap_display_init stuff can be removed when the DT conversion has been done.
For the omap4_dsi_mux_pads (or the omap5 dsi muxing that was recently
discussed) I still have no solution, but I haven't spent time on it. I
have dropped the omap5 dsi muxing from the latest series for that reason.
dispc_disable_outputs and omap_dss_reset are needed because omap_device
doesn't handle resetting DSS properly, as special steps need to be done
for that. omap_dss_reset is called from the hwmod/omap_device code, so I
don't think this code can be anywhere else.
For the omap_display_get_version() I have no good solution. Making
separate .dts versions for all the needed OMAP ES versions seems like a
huge hassle to me, but that is one solution.
I think that would mean having separate .dtsi files for omapdss for
omap3_es1, omap3_es3plus, omap4_es1, omap4_es2, omap4_es3plus, and then
having separate omapxxxx.dtsi files for all of those, and then separate
board .dts files for the ES versions used on each board.
Or is there some sane way to define such things in dts?
> _any_ new crap into arch/arm/mach-omap2/display.c.
>
> So please consider this a huge eternal NAK to add any more crap to
> arch/arm/mach-omap2/display.c from me. No more new soc_is beyond
> the soc_is_am43xx() you have in linux next. No more adding
> of_find_compatible_node() beyond ti,omap5-dss you have in linux next.
>
> And no more new panel remapping in this file as soon as you have found
> a better solution. Preferrably by v3.17 merge window. This file just
> needs to disappear. Yuk.
Do you object to the compatible string remapping as such, or just that
it's in arch/arm/mach-omap2?
I guess nothing prevents me from moving it to drivers/, and having some
early-ish initcall doing the job.
If the remapping as such is horrible, I'm all ears for better ideas. I
spent quite a lot of time on it, and that's the best I could come up with.
It's rather simple prefixing of the compatible strings for selected
devices. The purpose of that is to have proper data in the .dts files
(which I think is very important) with the cost of having some rather
simple internal hacks in the kernel, which can be removed immediately
when we have a common display driver framework.
>> I'm not sure what it would give us to try to be compatible with
>> simple-panel.txt. The simple-panel bindings won't probably be compatible
>> with the future common display drivers in any case, as the simple-panel
>> binding is just too limited and doesn't describe the hardware fully.
>
> Hmm what else does a panel need where the existing binding cannot be
> extended?
The existing simple-panel binding doesn't describe the connections of
the panel, i.e. its video input. I guess it can be extended, but I don't
see what the benefit is of trying to create new panel bindings
compatible with the simple-panel bindings. As I see, the simple-panel
bindings work only with very limited use cases, where the drivers make
assumptions. Simple panel bindings cannot be used with omapdss, nor can
it be used with the future common display framework.
But I'm not really familiar with using extending current bindings, and
making new bindings compatible with old ones. Can you explain why it'd
be good to have the sharp panel bindings compatible with simple-panel?
In what kind of scenario would it be used?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Javier Martinez Canillas @ 2014-05-13 11:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5371F923.80000@ti.com>
On Tue, May 13, 2014 at 12:51 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 12/05/14 18:51, Tony Lindgren wrote:
>
>>> It's already in v3.15.
>>
>> Oh great.. And you dumped it into arch/arm/mach-omap2 too and I somehow
>> even acked it :( Looks like there's also the custom mux hacks. And
>> custom hwmod hacks. And ongoing soc_is_xxx tinkering. Now let's not add
>
> The omap2_dss_hwmod_data, create_dss_pdev and create_simple_dss_pdev,
> omap_display_init stuff can be removed when the DT conversion has been done.
>
> For the omap4_dsi_mux_pads (or the omap5 dsi muxing that was recently
> discussed) I still have no solution, but I haven't spent time on it. I
> have dropped the omap5 dsi muxing from the latest series for that reason.
>
> dispc_disable_outputs and omap_dss_reset are needed because omap_device
> doesn't handle resetting DSS properly, as special steps need to be done
> for that. omap_dss_reset is called from the hwmod/omap_device code, so I
> don't think this code can be anywhere else.
>
> For the omap_display_get_version() I have no good solution. Making
> separate .dts versions for all the needed OMAP ES versions seems like a
> huge hassle to me, but that is one solution.
>
> I think that would mean having separate .dtsi files for omapdss for
> omap3_es1, omap3_es3plus, omap4_es1, omap4_es2, omap4_es3plus, and then
> having separate omapxxxx.dtsi files for all of those, and then separate
> board .dts files for the ES versions used on each board.
>
> Or is there some sane way to define such things in dts?
>
Unfortunately there isn't.
I have a similar problem with the IGEP boards since there are just too
many variations of them (e.g: DM3730 SoC vs OMAP3530 SoC, NAND vs
OneNAND, 256MB vs 512MB flash memory sizes, with and without wifi
chip, etc).
Since dts are supposed to describe the hardware, each revision with a
slighter variation forces to have a different dts. My solution was to
not try to have a dts for every single variation in mainline but only
one for the most common revision and that could be used as a reference
to modify and ship on each device. Unfortunately that is not possible
to you since each DSS IP block is used by many boards.
>> _any_ new crap into arch/arm/mach-omap2/display.c.
>>
>> So please consider this a huge eternal NAK to add any more crap to
>> arch/arm/mach-omap2/display.c from me. No more new soc_is beyond
>> the soc_is_am43xx() you have in linux next. No more adding
>> of_find_compatible_node() beyond ti,omap5-dss you have in linux next.
>>
>> And no more new panel remapping in this file as soon as you have found
>> a better solution. Preferrably by v3.17 merge window. This file just
>> needs to disappear. Yuk.
>
> Do you object to the compatible string remapping as such, or just that
> it's in arch/arm/mach-omap2?
>
> I guess nothing prevents me from moving it to drivers/, and having some
> early-ish initcall doing the job.
>
> If the remapping as such is horrible, I'm all ears for better ideas. I
> spent quite a lot of time on it, and that's the best I could come up with.
>
> It's rather simple prefixing of the compatible strings for selected
> devices. The purpose of that is to have proper data in the .dts files
> (which I think is very important) with the cost of having some rather
> simple internal hacks in the kernel, which can be removed immediately
> when we have a common display driver framework.
>
Even though the compatible trick that I said before could be an
alternative, it has the problem that does not describes the hardware
as you said. The restriction of the DT being a stable API and get it
right from the beginning forces us to make these kind of technical
decisions.
So, since we can change the kernel later but not the DTS, I agree with
you that the remapping is the least bad of our options.
>>> I'm not sure what it would give us to try to be compatible with
>>> simple-panel.txt. The simple-panel bindings won't probably be compatible
>>> with the future common display drivers in any case, as the simple-panel
>>> binding is just too limited and doesn't describe the hardware fully.
>>
>> Hmm what else does a panel need where the existing binding cannot be
>> extended?
>
> The existing simple-panel binding doesn't describe the connections of
> the panel, i.e. its video input. I guess it can be extended, but I don't
> see what the benefit is of trying to create new panel bindings
> compatible with the simple-panel bindings. As I see, the simple-panel
> bindings work only with very limited use cases, where the drivers make
> assumptions. Simple panel bindings cannot be used with omapdss, nor can
> it be used with the future common display framework.
>
> But I'm not really familiar with using extending current bindings, and
> making new bindings compatible with old ones. Can you explain why it'd
> be good to have the sharp panel bindings compatible with simple-panel?
> In what kind of scenario would it be used?
>
> Tomi
>
>
Best regards,
Javier
^ permalink raw reply
* [PATCH] video: of: display_timing: remove two unsafe error messages
From: Lucas Stach @ 2014-05-13 12:58 UTC (permalink / raw)
To: linux-fbdev
The error message would try to dereference the pointer that
just has been tested to be NULL. As those messages don't
really add any value without the info that the np could
provide, just remove them.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
drivers/video/of_display_timing.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/video/of_display_timing.c b/drivers/video/of_display_timing.c
index ba5b40f581f6..3dc93cfacd47 100644
--- a/drivers/video/of_display_timing.c
+++ b/drivers/video/of_display_timing.c
@@ -115,10 +115,8 @@ int of_get_display_timing(struct device_node *np, const char *name,
{
struct device_node *timing_np;
- if (!np) {
- pr_err("%s: no devicenode given\n", of_node_full_name(np));
+ if (!np)
return -EINVAL;
- }
timing_np = of_get_child_by_name(np, name);
if (!timing_np) {
@@ -142,10 +140,8 @@ struct display_timings *of_get_display_timings(struct device_node *np)
struct device_node *native_mode;
struct display_timings *disp;
- if (!np) {
- pr_err("%s: no device node given\n", of_node_full_name(np));
+ if (!np)
return NULL;
- }
timings_np = of_get_child_by_name(np, "display-timings");
if (!timings_np) {
--
2.0.0.rc0
^ permalink raw reply related
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tony Lindgren @ 2014-05-13 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABxcv==_LCw1kPYm17g=h8VfSN2V_qsgXjTnsy-JOetawSv4pA@mail.gmail.com>
* Javier Martinez Canillas <javier@dowhile0.org> [140513 04:40]:
> On Tue, May 13, 2014 at 12:51 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > On 12/05/14 18:51, Tony Lindgren wrote:
> >
> >>> It's already in v3.15.
> >>
> >> Oh great.. And you dumped it into arch/arm/mach-omap2 too and I somehow
> >> even acked it :( Looks like there's also the custom mux hacks. And
> >> custom hwmod hacks. And ongoing soc_is_xxx tinkering. Now let's not add
> >
> > The omap2_dss_hwmod_data, create_dss_pdev and create_simple_dss_pdev,
> > omap_display_init stuff can be removed when the DT conversion has been done.
Yes great that helps :)
> > For the omap4_dsi_mux_pads (or the omap5 dsi muxing that was recently
> > discussed) I still have no solution, but I haven't spent time on it. I
> > have dropped the omap5 dsi muxing from the latest series for that reason.
OK
> > dispc_disable_outputs and omap_dss_reset are needed because omap_device
> > doesn't handle resetting DSS properly, as special steps need to be done
> > for that. omap_dss_reset is called from the hwmod/omap_device code, so I
> > don't think this code can be anywhere else.
OK that we should be able to do with drivers/reset eventually. The reset
and idle of drivers is also needed for unused devices too, so we can't
have drivers do it in those cases.
> > For the omap_display_get_version() I have no good solution. Making
> > separate .dts versions for all the needed OMAP ES versions seems like a
> > huge hassle to me, but that is one solution.
> >
> > I think that would mean having separate .dtsi files for omapdss for
> > omap3_es1, omap3_es3plus, omap4_es1, omap4_es2, omap4_es3plus, and then
> > having separate omapxxxx.dtsi files for all of those, and then separate
> > board .dts files for the ES versions used on each board.
> >
> > Or is there some sane way to define such things in dts?
> >
>
> Unfortunately there isn't.
>
> I have a similar problem with the IGEP boards since there are just too
> many variations of them (e.g: DM3730 SoC vs OMAP3530 SoC, NAND vs
> OneNAND, 256MB vs 512MB flash memory sizes, with and without wifi
> chip, etc).
>
> Since dts are supposed to describe the hardware, each revision with a
> slighter variation forces to have a different dts. My solution was to
> not try to have a dts for every single variation in mainline but only
> one for the most common revision and that could be used as a reference
> to modify and ship on each device. Unfortunately that is not possible
> to you since each DSS IP block is used by many boards.
Well ideally the revision info for a device would come from device
revision registers rather using the SoC revision. In the DSS case when
the SoC revision is needed by a device it maybe it can be deciphered
from a combination of compatible flag and the clock rate for example?
But yeah I agree we still need revision detection in the kernel
rather than try to create separate .dtsi files for sub-revisions.
> >> _any_ new crap into arch/arm/mach-omap2/display.c.
> >>
> >> So please consider this a huge eternal NAK to add any more crap to
> >> arch/arm/mach-omap2/display.c from me. No more new soc_is beyond
> >> the soc_is_am43xx() you have in linux next. No more adding
> >> of_find_compatible_node() beyond ti,omap5-dss you have in linux next.
> >>
> >> And no more new panel remapping in this file as soon as you have found
> >> a better solution. Preferrably by v3.17 merge window. This file just
> >> needs to disappear. Yuk.
> >
> > Do you object to the compatible string remapping as such, or just that
> > it's in arch/arm/mach-omap2?
It's something I'd rather not have under mach-omap2 as that means that
I may need to deal with it too to some extent. And I don't think we
need to do such remapping, we should be able to use the panel compatible
strings as they are just fine. It should be possible to figure out from
the device tree properties what controller the panel belongs to. Or
for now, use the panel registration to figure out what display controller
it belongs to.
> > I guess nothing prevents me from moving it to drivers/, and having some
> > early-ish initcall doing the job.
/me likes this idea if you need it at all. Stuff like this tends to stay
and spread, so I'd rather not do the remapping of compatible strings at
all.
> > If the remapping as such is horrible, I'm all ears for better ideas. I
> > spent quite a lot of time on it, and that's the best I could come up with.
> >
> > It's rather simple prefixing of the compatible strings for selected
> > devices. The purpose of that is to have proper data in the .dts files
> > (which I think is very important) with the cost of having some rather
> > simple internal hacks in the kernel, which can be removed immediately
> > when we have a common display driver framework.
> >
>
> Even though the compatible trick that I said before could be an
> alternative, it has the problem that does not describes the hardware
> as you said. The restriction of the DT being a stable API and get it
> right from the beginning forces us to make these kind of technical
> decisions.
>
> So, since we can change the kernel later but not the DTS, I agree with
> you that the remapping is the least bad of our options.
Yes the binding for the panel should just describe the panel so it can be
used with whatever display controller. But we do have quite a few buses
probing devices. How about set up the panel probing the same way?
For the panels on display controller, just do the usual
for_each_child_of_node(pdev->dev.of_node, child) and probe them?
It seems the remapping of compatible strings is not needed in this
as we're only picking up panels that are children of the display
controller.
> >>> I'm not sure what it would give us to try to be compatible with
> >>> simple-panel.txt. The simple-panel bindings won't probably be compatible
> >>> with the future common display drivers in any case, as the simple-panel
> >>> binding is just too limited and doesn't describe the hardware fully.
> >>
> >> Hmm what else does a panel need where the existing binding cannot be
> >> extended?
> >
> > The existing simple-panel binding doesn't describe the connections of
> > the panel, i.e. its video input. I guess it can be extended, but I don't
> > see what the benefit is of trying to create new panel bindings
> > compatible with the simple-panel bindings. As I see, the simple-panel
> > bindings work only with very limited use cases, where the drivers make
> > assumptions. Simple panel bindings cannot be used with omapdss, nor can
> > it be used with the future common display framework.
Well it seems at least the reset and enable pin standard from that
binding can be kept.
> > But I'm not really familiar with using extending current bindings, and
> > making new bindings compatible with old ones. Can you explain why it'd
> > be good to have the sharp panel bindings compatible with simple-panel?
> > In what kind of scenario would it be used?
Ideally the panel binding just describes the panel and it should not
matter which display controller it is a child of.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
From: Tony Lindgren @ 2014-05-13 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5370DE42.2060607@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140512 07:45]:
> On 12/05/14 17:39, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [140512 04:36]:
> >> On 09/05/14 17:37, Tony Lindgren wrote:
> >>>
> >>> This is just the 3730-evm with the Sharp VGA panel mentioned in
> >>> this series.
> >>
> >> Hmm, well, those both look fine. The fck is well below the maximum,
> >> which is somewhere around 170MHz-180MHz. The lck/pck ratio is higher
> >> with this patch, but that should affect the GFX overlay.
> >>
> >> So you're just booting, and there are no applications that use the
> >> framebuffer? And there is no rotation or such configured?
> >
> > Right. The rotation is set to 3 though.
>
> Hmm, that's probably the issue then. VRFB rotation is very heavy on the
> memory bandwidth, and is generally a very easy way to get sync lost errors.
I found another case without rotation where the error always triggers.
By forcing 3730-evm LCD panel to QVGA mode it always seems to happen
even without rotation.
Without this patch with errors and no image:
# cat /sys/kernel/debug/omapdss/clk
[ 55.185729] DSS: dss_runtime_get
[ 55.189422] DSS: dss_runtime_put
[ 55.192810] DISPC: dispc_runtime_get
[ 55.196685] DISPC: dispc_runtime_put
- DSS -
DSS_FCK (DSS1_ALWON_FCLK) = 27000000
- DISPC -
dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK)
fck 27000000
- LCD -
LCD clk source = DSS_FCK (DSS1_ALWON_FCLK)
lck 27000000 lck div 1
pck 5400000 pck div 5
With this patch without errors and penguin showing:
# cat /sys/kernel/debug/omapdss/clk
[ 19.905792] DSS: dss_runtime_get
[ 19.909545] DSS: dss_runtime_put
[ 19.912933] DISPC: dispc_runtime_get
[ 19.916778] DISPC: dispc_runtime_put
- DSS -
DSS_FCK (DSS1_ALWON_FCLK) = 108000000
- DISPC -
dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK)
fck 108000000
- LCD -
LCD clk source = DSS_FCK (DSS1_ALWON_FCLK)
lck 108000000 lck div 1
pck 5400000 pck div 20
In this case the errors are different too:
DISPC: channel 0 xres 240 yres 320
DISPC: pck 5400000
DISPC: hsw 3 hfp 3 hbp 39 vsw 1 vfp 2 vbp 7
DISPC: vsync_level 1 hsync_level 1 data_pclk_edge 1 de_level 0 sync_pclk_edge 0
DISPC: hsync 18947Hz, vsync 57Hz
DISPC: lck = 27000000 (1)
DISPC: pck = 5400000 (5)
APPLY: DISPC IRQ: 0x60: GFX_FIFO_UNDERFLOW
APPLY: DISPC IRQ: 0x4062: GFX_FIFO_UNDERFLOW SYNC_LOST
DISPC: dispc_runtime_get
omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
Regarding rotation, it does look like that with VGA mode enabling
rotation makes the error trigger quite often on 3730.
> will handle it fine with the clock rates and bandwidth usage you have
> for your use cases.
I don't think it's all because of rotation. And rotating my head
makes my neck hurt!
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tony Lindgren @ 2014-05-13 21:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140509153008.GC17814@atomide.com>
* Tony Lindgren <tony@atomide.com> [140509 08:31]:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140509 01:31]:
> > On 09/05/14 02:33, Tony Lindgren wrote:
> > > * Tony Lindgren <tony@atomide.com> [140507 11:00]:
> > >> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140507 09:03]:
> > >>> On 07/05/14 18:03, Tony Lindgren wrote:
> > >>>>
> > >>>> BTW, I'm also personally fine with all five gpios showing in a single
> > >>>> gpios property, I'm not too exited about naming anything in DT..
> > >>>
> > >>> I don't have a strong opinion here. I don't have much experience with
> > >>> DT, especially with making bindings compatible with other ones.
> > >>>
> > >>> I'd just forget the simple-panel, and have single gpio array.
> > >>
> > >> Well if it's a don't care flag for both of us, let's try to use
> > >> the existing standard for simple-panel.txt and add mode-gpios
> > >> property. I'll post a patch for that.
> > >
> > > Here's an updated version using enable-gpios, reset-gpios and
> > > mode-gpios. So it follows simple-panel.txt and adds mode-gpios
> > > that's currently specific to this panel only.
> > >
> > > Also updated for -EPROBE_DEFER handling, tested that by changing
> > > one of the GPIOs to be a twl4030 GPIO.
> >
> > To speed things up a bit, I made the changes I suggested. Compile tested
> > only.
>
> OK thanks did not get the penguin with it so need to look at it a bit
> more.
Here's this patch updated again for QVGA and VGA support and to use
your panel remapping. I've also made sure the blanking works properly
on evm-37xx and ldp.
Regards,
Tony
8< --------------------
From: Tony Lindgren <tony@atomide.com>
Date: Mon, 28 Apr 2014 20:22:21 -0700
Subject: [PATCH] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
Add device tree support for sharp-ls037v7dw01 panel.
Note that this patch is using the remapping of the compatible
flag as implemented by Tomi (that I do not like), but seems
like that's currently needed to avoid redoing the panel
bindings later on. And for the record, that has been agreed
to be a temporary measure until the generic display bindings
can be used by DSS.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt
@@ -0,0 +1,44 @@
+SHARP LS037V7DW01 TFT-LCD panel
+=================+
+Required properties:
+- compatible: "sharp,ls037v7dw01"
+
+Optional properties:
+- label: a symbolic name for the panel
+- enable-gpios: a GPIO spec for the optional enable pin
+ this pin is the INI pin as specified in the LS037V7DW01.pdf file.
+- reset-gpios: a GPIO spec for the optional reset pin
+ this pin is the RESB pin as specified in the LS037V7DW01.pdf file.
+- mode-gpios: a GPIO
+ ordered MO, LR, and UD as specified in the LS037V7DW01.pdf file.
+
+Required nodes:
+- Video port for DPI input
+
+This panel can have zero to five GPIOs to configure
+to change configuration between QVGA and VGA mode
+and the scan direction. As these pins can be also
+configured with external pulls, all the GPIOs are
+considered optional with holes in the array.
+
+Example
+-------
+
+Example when connected to a omap2+ based device:
+
+lcd0: display {
+ compatible = "sharp,ls037v7dw01";
+ power-supply = <&lcd_3v3>;
+ enable-gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */
+ reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd RESB */
+ mode-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH /* gpio154, lcd MO */
+ &gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */
+ &gpio1 3 GPIO_ACTIVE_HIGH>; /* gpio3, lcd UD */
+
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+};
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -562,6 +562,7 @@ static const char * const dss_compat_conv_list[] __initconst = {
"hdmi-connector",
"panel-dpi",
"panel-dsi-cm",
+ "sharp,ls037v7dw01",
"sony,acx565akm",
"svideo-connector",
"ti,tfp410",
--- a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
@@ -12,15 +12,18 @@
#include <linux/delay.h>
#include <linux/gpio.h>
#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
-
+#include <linux/regulator/consumer.h>
#include <video/omapdss.h>
#include <video/omap-panel-data.h>
struct panel_drv_data {
struct omap_dss_device dssdev;
struct omap_dss_device *in;
+ struct regulator *vcc;
int data_lines;
@@ -31,9 +34,33 @@ struct panel_drv_data {
struct gpio_desc *mo_gpio; /* low = 480x640, high = 240x320 */
struct gpio_desc *lr_gpio; /* high = conventional horizontal scanning */
struct gpio_desc *ud_gpio; /* high = conventional vertical scanning */
+
+#define SHARP_LS_QVGA (1 << 0)
+ u32 flags;
+};
+
+static const struct omap_video_timings sharp_ls_qvga_timings = {
+ .x_res = 240,
+ .y_res = 320,
+
+ .pixelclock = 5400000,
+
+ .hsw = 3,
+ .hfp = 3,
+ .hbp = 39,
+
+ .vsw = 1,
+ .vfp = 2,
+ .vbp = 7,
+
+ .vsync_level = OMAPDSS_SIG_ACTIVE_LOW,
+ .hsync_level = OMAPDSS_SIG_ACTIVE_LOW,
+ .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
+ .de_level = OMAPDSS_SIG_ACTIVE_HIGH,
+ .sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
};
-static const struct omap_video_timings sharp_ls_timings = {
+static const struct omap_video_timings sharp_ls_vga_timings = {
.x_res = 480,
.y_res = 640,
@@ -95,12 +122,21 @@ static int sharp_ls_enable(struct omap_dss_device *dssdev)
if (omapdss_device_is_enabled(dssdev))
return 0;
- in->ops.dpi->set_data_lines(in, ddata->data_lines);
+ if (ddata->data_lines)
+ in->ops.dpi->set_data_lines(in, ddata->data_lines);
in->ops.dpi->set_timings(in, &ddata->videomode);
+ if (ddata->vcc) {
+ r = regulator_enable(ddata->vcc);
+ if (r != 0)
+ return r;
+ }
+
r = in->ops.dpi->enable(in);
- if (r)
+ if (r) {
+ regulator_disable(ddata->vcc);
return r;
+ }
/* wait couple of vsyncs until enabling the LCD */
msleep(50);
@@ -136,6 +172,9 @@ static void sharp_ls_disable(struct omap_dss_device *dssdev)
in->ops.dpi->disable(in);
+ if (ddata->vcc)
+ regulator_disable(ddata->vcc);
+
dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
}
@@ -243,6 +282,72 @@ static int sharp_ls_probe_pdata(struct platform_device *pdev)
return 0;
}
+static struct gpio_desc *
+sharp_ls_get_gpio_of(struct device *dev, int index, int val, char *desc)
+{
+ struct gpio_desc *gpio;
+
+ gpio = devm_gpiod_get_index(dev, desc, index);
+ if (IS_ERR(gpio))
+ return gpio;
+
+ gpiod_direction_output(gpio, val);
+
+ return gpio;
+}
+
+static int sharp_ls_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev->dev.of_node;
+ struct omap_dss_device *in;
+
+ ddata->vcc = devm_regulator_get(&pdev->dev, "envdd");
+ if (IS_ERR(ddata->vcc)) {
+ dev_err(&pdev->dev, "failed to get regulator\n");
+ return PTR_ERR(ddata->vcc);
+ }
+
+ /* lcd INI */
+ ddata->ini_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 0, "enable");
+ if (PTR_ERR(ddata->ini_gpio) = -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ /* lcd RESB */
+ ddata->resb_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 1, "reset");
+ if (PTR_ERR(ddata->resb_gpio) = -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ /* lcd MO */
+ ddata->mo_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 1, "mode");
+ if (PTR_ERR(ddata->mo_gpio) = -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ if (!IS_ERR(ddata->mo_gpio))
+ if (gpiod_get_raw_value_cansleep(ddata->mo_gpio))
+ ddata->flags |= SHARP_LS_QVGA;
+
+ /* lcd LR */
+ ddata->lr_gpio = sharp_ls_get_gpio_of(&pdev->dev, 1, 1, "mode");
+ if (PTR_ERR(ddata->lr_gpio) = -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ /* lcd UD */
+ ddata->ud_gpio = sharp_ls_get_gpio_of(&pdev->dev, 2, 1, "mode");
+ if (PTR_ERR(ddata->ud_gpio) = -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(&pdev->dev, "failed to find video source\n");
+ return PTR_ERR(in);
+ }
+
+ ddata->in = in;
+
+ return 0;
+}
+
static int sharp_ls_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -259,11 +364,18 @@ static int sharp_ls_probe(struct platform_device *pdev)
r = sharp_ls_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev->dev.of_node) {
+ r = sharp_ls_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
- ddata->videomode = sharp_ls_timings;
+ if (ddata->flags & SHARP_LS_QVGA)
+ ddata->videomode = sharp_ls_qvga_timings;
+ else
+ ddata->videomode = sharp_ls_vga_timings;
dssdev = &ddata->dssdev;
dssdev->dev = &pdev->dev;
@@ -302,12 +414,20 @@ static int __exit sharp_ls_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id sharp_ls_of_match[] = {
+ { .compatible = "omapdss,sharp,ls037v7dw01", },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, sharp_ls_of_match);
+
static struct platform_driver sharp_ls_driver = {
.probe = sharp_ls_probe,
.remove = __exit_p(sharp_ls_remove),
.driver = {
.name = "panel-sharp-ls037v7dw01",
.owner = THIS_MODULE,
+ .of_match_table = sharp_ls_of_match,
},
};
^ permalink raw reply
* Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
From: Tony Lindgren @ 2014-05-13 21:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140509153723.GD17814@atomide.com>
* Tony Lindgren <tony@atomide.com> [140509 08:38]:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140509 00:08]:
> > On 09/05/14 02:36, Tony Lindgren wrote:
> > Why always-on?
>
> Oops, yeah that should not be there. The GPIO is board specific.
Oops, on ldp the regulator is always on tps61130rsa enabled by
twl4030 regen. Here's the updated patch with ldp support fixed
for the GPIOs tested with blank and bl_power.
Regards,
Tony
8< ------------------
From: Tony Lindgren <tony@atomide.com>
Date: Thu, 8 May 2014 17:55:32 -0700
Subject: [PATCH] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
Looks like quite a few omap3 boards have sharp ls037v7dw01 that's
configured as various panel dpi entries for whatever legacy reasons.
For device tree based support, let's just configure these properly for
panel ls037v7dw01 instead of panel dpi.
This patch creates a common file for panel ls037v7dw01, and makes
boards ldp and omap3-evm to use it. The panel for ldp is configured
in the qvga mode and omap3-evm panel in vga mode.
The ls037v7dw01 also seems to be coupled with an ad7846 touchscreen
controller for the omaps, so let's add a basic configuration for
the touchscreen also using the default values.
Note that we can now remove the regulator-name = "vdds_dsi"
entry for ldp, that's no longer needed as we have the entry
for vdds_dsi-supply = <&vpll2>.
Signed-off-by: Tony Lindgren <tony@atomide.com>
--- a/arch/arm/boot/dts/omap3-evm-37xx.dts
+++ b/arch/arm/boot/dts/omap3-evm-37xx.dts
@@ -26,7 +26,44 @@
};
};
+&dss {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &dss_dpi_pins1
+ &dss_dpi_pins2
+ >;
+};
+
&omap3_pmx_core {
+ dss_dpi_pins1: pinmux_dss_dpi_pins2 {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x20d4, PIN_OUTPUT | MUX_MODE0) /* dss_pclk.dss_pclk */
+ OMAP3_CORE1_IOPAD(0x20d6, PIN_OUTPUT | MUX_MODE0) /* dss_hsync.dss_hsync */
+ OMAP3_CORE1_IOPAD(0x20d8, PIN_OUTPUT | MUX_MODE0) /* dss_vsync.dss_vsync */
+ OMAP3_CORE1_IOPAD(0x20da, PIN_OUTPUT | MUX_MODE0) /* dss_acbias.dss_acbias */
+
+ OMAP3_CORE1_IOPAD(0x20e8, PIN_OUTPUT | MUX_MODE0) /* dss_data6.dss_data6 */
+ OMAP3_CORE1_IOPAD(0x20ea, PIN_OUTPUT | MUX_MODE0) /* dss_data7.dss_data7 */
+ OMAP3_CORE1_IOPAD(0x20ec, PIN_OUTPUT | MUX_MODE0) /* dss_data8.dss_data8 */
+ OMAP3_CORE1_IOPAD(0x20ee, PIN_OUTPUT | MUX_MODE0) /* dss_data9.dss_data9 */
+ OMAP3_CORE1_IOPAD(0x20f0, PIN_OUTPUT | MUX_MODE0) /* dss_data10.dss_data10 */
+ OMAP3_CORE1_IOPAD(0x20f2, PIN_OUTPUT | MUX_MODE0) /* dss_data11.dss_data11 */
+ OMAP3_CORE1_IOPAD(0x20f4, PIN_OUTPUT | MUX_MODE0) /* dss_data12.dss_data12 */
+ OMAP3_CORE1_IOPAD(0x20f6, PIN_OUTPUT | MUX_MODE0) /* dss_data13.dss_data13 */
+ OMAP3_CORE1_IOPAD(0x20f8, PIN_OUTPUT | MUX_MODE0) /* dss_data14.dss_data14 */
+ OMAP3_CORE1_IOPAD(0x20fa, PIN_OUTPUT | MUX_MODE0) /* dss_data15.dss_data15 */
+ OMAP3_CORE1_IOPAD(0x20fc, PIN_OUTPUT | MUX_MODE0) /* dss_data16.dss_data16 */
+ OMAP3_CORE1_IOPAD(0x20fe, PIN_OUTPUT | MUX_MODE0) /* dss_data17.dss_data17 */
+
+ OMAP3_CORE1_IOPAD(0x2100, PIN_OUTPUT | MUX_MODE3) /* dss_data18.dss_data0 */
+ OMAP3_CORE1_IOPAD(0x2102, PIN_OUTPUT | MUX_MODE3) /* dss_data19.dss_data1 */
+ OMAP3_CORE1_IOPAD(0x2104, PIN_OUTPUT | MUX_MODE3) /* dss_data20.dss_data2 */
+ OMAP3_CORE1_IOPAD(0x2106, PIN_OUTPUT | MUX_MODE3) /* dss_data21.dss_data3 */
+ OMAP3_CORE1_IOPAD(0x2108, PIN_OUTPUT | MUX_MODE3) /* dss_data22.dss_data4 */
+ OMAP3_CORE1_IOPAD(0x210a, PIN_OUTPUT | MUX_MODE3) /* dss_data23.dss_data5 */
+ >;
+ };
+
mmc1_pins: pinmux_mmc1_pins {
pinctrl-single,pins = <
0x114 (PIN_OUTPUT_PULLUP | MUX_MODE0) /* sdmmc1_clk.sdmmc1_clk */
@@ -75,6 +112,19 @@
};
};
+&omap3_pmx_wkup {
+ dss_dpi_pins2: pinmux_dss_dpi_pins1 {
+ pinctrl-single,pins = <
+ 0x0a (PIN_OUTPUT | MUX_MODE3) /* sys_boot0.dss_data18 */
+ 0x0c (PIN_OUTPUT | MUX_MODE3) /* sys_boot1.dss_data19 */
+ 0x10 (PIN_OUTPUT | MUX_MODE3) /* sys_boot3.dss_data20 */
+ 0x12 (PIN_OUTPUT | MUX_MODE3) /* sys_boot4.dss_data21 */
+ 0x14 (PIN_OUTPUT | MUX_MODE3) /* sys_boot5.dss_data22 */
+ 0x16 (PIN_OUTPUT | MUX_MODE3) /* sys_boot6.dss_data23 */
+ >;
+ };
+};
+
&mmc1 {
pinctrl-names = "default";
pinctrl-0 = <&mmc1_pins>;
--- a/arch/arm/boot/dts/omap3-evm-common.dtsi
+++ b/arch/arm/boot/dts/omap3-evm-common.dtsi
@@ -44,6 +44,11 @@
#include "twl4030.dtsi"
#include "twl4030_omap3.dtsi"
+#include "omap3-panel-sharp-ls037v7dw01.dtsi"
+
+&backlight0 {
+ gpios = <&twl_gpio 18 GPIO_ACTIVE_LOW>;
+};
&i2c2 {
clock-frequency = <400000>;
@@ -61,6 +66,32 @@
};
};
+&lcd_3v3 {
+ gpio = <&gpio5 25 GPIO_ACTIVE_LOW>; /* gpio153 */
+ enable-active-low;
+};
+
+&lcd0 {
+ enable-gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */
+ reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd RESB */
+ /*
+ * The LCD is sideways, so we want the VGA mode instead of
+ * QVGA mode. Probably also want to have omapfb.rotate=3
+ * in the kernel cmdline until there's a binding for that.
+ */
+ mode-gpios = <&gpio5 26 GPIO_ACTIVE_LOW /* gpio154, lcd MO */
+ &gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */
+ &gpio1 3 GPIO_ACTIVE_HIGH>; /* gpio3, lcd UD */
+};
+
+&mcspi1 {
+ tsc2046@0 {
+ interrupt-parent = <&gpio6>;
+ interrupts = <15 0>; /* gpio175 */
+ pendown-gpio = <&gpio6 15 0>;
+ };
+};
+
&mmc1 {
vmmc-supply = <&vmmc1>;
vmmc_aux-supply = <&vsim>;
--- a/arch/arm/boot/dts/omap3-ldp.dts
+++ b/arch/arm/boot/dts/omap3-ldp.dts
@@ -164,6 +164,11 @@
#include "twl4030.dtsi"
#include "twl4030_omap3.dtsi"
+#include "omap3-panel-sharp-ls037v7dw01.dtsi"
+
+&backlight0 {
+ gpios = <&twl_gpio 7 GPIO_ACTIVE_HIGH>;
+};
&i2c2 {
clock-frequency = <400000>;
@@ -173,6 +178,25 @@
clock-frequency = <400000>;
};
+/* tps61130rsa enabled by twl4030 regen */
+&lcd_3v3 {
+ regulator-always-on;
+};
+
+&lcd0 {
+ enable-gpios = <&twl_gpio 15 GPIO_ACTIVE_HIGH>; /* lcd INI */
+ reset-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>; /* gpio55, lcd RESB */
+ mode-gpios = <&gpio2 24 GPIO_ACTIVE_HIGH>; /* gpio56, lcd MO */
+};
+
+&mcspi1 {
+ tsc2046@0 {
+ interrupt-parent = <&gpio2>;
+ interrupts = <22 0>; /* gpio54 */
+ pendown-gpio = <&gpio2 22 0>;
+ };
+};
+
&mmc1 {
/* See 35xx errata 2.1.1.128 in SPRZ278F */
compatible = "ti,omap3-pre-es3-hsmmc";
@@ -251,8 +275,3 @@
/* Needed for ads7846 */
regulator-name = "vcc";
};
-
-&vpll2 {
- /* Needed for DSS */
- regulator-name = "vdds_dsi";
-};
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
@@ -0,0 +1,67 @@
+/*
+ * Common file for omap dpi panels with QVGA and reset pins
+ *
+ * Note that the board specifc DTS file needs to specify
+ * at minimum the GPIO enable-gpios for display, and
+ * gpios for gpio-backlight.
+ */
+
+/ {
+ aliases {
+ display0 = &lcd0;
+ };
+
+ backlight0: backlight {
+ compatible = "gpio-backlight";
+ default-on;
+ };
+
+ /* 3.3V GPIO controlled regulator for LCD_ENVDD */
+ lcd_3v3: regulator-lcd-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "lcd_3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ startup-delay-us = <70000>;
+ };
+
+ lcd0: display {
+ compatible = "sharp,ls037v7dw01";
+ label = "lcd";
+ power-supply = <&lcd_3v3>;
+
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+ };
+};
+
+&dss {
+ status = "ok";
+ vdds_dsi-supply = <&vpll2>;
+ port {
+ dpi_out: endpoint {
+ remote-endpoint = <&lcd_in>;
+ data-lines = <18>;
+ };
+ };
+};
+
+&mcspi1 {
+ tsc2046@0 {
+ reg = <0>; /* CS0 */
+ compatible = "ti,tsc2046";
+ spi-max-frequency = <1000000>;
+ vcc-supply = <&lcd_3v3>;
+ ti,x-min = /bits/ 16 <0>;
+ ti,x-max = /bits/ 16 <8000>;
+ ti,y-min = /bits/ 16 <0>;
+ ti,y-max = /bits/ 16 <4800>;
+ ti,x-plate-ohms = /bits/ 16 <40>;
+ ti,pressure-max = /bits/ 16 <255>;
+ ti,swap-xy;
+ linux,wakeup;
+ };
+};
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tomi Valkeinen @ 2014-05-14 6:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140513152518.GA16837@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 5589 bytes --]
On 13/05/14 18:25, Tony Lindgren wrote:
> Well ideally the revision info for a device would come from device
> revision registers rather using the SoC revision. In the DSS case when
> the SoC revision is needed by a device it maybe it can be deciphered
> from a combination of compatible flag and the clock rate for example?
I've been trying that. The HW guys didn't bother to update the DSS
revision registers, so they are useless. And, for example, the OMAP3 ES
difference is only about bitfield widths in two registers.
I tried writing "too long" value to the register on the earlier ES
version, hoping that the extra bits would be kept at zero, but that
wasn't the case. So I just don't see a way to detect this from the DSS's
point of view.
>>> Do you object to the compatible string remapping as such, or just that
>>> it's in arch/arm/mach-omap2?
>
> It's something I'd rather not have under mach-omap2 as that means that
> I may need to deal with it too to some extent. And I don't think we
> need to do such remapping, we should be able to use the panel compatible
> strings as they are just fine. It should be possible to figure out from
> the device tree properties what controller the panel belongs to. Or
> for now, use the panel registration to figure out what display controller
> it belongs to.
>
>>> I guess nothing prevents me from moving it to drivers/, and having some
>>> early-ish initcall doing the job.
>
> /me likes this idea if you need it at all. Stuff like this tends to stay
> and spread, so I'd rather not do the remapping of compatible strings at
> all.
Yep. I'll look to this. Thinking about it now, it kind of makes more
sense to have it in the omapdss's directory.
>> So, since we can change the kernel later but not the DTS, I agree with
>> you that the remapping is the least bad of our options.
>
> Yes the binding for the panel should just describe the panel so it can be
> used with whatever display controller. But we do have quite a few buses
> probing devices. How about set up the panel probing the same way?
> For the panels on display controller, just do the usual
> for_each_child_of_node(pdev->dev.of_node, child) and probe them?
>
> It seems the remapping of compatible strings is not needed in this
> as we're only picking up panels that are children of the display
> controller.
The panels (or display encoders) are not (usually) children of the
display controller. They are children of their respective control bus.
Say, an i2c panel is a child of i2c bus. If there's no control bus, like
is the case with the sharp panel, it's a platform device.
The video paths of the panels and encoders are connected using the v4l2
style ports/endpoints. We can use those to see what display controller a
panel is connected to, but only after the panel driver has already
probed. We don't have control for the actual probing, as that happens
with whatever the control bus is for the display component.
>>>>> I'm not sure what it would give us to try to be compatible with
>>>>> simple-panel.txt. The simple-panel bindings won't probably be compatible
>>>>> with the future common display drivers in any case, as the simple-panel
>>>>> binding is just too limited and doesn't describe the hardware fully.
>>>>
>>>> Hmm what else does a panel need where the existing binding cannot be
>>>> extended?
>>>
>>> The existing simple-panel binding doesn't describe the connections of
>>> the panel, i.e. its video input. I guess it can be extended, but I don't
>>> see what the benefit is of trying to create new panel bindings
>>> compatible with the simple-panel bindings. As I see, the simple-panel
>>> bindings work only with very limited use cases, where the drivers make
>>> assumptions. Simple panel bindings cannot be used with omapdss, nor can
>>> it be used with the future common display framework.
>
> Well it seems at least the reset and enable pin standard from that
> binding can be kept.
Only enable gpio there. But even that's vague. Do you turn on the power
before or after setting the enable gpio? How long delay should be
between the power and the gpio? Different panels have different rules
for the power-up.
>>> But I'm not really familiar with using extending current bindings, and
>>> making new bindings compatible with old ones. Can you explain why it'd
>>> be good to have the sharp panel bindings compatible with simple-panel?
>>> In what kind of scenario would it be used?
>
> Ideally the panel binding just describes the panel and it should not
> matter which display controller it is a child of.
Yes, but that means the panel bindings need to have enough information
so that all display controllers can use it. Simple-panel bindings do not
have enough information. The simple-panel bindings do not have
information about the video bus input, and it doesn't even have
information about the resolution or bitdepth of the panel.
So I'm still asking, if we create sharp bindings that use the same
properties as the simple-panel bindings, and define that sharp panel is
compatible with simple-panel, what kind of scenario in practice would it
be used in?
Would the scenario be some other OS, that doesn't have a driver for the
sharp panel, but has a driver for the simple-panel? That would only work
if the sharp panel hardware is setup so that only the enable gpio is
needed, so that quite a narrow definition of "compatible".
Or is there some other scenario in which it could be used?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
From: Tomi Valkeinen @ 2014-05-14 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140513152626.GB16837@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 4221 bytes --]
On 13/05/14 18:26, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140512 07:45]:
>> On 12/05/14 17:39, Tony Lindgren wrote:
>>> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140512 04:36]:
>>>> On 09/05/14 17:37, Tony Lindgren wrote:
>>>>>
>>>>> This is just the 3730-evm with the Sharp VGA panel mentioned in
>>>>> this series.
>>>>
>>>> Hmm, well, those both look fine. The fck is well below the maximum,
>>>> which is somewhere around 170MHz-180MHz. The lck/pck ratio is higher
>>>> with this patch, but that should affect the GFX overlay.
>>>>
>>>> So you're just booting, and there are no applications that use the
>>>> framebuffer? And there is no rotation or such configured?
>>>
>>> Right. The rotation is set to 3 though.
>>
>> Hmm, that's probably the issue then. VRFB rotation is very heavy on the
>> memory bandwidth, and is generally a very easy way to get sync lost errors.
>
> I found another case without rotation where the error always triggers.
> By forcing 3730-evm LCD panel to QVGA mode it always seems to happen
> even without rotation.
>
> Without this patch with errors and no image:
>
> # cat /sys/kernel/debug/omapdss/clk
> [ 55.185729] DSS: dss_runtime_get
> [ 55.189422] DSS: dss_runtime_put
> [ 55.192810] DISPC: dispc_runtime_get
> [ 55.196685] DISPC: dispc_runtime_put
> - DSS -
> DSS_FCK (DSS1_ALWON_FCLK) = 27000000
> - DISPC -
> dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK)
> fck 27000000
> - LCD -
> LCD clk source = DSS_FCK (DSS1_ALWON_FCLK)
> lck 27000000 lck div 1
> pck 5400000 pck div 5
>
> With this patch without errors and penguin showing:
>
> # cat /sys/kernel/debug/omapdss/clk
> [ 19.905792] DSS: dss_runtime_get
> [ 19.909545] DSS: dss_runtime_put
> [ 19.912933] DISPC: dispc_runtime_get
> [ 19.916778] DISPC: dispc_runtime_put
> - DSS -
> DSS_FCK (DSS1_ALWON_FCLK) = 108000000
> - DISPC -
> dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK)
> fck 108000000
> - LCD -
> LCD clk source = DSS_FCK (DSS1_ALWON_FCLK)
> lck 108000000 lck div 1
> pck 5400000 pck div 20
>
> In this case the errors are different too:
>
> DISPC: channel 0 xres 240 yres 320
> DISPC: pck 5400000
> DISPC: hsw 3 hfp 3 hbp 39 vsw 1 vfp 2 vbp 7
> DISPC: vsync_level 1 hsync_level 1 data_pclk_edge 1 de_level 0 sync_pclk_edge 0
> DISPC: hsync 18947Hz, vsync 57Hz
> DISPC: lck = 27000000 (1)
> DISPC: pck = 5400000 (5)
> APPLY: DISPC IRQ: 0x60: GFX_FIFO_UNDERFLOW
> APPLY: DISPC IRQ: 0x4062: GFX_FIFO_UNDERFLOW SYNC_LOST
> DISPC: dispc_runtime_get
> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
I'm quite out of ideas... The pixel clock is so low that underflow
shouldn't really happen. I was trying to find 3730 documentation that
would describe the PRCM's multipliers and dividers for DSS (i.e. the
ones you change in this patch), but I didn't find anything.
Maybe the DSS clock's fixed multiplier has been changed for 3730. But in
that case our .dts files related to the clocks are wrong too. The clock
nodes related to this are dpll4_m4x2_mul_ck, which is corresponds to the
"dss_fck_multiplier" value in omapdss, and dpll4_m4_ck, which
corresponds to the "fck_div_max" value.
One thing to try out is, without this patch, change
CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK to force the dss func clock higher.
With QVGA mode, you could try, say, value of 19, which should make sure
the fck is at least 19 times higher than pck.
> Regarding rotation, it does look like that with VGA mode enabling
> rotation makes the error trigger quite often on 3730.
>
>> will handle it fine with the clock rates and bandwidth usage you have
>> for your use cases.
>
> I don't think it's all because of rotation. And rotating my head
No, probably not. The pixel clocks are so low that the rotation should
work fine. Except if there's something wrong the the VRFB or the memory
bus, which make the VRFB rotation not work even with low pixel clocks.
> makes my neck hurt!
You need to learn to hold the device a bit differently!
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [alsa-devel] [PATCH 00/19] Rework OMAP4+ HDMI audio support
From: Jyri Sarha @ 2014-05-14 10:02 UTC (permalink / raw)
To: Joachim Eastwood
Cc: alsa-devel, linux-fbdev, devicetree, linux-omap, liam.r.girdwood,
detheridge, broonie, peter.ujfalusi, Tomi Valkeinen,
Benoit Cousson
In-Reply-To: <CAGhQ9VzjndCBp+ZHS3XPPvS4ors6u9BfHf4NY_HNYN5ynyQOYQ@mail.gmail.com>
On 05/13/2014 12:13 AM, Joachim Eastwood wrote:
> On 12 May 2014 11:12, Jyri Sarha <jsarha@ti.com> wrote:
...
>
> hey, this worked straight away :)
>
> But there seems to be something wrong with the channel mapping.
>
> For stereo (speaker-test -c 2) the mapping is correct.
>
> But for -c 4 and -c 8 it gets weird:
> speaker-test -c 4 -s X # where X is 1-4
> 1: Front Left is Rear Left
> 2: Front Right is Rear Right
> 3: Rear Right is Front Right
> 4: Rear Left is Front Left
>
> speaker-test -c 8 -s X # where X is 1-8
> 1: Front Left is Rear Left
> 2: Center is Rear Left
> 3: Front Right is Rear Right
> 4: Side Right is Front Right
> 5: Rear Right is silent
> 6: Rear Left is Center
> 7: Side Left is Front Left
> 8: LFE - Rear Right
>
> I think you need to check what channel order ALSA expects. I believe
> speaker-test does the right thing on my HTPC normally connected to my
> receiver.
>
I checked the implementation and there was indeed something weird there,
but the implementation can not explain the FL and FR channels jumping
around. FL and FL should always be the first two channels in all
configurations and the implementation does not touch them.
The implementation uses 8ch HDMI setup for anything above 2ch with
"Audio InfoFrame Data Byte 4" set to 0x13. According to CEA-861 specs
this means following channel order: FL, FR, LFE, FC, RL, RR, RLC, RRC
This is a closest match to ALSA 8ch mapping (according to
sound/core/pcm_lib.c) which is: FL, FR, FC, LFE, RL, RR, SL, SR
Current implementation has FLE and FC channels correctly swapped, but it
shifts them to last two channels and RL, RR, SL, SR are shifted down to
fill the place. This is all wrong and I'll try to come up with a fix for
that. Unfortunately I can not test anything beyond 2 ch myself so I
would need someone to volunteer to test my patch.
Best regards,
Jyri
^ permalink raw reply
* [PATCH] offb: Fix little-endian support
From: Takashi Iwai @ 2014-05-14 13:21 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Jean-Christophe Plagniol-Villard, Cedric Le Goater, linux-fbdev,
linux-kernel
Although the color palette was corrected for little endian by the
commit [e1edf18b: offb: Add palette hack for little endian], the
graphics mode is still shown in psychedelic colors. For fixing this
properly, we rather need to correct the RGB offsets depending on
endianess.
Since the RGB base offsets are corrected, we don't need the hack for
pallette color entries. This patch reverts that, too.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
drivers/video/fbdev/offb.c | 51 +++++++++++++++++++++++++++++-----------------
1 file changed, 32 insertions(+), 19 deletions(-)
diff --git a/drivers/video/fbdev/offb.c b/drivers/video/fbdev/offb.c
index 7d44d669d5b6..0224a62aa49d 100644
--- a/drivers/video/fbdev/offb.c
+++ b/drivers/video/fbdev/offb.c
@@ -93,13 +93,6 @@ extern boot_infos_t *boot_infos;
#define FB_RIGHT_POS(p, bpp) (fb_be_math(p) ? 0 : (32 - (bpp)))
-static inline u32 offb_cmap_byteswap(struct fb_info *info, u32 value)
-{
- u32 bpp = info->var.bits_per_pixel;
-
- return cpu_to_be32(value) >> FB_RIGHT_POS(info, bpp);
-}
-
/*
* Set a single color register. The values supplied are already
* rounded down to the hardware's capabilities (according to the
@@ -129,7 +122,7 @@ static int offb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
mask <<= info->var.transp.offset;
value |= mask;
}
- pal[regno] = offb_cmap_byteswap(info, value);
+ pal[regno] = value;
return 0;
}
@@ -451,6 +444,8 @@ static void __init offb_init_fb(const char *name, const char *full_name,
else
fix->visual = FB_VISUAL_TRUECOLOR;
+ info->flags = FBINFO_DEFAULT | FBINFO_MISC_FIRMWARE | foreign_endian;
+
var->xoffset = var->yoffset = 0;
switch (depth) {
case 8:
@@ -466,35 +461,54 @@ static void __init offb_init_fb(const char *name, const char *full_name,
break;
case 15: /* RGB 555 */
var->bits_per_pixel = 16;
- var->red.offset = 10;
+ if (fb_be_math(info)) {
+ var->red.offset = 10;
+ var->green.offset = 5;
+ var->blue.offset = 0;
+ } else {
+ var->red.offset = 0;
+ var->green.offset = 5;
+ var->blue.offset = 10;
+ }
var->red.length = 5;
- var->green.offset = 5;
var->green.length = 5;
- var->blue.offset = 0;
var->blue.length = 5;
var->transp.offset = 0;
var->transp.length = 0;
break;
case 16: /* RGB 565 */
var->bits_per_pixel = 16;
- var->red.offset = 11;
+ if (fb_be_math(info)) {
+ var->red.offset = 11;
+ var->green.offset = 5;
+ var->blue.offset = 0;
+ } else {
+ var->red.offset = 0;
+ var->green.offset = 5;
+ var->blue.offset = 11;
+ }
var->red.length = 5;
- var->green.offset = 5;
var->green.length = 6;
- var->blue.offset = 0;
var->blue.length = 5;
var->transp.offset = 0;
var->transp.length = 0;
break;
case 32: /* RGB 888 */
var->bits_per_pixel = 32;
- var->red.offset = 16;
+ if (fb_be_math(info)) {
+ var->red.offset = 16;
+ var->green.offset = 8;
+ var->blue.offset = 0;
+ var->transp.offset = 24;
+ } else {
+ var->red.offset = 8;
+ var->green.offset = 16;
+ var->blue.offset = 24;
+ var->transp.offset = 0;
+ }
var->red.length = 8;
- var->green.offset = 8;
var->green.length = 8;
- var->blue.offset = 0;
var->blue.length = 8;
- var->transp.offset = 24;
var->transp.length = 8;
break;
}
@@ -521,7 +535,6 @@ static void __init offb_init_fb(const char *name, const char *full_name,
info->fbops = &offb_ops;
info->screen_base = ioremap(address, fix->smem_len);
info->pseudo_palette = (void *) (info + 1);
- info->flags = FBINFO_DEFAULT | FBINFO_MISC_FIRMWARE | foreign_endian;
fb_alloc_cmap(&info->cmap, 256, 0);
--
1.9.2
^ permalink raw reply related
* Re: [PATCH] offb: Fix little-endian support
From: Cedric Le Goater @ 2014-05-14 14:01 UTC (permalink / raw)
To: Takashi Iwai, Tomi Valkeinen
Cc: Jean-Christophe Plagniol-Villard, linux-fbdev, linux-kernel
In-Reply-To: <1400073709-15012-1-git-send-email-tiwai@suse.de>
Hi Iwai-san,
On 05/14/2014 03:21 PM, Takashi Iwai wrote:
> Although the color palette was corrected for little endian by the
> commit [e1edf18b: offb: Add palette hack for little endian], the
> graphics mode is still shown in psychedelic colors.
Are you referring to the linux logo colors ? If so, could you please
try the patch below, it should be a fix.
> For fixing this
> properly, we rather need to correct the RGB offsets depending on
> endianess.
>
> Since the RGB base offsets are corrected, we don't need the hack for
> pallette color entries. This patch reverts that, too.
Are you testing using qemu -vga std -vnc :x ? If so, did you try changing
the depth to 8,15,16,32 ? I think the patch might be breaking big endian
too.
Now, I am far from being an expert on frame buffers. It would be glad
to have some insights on that topic.
Thanks,
C.
[PATCH] fb: fix logo palette entries for little endian
The offb_cmap_byteswap() routine helps byteswapping the color map
entries when required. This patch externalizes and renames the helper
routine to adjust the pseudo palette of the logo when running on
little endian.
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
---
drivers/video/fbmem.c | 6 ++++--
drivers/video/offb.c | 11 +----------
include/linux/fb.h | 8 ++++++++
3 files changed, 13 insertions(+), 12 deletions(-)
Index: linux.git/drivers/video/fbmem.c
=================================--- linux.git.orig/drivers/video/fbmem.c
+++ linux.git/drivers/video/fbmem.c
@@ -252,7 +252,8 @@ static void fb_set_logo_truepalette(str
blueshift = info->var.blue.offset - (8 - info->var.blue.length);
for ( i = 0; i < logo->clutsize; i++) {
- palette[i+32] = (safe_shift((clut[0] & redmask), redshift) |
+ palette[i+32] = fb_cmap_byteswap(info,
+ safe_shift((clut[0] & redmask), redshift) |
safe_shift((clut[1] & greenmask), greenshift) |
safe_shift((clut[2] & bluemask), blueshift));
clut += 3;
@@ -271,7 +272,8 @@ static void fb_set_logo_directpalette(st
blueshift = info->var.blue.offset;
for (i = 32; i < 32 + logo->clutsize; i++)
- palette[i] = i << redshift | i << greenshift | i << blueshift;
+ palette[i] = fb_cmap_byteswap(info, i << redshift |
+ i << greenshift | i << blueshift);
}
static void fb_set_logo(struct fb_info *info,
Index: linux.git/drivers/video/offb.c
=================================--- linux.git.orig/drivers/video/offb.c
+++ linux.git/drivers/video/offb.c
@@ -91,15 +91,6 @@ extern boot_infos_t *boot_infos;
#define AVIVO_DC_LUTB_WHITE_OFFSET_GREEN 0x6cd4
#define AVIVO_DC_LUTB_WHITE_OFFSET_RED 0x6cd8
-#define FB_RIGHT_POS(p, bpp) (fb_be_math(p) ? 0 : (32 - (bpp)))
-
-static inline u32 offb_cmap_byteswap(struct fb_info *info, u32 value)
-{
- u32 bpp = info->var.bits_per_pixel;
-
- return cpu_to_be32(value) >> FB_RIGHT_POS(info, bpp);
-}
-
/*
* Set a single color register. The values supplied are already
* rounded down to the hardware's capabilities (according to the
@@ -129,7 +120,7 @@ static int offb_setcolreg(u_int regno, u
mask <<= info->var.transp.offset;
value |= mask;
}
- pal[regno] = offb_cmap_byteswap(info, value);
+ pal[regno] = fb_cmap_byteswap(info, value);
return 0;
}
Index: linux.git/include/linux/fb.h
=================================--- linux.git.orig/include/linux/fb.h
+++ linux.git/include/linux/fb.h
@@ -582,6 +582,7 @@ static inline struct apertures_struct *a
#endif
+#define FB_RIGHT_POS(p, bpp) (fb_be_math(p) ? 0 : (32 - (bpp)))
#define FB_LEFT_POS(p, bpp) (fb_be_math(p) ? (32 - (bpp)) : 0)
#define FB_SHIFT_HIGH(p, val, bits) (fb_be_math(p) ? (val) >> (bits) : \
(val) << (bits))
@@ -681,6 +682,13 @@ static inline bool fb_be_math(struct fb_
#endif /* CONFIG_FB_FOREIGN_ENDIAN */
}
+static inline u32 fb_cmap_byteswap(struct fb_info *info, u32 value)
+{
+ u32 bpp = info->var.bits_per_pixel;
+
+ return cpu_to_be32(value) >> FB_RIGHT_POS(info, bpp);
+}
+
/* drivers/video/fbsysfs.c */
extern struct fb_info *framebuffer_alloc(size_t size, struct device *dev);
extern void framebuffer_release(struct fb_info *info);
^ permalink raw reply
* Re: [PATCH] offb: Fix little-endian support
From: Takashi Iwai @ 2014-05-14 14:24 UTC (permalink / raw)
To: Cedric Le Goater
Cc: Dinar Valeev, Tomi Valkeinen, Jean-Christophe Plagniol-Villard,
linux-fbdev, linux-kernel
In-Reply-To: <5373772D.9060807@fr.ibm.com>
At Wed, 14 May 2014 16:01:17 +0200,
Cedric Le Goater wrote:
>
> Hi Iwai-san,
>
> On 05/14/2014 03:21 PM, Takashi Iwai wrote:
> > Although the color palette was corrected for little endian by the
> > commit [e1edf18b: offb: Add palette hack for little endian], the
> > graphics mode is still shown in psychedelic colors.
>
> Are you referring to the linux logo colors ? If so, could you please
> try the patch below, it should be a fix.
Not only penguin logo but the whole X graphics got strange colors,
too, according to the bug report. I put the original reporter/tester
(Dinar Valeev) to Cc.
I'm merely a person who tries to fix this mess ;)
BTW, did you try to run X on fbdev?
> > For fixing this
> > properly, we rather need to correct the RGB offsets depending on
> > endianess.
> >
> > Since the RGB base offsets are corrected, we don't need the hack for
> > pallette color entries. This patch reverts that, too.
>
> Are you testing using qemu -vga std -vnc :x ? If so, did you try changing
> the depth to 8,15,16,32 ?
Yes, it was with qemu -vga std -vnc :x.
About different color depths, Dinar can test / clarify better, I
suppose.
> I think the patch might be breaking big endian
> too.
Big endian should work as is because my patch uses the original
offsets when fb_be_math() is true. It corrects the RGB offsets if
!fb_be_math().
But, I'm also entirely not sure whether this is 100% correct, either.
Namely, if the RGB offsets were correct for some little endian
machines with offb, my patch would break it, of course. But, then
your previous fix must have already broken it as well, so I took the
same fb_be_math() check.
thanks,
Takashi
> Now, I am far from being an expert on frame buffers. It would be glad
> to have some insights on that topic.
>
> Thanks,
>
> C.
>
>
> [PATCH] fb: fix logo palette entries for little endian
>
> The offb_cmap_byteswap() routine helps byteswapping the color map
> entries when required. This patch externalizes and renames the helper
> routine to adjust the pseudo palette of the logo when running on
> little endian.
>
> Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
> ---
> drivers/video/fbmem.c | 6 ++++--
> drivers/video/offb.c | 11 +----------
> include/linux/fb.h | 8 ++++++++
> 3 files changed, 13 insertions(+), 12 deletions(-)
>
> Index: linux.git/drivers/video/fbmem.c
> =================================> --- linux.git.orig/drivers/video/fbmem.c
> +++ linux.git/drivers/video/fbmem.c
> @@ -252,7 +252,8 @@ static void fb_set_logo_truepalette(str
> blueshift = info->var.blue.offset - (8 - info->var.blue.length);
>
> for ( i = 0; i < logo->clutsize; i++) {
> - palette[i+32] = (safe_shift((clut[0] & redmask), redshift) |
> + palette[i+32] = fb_cmap_byteswap(info,
> + safe_shift((clut[0] & redmask), redshift) |
> safe_shift((clut[1] & greenmask), greenshift) |
> safe_shift((clut[2] & bluemask), blueshift));
> clut += 3;
> @@ -271,7 +272,8 @@ static void fb_set_logo_directpalette(st
> blueshift = info->var.blue.offset;
>
> for (i = 32; i < 32 + logo->clutsize; i++)
> - palette[i] = i << redshift | i << greenshift | i << blueshift;
> + palette[i] = fb_cmap_byteswap(info, i << redshift |
> + i << greenshift | i << blueshift);
> }
>
> static void fb_set_logo(struct fb_info *info,
> Index: linux.git/drivers/video/offb.c
> =================================> --- linux.git.orig/drivers/video/offb.c
> +++ linux.git/drivers/video/offb.c
> @@ -91,15 +91,6 @@ extern boot_infos_t *boot_infos;
> #define AVIVO_DC_LUTB_WHITE_OFFSET_GREEN 0x6cd4
> #define AVIVO_DC_LUTB_WHITE_OFFSET_RED 0x6cd8
>
> -#define FB_RIGHT_POS(p, bpp) (fb_be_math(p) ? 0 : (32 - (bpp)))
> -
> -static inline u32 offb_cmap_byteswap(struct fb_info *info, u32 value)
> -{
> - u32 bpp = info->var.bits_per_pixel;
> -
> - return cpu_to_be32(value) >> FB_RIGHT_POS(info, bpp);
> -}
> -
> /*
> * Set a single color register. The values supplied are already
> * rounded down to the hardware's capabilities (according to the
> @@ -129,7 +120,7 @@ static int offb_setcolreg(u_int regno, u
> mask <<= info->var.transp.offset;
> value |= mask;
> }
> - pal[regno] = offb_cmap_byteswap(info, value);
> + pal[regno] = fb_cmap_byteswap(info, value);
> return 0;
> }
>
> Index: linux.git/include/linux/fb.h
> =================================> --- linux.git.orig/include/linux/fb.h
> +++ linux.git/include/linux/fb.h
> @@ -582,6 +582,7 @@ static inline struct apertures_struct *a
>
> #endif
>
> +#define FB_RIGHT_POS(p, bpp) (fb_be_math(p) ? 0 : (32 - (bpp)))
> #define FB_LEFT_POS(p, bpp) (fb_be_math(p) ? (32 - (bpp)) : 0)
> #define FB_SHIFT_HIGH(p, val, bits) (fb_be_math(p) ? (val) >> (bits) : \
> (val) << (bits))
> @@ -681,6 +682,13 @@ static inline bool fb_be_math(struct fb_
> #endif /* CONFIG_FB_FOREIGN_ENDIAN */
> }
>
> +static inline u32 fb_cmap_byteswap(struct fb_info *info, u32 value)
> +{
> + u32 bpp = info->var.bits_per_pixel;
> +
> + return cpu_to_be32(value) >> FB_RIGHT_POS(info, bpp);
> +}
> +
> /* drivers/video/fbsysfs.c */
> extern struct fb_info *framebuffer_alloc(size_t size, struct device *dev);
> extern void framebuffer_release(struct fb_info *info);
>
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tony Lindgren @ 2014-05-14 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53730AFB.2090800@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140513 23:20]:
> On 13/05/14 18:25, Tony Lindgren wrote:
>
> > Well ideally the revision info for a device would come from device
> > revision registers rather using the SoC revision. In the DSS case when
> > the SoC revision is needed by a device it maybe it can be deciphered
> > from a combination of compatible flag and the clock rate for example?
>
> I've been trying that. The HW guys didn't bother to update the DSS
> revision registers, so they are useless. And, for example, the OMAP3 ES
> difference is only about bitfield widths in two registers.
>
> I tried writing "too long" value to the register on the earlier ES
> version, hoping that the extra bits would be kept at zero, but that
> wasn't the case. So I just don't see a way to detect this from the DSS's
> point of view.
>
> >>> Do you object to the compatible string remapping as such, or just that
> >>> it's in arch/arm/mach-omap2?
> >
> > It's something I'd rather not have under mach-omap2 as that means that
> > I may need to deal with it too to some extent. And I don't think we
> > need to do such remapping, we should be able to use the panel compatible
> > strings as they are just fine. It should be possible to figure out from
> > the device tree properties what controller the panel belongs to. Or
> > for now, use the panel registration to figure out what display controller
> > it belongs to.
> >
> >>> I guess nothing prevents me from moving it to drivers/, and having some
> >>> early-ish initcall doing the job.
> >
> > /me likes this idea if you need it at all. Stuff like this tends to stay
> > and spread, so I'd rather not do the remapping of compatible strings at
> > all.
>
> Yep. I'll look to this. Thinking about it now, it kind of makes more
> sense to have it in the omapdss's directory.
OK thanks.
> >> So, since we can change the kernel later but not the DTS, I agree with
> >> you that the remapping is the least bad of our options.
> >
> > Yes the binding for the panel should just describe the panel so it can be
> > used with whatever display controller. But we do have quite a few buses
> > probing devices. How about set up the panel probing the same way?
>
> > For the panels on display controller, just do the usual
> > for_each_child_of_node(pdev->dev.of_node, child) and probe them?
> >
> > It seems the remapping of compatible strings is not needed in this
> > as we're only picking up panels that are children of the display
> > controller.
>
> The panels (or display encoders) are not (usually) children of the
> display controller. They are children of their respective control bus.
> Say, an i2c panel is a child of i2c bus. If there's no control bus, like
> is the case with the sharp panel, it's a platform device.
OK
> The video paths of the panels and encoders are connected using the v4l2
> style ports/endpoints. We can use those to see what display controller a
> panel is connected to, but only after the panel driver has already
> probed. We don't have control for the actual probing, as that happens
> with whatever the control bus is for the display component.
OK. So with generic panels, you can just let the panels probe with
the right compatible flag then and let the ports/endpoints registration
to figure out if the panel is usable for the display controller in
question.
> >>>>> I'm not sure what it would give us to try to be compatible with
> >>>>> simple-panel.txt. The simple-panel bindings won't probably be compatible
> >>>>> with the future common display drivers in any case, as the simple-panel
> >>>>> binding is just too limited and doesn't describe the hardware fully.
> >>>>
> >>>> Hmm what else does a panel need where the existing binding cannot be
> >>>> extended?
> >>>
> >>> The existing simple-panel binding doesn't describe the connections of
> >>> the panel, i.e. its video input. I guess it can be extended, but I don't
> >>> see what the benefit is of trying to create new panel bindings
> >>> compatible with the simple-panel bindings. As I see, the simple-panel
> >>> bindings work only with very limited use cases, where the drivers make
> >>> assumptions. Simple panel bindings cannot be used with omapdss, nor can
> >>> it be used with the future common display framework.
> >
> > Well it seems at least the reset and enable pin standard from that
> > binding can be kept.
>
> Only enable gpio there. But even that's vague. Do you turn on the power
> before or after setting the enable gpio? How long delay should be
> between the power and the gpio? Different panels have different rules
> for the power-up.
Sure, it's a complex problem. But for the enable gpio..
Maybe the enable GPIO should be treated as a regulator? That would allow
specifying first the source regulator startup delay, and then the
panel has it's own startup delay.
> >>> But I'm not really familiar with using extending current bindings, and
> >>> making new bindings compatible with old ones. Can you explain why it'd
> >>> be good to have the sharp panel bindings compatible with simple-panel?
> >>> In what kind of scenario would it be used?
> >
> > Ideally the panel binding just describes the panel and it should not
> > matter which display controller it is a child of.
>
> Yes, but that means the panel bindings need to have enough information
> so that all display controllers can use it. Simple-panel bindings do not
> have enough information. The simple-panel bindings do not have
> information about the video bus input, and it doesn't even have
> information about the resolution or bitdepth of the panel.
Some of that you can hide into the panel driver based on the compatible
flag. So why not already do something like this in the .dts files
instead of the remapping:
compatible = "sharp,ls037v7dw01-omap-dss", "sharp,ls037v7dw01";
And drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
would only claim to be compatible with "sharp,ls037v7dw01-omap-dss".
Then when the common panel framework is available, you can stop
parsing sharp,ls037v7dw01-omap-dss but the .dts files don't need
to be changed and it's fine to keep "sharp,ls037v7dw01-omap-dss"
in the .dts files.
> So I'm still asking, if we create sharp bindings that use the same
> properties as the simple-panel bindings, and define that sharp panel is
> compatible with simple-panel, what kind of scenario in practice would it
> be used in?
Well with the above example, just by dss with "sharp,ls037v7dw01-omap-dss"
until some other SoC notices it can use the GPIO parts of the panel
code at least :)
> Would the scenario be some other OS, that doesn't have a driver for the
> sharp panel, but has a driver for the simple-panel? That would only work
> if the sharp panel hardware is setup so that only the enable gpio is
> needed, so that quite a narrow definition of "compatible".
That's where we can use the compatible flags and just avoid parsing
the generic compatible flag unless some common framework is available.
> Or is there some other scenario in which it could be used?
I guess other OS or other SoC with a different display controller
but the same panel.
Regards,
Tony
^ permalink raw reply
* Re: [alsa-devel] [PATCH 00/19] Rework OMAP4+ HDMI audio support
From: Joachim Eastwood @ 2014-05-14 16:25 UTC (permalink / raw)
To: Jyri Sarha
Cc: alsa-devel, linux-fbdev, devicetree, linux-omap, liam.r.girdwood,
detheridge, broonie, peter.ujfalusi, Tomi Valkeinen,
Benoit Cousson
In-Reply-To: <53733F2E.4030803@ti.com>
On 14 May 2014 12:02, Jyri Sarha <jsarha@ti.com> wrote:
> On 05/13/2014 12:13 AM, Joachim Eastwood wrote:
>>
>> On 12 May 2014 11:12, Jyri Sarha <jsarha@ti.com> wrote:
>
> ...
>
>>
>> hey, this worked straight away :)
>>
>> But there seems to be something wrong with the channel mapping.
>>
>> For stereo (speaker-test -c 2) the mapping is correct.
>>
>> But for -c 4 and -c 8 it gets weird:
>> speaker-test -c 4 -s X # where X is 1-4
>> 1: Front Left is Rear Left
>> 2: Front Right is Rear Right
>> 3: Rear Right is Front Right
>> 4: Rear Left is Front Left
>>
>> speaker-test -c 8 -s X # where X is 1-8
>> 1: Front Left is Rear Left
>> 2: Center is Rear Left
>> 3: Front Right is Rear Right
>> 4: Side Right is Front Right
>> 5: Rear Right is silent
>> 6: Rear Left is Center
>> 7: Side Left is Front Left
>> 8: LFE - Rear Right
>>
>> I think you need to check what channel order ALSA expects. I believe
>> speaker-test does the right thing on my HTPC normally connected to my
>> receiver.
>>
>
> I checked the implementation and there was indeed something weird there, but
> the implementation can not explain the FL and FR channels jumping around. FL
> and FL should always be the first two channels in all configurations and the
> implementation does not touch them.
>
> The implementation uses 8ch HDMI setup for anything above 2ch with "Audio
> InfoFrame Data Byte 4" set to 0x13. According to CEA-861 specs this means
> following channel order: FL, FR, LFE, FC, RL, RR, RLC, RRC
>
> This is a closest match to ALSA 8ch mapping (according to
> sound/core/pcm_lib.c) which is: FL, FR, FC, LFE, RL, RR, SL, SR
hm, okey. I haven't look at the code but it do seem strange. But with
speaker-test -c 4 the front and back are surely swapped here.
I'll do some more testing and also check with my HTPC. btw, I only
have a 5.1 setup over here so I can't test all the discrete channels.
> Current implementation has FLE and FC channels correctly swapped, but it
> shifts them to last two channels and RL, RR, SL, SR are shifted down to fill
> the place. This is all wrong and I'll try to come up with a fix for that.
> Unfortunately I can not test anything beyond 2 ch myself so I would need
> someone to volunteer to test my patch.
I have the dev kit setup up over here so I can test your patches.
regards
Joachim Eastwood
^ permalink raw reply
* Re: [PATCH] offb: Fix little-endian support
From: Geert Uytterhoeven @ 2014-05-14 16:56 UTC (permalink / raw)
To: Cedric Le Goater
Cc: Takashi Iwai, Tomi Valkeinen, Jean-Christophe Plagniol-Villard,
Linux Fbdev development list, linux-kernel@vger.kernel.org
In-Reply-To: <5373772D.9060807@fr.ibm.com>
On Wed, May 14, 2014 at 4:01 PM, Cedric Le Goater <clg@fr.ibm.com> wrote:
> --- linux.git.orig/drivers/video/fbmem.c
> +++ linux.git/drivers/video/fbmem.c
> @@ -252,7 +252,8 @@ static void fb_set_logo_truepalette(str
> blueshift = info->var.blue.offset - (8 - info->var.blue.length);
>
> for ( i = 0; i < logo->clutsize; i++) {
> - palette[i+32] = (safe_shift((clut[0] & redmask), redshift) |
> + palette[i+32] = fb_cmap_byteswap(info,
> + safe_shift((clut[0] & redmask), redshift) |
> safe_shift((clut[1] & greenmask), greenshift) |
> safe_shift((clut[2] & bluemask), blueshift));
> clut += 3;
> @@ -271,7 +272,8 @@ static void fb_set_logo_directpalette(st
> blueshift = info->var.blue.offset;
>
> for (i = 32; i < 32 + logo->clutsize; i++)
> - palette[i] = i << redshift | i << greenshift | i << blueshift;
> + palette[i] = fb_cmap_byteswap(info, i << redshift |
> + i << greenshift | i << blueshift);
I find it very strange you have to touch the generic code in such a way...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] offb: Fix little-endian support
From: Cedric Le Goater @ 2014-05-14 17:04 UTC (permalink / raw)
To: Takashi Iwai
Cc: Dinar Valeev, Tomi Valkeinen, Jean-Christophe Plagniol-Villard,
linux-fbdev, linux-kernel
In-Reply-To: <s5hha4sh20d.wl%tiwai@suse.de>
On 05/14/2014 04:24 PM, Takashi Iwai wrote:
> At Wed, 14 May 2014 16:01:17 +0200,
> Cedric Le Goater wrote:
>>
>> Hi Iwai-san,
>>
>> On 05/14/2014 03:21 PM, Takashi Iwai wrote:
>>> Although the color palette was corrected for little endian by the
>>> commit [e1edf18b: offb: Add palette hack for little endian], the
>>> graphics mode is still shown in psychedelic colors.
>>
>> Are you referring to the linux logo colors ? If so, could you please
>> try the patch below, it should be a fix.
>
> Not only penguin logo but the whole X graphics got strange colors,
> too, according to the bug report. I put the original reporter/tester
> (Dinar Valeev) to Cc.
> I'm merely a person who tries to fix this mess ;)
>
> BTW, did you try to run X on fbdev?
Not at the time, I was working on the console only, BE and LE.
I just tried fbdev and indeed this is a psychedelic mess :)
Your fix has also issues on BE and console and the patch of mine
below is of no use for fbdev. Damn, this is a nightmare.
C.
>>> For fixing this
>>> properly, we rather need to correct the RGB offsets depending on
>>> endianess.
>>>
>>> Since the RGB base offsets are corrected, we don't need the hack for
>>> pallette color entries. This patch reverts that, too.
>>
>> Are you testing using qemu -vga std -vnc :x ? If so, did you try changing
>> the depth to 8,15,16,32 ?
>
> Yes, it was with qemu -vga std -vnc :x.
> About different color depths, Dinar can test / clarify better, I
> suppose.
>
>> I think the patch might be breaking big endian
>> too.
>
> Big endian should work as is because my patch uses the original
> offsets when fb_be_math() is true. It corrects the RGB offsets if
> !fb_be_math().
>
> But, I'm also entirely not sure whether this is 100% correct, either.
> Namely, if the RGB offsets were correct for some little endian
> machines with offb, my patch would break it, of course. But, then
> your previous fix must have already broken it as well, so I took the
> same fb_be_math() check.
>
>
> thanks,
>
> Takashi
>
>> Now, I am far from being an expert on frame buffers. It would be glad
>> to have some insights on that topic.
>>
>> Thanks,
>>
>> C.
>>
>>
>> [PATCH] fb: fix logo palette entries for little endian
>>
>> The offb_cmap_byteswap() routine helps byteswapping the color map
>> entries when required. This patch externalizes and renames the helper
>> routine to adjust the pseudo palette of the logo when running on
>> little endian.
>>
>> Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
>> ---
>> drivers/video/fbmem.c | 6 ++++--
>> drivers/video/offb.c | 11 +----------
>> include/linux/fb.h | 8 ++++++++
>> 3 files changed, 13 insertions(+), 12 deletions(-)
>>
>> Index: linux.git/drivers/video/fbmem.c
>> =================================>> --- linux.git.orig/drivers/video/fbmem.c
>> +++ linux.git/drivers/video/fbmem.c
>> @@ -252,7 +252,8 @@ static void fb_set_logo_truepalette(str
>> blueshift = info->var.blue.offset - (8 - info->var.blue.length);
>>
>> for ( i = 0; i < logo->clutsize; i++) {
>> - palette[i+32] = (safe_shift((clut[0] & redmask), redshift) |
>> + palette[i+32] = fb_cmap_byteswap(info,
>> + safe_shift((clut[0] & redmask), redshift) |
>> safe_shift((clut[1] & greenmask), greenshift) |
>> safe_shift((clut[2] & bluemask), blueshift));
>> clut += 3;
>> @@ -271,7 +272,8 @@ static void fb_set_logo_directpalette(st
>> blueshift = info->var.blue.offset;
>>
>> for (i = 32; i < 32 + logo->clutsize; i++)
>> - palette[i] = i << redshift | i << greenshift | i << blueshift;
>> + palette[i] = fb_cmap_byteswap(info, i << redshift |
>> + i << greenshift | i << blueshift);
>> }
>>
>> static void fb_set_logo(struct fb_info *info,
>> Index: linux.git/drivers/video/offb.c
>> =================================>> --- linux.git.orig/drivers/video/offb.c
>> +++ linux.git/drivers/video/offb.c
>> @@ -91,15 +91,6 @@ extern boot_infos_t *boot_infos;
>> #define AVIVO_DC_LUTB_WHITE_OFFSET_GREEN 0x6cd4
>> #define AVIVO_DC_LUTB_WHITE_OFFSET_RED 0x6cd8
>>
>> -#define FB_RIGHT_POS(p, bpp) (fb_be_math(p) ? 0 : (32 - (bpp)))
>> -
>> -static inline u32 offb_cmap_byteswap(struct fb_info *info, u32 value)
>> -{
>> - u32 bpp = info->var.bits_per_pixel;
>> -
>> - return cpu_to_be32(value) >> FB_RIGHT_POS(info, bpp);
>> -}
>> -
>> /*
>> * Set a single color register. The values supplied are already
>> * rounded down to the hardware's capabilities (according to the
>> @@ -129,7 +120,7 @@ static int offb_setcolreg(u_int regno, u
>> mask <<= info->var.transp.offset;
>> value |= mask;
>> }
>> - pal[regno] = offb_cmap_byteswap(info, value);
>> + pal[regno] = fb_cmap_byteswap(info, value);
>> return 0;
>> }
>>
>> Index: linux.git/include/linux/fb.h
>> =================================>> --- linux.git.orig/include/linux/fb.h
>> +++ linux.git/include/linux/fb.h
>> @@ -582,6 +582,7 @@ static inline struct apertures_struct *a
>>
>> #endif
>>
>> +#define FB_RIGHT_POS(p, bpp) (fb_be_math(p) ? 0 : (32 - (bpp)))
>> #define FB_LEFT_POS(p, bpp) (fb_be_math(p) ? (32 - (bpp)) : 0)
>> #define FB_SHIFT_HIGH(p, val, bits) (fb_be_math(p) ? (val) >> (bits) : \
>> (val) << (bits))
>> @@ -681,6 +682,13 @@ static inline bool fb_be_math(struct fb_
>> #endif /* CONFIG_FB_FOREIGN_ENDIAN */
>> }
>>
>> +static inline u32 fb_cmap_byteswap(struct fb_info *info, u32 value)
>> +{
>> + u32 bpp = info->var.bits_per_pixel;
>> +
>> + return cpu_to_be32(value) >> FB_RIGHT_POS(info, bpp);
>> +}
>> +
>> /* drivers/video/fbsysfs.c */
>> extern struct fb_info *framebuffer_alloc(size_t size, struct device *dev);
>> extern void framebuffer_release(struct fb_info *info);
>>
>
^ permalink raw reply
* Re: [PATCH] offb: Fix little-endian support
From: Takashi Iwai @ 2014-05-14 17:57 UTC (permalink / raw)
To: Cedric Le Goater
Cc: Dinar Valeev, Tomi Valkeinen, Jean-Christophe Plagniol-Villard,
linux-fbdev, linux-kernel
In-Reply-To: <5373A200.6080301@fr.ibm.com>
At Wed, 14 May 2014 19:04:00 +0200,
Cedric Le Goater wrote:
>
> On 05/14/2014 04:24 PM, Takashi Iwai wrote:
> > At Wed, 14 May 2014 16:01:17 +0200,
> > Cedric Le Goater wrote:
> >>
> >> Hi Iwai-san,
> >>
> >> On 05/14/2014 03:21 PM, Takashi Iwai wrote:
> >>> Although the color palette was corrected for little endian by the
> >>> commit [e1edf18b: offb: Add palette hack for little endian], the
> >>> graphics mode is still shown in psychedelic colors.
> >>
> >> Are you referring to the linux logo colors ? If so, could you please
> >> try the patch below, it should be a fix.
> >
> > Not only penguin logo but the whole X graphics got strange colors,
> > too, according to the bug report. I put the original reporter/tester
> > (Dinar Valeev) to Cc.
> > I'm merely a person who tries to fix this mess ;)
> >
> > BTW, did you try to run X on fbdev?
>
> Not at the time, I was working on the console only, BE and LE.
> I just tried fbdev and indeed this is a psychedelic mess :)
>
> Your fix has also issues on BE and console and the patch of mine
> below is of no use for fbdev. Damn, this is a nightmare.
Hm, so it actually regressed on BE?
It's strange because fb_math_be() should be true and the patch won't
change the values in that case...
Takashi
>
> C.
>
> >>> For fixing this
> >>> properly, we rather need to correct the RGB offsets depending on
> >>> endianess.
> >>>
> >>> Since the RGB base offsets are corrected, we don't need the hack for
> >>> pallette color entries. This patch reverts that, too.
> >>
> >> Are you testing using qemu -vga std -vnc :x ? If so, did you try changing
> >> the depth to 8,15,16,32 ?
> >
> > Yes, it was with qemu -vga std -vnc :x.
> > About different color depths, Dinar can test / clarify better, I
> > suppose.
> >
> >> I think the patch might be breaking big endian
> >> too.
> >
> > Big endian should work as is because my patch uses the original
> > offsets when fb_be_math() is true. It corrects the RGB offsets if
> > !fb_be_math().
> >
> > But, I'm also entirely not sure whether this is 100% correct, either.
> > Namely, if the RGB offsets were correct for some little endian
> > machines with offb, my patch would break it, of course. But, then
> > your previous fix must have already broken it as well, so I took the
> > same fb_be_math() check.
> >
> >
> > thanks,
> >
> > Takashi
> >
> >> Now, I am far from being an expert on frame buffers. It would be glad
> >> to have some insights on that topic.
> >>
> >> Thanks,
> >>
> >> C.
> >>
> >>
> >> [PATCH] fb: fix logo palette entries for little endian
> >>
> >> The offb_cmap_byteswap() routine helps byteswapping the color map
> >> entries when required. This patch externalizes and renames the helper
> >> routine to adjust the pseudo palette of the logo when running on
> >> little endian.
> >>
> >> Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
> >> ---
> >> drivers/video/fbmem.c | 6 ++++--
> >> drivers/video/offb.c | 11 +----------
> >> include/linux/fb.h | 8 ++++++++
> >> 3 files changed, 13 insertions(+), 12 deletions(-)
> >>
> >> Index: linux.git/drivers/video/fbmem.c
> >> =================================> >> --- linux.git.orig/drivers/video/fbmem.c
> >> +++ linux.git/drivers/video/fbmem.c
> >> @@ -252,7 +252,8 @@ static void fb_set_logo_truepalette(str
> >> blueshift = info->var.blue.offset - (8 - info->var.blue.length);
> >>
> >> for ( i = 0; i < logo->clutsize; i++) {
> >> - palette[i+32] = (safe_shift((clut[0] & redmask), redshift) |
> >> + palette[i+32] = fb_cmap_byteswap(info,
> >> + safe_shift((clut[0] & redmask), redshift) |
> >> safe_shift((clut[1] & greenmask), greenshift) |
> >> safe_shift((clut[2] & bluemask), blueshift));
> >> clut += 3;
> >> @@ -271,7 +272,8 @@ static void fb_set_logo_directpalette(st
> >> blueshift = info->var.blue.offset;
> >>
> >> for (i = 32; i < 32 + logo->clutsize; i++)
> >> - palette[i] = i << redshift | i << greenshift | i << blueshift;
> >> + palette[i] = fb_cmap_byteswap(info, i << redshift |
> >> + i << greenshift | i << blueshift);
> >> }
> >>
> >> static void fb_set_logo(struct fb_info *info,
> >> Index: linux.git/drivers/video/offb.c
> >> =================================> >> --- linux.git.orig/drivers/video/offb.c
> >> +++ linux.git/drivers/video/offb.c
> >> @@ -91,15 +91,6 @@ extern boot_infos_t *boot_infos;
> >> #define AVIVO_DC_LUTB_WHITE_OFFSET_GREEN 0x6cd4
> >> #define AVIVO_DC_LUTB_WHITE_OFFSET_RED 0x6cd8
> >>
> >> -#define FB_RIGHT_POS(p, bpp) (fb_be_math(p) ? 0 : (32 - (bpp)))
> >> -
> >> -static inline u32 offb_cmap_byteswap(struct fb_info *info, u32 value)
> >> -{
> >> - u32 bpp = info->var.bits_per_pixel;
> >> -
> >> - return cpu_to_be32(value) >> FB_RIGHT_POS(info, bpp);
> >> -}
> >> -
> >> /*
> >> * Set a single color register. The values supplied are already
> >> * rounded down to the hardware's capabilities (according to the
> >> @@ -129,7 +120,7 @@ static int offb_setcolreg(u_int regno, u
> >> mask <<= info->var.transp.offset;
> >> value |= mask;
> >> }
> >> - pal[regno] = offb_cmap_byteswap(info, value);
> >> + pal[regno] = fb_cmap_byteswap(info, value);
> >> return 0;
> >> }
> >>
> >> Index: linux.git/include/linux/fb.h
> >> =================================> >> --- linux.git.orig/include/linux/fb.h
> >> +++ linux.git/include/linux/fb.h
> >> @@ -582,6 +582,7 @@ static inline struct apertures_struct *a
> >>
> >> #endif
> >>
> >> +#define FB_RIGHT_POS(p, bpp) (fb_be_math(p) ? 0 : (32 - (bpp)))
> >> #define FB_LEFT_POS(p, bpp) (fb_be_math(p) ? (32 - (bpp)) : 0)
> >> #define FB_SHIFT_HIGH(p, val, bits) (fb_be_math(p) ? (val) >> (bits) : \
> >> (val) << (bits))
> >> @@ -681,6 +682,13 @@ static inline bool fb_be_math(struct fb_
> >> #endif /* CONFIG_FB_FOREIGN_ENDIAN */
> >> }
> >>
> >> +static inline u32 fb_cmap_byteswap(struct fb_info *info, u32 value)
> >> +{
> >> + u32 bpp = info->var.bits_per_pixel;
> >> +
> >> + return cpu_to_be32(value) >> FB_RIGHT_POS(info, bpp);
> >> +}
> >> +
> >> /* drivers/video/fbsysfs.c */
> >> extern struct fb_info *framebuffer_alloc(size_t size, struct device *dev);
> >> extern void framebuffer_release(struct fb_info *info);
> >>
> >
>
^ permalink raw reply
* [PATCH] video : remove redundant error check
From: Daeseok Youn @ 2014-05-15 7:55 UTC (permalink / raw)
To: plagnioj
Cc: tomi.valkeinen, jg1.han, daeseok.youn, daniel.vetter,
Julia.Lawall, linux-fbdev, linux-kernel
From 060757f81f85babf393cc76714d49af25af7791d Mon Sep 17 00:00:00 2001
From: Daeseok Youn <daeseok.youn@gmail.com>
Date: Thu, 15 May 2014 16:51:35 +0900
Subject: [PATCH] video : remove redundant error check
It doesn't need to check "err" for printing info.
And also use pr_info instead of printk.
Signed-off-by: Daeseok Youn <daeseok.youn@gmail.com>
---
drivers/video/fbdev/i810/i810_main.c | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/i810/i810_main.c b/drivers/video/fbdev/i810/i810_main.c
index bb674e4..15cb397 100644
--- a/drivers/video/fbdev/i810/i810_main.c
+++ b/drivers/video/fbdev/i810/i810_main.c
@@ -1910,13 +1910,12 @@ static void i810fb_find_init_mode(struct fb_info *info)
for (i = 0; i < par->ddc_num + 1; i++) {
err = i810_probe_i2c_connector(info, &par->edid, i);
- if (!err)
+ if (!err) {
+ pr_info("i810fb_init_pci: DDC probe successful\n");
break;
+ }
}
- if (!err)
- printk("i810fb_init_pci: DDC probe successful\n");
-
fb_edid_to_monspecs(par->edid, specs);
if (specs->modedb = NULL)
--
1.7.1
^ permalink raw reply related
* [PATCH] OMAPDSS: move 'compatible' converter to omapdss driver
From: Tomi Valkeinen @ 2014-05-15 8:05 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, linux-fbdev, Archit Taneja, Tomi Valkeinen
Move the panel/encoder driver compatible-string converter from
arch/arm/mach-omap2/display.c to omapdss driver. That is a more logical
place for it, as it's really an omapdss internal hack.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/display.c | 56 -----------
drivers/video/fbdev/omap2/Makefile | 2 +-
drivers/video/fbdev/omap2/dss/Kconfig | 4 +
drivers/video/fbdev/omap2/dss/Makefile | 1 +
drivers/video/fbdev/omap2/dss/omapdss-boot-init.c | 112 ++++++++++++++++++++++
5 files changed, 118 insertions(+), 57 deletions(-)
create mode 100644 drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 16d33d831287..519a20fc0432 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -555,65 +555,9 @@ int omap_dss_reset(struct omap_hwmod *oh)
return r;
}
-/* list of 'compatible' nodes to convert to omapdss specific */
-static const char * const dss_compat_conv_list[] __initconst = {
- "composite-connector",
- "dvi-connector",
- "hdmi-connector",
- "panel-dpi",
- "panel-dsi-cm",
- "sony,acx565akm",
- "svideo-connector",
- "ti,tfp410",
- "ti,tpd12s015",
-};
-
-/* prepend compatible string with "omapdss," */
-static __init void omapdss_omapify_node(struct device_node *node,
- const char *compat)
-{
- char *new_compat;
- struct property *prop;
-
- new_compat = kasprintf(GFP_KERNEL, "omapdss,%s", compat);
-
- prop = kzalloc(sizeof(*prop), GFP_KERNEL);
-
- if (!prop) {
- pr_err("omapdss_omapify_node: kzalloc failed\n");
- return;
- }
-
- prop->name = "compatible";
- prop->value = new_compat;
- prop->length = strlen(new_compat) + 1;
-
- of_update_property(node, prop);
-}
-
-/*
- * As omapdss panel drivers are omapdss specific, but we want to define the
- * DT-data in generic manner, we convert the compatible strings of the panel
- * nodes from "panel-foo" to "omapdss,panel-foo". This way we can have both
- * correct DT data and omapdss specific drivers.
- *
- * When we get generic panel drivers to the kernel, this will be removed.
- */
void __init omapdss_early_init_of(void)
{
- int i;
-
- for (i = 0; i < ARRAY_SIZE(dss_compat_conv_list); ++i) {
- const char *compat = dss_compat_conv_list[i];
- struct device_node *node = NULL;
-
- while ((node = of_find_compatible_node(node, NULL, compat))) {
- if (!of_device_is_available(node))
- continue;
- omapdss_omapify_node(node, compat);
- }
- }
}
struct device_node * __init omapdss_find_dss_of_node(void)
diff --git a/drivers/video/fbdev/omap2/Makefile b/drivers/video/fbdev/omap2/Makefile
index bf8127df8c71..f8745ec369cc 100644
--- a/drivers/video/fbdev/omap2/Makefile
+++ b/drivers/video/fbdev/omap2/Makefile
@@ -1,5 +1,5 @@
obj-$(CONFIG_OMAP2_VRFB) += vrfb.o
-obj-$(CONFIG_OMAP2_DSS) += dss/
+obj-y += dss/
obj-y += displays-new/
obj-$(CONFIG_FB_OMAP2) += omapfb/
diff --git a/drivers/video/fbdev/omap2/dss/Kconfig b/drivers/video/fbdev/omap2/dss/Kconfig
index dde4281663b1..a28f3a39ab1b 100644
--- a/drivers/video/fbdev/omap2/dss/Kconfig
+++ b/drivers/video/fbdev/omap2/dss/Kconfig
@@ -1,6 +1,10 @@
+config OMAP2_DSS_INIT
+ bool
+
menuconfig OMAP2_DSS
tristate "OMAP2+ Display Subsystem support"
select VIDEOMODE_HELPERS
+ select OMAP2_DSS_INIT
help
OMAP2+ Display Subsystem support.
diff --git a/drivers/video/fbdev/omap2/dss/Makefile b/drivers/video/fbdev/omap2/dss/Makefile
index 8aec8bda27cc..3b79ad74f2e1 100644
--- a/drivers/video/fbdev/omap2/dss/Makefile
+++ b/drivers/video/fbdev/omap2/dss/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_OMAP2_DSS_INIT) += omapdss-boot-init.o
obj-$(CONFIG_OMAP2_DSS) += omapdss.o
# Core DSS files
omapdss-y := core.o dss.o dss_features.o dispc.o dispc_coefs.o display.o \
diff --git a/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c b/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
new file mode 100644
index 000000000000..468f6eff370c
--- /dev/null
+++ b/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright (C) 2014 Texas Instruments
+ * Author: Tomi Valkeinen <tomi.valkeinen@nokia.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/kernel.h>
+#include <linux/of.h>
+#include <linux/slab.h>
+
+/* list of 'compatible' nodes to convert to omapdss specific */
+static const char * const dss_compat_conv_list[] __initconst = {
+ "composite-connector",
+ "dvi-connector",
+ "hdmi-connector",
+ "panel-dpi",
+ "panel-dsi-cm",
+ "sony,acx565akm",
+ "svideo-connector",
+ "ti,tfp410",
+ "ti,tpd12s015",
+};
+
+/* prepend compatible string with "omapdss," */
+static __init void omapdss_omapify_node(struct device_node *node,
+ const char *compat)
+{
+ char *new_compat;
+ struct property *prop;
+
+ new_compat = kasprintf(GFP_KERNEL, "omapdss,%s", compat);
+
+ prop = kzalloc(sizeof(*prop), GFP_KERNEL);
+
+ if (!prop) {
+ pr_err("omapdss_omapify_node: kzalloc failed\n");
+ return;
+ }
+
+ prop->name = "compatible";
+ prop->value = new_compat;
+ prop->length = strlen(new_compat) + 1;
+
+ of_update_property(node, prop);
+}
+
+static struct device_node * __init omapdss_find_dss_of_node(void)
+{
+ struct device_node *node;
+
+ node = of_find_compatible_node(NULL, NULL, "ti,omap2-dss");
+ if (node)
+ return node;
+
+ node = of_find_compatible_node(NULL, NULL, "ti,omap3-dss");
+ if (node)
+ return node;
+
+ node = of_find_compatible_node(NULL, NULL, "ti,omap4-dss");
+ if (node)
+ return node;
+
+ node = of_find_compatible_node(NULL, NULL, "ti,omap5-dss");
+ if (node)
+ return node;
+
+ return NULL;
+}
+
+/*
+ * As omapdss panel drivers are omapdss specific, but we want to define the
+ * DT-data in generic manner, we convert the compatible strings of the panel
+ * nodes from "panel-foo" to "omapdss,panel-foo". This way we can have both
+ * correct DT data and omapdss specific drivers.
+ *
+ * When we get generic panel drivers to the kernel, this will be removed.
+ */
+static int __init omap_dss_boot_init(void)
+{
+ int i;
+
+ /* do we have omapdss device? */
+ if (omapdss_find_dss_of_node() = NULL)
+ return 0;
+
+ for (i = 0; i < ARRAY_SIZE(dss_compat_conv_list); ++i) {
+ const char *compat = dss_compat_conv_list[i];
+ struct device_node *node = NULL;
+
+ while ((node = of_find_compatible_node(node, NULL, compat))) {
+ if (!of_device_is_available(node))
+ continue;
+
+ omapdss_omapify_node(node, compat);
+ }
+ }
+
+ return 0;
+}
+
+subsys_initcall(omap_dss_boot_init);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tomi Valkeinen @ 2014-05-15 8:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140513212639.GA18001@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 957 bytes --]
On 14/05/14 00:26, Tony Lindgren wrote:
> + /* lcd MO */
> + ddata->mo_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 1, "mode");
> + if (PTR_ERR(ddata->mo_gpio) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> +
> + if (!IS_ERR(ddata->mo_gpio))
> + if (gpiod_get_raw_value_cansleep(ddata->mo_gpio))
> + ddata->flags |= SHARP_LS_QVGA;
Shouldn't there be an explicit flag in the DT data for this? If the
panel's MO pin is hardwired to, say, pull up, then the mode-gpios won't
have MO gpio, right? So something like:
mode-gpios = <0 /* high, lcd MO */
&gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */
&gpio1 3 GPIO_ACTIVE_HIGH>; /* gpio3, lcd UD */
vga-mode; /* MO hardwired high */
Btw, the gpio.txt has each gpio inside <>:
chipsel-gpios = <&gpio1 12 0>,
<&gpio1 13 0>,
<0>, /* holes are permitted, means no GPIO 2 */
<&gpio2 2>;
Is that equivalent to having all gpios inside <>?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 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