Let's CC Russell for this one. On Wed, Aug 25, 2010 at 11:05 AM, Tomi Valkeinen <tomi.valkeinen@xxxxxxxxx> wrote: > 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". > > Tomi > > > -- > 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 > -- 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
