All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Kurt Kartaltepe <kkartaltepe@gmail.com>,
	Alex Deucher <alexdeucher@gmail.com>
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: Remove pci address checks from acpi_vfct_bios
Date: Tue, 19 Mar 2024 10:54:48 +0100	[thread overview]
Message-ID: <cbc7739a-21c3-4872-bcb0-4fceaf607d32@amd.com> (raw)
In-Reply-To: <CACawnnx8Z5jbBdzct9Omeq3Y6iJhMDTDy_C3DRPe9irjoHRn+Q@mail.gmail.com>

Am 19.03.24 um 02:55 schrieb Kurt Kartaltepe:
> On Mon, Mar 18, 2024 at 12:57 PM Alex Deucher <alexdeucher@gmail.com> wrote:
>> On Mon, Mar 18, 2024 at 3:52 PM Alex Deucher <alexdeucher@gmail.com> wrote:
> ...
>>> Depends on the platform, but recent ones use VFCT.  That said, there
>>> should only ever be one IGPU in the system so I think we could just
>>> rely on the VID and DID for APUs in this case and check everything for
>>> dGPUs.
>> Is there a reason why you need this option?  Even beyond this, I could
>> envision other problems related to APUs and ACPI if these changed.
>>
>> Alex
> So there are multiple factors in play. I am trying to make use of the
> lovely usb4/tb3 controllers on the 7940HS with the reportedly Intel
> Tamales Module 2 pci/pci bridge over the usb4 interface. This provides
> a handy way to expand the pcie bus but configuring ACPI and pcie
> topology isn't generally an option on consumer BIOS (unless you want
> to enlighten me). This leaves us in the situation where the bios can
> enumerate devices poorly resulting in inaccessible devices due to
> address conflicts. To resolve address conflicts the only option I'm
> aware of is pci=assign-busses, maybe this could also be configured at
> runtime but assign-busses seemed nice in some ways.

Well what problems do you run into? The ACPI and BIOS assignments 
usually work much better than whatever the Linux PCI subsystem comes up 
with.

The PCI subsystem in the Linux kernel for example can't handle back to 
back resources behind multiple downstream bridges.

So when the BIOS fails to assign something it's extremely unlikely that 
the Linux kernel will do the right thing either.

Regards,
Christian.

>
> I havnt experienced any issues with the APU (graphics, hardware
> encoders/decoders) but I do think assign-busses might be renumbering
> again after suspend/resume/pci rescans but I need to debug further,
> maybe suspend/resume are just broken when ACPI addresses are wrong.
> Obviously the graphics user space (compositors, mesa might be working
> as expected) dont handle the device switching addresses while in use,
> for amdgpu kernel side I haven't inspected deeply yet.
>
> I'm not sure if this is the right approach to solving the problem, and
> given your input i'm considering it may be better, though not
> upstreamable, to implement renumbering only for specified devices like
> this pci bridge or investigate runtime management of the pci bus
> addresses. The current assign-busses implementation is quite the big
> hammer admittedly.
>
> --Kurt Kartaltepe


  reply	other threads:[~2024-03-19  9:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-18  6:52 [PATCH] drm/amdgpu: Remove pci address checks from acpi_vfct_bios Kurt Kartaltepe
2024-03-18 13:36 ` Alex Deucher
2024-03-18 14:19   ` Kurt Kartaltepe
2024-03-18 15:42     ` Alex Deucher
2024-03-18 16:06       ` Kurt Kartaltepe
2024-03-18 19:52         ` Alex Deucher
2024-03-18 19:57           ` Alex Deucher
2024-03-19  1:55             ` Kurt Kartaltepe
2024-03-19  9:54               ` Christian König [this message]
2024-03-19 15:04                 ` Kurt Kartaltepe
2024-03-20 13:31                   ` Christian König
2024-03-20 14:24                     ` Kurt Kartaltepe

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=cbc7739a-21c3-4872-bcb0-4fceaf607d32@amd.com \
    --to=christian.koenig@amd.com \
    --cc=alexdeucher@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=kkartaltepe@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.