> -----Original Message----- > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > owner@xxxxxxxxxxxxxxx] On Behalf Of Tomi Valkeinen > Sent: Wednesday, August 25, 2010 1:36 PM > To: ext Mike Rapoport > Cc: Palande Ameya (Nokia-MS/Helsinki); linux-omap > Subject: Re: DSS2 broken with 36-rc1 > > Hi, > > On Mon, 2010-08-23 at 09:06 +0200, ext Mike Rapoport wrote: > > Mike Rapoport wrote: > > > From 81e9278ad27bc91be42105321e0e26d0be9e883b Mon Sep 17 00:00:00 2001 > > From: Mike Rapoport <mike@xxxxxxxxxxxxxx> > > Date: Mon, 23 Aug 2010 09:40:09 +0300 > > Subject: [PATCH] OMAP: DSS2: OMAPFB: use phys_to_virt for RAM mappings > > > > After commit 309caa9cc6ff39d261264ec4ff10e29489afc8f8 (ARM: Prohibit > > ioremap() on kernel managed RAM) it is impossible to ioremap SDRAM for > > the framebuffer. Use phys_to_virt for kernel managed RAM mapping and > > ioremap for other memory types > > Hmm. omapfb reserves/allocates the ram using memblock, and obviously > memory from memblock is "kernel managed RAM". What does it mean? The RAM > is already mapped? I guess so, if phys_to_virt() works. (I guess the > whole RAM is mapped automatically). With what caching? How can we get > writecombining for this memory? > > Looking at the description of "ARM: Prohibit ioremap() on kernel managed > RAM" it sounds to me that we cannot have writecombining for framebuffer > memory, if it's "kernel managed RAM". > This is indeed the case. One way to get write combining memory is to use dma_alloc_coherent in kernel space. You can reserve some memory outside the kernel memory map and directly mmap it to users pace with whatever attributes you interested in. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
