public inbox for linux-pci@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: "Koenig, Christian" <Christian.Koenig@amd.com>
Cc: "Deucher, Alexander" <Alexander.Deucher@amd.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: Question about call to pci_assign_unassigned_bus_resources in amdgpu
Date: Mon, 24 Jun 2019 18:47:50 +1000	[thread overview]
Message-ID: <ea9f770c373ad9c6a998edbd603972014e4b7fea.camel@kernel.crashing.org> (raw)
In-Reply-To: <71904c98-be86-2807-d5c9-4b90c7387f6f@amd.com>

On Mon, 2019-06-24 at 08:42 +0000, Koenig, Christian wrote:
> Then we resize the VRAM BAR by calling pci_resize_resource(). That in 
> turn tries to resize and shuffle around the parent bridge resources 
> using pci_reassign_bridge_resources().
> 
> But pci_reassign_bridge_resources() does not assign any device 
> resources, it just tries to make sure the upstream bridges have enough 
> space to fit everything in.
> 
> Independent if we succeeded or failed with handling the bridge(s) we 
> call pci_assign_unassigned_bus_resources() to re-assign the previously 
> freed up VRAM and doorbell BARs.
> 
> So yeah, this definitely necessary, or otherwise the driver would crash 
> soon after because the resources are not assigned again.

Oh, I missed that pci_reassign_bridge_resources() didn't reassign the
resources under the bridge... ugh... that code is a bloody mess.

We have 4 or 5 "assign bus resources" functions, all subtly different
for no clear reasons (the historical changelogs from Yinghai may as
well don't exist, they are basically encrypted), and in most case for
no good reasons....

Question: Do you ever need to assign anything other than that one
device though ? In my branch, I've added this typically for the case
where a single device needs to be reassigned:

+void pci_dev_assign_resources(struct pci_dev *dev)
+{
+	LIST_HEAD(head);
+
+	/* Assign non-fixed resources */
+	__dev_sort_resources(dev, &head);
+	__assign_resources_sorted(&head, NULL, NULL);
+
+	/* Assign fixed ones if any */
+	pdev_assign_fixed_resources(dev);
+}
+EXPORT_SYMBOL(pci_dev_assign_resources);

Would that work for you ?

If yes, I'll replace pci_assign_unassigned_bus_resources(). I'd like to
eventually kill it..

Cheers,
Ben.



  reply	other threads:[~2019-06-24  8:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-24  4:27 Question about call to pci_assign_unassigned_bus_resources in amdgpu Benjamin Herrenschmidt
2019-06-24  8:42 ` Koenig, Christian
2019-06-24  8:47   ` Benjamin Herrenschmidt [this message]
2019-06-24  8:56     ` Benjamin Herrenschmidt
2019-06-24  9:10       ` Koenig, Christian
2019-06-24  9:08     ` Koenig, Christian
2019-06-24  9:15       ` Benjamin Herrenschmidt
2019-06-24  9:42         ` Koenig, Christian
2019-06-24 10:27           ` Benjamin Herrenschmidt

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=ea9f770c373ad9c6a998edbd603972014e4b7fea.camel@kernel.crashing.org \
    --to=benh@kernel.crashing.org \
    --cc=Alexander.Deucher@amd.com \
    --cc=Christian.Koenig@amd.com \
    --cc=linux-pci@vger.kernel.org \
    /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