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@xxxxxxxxxxxxxx> > >> --- > >> > >> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
