On Thu, Dec 6, 2018 at 8:38 PM Christoph Hellwig wrote:
>
> On Fri, Nov 30, 2018 at 10:46:04AM +0100, Daniel Vetter wrote:
> > > Being able to dip into CMA and maybe iommu coalescing if we want to
> > > get fancy is indeed the only reason for this API. If we just wanted
> > > to map pages we coul
On Fri, Nov 30, 2018 at 10:46:04AM +0100, Daniel Vetter wrote:
> > Being able to dip into CMA and maybe iommu coalescing if we want to
> > get fancy is indeed the only reason for this API. If we just wanted
> > to map pages we could already do that now with just a little bit
> > of boilerplate cod
On Sat, Dec 1, 2018 at 3:47 AM Rob Clark wrote:
>
> On Fri, Nov 30, 2018 at 9:05 PM Tomasz Figa wrote:
> >
> > On Thu, Nov 29, 2018 at 4:23 PM Tomasz Figa wrote:
> > >
> > > On Thu, Nov 29, 2018 at 12:03 PM Robin Murphy
> > > wrote:
> > > >
> > > > On 29/11/2018 19:57, Tomasz Figa wrote:
> > >
On Fri, Nov 30, 2018 at 9:05 PM Tomasz Figa wrote:
>
> On Thu, Nov 29, 2018 at 4:23 PM Tomasz Figa wrote:
> >
> > On Thu, Nov 29, 2018 at 12:03 PM Robin Murphy wrote:
> > >
> > > On 29/11/2018 19:57, Tomasz Figa wrote:
> > > > On Thu, Nov 29, 2018 at 11:40 AM Jordan Crouse
> > > > wrote:
> > >
On Thu, Nov 29, 2018 at 4:23 PM Tomasz Figa wrote:
>
> On Thu, Nov 29, 2018 at 12:03 PM Robin Murphy wrote:
> >
> > On 29/11/2018 19:57, Tomasz Figa wrote:
> > > On Thu, Nov 29, 2018 at 11:40 AM Jordan Crouse
> > > wrote:
> > >>
> > >> On Thu, Nov 29, 2018 at 01:48:15PM -0500, Rob Clark wrote:
On Thu, Nov 29, 2018 at 07:33:34PM +0100, Christoph Hellwig wrote:
> On Thu, Nov 29, 2018 at 06:09:05PM +0100, Daniel Vetter wrote:
> > What kind of abuse do you expect? It could very well be that gpu folks
> > call that "standard use case" ... At least on x86 with the i915 driver
> > we pretty muc
On Fri, Nov 30, 2018 at 10:35:27AM +0100, Daniel Vetter wrote:
> > Whether the cache maintenance operation needs to actually do anything
> > or not is a function of `dev`. We can have some devices that are
> > coherent with CPU caches, and some that are not, on the same system.
>
> So the thing is
On Thu, Nov 29, 2018 at 01:57:38PM -0500, Rob Clark wrote:
> On Thu, Nov 29, 2018 at 12:24 PM Tomasz Figa wrote:
> >
> > [CC Marek]
> >
> > On Thu, Nov 29, 2018 at 9:09 AM Daniel Vetter wrote:
> > >
> > > On Thu, Nov 29, 2018 at 5:57 PM Christoph Hellwig wrote:
> > > >
> > > > Note that one thin
On Thu, Nov 29, 2018 at 08:15:23PM -0500, Rob Clark wrote:
> As far as hiding cache ops behind iommu layer, I guess I'd been
> thinking more of just letting the drivers that want to bypass dma
> layer take things into their own hands.. tbh I think/assume/hope
> drm/msm is more the exception than th
On Thu, Nov 29, 2018 at 09:24:17AM -0800, Tomasz Figa wrote:
> [CC Marek]
>
> On Thu, Nov 29, 2018 at 9:09 AM Daniel Vetter wrote:
> >
> > On Thu, Nov 29, 2018 at 5:57 PM Christoph Hellwig wrote:
> > > On Thu, Nov 29, 2018 at 05:28:07PM +0100, Daniel Vetter wrote:
> > > > Just spend a bit of tim
On Thu, Nov 29, 2018 at 10:57 AM Christoph Hellwig wrote:
>
> On Thu, Nov 29, 2018 at 03:43:50PM +0100, Daniel Vetter wrote:
> > Yeah we had patches to add manual cache management code to drm, so we
> > don't have to abuse the dma streaming api anymore. Got shouted down.
> > Abusing the dma stream
On Thu, Nov 29, 2018 at 12:03 PM Robin Murphy wrote:
>
> On 29/11/2018 19:57, Tomasz Figa wrote:
> > On Thu, Nov 29, 2018 at 11:40 AM Jordan Crouse
> > wrote:
> >>
> >> On Thu, Nov 29, 2018 at 01:48:15PM -0500, Rob Clark wrote:
> >>> On Thu, Nov 29, 2018 at 10:54 AM Christoph Hellwig wrote:
> >
Hi Christoph,
On Thu, Nov 29, 2018 at 05:57:15PM +0100, Christoph Hellwig wrote:
>
> As for the buffer sharing: at least for the DMA API side I want to
> move the current buffer sharing users away from dma_alloc_coherent
> (and coherent dma_alloc_attrs users) and the remapping done in there
> req
On 29/11/2018 19:57, Tomasz Figa wrote:
On Thu, Nov 29, 2018 at 11:40 AM Jordan Crouse wrote:
On Thu, Nov 29, 2018 at 01:48:15PM -0500, Rob Clark wrote:
On Thu, Nov 29, 2018 at 10:54 AM Christoph Hellwig wrote:
On Thu, Nov 29, 2018 at 09:42:50AM -0500, Rob Clark wrote:
Maybe the thing we
On Thu, Nov 29, 2018 at 11:40 AM Jordan Crouse wrote:
>
> On Thu, Nov 29, 2018 at 01:48:15PM -0500, Rob Clark wrote:
> > On Thu, Nov 29, 2018 at 10:54 AM Christoph Hellwig wrote:
> > >
> > > On Thu, Nov 29, 2018 at 09:42:50AM -0500, Rob Clark wrote:
> > > > Maybe the thing we need to do is just i
On Thu, Nov 29, 2018 at 01:48:15PM -0500, Rob Clark wrote:
> On Thu, Nov 29, 2018 at 10:54 AM Christoph Hellwig wrote:
> >
> > On Thu, Nov 29, 2018 at 09:42:50AM -0500, Rob Clark wrote:
> > > Maybe the thing we need to do is just implement a blacklist of
> > > compatible strings for devices which
On Thu, Nov 29, 2018 at 12:24 PM Tomasz Figa wrote:
>
> [CC Marek]
>
> On Thu, Nov 29, 2018 at 9:09 AM Daniel Vetter wrote:
> >
> > On Thu, Nov 29, 2018 at 5:57 PM Christoph Hellwig wrote:
> > >
> > > Note that one thing I'd like to avoid is exposing these funtions directly
> > > to drivers, as
On Thu, Nov 29, 2018 at 10:54 AM Christoph Hellwig wrote:
>
> On Thu, Nov 29, 2018 at 09:42:50AM -0500, Rob Clark wrote:
> > Maybe the thing we need to do is just implement a blacklist of
> > compatible strings for devices which should skip the automatic
> > iommu/dma hookup. Maybe a bit ugly, bu
On Thu, Nov 29, 2018 at 10:53 AM Christoph Hellwig wrote:
>
> On Thu, Nov 29, 2018 at 09:25:43AM -0500, Rob Clark wrote:
> > > As I told you before: hell no. If you spent the slightest amount of
> > > actually trying to understand what you are doing here you'd know this
> > > can't work. Just t
On Thu, Nov 29, 2018 at 05:33:03PM +, Brian Starkey wrote:
> This sounds very useful for ion, to avoid CPU cache maintenance as
> long as the buffer stays in device-land.
>
> One question though: How would you determine "the last user to unmap"
> to know when to do the final "make visible to C
On Thu, Nov 29, 2018 at 09:24:17AM -0800, Tomasz Figa wrote:
> Whether the cache maintenance operation needs to actually do anything
> or not is a function of `dev`. We can have some devices that are
> coherent with CPU caches, and some that are not, on the same system.
Yes, but that part is not d
On Thu, Nov 29, 2018 at 06:09:05PM +0100, Daniel Vetter wrote:
> What kind of abuse do you expect? It could very well be that gpu folks
> call that "standard use case" ... At least on x86 with the i915 driver
> we pretty much rely on architectural guarantees for how cache flushes
> work very much.
[CC Marek]
On Thu, Nov 29, 2018 at 9:09 AM Daniel Vetter wrote:
>
> On Thu, Nov 29, 2018 at 5:57 PM Christoph Hellwig wrote:
> > On Thu, Nov 29, 2018 at 05:28:07PM +0100, Daniel Vetter wrote:
> > > Just spend a bit of time reading through the implementations already
> > > merged. Is the struct d
On Thu, Nov 29, 2018 at 5:57 PM Christoph Hellwig wrote:
> On Thu, Nov 29, 2018 at 05:28:07PM +0100, Daniel Vetter wrote:
> > Just spend a bit of time reading through the implementations already
> > merged. Is the struct device *dev parameter actually needed anywhere?
> > dma-api definitely needs
On Thu, Nov 29, 2018 at 05:28:07PM +0100, Daniel Vetter wrote:
> Just spend a bit of time reading through the implementations already
> merged. Is the struct device *dev parameter actually needed anywhere?
> dma-api definitely needs it, because we need that to pick the right iommu.
> But for cache
On Thu, Nov 29, 2018 at 04:57:58PM +0100, Christoph Hellwig wrote:
> On Thu, Nov 29, 2018 at 03:43:50PM +0100, Daniel Vetter wrote:
> > Yeah we had patches to add manual cache management code to drm, so we
> > don't have to abuse the dma streaming api anymore. Got shouted down.
> > Abusing the dma
On Thu, Nov 29, 2018 at 03:43:50PM +0100, Daniel Vetter wrote:
> Yeah we had patches to add manual cache management code to drm, so we
> don't have to abuse the dma streaming api anymore. Got shouted down.
> Abusing the dma streaming api also gets shouted down. It's a gpu, any
> idea of these drive
On Thu, Nov 29, 2018 at 09:42:50AM -0500, Rob Clark wrote:
> Maybe the thing we need to do is just implement a blacklist of
> compatible strings for devices which should skip the automatic
> iommu/dma hookup. Maybe a bit ugly, but it would also solve a problem
> preventing us from enabling per-pro
On Thu, Nov 29, 2018 at 09:25:43AM -0500, Rob Clark wrote:
> > As I told you before: hell no. If you spent the slightest amount of
> > actually trying to understand what you are doing here you'd know this
> > can't work. Just turn on dma debugging and this will blow up in your
> > face.
>
> you
On Thu, Nov 29, 2018 at 3:26 PM Rob Clark wrote:
>
> On Thu, Nov 29, 2018 at 9:14 AM Christoph Hellwig wrote:
> >
> > On Thu, Nov 29, 2018 at 07:33:15PM +0530, Vivek Gautam wrote:
> > > dma_map_sg() expects a DMA domain. However, the drm devices
> > > have been traditionally using unmanaged iommu
On Thu, Nov 29, 2018 at 9:25 AM Rob Clark wrote:
>
> On Thu, Nov 29, 2018 at 9:14 AM Christoph Hellwig wrote:
> >
> > On Thu, Nov 29, 2018 at 07:33:15PM +0530, Vivek Gautam wrote:
> > > dma_map_sg() expects a DMA domain. However, the drm devices
> > > have been traditionally using unmanaged iommu
On Thu, Nov 29, 2018 at 07:33:15PM +0530, Vivek Gautam wrote:
> dma_map_sg() expects a DMA domain. However, the drm devices
> have been traditionally using unmanaged iommu domain which
> is non-dma type. Using dma mapping APIs with that domain is bad.
>
> Replace dma_map_sg() calls with dma_sync_s
On Thu, Nov 29, 2018 at 9:14 AM Christoph Hellwig wrote:
>
> On Thu, Nov 29, 2018 at 07:33:15PM +0530, Vivek Gautam wrote:
> > dma_map_sg() expects a DMA domain. However, the drm devices
> > have been traditionally using unmanaged iommu domain which
> > is non-dma type. Using dma mapping APIs with
dma_map_sg() expects a DMA domain. However, the drm devices
have been traditionally using unmanaged iommu domain which
is non-dma type. Using dma mapping APIs with that domain is bad.
Replace dma_map_sg() calls with dma_sync_sg_for_device{|cpu}()
to do the cache maintenance.
Signed-off-by: Vivek
34 matches
Mail list logo
