[PATCH] [Streak] Add workaround for TTY kernel OOPS at the cost of performance.

[PATCH] [Streak] Add workaround for TTY kernel OOPS at the cost of performance.

[Tomasz Sterna]

The current framebuffer driver oopses when used as a console (kernel
parameter: console=tty ).
Here is a patch that makes it work - at the cost of performance.

Signed-off-by: Bradley Smith <brad@brad-smith.co.uk>
(cherry picked from commit 28d06a6366c851c6e0c5b954353bf82cb641d4e7)
---
 drivers/video/msm/Kconfig     |    4 ++++
 drivers/video/msm/mdp.c       |   20 ++++++++++++++++++++
 drivers/video/msm/mdp.h       |    3 +++
 drivers/video/msm/mdp_dma.c   |   15 +++++++++++++++
 drivers/video/msm/mdp_dma_s.c |   28 ++++++++++++++++++++++++++++
 drivers/video/msm/msm_fb.c    |    2 ++
 drivers/video/msm/msm_fb.h    |   14 ++++++++++++++
 7 files changed, 86 insertions(+), 0 deletions(-)

diff --git a/drivers/video/msm/Kconfig b/drivers/video/msm/Kconfig
index e887a2d..cff8435 100644
--- a/drivers/video/msm/Kconfig
+++ b/drivers/video/msm/Kconfig
@@ -14,3 +14,7 @@ config FB_MSM_LCDC
 	depends on FB_MSM && MSM_MDP31
 	default y
 
+config MSM_FB_TTY_WORKAROUND
+	bool "Workaround TTY kernel OOPS at the cost of performance"
+	depends on FB_MSM
+	default n
diff --git a/drivers/video/msm/mdp.c b/drivers/video/msm/mdp.c
index e56dd81..8bc2b13 100644
--- a/drivers/video/msm/mdp.c
+++ b/drivers/video/msm/mdp.c
@@ -118,6 +118,10 @@ static int mdp_suspend(struct platform_device *pdev, pm_message_t state);
 struct timeval mdp_dma2_timeval;
 struct timeval mdp_ppp_timeval;
 
+#ifdef CONFIG_MSM_FB_TTY_WORKAROUND
+LIST_HEAD(msm_fb_dma_task_list);
+#endif
+
 #ifdef CONFIG_HAS_EARLYSUSPEND
 static struct early_suspend early_suspend;
 #endif
@@ -634,10 +638,26 @@ irqreturn_t mdp_isr(int irq, void *ptr)
 		/* DMA2 LCD-Out Complete */
 		if (mdp_interrupt & MDP_DMA_S_DONE) {
 			dma = &dma_s_data;
+#ifdef CONFIG_MSM_FB_TTY_WORKAROUND
+			if(!list_empty(&msm_fb_dma_task_list)) {
+				struct msm_fb_dma_task *tsk = list_first_entry(
+					&msm_fb_dma_task_list, struct msm_fb_dma_task, list);
+				dma->busy = TRUE;
+				mdp_dma_s_update_lcd(tsk->mfd, &tsk->ibuf);
+				list_del(&tsk->list);
+				kfree(tsk);
+			}
+			else {
+				mdp_disable_irq(MDP_DMA_S_TERM);
+				mdp_disable_irq(MDP_DMA_E_TERM);
+				dma->busy = FALSE;
+			}
+#else
 			dma->busy = FALSE;
 			mdp_pipe_ctrl(MDP_DMA_S_BLOCK, MDP_BLOCK_POWER_OFF,
 				      TRUE);
 			complete(&dma->comp);
+#endif
 		}
 		/* DMA_E LCD-Out Complete */
 		if (mdp_interrupt & MDP_DMA_E_DONE) {
diff --git a/drivers/video/msm/mdp.h b/drivers/video/msm/mdp.h
index d60ccae..f3d064b 100644
--- a/drivers/video/msm/mdp.h
+++ b/drivers/video/msm/mdp.h
@@ -680,4 +680,7 @@ int mdp_debugfs_init(void);
 #endif
 
 void mdp_dma_s_update(struct msm_fb_data_type *mfd);
+#ifdef CONFIG_MSM_FB_TTY_WORKAROUND
+void mdp_dma_s_update_lcd(struct msm_fb_data_type *mfd, MDPIBUF *iBuf);
+#endif
 #endif /* MDP_H */
diff --git a/drivers/video/msm/mdp_dma.c b/drivers/video/msm/mdp_dma.c
index dc8d58d..f62c7e3 100644
--- a/drivers/video/msm/mdp_dma.c
+++ b/drivers/video/msm/mdp_dma.c
@@ -433,7 +433,9 @@ void mdp_dma2_update(struct msm_fb_data_type *mfd)
 	down(&mfd->dma->mutex);
 	if ((mfd) && (!mfd->dma->busy) && (mfd->panel_power_on)) {
 		down(&mfd->sem);
+#if !defined(CONFIG_MSM_FB_TTY_WORKAROUND)
 		mfd->ibuf_flushed = TRUE;
+#endif
 		mdp_dma2_update_lcd(mfd);
 
 		mdp_enable_irq(MDP_DMA2_TERM);
@@ -448,11 +450,13 @@ void mdp_dma2_update(struct msm_fb_data_type *mfd)
 		wait_for_completion_killable(&mfd->dma->comp);
 		mdp_disable_irq(MDP_DMA2_TERM);
 
+#if !defined(CONFIG_MSM_FB_TTY_WORKAROUND)
 	/* signal if pan function is waiting for the update completion */
 		if (mfd->pan_waiting) {
 			mfd->pan_waiting = FALSE;
 			complete(&mfd->pan_comp);
 		}
+#endif
 	}
 	up(&mfd->dma->mutex);
 }
