On 8/12/2021 1:34 AM, Christoph Hellwig wrote:
Do you have a pointer to a git branch with this series and all dependencies
to ease testing?
Hi Christoph,
Yes, actually tomorrow we're planning to send a new version with
detailed instructions
on how to setup and run each of the tests. This
Hello Brian,
(+Uma in cc)
Thanks for your comments, Let me try to fill-in for Harry to keep the
design discussion going. Please find my comments inline.
On 8/2/2021 10:00 PM, Brian Starkey wrote:
Hi,
Thanks for having a stab at this, it's a massive complex topic to
solve.
Do you have the
On 8/12/2021 10:24 PM, Michel Dänzer wrote:
On 2021-08-12 1:33 p.m., Lazar, Lijo wrote:
On 8/12/2021 1:41 PM, Michel Dänzer wrote:
On 2021-08-12 7:55 a.m., Koenig, Christian wrote:
Hi James,
Evan seems to have understood how this all works together.
See while any begin/end use critical
The pull request you sent on Fri, 13 Aug 2021 07:06:07 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-08-13
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/82cce5f4291e089d44b7b9bc77918cbcd52d429e
Thank you!
--
Deet-doot-dot, I am a bot.
Implement virtgpu specific map_dma_buf callback to support mapping
exported vram object dma-bufs. The dma-buf callback is used directly, as
vram objects don't have backing pages and thus can't implement the
drm_gem_object_funcs.get_sg_table callback.
Signed-off-by: David Stevens
---
v1 -> v2:
-
On 2021-08-12 06:11, Stephen Boyd wrote:
Quoting Sankeerth Billakanti (2021-08-11 17:08:01)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index b131fd37..1096c44 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++
On Thu, Aug 12, 2021 at 09:47:23PM +0200, Daniel Vetter wrote:
> On Thu, Aug 12, 2021 at 03:23:30PM +, Matthew Brost wrote:
> > On Thu, Aug 12, 2021 at 04:11:28PM +0200, Daniel Vetter wrote:
> > > On Wed, Aug 11, 2021 at 01:16:18AM +, Matthew Brost wrote:
> > > > Flush the work queue for
On Thu, Aug 12, 2021 at 9:49 AM Daniel Vetter wrote:
>
> On Thu, Aug 12, 2021 at 2:44 PM Maarten Lankhorst
> wrote:
> >
> > DG1 has support for local memory, which requires the usage of the
> > lmem placement extension for creating bo's, and memregion queries
> > to obtain the size. Because of
Hey Linus,
Another week, another set of pretty regular fixes, nothing really
stands out too much.
Dave.
drm-fixes-2021-08-13:
drm fixes for 5.14-rc6
amdgpu:
- Yellow carp update
- RAS EEPROM fixes
- BACO/BOCO fixes
- Fix a memory leak in an error path
- Freesync fix
- VCN harvesting fix
-
Hi,
On Tue, Aug 10, 2021 at 5:13 AM Geert Uytterhoeven wrote:
>
> On Fri, Jul 23, 2021 at 7:35 AM Uwe Kleine-König
> wrote:
> > On Fri, Jul 23, 2021 at 03:09:44PM +1000, Stephen Rothwell wrote:
> > > After merging the driver-core tree, today's linux-next build (arm
> > > multi_v7_defconfig)
It's needed for pgprot_t which is used in the header.
Signed-off-by: Jason Ekstrand
Cc: Christian König
---
drivers/gpu/drm/ttm/ttm_tt.c | 1 -
include/drm/ttm/ttm_tt.h | 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c
These names were changed in
commit 8af8a109b34fa88b8b91f25d11485b37d37549c3
Author: Christian König
Date: Thu Oct 1 14:51:40 2020 +0200
drm/ttm: device naming cleanup
But he missed a couple of them.
Signed-off-by: Jason Ekstrand
Cc: Christian König
Fixes: 8af8a109b34f ("drm/ttm:
Laurent,
On Thu, Aug 12, 2021 at 12:26 PM Laurent Pinchart
wrote:
>
> Hi Rob,
>
> Thank you for the patch.
>
> On Wed, Aug 11, 2021 at 04:52:50PM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > Slightly awkward to fish out the display_info when we aren't creating
> > own connector. But I
On Thu, Aug 12, 2021 at 5:26 AM Michel Dänzer wrote:
>
> On 2021-08-11 7:55 p.m., Mark Yacoub wrote:
> > From: Mark Yacoub
> >
> > [Why]
> > Userspace should get back a copy of the request that's been modified
> > even when drm_wait_vblank_ioctl returns a failure.
> >
> > Rationale:
> >
From: Mark Yacoub
[Why]
Userspace should get back a copy of drm_wait_vblank that's been modified
even when drm_wait_vblank_ioctl returns a failure.
Rationale:
drm_wait_vblank_ioctl modifies the request and expects the user to read
it back. When the type is RELATIVE, it modifies it to ABSOLUTE
On Thu, Aug 12, 2021 at 03:23:30PM +, Matthew Brost wrote:
> On Thu, Aug 12, 2021 at 04:11:28PM +0200, Daniel Vetter wrote:
> > On Wed, Aug 11, 2021 at 01:16:18AM +, Matthew Brost wrote:
> > > Flush the work queue for GuC generated G2H messages durinr a GT reset.
> > > This is accomplished
On Thu, Aug 12, 2021 at 07:01:44PM +0200, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Thu, Aug 12, 2021 at 03:14:12PM +0200, Daniel Vetter wrote:
> > Aside from deleting lots of code the real motivation here is to switch
> > the mmap over to VM_PFNMAP, to be more consistent with what real gpu
> >
Last drm-misc-next for next kernel release!
drm-misc-next-2021-08-12:
drm-misc-next for v5.15:
UAPI Changes:
Cross-subsystem Changes:
- Add lockdep_assert(once) helpers.
Core Changes:
- Add lockdep assert to drm_is_current_master_locked.
- Fix typos in dma-buf documentation.
- Mark drm irq
On Thu, Aug 05, 2021 at 12:46:58PM +0200, Daniel Vetter wrote:
> Integrated into the scheduler now and all users converted over.
>
> Signed-off-by: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Sumit Semwal
>
On Thu, Aug 05, 2021 at 12:46:57PM +0200, Daniel Vetter wrote:
> drm_sched_job_init is already at the right place, so this boils down
> to deleting code.
>
> Signed-off-by: Daniel Vetter
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: Sumit Semwal
> Cc: "Christian König"
> Cc:
On Thu, Aug 05, 2021 at 12:46:56PM +0200, Daniel Vetter wrote:
> We need to pull the drm_sched_job_init much earlier, but that's very
> minor surgery.
>
> v2: Actually fix up cleanup paths by calling drm_sched_job_init, which
> I wanted to to in the previous round (and did, for all other
On Thu, Aug 05, 2021 at 12:46:53PM +0200, Daniel Vetter wrote:
> Nothing special going on here.
>
> Aside reviewing the code, it seems like drm_sched_job_arm() should be
> moved into lima_sched_context_queue_task and put under some mutex
> together with drm_sched_push_job(). See the kerneldoc for
On Tue, Aug 03, 2021 at 03:29:43PM -0700, Matthew Brost wrote:
> Some workloads use lots of contexts that continually pin / unpin
> contexts. With GuC submission an unpin translates to a schedule disable
> H2G which puts pressure on both the i915 and GuC. A schedule disable can
> also block future
Hi Rob,
Thank you for the patch.
On Wed, Aug 11, 2021 at 04:52:50PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Slightly awkward to fish out the display_info when we aren't creating
> own connector. But I don't see an obvious better way.
We need a bit more than this, to support the
Hi Rob,
On Thu, Aug 12, 2021 at 12:09:12PM -0700, Rob Clark wrote:
> On Thu, Aug 12, 2021 at 11:44 AM Laurent Pinchart wrote:
> > On Wed, Aug 11, 2021 at 04:52:49PM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > For the brave new world of bridges not creating their own connectors, we
On Thu, Aug 12, 2021 at 11:44 AM Laurent Pinchart
wrote:
>
> Hi Rob,
>
> Thank you for the patch.
>
> On Wed, Aug 11, 2021 at 04:52:49PM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > For the brave new world of bridges not creating their own connectors, we
> > need to implement the max
Hi Rob,
Thank you for the patch.
On Wed, Aug 11, 2021 at 04:52:49PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> For the brave new world of bridges not creating their own connectors, we
> need to implement the max clock limitation via bridge->mode_valid()
> instead of connector->mode_valid().
On Thu, Aug 12, 2021 at 10:31 AM Sam Ravnborg wrote:
>
> Hi Rob,
>
> On Wed, Aug 11, 2021 at 04:52:48PM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > For now, since we have a mix of bridges which support this flag, which
> > which do *not* support this flag, or work both ways, try it once
Hi Rob,
On Wed, Aug 11, 2021 at 04:52:48PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> For now, since we have a mix of bridges which support this flag, which
> which do *not* support this flag, or work both ways, try it once with
> NO_CONNECTOR and then fall back to the old way if that
Hi,
On Wed, Aug 11, 2021 at 4:51 PM Rob Clark wrote:
>
> From: Rob Clark
>
> For the brave new world of bridges not creating their own connectors, we
> need to implement the max clock limitation via bridge->mode_valid()
> instead of connector->mode_valid().
>
> Signed-off-by: Rob Clark
> ---
>
Hi,
On Wed, Aug 11, 2021 at 4:51 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Slightly awkward to fish out the display_info when we aren't creating
> own connector. But I don't see an obvious better way.
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 34
On Thu, Aug 12, 2021 at 9:55 AM Doug Anderson wrote:
>
> Hi,
>
> On Wed, Aug 11, 2021 at 4:51 PM Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > If we created our own connector because the driver does not support the
> > NO_CONNECTOR flag, we don't want the downstream bridge to *also* create
>
Hi Daniel,
On Thu, Aug 12, 2021 at 03:14:12PM +0200, Daniel Vetter wrote:
> Aside from deleting lots of code the real motivation here is to switch
> the mmap over to VM_PFNMAP, to be more consistent with what real gpu
> drivers do. They're all VM_PFNMP, which means get_user_pages doesn't
> work,
Hi,
On Wed, Aug 11, 2021 at 4:51 PM Rob Clark wrote:
>
> From: Rob Clark
>
> If we created our own connector because the driver does not support the
> NO_CONNECTOR flag, we don't want the downstream bridge to *also* create
> a connector. And if this driver did pass the NO_CONNECTOR flag (and
On 2021-08-12 1:33 p.m., Lazar, Lijo wrote:
> On 8/12/2021 1:41 PM, Michel Dänzer wrote:
>> On 2021-08-12 7:55 a.m., Koenig, Christian wrote:
>>> Hi James,
>>>
>>> Evan seems to have understood how this all works together.
>>>
>>> See while any begin/end use critical section is active the work
Hi Dave & Daniel,
This is the main pull for v5.15, after the early pull request with
drm/scheduler conversion:
* New a6xx GPU support: a680 and 7c3
* dsi: 7nm phi, sc7280 support, test pattern generator support
* mdp4 fixes for older hw like the nexus7
* displayport fixes
There will be minor
Hi Rob
Thank you for the patch.
On Wed, Aug 11, 2021 at 04:52:48PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> For now, since we have a mix of bridges which support this flag, which
> which do *not* support this flag, or work both ways, try it once with
> NO_CONNECTOR and then fall back to
Hi Rob,
Thank you for the patch.
On Wed, Aug 11, 2021 at 04:52:47PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> If we created our own connector because the driver does not support the
> NO_CONNECTOR flag, we don't want the downstream bridge to *also* create
> a connector. And if this driver
Hi,
On Thu, Aug 12, 2021 at 2:38 AM Sam Ravnborg wrote:
>
> Hi Doug,
> On Mon, Aug 09, 2021 at 03:18:03PM -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Tue, Aug 3, 2021 at 1:41 PM Sam Ravnborg wrote:
> > >
> > > Hi Douglas,
> > >
> > > On Fri, Jul 30, 2021 at 02:26:19PM -0700, Douglas Anderson
Hi Dave and Daniel,
Here goes drm-intel-fixes-2021-08-12:
- GVT fix for Windows VM hang.
- Display fix of 12 BPC bits for display 12 and newer.
- Don't try to access some media register for fused off domains.
- Fix kerneldoc build warnings.
Thanks,
Rodrigo.
The following changes since commit
On Thu, Aug 12, 2021 at 5:10 PM Jason Ekstrand wrote:
> On Tue, Aug 10, 2021 at 8:05 AM Daniel Vetter wrote:
> >
> > This essentially reverts
> >
> > commit 89ff76bf9b3b0b86e6bbe344bd6378d8661303fc
> > Author: Chris Wilson
> > Date: Thu Apr 2 13:42:18 2020 +0100
> >
> > drm/i915/gem:
On Thu, Aug 12, 2021 at 04:11:28PM +0200, Daniel Vetter wrote:
> On Wed, Aug 11, 2021 at 01:16:18AM +, Matthew Brost wrote:
> > Flush the work queue for GuC generated G2H messages durinr a GT reset.
> > This is accomplished by spinning on the the list of outstanding G2H to
> > go empty.
> >
>
On Tue, Aug 10, 2021 at 8:05 AM Daniel Vetter wrote:
>
> This essentially reverts
>
> commit 89ff76bf9b3b0b86e6bbe344bd6378d8661303fc
> Author: Chris Wilson
> Date: Thu Apr 2 13:42:18 2020 +0100
>
> drm/i915/gem: Utilize rcu iteration of context engines
>
> Note that the other use of
On Thu, Aug 12, 2021 at 4:45 PM Daniel Vetter wrote:
>
> On Wed, Aug 11, 2021 at 06:06:36PM +, Matthew Brost wrote:
> > On Tue, Aug 10, 2021 at 11:07:55AM +0200, Daniel Vetter wrote:
> > > On Tue, Aug 10, 2021 at 10:53:37AM +0200, Daniel Vetter wrote:
> > > > On Mon, Aug 09, 2021 at
Pushed to drm-misc-next, thanks!
On Thu, Aug 12, 2021 at 2:44 PM Maarten Lankhorst
wrote:
>
> DG1 has support for local memory, which requires the usage of the
> lmem placement extension for creating bo's, and memregion queries
> to obtain the size. Because of this, those parts of the uapi are
> no longer guarded behind
On Wed, Aug 11, 2021 at 06:06:36PM +, Matthew Brost wrote:
> On Tue, Aug 10, 2021 at 11:07:55AM +0200, Daniel Vetter wrote:
> > On Tue, Aug 10, 2021 at 10:53:37AM +0200, Daniel Vetter wrote:
> > > On Mon, Aug 09, 2021 at 06:58:23PM +, Matthew Brost wrote:
> > > > On Mon, Aug 09, 2021 at
On Wed, Aug 11, 2021 at 01:16:18AM +, Matthew Brost wrote:
> Flush the work queue for GuC generated G2H messages durinr a GT reset.
> This is accomplished by spinning on the the list of outstanding G2H to
> go empty.
>
> Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC
>
On Wed, Aug 11, 2021 at 05:43:23PM +, Matthew Brost wrote:
> On Wed, Aug 11, 2021 at 11:55:48AM +0200, Daniel Vetter wrote:
> > On Mon, Aug 09, 2021 at 07:32:26PM +, Matthew Brost wrote:
> > > On Mon, Aug 09, 2021 at 07:17:27PM +0200, Daniel Vetter wrote:
> > > > On Tue, Aug 03, 2021 at
replace dma_mmap_attrs() with dma_mmap_coherent() kindly.
BTW, fix indentation.
Signed-off-by: Cai Huoqing
---
drivers/video/fbdev/au1200fb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/au1200fb.c b/drivers/video/fbdev/au1200fb.c
index
Aside from deleting lots of code the real motivation here is to switch
the mmap over to VM_PFNMAP, to be more consistent with what real gpu
drivers do. They're all VM_PFNMP, which means get_user_pages doesn't
work, and even if you try and there's a struct page behind that,
touching it and mucking
intel-gfx-ci realized that something is not quite coherent anymore on
some platforms for our i915+vgem tests, when I tried to switch vgem
over to shmem helpers.
After lots of head-scratching I realized that I've removed calls to
drm_clflush. And we need those. To make this a bit cleaner use the
We want to stop gup, which isn't the case if we use vmf_insert_page
and VM_MIXEDMAP, because that does not set pte_special.
The motivation here is to stop get_user_pages from working on buffer
object mmaps in general. Quoting some discussion with Thomas:
On Thu, Jul 22, 2021 at 08:22:43PM +0200,
tldr; DMA buffers aren't normal memory, expecting that you can use
them like that (like calling get_user_pages works, or that they're
accounting like any other normal memory) cannot be guaranteed.
Since some userspace only runs on integrated devices, where all
buffers are actually all resident
On Wed, Aug 11, 2021 at 01:04:01PM +0900, David Stevens wrote:
> Blob resources without the cross device flag don't have a uuid to share
> with other virtio devices. When exporting such blobs, set uuid_state to
> STATE_ERR so that virtgpu_virtio_get_uuid doesn't hang.
>
> Signed-off-by: David
On Thu, Jul 22, 2021 at 08:22:43PM +0200, Thomas Zimmermann wrote:
> Hi,
>
> I'm not knowledgeable enougth to give this a full review. If you can just
> answer my questions, fell free to add an
>
> Acked-by: Thomas Zimmermann
>
> to the patch. :)
>
> Am 13.07.21 um 22:51 schrieb Daniel
Hi,
> +static struct sg_table *virtgpu_gem_map_dma_buf(
> + struct dma_buf_attachment *attach,
> + enum dma_data_direction dir)
checkpatch doesn't like that:
-:47: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#47: FILE:
DG1 has support for local memory, which requires the usage of the
lmem placement extension for creating bo's, and memregion queries
to obtain the size. Because of this, those parts of the uapi are
no longer guarded behind FAKE_LMEM.
According to the pull request referenced below, mesa should be
This reverts commit fae352efb12196e7110f98bc1297ce533472764d.
Inside core-for-CI, reverting to make next patch apply cleanly.
---
drivers/gpu/drm/i915/i915_pci.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index
On 8/12/2021 1:41 PM, Michel Dänzer wrote:
On 2021-08-12 7:55 a.m., Koenig, Christian wrote:
Hi James,
Evan seems to have understood how this all works together.
See while any begin/end use critical section is active the work should not be
active.
When you handle only one ring you can
This reverts commit fae352efb12196e7110f98bc1297ce533472764d.
Inside core-for-CI, reverting to make next patch apply cleanly.
---
drivers/gpu/drm/i915/i915_pci.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index
see if anything breaks.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/Kconfig.debug | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index e7fd3e76f8a2..f27c0b5873f7 100644
---
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 1bbd09ad5287..93ccdc6bbd03 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++
On Wed, Aug 11, 2021 at 10:52:55AM -0500, Tom Lendacky wrote:
> On 8/11/21 7:19 AM, Kirill A. Shutemov wrote:
> > On Tue, Aug 10, 2021 at 02:48:54PM -0500, Tom Lendacky wrote:
> >> On 8/10/21 1:45 PM, Kuppuswamy, Sathyanarayanan wrote:
> >>>
> >>>
> >>> On 7/27/21 3:26 PM, Tom Lendacky wrote:
>
>> Raspberry Pi displaying video with subtitles or other controls. I was
>> thinking of the fullscreen case but if zero copy video can be made to
>> work to the main desktop then that would even better.
>>
>> If displaying 4k video the Pi does not have enough bandwidth left for a
>> single frame
Hi Doug,
On Mon, Aug 09, 2021 at 03:18:03PM -0700, Doug Anderson wrote:
> Hi,
>
> On Tue, Aug 3, 2021 at 1:41 PM Sam Ravnborg wrote:
> >
> > Hi Douglas,
> >
> > On Fri, Jul 30, 2021 at 02:26:19PM -0700, Douglas Anderson wrote:
> > > The goal of this patch series is to move away from hardcoding
On 2021-08-11 7:55 p.m., Mark Yacoub wrote:
> From: Mark Yacoub
>
> [Why]
> Userspace should get back a copy of the request that's been modified
> even when drm_wait_vblank_ioctl returns a failure.
>
> Rationale:
> drm_wait_vblank_ioctl modifies the request and expects the user to read
> back.
Hi Dave and Daniel,
only one bug fix in this week's drm-misc-fixes.
Best regards
Thomas
drm-misc-fixes-2021-08-12:
Short summary of fixes pull:
* meson: Fix colors when booting with HDR
The following changes since commit e89afb51f97ae03ee246c1fd0b47e3e491266aef:
drm/vmwgfx: Fix a 64bit
On 2021-08-12 7:55 a.m., Koenig, Christian wrote:
> Hi James,
>
> Evan seems to have understood how this all works together.
>
> See while any begin/end use critical section is active the work should not be
> active.
>
> When you handle only one ring you can just call cancel in begin use and
The vmw_gmrid_man_get_node() function calls vmw_host_printf() while
holding a spinlock so these functions need to be atomic. Generally,
no one expects printf() functions to sleep.
Fixes: cfdc3458db8a ("drm/vmwgfx: Be a lot more flexible with MOB limits")
Signed-off-by: Dan Carpenter
---
Add two more parameters to set spm_addr_dev0 & spm_addr_dev1
addresses. These two parameters configure the start SP
addresses for each device in test_hmm driver.
Consequently, this configures zone device type as generic.
Signed-off-by: Alex Sierra
---
tools/testing/selftests/vm/test_hmm.sh | 20
Device Generic type uses device memory that is coherently
accesible by the CPU. Usually, this is shown as SP
(special purpose) memory range at the BIOS-e820 memory
enumeration. If no SP memory is supported in system,
this could be faked by setting CONFIG_EFI_FAKE_MEMMAP.
Currently, test_hmm only
In order to configure device generic in test_hmm, two
module parameters should be passed, which correspon to the
SP start address of each device (2) spm_addr_dev0 &
spm_addr_dev1. If no parameters are passed, private device
type is configured.
v5:
Remove devmem->pagemap.type =
new ioctl cmd added to query zone device type. This will be
used once the test_hmm adds zone device generic type.
Signed-off-by: Alex Sierra
---
lib/test_hmm.c | 15 ++-
lib/test_hmm_uapi.h | 7 +++
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git
Device generic type case added for migrate_vma_pages and
migrate_vma_check_page helpers.
Both, generic and private device types have the same
conditions to decide to migrate pages from/to device
memory.
Signed-off-by: Alex Sierra
---
mm/migrate.c | 20 +---
1 file changed, 9
When CPU is connected throug XGMI, it has coherent
access to VRAM resource. In this case that resource
is taken from a table in the device gmc aperture base.
This resource is used along with the device type, which could
be DEVICE_PRIVATE or DEVICE_GENERIC to create the device
page map region.
From: Ralph Campbell
ZONE_DEVICE struct pages have an extra reference count that complicates the
code for put_page() and several places in the kernel that need to check the
reference count to see that a page is not being used (gup, compaction,
migration, etc.). Clean up the code so the reference
Test cases such as migrate_fault and migrate_multiple,
were modified to explicit migrate from device to sys memory
without the need of page faults, when using device generic
type.
Snapshot test case updated to read memory device type
first and based on that, get the proper returned results
Generic device type memory on VRAM to RAM migration,
has similar access as System RAM from the CPU. This flag sets
the source from the sender. Which in Generic type case,
should be set as SYSTEM.
Signed-off-by: Alex Sierra
Reviewed-by: Felix Kuehling
---
Add MEMORY_DEVICE_GENERIC case to free_zone_device_page callback.
Device generic type memory case is now able to free its pages properly.
Signed-off-by: Alex Sierra
---
mm/memremap.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/memremap.c b/mm/memremap.c
index
The AMD architecture for the Frontier supercomputer will
have device memory which can be coherently accessed by
the CPU. The system BIOS advertises this memory as SPM
(special purpose memory) in the UEFI system address map.
The AMDGPU driver needs to be able to lookup this resource
in order to
Two helpers added. One checks if zone device page is generic
type. The other if page is either private or generic type.
Signed-off-by: Alex Sierra
---
include/linux/mm.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index
From: Ralph Campbell
There are several places where ZONE_DEVICE struct pages assume a reference
count == 1 means the page is idle and free. Instead of open coding this,
add a helper function to hide this detail.
v3:
[AS]: rename dax_layout_is_idle_page func to dax_page_unused
v4:
[AS]: This
v1:
AMD is building a system architecture for the Frontier supercomputer with a
coherent interconnect between CPUs and GPUs. This hardware architecture allows
the CPUs to coherently access GPU device memory. We have hardware in our labs
and we are working with our partner HPE on the BIOS, firmware
84 matches
Mail list logo
