All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Rob Clark <robdclark@chromium.org>,
	Maxime Ripard <maxime.ripard@bootlin.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	David Airlie <airlied@linux.ie>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Sean Paul <sean@poorly.run>, Rob Clark <robdclark@gmail.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Will Deacon <will@kernel.org>, Christoph Hellwig <hch@lst.de>,
	Allison Randal <allison@lohutok.net>
Subject: Re: [PATCH 1/2] drm: add cache support for arm64
Date: Thu, 8 Aug 2019 11:55:06 +0200	[thread overview]
Message-ID: <20190808095506.GA32621@lst.de> (raw)
In-Reply-To: <CAKMK7uH1O3q8VUftikipGH6ACPoT-8tbV1Zwo-8WL=wUHiqsoQ@mail.gmail.com>

On Wed, Aug 07, 2019 at 10:48:56AM +0200, Daniel Vetter wrote:
> >    other drm drivers how do they guarantee addressability without an
> >    iommu?)
> 
> We use shmem to get at swappable pages. We generally just assume that
> the gpu can get at those pages, but things fall apart in fun ways:
> - some setups somehow inject bounce buffers. Some drivers just give
> up, others try to allocate a pool of pages with dma_alloc_coherent.
> - some devices are misdesigned and can't access as much as the cpu. We
> allocate using GFP_DMA32 to fix that.

Well, for shmem you can't really call allocators directly, right?

One thing I have in my pipeline is a dma_alloc_pages API that allocates
pages that are guaranteed to be addressably by the device or otherwise
fail.  But that doesn't really help with the shmem fs.

> Also modern gpu apis pretty much assume you can malloc() and then use
> that directly with the gpu.

Which is fine as long as the GPU itself supports full 64-bit addressing
(or always sits behind an iommu), and the platform doesn't impose
addressing limit, which unfortunately some that are shipped right now
still do :(

But userspace malloc really means dma_map_* anyway, so not really
relevant for memory allocations.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Christoph Hellwig <hch@lst.de>,
	Rob Clark <robdclark@chromium.org>,
	Rob Clark <robdclark@gmail.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <maxime.ripard@bootlin.com>,
	Sean Paul <sean@poorly.run>, David Airlie <airlied@linux.ie>,
	Allison Randal <allison@lohutok.net>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] drm: add cache support for arm64
Date: Thu, 8 Aug 2019 11:55:06 +0200	[thread overview]
Message-ID: <20190808095506.GA32621@lst.de> (raw)
In-Reply-To: <CAKMK7uH1O3q8VUftikipGH6ACPoT-8tbV1Zwo-8WL=wUHiqsoQ@mail.gmail.com>

On Wed, Aug 07, 2019 at 10:48:56AM +0200, Daniel Vetter wrote:
> >    other drm drivers how do they guarantee addressability without an
> >    iommu?)
> 
> We use shmem to get at swappable pages. We generally just assume that
> the gpu can get at those pages, but things fall apart in fun ways:
> - some setups somehow inject bounce buffers. Some drivers just give
> up, others try to allocate a pool of pages with dma_alloc_coherent.
> - some devices are misdesigned and can't access as much as the cpu. We
> allocate using GFP_DMA32 to fix that.

Well, for shmem you can't really call allocators directly, right?

One thing I have in my pipeline is a dma_alloc_pages API that allocates
pages that are guaranteed to be addressably by the device or otherwise
fail.  But that doesn't really help with the shmem fs.

> Also modern gpu apis pretty much assume you can malloc() and then use
> that directly with the gpu.

