* [patch] xenfb: fix xenfb suspend/resume race.
From: Joe Jin @ 2011-01-07 10:17 UTC (permalink / raw)
To: jeremy, ian.campbell, Andrew Morton
Cc: linux-fbdev, xen-devel, gurudas.pai, guru.anbalagane,
greg.marsden, joe.jin, linux-kernel, Konrad Rzeszutek Wilk
In-Reply-To: <4D26B577.5060105@oracle.com>
Hi,
when do migration test, we hit the panic as below:
<1>BUG: unable to handle kernel paging request at 0000000b819fdb98
<1>IP: [<ffffffff812a588f>] notify_remote_via_irq+0x13/0x34
<4>PGD 94b10067 PUD 0
<0>Oops: 0000 [#1] SMP
<0>last sysfs file: /sys/class/misc/autofs/dev
<4>CPU 3
<4>Modules linked in: autofs4(U) hidp(U) nfs(U) fscache(U) nfs_acl(U)
auth_rpcgss(U) rfcomm(U) l2cap(U) bluetooth(U) rfkill(U) lockd(U) sunrpc(U)
nf_conntrack_netbios_ns(U) ipt_REJECT(U) nf_conntrack_ipv4(U)
nf_defrag_ipv4(U) xt_state(U) nf_conntrack(U) iptable_filter(U) ip_tables(U)
ip6t_REJECT(U) xt_tcpudp(U) ip6table_filter(U) ip6_tables(U) x_tables(U)
ipv6(U) parport_pc(U) lp(U) parport(U) snd_seq_dummy(U) snd_seq_oss(U)
snd_seq_midi_event(U) snd_seq(U) snd_seq_device(U) snd_pcm_oss(U)
snd_mixer_oss(U) snd_pcm(U) snd_timer(U) snd(U) soundcore(U)
snd_page_alloc(U) joydev(U) xen_netfront(U) pcspkr(U) xen_blkfront(U)
uhci_hcd(U) ohci_hcd(U) ehci_hcd(U)
Pid: 18, comm: events/3 Not tainted 2.6.32
RIP: e030:[<ffffffff812a588f>] [<ffffffff812a588f>]
ify_remote_via_irq+0x13/0x34
RSP: e02b:ffff8800e7bf7bd0 EFLAGS: 00010202
RAX: ffff8800e61c8000 RBX: ffff8800e62f82c0 RCX: 0000000000000000
RDX: 00000000000001e3 RSI: ffff8800e7bf7c68 RDI: 0000000bfffffff4
RBP: ffff8800e7bf7be0 R08: 00000000000001e2 R09: ffff8800e62f82c0
R10: 0000000000000001 R11: ffff8800e6386110 R12: 0000000000000000
R13: 0000000000000007 R14: ffff8800e62f82e0 R15: 0000000000000240
FS: 00007f409d3906e0(0000) GS:ffff8800028b8000(0000)
GS:0000000000000000
CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000b819fdb98 CR3: 000000003ee3b000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process events/3 (pid: 18, threadinfo ffff8800e7bf6000, task
f8800e7bf4540)
Stack:
0000000000000200 ffff8800e61c8000 ffff8800e7bf7c00 ffffffff812712c9
<0> ffffffff8100ea5f ffffffff81438d80 ffff8800e7bf7cd0 ffffffff812714ee
<0> 0000000000000000 ffffffff81270568 000000000000e030 0000000000010202
Call Trace:
[<ffffffff812712c9>] xenfb_send_event+0x5c/0x5e
[<ffffffff8100ea5f>] ? xen_restore_fl_direct_end+0x0/0x1
[<ffffffff81438d80>] ? _spin_unlock_irqrestore+0x16/0x18
[<ffffffff812714ee>] xenfb_refresh+0x1b1/0x1d7
[<ffffffff81270568>] ? sys_imageblit+0x1ac/0x458
[<ffffffff81271786>] xenfb_imageblit+0x2f/0x34
[<ffffffff8126a3e5>] soft_cursor+0x1b5/0x1c8
[<ffffffff8126a137>] bit_cursor+0x4b6/0x4d7
[<ffffffff8100ea5f>] ? xen_restore_fl_direct_end+0x0/0x1
[<ffffffff81438d80>] ? _spin_unlock_irqrestore+0x16/0x18
[<ffffffff81269c81>] ? bit_cursor+0x0/0x4d7
[<ffffffff812656b7>] fb_flashcursor+0xff/0x111
[<ffffffff812655b8>] ? fb_flashcursor+0x0/0x111
[<ffffffff81071812>] worker_thread+0x14d/0x1ed
[<ffffffff81075a8c>] ? autoremove_wake_function+0x0/0x3d
[<ffffffff81438d80>] ? _spin_unlock_irqrestore+0x16/0x18
[<ffffffff810716c5>] ? worker_thread+0x0/0x1ed
[<ffffffff810756e3>] kthread+0x6e/0x76
[<ffffffff81012dea>] child_rip+0xa/0x20
[<ffffffff81011fd1>] ? int_ret_from_sys_call+0x7/0x1b
[<ffffffff8101275d>] ? retint_restore_args+0x5/0x6
[<ffffffff81012de0>] ? child_rip+0x0/0x20
Code: 6b ff 0c 8b 87 a4 db 9f 81 66 85 c0 74 08 0f b7 f8 e8 3b ff ff ff c9
c3 55 48 89 e5 48 83 ec 10 0f 1f 44 00 00 89 ff 48 6b ff 0c <8b> 87 a4 db 9f
81 66 85 c0 74 14 48 8d 75 f0 0f b7 c0 bf 04 00
RIP [<ffffffff812a588f>] notify_remote_via_irq+0x13/0x34
RSP <ffff8800e7bf7bd0>
CR2: 0000000b819fdb98
---[ end trace 098b4b74827595d0 ]---
The root cause of race between the resume and reconnecting to the backend
Clear update_wanted flag of xenfb before disconnect backend would fix this issue.
Also below patch will fixed mem leak when connect to xenfb backend failed.
Signed-off-by: Joe Jin <joe.jin@oracle.com>
Tested-by: Gurudas Pai <gurudas.pai@oracle.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
xen-fbfront.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
index dc72563..f2d9eb5 100644
--- a/drivers/video/xen-fbfront.c
+++ b/drivers/video/xen-fbfront.c
@@ -616,6 +616,8 @@ static int xenfb_connect_backend(struct xenbus_device *dev,
static void xenfb_disconnect_backend(struct xenfb_info *info)
{
+ /* Prevent xenfb refresh */
+ info->update_wanted = 0;
if (info->irq >= 0)
unbind_from_irqhandler(info->irq, info);
info->irq = -1;
^ permalink raw reply related
* [patch] xenfb: fix potential memory leak
From: Joe Jin @ 2011-01-07 10:20 UTC (permalink / raw)
To: jeremy, ian.campbell, Andrew Morton
Cc: linux-fbdev, xen-devel, gurudas.pai, guru.anbalagane,
greg.marsden, joe.jin, linux-kernel, Konrad Rzeszutek Wilk
Hi,
This patch fix potential memory leak when xenfb connect backend failed.
Thanks for Ian's review and comments.
Signed-off-by: Joe Jin <joe.jin@oracle.com>
Tested-by: Gurudas Pai <gurudas.pai@oracle.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
xen-fbfront.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
index dc72563..953334a 100644
--- a/drivers/video/xen-fbfront.c
+++ b/drivers/video/xen-fbfront.c
@@ -561,26 +561,24 @@ static void xenfb_init_shared_page(struct xenfb_info *info,
static int xenfb_connect_backend(struct xenbus_device *dev,
struct xenfb_info *info)
{
- int ret, evtchn;
+ int ret, evtchn, irq;
struct xenbus_transaction xbt;
ret = xenbus_alloc_evtchn(dev, &evtchn);
if (ret)
return ret;
- ret = bind_evtchn_to_irqhandler(evtchn, xenfb_event_handler,
+ irq = bind_evtchn_to_irqhandler(evtchn, xenfb_event_handler,
0, dev->devicetype, info);
- if (ret < 0) {
+ if (irq < 0) {
xenbus_free_evtchn(dev, evtchn);
xenbus_dev_fatal(dev, ret, "bind_evtchn_to_irqhandler");
- return ret;
+ return irq;
}
- info->irq = ret;
-
again:
ret = xenbus_transaction_start(&xbt);
if (ret) {
xenbus_dev_fatal(dev, ret, "starting transaction");
- return ret;
+ goto unbind_irq;
}
ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
virt_to_mfn(info->page));
@@ -602,15 +600,18 @@ static int xenfb_connect_backend(struct xenbus_device *dev,
if (ret = -EAGAIN)
goto again;
xenbus_dev_fatal(dev, ret, "completing transaction");
- return ret;
+ goto unbind_irq;
}
xenbus_switch_state(dev, XenbusStateInitialised);
+ info->irq = irq;
return 0;
error_xenbus:
xenbus_transaction_end(xbt, 1);
xenbus_dev_fatal(dev, ret, "writing xenstore");
+ unbind_irq:
+ unbind_from_irqhandler(irq, info);
return ret;
}
^ permalink raw reply related
* [PATCH 0/3 v2] fbdev: sh-mobile HDMI
From: Guennadi Liakhovetski @ 2011-01-07 11:57 UTC (permalink / raw)
To: linux-fbdev
3 not really logically connected HDMI patches for 2.6.38. Now based on top
of the fbdev-2.6/master branch. They only work with patch
https://patchwork.kernel.org/patch/338671/ reverted.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* [PATCH 1/3 v2] fbdev: sh_mobile_hdmi: add command line option to
From: Guennadi Liakhovetski @ 2011-01-07 11:57 UTC (permalink / raw)
To: linux-fbdev
Currently, if no command-line option is specified, the sh_mobile_hdmi
will use the default 720p video mode. If a command line option of the
form "video=sh_mobile_lcdc:<width>x<height>@<refresh>" is provided,
the driver will look for that mode among those, available in the
monitor EDID. This patch adds the ability to request the driver to
use monitor's preferred mode by specifying 0 as width and hight in
the above string. If that mode is not supported by the system, the
driver will continue scanning through EDID modes, until it finds a
suitable one.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
v2:
1. ported onto current fbdev development tree
2. fixed regression, caused by https://patchwork.kernel.org/patch/453141/
which made the use of all EDID modes impossible, because they don't set
.bits_per_pixel
drivers/video/sh_mobile_hdmi.c | 60 +++++++++++++++++++++++++++------------
1 files changed, 41 insertions(+), 19 deletions(-)
diff --git a/drivers/video/sh_mobile_hdmi.c b/drivers/video/sh_mobile_hdmi.c
index 8c59cc8..571bd9f 100644
--- a/drivers/video/sh_mobile_hdmi.c
+++ b/drivers/video/sh_mobile_hdmi.c
@@ -737,7 +737,7 @@ static int sh_hdmi_read_edid(struct sh_hdmi *hdmi, unsigned long *hdmi_rate,
struct fb_modelist *modelist = NULL;
unsigned int f_width = 0, f_height = 0, f_refresh = 0;
unsigned long found_rate_error = ULONG_MAX; /* silly compiler... */
- bool exact_match = false;
+ bool scanning = false, preferred_bad = false;
u8 edid[128];
char *forced;
int i;
@@ -800,6 +800,9 @@ static int sh_hdmi_read_edid(struct sh_hdmi *hdmi, unsigned long *hdmi_rate,
if (i < 2) {
f_width = 0;
f_height = 0;
+ } else {
+ /* The user wants us to use the EDID data */
+ scanning = true;
}
dev_dbg(hdmi->dev, "Forced mode %ux%u@%uHz\n",
f_width, f_height, f_refresh);
@@ -807,37 +810,56 @@ static int sh_hdmi_read_edid(struct sh_hdmi *hdmi, unsigned long *hdmi_rate,
/* Walk monitor modes to find the best or the exact match */
for (i = 0, mode = hdmi->monspec.modedb;
- f_width && f_height && i < hdmi->monspec.modedb_len && !exact_match;
+ i < hdmi->monspec.modedb_len && scanning;
i++, mode++) {
unsigned long rate_error;
- /* No interest in unmatching modes */
- if (f_width != mode->xres || f_height != mode->yres)
+ if (!f_width && !f_height) {
+ /*
+ * A parameter string "video=sh_mobile_lcdc:0x0" means
+ * use the preferred EDID mode. If it is rejected by
+ * .fb_check_var(), keep looking, until an acceptable
+ * one is found.
+ */
+ if ((mode->flag & FB_MODE_IS_FIRST) || preferred_bad)
+ scanning = false;
+ else
+ continue;
+ } else if (f_width != mode->xres || f_height != mode->yres) {
+ /* No interest in unmatching modes */
continue;
+ }
rate_error = sh_hdmi_rate_error(hdmi, mode, hdmi_rate, parent_rate);
- if (f_refresh = mode->refresh || (!f_refresh && !rate_error))
- /*
- * Exact match if either the refresh rate matches or it
- * hasn't been specified and we've found a mode, for
- * which we can configure the clock precisely
- */
- exact_match = true;
- else if (found && found_rate_error <= rate_error)
- /*
- * We otherwise search for the closest matching clock
- * rate - either if no refresh rate has been specified
- * or we cannot find an exactly matching one
- */
- continue;
+ if (scanning) {
+ if (f_refresh = mode->refresh || (!f_refresh && !rate_error))
+ /*
+ * Exact match if either the refresh rate
+ * matches or it hasn't been specified and we've
+ * found a mode, for which we can configure the
+ * clock precisely
+ */
+ scanning = false;
+ else if (found && found_rate_error <= rate_error)
+ /*
+ * We otherwise search for the closest matching
+ * clock rate - either if no refresh rate has
+ * been specified or we cannot find an exactly
+ * matching one
+ */
+ continue;
+ }
/* Check if supported: sufficient fb memory, supported clock-rate */
fb_videomode_to_var(var, mode);
+ var->bits_per_pixel = info->var.bits_per_pixel;
+
if (info && info->fbops->fb_check_var &&
info->fbops->fb_check_var(var, info)) {
- exact_match = false;
+ scanning = true;
+ preferred_bad = true;
continue;
}
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/3 v2] fbdev: sh_mobile_hdmi: framebuffer notifiers have to
From: Guennadi Liakhovetski @ 2011-01-07 11:57 UTC (permalink / raw)
To: linux-fbdev
A previous patch added a framebuffer notifier to sh_mobile_hdmi.c,
but did not register it with the framebuffer core. This patch adds
such a registration and moves the notifier block into dynamically
allocated per-device private data.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
drivers/video/sh_mobile_hdmi.c | 19 +++++++++----------
1 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/video/sh_mobile_hdmi.c b/drivers/video/sh_mobile_hdmi.c
index 571bd9f..46ab355 100644
--- a/drivers/video/sh_mobile_hdmi.c
+++ b/drivers/video/sh_mobile_hdmi.c
@@ -221,6 +221,7 @@ struct sh_hdmi {
struct delayed_work edid_work;
struct fb_var_screeninfo var;
struct fb_monspecs monspec;
+ struct notifier_block notifier;
};
static void hdmi_write(struct sh_hdmi *hdmi, u8 data, u8 reg)
@@ -1197,13 +1198,6 @@ out:
}
static int sh_hdmi_notify(struct notifier_block *nb,
- unsigned long action, void *data);
-
-static struct notifier_block sh_hdmi_notifier = {
- .notifier_call = sh_hdmi_notify,
-};
-
-static int sh_hdmi_notify(struct notifier_block *nb,
unsigned long action, void *data)
{
struct fb_event *event = data;
@@ -1212,7 +1206,7 @@ static int sh_hdmi_notify(struct notifier_block *nb,
struct sh_mobile_lcdc_board_cfg *board_cfg = &ch->cfg.board_cfg;
struct sh_hdmi *hdmi = board_cfg->board_data;
- if (nb != &sh_hdmi_notifier || !hdmi || hdmi->info != info)
+ if (!hdmi || nb != &hdmi->notifier || hdmi->info != info)
return NOTIFY_DONE;
switch(action) {
@@ -1231,11 +1225,11 @@ static int sh_hdmi_notify(struct notifier_block *nb,
* temporarily, synchronise with the work queue and re-acquire
* the info->lock.
*/
- unlock_fb_info(hdmi->info);
+ unlock_fb_info(info);
mutex_lock(&hdmi->mutex);
hdmi->info = NULL;
mutex_unlock(&hdmi->mutex);
- lock_fb_info(hdmi->info);
+ lock_fb_info(info);
return NOTIFY_OK;
}
return NOTIFY_DONE;
@@ -1333,6 +1327,9 @@ static int __init sh_hdmi_probe(struct platform_device *pdev)
goto ecodec;
}
+ hdmi->notifier.notifier_call = sh_hdmi_notify;
+ fb_register_client(&hdmi->notifier);
+
return 0;
ecodec:
@@ -1363,6 +1360,8 @@ static int __exit sh_hdmi_remove(struct platform_device *pdev)
snd_soc_unregister_codec(&pdev->dev);
+ fb_unregister_client(&hdmi->notifier);
+
board_cfg->display_on = NULL;
board_cfg->display_off = NULL;
board_cfg->board_data = NULL;
--
1.7.2.3
^ permalink raw reply related
* [PATCH 3/3 v2] fbdev: sh_mobile_hdmi: simplify pointer handling
From: Guennadi Liakhovetski @ 2011-01-07 11:58 UTC (permalink / raw)
To: linux-fbdev
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
drivers/video/sh_mobile_hdmi.c | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/video/sh_mobile_hdmi.c b/drivers/video/sh_mobile_hdmi.c
index 46ab355..e3eb77d 100644
--- a/drivers/video/sh_mobile_hdmi.c
+++ b/drivers/video/sh_mobile_hdmi.c
@@ -878,9 +878,9 @@ static int sh_hdmi_read_edid(struct sh_hdmi *hdmi, unsigned long *hdmi_rate,
* driver, and passing ->info with HDMI platform data.
*/
if (info && !found) {
- modelist = hdmi->info->modelist.next &&
- !list_empty(&hdmi->info->modelist) ?
- list_entry(hdmi->info->modelist.next,
+ modelist = info->modelist.next &&
+ !list_empty(&info->modelist) ?
+ list_entry(info->modelist.next,
struct fb_modelist, list) :
NULL;
@@ -1123,6 +1123,7 @@ static void sh_hdmi_edid_work_fn(struct work_struct *work)
mutex_lock(&hdmi->mutex);
if (hdmi->hp_state = HDMI_HOTPLUG_CONNECTED) {
+ struct fb_info *info = hdmi->info;
unsigned long parent_rate = 0, hdmi_rate;
/* A device has been plugged in */
@@ -1144,22 +1145,21 @@ static void sh_hdmi_edid_work_fn(struct work_struct *work)
/* Switched to another (d) power-save mode */
msleep(10);
- if (!hdmi->info)
+ if (!info)
goto out;
- ch = hdmi->info->par;
+ ch = info->par;
acquire_console_sem();
/* HDMI plug in */
if (!sh_hdmi_must_reconfigure(hdmi) &&
- hdmi->info->state = FBINFO_STATE_RUNNING) {
+ info->state = FBINFO_STATE_RUNNING) {
/*
* First activation with the default monitor - just turn
* on, if we run a resume here, the logo disappears
*/
- if (lock_fb_info(hdmi->info)) {
- struct fb_info *info = hdmi->info;
+ if (lock_fb_info(info)) {
info->var.width = hdmi->var.width;
info->var.height = hdmi->var.height;
sh_hdmi_display_on(hdmi, info);
@@ -1167,7 +1167,7 @@ static void sh_hdmi_edid_work_fn(struct work_struct *work)
}
} else {
/* New monitor or have to wake up */
- fb_set_suspend(hdmi->info, 0);
+ fb_set_suspend(info, 0);
}
release_console_sem();
--
1.7.2.3
^ permalink raw reply related
* Accessing FB struct
From: vijay singh @ 2011-01-07 12:16 UTC (permalink / raw)
To: linux-fbdev
Hello,
Is their any api available under Xlib which can give me information of
frame buffer struct (mentioned below).
struct fb_buffer_info {
u8 bpp ;
u8 num_buffers ;
enum color_mode mode ;
u32 height ;
u32 width ;
u32 stride ;
struct
fbbuffer_addr buffer_address[NUM_FB_BUFFERS];
};
or what is way to get data available under above struct.
Cheers--
Vij
^ permalink raw reply
* [GIT PULL] OMAP DSS changes for .38 merge window
From: Tomi Valkeinen @ 2011-01-07 12:41 UTC (permalink / raw)
To: ext Paul Mundt
Cc: linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org,
ext Tony Lindgren
Hello Paul,
Here are some OMAP display changes for .38. I hope they are not too
late, but the holidays messed up my schedules a bit.
I made two branches, as I'm not sure which is better:
for-paul-38 - This one is the original non-rebased branch. This causes a
trivial conflict with fbdev/master in drivers/video/omap2/vram.c (SZ_2M
is the right one), and also it contains a patch (memblock: fix
memblock_is_region_memory()) which is not yet in mainline, but is in
Andrew Morton's tree.
for-paul-38-rebased - The above branch rebased on top of v2.6.37, and
the memblock commit removed.
Which one you prefer? Or is there some other way I should handle this?
I could merge v2.6.37 to my branch, which would remove the conflict, but
that would still leave the memblock patch. I guess the patch is going in
soon, but as it's not in my area, I don't feel it's right to get it in
via my patch set. Alternatively I could wait until the patch is in
Linus' tree, but that could make it tight to be in time for the merge
window.
Tomi
The following changes since commit c8ddb2713c624f432fa5fe3c7ecffcdda46ea0d4:
Linux 2.6.37-rc1 (2010-11-01 07:54:12 -0400)
are available in the git repository at:
git://gitorious.org/linux-omap-dss2/linux.git for-paul-38
Archit Taneja (5):
OMAP: DSS2: Fix: Read correct bit in dispc_enable_alpha_blending()
OMAP: DSS2: Clean up DISPC color mode validation checks
OMAP: DSS2: Add dss_features for omap4 and overlay manager related features
OMAP: DSS2: Use dss_features to handle DISPC bits removed on OMAP4
OMAP: DSS2: Fix build breaks for rfbi.c and dsi.c
Bryan Wu (4):
OMAP: DSS2: Add generic DPI panel display driver
OMAP: use generic DPI panel driver in board files
OMAP: DSS2: remove generic DPI panel driver duplicated panel drivers
OMAP: DSS2: Add back authors of panel-generic.c based drivers
Erik Gilling (1):
OMAP: DSS2: Add NEC NL8048HL11-01B display panel
Kishore Y (2):
OMAP3: ZOOM2/3/3630SDP: Add display board file for OMAP3
OMAP3: Enable display on ZOOM2/3/3630SDP
Rajkumar N (1):
OMAP3630: DSS2: Enable Pre-Multiplied Alpha Support
Samreen (2):
OMAP3: DSS2: Split OMAP3 has feature for 3430 & 3630
OMAP: DSS2: OMAPFB: Add null pointer check
Sumit Semwal (5):
OMAP: DSS2: Represent DISPC register defines with channel as parameter
OMAP: DSS2: Introduce omap_channel argument to DISPC functions used by interface drivers
OMAP: DSS2: Change remaining DISPC functions for new omap_channel argument
OMAP: DSS2: LCD2 Channel Changes for DISPC
OMAP: DSS2: Introduce omap_channel as an omap_dss_device parameter, add new overlay manager.
Tomi Valkeinen (4):
memblock: fix memblock_is_region_memory()
OMAP: VRAM: improve VRAM error prints
OMAP: VRAM: Fix boot-time memory allocation
OMAP: DSS: Fix documentation regarding 'vram' kernel parameter
Documentation/arm/OMAP/DSS | 7 +-
arch/arm/mach-omap2/Makefile | 3 +
arch/arm/mach-omap2/board-3430sdp.c | 12 +-
arch/arm/mach-omap2/board-3630sdp.c | 1 +
arch/arm/mach-omap2/board-am3517evm.c | 23 +-
arch/arm/mach-omap2/board-cm-t35.c | 23 +-
arch/arm/mach-omap2/board-devkit8000.c | 26 +-
arch/arm/mach-omap2/board-igep0020.c | 12 +-
arch/arm/mach-omap2/board-omap3beagle.c | 12 +-
arch/arm/mach-omap2/board-omap3evm.c | 12 +-
arch/arm/mach-omap2/board-omap3stalker.c | 23 +-
arch/arm/mach-omap2/board-zoom-display.c | 168 +++++
arch/arm/mach-omap2/board-zoom-peripherals.c | 49 ++-
arch/arm/mach-omap2/board-zoom2.c | 1 +
arch/arm/mach-omap2/board-zoom3.c | 1 +
arch/arm/mach-omap2/include/mach/board-zoom.h | 3 +
arch/arm/plat-omap/include/plat/display.h | 9 +
.../arm/plat-omap/include/plat/panel-generic-dpi.h | 37 ++
drivers/video/omap2/displays/Kconfig | 27 +-
drivers/video/omap2/displays/Makefile | 5 +-
drivers/video/omap2/displays/panel-generic-dpi.c | 365 +++++++++++
drivers/video/omap2/displays/panel-generic.c | 174 ------
.../omap2/displays/panel-nec-nl8048hl11-01b.c | 325 ++++++++++
.../video/omap2/displays/panel-sharp-lq043t1dg01.c | 165 -----
.../video/omap2/displays/panel-toppoly-tdo35s.c | 164 -----
drivers/video/omap2/dss/dispc.c | 636 +++++++++++++-------
drivers/video/omap2/dss/dpi.c | 40 +-
drivers/video/omap2/dss/dsi.c | 27 +-
drivers/video/omap2/dss/dss.h | 35 +-
drivers/video/omap2/dss/dss_features.c | 66 ++-
drivers/video/omap2/dss/dss_features.h | 10 +-
drivers/video/omap2/dss/manager.c | 80 ++-
drivers/video/omap2/dss/overlay.c | 55 ++-
drivers/video/omap2/dss/rfbi.c | 20 +-
drivers/video/omap2/dss/sdi.c | 24 +-
drivers/video/omap2/omapfb/omapfb-main.c | 5 +-
drivers/video/omap2/vram.c | 17 +-
mm/memblock.c | 8 +-
38 files changed, 1776 insertions(+), 894 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-zoom-display.c
create mode 100644 arch/arm/plat-omap/include/plat/panel-generic-dpi.h
create mode 100644 drivers/video/omap2/displays/panel-generic-dpi.c
delete mode 100644 drivers/video/omap2/displays/panel-generic.c
create mode 100644 drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
delete mode 100644 drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
delete mode 100644 drivers/video/omap2/displays/panel-toppoly-tdo35s.c
^ permalink raw reply
* Recursive lock in fbcon after unblank and modelist change
From: James Hogan @ 2011-01-07 12:55 UTC (permalink / raw)
To: linux-fbdev
Hi,
I'm hitting the following recursive locking problem when unblanking
the framebuffer (echoing 3 then 0 to /sys/class/graphics/fb0/blank).
Basically this is what's happening:
* the fb_blank function sends the blank notification
* fbcon gets the blank notification, and calls fbcon_switch
* fbcon_switch calls fb_set_var
* fb_set_var actually makes a change, which triggers another
notification (mode change), which tries to lock fb_notifier_list.rwsem
again, which triggers the lockdep warning (and presumably potentially
a deadlock).
The reason fb_set_var makes a change is because the mode list has been
updated since the last mode change, so the current mode is effectively
out of date. E.g. this could be done by writing to
/sys/class/graphics/fb0/modes, or in my case an HDMI driver updates
the modelist on a monitor hotplug event after reading the EDID in the
same way as the sysfs interface.
So, a few questions:
(1) Is this situation a valid situation, where the modelist has been
overwritten but current mode left unchanged?
(2) If (1), any ideas how the recursive locking situation should be resolved?
(3) If not (1), should updating the modelist using sysfs (and
similarly on a monitor hotplug event), also update the current mode to
the nearest mode in the list (fb_new_modelist would seem an
appropriate place)?
Thanks
James
======================[ INFO: possible recursive locking detected ]
2.6.37-rc7+ #1435
---------------------------------------------
sh/382 is trying to acquire lock:
((fb_notifier_list).rwsem){.+.+.+}, at: [<40040a60>]
___blocking_notifier_call_chain+0x34/0x80
but task is already holding lock:
((fb_notifier_list).rwsem){.+.+.+}, at: [<40040a60>]
___blocking_notifier_call_chain+0x34/0x80
other info that might help us debug this:
3 locks held by sh/382:
#0: (&buffer->mutex){+.+.+.}, at: [<400e8ab0>] _sysfs_write_file+0x38/0x1a4
#1: (s_active#13){.+.+.+}, at: [<400e8ba0>] _sysfs_write_file+0x128/0x1a4
#2: ((fb_notifier_list).rwsem){.+.+.+}, at: [<40040a60>]
___blocking_notifier_call_chain+0x34/0x80
stack backtrace:
Call trace:
[<40003b1c>] _show_stack+0x68/0x7c
[<40003b44>] _dump_stack+0x14/0x28
[<4004f360>] _validate_chain+0x1170/0x137c
[<4004f9dc>] ___lock_acquire+0x470/0xc44
[<4005020c>] _lock_acquire+0x5c/0x84
[<40238204>] _down_read+0x48/0x64
[<40040a5c>] ___blocking_notifier_call_chain+0x30/0x80
[<40040ac0>] _blocking_notifier_call_chain+0x14/0x28
[<401332ac>] _fb_notifier_call_chain+0x1c/0x30
[<40134894>] _fb_set_var+0x170/0x324
[<40141e98>] _fbcon_switch+0x1b8/0x5a4
[<401635d4>] _redraw_screen+0x100/0x268
[<401424bc>] _fbcon_blank+0x238/0x2e0
[<40163834>] _do_unblank_screen+0xf8/0x200
[<40140aa8>] _fbcon_event_notify+0xae0/0xae8
[<40040608>] _notifier_call_chain+0x48/0x94
[<40040a74>] ___blocking_notifier_call_chain+0x48/0x80
[<40040ac0>] _blocking_notifier_call_chain+0x14/0x28
[<401332ac>] _fb_notifier_call_chain+0x1c/0x30
[<40133938>] _fb_blank+0x7c/0xa8
[<40139964>] _store_blank+0x50/0x84
[<401739ec>] _dev_attr_store+0x20/0x48
[<400e8bc0>] _sysfs_write_file+0x148/0x1a4
[<4009180c>] _vfs_write+0xec/0x194
[<40092168>] _sys_write+0x40/0x90
[<4000460c>] _switch_handler+0x110/0x170
[<40001098>] ___TBIBoingVec+0xc/0x10
INFO: lockdep is turned off.
^ permalink raw reply
* Re: [GIT PULL] OMAP DSS changes for .38 merge window
From: Paul Mundt @ 2011-01-07 13:25 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org,
ext Tony Lindgren
In-Reply-To: <1294404103.3968.56.camel@nubuntu>
On Fri, Jan 07, 2011 at 02:41:43PM +0200, Tomi Valkeinen wrote:
> Hello Paul,
>
> Here are some OMAP display changes for .38. I hope they are not too
> late, but the holidays messed up my schedules a bit.
>
No, no problem. I usually aim to do two merges per merge window on
average, one at the beginning and one nearer the end. There are often
many patches that have dependencies that are blocked while other trees
merge that get sent off when their dependencies have been met.
> I made two branches, as I'm not sure which is better:
>
> for-paul-38 - This one is the original non-rebased branch. This causes a
> trivial conflict with fbdev/master in drivers/video/omap2/vram.c (SZ_2M
> is the right one), and also it contains a patch (memblock: fix
> memblock_is_region_memory()) which is not yet in mainline, but is in
> Andrew Morton's tree.
>
> for-paul-38-rebased - The above branch rebased on top of v2.6.37, and
> the memblock commit removed.
>
> Which one you prefer? Or is there some other way I should handle this?
>
> I could merge v2.6.37 to my branch, which would remove the conflict, but
> that would still leave the memblock patch. I guess the patch is going in
> soon, but as it's not in my area, I don't feel it's right to get it in
> via my patch set. Alternatively I could wait until the patch is in
> Linus' tree, but that could make it tight to be in time for the merge
> window.
>
Andrew usually patch-bombs near the end of the window, so it's generally
a good idea to have things settled before then. In this case if the patch
is already destined for mainline then I can just pull the rebased branch,
send that out, and then once -mm syncs up everything should be good to go
for -rc1.
Looking at the change in question, it's just a correctness fix and
doesn't impact the API from the driver point of view, so at least there
won't be build damage if they're out of sync for a couple of days
(although it may trigger some nasty surprises for anyone unlucky enough
to bisect in the middle).
In any event, unless you absolutely need the change to be upstream first,
I'll plan to pull the rebase branch. If you need it there earlier we can
probably also just prod Andrew and get that one patch off earlier than
the rest of the -mm bits.
^ permalink raw reply
* Re: [GIT PULL] OMAP DSS changes for .38 merge window
From: Tomi Valkeinen @ 2011-01-07 13:37 UTC (permalink / raw)
To: ext Paul Mundt
Cc: linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org,
ext Tony Lindgren
In-Reply-To: <20110107132541.GA31660@linux-sh.org>
On Fri, 2011-01-07 at 22:25 +0900, ext Paul Mundt wrote:
> On Fri, Jan 07, 2011 at 02:41:43PM +0200, Tomi Valkeinen wrote:
> > Hello Paul,
> >
> > Here are some OMAP display changes for .38. I hope they are not too
> > late, but the holidays messed up my schedules a bit.
> >
> No, no problem. I usually aim to do two merges per merge window on
> average, one at the beginning and one nearer the end. There are often
> many patches that have dependencies that are blocked while other trees
> merge that get sent off when their dependencies have been met.
Ok, good. There are still some patches going around reviews that would
be nice to get in .38, but time is running short so I decided to send
the current patches.
I guess it's not out-of-the-question to get driver changes in in early
rcs, but I'd rather get everything pulled during the merge window. Also,
some of the patches still out there touch OMAP's arch/ files, so they
are not plain driver changes.
>
> > I made two branches, as I'm not sure which is better:
> >
> > for-paul-38 - This one is the original non-rebased branch. This causes a
> > trivial conflict with fbdev/master in drivers/video/omap2/vram.c (SZ_2M
> > is the right one), and also it contains a patch (memblock: fix
> > memblock_is_region_memory()) which is not yet in mainline, but is in
> > Andrew Morton's tree.
> >
> > for-paul-38-rebased - The above branch rebased on top of v2.6.37, and
> > the memblock commit removed.
> >
> > Which one you prefer? Or is there some other way I should handle this?
> >
> > I could merge v2.6.37 to my branch, which would remove the conflict, but
> > that would still leave the memblock patch. I guess the patch is going in
> > soon, but as it's not in my area, I don't feel it's right to get it in
> > via my patch set. Alternatively I could wait until the patch is in
> > Linus' tree, but that could make it tight to be in time for the merge
> > window.
> >
> Andrew usually patch-bombs near the end of the window, so it's generally
> a good idea to have things settled before then. In this case if the patch
> is already destined for mainline then I can just pull the rebased branch,
> send that out, and then once -mm syncs up everything should be good to go
> for -rc1.
>
> Looking at the change in question, it's just a correctness fix and
> doesn't impact the API from the driver point of view, so at least there
> won't be build damage if they're out of sync for a couple of days
> (although it may trigger some nasty surprises for anyone unlucky enough
> to bisect in the middle).
>
> In any event, unless you absolutely need the change to be upstream first,
> I'll plan to pull the rebase branch. If you need it there earlier we can
> probably also just prod Andrew and get that one patch off earlier than
> the rest of the -mm bits.
No, the fix is not needed urgently. The memblock fix is only important
for some rare use cases, which I don't think anyone is currently using
(allocating video memory from SDRAM at a predefined address).
Tomi
^ permalink raw reply
* Re: [GIT PULL] OMAP DSS changes for .38 merge window
From: Paul Mundt @ 2011-01-07 13:52 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org,
ext Tony Lindgren
In-Reply-To: <1294407452.3968.81.camel@nubuntu>
On Fri, Jan 07, 2011 at 03:37:32PM +0200, Tomi Valkeinen wrote:
> On Fri, 2011-01-07 at 22:25 +0900, ext Paul Mundt wrote:
> I guess it's not out-of-the-question to get driver changes in in early
> rcs, but I'd rather get everything pulled during the merge window. Also,
> some of the patches still out there touch OMAP's arch/ files, so they
> are not plain driver changes.
>
As long as all the new and big stuff goes in for -rc1 it's certainly fine
to take care of the rest over the next few rc releases. Things do
invariably break when multiple trees are being merged, so it's to be
expected.
> > Looking at the change in question, it's just a correctness fix and
> > doesn't impact the API from the driver point of view, so at least there
> > won't be build damage if they're out of sync for a couple of days
> > (although it may trigger some nasty surprises for anyone unlucky enough
> > to bisect in the middle).
> >
> > In any event, unless you absolutely need the change to be upstream first,
> > I'll plan to pull the rebase branch. If you need it there earlier we can
> > probably also just prod Andrew and get that one patch off earlier than
> > the rest of the -mm bits.
>
> No, the fix is not needed urgently. The memblock fix is only important
> for some rare use cases, which I don't think anyone is currently using
> (allocating video memory from SDRAM at a predefined address).
>
Hmm, I've just fast-forwarded to Linus's current tree and tried to pull
your rebase branch in, but it seems to have a board conflict with the
OMAP tree merge:
CONFLICT (delete/modify): arch/arm/mach-omap2/board-zoom2.c deleted in HEAD and modified in 122ffebf2191529153c079b457e38ca3829eac40. Version 122ffebf2191529153c079b457e38ca3829eac40 of arch/arm/mach-omap2/board-zoom2.c left in tree.
Additionally there's a board-zoom.c conflict that looks like this:
diff --cc arch/arm/mach-omap2/board-zoom.c
index e041c53,1523369..0000000
--- a/arch/arm/mach-omap2/board-zoom.c
+++ b/arch/arm/mach-omap2/board-zoom.c
@@@ -118,29 -113,17 +118,36 @@@ static const struct ehci_hcd_omap_platf
static void __init omap_zoom_init(void)
{
- omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
- zoom_peripherals_init();
+ if (machine_is_omap_zoom2()) {
+ omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+ } else if (machine_is_omap_zoom3()) {
+ omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
+ omap_mux_init_gpio(ZOOM3_EHCI_RESET_GPIO, OMAP_PIN_OUTPUT);
+ usb_ehci_init(&ehci_pdata);
+ }
+
board_nand_init(zoom_nand_partitions,
- ARRAY_SIZE(zoom_nand_partitions), ZOOM_NAND_CS);
+ ARRAY_SIZE(zoom_nand_partitions), ZOOM_NAND_CS);
zoom_debugboard_init();
++<<<<<<< HEAD:arch/arm/mach-omap2/board-zoom.c
+ zoom_peripherals_init();
++===+ zoom_display_init();
+
+ omap_mux_init_gpio(64, OMAP_PIN_OUTPUT);
+ usb_ehci_init(&ehci_pdata);
++>>>>>>> 122ffebf2191529153c079b457e38ca3829eac40:arch/arm/mach-omap2/board-zoom3.c
}
+MACHINE_START(OMAP_ZOOM2, "OMAP Zoom2 board")
+ .boot_params = 0x80000100,
+ .map_io = omap3_map_io,
+ .reserve = omap_reserve,
+ .init_irq = omap_zoom_init_irq,
+ .init_machine = omap_zoom_init,
+ .timer = &omap_timer,
+MACHINE_END
+
MACHINE_START(OMAP_ZOOM3, "OMAP Zoom3 board")
.boot_params = 0x80000100,
.map_io = omap3_map_io,
* Unmerged path arch/arm/mach-omap2/board-zoom2.c
It looks like there has been some consolidation work based on the last commit,
but I'll leave it to you to decide how to handle.
^ permalink raw reply
* Re: [GIT PULL] OMAP DSS changes for .38 merge window
From: Tomi Valkeinen @ 2011-01-07 14:06 UTC (permalink / raw)
To: ext Paul Mundt
Cc: linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org,
ext Tony Lindgren
In-Reply-To: <20110107135217.GA3760@linux-sh.org>
On Fri, 2011-01-07 at 22:52 +0900, ext Paul Mundt wrote:
> Hmm, I've just fast-forwarded to Linus's current tree and tried to pull
> your rebase branch in, but it seems to have a board conflict with the
> OMAP tree merge:
>
> CONFLICT (delete/modify): arch/arm/mach-omap2/board-zoom2.c deleted in HEAD and modified in 122ffebf2191529153c079b457e38ca3829eac40. Version 122ffebf2191529153c079b457e38ca3829eac40 of arch/arm/mach-omap2/board-zoom2.c left in tree.
>
> Additionally there's a board-zoom.c conflict that looks like this:
Ah. I'll have to fix that. Let's leave this until Monday, as I don't
have a board here to test the fixes.
Tomi
^ permalink raw reply
* Re: A query on frame buffers
From: Konrad Rzeszutek Wilk @ 2011-01-07 16:58 UTC (permalink / raw)
To: Michel Dänzer; +Cc: Prasad Joshi, linux-fbdev, dri-devel
In-Reply-To: <1294390835.6019.218.camel@thor.local>
> > The errors
> >
> > [ 3.778476] [drm:r100_ring_test] *ERROR* radeon: ring test failed
> > (sracth(0x15E4)=0xCAFEDEAD)
> > [ 3.781010] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
> > [ 3.782542] radeon 0000:00:04.0: failled initializing CP (-22).
> > [ 3.784006] radeon 0000:00:04.0: Disabling GPU acceleration
> >
> > Seem to be disabling GPU functionality. For now, I am interested in
> > Graphics functionality of the ATI card and not GPGPU functionality.
> >
> > I will appreciate if you can help me with some information on solving
> > this problem. Let me know if I should be asking this question on
> > another forum. Please keep me in CC.
>
> Looks like dri-devel material, added to CC.
>
> As a first guess, maybe the system memory pages accessed by the GPU GART
> aren't the same ones intended for this by the VM.
I actually have patches for that (sorry for the late reply).
Try:
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/ttm.pci-api.v3
But I am not sure if they would make any difference here. You said
you are using KVM-QEMU - you must also be using an IOMMU? Does the IOMMU
give you any errors?
^ permalink raw reply
* Re: A query on frame buffers
From: Prasad Joshi @ 2011-01-07 17:47 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: Michel Dänzer, linux-fbdev, dri-devel
In-Reply-To: <20110107165813.GA24320@dumpdata.com>
2011/1/7 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>:
>> > The errors
>> >
>> > [ 3.778476] [drm:r100_ring_test] *ERROR* radeon: ring test failed
>> > (sracth(0x15E4)=0xCAFEDEAD)
>> > [ 3.781010] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
>> > [ 3.782542] radeon 0000:00:04.0: failled initializing CP (-22).
>> > [ 3.784006] radeon 0000:00:04.0: Disabling GPU acceleration
>> >
>> > Seem to be disabling GPU functionality. For now, I am interested in
>> > Graphics functionality of the ATI card and not GPGPU functionality.
>> >
>> > I will appreciate if you can help me with some information on solving
>> > this problem. Let me know if I should be asking this question on
>> > another forum. Please keep me in CC.
>>
>> Looks like dri-devel material, added to CC.
>>
>> As a first guess, maybe the system memory pages accessed by the GPU GART
>> aren't the same ones intended for this by the VM.
>
> I actually have patches for that (sorry for the late reply).
>
> Try:
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/ttm.pci-api.v3
>
> But I am not sure if they would make any difference here. You said
> you are using KVM-QEMU - you must also be using an IOMMU? Does the IOMMU
> give you any errors?
>
Yes I want to pass-through the ATI Radeon card to VM in KVM. I have
enabled the IOMMU support and it works perfectly alright. I tried
passing through a network card it worked.
Should I try the patch you suggested?
>
^ permalink raw reply
* Re: A query on frame buffers
From: Konrad Rzeszutek Wilk @ 2011-01-07 19:24 UTC (permalink / raw)
To: Prasad Joshi; +Cc: Michel Dänzer, linux-fbdev, dri-devel
In-Reply-To: <AANLkTik_YENOcUioFFEN73i9ASZ7oZ80FZ_NXt-Ti5RV@mail.gmail.com>
On Fri, Jan 07, 2011 at 05:47:59PM +0000, Prasad Joshi wrote:
> 2011/1/7 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>:
> >> > The errors
> >> >
> >> > [ 3.778476] [drm:r100_ring_test] *ERROR* radeon: ring test failed
> >> > (sracth(0x15E4)=0xCAFEDEAD)
> >> > [ 3.781010] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
> >> > [ 3.782542] radeon 0000:00:04.0: failled initializing CP (-22).
> >> > [ 3.784006] radeon 0000:00:04.0: Disabling GPU acceleration
> >> >
> >> > Seem to be disabling GPU functionality. For now, I am interested in
> >> > Graphics functionality of the ATI card and not GPGPU functionality.
> >> >
> >> > I will appreciate if you can help me with some information on solving
> >> > this problem. Let me know if I should be asking this question on
> >> > another forum. Please keep me in CC.
> >>
> >> Looks like dri-devel material, added to CC.
> >>
> >> As a first guess, maybe the system memory pages accessed by the GPU GART
> >> aren't the same ones intended for this by the VM.
> >
> > I actually have patches for that (sorry for the late reply).
> >
> > Try:
> > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/ttm.pci-api.v3
> >
> > But I am not sure if they would make any difference here. You said
> > you are using KVM-QEMU - you must also be using an IOMMU? Does the IOMMU
> > give you any errors?
> >
>
> Yes I want to pass-through the ATI Radeon card to VM in KVM. I have
> enabled the IOMMU support and it works perfectly alright. I tried
> passing through a network card it worked.
>
> Should I try the patch you suggested?
Go for it. I am still at lost why you would see those errors unless..
well, what is the DMA code that gets turned on when you run your guest?
What do you see for 'PCI-DMA' ? Is it bounce buffer or swiotlb?
How much memory do you pass to the guest? less than 4GB?
^ permalink raw reply
* Re: [PATCH] Corrected matroxfb video option in comments and kernel
From: Vicente Jiménez @ 2011-01-08 0:54 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <AANLkTikqCduraRjVvtaU3u1ikQyR-3GryovdTMe-z5HD@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 985 bytes --]
Attached the patch with the miisng signed-off-by.
On Thu, Jan 6, 2011 at 7:35 AM, Paul Mundt <lethal@linux-sh.org> wrote:
> On Tue, Dec 28, 2010 at 11:03:50AM +0100, Vicente Jim?nez wrote:
>> From 81561bbf722613794c77cd03c537f4139b2d0976 Mon Sep 17 00:00:00 2001
>> From: Vicente Jimenez Aguilar <googuy@gmail.com>
>> Date: Tue, 28 Dec 2010 11:35:24 +0100
>> Subject: [PATCH 2/2] Corrected matroxfb video option in comments and kernel config help.
>>
>> Configuring the kernel I found that the Matrox frame buffer help has a
>> different option than the one in the docs (Documentation/fb/matroxfb.txt).
>> I decided to check the source code to see what is the correct option.
>> drivers/video/matrox/matroxfb_base.c has a lot of comments that sugests
>> that the video option is "matrox".
>> However in line 2452 of this same file you have:
>> fb_get_options("matroxfb", &option)
>>
>> video=matroxfb:XXX is the correct video option not video=matrox:XXX.
>
> Missing Signed-off-by.
>
[-- Attachment #2: 0002-Corrected-matroxfb-video-option-in-comments-and-kern.patch --]
[-- Type: text/x-patch, Size: 5844 bytes --]
From 240687e43f325a41e7edb02fc3d2277559d90079 Mon Sep 17 00:00:00 2001
From: Vicente Jimenez Aguilar <googuy@gmail.com>
Date: Tue, 28 Dec 2010 11:35:24 +0100
Subject: [PATCH 2/2] Corrected matroxfb video option in comments and kernel config help.
Configuring the kernel I found that the Matrox frame buffer help has a
different option than the one in the docs (Documentation/fb/matroxfb.txt).
I decided to check the source code to see what is the correct option.
drivers/video/matrox/matroxfb_base.c has a lot of comments that sugests
that the video option is "matrox".
However in line 2452 of this same file you have:
fb_get_options("matroxfb", &option)
video=matroxfb:XXX is the correct video option not video=matrox:XXX.
Signed-off-by: Vicente Jimenez Aguilar <googuy@gmail.com>
---
drivers/video/Kconfig | 2 +-
drivers/video/matrox/matroxfb_base.c | 70 +++++++++++++++++-----------------
2 files changed, 36 insertions(+), 36 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 27c1fb4..58c3349 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1209,7 +1209,7 @@ config FB_MATROX
module will be called matroxfb.
You can pass several parameters to the driver at boot time or at
- module load time. The parameters look like "video=matrox:XXX", and
+ module load time. The parameters look like "video=matroxfb:XXX", and
are described in <file:Documentation/fb/matroxfb.txt>.
config FB_MATROX_MILLENIUM
diff --git a/drivers/video/matrox/matroxfb_base.c b/drivers/video/matrox/matroxfb_base.c
index 052dd9f..a082deb 100644
--- a/drivers/video/matrox/matroxfb_base.c
+++ b/drivers/video/matrox/matroxfb_base.c
@@ -1247,46 +1247,46 @@ static struct { struct fb_bitfield red, green, blue, transp; int bits_per_pixel;
};
/* initialized by setup, see explanation at end of file (search for MODULE_PARM_DESC) */
-static unsigned int mem; /* "matrox:mem:xxxxxM" */
+static unsigned int mem; /* "matroxfb:mem:xxxxxM" */
static int option_precise_width = 1; /* cannot be changed, option_precise_width==0 must imply noaccel */
-static int inv24; /* "matrox:inv24" */
-static int cross4MB = -1; /* "matrox:cross4MB" */
-static int disabled; /* "matrox:disabled" */
-static int noaccel; /* "matrox:noaccel" */
-static int nopan; /* "matrox:nopan" */
-static int no_pci_retry; /* "matrox:nopciretry" */
-static int novga; /* "matrox:novga" */
-static int nobios; /* "matrox:nobios" */
-static int noinit = 1; /* "matrox:init" */
-static int inverse; /* "matrox:inverse" */
-static int sgram; /* "matrox:sgram" */
+static int inv24; /* "matroxfb:inv24" */
+static int cross4MB = -1; /* "matroxfb:cross4MB" */
+static int disabled; /* "matroxfb:disabled" */
+static int noaccel; /* "matroxfb:noaccel" */
+static int nopan; /* "matroxfb:nopan" */
+static int no_pci_retry; /* "matroxfb:nopciretry" */
+static int novga; /* "matroxfb:novga" */
+static int nobios; /* "matroxfb:nobios" */
+static int noinit = 1; /* "matroxfb:init" */
+static int inverse; /* "matroxfb:inverse" */
+static int sgram; /* "matroxfb:sgram" */
#ifdef CONFIG_MTRR
-static int mtrr = 1; /* "matrox:nomtrr" */
+static int mtrr = 1; /* "matroxfb:nomtrr" */
#endif
-static int grayscale; /* "matrox:grayscale" */
-static int dev = -1; /* "matrox:dev:xxxxx" */
-static unsigned int vesa = ~0; /* "matrox:vesa:xxxxx" */
-static int depth = -1; /* "matrox:depth:xxxxx" */
-static unsigned int xres; /* "matrox:xres:xxxxx" */
-static unsigned int yres; /* "matrox:yres:xxxxx" */
-static unsigned int upper = ~0; /* "matrox:upper:xxxxx" */
-static unsigned int lower = ~0; /* "matrox:lower:xxxxx" */
-static unsigned int vslen; /* "matrox:vslen:xxxxx" */
-static unsigned int left = ~0; /* "matrox:left:xxxxx" */
-static unsigned int right = ~0; /* "matrox:right:xxxxx" */
-static unsigned int hslen; /* "matrox:hslen:xxxxx" */
-static unsigned int pixclock; /* "matrox:pixclock:xxxxx" */
-static int sync = -1; /* "matrox:sync:xxxxx" */
-static unsigned int fv; /* "matrox:fv:xxxxx" */
-static unsigned int fh; /* "matrox:fh:xxxxxk" */
-static unsigned int maxclk; /* "matrox:maxclk:xxxxM" */
-static int dfp; /* "matrox:dfp */
-static int dfp_type = -1; /* "matrox:dfp:xxx */
-static int memtype = -1; /* "matrox:memtype:xxx" */
-static char outputs[8]; /* "matrox:outputs:xxx" */
+static int grayscale; /* "matroxfb:grayscale" */
+static int dev = -1; /* "matroxfb:dev:xxxxx" */
+static unsigned int vesa = ~0; /* "matroxfb:vesa:xxxxx" */
+static int depth = -1; /* "matroxfb:depth:xxxxx" */
+static unsigned int xres; /* "matroxfb:xres:xxxxx" */
+static unsigned int yres; /* "matroxfb:yres:xxxxx" */
+static unsigned int upper = ~0; /* "matroxfb:upper:xxxxx" */
+static unsigned int lower = ~0; /* "matroxfb:lower:xxxxx" */
+static unsigned int vslen; /* "matroxfb:vslen:xxxxx" */
+static unsigned int left = ~0; /* "matroxfb:left:xxxxx" */
+static unsigned int right = ~0; /* "matroxfb:right:xxxxx" */
+static unsigned int hslen; /* "matroxfb:hslen:xxxxx" */
+static unsigned int pixclock; /* "matroxfb:pixclock:xxxxx" */
+static int sync = -1; /* "matroxfb:sync:xxxxx" */
+static unsigned int fv; /* "matroxfb:fv:xxxxx" */
+static unsigned int fh; /* "matroxfb:fh:xxxxxk" */
+static unsigned int maxclk; /* "matroxfb:maxclk:xxxxM" */
+static int dfp; /* "matroxfb:dfp */
+static int dfp_type = -1; /* "matroxfb:dfp:xxx */
+static int memtype = -1; /* "matroxfb:memtype:xxx" */
+static char outputs[8]; /* "matroxfb:outputs:xxx" */
#ifndef MODULE
-static char videomode[64]; /* "matrox:mode:xxxxx" or "matrox:xxxxx" */
+static char videomode[64]; /* "matroxfb:mode:xxxxx" or "matroxfb:xxxxx" */
#endif
static int matroxfb_getmemory(struct matrox_fb_info *minfo,
--
1.7.3.4
^ permalink raw reply related
* Re: A query on frame buffers
From: Prasad Joshi @ 2011-01-08 2:12 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: Michel Dänzer, linux-fbdev, dri-devel
In-Reply-To: <20110107192437.GD27871@dumpdata.com>
On Fri, Jan 7, 2011 at 7:24 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Fri, Jan 07, 2011 at 05:47:59PM +0000, Prasad Joshi wrote:
>> 2011/1/7 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>:
>> >> > The errors
>> >> >
>> >> > [ 3.778476] [drm:r100_ring_test] *ERROR* radeon: ring test failed
>> >> > (sracth(0x15E4)=0xCAFEDEAD)
>> >> > [ 3.781010] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
>> >> > [ 3.782542] radeon 0000:00:04.0: failled initializing CP (-22).
>> >> > [ 3.784006] radeon 0000:00:04.0: Disabling GPU acceleration
>> >> >
>> >> > Seem to be disabling GPU functionality. For now, I am interested in
>> >> > Graphics functionality of the ATI card and not GPGPU functionality.
>> >> >
>> >> > I will appreciate if you can help me with some information on solving
>> >> > this problem. Let me know if I should be asking this question on
>> >> > another forum. Please keep me in CC.
>> >>
>> >> Looks like dri-devel material, added to CC.
>> >>
>> >> As a first guess, maybe the system memory pages accessed by the GPU GART
>> >> aren't the same ones intended for this by the VM.
>> >
>> > I actually have patches for that (sorry for the late reply).
>> >
>> > Try:
>> > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/ttm.pci-api.v3
I could access the git repository, but was not able to get those
patches form the repository. Frankly speaking, I don't know how to get
those patches.
>> >
>> > But I am not sure if they would make any difference here. You said
>> > you are using KVM-QEMU - you must also be using an IOMMU? Does the IOMMU
>> > give you any errors?
>> >
>>
>> Yes I want to pass-through the ATI Radeon card to VM in KVM. I have
>> enabled the IOMMU support and it works perfectly alright. I tried
>> passing through a network card it worked.
>>
>> Should I try the patch you suggested?
>
> Go for it. I am still at lost why you would see those errors unless..
> well, what is the DMA code that gets turned on when you run your guest?
> What do you see for 'PCI-DMA' ? Is it bounce buffer or swiotlb?
> How much memory do you pass to the guest? less than 4GB?
>
I am trying these things on Uni server, I will let you know the
answers by tomorrow.
Thanks and Regards,
Prasad
^ permalink raw reply
* [PATCH] video: imx: Update the manufacturer name
From: Fabio Estevam @ 2011-01-09 16:33 UTC (permalink / raw)
To: linux-fbdev
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
drivers/video/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 55dc6fb..0ac30ef 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -414,7 +414,7 @@ config FB_SA1100
Y here.
config FB_IMX
- tristate "Motorola i.MX LCD support"
+ tristate "Freescale i.MX LCD support"
depends on FB && (HAVE_FB_IMX || ARCH_MX1 || ARCH_MX2)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH] video: imx: Update the manufacturer name
From: @ 2011-01-09 19:11 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1294590818-5001-1-git-send-email-festevam@gmail.com>
Hello Fabio,
On Sun, Jan 09, 2011 at 02:33:38PM -0200, Fabio Estevam wrote:
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> drivers/video/Kconfig | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 55dc6fb..0ac30ef 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -414,7 +414,7 @@ config FB_SA1100
> Y here.
>
> config FB_IMX
> - tristate "Motorola i.MX LCD support"
> + tristate "Freescale i.MX LCD support"
do you have an explanation why this is wrong? Was it a copy&paste
error? If it used to be correct I'd prefer to keep Motorola in there.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH] video: imx: Update the manufacturer name
From: Fabio Estevam @ 2011-01-09 23:19 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1294590818-5001-1-git-send-email-festevam@gmail.com>
Hi Uwe,
2011/1/9 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
> Hello Fabio,
>
> On Sun, Jan 09, 2011 at 02:33:38PM -0200, Fabio Estevam wrote:
>> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
>> ---
>> drivers/video/Kconfig | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
>> index 55dc6fb..0ac30ef 100644
>> --- a/drivers/video/Kconfig
>> +++ b/drivers/video/Kconfig
>> @@ -414,7 +414,7 @@ config FB_SA1100
>> Y here.
>>
>> config FB_IMX
>> - tristate "Motorola i.MX LCD support"
>> + tristate "Freescale i.MX LCD support"
> do you have an explanation why this is wrong? Was it a copy&paste
> error? If it used to be correct I'd prefer to keep Motorola in there.
The reason is that there exists no "Motorola i.MX" anymore.
Freescale is the company that manufactures the i.MX processors
currently, not Motorola.
Motorola used to manufacture i.MX devices until 2004. After the
spin-off in 2004, Freescale continued as the i.MX manufacturer.
Also, if you look at the first submission of the i.MX framebuffer
driver from Sascha (imxfb: Add Freescale i.MX framebuffer driver -
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h|2f891cb64b0b9c8d389da97c221ee4288f1307)
it contains the correct name there ,so this patch makes the driver
selection consistent.
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH v3] LEDS: Add output invertion option to backlight trigger
From: Janusz Krzysztofik @ 2011-01-10 4:54 UTC (permalink / raw)
To: Andrew Morton
Cc: Richard Purdie, linux-fbdev@vger.kernel.org, linux-kernel,
linux-omap@vger.kernel.org, Paul Mundt, Richard Purdie
In-Reply-To: <20110106130440.cfd77c8e.akpm@linux-foundation.org>
This patch extends the LED backlight tirgger driver with an option that
allows for inverting the trigger output polarity.
With the invertion option provided, I (ab)use the backlight trigger for
driving a LED that indicates LCD display blank condtition on my Amstrad
Delta videophone. Since the machine has no dedicated power LED, it was
not possible to distinguish if the display was blanked, or the machine
was turned off, without touching it.
The invert sysfs control is patterned after a similiar function of the
GPIO trigger driver.
Created and tested against linux-2.6.37 on Amstrad Delta.
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Cc: Richard Purdie <rpurdie@rpsys.net>
---
v2 -> v3 changes, all provided, requested or inspired by Andrew Morton
(thanks!):
- sysfs file should show "0" or "1" to match the thing which the user
wrote there,
- use strict_strtoul() so the kernel correctly rejects non-numerical
input,
- disallow any input other than 0 or 1,
- new sysfs file should be documented,
- the new sysfs file name could be consistent with the one already used
by the gpio trigger for a similiar function.
v1 -> v2 changes:
- improve some conditional expressions to be more readable; thanks to
Ralph Corderoy (from e3-hacking) and Lars-Peter Clausen for their
suggestions,
- refresh against linux-2.6.36-rc5.
Documentation/ABI/testing/sysfs-class-led | 10 ++++
drivers/leds/ledtrig-backlight.c | 61 ++++++++++++++++++++++++++++--
2 files changed, 67 insertions(+), 4 deletions(-)
--- linux-2.6.37/drivers/leds/ledtrig-backlight.c.orig 2011-01-10 02:55:26.000000000 +0100
+++ linux-2.6.37/drivers/leds/ledtrig-backlight.c 2011-01-10 03:12:46.000000000 +0100
@@ -26,6 +26,7 @@ struct bl_trig_notifier {
int brightness;
int old_status;
struct notifier_block notifier;
+ unsigned invert;
};
static int fb_notifier_callback(struct notifier_block *p,
@@ -36,23 +37,64 @@ static int fb_notifier_callback(struct n
struct led_classdev *led = n->led;
struct fb_event *fb_event = data;
int *blank = fb_event->data;
+ int new_status = *blank ? BLANK : UNBLANK;
switch (event) {
case FB_EVENT_BLANK :
- if (*blank && n->old_status = UNBLANK) {
+ if (new_status = n->old_status)
+ break;
+
+ if ((n->old_status = UNBLANK) ^ n->invert) {
n->brightness = led->brightness;
led_set_brightness(led, LED_OFF);
- n->old_status = BLANK;
- } else if (!*blank && n->old_status = BLANK) {
+ } else {
led_set_brightness(led, n->brightness);
- n->old_status = UNBLANK;
}
+
+ n->old_status = new_status;
+
break;
}
return 0;
}
+static ssize_t bl_trig_invert_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct led_classdev *led = dev_get_drvdata(dev);
+ struct bl_trig_notifier *n = led->trigger_data;
+
+ return sprintf(buf, "%u\n", n->invert);
+}
+
+static ssize_t bl_trig_invert_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t num)
+{
+ struct led_classdev *led = dev_get_drvdata(dev);
+ struct bl_trig_notifier *n = led->trigger_data;
+ unsigned long invert;
+ int ret;
+
+ ret = strict_strtoul(buf, 10, &invert);
+ if (ret < 0)
+ return ret;
+
+ if (invert > 1)
+ return -EINVAL;
+
+ n->invert = invert;
+
+ /* After inverting, we need to update the LED. */
+ if ((n->old_status = BLANK) ^ n->invert)
+ led_set_brightness(led, LED_OFF);
+ else
+ led_set_brightness(led, n->brightness);
+
+ return num;
+}
+static DEVICE_ATTR(inverted, 0644, bl_trig_invert_show, bl_trig_invert_store);
+
static void bl_trig_activate(struct led_classdev *led)
{
int ret;
@@ -66,6 +108,10 @@ static void bl_trig_activate(struct led_
return;
}
+ ret = device_create_file(led->dev, &dev_attr_inverted);
+ if (ret)
+ goto err_invert;
+
n->led = led;
n->brightness = led->brightness;
n->old_status = UNBLANK;
@@ -74,6 +120,12 @@ static void bl_trig_activate(struct led_
ret = fb_register_client(&n->notifier);
if (ret)
dev_err(led->dev, "unable to register backlight trigger\n");
+
+ return;
+
+err_invert:
+ led->trigger_data = NULL;
+ kfree(n);
}
static void bl_trig_deactivate(struct led_classdev *led)
@@ -82,6 +134,7 @@ static void bl_trig_deactivate(struct le
(struct bl_trig_notifier *) led->trigger_data;
if (n) {
+ device_remove_file(led->dev, &dev_attr_inverted);
fb_unregister_client(&n->notifier);
kfree(n);
}
--- linux-2.6.37/Documentation/ABI/testing/sysfs-class-led.orig 2011-01-10 02:42:16.000000000 +0100
+++ linux-2.6.37/Documentation/ABI/testing/sysfs-class-led 2011-01-10 03:38:28.000000000 +0100
@@ -26,3 +26,13 @@ Description:
scheduler is chosen. Trigger specific parameters can appear in
/sys/class/leds/<led> once a given trigger is selected.
+What: /sys/class/leds/<led>/inverted
+Date: January 2011
+KernelVersion: 2.6.38
+Contact: Richard Purdie <rpurdie@rpsys.net>
+Description:
+ Invert the LED on/off state. This parameter is specific to
+ gpio and backlight triggers. In case of the backlight trigger,
+ it is usefull when driving a LED which is intended to indicate
+ a device in a standby like state.
+
^ permalink raw reply
* Re: [PATCH] video: imx: Update the manufacturer name
From: @ 2011-01-10 9:39 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1294590818-5001-1-git-send-email-festevam@gmail.com>
Hello Fabio,
On Sun, Jan 09, 2011 at 09:19:18PM -0200, Fabio Estevam wrote:
> 2011/1/9 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
> > On Sun, Jan 09, 2011 at 02:33:38PM -0200, Fabio Estevam wrote:
> >> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> >> ---
> >> drivers/video/Kconfig | 2 +-
> >> 1 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> >> index 55dc6fb..0ac30ef 100644
> >> --- a/drivers/video/Kconfig
> >> +++ b/drivers/video/Kconfig
> >> @@ -414,7 +414,7 @@ config FB_SA1100
> >> Y here.
> >>
> >> config FB_IMX
> >> - tristate "Motorola i.MX LCD support"
> >> + tristate "Freescale i.MX LCD support"
> > do you have an explanation why this is wrong? Was it a copy&paste
> > error? If it used to be correct I'd prefer to keep Motorola in there.
>
> The reason is that there exists no "Motorola i.MX" anymore.
>
> Freescale is the company that manufactures the i.MX processors
> currently, not Motorola.
>
> Motorola used to manufacture i.MX devices until 2004. After the
> spin-off in 2004, Freescale continued as the i.MX manufacturer.
>
> Also, if you look at the first submission of the i.MX framebuffer
> driver from Sascha (imxfb: Add Freescale i.MX framebuffer driver -
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h|2f891cb64b0b9c8d389da97c221ee4288f1307)
> it contains the correct name there ,so this patch makes the driver
> selection consistent.
If you add (a maybe shortend version of) this to the commit log it would
be fine for me.
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [GIT PULL] OMAP DSS changes for .38 merge window v2
From: Tomi Valkeinen @ 2011-01-10 9:51 UTC (permalink / raw)
To: ext Paul Mundt
Cc: linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org,
ext Tony Lindgren
In-Reply-To: <1294404103.3968.56.camel@nubuntu>
Hi Paul,
Here's a new pull request for OMAP display subsystem patches. This one
is rebased on top of the new omap patches on mainline, and the resulting
board file conflict has been fixed.
And while rebasing, I squashed the topmost patch, OMAP: DSS2: Fix build
breaks for rfbi.c and dsi.c, into the respective patches. The patch
contained only a few trivial compile fixes to errors which mistakenly
slipped in.
Tomi
The following changes since commit 01539ba2a706ab7d35fc0667dff919ade7f87d63:
Merge branch 'omap-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6 (2011-01-06 19:13:58 -0800)
are available in the git repository at:
git://gitorious.org/linux-omap-dss2/linux.git for-paul-38-rebased
Archit Taneja (4):
OMAP: DSS2: Fix: Read correct bit in dispc_enable_alpha_blending()
OMAP: DSS2: Clean up DISPC color mode validation checks
OMAP: DSS2: Add dss_features for omap4 and overlay manager related features
OMAP: DSS2: Use dss_features to handle DISPC bits removed on OMAP4
Bryan Wu (4):
OMAP: DSS2: Add generic DPI panel display driver
OMAP: use generic DPI panel driver in board files
OMAP: DSS2: remove generic DPI panel driver duplicated panel drivers
OMAP: DSS2: Add back authors of panel-generic.c based drivers
Erik Gilling (1):
OMAP: DSS2: Add NEC NL8048HL11-01B display panel
Kishore Y (2):
OMAP3: ZOOM2/3/3630SDP: Add display board file for OMAP3
OMAP3: Enable display on ZOOM2/3/3630SDP
Rajkumar N (1):
OMAP3630: DSS2: Enable Pre-Multiplied Alpha Support
Samreen (2):
OMAP3: DSS2: Split OMAP3 has feature for 3430 & 3630
OMAP: DSS2: OMAPFB: Add null pointer check
Sumit Semwal (5):
OMAP: DSS2: Represent DISPC register defines with channel as parameter
OMAP: DSS2: Introduce omap_channel argument to DISPC functions used by interface drivers
OMAP: DSS2: Change remaining DISPC functions for new omap_channel argument
OMAP: DSS2: LCD2 Channel Changes for DISPC
OMAP: DSS2: Introduce omap_channel as an omap_dss_device parameter, add new overlay manager.
arch/arm/mach-omap2/Makefile | 3 +
arch/arm/mach-omap2/board-3430sdp.c | 12 +-
arch/arm/mach-omap2/board-3630sdp.c | 1 +
arch/arm/mach-omap2/board-am3517evm.c | 23 +-
arch/arm/mach-omap2/board-cm-t35.c | 23 +-
arch/arm/mach-omap2/board-devkit8000.c | 26 +-
arch/arm/mach-omap2/board-igep0020.c | 12 +-
arch/arm/mach-omap2/board-omap3beagle.c | 12 +-
arch/arm/mach-omap2/board-omap3evm.c | 12 +-
arch/arm/mach-omap2/board-omap3stalker.c | 23 +-
arch/arm/mach-omap2/board-zoom-display.c | 168 +++++
arch/arm/mach-omap2/board-zoom-peripherals.c | 49 ++-
arch/arm/mach-omap2/board-zoom.c | 1 +
arch/arm/mach-omap2/include/mach/board-zoom.h | 3 +
arch/arm/plat-omap/include/plat/display.h | 9 +
.../arm/plat-omap/include/plat/panel-generic-dpi.h | 37 ++
drivers/video/omap2/displays/Kconfig | 27 +-
drivers/video/omap2/displays/Makefile | 5 +-
drivers/video/omap2/displays/panel-generic-dpi.c | 365 +++++++++++
drivers/video/omap2/displays/panel-generic.c | 174 ------
.../omap2/displays/panel-nec-nl8048hl11-01b.c | 325 ++++++++++
.../video/omap2/displays/panel-sharp-lq043t1dg01.c | 165 -----
.../video/omap2/displays/panel-toppoly-tdo35s.c | 164 -----
drivers/video/omap2/dss/dispc.c | 636 +++++++++++++-------
drivers/video/omap2/dss/dpi.c | 40 +-
drivers/video/omap2/dss/dsi.c | 27 +-
drivers/video/omap2/dss/dss.h | 35 +-
drivers/video/omap2/dss/dss_features.c | 66 ++-
drivers/video/omap2/dss/dss_features.h | 10 +-
drivers/video/omap2/dss/manager.c | 80 ++-
drivers/video/omap2/dss/overlay.c | 55 ++-
drivers/video/omap2/dss/rfbi.c | 20 +-
drivers/video/omap2/dss/sdi.c | 24 +-
drivers/video/omap2/omapfb/omapfb-main.c | 5 +-
34 files changed, 1754 insertions(+), 883 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-zoom-display.c
create mode 100644 arch/arm/plat-omap/include/plat/panel-generic-dpi.h
create mode 100644 drivers/video/omap2/displays/panel-generic-dpi.c
delete mode 100644 drivers/video/omap2/displays/panel-generic.c
create mode 100644 drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
delete mode 100644 drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
delete mode 100644 drivers/video/omap2/displays/panel-toppoly-tdo35s.c
^ permalink raw reply
* [PATCH v2] video: imx: Update the manufacturer's name
From: Fabio Estevam @ 2011-01-10 11:47 UTC (permalink / raw)
To: linux-fbdev
i.MX processors are currently manufactured by Freescale, not Motorola.
Make the manufacturer's name consistent.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
Changes since v1:
- Improved commit message
- Replaced Motorola reference in imxfb.c
drivers/video/Kconfig | 2 +-
drivers/video/imxfb.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 55dc6fb..0ac30ef 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -414,7 +414,7 @@ config FB_SA1100
Y here.
config FB_IMX
- tristate "Motorola i.MX LCD support"
+ tristate "Freescale i.MX LCD support"
depends on FB && (HAVE_FB_IMX || ARCH_MX1 || ARCH_MX2)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
index 1ab2c25..69bd4a5 100644
--- a/drivers/video/imxfb.c
+++ b/drivers/video/imxfb.c
@@ -974,6 +974,6 @@ static void __exit imxfb_cleanup(void)
module_init(imxfb_init);
module_exit(imxfb_cleanup);
-MODULE_DESCRIPTION("Motorola i.MX framebuffer driver");
+MODULE_DESCRIPTION("Freescale i.MX framebuffer driver");
MODULE_AUTHOR("Sascha Hauer, Pengutronix");
MODULE_LICENSE("GPL");
--
1.6.0.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox