dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: "Christian König" <christian.koenig@amd.com>,
	"Matthew Auld" <matthew.william.auld@gmail.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	ML dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH v3 06/12] drm/ttm: Add a generic TTM memcpy move for page-based iomem
Date: Wed, 26 May 2021 12:57:10 +0200	[thread overview]
Message-ID: <fbbb896e7e886e4d41b3a319c6aa7c5bb2e8ad4e.camel@linux.intel.com> (raw)
In-Reply-To: <9f8fe3af-6d49-f652-70bc-36a27007d821@amd.com>

On Wed, 2021-05-26 at 12:45 +0200, Christian König wrote:
> Am 26.05.21 um 09:39 schrieb Thomas Hellström:
> > [SNIP]
> > > > I think the long term goal is to use memremap all over the
> > > > place, to
> > > > just not have to bother with the __iomem annotation. But to do
> > > > that io-
> > > > mapping.h needs to support memremap. But for now we need to be
> > > > strict
> > > > about __iomem unless we're in arch specific code. That's why
> > > > that
> > > > dma_buf_map thing was created, but TTM memcpy was never fully
> > > > adapted.
> > > 
> > > I don't think that this will work. __iomem annotation is there 
> > > because we have architectures where you need to use special CPU 
> > > instructions for iomem access.
> > > 
> > > That won't go away just because we use memremap().
> > 
> > That's true, but can we ever support those with TTM, given that we 
> > allow user-space mmaping that transparently may change to an iomap?
> > Given that, and what's written here
> > 
> >  
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flwn.net%2FArticles%2F653585%2F&amp;data=04%7C01%7Cchristian.koenig%40amd.com%7C1cdcfe9d20e740308c9e08d92019785b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637576116034492654%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=e2BFGQJcElwVxrvHcnALDWscHN7ernLekGvXHqWBcwY%3D&amp;reserved=0
> >  
> > 
> > 
> > To me it sounds like if an architecture can't support memremap, we 
> > can't support it with TTM either.
> 
> That was also my argument, but this is unfortunately not true.
> 
> We already have architectures where the __iomem approach is mandatory
> for kernel mappings, but work fine for userspace (don't ask me how
> that 
> works, idk).

Ugh. :/

> 
> That's the reason why we had to fix the UVD firmware upload in the
> kernel:
> 
> commit ba0b2275a6781b2f3919d931d63329b5548f6d5f
> Author: Christian König <christian.koenig@amd.com>
> Date:   Tue Aug 23 11:00:17 2016 +0200
> 
>      drm/amdgpu: use memcpy_to/fromio for UVD fw upload
> 
> > 
> > In any case for this particular patch, to avoid potential
> > regressions, 
> > OK if I just add an ioremap() in case the memremap fails?
> 
> Well because of the issues outlined above I would actually prefer if
> we 
> can keep the __iomem annotation around.

Well, we'd do that. Since we use the dma_buf_map unconditionally.

So what would happen in the above case, would be:

- memremap would fail. (Otherwise I'd be terribly confused)
- we retry with ioremap and the dma-buf-map member is_iomem would thus
be set
- memcpy would do the right thing, based on is_iomem.

/Thomas

> 
> Christian.
> 
> > 
> > /Thomas
> > 
> > 
> > > 
> > > Christian.
> > > 
> > > > 
> > > > As for limited arch support for memremap cached, It looks like
> > > > we only
> > > > need to or in "backup" mapping modes in the memremap flags, and
> > > > we'd
> > > > mimic the previous behaviour.
> > > > 
> > > > /Thomas
> > > > 
> > > > 
> > > > > > /Thomas
> > > > > > 
> > > > > > 
> > > > 
> > > 
> 



  reply	other threads:[~2021-05-26 10:57 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-21 15:32 [PATCH v3 00/12] drm/i915: Move LMEM (VRAM) management over to TTM Thomas Hellström
2021-05-21 15:32 ` [PATCH v3 01/12] drm/i915: Untangle the vma pages_mutex Thomas Hellström
2021-05-21 15:32 ` [PATCH v3 02/12] drm/i915: Don't free shared locks while shared Thomas Hellström
2021-05-21 15:32 ` [PATCH v3 03/12] drm/i915: Fix i915_sg_page_sizes to record dma segments rather than physical pages Thomas Hellström
2021-05-21 15:32 ` [PATCH v3 04/12] drm/i915/ttm Initialize the ttm device and memory managers Thomas Hellström
2021-05-21 15:32 ` [PATCH v3 05/12] drm/i915/ttm: Embed a ttm buffer object in the i915 gem object Thomas Hellström
2021-05-21 15:32 ` [PATCH v3 06/12] drm/ttm: Add a generic TTM memcpy move for page-based iomem Thomas Hellström
2021-05-25  9:18   ` [Intel-gfx] " Matthew Auld
2021-05-25  9:32     ` Thomas Hellström
2021-05-25  9:58       ` Matthew Auld
2021-05-25 10:07         ` Thomas Hellström
2021-05-25 15:48           ` Christian König
2021-05-26  7:39             ` Thomas Hellström
2021-05-26 10:45               ` Christian König
2021-05-26 10:57                 ` Thomas Hellström [this message]
2021-05-21 15:32 ` [PATCH v3 07/12] drm, drm/i915: Move the memcpy_from_wc functionality to core drm Thomas Hellström
2021-05-24 16:45   ` [Intel-gfx] " Matthew Auld
2021-05-24 18:12     ` Thomas Hellström
2021-05-21 15:32 ` [PATCH v3 08/12] drm/ttm: Use drm_memcpy_from_wc_dbm for TTM bo moves Thomas Hellström
2021-05-24 18:16   ` Matthew Auld
2021-05-24 18:47     ` Thomas Hellström
2021-05-26 12:48   ` Christian König
2021-05-21 15:32 ` [PATCH v3 09/12] drm/ttm: Document and optimize ttm_bo_pipeline_gutting() Thomas Hellström
2021-05-25 11:00   ` [Intel-gfx] " Matthew Auld
2021-05-25 13:37     ` Thomas Hellström
2021-05-21 15:32 ` [PATCH v3 10/12] drm/ttm, drm/amdgpu: Allow the driver some control over swapping Thomas Hellström
2021-05-21 15:32 ` [PATCH v3 11/12] drm/i915/ttm: Introduce a TTM i915 gem object backend Thomas Hellström
2021-05-21 15:32 ` [PATCH v3 12/12] drm/i915/lmem: Verify checks for lmem residency Thomas Hellström

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=fbbb896e7e886e4d41b3a319c6aa7c5bb2e8ad4e.camel@linux.intel.com \
    --to=thomas.hellstrom@linux.intel.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=matthew.william.auld@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox