This series patches seems to make AGP aperture allowed to access any system
memory (16GB) bypass GPU VM protection.
If someone made a wrong logic requesting an illegal address which occasionally
was located inside AGP aperture,
but without any VM protection, the illegal address would be
On 2018年08月28日 03:03, Felix Kuehling wrote:
The point of this series seems to be to allow access to small system
memory BOs (one page) without a GART mapping. I'm guessing that reduces
pressure on the GART and removes the need for HDP and TLB flushes.
I think if adding these explain/reason to
On 08/27/2018 10:04 PM, Alex Deucher wrote:
On Mon, Aug 27, 2018 at 9:45 AM Christian König
wrote:
Looks like a copy error to me.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
Reviewed-by: Junwei Zhang
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 2 +-
1 file changed,
On 08/28/2018 12:53 AM, Christian König wrote:
Start to use the old AGP aperture for system memory access.
Signed-off-by: Christian König
Reviewed-by: Junwei Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 24 +
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h |
On 08/28/2018 12:53 AM, Christian König wrote:
Helper to figure out the location of the AGP BAR.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 42 +
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h | 5 +++
2 files changed, 47 insertions(+)
On 08/28/2018 12:53 AM, Christian König wrote:
Most of the time we only need to know if the BO has a valid GMC addr.
Signed-off-by: Christian König
good to see this cleanup :)
Reviewed-by: Junwei Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 --
On 08/28/2018 03:07 AM, Alex Deucher wrote:
On Mon, Aug 27, 2018 at 12:56 PM Christian König
wrote:
Further separate GART and GTT domain.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
Reviewed-by: Junwei Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 3 ++-
On 08/28/2018 09:56 AM, Zhang, Jerry (Junwei) wrote:
On 08/28/2018 12:53 AM, Christian König wrote:
Only use the lower address space on GMC9 for the system domain.
Otherwise we would need to sign extend GMC addresses.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
On 08/28/2018 12:53 AM, Christian König wrote:
Always try to put the GART away from where VRAM is.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
On 08/28/2018 03:05 AM, Alex Deucher wrote:
On Mon, Aug 27, 2018 at 12:55 PM Christian König
wrote:
Instead of the larger one use the smaller hole in the MC address
space for the GART mappings.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
Reviewed-by: Junwei Zhang
---
On 08/28/2018 12:53 AM, Christian König wrote:
Improve the VCE limitation handling.
Signed-off-by: Christian König
Reviewed-by: Junwei Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 28 -
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git
On 08/28/2018 02:59 AM, Alex Deucher wrote:
On Mon, Aug 27, 2018 at 12:56 PM Christian König
wrote:
Move that into amdgpu_gmc.c since we are really deadling with GMC
address space here.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
Reviewed-by: Junwei Zhang
---
On 08/28/2018 12:53 AM, Christian König wrote:
Only use the lower address space on GMC9 for the system domain.
Otherwise we would need to sign extend GMC addresses.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 7 +++
1 file changed, 3 insertions(+), 4
This is the next version of my patch series for teaching DRM how to
automatically create debugfs nodes for drivers with MST topologies. This
was originally intended just for nouveau, but has since been expanded to
all DRM drivers.
Cc: Maarten Lankhorst
Cc: Daniel Stone
Lyude Paul (4):
There's no actual reason we pass the connector ID instead of a pointer
to the connector itself, and we're going to need the entire connector
(but only temporarily) in order to name MST debugfs folders properly
since connector IDs can't be looked up until the driver has been
registered with
Thank you Felix. That is a great point. I will update patch.
Thanks,
Oak
-Original Message-
From: Kuehling, Felix
Sent: Monday, August 27, 2018 4:05 PM
To: Oak Zeng ; amd-gfx@lists.freedesktop.org
Cc: Zeng, Oak
Subject: Re: [PATCH 2/2] drm/amdkfd: Release an acquired process vm
On
On 2018-08-27 03:25 PM, Oak Zeng wrote:
> For compute vm acquired from amdgpu, vm.pasid is managed
> by kfd. Decouple pasid from such vm on process destroy
> to avoid duplicate pasid release.
>
> Signed-off-by: Oak Zeng
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 1 +
>
On 2018-08-27 03:25 PM, Oak Zeng wrote:
> To make a amdgpu vm to a compute vm, the old pasid will be freed and
> replaced with a pasid managed by kfd. Kfd can't reuse original pasid
> allocated by amdgpu because kfd uses different pasid policy with amdgpu.
> For example, all graphic devices share
To make a amdgpu vm to a compute vm, the old pasid will be freed and
replaced with a pasid managed by kfd. Kfd can't reuse original pasid
allocated by amdgpu because kfd uses different pasid policy with amdgpu.
For example, all graphic devices share one same pasid in a process.
Signed-off-by: Oak
For compute vm acquired from amdgpu, vm.pasid is managed
by kfd. Decouple pasid from such vm on process destroy
to avoid duplicate pasid release.
Signed-off-by: Oak Zeng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 1 +
Hi Alex/Felix,
I submitted a new patch to address below comments.
I also come up with another patch to release a compute vm on kfd process
destroy, to address a pasid duplicate release (from both kfd and amdgpu
side)issue.
Please help to review.
Thanks,
Oak
-Original Message-
From:
On 2018-08-24 10:34 AM, Amber Lin wrote:
> Since KFD is only supported by single GPU driver, it makes sense to merge
> amdgpu and amdkfd into one module. This patch is the initial step: merge
> Kconfig and Makefile.
>
> v2: also remove kfd from drm Kconfig
>
> Change-Id:
On 2018-08-24 11:08 AM, Amber Lin wrote:
> After merging KFD into amdgpu, move module parameters defined in KFD to
> amdgpu_drv.c, where other module parameters are declared.
>
> v2: add kernel-doc comments
>
> Change-Id: I2de8d6c96bb49554c028bbc84bdb194f974c9278
> Signed-off-by: Amber Lin
Reviewed-by: Marek Olšák
Marek
On Mon, Aug 27, 2018 at 2:55 PM, Alex Deucher wrote:
> On Mon, Aug 27, 2018 at 2:23 PM Andrey Grodzovsky
> wrote:
>>
>> The fault reports the page number where the fault happend and not
>> the exact faulty address. Update the print message to reflect that.
>>
>>
On Mon, Aug 27, 2018 at 12:56 PM Christian König
wrote:
>
> Further separate GART and GTT domain.
>
> Signed-off-by: Christian König
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 3 ++-
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +++---
> 2 files
On Mon, Aug 27, 2018 at 12:55 PM Christian König
wrote:
>
> Instead of the larger one use the smaller hole in the MC address
> space for the GART mappings.
>
> Signed-off-by: Christian König
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 3 ++-
> 1 file changed,
The point of this series seems to be to allow access to small system
memory BOs (one page) without a GART mapping. I'm guessing that reduces
pressure on the GART and removes the need for HDP and TLB flushes. Why
does Patch 10 only enable that on GFXv9? Is there less benefit on older
chips?
Is
On Mon, Aug 27, 2018 at 12:55 PM Christian König
wrote:
>
> Improve the VCE limitation handling.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 28 -
> 1 file changed, 13 insertions(+), 15 deletions(-)
>
> diff --git
On Mon, Aug 27, 2018 at 12:56 PM Christian König
wrote:
>
> Move that into amdgpu_gmc.c since we are really deadling with GMC
> address space here.
>
> Signed-off-by: Christian König
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h| 4 --
>
On Mon, Aug 27, 2018 at 12:56 PM Christian König
wrote:
>
> Only use the lower address space on GMC9 for the system domain.
> Otherwise we would need to sign extend GMC addresses.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 7 +++
> 1 file changed, 3
On 2018-08-27 12:53 PM, Christian König wrote:
> Most of the time we only need to know if the BO has a valid GMC addr.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 --
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
>
On Mon, Aug 27, 2018 at 2:23 PM Andrey Grodzovsky
wrote:
>
> The fault reports the page number where the fault happend and not
> the exact faulty address. Update the print message to reflect that.
>
> Signed-off-by: Andrey Grodzovsky
Reviewed-by: Alex Deucher
> ---
>
On 2018-08-27 12:53 PM, Christian König wrote:
> Helper to figure out the location of the AGP BAR.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 42 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h | 5 +++
> 2 files changed, 47
The fault reports the page number where the fault happend and not
the exact faulty address. Update the print message to reflect that.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Looks like you resume from suspend went bad and hence you have latter
trouble in shutting down.
Please open FDO ticket for this (https://bugs.freedesktop.org/) + attach
full dmesg log without grep.
S3 was working before so looks like regression.
Try maybe 4.17 kernel and if you find it
Enable the old AGP aperture to avoid GART mappings.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c | 10 +-
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c| 1 +
drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c | 10 +-
3 files changed, 11 insertions(+), 10
Start to use the old AGP aperture for system memory access.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 24 +
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 9
Further separate GART and GTT domain.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +++---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
Helper to figure out the location of the AGP BAR.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 42 +
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h | 5 +++
2 files changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
Instead of the larger one use the smaller hole in the MC address
space for the GART mappings.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
Most of the time we only need to know if the BO has a valid GMC addr.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 --
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 13 +
3 files changed, 6
Improve the VCE limitation handling.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 28 -
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
Always try to put the GART away from where VRAM is.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
index
Move that into amdgpu_gmc.c since we are really deadling with GMC
address space here.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 4 --
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 65 --
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c| 64
Only use the lower address space on GMC9 for the system domain.
Otherwise we would need to sign extend GMC addresses.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git
Hi everybody , I am trying to resolve various problems I observe when
logically removing AMDGPU device from pci - echo 1 >
/sys/class/drm/card0/device/remove
One of the problems I encountered was hitting WARNs in
amdgpu_gem_force_release. It complaints about still open client FDs and
BOs
> -Original Message-
> From: amd-gfx On Behalf Of Felix
> Kuehling
> Sent: Friday, August 24, 2018 5:58 PM
> To: Deucher, Alexander ; Koenig, Christian
> ; Oded Gabbay ;
> Dave Airlie
> Cc: amd-gfx list
> Subject: Re: KFD co-maintainership and branch model
>
> On 2018-08-23 08:38 AM,
On Mon, Aug 27, 2018 at 9:45 AM Christian König
wrote:
>
> Looks like a copy error to me.
>
> Signed-off-by: Christian König
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Mon, Aug 27, 2018 at 12:04 AM Quan, Evan wrote:
>
> Hi @Deucher, Alexander & @Zhu, Rex,
>
>
> I can remove the od setings for power limit and fan speed related since they
> seem redundant with other sysfs apis.
>
> But for the clock/voltage related, i can not see how to reuse old
>
Looks like a copy error to me.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index 66abfcf87ad0..ad40acb236bc 100644
---
Add DisplayPort CEC-Tunneling-over-AUX support to amdgpu.
Signed-off-by: Hans Verkuil
Acked-by: Alex Deucher
Reviewed-by: Harry Wentland
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c| 9 -
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 ++
2 files
When parsing the reply of a DP_REMOTE_DPCD_READ DPCD command the
result is wrong due to a missing idx increment.
This was never noticed since DP_REMOTE_DPCD_READ is currently not
used, but if you enable it, then it is all wrong.
Signed-off-by: Hans Verkuil
Reviewed-by: Lyude Paul
Acked-by:
Add DisplayPort CEC-Tunneling-over-AUX support to nouveau.
Signed-off-by: Hans Verkuil
Reviewed-by: Lyude Paul
Acked-by: Alex Deucher
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git
From: Hans Verkuil
Now that the DisplayPort CEC-Tunneling-over-AUX drm+i915 support
has been merged in the mainline kernel it is time to roll this
out to nouveau and amdgpu as well.
The first patch is required for this: it adds checks that the drm_dp_cec
functions are called with a working aux
From: Hans Verkuil
A big problem with DP CEC-Tunneling-over-AUX is that it is tricky
to find adapters with a chipset that supports this AND where the
manufacturer actually connected the HDMI CEC line to the chipset.
Add a mention of the MegaChips 2900 chipset which seems to support
this feature
From: Hans Verkuil
When parsing the reply of a DP_REMOTE_DPCD_READ DPCD command the
result is wrong due to a missing idx increment.
This was never noticed since DP_REMOTE_DPCD_READ is currently not
used, but if you enable it, then it is all wrong.
Signed-off-by: Hans Verkuil
Reviewed-by:
From: Hans Verkuil
If aux->transfer == NULL, then just return without doing
anything. In that case the function is likely called for
a non-(e)DP connector.
This never happened for the i915 driver, but the nouveau and amdgpu
drivers need this check.
The alternative would be to add this check in
On 2018/08/24 22:52, Michal Hocko wrote:
> @@ -180,11 +180,15 @@ void amdgpu_mn_unlock(struct amdgpu_mn *mn)
> */
> static int amdgpu_mn_read_lock(struct amdgpu_mn *amn, bool blockable)
> {
> - if (blockable)
> - mutex_lock(>read_lock);
> - else if
Am 26.08.2018 um 10:40 schrieb Tetsuo Handa:
On 2018/08/24 22:52, Michal Hocko wrote:
@@ -180,11 +180,15 @@ void amdgpu_mn_unlock(struct amdgpu_mn *mn)
*/
static int amdgpu_mn_read_lock(struct amdgpu_mn *amn, bool blockable)
{
- if (blockable)
-
59 matches
Mail list logo
