On 15 June 2011 16:39, Larry Bassel <lbassel@xxxxxxxxxxxxxx> wrote: > On 15 Jun 11 10:36, Marek Szyprowski wrote: >> Hello, >> >> On Tuesday, June 14, 2011 10:42 PM Arnd Bergmann wrote: >> >> > On Tuesday 14 June 2011 20:58:25 Zach Pfeffer wrote: >> > > I've seen this split bank allocation in Qualcomm and TI SoCs, with >> > > Samsung, that makes 3 major SoC vendors (I would be surprised if >> > > Nvidia didn't also need to do this) - so I think some configurable >> > > method to control allocations is necessarily. The chips can't do >> > > decode without it (and by can't do I mean 1080P and higher decode is >> > > not functionally useful). Far from special, this would appear to be >> > > the default. > > We at Qualcomm have some platforms that have memory of different > performance characteristics, some drivers will need a way of > specifying that they need fast memory for an allocation (and would prefer > an error if it is not available rather than a fallback to slower > memory). It would also be bad if allocators who don't need fast > memory got it "accidentally", depriving those who really need it. I think this statement actually applies to all the SoCs that are coming out now and in the future from TI, Samsung, Nvidia, Freescale, ST Ericsson and others. It seems that in all cases users will want to: 1. Allocate memory with a per-SoC physical memory mapping policy that is usually manually specified, i.e. use this physical memory bank set for this allocation or nothing. 2. Be able to easily pass a token to this memory between various userspace processes and the kernel. 3. Be able to easily and explicitly access attributes of an allocation from all contexts. 4. Be able to save and reload this memory without giving up the virtual address allocation. In essence they want a architectural independent map object that can bounce around the system with a unique handle. >> > >> > Thanks for the insight, that's a much better argument than 'something >> > may need it'. Are those all chips without an IOMMU or do we also >> > need to solve the IOMMU case with split bank allocation? >> > >> > I think I'd still prefer to see the support for multiple regions split >> > out into one of the later patches, especially since that would defer >> > the question of how to do the initialization for this case and make >> > sure we first get a generic way. >> > >> > You've convinced me that we need to solve the problem of allocating >> > memory from a specific bank eventually, but separating it from the >> > one at hand (contiguous allocation) should help getting the important >> > groundwork in at first. >> > >> > The possible conflict that I still see with per-bank CMA regions are: >> > >> > * It completely destroys memory power management in cases where that >> > is based on powering down entire memory banks. >> >> I don't think that per-bank CMA regions destroys memory power management >> more than the global CMA pool. Please note that the contiguous buffers >> (or in general dma-buffers) right now are unmovable so they don't fit >> well into memory power management. > > We also have platforms where a well-defined part of the memory > can be powered off, and other parts can't (or won't). We need a way > to steer the place allocations come from to the memory that won't be > turned off (so that CMA allocations are not an obstacle to memory > hotremove). > >> >> Best regards >> -- >> Marek Szyprowski >> Samsung Poland R&D Center >> >> >> >> _______________________________________________ >> Linaro-mm-sig mailing list >> Linaro-mm-sig@xxxxxxxxxxxxxxxx >> http://lists.linaro.org/mailman/listinfo/linaro-mm-sig > > Larry Bassel > > -- > Sent by an employee of the Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