@@ -484,6 +488,12 @@ void mdp_set_dma_pan_info(struct fb_info *info, struct mdp_dirty_region *dirty,
 
 	iBuf->vsync_enable = sync;
 
+#ifdef CONFIG_MSM_FB_TTY_WORKAROUND
+	iBuf->dma_x = 0;
+	iBuf->dma_y = 0;
+	iBuf->dma_w = info->var.xres;
+	iBuf->dma_h = info->var.yres;
+#else
 	if (dirty) {
 		/*
 		 * ToDo: dirty region check inside var.xoffset+xres
@@ -500,6 +510,7 @@ void mdp_set_dma_pan_info(struct fb_info *info, struct mdp_dirty_region *dirty,
 		iBuf->dma_h = info->var.yres;
 	}
 	mfd->ibuf_flushed = FALSE;
+#endif
 	up(&mfd->sem);
 }
 
@@ -510,6 +521,9 @@ void mdp_dma_pan_update(struct fb_info *info)
 
 	iBuf = &mfd->ibuf;
 
+#ifdef CONFIG_MSM_FB_TTY_WORKAROUND
+	mfd->dma_fnc(mfd);
+#else
 	if (mfd->sw_currently_refreshing) {
 		/* we need to wait for the pending update */
 		mfd->pan_waiting = TRUE;
@@ -521,6 +535,7 @@ void mdp_dma_pan_update(struct fb_info *info)
 		wait_for_completion_killable(&mfd->pan_comp);
 	} else
 		mfd->dma_fnc(mfd);
+#endif
 }
 
 void mdp_refresh_screen(unsigned long data)
diff --git a/drivers/video/msm/mdp_dma_s.c b/drivers/video/msm/mdp_dma_s.c
index ee39504..c9b67d5 100644
--- a/drivers/video/msm/mdp_dma_s.c
+++ b/drivers/video/msm/mdp_dma_s.c
@@ -37,9 +37,14 @@
 #include "mdp.h"
 #include "msm_fb.h"
 
