On Wed, 6 Jul 2011, Arnd Bergmann wrote:
> On Wednesday 06 July 2011 21:10:07 Nicolas Pitre wrote:
> > If you get a highmem page, because the cache is VIPT, that page might
> > still be cached even if it wasn't mapped. With a VIVT cache we must
> > flush the cache
On Wed, 6 Jul 2011, Arnd Bergmann wrote:
> On Wednesday 06 July 2011, Russell King - ARM Linux wrote:
> > On Wed, Jul 06, 2011 at 04:51:49PM +0200, Arnd Bergmann wrote:
> > > On Wednesday 06 July 2011, Russell King - ARM Linux wrote:
> > >
> > > I don't see how. The pages get allocated from an un
On Wed, 6 Jul 2011, Russell King - ARM Linux wrote:
> Another issue is that when a platform has restricted DMA regions,
> they typically don't fall into the highmem zone. As the dmabounce
> code allocates from the DMA coherent allocator to provide it with
> guaranteed DMA-able memory, that would
On Sat, 26 Feb 2011, Kyungmin Park wrote:
> On Sat, Feb 26, 2011 at 2:22 AM, Linus Walleij
> wrote:
> > 2011/2/24 Edward Hervey :
> >
> >> What *needs* to be solved is an API for data allocation/passing at the
> >> kernel level which v4l2,omx,X,GL,vdpau,vaapi,... can use and that
> >> userspace
On Wed, 12 Jan 2011, Marek Szyprowski wrote:
> I understand that modifying L1 page tables is definitely not a proper way of
> handling this. It simply costs too much. But what if we consider that the DMA
> memory can be only allocated from a specific range of the system memory?
> Assuming that thi
