From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which one
is primary at boot time. This patch tries to solve the mentioned problem by
implementing the .be_primary() callback. VGAARB will call back to Nouveau
when the drm/nouveau gets loaded successfully.
Pass
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve above mentioned
problem by introduced the ->be_primary() function stub. The specific
device drivers can provide an implementation to hook up with this
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which one
is primary at boot time. This patch tries to solve the mentioned problem by
implementing the .be_primary() callback. Pass loongson.modeset=10 on the
kernel cmd line if you really want the device bound b
From: Sui Jingfeng
Becasuse the display controller in the ASpeed BMC chip is a VGA-compatible
device, the software programming guide of AST2400 say that it is fully
IBM VGA compliant. Thus, it should also participate in the arbitration.
Cc: Thomas Zimmermann
Cc: Jocelyn Falempe
Signed-off-by:
From: Sui Jingfeng
Because the display controller in the Hibmc chip is a VGA compatible
display controller. Because ARM64 doesn't need the VGA console. It does not
need to worry about the side effects that come with the VGA compatible.
However, the real problem is that some ARM64 PCs and servers
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve above mentioned
problem by introduced the ->be_primary() function stub. The specific
device drivers can provide an implementation to hook up with this
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which one
is primary at boot time. This patch tries to solve the mentioned problem by
implementing the .be_primary() callback. Pass radeon.modeset=10 on the
kernel cmd line if you really want the device bound by
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which one
is primary at boot time. This patch tries to solve the mentioned problem by
implementing the .be_primary() callback. Pass amdgpu.modeset=10 on the
kernel cmd line if you really want the device bound by
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which one
is primary at boot time. This patch tries to solve the mentioned problem by
implementing the .be_primary() callback. Pass i915.modeset=10 on the kernel
cmd line if you really want the device bound by i9
From: Sui Jingfeng
Because the display controller in N2000/D2000 series can be VGA-compatible,
so let's register gma500 as a VGA client, despite the firmware may alter
the PCI class code of IGD on a multiple GPU co-exist configuration. But
this commit no crime, because VGAARB only cares about VGA
On Tue, 05 Sep 2023, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> On a machine with multiple GPUs, a Linux user has no control over which
> one is primary at boot time. This series tries to solve above mentioned
> problem by introduced the ->be_primary() function stub. The specific
> device drive
On 9/5/2023 1:24 PM, Christian König wrote:
> Am 04.09.23 um 08:05 schrieb Ma Jun:
>> [1] Remove the irq flags setting code since pci_alloc_irq_vectors()
>> handles these flags.
>> [2] Free the msi vectors in case of error.
>>
>> Signed-off-by: Ma Jun
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdg
Hi
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve above mentioned
If anything, the primary graphics adapter is the one initialized by the
firmware.
Hi
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve above mentioned
problem by introduced the ->be_primary() function stub. The specific
device drivers c
Am 05.09.23 um 12:38 schrieb Jani Nikula:
On Tue, 05 Sep 2023, Sui Jingfeng wrote:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve above mentioned
problem by introduced the ->be_primary() functi
Hi,
On 2023/9/5 18:45, Thomas Zimmermann wrote:
Hi
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve above mentioned
If anything, the primary graphic
On Sun, Sep 3, 2023 at 9:23 PM Quan, Evan wrote:
>
> [AMD Official Use Only - General]
>
> Actually, with my original design, there indeed came with an 'r' option
> support.
> But I found that brings some confusion. Since per current 'r' option design,
> it will
> reset all attributes back to or
On 2023-08-31 17:29, Chen, Xiaogang
wrote:
On 8/31/2023 3:59 PM, Felix Kuehling wrote:
On 2023-08-31 16:33, Chen, Xiaogang wrote:
That said, I'm no
Can we boot the system if we only apply patces 1-3? If not, we might
want to move patch 2 to the end of the series.
A bunch of these patches are from me. Would be good if they can get a
Reviewed-by from you (or someone else, other than me) before merging.
Series is
Reviewed-by: Harry Wentland
H
On some APU systems, there is no atom context and so the
atom_context struct is null.
Add a check to the VBIOS_INFO branch of amdgpu_info_ioctl
to handle this case, returning all zeroes.
Signed-off-by: David Francis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 19 ---
1 file ch
Hi,
I'm updating the color state part of DTN log to match DCN3.0 HW better.
Currently, the DTN log considers the DCN10 color pipeline, which is
useless for DCN3.0 because of all the differences in color caps between
DCN versions. In addition to new color blocks and caps, some semantic
differences
Prepare to hook color state logging according to DCN version.
Signed-off-by: Melissa Wen
---
.../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 27 +--
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
b/drivers
Logging DCN3 MPC state was following DCN1 implementation that doesn't
consider new DCN3 MPC color blocks. Create new elements according to
DCN3 MPC color caps and a new DCN3-specific function for reading MPC
data.
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/dc/dcn30/dcn30_mpc.c | 55
DCN3 DPP color state was uncollected and some state elements from DCN1
doesn't fit DCN3. Create new elements according to DCN3 color caps and
fill them up for DTN log output.
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c | 28 +--
drivers/gpu/drm/am
Color caps changed between HW versions which caused DCN10 color state
sections on DTN log no longer fit DCN3.0 versions. Create a
DCN3.0-specific color state logging and hook it to drivers of DCN3.0
family.
Signed-off-by: Melissa Wen
---
.../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 5 +-
...
Add color caps information for DPP and MPC block to show HW color caps.
Signed-off-by: Melissa Wen
---
.../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 23 +++
.../drm/amd/display/dc/dcn30/dcn30_hwseq.c| 23 +++
2 files changed, 46 insertions(+)
diff --git a/d
On Mon, Sep 4, 2023 at 2:30 AM Ma Jun wrote:
>
> [1] Remove the irq flags setting code since pci_alloc_irq_vectors()
> handles these flags.
> [2] Free the msi vectors in case of error.
>
> Signed-off-by: Ma Jun
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 43 ++---
> 1 f
Hi,
On 2023/9/5 21:28, Christian König wrote:
2) Typically, those non-86 machines don't have a good UEFI firmware
support, which doesn't support select primary GPU as firmware
stage.
Even on x86, there are old UEFI firmwares which already made
undesired
decision for you.
3) This
On Mon, Sep 4, 2023 at 9:20 AM Lijo Lazar wrote:
>
> pp_dpm_*clk nodes also could show the frequencies when a clock is in
> 'sleep' state. Add documentation related to that.
>
> Signed-off-by: Lijo Lazar
> ---
> drivers/gpu/drm/amd/pm/amdgpu_pm.c | 10 +-
> 1 file changed, 9 insertions(+
On Tue, 5 Sep 2023 03:57:15 +0800
Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> On a machine with multiple GPUs, a Linux user has no control over which
> one is primary at boot time. This series tries to solve above mentioned
> problem by introduced the ->be_primary() function stub. The specifi
On Tue, Sep 5, 2023 at 10:50 AM David Francis wrote:
>
> On some APU systems, there is no atom context and so the
> atom_context struct is null.
>
> Add a check to the VBIOS_INFO branch of amdgpu_info_ioctl
> to handle this case, returning all zeroes.
>
> Signed-off-by: David Francis
> ---
> dri
Hi
Am 05.09.23 um 15:30 schrieb suijingfeng:
Hi,
On 2023/9/5 18:45, Thomas Zimmermann wrote:
Hi
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve abo
On 9/5/2023 9:02 AM, Philip Yang wrote:
On 2023-08-31 17:29, Chen, Xiaogang wrote:
On 8/31/2023 3:59 PM, Felix Kuehling wrote:
On 2023-08-31 16:33, Chen, Xiaogang wrote:
That said, I'm not actually sure why we're freeing the DMA
address array after migration to RAM at all. I think we stil
It has been observed that task_info struct makes it difficult to
handle amdgpu_vm during a GPU reset, due to it's parameters like
task_name and process name.
This patch:
- removes task_info struct from amdgpu_vm and moves it into vm_mgr
as an Xarray.
- creates a PID vs task_info mapping to index
[AMD Official Use Only - General]
[AMD Official Use Only - General]
Yeah we've had JIRAs (e.g. https://ontrack-internal.amd.com/browse/SWDEV-409711
) raised that ASAN can't compile the thunk due to using = {0} . Using memset is
definitely preferred to save trouble later.
Kent
This is kernel
On Mon, Sep 4, 2023 at 1:00 AM Lang Yu wrote:
>
> Fixes: ab041551f4a7 ("drm/amdgpu: add VPE 6.1.0 support")
>
> Signed-off-by: Lang Yu
> Reported-by: kernel test robot
> Link:
> https://lore.kernel.org/oe-kbuild-all/202309020608.fwp8qmht-...@intel.com
Reviewed-by: Alex Deucher
> ---
> drive
On 09/05, Melissa Wen wrote:
> Hi,
>
> I'm updating the color state part of DTN log to match DCN3.0 HW better.
> Currently, the DTN log considers the DCN10 color pipeline, which is
> useless for DCN3.0 because of all the differences in color caps between
> DCN versions. In addition to new color bl
On 2023/9/5 18:49, Thomas Zimmermann wrote:
Hi
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve above mentioned
problem by introduced the ->be_primary
Hi,
On 2023/9/5 22:52, Alex Williamson wrote:
On Tue, 5 Sep 2023 03:57:15 +0800
Sui Jingfeng wrote:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve above mentioned
problem by introduced the -
[AMD Official Use Only - General]
Sorry, meant to keep the JIRA part internal. As it stands, the amd/ folder
alone has 458 {0}s (plus 55 {}s), and 741 memset-to-0s. So I guess it’s a
matter of whether or not we’ll start enforcing memsets vs {0} in the near
future. If we intend to switch over so
On Wed, 6 Sep 2023 00:21:09 +0800
suijingfeng wrote:
> Hi,
>
> On 2023/9/5 22:52, Alex Williamson wrote:
> > On Tue, 5 Sep 2023 03:57:15 +0800
> > Sui Jingfeng wrote:
> >
> >> From: Sui Jingfeng
> >>
> >> On a machine with multiple GPUs, a Linux user has no control over which
> >> one is pr
On Tue, Sep 5, 2023 at 12:15 PM Francis, David wrote:
>
> [AMD Official Use Only - General]
>
>
> [AMD Official Use Only - General]
>
> Yeah we've had JIRAs (e.g.
> https://ontrack-internal.amd.com/browse/SWDEV-409711 ) raised that ASAN can't
> compile the thunk due to using = {0} . Using memset
[WHY]
edid_override and drm_edid_override_connector_update, according to drm
documentation, should not be referred outside drm_edid.
[HOW]
Remove and replace them accordingly.
Signed-off-by: Alex Hung
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 23 ++-
1 file changed, 2
Applied and dropped the printk.
Alex
On Fri, Sep 1, 2023 at 3:40 AM Christian König wrote:
>
> Am 01.09.23 um 09:02 schrieb Jiapeng Chong:
> > No functional modification involved.
> >
> > drivers/gpu/drm/amd/amdgpu/nbio_v7_11.c:34 nbio_v7_11_get_rev_id() warn:
> > inconsistent indenting.
>
>
>
Hi,
On 2023/9/5 13:50, Christian König wrote:
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over
which one
is primary at boot time.
Question is why is that useful? Should we give users the ability to
control th
Applied. Thanks!
On Thu, Aug 31, 2023 at 8:52 PM Yang Li wrote:
>
> ./drivers/gpu/drm/amd/display/dc/dcn35/dcn35_resource.c:
> dcn31/dcn31_dio_link_encoder.h is included more than once.
>
> Signed-off-by: Yang Li
> ---
> drivers/gpu/drm/amd/display/dc/dcn35/dcn35_resource.c | 1 -
> 1 file ch
Applied. Thanks!
On Thu, Aug 31, 2023 at 8:52 PM Yang Li wrote:
>
> ./drivers/gpu/drm/amd/display/dc/dcn35/dcn35_optc.c: dcn35_optc.h is included
> more than once.
>
> Signed-off-by: Yang Li
> ---
> drivers/gpu/drm/amd/display/dc/dcn35/dcn35_optc.c | 1 -
> 1 file changed, 1 deletion(-)
>
> d
Applied. Thanks!
On Thu, Aug 31, 2023 at 8:52 PM Yang Li wrote:
>
> ./drivers/gpu/drm/amd/display/dc/dcn35/dcn35_hwseq.c: clk_mgr.h is included
> more than once.
>
> Signed-off-by: Yang Li
> ---
> drivers/gpu/drm/amd/display/dc/dcn35/dcn35_hwseq.c | 1 -
> 1 file changed, 1 deletion(-)
>
> di
Applied. Thanks!
On Thu, Aug 31, 2023 at 8:52 PM Yang Li wrote:
>
> ./drivers/gpu/drm/amd/display/dc/clk_mgr/dcn35/dcn35_clk_mgr.c:
> dcn35_clk_mgr.h is included more than once.
>
> Signed-off-by: Yang Li
> ---
> drivers/gpu/drm/amd/display/dc/clk_mgr/dcn35/dcn35_clk_mgr.c | 1 -
> 1 file cha
Applied the series. Thanks!
Alex
On Thu, Aug 31, 2023 at 9:29 PM Yang Li wrote:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn35/dcn35_fpu.c:260
> dcn35_update_bw_bounding_box_fpu() warn: inconsistent indenting
>
> Signed-off-by: Yang Li
> ---
> drivers/gpu/drm/amd/display/dc/dml/dcn35
Reviewed-by: Alex Hung
On 2023-08-16 15:26, Alex Hung wrote:
From: Harry Wentland
[WHY]
Previously this only excluded build for a few amdgpu_dm
binaries which makes no sense.
[HOW]
Wrap the entire Makefile in "ifneq ($(CONFIG_DRM_AMD_DC),)"
Signed-off-by: Harry Wentland
Signed-off-by: Alex
Reviewed-by: Alex Hung
On 2023-08-16 15:26, Alex Hung wrote:
From: Harry Wentland
[WHAT]
Prepare a virtual connector for writeback.
Signed-off-by: Harry Wentland
Signed-off-by: Alex Hung
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 11 +--
drivers/gpu/drm/amd/display
Reviewed-by: Alex Hung
On 2023-08-16 15:26, Alex Hung wrote:
From: Harry Wentland
[WHY]
Writeback connectors are based on a different object:
drm_writeback_connector, and are therefore different from
amdgpu_dm_connector. We need to be careful to ensure code
designed for amdgpu_dm_connector do
Reviewed-by: Alex Hung
On 2023-08-16 15:26, Alex Hung wrote:
From: Harry Wentland
[WHY]
We will be dealing with two types of connector: amdgpu_dm_connector
and drm_writeback_connector.
[HOW]
We want to find both and then cast to the appriopriate type afterwards.
Signed-off-by: Harry Wentlan
Reviewed-by: Alex Hung
On 2023-08-16 15:26, Alex Hung wrote:
From: Harry Wentland
[WHAT]
We need to use this function for both amdgpu_dm_connectors
and drm_writeback_connectors. Modify it to operate on
a drm_connector as a common base.
Signed-off-by: Harry Wentland
Signed-off-by: Alex Hung
Reviewed-by: Alex Hung
On 2023-08-16 15:26, Alex Hung wrote:
From: Harry Wentland
[WHAT]
Again, we need to use this function for writeback connectors,
which are not of type amdgpu_dm_connector. Use the common base
drm_connector instead.
Signed-off-by: Harry Wentland
Signed-off-by: Alex Hung
Reviewed-by: Alex Hung
On 2023-08-16 15:26, Alex Hung wrote:
From: Harry Wentland
[WHY]
We need to track the dc_link and it would get confusing if
re-using the amdgpu_dm_connector.
[HOW]
Creating new amdgpu_dm_wb_connector.
Signed-off-by: Harry Wentland
Signed-off-by: Alex Hung
---
.../
Reviewed-by: Alex Hung
On 2023-08-16 15:26, Alex Hung wrote:
From: Harry Wentland
[WHAT]
Writeback connectors don't have a physical sink but DC still
needs a sink to function. Create a fake sink and stream for
writeback connectors
Signed-off-by: Harry Wentland
Signed-off-by: Alex Hung
---
On 2023-09-05 08:20, Harry Wentland wrote:
Can we boot the system if we only apply patces 1-3? If not, we might
want to move patch 2 to the end of the series.
The system boots with the first three patches namely
drm/amd/display: Initialize writeback connector
drm/amd/display: Create one vir
There are two places in apply_below_the_range() where it's possible for
a divide by zero error to occur. So, to fix this make sure the divisor
is non-zero before attempting the computation in both cases.
Cc: sta...@vger.kernel.org
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2637
Fixes: a
On 2023-09-05 14:53, Hamza Mahfooz wrote:
There are two places in apply_below_the_range() where it's possible for
a divide by zero error to occur. So, to fix this make sure the divisor
is non-zero before attempting the computation in both cases.
Cc: sta...@vger.kernel.org
Link: https://gitlab
This will allow base driver to dictate whether seamless should be
enabled. No intended functional changes.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 21 +
.../gpu/drm/amd/display/amd
IP discovery is a good line in the sand to expand seamless boot
to more ASICs.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/
`amdgpu_gmc_get_vbios_allocations` has a special case for how to
bring up yellow carp when amdgpu discovery is turned off. As this ASIC
ships with discovery turned on, it's generally dead code and worse it
causes `adev->mman.keep_stolen_vga_memory` to not be initialized for
yellow carp.
Remove it.
Seamless boot allows keeping the content on the framebuffer from pre-boot
so the screen doesn't get "painted black" during boot process.
Ideally the flow looks like:
* UEFI F/W posts vendor logo
* GRUB doesn't show anything, but silently continues
* Plymouth starts and adds OS logo to bottom and s
The module parameter can be used to test more easily enabling seamless
boot support on additional ASICs.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 20 +---
drivers/gpu/drm/amd/amdgpu/amdgpu
On Tue, Sep 5, 2023 at 3:50 PM Mario Limonciello
wrote:
>
> This will allow base driver to dictate whether seamless should be
> enabled. No intended functional changes.
>
> Signed-off-by: Mario Limonciello
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
> drivers/gpu/drm/amd/amdgp
Reviewed-by: Alex Deucher
On Tue, Sep 5, 2023 at 3:45 PM Mario Limonciello
wrote:
>
> `amdgpu_gmc_get_vbios_allocations` has a special case for how to
> bring up yellow carp when amdgpu discovery is turned off. As this ASIC
> ships with discovery turned on, it's generally dead code and worse it
[Public]
> -Original Message-
> From: amd-gfx On Behalf Of Mario
> Limonciello
> Sent: Tuesday, September 5, 2023 3:26 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Limonciello, Mario
> Subject: [PATCH 4/4] drm/amd: Enable seamless boot by default on newer
> APUs
>
> IP discovery is a goo
On 9/5/2023 15:07, Deucher, Alexander wrote:
[Public]
-Original Message-
From: amd-gfx On Behalf Of Mario
Limonciello
Sent: Tuesday, September 5, 2023 3:26 PM
To: amd-gfx@lists.freedesktop.org
Cc: Limonciello, Mario
Subject: [PATCH 4/4] drm/amd: Enable seamless boot by default on newe
On Tue, Sep 5, 2023 at 3:00 AM Christian König
wrote:
>
> The KIQ code path was ignoring the second flush. Also avoid long lines and
> re-calculating the register offsets over and over again.
I'd split this into two patches, one for the code cleanup and one to
fix the missing flush.
Alex
>
> Si
On Tue, Sep 5, 2023 at 2:20 AM Christian König
wrote:
>
> Move the SDMA workaround necessary for Navi 1x into a higher layer.
You could split out the register offsets code cleanup into a separate
patch. Either way, the patch is:
Reviewed-by: Alex Deucher
>
> Signed-off-by: Christian König
> -
On Tue, Sep 5, 2023 at 2:30 AM Christian König
wrote:
>
> Remove leftovers from copying this from the gmc v10 code.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c | 108 ++---
> 1 file changed, 41 insertions(+), 67 deletions(-)
>
> diff --gi
On Tue, Sep 5, 2023 at 7:30 AM Christian König
wrote:
>
> Testing for reset is pointless since the reset can start right after the
> test. Grab the reset semaphore instead.
>
> The same PASID can be used by more than once VMID, build a mask of VMIDs
> to reset instead of just restting the first on
On Tue, Sep 5, 2023 at 3:00 AM Christian König
wrote:
>
> Testing for reset is pointless since the reset can start right after the
> test. Grab the reset semaphore instead.
>
> The same PASID can be used by more than once VMID, build a mask of VMIDs
> to reset instead of just restting the first on
[Public]
> -Original Message-
> From: amd-gfx On Behalf Of
> Christian König
> Sent: Tuesday, September 5, 2023 2:04 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Sharma, Shashank
> Subject: [PATCH 06/11] drm/amdgpu: fix and cleanup
> gmc_v9_0_flush_gpu_tlb_pasid
>
> Testing for reset is
On Tue, Sep 5, 2023 at 2:15 AM Christian König
wrote:
>
> The same PASID can be used by more than one VMID, reset each of them.
>
> Use the common KIQ handling.
>
> Signed-off-by: Christian König
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 66 ---
On Tue, Sep 5, 2023 at 3:00 AM Christian König
wrote:
>
> The same PASID can be used by more than one VMID, reset each of them.
>
> Use the common KIQ handling.
>
> Signed-off-by: Christian König
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c | 63 ---
On Tue, Sep 5, 2023 at 2:30 AM Christian König
wrote:
>
> That function never fails, drop the error return.
>
> Signed-off-by: Christian König
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 7 ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h | 6 +++---
> drivers
On Tue, Sep 5, 2023 at 2:30 AM Christian König
wrote:
>
> Instead of each implementation doing this more or less correctly
> move taking the reset lock at a higher level.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 9 +
> drivers/gpu/drm/amd/amdgp
On Tue, Sep 5, 2023 at 3:00 AM Christian König
wrote:
>
> For the PASID flushing we already handled that at a higher layer, apply
> those workarounds to the standard flush as well.
>
> Signed-off-by: Christian König
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 1
Signed-off-by: Lin.Cao
Change-Id: I1322c010d1428b2c1df5080b72da94e90cf17fec
---
drivers/gpu/drm/amd/amdkfd/kfd_pm4_headers_ai.h | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_pm4_headers_ai.h
b/drivers/gpu/drm/amd/amdkfd/kfd_pm4_headers_ai.h
inde
Hi,
On 2023/9/5 23:05, Thomas Zimmermann wrote:
However, on modern Linux systems the primary display does not really
exist.
No, it do exist. X server need to know which one is the primary GPU.
The '*' character at the of (4@0:0:0) PCI device is the Primary.
The '*' denote primary, see the l
On 2023/9/5 23:05, Thomas Zimmermann wrote:
Hi
Am 05.09.23 um 15:30 schrieb suijingfeng:
Hi,
On 2023/9/5 18:45, Thomas Zimmermann wrote:
Hi
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over
which
one is prim
Hi,
On 2023/9/5 23:05, Thomas Zimmermann wrote:
However, on modern Linux systems the primary display does not really
exist. 'Primary' is the device that is available via VGA, VESA or EFI.
I may miss the point, what do you means by choose the word "modern"?
Are you trying to tell me that X se
SMU v13.0.6 SOCs have 100MHz reference clock.
Signed-off-by: Lijo Lazar
---
drivers/gpu/drm/amd/amdgpu/soc15.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c
b/drivers/gpu/drm/amd/amdgpu/soc15.c
index f5be40d7ba36..28094cd7d9c2 100644
--
[AMD Official Use Only - General]
Reviewed-by: Hawking Zhang
Regards
Hawking
-Original Message-
From: Lazar, Lijo
Sent: Wednesday, September 6, 2023 11:57
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Deucher, Alexander
Subject: [PATCH] drm/amdgpu: Fix refclk reporting for SM
On 9/5/2023 10:46 PM, Alex Deucher wrote:
> On Mon, Sep 4, 2023 at 2:30 AM Ma Jun wrote:
>>
>> [1] Remove the irq flags setting code since pci_alloc_irq_vectors()
>> handles these flags.
>> [2] Free the msi vectors in case of error.
>>
>> Signed-off-by: Ma Jun
>> ---
>> drivers/gpu/drm/amd/am
Am 05.09.23 um 15:30 schrieb suijingfeng:
Hi,
On 2023/9/5 18:45, Thomas Zimmermann wrote:
Hi
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve above m
Am 05.09.23 um 16:28 schrieb Sui Jingfeng:
Hi,
On 2023/9/5 21:28, Christian König wrote:
2) Typically, those non-86 machines don't have a good UEFI firmware
support, which doesn't support select primary GPU as firmware
stage.
Even on x86, there are old UEFI firmwares which already mad
[1] Remove the irq flags setting code since pci_alloc_irq_vectors()
handles these flags.
[2] Free the msi vectors in case of error.
v2:
- Remove local variable initializing code (Christian)
- Use PCI_IRQ_ALL_TYPES (Alex)
Signed-off-by: Ma Jun
---
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 45 +++
91 matches
Mail list logo
