[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAK=WgbaM-3_rsJ=Tq_YK-HboAUxxpvgG6iFSYafuTbKE7Ss1Hg@mail.gmail.com>
Date: Fri, 1 Jun 2012 11:04:40 +0300
From: Ohad Ben-Cohen <ohad@...ery.com>
To: sjur.brandeland@...ricsson.com
Cc: Loic PALLARDY <loic.pallardy@...ricsson.com>,
Ludovic BARRE <ludovic.barre@...ricsson.com>,
linux-kernel@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
Linus Walleij <linus.walleij@...aro.org>,
Sjur Brændeland <sjurbren@...il.com>
Subject: Re: [RFC] remoteproc: Add custom STE-modem firmware loader.
Hi Sjur,
On Thu, May 31, 2012 at 5:12 PM, <sjur.brandeland@...ricsson.com> wrote:
> OK, here is an early version of the STE-Modem firmware loader.
> Haven't done the Makefile and Kconfig updates yet though.
Thanks for posting this! I'll find the time to review this asap.
> But I have one issue, I need the firmware image to be allocated
> at the start of shared memory. But the vring gets allocated first.
> I could work around this by calling dma_mark_declared_memory_occupied(),
> from the driver and then call dma_release_from_coherent() before booting.
> But this feels like a hack. Any ideas on how to handle this properly?
One proper way to handle this is to allow platforms to provide
separate memory regions for separate purposes by binding each memory
region to a different per-purpose subdevices.
This way remoteproc could then use the right device whenever it
invokes the DMA API, and memory will then always be allocated from the
expected region, without being affected by different allocation
orders.
Ludovic was working on a patch that does exactly that, and the zynq
folks also need it, so the timing of your request looks perfect :)
Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists