Hi Omar, On Thursday 07 October 2010 07:45:36 Omar Ramirez Luna wrote: > tidspbridge driver uses a block of memory denominated SHared Memory > to store info & communicate with DSP, this SHM needs to be physically > contiguous and non-cacheable, There are non-cacheable mappings, but there's no such thing as non-cacheable memory. Does the MPU mapping for that SHM block really needs to be non- cacheable, your could you instead flush the cache after writing to it (performance issues might be involved, I don't know the details about that SHM usage) ? > to achieve the latter the driver ioremaps > the memory reserved to be SHM, this will trigger a warning if the > memory is under kernel control (because it creates another set of > mapping attributes, for the same memory area). > > For now this can be avoided if a portion of memory (6MB) is left out > of kernel control (using bootarg attribute mem=) where tidspbridge > driver can make use of the memory and ioremap it without above > restriction. > > Parameter has precedence over memblock allocator for shared memory. > > i.e.: on a system with 256MB > > set 'bootargs mem=250M ...' > > cat /proc/iomem > ... > 80000000-8f9fffff : System RAM > > So driver needs to be installed with: > > insmod bridgedriver.ko phys_mempool_base=0x8FA00000 > > Same rationale applies for the menuconfig option. > > Signed-off-by: Omar Ramirez Luna <omar.ramirez@xxxxxx> -- Regards, Laurent Pinchart -- 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
