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
>> ---
>>
[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
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
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
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
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
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
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 |
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 +
>
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 +++---
>
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: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
[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 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 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 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
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 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
>
>
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
[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
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
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 +
>
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 +---
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
`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
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
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 +
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:
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:
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
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
---
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]
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
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
[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
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
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 +--
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:
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
> ---
>
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
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(-)
>
>
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(-)
>
>
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
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
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.
>
>
>
[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
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
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
[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
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
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
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
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
> ---
>
[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
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
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
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
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
> ---
>
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
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
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)
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
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
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 +-
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 +--
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
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
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
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
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
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
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
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
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()
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
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.
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
>> ---
>>
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
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
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
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 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 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
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
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 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.
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
[AMD Official Use Only - General]
Looks good to me.
Series is:
Reviewed-by: Solomon Chiu
From: Yu, Lang
Sent: Monday, September 4, 2023 12:22 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Chiu, Solomon
; Yu, Lang ; kernel test robot
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/amdgpu/gmc_v10_0.c | 6 +-
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c |
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
---
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 66 --
1 file changed, 19 insertions(+), 47 deletions(-)
diff --git
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 one.
Signed-off-by: Christian König
---
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
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 19 +++
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 74 -
2 files
That function never fails, drop the error return.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 7 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h | 6 +++---
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 7 +++
drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c | 7 +++
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
---
drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c | 63 --
1 file changed, 19 insertions(+), 44 deletions(-)
diff --git
Move the SDMA workaround necessary for Navi 1x into a higher layer.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 48 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h | 5 +-
drivers/gpu/drm/amd/amdgpu/gfxhub_v2_0.c | 3 +
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 one.
Signed-off-by: Christian König
---
Testing for reset is pointless since the reset can start right after the
test.
The same PASID can be used by more than one VMID, reset each of them.
Move the KIQ and all the workaround handling into common GMC code.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c |
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 --git a/drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c
The KIQ code path was ignoring the second flush. Also avoid long lines and
re-calculating the register offsets over and over again.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 29 +--
1 file changed, 18 insertions(+), 11 deletions(-)
diff
1 - 100 of 101 matches
Mail list logo
