On 14 June 2011 12:01, Daniel Stone [off-list ref] wrote:

Hi,

On Tue, Jun 14, 2011 at 06:03:00PM +0200, Arnd Bergmann wrote:

quoted

On Tuesday 14 June 2011, Michal Nazarewicz wrote:

quoted

On Tue, 14 Jun 2011 15:49:29 +0200, Arnd Bergmann [off-list ref] wrote:

quoted

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-sig at lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-mm-sig