Re: [PATCHv2] arm64: Add atomic pool for non-coherent and CMA allocaitons.

[Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>]

On Wed, Jun 04, 2014 at 01:30:18AM +0100, Laura Abbott wrote:
> On 6/3/2014 6:28 AM, Will Deacon wrote:
> > Hi Laura,
> > 
> > On Mon, Jun 02, 2014 at 09:03:52PM +0100, Laura Abbott wrote:
> >> Neither CMA nor noncoherent allocations support atomic allocations.
> >> Add a dedicated atomic pool to support this.
> >>
> >> Change-Id: I46c8fdffe5e0687403d42b37643137c8cf344259
> >> Signed-off-by: Laura Abbott <lauraa-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> >> ---
> >>
> >> v2: Various bug fixes pointed out by David and Ritesh (CMA dependency, swapping
> >> coherent, noncoherent). I'm still not sure how to address the devicetree
> >> suggestion by Will [1][2]. I added the devicetree mailing list this time around
> >> to get more input on this.
> >>
> >> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/249180.html
> >> [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/249528.html
> > 
> > Perhaps that can be done later then, since from what you're saying, we need
> > the command-line option either way? Have you looked at how this fits in with
> > the iommu-helper work from Ritesh? We could put the parameter parsing in
> > there too.
> > 
> 
> This doesn't seem to overlap with Ritesh's work. The atomic mapping is still
> handled in the arm specific code so I assume it would be handled in the arm64
> specific code as well. Another question might be is if it would be useful to
> make the atomic code common somehow between arm and arm64.

Yeah, that's what I was alluding to. The more of this code that can be
shared between architectures, the better.

Will
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html