On Sun, Aug 18, 2019 at 10:23 PM Christoph Hellwig wrote:
>
> On Fri, Aug 16, 2019 at 02:04:35PM -0700, Rob Clark wrote:
> > I don't disagree about needing an API to get uncached memory (or
> > ideally just something outside of the linear map). But I think this
> > is a separate problem.
> >
> >
On Fri, Aug 16, 2019 at 02:04:35PM -0700, Rob Clark wrote:
> I don't disagree about needing an API to get uncached memory (or
> ideally just something outside of the linear map). But I think this
> is a separate problem.
>
> What I was hoping for, for v5.4, is a way to stop abusing dma_map/sync
>
On Thu, Aug 15, 2019 at 10:53 AM Christoph Hellwig wrote:
>
> On Thu, Aug 15, 2019 at 06:54:39AM -0700, Rob Clark wrote:
> > On Wed, Aug 14, 2019 at 11:51 PM Christoph Hellwig wrote:
> > >
> > > As said before I don't think these low-level helpers are the
> > > right API to export, but even if th
Sorry if the style is messed up, replying from my phone.
Am 15.08.2019 20:27 schrieb Christoph Hellwig :
On Thu, Aug 15, 2019 at 06:21:00PM +, Koenig, Christian wrote:
> > (2) Add support for DMA_ATTR_NO_KERNEL_MAPPING to this new API instead
> > of dma_alloc_attrs. The initial differ
On Wed, Aug 14, 2019 at 11:51 PM Christoph Hellwig wrote:
>
> As said before I don't think these low-level helpers are the
> right API to export, but even if they did you'd just cover a tiny
> subset of the architectures.
Are you thinking instead something like:
void dma_sync_sg_for_{cpu,device}
On Thu, Aug 15, 2019 at 06:48:39PM +, Koenig, Christian wrote:
> Well, for the graphics case I absolutely need to keep the linear kernel
> mapping. Because for certain use cases the memory is accessed by the kernel
> all the time as well.
Then don't set DMA_ATTR_NO_KERNEL_MAPPING. At least
On Thu, Aug 15, 2019 at 06:21:00PM +, Koenig, Christian wrote:
> > (2) Add support for DMA_ATTR_NO_KERNEL_MAPPING to this new API instead
> > of dma_alloc_attrs. The initial difference with that flag is just
> > that we allow highmem, but in the future we could also unmap this
>
Am 15.08.19 um 19:53 schrieb Christoph Hellwig:
> On Thu, Aug 15, 2019 at 06:54:39AM -0700, Rob Clark wrote:
>> On Wed, Aug 14, 2019 at 11:51 PM Christoph Hellwig wrote:
>>> As said before I don't think these low-level helpers are the
>>> right API to export, but even if they did you'd just cover
On Thu, Aug 15, 2019 at 06:54:39AM -0700, Rob Clark wrote:
> On Wed, Aug 14, 2019 at 11:51 PM Christoph Hellwig wrote:
> >
> > As said before I don't think these low-level helpers are the
> > right API to export, but even if they did you'd just cover a tiny
> > subset of the architectures.
>
> Ar
As said before I don't think these low-level helpers are the
right API to export, but even if they did you'd just cover a tiny
subset of the architectures.
Also to distil the previous thread - if you remap memory to uncached
the helper to use is arch_dma_prep_coherent, which does a writeback+
inva
From: Rob Clark
This is a replacement for a previous patches[1] that was adding arm64
support for drm_clflush. I've also added a patch to solve a similar
cache issue in vgem.
The first few patches just export arch_sync_dma_for_*(). Possibly
instead the EXPORT_SYMBOL_GPL() should be somewere ce
11 matches
Mail list logo