Which is fine as long as the GPU itself supports full 64-bit addressing
(or always sits behind an iommu), and the platform doesn't impose
addressing limit, which unfortunately some that are shipped right now
still do :(

But userspace malloc really means dma_map_* anyway, so not really
relevant for memory allocations.

  reply	other threads:[~2019-08-08  9:55 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-05 21:14 [PATCH 1/2] drm: add cache support for arm64 Rob Clark
2019-08-05 21:14 ` Rob Clark
2019-08-05 21:14 ` [PATCH 2/2] drm/msm: use drm_cache when available Rob Clark
2019-08-05 21:14   ` Rob Clark
2019-08-06  8:48 ` [PATCH 1/2] drm: add cache support for arm64 Christoph Hellwig
2019-08-06  8:48   ` Christoph Hellwig
2019-08-06  9:38   ` Daniel Vetter
2019-08-06  9:38     ` Daniel Vetter
2019-08-06  9:38     ` Daniel Vetter
2019-08-06 11:38     ` Christoph Hellwig
2019-08-06 11:38       ` Christoph Hellwig
2019-08-06 14:11   ` Rob Clark
2019-08-06 14:11     ` Rob Clark
2019-08-06 14:34     ` Mark Rutland
2019-08-06 14:34       ` Mark Rutland
2019-08-06 16:31       ` Rob Clark
2019-08-06 16:31         ` Rob Clark
2019-08-07 12:38         ` Mark Rutland
2019-08-07 12:38           ` Mark Rutland
2019-08-07 16:15           ` Rob Clark
2019-08-07 16:15             ` Rob Clark
2019-08-07 16:49             ` Mark Rutland
2019-08-07 16:49               ` Mark Rutland
2019-08-07 17:30               ` Rob Clark
2019-08-07 17:30                 ` Rob Clark
2019-08-08  7:59                 ` Christoph Hellwig
2019-08-08  7:59                   ` Christoph Hellwig
2019-08-08 16:44                   ` Rob Clark
2019-08-08 16:44                     ` Rob Clark
2019-08-09  8:18                     ` Christoph Hellwig
2019-08-09  8:18                       ` Christoph Hellwig
2019-08-08  7:58               ` Christoph Hellwig
2019-08-08  7:58                 ` Christoph Hellwig
2019-08-08 10:20                 ` Mark Rutland
2019-08-08 10:20                   ` Mark Rutland
2019-08-08 10:24                   ` Mark Rutland
2019-08-08 10:24                     ` Mark Rutland
2019-08-08 10:32                   ` Will Deacon
2019-08-08 10:32                     ` Will Deacon
2019-08-08  7:53           ` Christoph Hellwig
2019-08-08  7:53             ` Christoph Hellwig
2019-08-06 15:50     ` Christoph Hellwig
2019-08-06 15:50       ` Christoph Hellwig
2019-08-06 16:23       ` Rob Clark
2019-08-06 16:23         ` Rob Clark
2019-08-06 16:26         ` Rob Clark
2019-08-06 16:26           ` Rob Clark
2019-08-07  6:25         ` Christoph Hellwig
2019-08-07  6:25           ` Christoph Hellwig
2019-08-07  8:48           ` Daniel Vetter
2019-08-07  8:48             ` Daniel Vetter
2019-08-08  9:55             ` Christoph Hellwig [this message]
2019-08-08  9:55               ` Christoph Hellwig
2019-08-08 11:58               ` Daniel Vetter
2019-08-08 11:58                 ` Daniel Vetter
2019-08-08 11:58                 ` Daniel Vetter
2019-08-09  8:14                 ` Christoph Hellwig
2019-08-09  8:14                   ` Christoph Hellwig
2019-08-07 16:09           ` Rob Clark
2019-08-07 16:09             ` Rob Clark
2019-08-08 10:00             ` Christoph Hellwig
2019-08-08 10:00               ` Christoph Hellwig
2019-08-08 16:32               ` Rob Clark
2019-08-08 16:32                 ` Rob Clark

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190808095506.GA32621@lst.de \
    --to=hch@lst.de \
    --cc=airlied@linux.ie \
    --cc=allison@lohutok.net \
    --cc=catalin.marinas@arm.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=maxime.ripard@bootlin.com \
    --cc=robdclark@chromium.org \
    --cc=robdclark@gmail.com \
    --cc=sean@poorly.run \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.