[RFC] omap4-fb: use uncached screen_base

[RFC] omap4-fb: use uncached screen_base

[Jan Weitzel]

If the buffer is cached the image on the LCD is broken. Only some small
lines on the last rows. Flushing the cache "repairs" the image.

Is remap_range the right way to get a non cached buffer?
This patch only covers prealloc_screen, not dynamic
If the buffer is dynamic, is the use of dma_alloc_coherent right? Or should
the buffer remaped again if freed?
---
 drivers/video/omap4.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/video/omap4.c b/drivers/video/omap4.c
index 5642f25..1ade988 100644
--- a/drivers/video/omap4.c
+++ b/drivers/video/omap4.c
@@ -32,6 +32,8 @@
 #include <mach/omap4-silicon.h>
 #include <mach/omap4-fb.h>
 
+#include <asm/mmu.h>
+
 #include "omap4.h"
 
 struct omap4fb_device {
@@ -489,6 +491,9 @@ static int omap4fb_probe(struct device_d *dev)
 		fbi->prealloc_screen.addr =
 				(void __iomem *)pdata->screen->start;
 		fbi->prealloc_screen.size = resource_size(pdata->screen);
+		remap_range(fbi->prealloc_screen.addr,
+			fbi->prealloc_screen.size,
+			mmu_get_pte_uncached_flags());
 	}
 
 	omap4fb_reset(fbi);
-- 
1.7.0.4


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [RFC] omap4-fb: use uncached screen_base

[Sascha Hauer]

Hi Jan,

On Thu, Apr 11, 2013 at 01:28:19PM +0200, Jan Weitzel wrote:
> If the buffer is cached the image on the LCD is broken. Only some small
> lines on the last rows. Flushing the cache "repairs" the image.
> 
> Is remap_range the right way to get a non cached buffer?

I think using this is ok for now, at least when the driver is ARM
specific, which the omap fb driver is. We do not have a propert API
for this kind of stuff and I currently have no idea how such an API
would look like.

You should make sure though that pdata->screen->start and the screen
size are page aligned.

> This patch only covers prealloc_screen, not dynamic
> If the buffer is dynamic, is the use of dma_alloc_coherent right?

correct.

> Or should
> the buffer remaped again if freed?

ideally it should, at least when the screen is passed via platform data.
Anyway, when you pass it via platform_data then you normally do it to
preserve the screen during kernel start, so I wouldn't free it in this
case.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [RFC] omap4-fb: use uncached screen_base

[Alexander Aring]

Hi,

On Thu, Apr 11, 2013 at 01:28:19PM +0200, Jan Weitzel wrote:
> If the buffer is cached the image on the LCD is broken. Only some small
> lines on the last rows. Flushing the cache "repairs" the image.
> 
> Is remap_range the right way to get a non cached buffer?
> This patch only covers prealloc_screen, not dynamic
> If the buffer is dynamic, is the use of dma_alloc_coherent right? Or should
> the buffer remaped again if freed?
> ---
>  drivers/video/omap4.c |    5 +++++

Sry, where is this file in the current barebox version?
It's something which is in wip?

Regards
Alex

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [RFC] omap4-fb: use uncached screen_base

[Alexander Aring]

Hi,

On Fri, Apr 12, 2013 at 05:03:53PM +0200, Sascha Hauer wrote:
> Hi Jan,
> 
> On Thu, Apr 11, 2013 at 01:28:19PM +0200, Jan Weitzel wrote:
> > If the buffer is cached the image on the LCD is broken. Only some small
> > lines on the last rows. Flushing the cache "repairs" the image.
> > 
> > Is remap_range the right way to get a non cached buffer?
> 
> I think using this is ok for now, at least when the driver is ARM
> specific, which the omap fb driver is. We do not have a propert API
> for this kind of stuff and I currently have no idea how such an API
> would look like.
> 
> You should make sure though that pdata->screen->start and the screen
> size are page aligned.
> 
> > This patch only covers prealloc_screen, not dynamic
> > If the buffer is dynamic, is the use of dma_alloc_coherent right?
> 
> correct.
> 
> > Or should
> > the buffer remaped again if freed?
> 
> ideally it should, at least when the screen is passed via platform data.
> Anyway, when you pass it via platform_data then you normally do it to
> preserve the screen during kernel start, so I wouldn't free it in this
> case.
> 
maybe we check the page table flags on freeing a resource and restore
them to the "defaults"..., but we need to do this in an api which works
for all architectures.

Regards
Alex

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox