On 14 June 2011 12:01, Daniel Stone <dani...@collabora.com> wrote: > Hi, > > On Tue, Jun 14, 2011 at 06:03:00PM +0200, Arnd Bergmann wrote: >> On Tuesday 14 June 2011, Michal Nazarewicz wrote: >> > On Tue, 14 Jun 2011 15:49:29 +0200, Arnd Bergmann <a...@arndb.de> wrote: >> > > Please explain the exact requirements that lead you to defining multiple >> > > contexts. >> > >> > Some devices may have access only to some banks of memory. Some devices >> > may use different banks of memory for different purposes. >> >> For all I know, that is something that is only true for a few very special >> Samsung devices, and is completely unrelated of the need for contiguous >> allocations, so this approach becomes pointless as soon as the next >> generation of that chip grows an IOMMU, where we don't handle the special >> bank attributes. Also, the way I understood the situation for the Samsung >> SoC during the Budapest discussion, it's only a performance hack, not a >> functional requirement, unless you count '1080p playback' as a functional >> requirement.
Coming in mid topic... 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. > Hm, I think that was something similar but not quite the same: talking > about having allocations split to lie between two banks of RAM to > maximise the read/write speed for performance reasons. That's something > that can be handled in the allocator, rather than an API constraint, as > this is. > > Not that I know of any hardware which is limited as such, but eh. > > Cheers, > Daniel > > _______________________________________________ > Linaro-mm-sig mailing list > linaro-mm-...@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-mm-sig > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
