On 10/5/2010 4:05 PM, Felipe Contreras wrote:
On Tue, Oct 5, 2010 at 11:09 PM, Ramirez Luna,
Omar<omar.ramirez@xxxxxx> wrote:
Felipe Contreras wrote:
...
Hmmm, because my other option was to move the reserved memory
outside the kernel, but that involves specifying bootargs again and
using dma_alloc_coherent with their restrictions.
Huh, if there's no contiguous memory region reserved, then the
driver is doing dma_alloc_coherent already, but that fails
(apparently 5M is too much). Plus I've read that dma_alloc_coherent
is "precious"; shouldn't be used for that.
Initially bridge was using the memory on the upper part of the RAM,
specifying in bootargs mem=MAX-6MB, so reintroducing the parameter works
fine; dma_alloc_coherent was also used when bridge was compiled as
built-in the kernel but now it is not working either.
So, first I wanted to try reserving some region with mem=X boot
param, but that solution is ugly. If that worked, then I wanted ti
see if flushing each time we access that shm memory block works, but
in the process I wanted to reorganize the whole initialization code
because right now it's very ugly and confusing.
Yes, I can help with that, I'm sending a patch to reintroduce the
parameter for phys_mempool_base, however we need to remove or disable
the memblock functions related with dspbridge. I was thinking of a
menuconfig parameter to specify mempool base for built-in compilation.
Regards,
Omar
--
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
