No need to set up rb when no gfx rings.
Signed-off-by: Candice Li
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 7f187558220e9a..1d6d3a852a0b3d 10
Hi Dave, Daniel,
A bit bigger than normal, but this is several weeks of fixes since I was out
of the office and then digging out once I got back. Mainly fixes for new
IPs that were added in 6.0.
The following changes since commit 5493ee1919eae4f49d62276cf5986b7f7c7aa8f6:
Merge tag 'amd-drm-ne
Enable AMD_CG_SUPPORT_BIF_MGCG and AMD_CG_SUPPORT_BIF_LS support.
Signed-off-by: Tim Huang
---
drivers/gpu/drm/amd/amdgpu/soc21.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/soc21.c
b/drivers/gpu/drm/amd/amdgpu/soc21.c
index 1ff7fc7bb340
Add BIF Clock Gating MGCG and LS support for NBIO IP v7.7.0.
Signed-off-by: Tim Huang
---
drivers/gpu/drm/amd/amdgpu/nbio_v7_7.c | 78 ++
1 file changed, 78 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/nbio_v7_7.c
b/drivers/gpu/drm/amd/amdgpu/nbio_v7_7.c
index
Add the BIF0_PCIE_TX_POWER_CTRL_1 register offset and mask macro
definitions for AMD_CG_SUPPORT_BIF_LS.
Signed-off-by: Tim Huang
---
.../amd/include/asic_reg/nbio/nbio_7_7_0_offset.h | 2 ++
.../amd/include/asic_reg/nbio/nbio_7_7_0_sh_mask.h | 13 +
2 files changed, 15 insertions
Hi All,
Not sure if it has been reported, build of next-20220817 fails with the
error:
ERROR: modpost: "cpu_smallcore_map" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko]
undefined!
Trying to do a git bisect to find out the offending commit.
I will be happy to test any patch or provide any
On 8/17/22 19:01, Alex Deucher wrote:
> On Wed, Aug 17, 2022 at 6:03 PM Sudip Mukherjee (Codethink)
> wrote:
>>
>> Hi All,
>>
>> Not sure if it has been reported, build of next-20220817 fails with the
>> error:
>>
>> ERROR: modpost: "cpu
failure.
> > > >
> > > > I will be happy to test any patch or provide any extra log if needed.
> > >
> > > I have reverted that commit in today's linux-next.
> >
> > I have removed that revert. Sudip, can you recheck when linux-next is
> > released, please?
>
> The build failure is not seen with next-20220817.
Excellent, thanks.
--
Cheers,
Stephen Rothwell
pgpFiWk6JIXYG.pgp
Description: OpenPGP digital signature
On Wed, Aug 17, 2022 at 6:03 PM Sudip Mukherjee (Codethink)
wrote:
>
> Hi All,
>
> Not sure if it has been reported, build of next-20220817 fails with the
> error:
>
> ERROR: modpost: "cpu_smallcore_map" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko]
> undefined!
>
On Thu, Aug 18, 2022 at 12:04 AM Felix Kuehling wrote:
>
> Am 2022-08-12 um 21:27 schrieb Bas Nieuwenhuizen:
> > This way callsites can choose between READ/BOOKKEEP reservations.
> >
> > Signed-off-by: Bas Nieuwenhuizen
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 5 +
> >
Am 2022-08-12 um 21:27 schrieb Bas Nieuwenhuizen:
This way callsites can choose between READ/BOOKKEEP reservations.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 5 +
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 9 +++--
drivers/gpu/dr
On Wed, Aug 17, 2022 at 11:43 PM Maíra Canal wrote:
>
> Hi Mikhail,
>
> Looks like 45ecaea738830b9d521c93520c8f201359dcbd95 ("drm/sched: Partial
> revert of 'drm/sched: Keep s_fence->parent pointer'") introduced the
> error. Try reverting it and check if the use-after-free still happens.
Thanks,
t; pass-through during mode validation")
> > > And, reverting that commit has fixed the build failure.
> > >
> > > I will be happy to test any patch or provide any extra log if needed.
> >
> > I have reverted that commit in today's linux-next.
>
> I have removed that revert. Sudip, can you recheck when linux-next is
> released, please?
The build failure is not seen with next-20220817.
--
Regards
Sudip
On 8/17/22 7:22 AM, Hans de Goede wrote:
Hi Daniel,
On 7/15/22 13:59, Hans de Goede wrote:
Hi Daniel,
On 7/12/22 22:13, Daniel Dadap wrote:
Thanks, Hans:
On 7/12/22 14:38, Hans de Goede wrote:
On some new laptop designs a new Nvidia specific WMI interface is present
which gives info about p
On 8/17/22 10:05 AM, Hans de Goede wrote:
Hi Daniel,
On 8/2/22 18:49, Daniel Dadap wrote:
On 8/2/22 06:31, Hans de Goede wrote:
Hi Daniel,
On 7/21/22 23:30, Daniel Dadap wrote:
On 7/21/22 16:24, Daniel Dadap wrote:
On 7/12/22 14:38, Hans de Goede wrote:
ATM on x86 laptops where we want use
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, as
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 amdgp
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 an
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
* User
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
th
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 changed,
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 t
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 DisplayPo
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
---
i
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 pot
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: Imre
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.
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 ac
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
drm_dp_mst_atomic_
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
---
.../gpu/drm/amd/display/amdg
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
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 t
On 8/17/22 14:44, Mikhail Gavrilov wrote:
On Wed, Aug 17, 2022 at 9:08 PM Melissa Wen wrote:
Hi Mikhail,
IIUC, you got this second user-after-free by applying the first version
of Maíra's patch, right? So, that version was adding another unbalanced
unlock to the cs ioctl flow, but it was s
On Wed, Aug 17, 2022 at 9:08 PM Melissa Wen wrote:
>
> Hi Mikhail,
>
> IIUC, you got this second user-after-free by applying the first version
> of Maíra's patch, right? So, that version was adding another unbalanced
> unlock to the cs ioctl flow, but it was solved in the latest version,
> that yo
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 95d10484d66e54d5c01e36389e9318221fb8f60b Add linux-next specific
files for 20220817
Warning reports:
https://lore.kernel.org/linux-doc/202208162058.7appivkl-...@intel.com
https
Am 2022-08-17 um 11:04 schrieb Felix Kuehling:
Am 2022-08-16 um 23:09 schrieb Lang Yu:
Then we can remove the burden of maintaining codes to
parse family_id from gfx version in rocr,
i.e., remove DevIDToAddrLibFamily().
I'm OK with the change. But you won't be able to remove
DevIDToAddrLibFam
Hi Daniel,
On 8/2/22 18:49, Daniel Dadap wrote:
> On 8/2/22 06:31, Hans de Goede wrote:
>> Hi Daniel,
>>
>> On 7/21/22 23:30, Daniel Dadap wrote:
>>> On 7/21/22 16:24, Daniel Dadap wrote:
On 7/12/22 14:38, Hans de Goede wrote:
> ATM on x86 laptops where we want userspace to use the acpi_v
Am 2022-08-16 um 23:09 schrieb Lang Yu:
Then we can remove the burden of maintaining codes to
parse family_id from gfx version in rocr,
i.e., remove DevIDToAddrLibFamily().
I'm OK with the change. But you won't be able to remove
DevIDToAddrLibFamily as long as ROCr needs to support older kerne
[AMD Official Use Only - General]
Series is
Reviewed-by: Hawking Zhang
Regards,
Hawking
From: Chai, Thomas
Date: Wednesday, August 17, 2022 at 14:20
To: amd-gfx@lists.freedesktop.org
Cc: Chai, Thomas , Zhang, Hawking ,
Zhou1, Tao , Clements, John , Li,
Candice , Chai, Thomas
Subject: [PATC
On 2022-08-17 09:44, Alex Deucher wrote:
On Tue, Aug 16, 2022 at 10:54 PM Chai, Thomas wrote:
[AMD Official Use Only - General]
Hi Alex:
When removing an amdgpu device, it may be difficult to change the order of
psp_hw_fini calls.
1. The drm_dev_unplug call is at the beginning in the am
New GFX11 MES FW adds the trap_en bit. For now hardcode to 1 (traps
enabled).
Signed-off-by: Graham Sider
Acked-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/mes_v11_0.c| 1 +
drivers/gpu/drm/amd/include/mes_v11_api_def.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
dif
On Tue, Aug 16, 2022 at 10:54 PM Chai, Thomas wrote:
>
> [AMD Official Use Only - General]
>
> Hi Alex:
> When removing an amdgpu device, it may be difficult to change the order of
> psp_hw_fini calls.
>
> 1. The drm_dev_unplug call is at the beginning in the amdgpu_pci_remove
> function, whi
在 2022/8/15 21:12, Christian König 写道:
Am 15.08.22 um 09:34 schrieb 李真能:
在 2022/8/12 18:55, Christian König 写道:
Am 11.08.22 um 09:25 schrieb Zhenneng Li:
Although radeon card fence and wait for gpu to finish processing
current batch rings,
there is still a corner case that radeon lockup wor
Hi,
On 7/20/22 18:46, Alex Deucher wrote:
> On Wed, Jul 20, 2022 at 12:44 PM Alex Deucher wrote:
>>
>> On Tue, Jul 12, 2022 at 3:39 PM Hans de Goede wrote:
>>>
>>> Before this commit when we want userspace to use the acpi_video backlight
>>> device we register both the GPU's native backlight dev
Hi Daniel,
On 7/15/22 13:59, Hans de Goede wrote:
> Hi Daniel,
>
> On 7/12/22 22:13, Daniel Dadap wrote:
>> Thanks, Hans:
>>
>> On 7/12/22 14:38, Hans de Goede wrote:
>>> On some new laptop designs a new Nvidia specific WMI interface is present
>>> which gives info about panel brightness control
Am 17.08.22 um 09:31 schrieb 李真能:
在 2022/8/15 21:12, Christian König 写道:
Am 15.08.22 um 09:34 schrieb 李真能:
在 2022/8/12 18:55, Christian König 写道:
Am 11.08.22 um 09:25 schrieb Zhenneng Li:
Although radeon card fence and wait for gpu to finish processing
current batch rings,
there is still a
[Public]
This patch is
Reviewed-by: Yifan Zhang
-Original Message-
From: Huang, Tim
Sent: Wednesday, August 17, 2022 2:14 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Zhang, Yifan
; Du, Xiaojian ; Huang, Tim
Subject: [PATCH] drm/amdgpu: enable GFXOFF allow control
47 matches
Mail list logo
