Currently the SVM get_attr call allows querying, which flags are set
in the entire address range. Add the opposite query, which flags are
clear in the entire address range. Both queries can be combined in a
single get_attr call, which allows answering questions such as, "is
this address range coher
Am 2021-07-16 um 11:07 a.m. schrieb Theodore Y. Ts'o:
> On Wed, Jun 23, 2021 at 05:49:55PM -0400, Felix Kuehling wrote:
>> I can think of two ways to test the changes for MEMORY_DEVICE_GENERIC in
>> this patch series in a way that is reproducible without special hardware and
>> firmware:
>>
>> For
On 2021-07-16 4:29 p.m., Alex Deucher
wrote:
On Wed, Jul 14, 2021 at 1:58 PM Luben Tuikov wrote:
This fixes a bug which if we probe a non-existing
I2C device, and the SMU returns 0xFF, from then on
we can never communicate with the SMU, because the
co
Similar to xGMI reporting the min/max bandwidth between direct peers, PCIe
will report the min/max bandwidth to the KFD.
v2: change to bandwidth
Signed-off-by: Jonathan Kim
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 61 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h |
Report the min/max bandwidth in megabytes to the kfd for direct
xgmi connections only.
v2: change reporting from num links to bandwidth
Signed-off-by: Jonathan Kim
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 23 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 1 +
driv
The TA can now be invoked to provide the number of xgmi links connecting
a direct source and destination peer.
Non-direct peers will report zero links.
Signed-off-by: Jonathan Kim
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 23 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h |
On Wed, Jul 14, 2021 at 1:58 PM Luben Tuikov wrote:
>
> This fixes a bug which if we probe a non-existing
> I2C device, and the SMU returns 0xFF, from then on
> we can never communicate with the SMU, because the
> code before this patch reads and interprets 0xFF
> as a terminal error, and thus we
Patches 3 and 5 are
Reviewed-by: Felix Kuehling
Am 2021-07-16 um 11:36 a.m. schrieb Oak Zeng:
> start_cpsch and stop_cpsch can be called during kfd device
> initialization or during gpu reset/recovery. So they can
> run concurrently. Currently in start_cpsch and stop_cpsch,
> pm_init and pm_uni
This variable will be used to determine whether packet
manager is initialized or not, in a future patch.
Signed-off-by: Oak Zeng
Acked-by: Christian Konig
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers
Oak Zeng (5):
drm/amdgpu: Fix a printing message
drm/amdgpu: Change a few function names
drm/amdkfd: Renaming dqm->packets to dqm->packet_mgr
drm/amdkfd: Set priv_queue to NULL after it is freed
drm/amdkfd: Fix a concurrency issue during kfd recovery
drivers/gpu/drm/amd/amdgpu/amdgpu_ps
The printing message "PSP loading VCN firmware" is mis-leading because
people might think driver is loading VCN firmware. Actually when this
message is printed, driver is just preparing some VCN ucode, not loading
VCN firmware yet. The actual VCN firmware loading will be in the PSP block
hw_init. F
Function name "psp_np_fw_load" is not proper as people don't
know _np_fw_ means "non psp firmware". Change the function
name to psp_load_non_psp_fw for better understanding. Same
thing for function psp_execute_np_fw_load.
Signed-off-by: Oak Zeng
Reviewed-by: Alex Deucher
Reviewed-by: Christian K
start_cpsch and stop_cpsch can be called during kfd device
initialization or during gpu reset/recovery. So they can
run concurrently. Currently in start_cpsch and stop_cpsch,
pm_init and pm_uninit is not protected by the dpm lock.
Imagine such a case that user use packet manager's function
to submi
Renaming packets to packet_mgr to reflect the real meaning
of this variable.
Signed-off-by: Oak Zeng
Acked-by: Christian Konig
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c| 2 +-
.../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 26 +++---
.../gpu/drm/amd/amdkfd/k
Am 2021-07-15 um 9:34 p.m. schrieb Oak Zeng:
> start_cpsch and stop_cpsch can be called during kfd device
> initialization or during gpu reset/recovery. So they can
> run concurrently. Currently in start_cpsch and stop_cpsch,
> pm_init and pm_uninit is not protected by the dpm lock.
> Imagine such
Am 2021-07-15 um 9:34 p.m. schrieb Oak Zeng:
> This variable will be used to determine whether packet
> manager is initialized or not, in a future patch.
>
> Signed-off-by: Oak Zeng
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c | 1 +
> 1 file changed, 1
Am 2021-07-15 um 9:34 p.m. schrieb Oak Zeng:
> Renaming packets to dpm (device packet manager) to
> reflect the real meaning of this variable.
I don't think introducing another new acronym is helpful. Also "dpm" and
"dqm" are visually too similar. Other places use "pm" for packet
manager. If you f
[Public]
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Oak Zeng
Sent: Thursday, July 15, 2021 9:25 PM
To: amd-gfx@lists.freedesktop.org
Cc: Xu, Feifei ; Kuehling, Felix ;
Liu, Leo ; Zeng, Oak ; Zhang, Hawking
Subject: [PATCH 2/5] drm/amdgpu: Change
[Public]
Please use dev_info rather than DRM_INFO.
Alex
From: amd-gfx on behalf of Oak Zeng
Sent: Thursday, July 15, 2021 9:25 PM
To: amd-gfx@lists.freedesktop.org
Cc: Xu, Feifei ; Kuehling, Felix ;
Liu, Leo ; Zeng, Oak ; Zhang, Hawking
Subject: [PATCH 1/5
On Sun, Jul 11, 2021 at 10:45:48AM -0700, Joe Perches wrote:
> On Sun, 2021-07-11 at 19:24 +0200, Len Baker wrote:
> > The branches of the "if" statement are the same. So remove the
> > unnecessary if and goto statements.
> >
> > Addresses-Coverity-ID: 1456916 ("Identical code for different branche
On Wed, Jun 23, 2021 at 05:49:55PM -0400, Felix Kuehling wrote:
>
> I can think of two ways to test the changes for MEMORY_DEVICE_GENERIC in
> this patch series in a way that is reproducible without special hardware and
> firmware:
>
> For the reference counting changes we could use the dax drive
Applied. Thanks!
Alex
On Thu, Jul 15, 2021 at 3:40 PM Harry Wentland wrote:
>
>
>
> On 2021-07-15 3:19 p.m., Mario Kleiner wrote:
> > On Thu, Jul 15, 2021 at 6:10 PM Alex Deucher wrote:
> >>
> >> On Wed, Jul 14, 2021 at 4:15 AM Liviu Dudau wrote:
> >>>
> >>> Commit 72a7cf0aec0c ("drm/amd/disp
Am 16.07.21 um 10:23 schrieb Kevin Wang:
split amdgpu_device_access_vram()
1. amdgpu_device_mm_access(): using MM_INDEX/MM_DATA to access vram
2. amdgpu_device_aper_access(): using vram aperature to access vram (option)
Signed-off-by: Kevin Wang
Reviewed-by: Christian König for the series.
using exiting function to replace duplicate code blocks in
amdgpu_ttm_vram_write().
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgp
split amdgpu_device_access_vram()
1. amdgpu_device_mm_access(): using MM_INDEX/MM_DATA to access vram
2. amdgpu_device_aper_access(): using vram aperature to access vram (option)
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 7 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_d
1. using vram aper to access vram if possible
2. avoid MM_INDEX/MM_DATA is not working when mmio protect feature is
enabled.
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 84 ++---
1 file changed, 49 insertions(+), 35 deletions(-)
diff --git a/drive
Am 15.07.21 um 21:05 schrieb Felix Kuehling:
KFD Thunk maps invisible VRAM BOs with PROT_NONE, MAP_PRIVATE.
is_cow_mapping returns true for these mappings, which causes mmap to fail
in ttm_bo_mmap_obj.
As a workaround, clear VM_MAYWRITE for PROT_NONE-COW mappings. This
should prevent the mapping
On Fri, Jul 16, 2021 at 08:16:27AM +0200, Christoph Hellwig wrote:
> Hi all,
>
> this series cleans up a bunch of lose ends in the vgaarb code.
>
> Diffstat:
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 11 +-
> drivers/gpu/drm/drm_irq.c |4
> drivers/gpu/drm/i915/displ
Am 16.07.21 um 08:16 schrieb Christoph Hellwig:
The define is entirely unused.
Signed-off-by: Christoph Hellwig
I'm not an expert for this particular code, but at least of hand
everything you do here makes totally sense.
Whole series is Acked-by: Christian König
Regards,
Christian.
---
Am 16.07.21 um 05:10 schrieb Kevin Wang:
1. using vram aper to access vram if possible
2. avoid MM_INDEX/MM_DATA is not working when mmio protect feature is
enabled.
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 91 +++--
1 file changed, 54 in
On 7/16/2021 7:04 AM, Oak Zeng wrote:
start_cpsch and stop_cpsch can be called during kfd device
initialization or during gpu reset/recovery. So they can
run concurrently. Currently in start_cpsch and stop_cpsch,
pm_init and pm_uninit is not protected by the dpm lock.
Imagine such a case that
Am 16.07.21 um 03:34 schrieb Oak Zeng:
The printing message "PSP loading VCN firmware" is mis-leading because
people might think driver is loading VCN firmware. Actually when this
message is printed, driver is just preparing some VCN ucode, not loading
VCN firmware yet. The actual VCN firmware lo
The VGA arbitration is entirely based on pci_dev structures, so just pass
that back to the set_vga_decode callback.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 9
drivers/gpu/drm/i915/display/intel_vga.c | 7 ---
drivers/gpu/drm/nouveau/nouv
Add a trivial wrapper for the unregister case that sets all fields to
NULL.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
drivers/gpu/drm/drm_irq.c | 4 ++--
drivers/gpu/drm/i915/display/intel_vga.c | 2 +-
drivers/gpu/drm/nouveau/nouv
Merge the different CONFIG_VGA_ARB ifdef blocks, remove superflous
externs, and regularize the stubs for !CONFIG_VGA_ARB.
Signed-off-by: Christoph Hellwig
---
include/linux/vgaarb.h | 90 --
1 file changed, 42 insertions(+), 48 deletions(-)
diff --git a/i
The define is entirely unused.
Signed-off-by: Christoph Hellwig
---
include/linux/vgaarb.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h
index dc6ddce92066..26ec8a057d2a 100644
--- a/include/linux/vgaarb.h
+++ b/include/linux/vgaarb.h
@@
Hi all,
this series cleans up a bunch of lose ends in the vgaarb code.
Diffstat:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 11 +-
drivers/gpu/drm/drm_irq.c |4
drivers/gpu/drm/i915/display/intel_vga.c |9 +-
drivers/gpu/drm/nouveau/nouveau_vga.c |8 -
dr
All callers pass NULL as the irq_set_state argument, so remove it and
the ->irq_set_state member in struct vga_device.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
drivers/gpu/drm/i915/display/intel_vga.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_vga.
Kerneldoc comments should be at the implementation side, not in the
header just declaring the prototype.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/vga/vgaarb.c | 11 +++
include/linux/vgaarb.h | 13 -
2 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/d
vga_conflicts only has a single caller and none of the arch overrides
mentioned in the comment. Just remove it and the thus dead check in the
caller.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/vga/vgaarb.c | 6 --
include/linux/vgaarb.h | 12
2 files changed, 18 deleti
using exiting function to replace duplicate code blocks in
amdgpu_ttm_vram_write().
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgp
split amdgpu_device_access_vram()
1. amdgpu_device_mm_access(): using MM_INDEX/MM_DATA to access vram
2. amdgpu_device_aper_access(): using vram aperature to access vram (option)
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 7 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_d
1. using vram aper to access vram if possible
2. avoid MM_INDEX/MM_DATA is not working when mmio protect feature is
enabled.
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 91 +++--
1 file changed, 54 insertions(+), 37 deletions(-)
diff --git a/drive
43 matches
Mail list logo