All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chen Li <chenli@uniontech.com>
To: "Christian König" <christian.koenig@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>,
	Chen Li <chenli@uniontech.com>,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/[amdgpu|radeon]: fix memset on io mem
Date: Fri, 18 Dec 2020 16:52:13 +0800	[thread overview]
Message-ID: <87v9czxzr6.wl-chenli@uniontech.com> (raw)
In-Reply-To: <0a449ae3-c55b-e1da-836c-3192eea5cb92@amd.com>

On Fri, 18 Dec 2020 16:10:12 +0800,
Christian König wrote:
> 
> Am 18.12.20 um 04:51 schrieb Chen Li:
> > [SNIP]
> >>>> If your ARM base board can't do that for some then you can't use the hardware
> >>>> with that board.
> >>> Good to know, thanks! BTW, have you ever seen or heard boards like mine which cannot mmap device memory correctly from userspace correctly?
> >> Unfortunately yes. We haven't been able to figure out what exactly goes wrong in
> >> those cases.
> > Ok. one more question: only e8860 or all radeon cards have this issue?
> 
> This applies to all hardware with dedicated memory which needs to be mapped to
> userspace.
> 
> That includes all graphics hardware from AMD as well as NVidia and probably a
> whole bunch of other PCIe devices.

Can mmio on these devices work fine in kernel space? I cannot see the difference here except user space should use uncacheable mmap to map virtual memory to device space(though I don't know how to use uncacheable mmap), while kernel use uncache ioremap. 

> 
> >>>       The graphics address remapping table (GART),[1] also known as the graphics aperture remapping table,[2] or graphics translation table (GTT),[3] is an I/O memory management unit (IOMMU) used by Accelerated Graphics Port (AGP) and PCI Express (PCIe) graphics cards.
> >> GART or GTT refers to the translation tables graphics hardware use to access
> >> system memory.
> >> 
> >> Something like 15 years ago we used the IOMMU functionality from AGP to
> >> implement that. But modern hardware (PCIe) uses some specialized hardware in the
> >> GPU for that.
> >> 
> >> Regards,
> >> Christian.
> >> 
> >> 
> >> 
> > Good to know, thanks! So modern GART/GTT is like tlb, and iommu is forcused on translating address and not manager the tlb.
> 
> You are getting closer in your understanding, but the TLB is the Translation
> lookaside buffer. Basically a cache of recent VM translations which is present
> is all page table translations (GART, IOMMU, CPU etc...).
> 
> The key difference is where the page table translation happens on modern
> hardware:
> 1. For the GART/GTT it is inside the GPU to translate between GPU internal and
> bus addresses.
> 2. For IOMMU it is inside the root complex of the PCIe to translate between bus
> addresses and physical addresses.
> 3. For CPU page tables it is inside the CPU core to translate between virtual
> addresses and physical addresses.
> 
> Regards,
> Christian.
> 
> 

Awesome explaination! Thanks in a ton!


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-12-20 11:10 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-16  5:41 [PATCH] drm/[amdgpu|radeon]: fix memset on io mem Chen Li
2020-12-16  7:59 ` Christian König
2020-12-16 13:48   ` Chen Li
2020-12-16 14:19     ` Christian König
2020-12-17  1:07       ` Chen Li
2020-12-17 10:25         ` Christian König
2020-12-17 13:37           ` Chen Li
2020-12-17 14:16             ` Christian König
2020-12-18  3:51               ` Chen Li
2020-12-18  8:10                 ` Christian König
2020-12-18  8:52                   ` Chen Li [this message]
2020-12-18 10:41                     ` Christian König
2020-12-17 13:45           ` Robin Murphy
2020-12-17 14:02             ` Christian König
2020-12-17 14:18               ` Lucas Stach
2020-12-18 14:17               ` Robin Murphy
2020-12-18 14:33                 ` Christian König
2020-12-18 15:19                   ` Robin Murphy
2020-12-18  6:14             ` Chen Li
2020-12-18 14:42               ` Robin Murphy
2020-12-16 12:52 ` [kbuild] " Dan Carpenter
2020-12-16 12:52   ` Dan Carpenter
2020-12-16 12:52   ` Dan Carpenter
2020-12-16 13:00 ` kernel test robot
2020-12-16 13:00   ` kernel test robot
2020-12-16 12:12 kernel test robot

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=87v9czxzr6.wl-chenli@uniontech.com \
    --to=chenli@uniontech.com \
    --cc=alexander.deucher@amd.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.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.