[RFC] omap4-fb: use uncached screen_base

Alexander Aring alex.aring at gmail.com
Mon Apr 15 08:20:44 EDT 2013


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.


More information about the barebox mailing list