From: Matthew Garrett <mjg59@srcf.ucam.org>
To: "Roedel, Joerg" <Joerg.Roedel@amd.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>,
"stable@kernel.org" <stable@kernel.org>
Subject: Re: [PATCH] x86: Reenable the AMD IOMMU if it's mysteriously vanished over suspend
Date: Mon, 4 Oct 2010 14:55:52 +0100 [thread overview]
Message-ID: <20101004135552.GA5063@srcf.ucam.org> (raw)
In-Reply-To: <20101004134339.GT9817@amd.com>
On Mon, Oct 04, 2010 at 03:43:39PM +0200, Roedel, Joerg wrote:
> > + pci_read_config_dword(iommu->dev, 0x44, &iommu->stored_addr_lo);
> > + pci_read_config_dword(iommu->dev, 0x48, &iommu->stored_addr_hi);
>
> Can you use iommu->cap_ptr here? This variant should be safe too but the
> magic numbers are non-descriptive.
Sure.
> > + /* There may be one iommu per bus, so find the appropriate bridge */
> > + while (pdev && (pdev->bus->number != iommu->dev->bus->number)) {
> > + pci_dev_put(pdev);
> > + pdev = pci_get_device(PCI_VENDOR_ID_ATI, device_id, pdev);
> > + }
>
> This does not work reliably with more than one IOMMU in the system. I
> suggest to get the NB device by using the bus/dev/fn of the IOMMU
> device. The IOMMU in RD890 is always function 2 of the NB device. So
> just take the bus/dev/fn of the IOMMU device, set fn to zero and get the
> NB device for re-enabling function two.
The docs imply that the northbridge will always be device 0 on a given
bus, so this ought to work? On the other hand, your approach is simpler.
> > for_each_iommu(iommu) {
> > iommu_disable(iommu);
> > - iommu_apply_quirks(iommu);
> > iommu_init_flags(iommu);
> > iommu_set_device_table(iommu);
> > iommu_enable_command_buffer(iommu);
> > @@ -1173,6 +1278,11 @@ static void disable_iommus(void)
> >
> > static int amd_iommu_resume(struct sys_device *dev)
> > {
> > + struct amd_iommu *iommu;
> > +
> > + for_each_iommu(iommu)
> > + iommu_apply_quirks(iommu);
> > +
> > /* re-load the hardware */
> > enable_iommus();
>
> Why have you moved this out of the enable_iommus() loop?
enable_iommus() is called on init, whereas this should only be performed
on resume.
I'll send out an updated patch later today.
--
Matthew Garrett | mjg59@srcf.ucam.org
next prev parent reply other threads:[~2010-10-04 13:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-01 14:01 [PATCH] x86: Reenable the AMD IOMMU if it's mysteriously vanished over suspend Matthew Garrett
2010-10-04 13:43 ` Roedel, Joerg
2010-10-04 13:55 ` Matthew Garrett [this message]
2010-10-04 14:13 ` Roedel, Joerg
2010-10-04 18:59 ` [PATCH v2] " Matthew Garrett
2010-10-06 10:07 ` Roedel, Joerg
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=20101004135552.GA5063@srcf.ucam.org \
--to=mjg59@srcf.ucam.org \
--cc=Joerg.Roedel@amd.com \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=stable@kernel.org \
--cc=x86@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 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.