+#ifdef CONFIG_MSM_FB_TTY_WORKAROUND
+void mdp_dma_s_update_lcd(struct msm_fb_data_type *mfd, MDPIBUF *iBuf)
+{
+#else
 static void mdp_dma_s_update_lcd(struct msm_fb_data_type *mfd)
 {
 	MDPIBUF *iBuf = &mfd->ibuf;
+#endif
 	int mddi_dest = FALSE;
 	uint32 outBpp = iBuf->bpp;
 	uint32 dma_s_cfg_reg;
@@ -141,6 +146,28 @@ static void mdp_dma_s_update_lcd(struct msm_fb_data_type *mfd)
 void mdp_dma_s_update(struct msm_fb_data_type *mfd)
 {
 	down(&mfd->dma->mutex);
+#ifdef CONFIG_MSM_FB_TTY_WORKAROUND
+	if(mfd && mfd->panel_power_on) {
+		if (!mfd->dma->busy) {
+			down(&mfd->sem);
+			mdp_enable_irq(MDP_DMA_S_TERM);
+			if (mfd->panel_info.type == MDDI_PANEL)
+				mdp_enable_irq(MDP_DMA_S_TERM);
+			else
+				mdp_enable_irq(MDP_DMA_E_TERM);
+			mfd->dma->busy = TRUE;
+			mdp_dma_s_update_lcd(mfd, &mfd->ibuf);
+			up(&mfd->sem);
+		}
+		else {
+			struct msm_fb_dma_task *tsk = kzalloc(sizeof(
+				struct msm_fb_dma_task), GFP_ATOMIC);
+			tsk->mfd = mfd;
+			tsk->ibuf = mfd->ibuf;
+			list_add_tail(&tsk->list, &msm_fb_dma_task_list);
+		}
+	}
+#else
 	if ((mfd) && (!mfd->dma->busy) && (mfd->panel_power_on)) {
 		down(&mfd->sem);
 		mdp_enable_irq(MDP_DMA_S_TERM);
@@ -167,5 +194,6 @@ void mdp_dma_s_update(struct msm_fb_data_type *mfd)
 			complete(&mfd->pan_comp);
 		}
 	}
+#endif
 	up(&mfd->dma->mutex);
 }
diff --git a/drivers/video/msm/msm_fb.c b/drivers/video/msm/msm_fb.c
index 14b1860..d355813 100644
--- a/drivers/video/msm/msm_fb.c
+++ b/drivers/video/msm/msm_fb.c
@@ -1025,8 +1025,10 @@ static int msm_fb_register(struct msm_fb_data_type *mfd)
 	mfd->sw_refreshing_enable = TRUE;
 	mfd->panel_power_on = FALSE;
 
+#if !defined(CONFIG_MSM_FB_TTY_WORKAROUND)
 	mfd->pan_waiting = FALSE;
 	init_completion(&mfd->pan_comp);
+#endif
 	init_completion(&mfd->refresher_comp);
 	init_MUTEX(&mfd->sem);
 
diff --git a/drivers/video/msm/msm_fb.h b/drivers/video/msm/msm_fb.h
index 2395cb2..2e1e38a 100644
--- a/drivers/video/msm/msm_fb.h
+++ b/drivers/video/msm/msm_fb.h
@@ -63,6 +63,10 @@
 #define MFD_KEY  0x11161126
 #define MSM_FB_MAX_DEV_LIST 32
 
+#ifdef CONFIG_MSM_FB_TTY_WORKAROUND
+extern struct list_head msm_fb_dma_task_list;
+#endif
+
 struct disp_info_type_suspend {
 	boolean op_enable;
 	boolean sw_refreshing_enable;
@@ -91,12 +95,16 @@ struct msm_fb_data_type {
 #endif
 
 	MDPIBUF ibuf;
+#if !defined(CONFIG_MSM_FB_TTY_WORKAROUND)
 	boolean ibuf_flushed;
+#endif
 	struct timer_list refresh_timer;
 	struct completion refresher_comp;
 
+#if !defined(CONFIG_MSM_FB_TTY_WORKAROUND)
 	boolean pan_waiting;
 	struct completion pan_comp;
+#endif
 
 	/* vsync */
 	boolean use_mdp_vsync;
@@ -167,6 +175,12 @@ struct msm_fb_data_type {
 	struct pm_qos_request_list *pm_qos_req;
 };
 
+struct msm_fb_dma_task {
+	struct msm_fb_data_type* mfd;
+	MDPIBUF ibuf;
+	struct list_head list;
+};
+
 struct dentry *msm_fb_get_debugfs_root(void);
 void msm_fb_debugfs_file_create(struct dentry *root, const char *name,
 				u32 *var);
-- 
1.7.0.4

Re: [PATCH] [Streak] Add workaround for TTY kernel OOPS at the cost of performance.

[Daniel Walker]

On Fri, 2010-10-01 at 00:42 +0200, Tomasz Sterna wrote:
> The current framebuffer driver oopses when used as a console (kernel
> parameter: console=tty ).
> Here is a patch that makes it work - at the cost of performance.
> 
> Signed-off-by: Bradley Smith <brad@brad-smith.co.uk>
> (cherry picked from commit 28d06a6366c851c6e0c5b954353bf82cb641d4e7)

Your submitting this for Bradley? If so you need to have a line like
this at the top,

From: Bradley Smith <brad@brad-smith.co.uk>

That denotes that your not the author of the commit..

Also this is against v2.6.36-rcX right ?

> ---
>  drivers/video/msm/Kconfig     |    4 ++++
>  drivers/video/msm/mdp.c       |   20 ++++++++++++++++++++
>  drivers/video/msm/mdp.h       |    3 +++
>  drivers/video/msm/mdp_dma.c   |   15 +++++++++++++++
>  drivers/video/msm/mdp_dma_s.c |   28 ++++++++++++++++++++++++++++
>  drivers/video/msm/msm_fb.c    |    2 ++
>  drivers/video/msm/msm_fb.h    |   14 ++++++++++++++
>  7 files changed, 86 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/video/msm/Kconfig b/drivers/video/msm/Kconfig
> index e887a2d..cff8435 100644
> --- a/drivers/video/msm/Kconfig
> +++ b/drivers/video/msm/Kconfig
> @@ -14,3 +14,7 @@ config FB_MSM_LCDC
>  	depends on FB_MSM && MSM_MDP31
>  	default y
>  
> +config MSM_FB_TTY_WORKAROUND
> +	bool "Workaround TTY kernel OOPS at the cost of performance"
> +	depends on FB_MSM
> +	default n

We can't have this selectable , especially if the kernel will OOPS if
it's off ..

I need a better description of the problem. What was the oops? This
looks DMA related, is that accurate and could you expand on why DMA was
causing a problem?

Daniel

-- 

Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: [PATCH] [Streak] Add workaround for TTY kernel OOPS at the cost of performance.

[Tomasz Sterna]

On czw, 2010-09-30 at 16:04 -0700, Daniel Walker wrote: 
> > Signed-off-by: Bradley Smith <brad@brad-smith.co.uk>
> > (cherry picked from commit 28d06a6366c851c6e0c5b954353bf82cb641d4e7)
> 
> Your submitting this for Bradley? If so you need to have a line like
> this at the top,

I am not exactly _submitting_ it. Bradley said this is a dirty
workaround and needs a real fix instead. This change just gave us
working kernel console.
I am rather pointing the problem and sharing the workaround.


> From: Bradley Smith <brad@brad-smith.co.uk>
> That denotes that your not the author of the commit..

I'm pretty new to git - sorry.
Yes, Bradley is the author of the patch. I only ported it to msm-2.6.35
from his android-msm-2.6.32 tree.

> Also this is against v2.6.36-rcX right ?

This is against msm-2.6.35 
> > +config MSM_FB_TTY_WORKAROUND
> > +	bool "Workaround TTY kernel OOPS at the cost of performance"
> > +	depends on FB_MSM
> > +	default n
> 
> We can't have this selectable , especially if the kernel will OOPS if
> it's off ..

As I mentioned - this is only a workaround of the problem. We turn it on
while debugging kernel boot, and off once it is working to get a better
performing fbcon for X11.


> I need a better description of the problem. What was the oops? This
> looks DMA related, is that accurate and could you expand on why DMA was
> causing a problem?

If you start an android-msm-2.6.29 or msm-2.6.35 (these are the ones I
tested) with MSM_FB driver compiled in and use 'console=tty' kernel
commandline option, kernel starts with proper console output on screen
and oopses in the middle of the process.
I don't know the exact nature of the problem. Maybe Brad would shed some
light.

If you're unable to reproduce the problem, I will rebuild the kernel
without the workaround and retype the OOPS message for you.

Re: [PATCH] [Streak] Add workaround for TTY kernel OOPS at the cost of performance.

[Daniel Walker]

On Fri, 2010-10-01 at 10:52 +0200, Tomasz Sterna wrote:

> If you start an android-msm-2.6.29 or msm-2.6.35 (these are the ones I
> tested) with MSM_FB driver compiled in and use 'console=tty' kernel
> commandline option, kernel starts with proper console output on screen
> and oopses in the middle of the process.
> I don't know the exact nature of the problem. Maybe Brad would shed some
> light.
> 
> If you're unable to reproduce the problem, I will rebuild the kernel
> without the workaround and retype the OOPS message for you.

I don't have access to Streak hardware, and I've not talked to anyone
that does. But if you give us the OOPS message we can try to figure out
what's going on..

BTW did Dell release a kernel for Streak? They might already have a
workaround in their kernel.

Daniel

-- 
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.

Re: [PATCH] [Streak] Add workaround for TTY kernel OOPS at the cost of performance.

[Tomasz Sterna]

Dnia 2010-10-01, pią o godzinie 08:47 -0700, Daniel Walker pisze:
> I don't have access to Streak hardware, and I've not talked to anyone
> that does. But if you give us the OOPS message we can try to figure
> out what's going on..

Do you say, that on other Snapdragon hardware msm-2.6.35 tree with
console=tty works fine and there is no error?


> BTW did Dell release a kernel for Streak? They might already have a
> workaround in their kernel. 

Yes they did: http://opensource.dell.com/releases/streak/
(This is where I ported the changes and drivers from)
But this kernels have exactly the same problem.

framebuffer driver works fine accessed from userspace, but breaks on
displaying kernel boot messages. Right after the message:
Console: switching to colour frame buffer device 60x50

I will try to retype the OOPS message, but it's hard - it scrolls out of
the screen ;-)

Re: [PATCH] [Streak] Add workaround for TTY kernel OOPS at the cost of performance.

[Daniel Walker]

On Fri, 2010-10-01 at 22:07 +0200, Tomasz Sterna wrote:
> Dnia 2010-10-01, pią o godzinie 08:47 -0700, Daniel Walker pisze:
> > I don't have access to Streak hardware, and I've not talked to anyone
> > that does. But if you give us the OOPS message we can try to figure
> > out what's going on..
> 
> Do you say, that on other Snapdragon hardware msm-2.6.35 tree with
> console=tty works fine and there is no error?

AFAIK .. I have a G1 which displays console messages to the framebuffer,
(using the mainline framebuffer driver ) I didn't put in console=tty
tho.

> 
> > BTW did Dell release a kernel for Streak? They might already have a
> > workaround in their kernel. 
> 
> Yes they did: http://opensource.dell.com/releases/streak/
> (This is where I ported the changes and drivers from)
> But this kernels have exactly the same problem.

Ok, great.

> framebuffer driver works fine accessed from userspace, but breaks on
> displaying kernel boot messages. Right after the message:
> Console: switching to colour frame buffer device 60x50
> 
> I will try to retype the OOPS message, but it's hard - it scrolls out of
> the screen ;-)

you could take a picture, assuming you have a camera.

Daniel

-- 
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.

Re: [PATCH] [Streak] Add workaround for TTY kernel OOPS at the cost of performance.

[Tomasz Sterna]

Dnia 2010-10-01, pią o godzinie 08:47 -0700, Daniel Walker pisze:
> But if you give us the OOPS message we can try to figure out
> what's going on.. 

[...] 
Console: switching to colour frame buffer device 60x50
BUG: scheduling while atomic swapper/1/0x00000002
Modules linked in:
[<c0032740>] (unwind_backtrace+0x0/0xe4) from [<c04104e8>] (schedule+0x68/0x330)
[<c04104e8>] (schedule+0x68/0x330) from [<c0410d98>] (schedule_timeout+0x18/0x1ec)
[<c0410d98>] (schedule_timeout+0x18/0x1ec) from [<c0410bc8>] (wait_for_common+0xf4/0x1ac)
[<c0410bc8>] (wait_for_common+0xf4/0x1ac) from [<c0410cd0>] (wait_for_completion_killable+0x18/0x24)
[<c0410cd0>] (wait_for_completion_killable+0x18/0x24) from 
[<c0081650>] (notifier_call_chain+0x38/0x68) from [<c0081850>] (__blocking_notifier_callchain+0x48/0x5c)
[<c0081850>] (__blocking_notifier_callchain+0x48/0x5c) from ...
then it gets "scrambled", but I see the following functions:
device_attach
bus_probe_device
driver_probe_device
bus_for_each_drv
platform_drv_probe
schedule
fbcon_takeover
device_attach

I guess the 'scheduling while atomic swapper' happens in fbcon_takeover()
Right?

P.S. source of oops msg is here: http://www.flickr.com/photos/smoku/5042198623/ ;-)

Re: [PATCH] [Streak] Add workaround for TTY kernel OOPS at the cost of performance.

[Bradley Smith]

On 1 October 2010 09:52, Tomasz Sterna <tomek@xiaoka.com> wrote:
>
> On czw, 2010-09-30 at 16:04 -0700, Daniel Walker wrote:
> > > Signed-off-by: Bradley Smith <brad@brad-smith.co.uk>
> > > (cherry picked from commit 28d06a6366c851c6e0c5b954353bf82cb641d4e7)
> >
> > Your submitting this for Bradley? If so you need to have a line like
> > this at the top,
>
> I am not exactly _submitting_ it. Bradley said this is a dirty
> workaround and needs a real fix instead. This change just gave us
> working kernel console.
> I am rather pointing the problem and sharing the workaround.
>
>
> > From: Bradley Smith <brad@brad-smith.co.uk>
> > That denotes that your not the author of the commit..
>
> I'm pretty new to git - sorry.
> Yes, Bradley is the author of the patch. I only ported it to msm-2.6.35
> from his android-msm-2.6.32 tree.
>
> > Also this is against v2.6.36-rcX right ?
>
> This is against msm-2.6.35
> > > +config MSM_FB_TTY_WORKAROUND
> > > +   bool "Workaround TTY kernel OOPS at the cost of performance"
> > > +   depends on FB_MSM
> > > +   default n
> >
> > We can't have this selectable , especially if the kernel will OOPS if
> > it's off ..
>
> As I mentioned - this is only a workaround of the problem. We turn it on
> while debugging kernel boot, and off once it is working to get a better
> performing fbcon for X11.
>
>
> > I need a better description of the problem. What was the oops? This
> > looks DMA related, is that accurate and could you expand on why DMA was
> > causing a problem?
>
> If you start an android-msm-2.6.29 or msm-2.6.35 (these are the ones I
> tested) with MSM_FB driver compiled in and use 'console=tty' kernel
> commandline option, kernel starts with proper console output on screen
> and oopses in the middle of the process.
> I don't know the exact nature of the problem. Maybe Brad would shed some
> light.
>
> If you're unable to reproduce the problem, I will rebuild the kernel
> without the workaround and retype the OOPS message for you.
>

I can't say I'm particularly happy about this.. Firstly Tomasz, please
do NOT submit my code/patches without consulting me first, secondly, I
strongly suggest you don't submit patches that you don't have a clue
what they do, or how they work. If you knew what this patch did, you'd
know it was most certainty not suitable for upstream.

Daniel, there are a number of problems with this patch, it's not even
for the main linux-msm tree, it supposed to be applied to the Qualcomm
froyo android msm tree (i.e.
https://www.codeaurora.org/gitweb/quic/la/?p=kernel/msm.git;a=shortlog;h=refs/heads/froyo),
and as you've probably gathered, it's in no way suitable for mainline
or the msm tree. The reason being, it will hugely degrade performance
of the MSM framebuffer.

Whilst I'm here, I might as well explain what the problem actually is.
A lot of the MSM fb functions end up calling the msm_fb_pan_display
function, this in turn then calls the functions to do the DMA
transfers to the display, and these DMA functions wait for the
transfer to complete. This works fine if you are using it as a normal
framebuffer, but when you try and use it as a TTY, the framebuffer
functions get called when spinlocks are held, i.e. in atomic context,
so of course waiting for the DMA transfer to complete is a nono.

As far as I can tell, the best way to fix this would be to have the
dma functions do the transfers asynchronously. This patch was an
initial attempt at this, but I was having problems with the dirty
region being incorrect, hence I just forced it to refresh the whole
display (hence unsuitability for unstream), this was just a quick hack
to get the TTY working, after all, I only needed it for development.

Feel free to use the code in this patch to have a look at what is
going on, but as I said, this is not going to apply against the
linux-msm tree cleanly. I'm also not /certain/ that this problem even
exists in the linux-msm tree, since I've never actually tried it, (the
msm_fb code is quite different between the android msm tree and this
one). A quick look at the code suggested it would however.

Also, this problem is not streak specific (nor have Dell addressed it,
why would they want people using the TTY?), it's going to happen on
anything that tries to use msm_fb as a TTY.

If you receive any patches in my name in the future, please could you
contact me first, since if I haven't submitted them myself, the the
likelihood is they are not supposed to go upstream.

Regards,
Bradley Smith

Bradley Smith                                     brad@brad-smith.co.uk
Debian GNU/Linux Developer                         bradsmith@debian.org
GPG: 0xC718D347       D201 7274 2FE1 A92A C45C EFAB 8F70 629A C718 D347