On Fri, Jul 19, 2019 at 2:09 AM Daniel Vetter wrote:
>
> On Tue, Jul 16, 2019 at 09:42:15AM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > Since there is no real device associated with vgem, it is impossible to
> > end up with appropriate dev->dma_ops, meaning that we have no way to
> > inva
On Tue, Jul 16, 2019 at 09:42:15AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Since there is no real device associated with vgem, it is impossible to
> end up with appropriate dev->dma_ops, meaning that we have no way to
> invalidate the shmem pages allocated by vgem. So, at least on platform
On Tue, Jul 16, 2019 at 10:01 AM Chris Wilson wrote:
>
> Quoting Rob Clark (2019-07-16 17:42:15)
> > From: Rob Clark
> >
> > Since there is no real device associated with vgem, it is impossible to
> > end up with appropriate dev->dma_ops, meaning that we have no way to
> > invalidate the shmem pa
Quoting Rob Clark (2019-07-16 17:42:15)
> From: Rob Clark
>
> Since there is no real device associated with vgem, it is impossible to
> end up with appropriate dev->dma_ops, meaning that we have no way to
> invalidate the shmem pages allocated by vgem. So, at least on platforms
> without drm_cfl
From: Rob Clark
Since there is no real device associated with vgem, it is impossible to
end up with appropriate dev->dma_ops, meaning that we have no way to
invalidate the shmem pages allocated by vgem. So, at least on platforms
without drm_cflush_pages(), we end up with corruption when cache li
