On 1 October 2010 09:52, Tomasz Sterna <tomek@xxxxxxxxxx> wrote: > > On czw, 2010-09-30 at 16:04 -0700, Daniel Walker wrote: > > > Signed-off-by: Bradley Smith <brad@xxxxxxxxxxxxxxxx> > > > (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@xxxxxxxxxxxxxxxx> > > 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@xxxxxxxxxxxxxxxx Debian GNU/Linux Developer bradsmith@xxxxxxxxxx GPG: 0xC718D347 D201 7274 2FE1 A92A C45C EFAB 8F70 629A C718 D347 -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
