[AMD Public Use]
Reviewed-by: Huang Rui
-Original Message-
From: Hou, Xiaomeng (Matthew)
Sent: Thursday, December 10, 2020 9:00 PM
To: amd-gfx@lists.freedesktop.org
Cc: Huang, Ray ; Gao, Likun ; Hou,
Xiaomeng (Matthew)
Subject: [PATCH] drm/amdgpu/sdma5.2: soft reset sdma blocks
I demand that Christian König may or may not have written...
> Am 10.12.20 um 14:59 schrieb Darren Salt:
> > I demand that Christian König may or may not have written...
> >
[snip]
>> My current kernel has another patch, applied on top of this patch, which
>> allows ignoring the size list. As
On 11/12/20 12:18 am, Aurabindo Pillai wrote:
> [Why]
> If experimental freesync video mode module parameter is enabled, add
> few extra display modes into the driver's mode list corresponding to common
> video frame rates. When userspace sets these modes, no modeset will be
> performed (if
LGTM,
Please feel free to use
Reviewed-by: Shashank Sharma
Regards
Shashank
On 11/12/20 12:18 am, Aurabindo Pillai wrote:
> [Why]
> Adds a module parameter to enable experimental freesync video mode modeset
> optimization. Enabling this mode allows the driver to skip a full modeset when
>
On 10/12/20 11:20 pm, Aurabindo Pillai wrote:
> On Thu, 2020-12-10 at 18:29 +0530, Shashank Sharma wrote:
>> On 10/12/20 8:15 am, Aurabindo Pillai wrote:
>>> [Why]
>>> Inorder to enable freesync video mode, driver adds extra
>>> modes based on preferred modes for common freesync frame rates.
>>>
Some cards don't advertise a BAR size which covers all of the VRAM.
Mine, a Sapphire RX 5600 XT Pulse, advertises only 256MB, 512MB and 1GB.
Despite this, it works fine with the full 6GB visible via an 8GB BAR.
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 2 +-
This is intended for devices which are known to work with BAR sizes other
than those which they advertise; usually larger.
---
drivers/pci/setup-res.c | 4 ++--
include/linux/pci.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/setup-res.c
This is to assist driver modules which do BAR resizing.
Signed-off-by: Darren Salt
---
drivers/pci/pci.h | 4
include/linux/pci.h | 9 +
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 8373d94414e9..9a3837a30369 100644
This is to assist driver modules which do BAR resizing.
Signed-off-by: Darren Salt
---
drivers/pci/pci.c | 2 ++
drivers/pci/pci.h | 2 --
include/linux/pci.h | 4
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 9 +
3 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index
This is coarse, applying to all dGPUs.
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 +++-
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 9 +
3 files changed, 17 insertions(+), 1 deletion(-)
diff --git
This allows BAR0 resizing to be done for cards which don't advertise support
for a size large enough to cover the VRAM but which do advertise at least
one size larger than the default. For example, my RX 5600 XT, which
advertises 256MB, 512MB and 1GB.
[v2] rewritten to use PCI helper functions;
This patch series improves the existing BAR resizing support in amdgpu. By
default, it will attempt to resize BAR0 for each dGPU present to cover the
VRAM, falling back to smaller sizes if necessary, e.g. if there's not enough
address space remaining or support for the size is not advertised.
Hello Simon,
Hope you are doing well,
I was helping out Aurabindo and the team with the design, so I have taken the
liberty of adding some comments on behalf of the team, Inline.
On 11/12/20 3:31 am, Simon Ser wrote:
> Hi,
>
> (CC dri-devel, Pekka and Martin who might be interested in this as
[AMD Official Use Only - Internal Distribution Only]
Series is acked-by: Evan Quan
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Friday, December 11, 2020 5:45 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH 7/7] drm/amdgpu: print what
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Evan Quan
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Friday, December 11, 2020 5:45 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH 7/7] drm/amdgpu: print what method we
Hi,
(CC dri-devel, Pekka and Martin who might be interested in this as well.)
On Thursday, December 10th, 2020 at 7:48 PM, Aurabindo Pillai
wrote:
> This patchset enables freesync video mode usecase where the userspace
> can request a freesync compatible video mode such that switching to this
Simplify the logic in the runtime resume handling for
atpx
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index
Check if the device has ACPI power resources so we can
enable runtime pm if so.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 4
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
The platform knows it's doing d3cold.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index
So we know when it's enabled and what method we are using.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index
Enable runtime pm on non HG/PX BOCO capable boards.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index
Change it to check if the device has ACPI power resources.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
In preparation for systems that support d3cold on dGPUs
independent of PX/HG. No functional change intended.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 33 --
Am 10.12.20 um 14:59 schrieb Darren Salt:
I demand that Christian König may or may not have written...
Am 10.12.20 um 01:57 schrieb Darren Salt:
This allows BAR0 resizing to be done for cards which don't advertise
support for a size large enough to cover the VRAM but which do advertise
at
I demand that Christian König may or may not have written...
> Am 10.12.20 um 01:57 schrieb Darren Salt:
>> This allows BAR0 resizing to be done for cards which don't advertise
>> support for a size large enough to cover the VRAM but which do advertise
>> at least one size larger than the
[Why]
Inorder to enable freesync video mode, driver adds extra
modes based on preferred modes for common freesync frame rates.
When commiting these mode changes, a full modeset is not needed.
If the change in only in the front porch timing value, skip full
modeset and continue using the same
[Why]
If experimental freesync video mode module parameter is enabled, add
few extra display modes into the driver's mode list corresponding to common
video frame rates. When userspace sets these modes, no modeset will be
performed (if current mode was one of freesync modes or the base freesync
[Why]
Adds a module parameter to enable experimental freesync video mode modeset
optimization. Enabling this mode allows the driver to skip a full modeset when
freesync compatible modes are requested by the userspace. This paramters also
adds some standard modes based on the connected monitor's
Changes in V2
=
1) Add freesync video modes based on preferred modes:
* Remove check for connector type before adding freesync compatible
modes as VRR support is being checked, and there is no reason to block
freesync video support on eDP.
* use drm_mode_equal() instead of
Series is:
Reviewed-by: Alex Deucher
On Wed, Dec 9, 2020 at 10:29 AM Hawking Zhang wrote:
>
> GUI_IDLE interrupts controlled by CP_INT_CNTL_RING0
> are only applicable to me0 pipe0.
>
> For ASICs that have gfx pipe removed, don't toggle
> those bits.
>
> Signed-off-by: Hawking Zhang
>
On Thu, 2020-12-10 at 18:29 +0530, Shashank Sharma wrote:
> On 10/12/20 8:15 am, Aurabindo Pillai wrote:
> > [Why]
> > Inorder to enable freesync video mode, driver adds extra
> > modes based on preferred modes for common freesync frame rates.
> > When commiting these mode changes, a full modeset
On 10/12/20 9:23 pm, Alex Deucher wrote:
> On Thu, Dec 10, 2020 at 8:03 AM Shashank Sharma
> wrote:
>>
>> On 10/12/20 3:58 pm, Christian König wrote:
>>> Am 10.12.20 um 05:49 schrieb Shashank Sharma:
On 09/12/20 11:00 pm, Alex Deucher wrote:
> On Fri, Dec 4, 2020 at 3:41 PM Alex
Hi Shashank,
Thanks for the review. Please see my inline responses.
On Thu, 2020-12-10 at 18:07 +0530, Shashank Sharma wrote:
> Hello Aurabindo,
>
>
> On 10/12/20 8:15 am, Aurabindo Pillai wrote:
>
> > [Why]
> > If experimental freesync video mode module parameter is enabled,
> > add
> > few
On Wed, Dec 9, 2020 at 11:49 PM Shashank Sharma wrote:
>
>
> On 09/12/20 11:00 pm, Alex Deucher wrote:
> > On Fri, Dec 4, 2020 at 3:41 PM Alex Deucher wrote:
> >> And drop it when we detach. If the shared buffer is in vram,
> >> we need to make sure we don't put the device into runtime
> >>
On Thu, Dec 10, 2020 at 8:03 AM Shashank Sharma wrote:
>
>
> On 10/12/20 3:58 pm, Christian König wrote:
> > Am 10.12.20 um 05:49 schrieb Shashank Sharma:
> >> On 09/12/20 11:00 pm, Alex Deucher wrote:
> >>> On Fri, Dec 4, 2020 at 3:41 PM Alex Deucher wrote:
> And drop it when we detach.
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Alex Deucher
From: amd-gfx on behalf of Xiaomeng Hou
Sent: Thursday, December 10, 2020 7:59 AM
To: amd-gfx@lists.freedesktop.org
Cc: Gao, Likun ; Huang, Ray ; Hou,
Xiaomeng (Matthew)
Subject:
[AMD Public Use]
Reviewed-by: Alex Deucher
From: Quan, Evan
Sent: Thursday, December 10, 2020 3:44 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Quan, Evan
Subject: [PATCH] drm/amd/pm: add deep sleep control for uclk and fclk
These are
[AMD Public Use]
Series is:
Reviewed-by: Alex Deucher
From: Quan, Evan
Sent: Thursday, December 10, 2020 2:10 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Quan, Evan
Subject: [PATCH 2/2] drm/amd/pm: update the data strucutre for SMU metrics
On Thu, Dec 10, 2020 at 08:56:08AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 09.12.20 um 19:04 schrieb Jeremy Cline:
> > Hi,
> >
> > On Tue, Dec 01, 2020 at 11:35:35AM +0100, Thomas Zimmermann wrote:
> > > Using struct drm_device.pdev is deprecated. Convert nouveau to struct
> > >
On 10/12/20 3:58 pm, Christian König wrote:
> Am 10.12.20 um 05:49 schrieb Shashank Sharma:
>> On 09/12/20 11:00 pm, Alex Deucher wrote:
>>> On Fri, Dec 4, 2020 at 3:41 PM Alex Deucher wrote:
And drop it when we detach. If the shared buffer is in vram,
we need to make sure we don't
Without doing the soft reset, register mmSDMA0_GFX_RB_WPTR's value could not be
reset to 0 when sdma block resumes. That would cause the ring buffer's read and
write pointers not equal and ring test fail. So add the soft reset step.
Signed-off-by: Xiaomeng Hou
---
On 10/12/20 8:15 am, Aurabindo Pillai wrote:
> [Why]
> Inorder to enable freesync video mode, driver adds extra
> modes based on preferred modes for common freesync frame rates.
> When commiting these mode changes, a full modeset is not needed.
> If the change in only in the front porch timing
Hello Aurabindo,
On 10/12/20 8:15 am, Aurabindo Pillai wrote:
> [Why]
> If experimental freesync video mode module parameter is enabled, add
> few extra display modes into the driver's mode list corresponding to common
> video frame rates. When userspace sets these modes, no modeset will be
>
Hi
Am 09.12.20 um 19:04 schrieb Jeremy Cline:
Hi,
On Tue, Dec 01, 2020 at 11:35:35AM +0100, Thomas Zimmermann wrote:
Using struct drm_device.pdev is deprecated. Convert nouveau to struct
drm_device.dev. No functional changes.
Signed-off-by: Thomas Zimmermann
Cc: Ben Skeggs
---
Hi
Am 10.12.20 um 10:03 schrieb Jani Nikula:
On Tue, 08 Dec 2020, Thomas Zimmermann wrote:
ping for a review of the i915 patches
What did you have in mind regarding merging the series? Should we just
pick the patches up?
Originally I thought that individual trees would merge their rsp
Am 10.12.20 um 05:49 schrieb Shashank Sharma:
On 09/12/20 11:00 pm, Alex Deucher wrote:
On Fri, Dec 4, 2020 at 3:41 PM Alex Deucher wrote:
And drop it when we detach. If the shared buffer is in vram,
we need to make sure we don't put the device into runtime
suspend.
Signed-off-by: Alex
Am 10.12.20 um 03:45 schrieb Aurabindo Pillai:
[Why]
Inorder to enable freesync video mode, driver adds extra
modes based on preferred modes for common freesync frame rates.
When commiting these mode changes, a full modeset is not needed.
If the change in only in the front porch timing value,
Am 10.12.20 um 01:57 schrieb Darren Salt:
This allows BAR0 resizing to be done for cards which don't advertise support
for a size large enough to cover the VRAM but which do advertise at least
one size larger than the default. For example, my RX 5600 XT, which
advertises 256MB, 512MB and 1GB.
Am 09.12.20 um 19:55 schrieb Darren Salt:
On the resize attempt failing with -EINVAL, instead report an informational
message indicating that the requested BAR size is not listed as supported by
the VBIOS.
Without this, as I have an RX 5600 XT which lists only 256MB, 512MB and
1024MB as
On 10/12/2020 02:14, Luben Tuikov wrote:
This patch does not change current behaviour.
The driver's job timeout handler now returns
status indicating back to the DRM layer whether
the task (job) was successfully aborted or whether
more time should be given to the task to complete.
I find the
Am 10.12.20 um 10:31 schrieb Lucas Stach:
Hi Luben,
Am Mittwoch, den 09.12.2020, 21:14 -0500 schrieb Luben Tuikov:
[SNIP]
-static void etnaviv_sched_timedout_job(struct drm_sched_job *sched_job)
+static enum drm_task_status etnaviv_sched_timedout_job(struct drm_sched_job
+
[AMD Public Use]
Hi Christian,
I discussed with @Liu, Monk and @Chen, Horace, it hasn't decided yet. I'll add
you and Alex to the mailing list.
-Original Message-
From: Christian König
Sent: Thursday, December 10, 2020 5:29 PM
To: Liu, Cheng Zhe ; Koenig, Christian
;
Hi Luben,
Am Mittwoch, den 09.12.2020, 21:14 -0500 schrieb Luben Tuikov:
> This patch does not change current behaviour.
>
> The driver's job timeout handler now returns
> status indicating back to the DRM layer whether
> the task (job) was successfully aborted or whether
> more time should be
Hi Cheng,
well with whom you discussed that? Such discussions should happen on the
mailing list and at minimum include Alex and me.
Anyway as discussed before this is not acceptable. We already discussed
this years ago and the behavior is fixed and not changeable.
Regards,
Christian.
Am
On Tue, 08 Dec 2020, Thomas Zimmermann wrote:
> ping for a review of the i915 patches
What did you have in mind regarding merging the series? Should we just
pick the patches up?
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
amd-gfx
These are supported by Sienna Cichlid and should be
taken into consideration during DS control.
Change-Id: I93ed67ae863a91b75d6dfecd87e74029ffafd302
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c | 16
1 file changed, 16 insertions(+)
diff --git
57 matches
Mail list logo
