On Fri, Oct 16, 2020 at 12:04 PM John Stultz wrote:
>
> On Thu, Oct 8, 2020 at 4:51 AM Brian Starkey wrote:
> > On Sat, Oct 03, 2020 at 04:02:57AM +, John Stultz wrote:
> > > @@ -393,6 +424,16 @@ static int system_heap_allocate(struct dma_heap
> > > *heap,
> > > /* just
On Fri, Oct 16, 2020 at 12:03 PM John Stultz wrote:
> On Thu, Oct 8, 2020 at 4:51 AM Brian Starkey wrote:
> > On Sat, Oct 03, 2020 at 04:02:57AM +, John Stultz wrote:
> > > @@ -426,6 +487,16 @@ static int system_heap_create(void)
> > > if (IS_ERR(sys_heap))
> > > return
On Thu, Oct 8, 2020 at 4:51 AM Brian Starkey wrote:
> On Sat, Oct 03, 2020 at 04:02:57AM +, John Stultz wrote:
> > @@ -215,8 +236,12 @@ static void *system_heap_do_vmap(struct
> > system_heap_buffer *buffer)
> > struct page **pages = vmalloc(sizeof(struct page *) * npages);
> >
On Sat, Oct 03, 2020 at 04:02:57AM +, John Stultz wrote:
> This adds a heap that allocates non-contiguous buffers that are
> marked as writecombined, so they are not cached by the CPU.
>
> This is useful, as most graphics buffers are usually not touched
> by the CPU or only written into once
On Mon, Oct 5, 2020 at 6:45 AM Christoph Hellwig wrote:
>
> How is this going to deal with VIVT caches?
Hrm. That's a good question. I'm not sure I totally have my head
around it but, I guess we could make sure to call
invalidate_kernel_vmap_range() in begin_cpu_access() and
This adds a heap that allocates non-contiguous buffers that are
marked as writecombined, so they are not cached by the CPU.
This is useful, as most graphics buffers are usually not touched
by the CPU or only written into once by the CPU. So when mapping
the buffer over and over between devices,
