Add AMD_PG_SUPPORT_GFX_PG support.
Signed-off-by: Tim Huang
---
drivers/gpu/drm/amd/amdgpu/soc21.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/soc21.c
b/drivers/gpu/drm/amd/amdgpu/soc21.c
index b700c6cb14b4..bbbf760f8ad2 100644
---
Enable GFX Power Gating control for GC IP v11.0.1.
Signed-off-by: Tim Huang
---
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
index
[AMD Official Use Only - General]
Reviewed-by: Feifei Xu
-Original Message-
From: amd-gfx On Behalf Of Evan Quan
Sent: Tuesday, August 9, 2022 9:31 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Quan, Evan
; Zhang, Hawking
Subject: [PATCH] drm/amd/pm: add 3715
[AMD Official Use Only - General]
Hi Alex,
Yes, we need to call amdgpu_gfx_off_ctrl(adev, enable) as well, but now the
GFXOFF feature is still not ready
on the FW side. I will add some comments about this and resend this patch to
avoid confusion.
Best Regards,
Tim Huang
-Original
Add support for 3715 softpptable.
Signed-off-by: Evan Quan
Reviewed-by: Hawking Zhang
Change-Id: Iae7360ce853a6b5fde38025d528640c9b88fc54c
---
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git
Use the mm reference from the fence. This allows removing the
svm_bo->svms pointer, which was problematic because we cannot assume
that the struct kfd_process containing the svms is still allocated
without holding a refcount on the process.
Use mmget_not_zero to ensure the mm is still valid, and
Now that we've finally gotten rid of the non-atomic MST users leftover in
the kernel, we can finally get rid of all of the legacy payload code we
have and move as much as possible into the MST atomic state structs. The
main purpose of this is to make the MST code a lot less confusing to work
on,
Right now, radeon is technically the only non-atomic driver still making
use of the MST helpers - and thus the final user of all of the legacy MST
helpers. Originally I was going to look into seeing if we could move legacy
MST into the radeon driver itself, however:
* SI and CIK both can use
Currently, we set drm_dp_atomic_payload->time_slots to 0 in order to
indicate that we're about to delete a payload in the current atomic state.
Since we're going to be dropping all of the legacy code for handling the
payload table however, we need to be able to ensure that we still keep
track of
In the past, we've ran into strange issues regarding errors in response to
trying to destroy payloads after a port has been unplugged. We fixed this
back in:
This is intended to replace the workaround that was added here:
commit 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by ports
We want to start cutting down on all of the places that we use port
validation, so that ports may be removed from the topology as quickly as
possible to minimize the number of errors we run into as a result of being
out of sync with the current topology status. This isn't a very typical
scenario
There's another kind of situation where we could potentially race with
nonblocking modesets and MST, especially if we were to only use the locking
provided by atomic modesetting:
* Display 1 begins as enabled on DP-1 in SST mode
* Display 1 switches to MST mode, exposes one sink in MST mode
*
Since we're going to be relying on atomic locking for payloads now (and the
MST mgr needs to track CRTCs), pull in the topology state for all modesets
in nv50_msto_atomic_check().
Signed-off-by: Lyude Paul
Acked-by: Jani Nikula
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
1 file
I'm not sure why, but at the time I originally wrote the find/release time
slot helpers I thought we should avoid keeping modeset tracking out of the
MST helpers. In retrospect though there's no actual good reason to do
this, and the logic has ended up being identical across all the drivers
using
Currently with the MST helpers we avoid releasing payloads _and_ avoid
pulling in the MST state if there aren't any actual payload changes. While
we want to keep the first step, we need to now make sure that we're always
pulling in the MST state on all modesets that can modify payloads - even if
Post-NV50, the only kind of encoder you'll find for DP connectors on Nvidia
GPUs are SORs (serial output resources). Because SORs have fixed
associations with their connectors, we can correctly assume that any DP
connector on a nvidia GPU will have exactly one SOR encoder routed to it
for
As Daniel Vetter pointed out, if we only use the atomic modesetting locks
with MST it's technically possible for a driver with non-blocking modesets
to race when it comes to MST displays - as we make the mistake of not doing
our own CRTC commit tracking in the topology_state object.
This could
Since we're about to start adding some stuff here, we may as well fill in
any missing documentation that we forgot to write.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
For some reason we mention returning 0 if "slots have been added back to
drm_dp_mst_topology_state->avail_slots". This is totally misleading,
avail_slots is simply for figuring out the total number of slots available
in total on the topology and has no relation to the current payload
allocations.
We already open-code this quite often, and will be iterating through
payloads even more once we've moved all of the payload tracking into the
atomic state. So, let's add a helper for doing this.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc:
VCPI is only sort of the correct term here, originally the majority of this
code simply referred to timeslots vaguely as "slots" - and since I started
working on it and adding atomic functionality, the name "VCPI slots" has
been used to represent time slots.
Now that we actually have consistent
For quite a while we've been carrying around a lot of legacy modesetting
code in the MST helpers that has been rather annoying to keep around,
and very often gets in the way of trying to implement additional
functionality in MST such as fallback link rate retraining, dynamic BPC
management and DSC
In retrospect, the name I chose for this originally is confusing, as
there's a lot more info in here then just the VCPI. This really should be
called a payload. Let's make it more obvious that this is meant to be
related to the atomic state and is about payloads by renaming it to
Just to make this more clear to outside contributors that these are
DC-specific structs, as this also threw me into a loop a number of times
before I figured out the purpose of this.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Fangzhi Zuo
Acked-by: Jani Nikula
---
This function isn't too confusing if you see the comment around the
call-site for it, but if you don't then it's not at all obvious this is
meant to copy DRM's payload table over to DC's internal state structs.
Seeing this function before finding that comment definitely threw me into a
loop a few
Also JFYI - I did see this comment but didn't address it in my respin, but
only because I figured this might be better for a followup patch considering
how much work is already in here
On Wed, 2022-06-15 at 04:43 +, Lin, Wayne wrote:
> I would prefer not using the term "available" which is a
On Mon, 2022-08-08 at 10:02 +, Lin, Wayne wrote:
> [Public]
>
>
>
> > -Original Message-
> > From: Lyude Paul
> > Sent: Thursday, August 4, 2022 4:28 AM
> > To: Lin, Wayne ; dri-de...@lists.freedesktop.org;
> > nouv...@lists.freedesktop.org; amd-gfx@lists.freedesktop.org
> > Cc:
As I discussed with Alice ,this change is when multi-vf running compute
benchmark (Luxmark) at the same time, which involves multiple vf do the tlb
invalidation at the same time. They observed kiq timeout after submit the tlb
invalidate command. Although each vf has the invalidate register
Currently, we are using soc._clock_tmp[] to temporarily store and modify
data from soc.clock_limits[] before copying it back into
soc.clock_limits[] (because modifying data directly in
soc.clock_limits[] causes unintended behavior). However, this approch
has a number of downsides, such as:
On Wed, Aug 3, 2022 at 5:02 AM Dusica Milinkovic
wrote:
>
Please include a patch description. Why do you need a longer timeout?
What problem does it fix?
> Signed-off-by: Dusica Milinkovic
> ---
> drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 6 +-
> drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c |
On Mon, Aug 8, 2022 at 6:32 AM Tim Huang wrote:
>
> Enable GFX Power Gating control for GC IP v11.0.1.
>
> Signed-off-by: Tim Huang
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 35 ++
> 1 file changed, 35 insertions(+)
>
> diff --git
[Public]
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Joseph
Greathouse
Sent: Thursday, August 4, 2022 12:01 PM
To: amd-gfx@lists.freedesktop.org
Cc: Russell, Kent ; Greathouse, Joseph
; Koenig, Christian
Subject: [PATCH] drm/amdgpu: Enable
I can't 100% judge if the IP version check is sufficient or not, so keep
an eye open for regression reports when this goes upstream.
Apart from that Acked-by: Christian König as
well.
Christian.
Am 08.08.22 um 15:12 schrieb Russell, Kent:
[AMD Official Use Only - General]
You can throw
Am 04.08.22 um 14:19 schrieb Arvind Yadav:
If core DMA-buf framework forgets to call dma_fence_enable_signaling()
before calling the dma_fence_is_signaled(). To handle this scenario on
debug kernel the DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT needs to be checked
before checking the actual signaling
On 08/05, Simon Ser wrote:
> Hi,
>
> Have you seen [1] and [2]? CC'ing Sean and Hans, it seems like there's
> a disagreement regarding probing early vs. setting the initial value to
> UNKNOWN.
>
> If a driver doesn't fetch EDIDs before exposing them to user-space,
> then there is an amount of
On 08/04, Melissa Wen wrote:
> To set the panel orientation property with quirk, we need the mode size
> provided by EDID. This info is available after EDID is read by
> dc_link_detect()
> and updated by amdgpu_dm_update_connector_after_detect(). The detection
> happens at driver load in
On 08/08, Hans de Goede wrote:
> Hi,
>
> On 8/5/22 19:34, Simon Ser wrote:
> > Hi,
> >
> > Have you seen [1] and [2]? CC'ing Sean and Hans, it seems like there's
> > a disagreement regarding probing early vs. setting the initial value to
> > UNKNOWN.
>
> At least for the discussions I've been
[AMD Official Use Only - General]
Hi all,
This week this patchset was tested on the following systems:
HP Envy 360, with Ryzen 5 4500U
Lenovo Thinkpad T14s Gen2, with AMD Ryzen 5 5650U
Sapphire Pulse RX5700XT
Reference AMD RX6800
Engineering board with Ryzen 9 5900H
These systems were
[AMD Official Use Only - General]
You can throw an Acked-by Kent Russell as well . Not
sure if there's someone who wants to provide a more concrete RB.
Kent
> -Original Message-
> From: Kuehling, Felix
> Sent: Thursday, August 4, 2022 2:54 PM
> To: Greathouse, Joseph ; amd-
>
Hi,
On 8/5/22 19:34, Simon Ser wrote:
> Hi,
>
> Have you seen [1] and [2]? CC'ing Sean and Hans, it seems like there's
> a disagreement regarding probing early vs. setting the initial value to
> UNKNOWN.
At least for the discussions I've been involved in so far
(see the links in the originak
Am 26.07.22 um 18:22 schrieb Arunpravin Paneer Selvam:
Check the bo->resource value before accessing the resource
mem_type.
[ 40.191227][ T184] general protection fault, probably for non-canonical
address 0xdc02: [#1] SMP KASAN PTI
[ 40.192995][ T184] KASAN:
On 8/8/2022 12:59 PM, Christian König wrote:
Am 02.08.22 um 15:55 schrieb Shashank Sharma:
This patch adds:
- A new input parameter "flags" in the amdgpu_ctx_create2 call.
- Some new flags defining workload type hints.
- Some change in the caller function of amdgpu_ctx_create2, to
Am 25.07.22 um 13:42 schrieb Arunpravin Paneer Selvam:
Implemented a new intersect and compatible callback functions
to ttm range manager fetching start offset from drm mm range
allocator.
Signed-off-by: Christian König
Signed-off-by: Arunpravin Paneer Selvam
---
Am 25.07.22 um 13:42 schrieb Arunpravin Paneer Selvam:
We are adding two new callbacks to ttm resource manager
function to handle intersection and compatibility of
placement and resources.
v2: move the amdgpu and ttm_range_manager changes to
separate patches (Christian)
Signed-off-by:
Am 02.08.22 um 15:55 schrieb Shashank Sharma:
This patch adds:
- A new input parameter "flags" in the amdgpu_ctx_create2 call.
- Some new flags defining workload type hints.
- Some change in the caller function of amdgpu_ctx_create2, to
accomodate this new parameter.
The idea is to pass the
Enable GFX Power Gating control for GC IP v11.0.1.
Signed-off-by: Tim Huang
---
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 35 ++
1 file changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
index
Add AMD_PG_SUPPORT_GFX_PG support.
Signed-off-by: Tim Huang
---
drivers/gpu/drm/amd/amdgpu/soc21.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/soc21.c
b/drivers/gpu/drm/amd/amdgpu/soc21.c
index b700c6cb14b4..bbbf760f8ad2 100644
---
[Public]
> -Original Message-
> From: Lyude Paul
> Sent: Thursday, August 4, 2022 4:28 AM
> To: Lin, Wayne ; dri-de...@lists.freedesktop.org;
> nouv...@lists.freedesktop.org; amd-gfx@lists.freedesktop.org
> Cc: Ville Syrjälä ; Zuo, Jerry
> ; Jani Nikula ; Imre Deak
> ; Daniel Vetter ;
On Sun, Aug 7, 2022 at 10:36 AM David Laight wrote:
>
> Or just shoot the software engineer who thinks 100 arguments
> is sane. :-)
I suspect the issue is that it's not primarily a software engineer who
wrote that code.
Hardware people writing code are about as scary as software engineers
with
From: Arnd Bergmann
> Sent: 05 August 2022 20:32
...
> One thing to try would be to condense a function call like
>
> dml32_CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport(
>
...
> /* more arguments */);
>
> into calling conventions that take a
On Fri, Aug 05, 2022 at 03:53:41PM -0600, Jim Cromie wrote:
> Rework/modernize docs:
>
> - use /proc/dynamic_debug/control in examples
>its *always* there (when dyndbg is config'd), even when is not.
>drop talk, its a distraction here.
>
> - alias ddcmd='echo $* >
On 8/2/2022 7:25 PM, Shashank Sharma wrote:
This patch adds:
- A new input parameter "flags" in the amdgpu_ctx_create2 call.
- Some new flags defining workload type hints.
- Some change in the caller function of amdgpu_ctx_create2, to
accomodate this new parameter.
The idea is to pass the
52 matches
Mail list logo
