From: Mario Limonciello <superm1@kernel.org>
To: Alex Deucher <alexdeucher@gmail.com>
Cc: amd-gfx@lists.freedesktop.org,
Mario Limonciello <mario.limonciello@amd.com>
Subject: Re: [PATCH v2] drm/amd: Add pre-zen AMD hardware to PCIe dynamic switching exclusions
Date: Thu, 3 Apr 2025 14:13:24 -0500 [thread overview]
Message-ID: <1d762b4d-3aae-4fad-b464-d1baa124e86e@kernel.org> (raw)
In-Reply-To: <CADnq5_Nz76WBm8wsU8k4LUpXrjKk6AbJfYV0CpaV3sXAJ2McEQ@mail.gmail.com>
On 4/3/2025 10:48 AM, Alex Deucher wrote:
> On Wed, Apr 2, 2025 at 11:12 PM Mario Limonciello <superm1@kernel.org> wrote:
>>
>> From: Mario Limonciello <mario.limonciello@amd.com>
>>
>> AMD RX580 when added AMD Phenom 2 has problems with overheating. This is due to
>
> I don't think this is entirely accurate. I think the GPU gets hot
> because the device hangs due to a problem with changing the PCIe
> clocks.
>
>> changes with PCIe dynamic switching introduced by commit 466a7d115326e
>> ("drm/amd: Use the first non-dGPU PCI device for BW limits").
>>
>> To avoid risks of other issues with old hardware require at least Zen hardware
>> for AMD side to enable PCIe dynamic switching.
>
> I'm pretty sure PCIe reclocking worked on pre-Zen hardware. We've
> supported this on our GPUs going back at least 15 or more years. I
> suspect the actual problem is that some links may not reliably train
> at the full bandwidth on some motherboards. Forcing a higher link
> speed may cause problems.
That seems odd to me it would advertise a higher link speed than it
could train at.
> Maybe it would be better to limit the max
> PCIe link rate to whatever the link is currently trained to. IIRC,
> PCIe links will train at the fastest link possible by default. The
> previous behavior was to limit the max clock to the slowest link in
> the topology to save power, but then we changed it to use the fastest
> link possible based on the PCIe link caps. Perhaps limiting it to the
> fastest currently trained link rate would be better.
I mean that's essentially what happens when
amdgpu_device_pcie_dynamic_switching_supported() returns that it doesn't
work.
If your theory is right; maybe what we really need is a pile of DMI
quirks for M/B that are having this problem.
>
> Alex
>
>>
>> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4098
>> Fixes: 466a7d115326e ("drm/amd: Use the first non-dGPU PCI device for BW limits")
>> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
>> ---
>> v2:
>> * Cover more hardware
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> index a30111d2c3ea0..caa44ee788c8f 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> @@ -1854,6 +1854,9 @@ bool amdgpu_device_seamless_boot_supported(struct amdgpu_device *adev)
>> *
>> * https://edc.intel.com/content/www/us/en/design/products/platforms/details/raptor-lake-s/13th-generation-core-processors-datasheet-volume-1-of-2/005/pci-express-support/
>> * https://gitlab.freedesktop.org/drm/amd/-/issues/2663
>> + *
>> + * AMD Phenom II X6 1090T has a similar issue
>> + * https://gitlab.freedesktop.org/drm/amd/-/issues/4098
>> */
>> static bool amdgpu_device_pcie_dynamic_switching_supported(struct amdgpu_device *adev)
>> {
>> @@ -1866,6 +1869,8 @@ static bool amdgpu_device_pcie_dynamic_switching_supported(struct amdgpu_device
>>
>> if (c->x86_vendor == X86_VENDOR_INTEL)
>> return false;
>> + if (c->x86_vendor == X86_VENDOR_AMD && !cpu_feature_enabled(X86_FEATURE_ZEN))
>> + return false;
>> #endif
>> return true;
>> }
>> --
>> 2.43.0
>>
next prev parent reply other threads:[~2025-04-03 19:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-03 3:11 [PATCH v2] drm/amd: Add pre-zen AMD hardware to PCIe dynamic switching exclusions Mario Limonciello
2025-04-03 15:48 ` Alex Deucher
2025-04-03 19:13 ` Mario Limonciello [this message]
2025-04-06 19:58 ` Alex Deucher
-- strict thread matches above, loose matches on Subject: below --
2025-04-04 17:21 Leo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1d762b4d-3aae-4fad-b464-d1baa124e86e@kernel.org \
--to=superm1@kernel.org \
--cc=alexdeucher@gmail.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=mario.limonciello@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox