[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100930184301.GP15338@8bytes.org>
Date: Thu, 30 Sep 2010 20:43:01 +0200
From: Joerg Roedel <joro@...tes.org>
To: Matthew Garrett <mjg59@...f.ucam.org>
Cc: linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
joerg.roedel@....com, jbarnes@...tuousgeek.org
Subject: Re: [PATCH] pci: Reenable the AMD IOMMU if it's mysteriously
vanished over suspend
On Thu, Sep 30, 2010 at 06:39:45PM +0100, Matthew Garrett wrote:
> On Thu, Sep 30, 2010 at 11:38:28AM -0400, Matthew Garrett wrote:
> > AMD's reference BIOS code had a bug that could result in the firmware
> > failing to reenable the iommu on resume. It transpires that this causes
> > certain less than desirable behaviour when it comes to PCI accesses, to
> > whit them ending up somewhere near Bristol when the more desirable outcome
> > was Edinburgh. Sadness ensues, perhaps along with filesystem corruption.
> > Let's make sure that it gets turned back on.
>
> Of course, this isn't actually sufficient - nothing in the iommu code
> appears to reprogram the BAR, for instance. Joerg, how is this meant to
> work?
Enabling the IOMMU device is only part of what the BIOS is supposed to
do to get the IOMMU ready for the OS. A handful of registers in the
config space of the device and the IOMMU MMIO region must also be
restored. Thats the simple part. The IOMMU device also spans two
indirect register spaces to configure the IOMMU caches. I have no idea
yet how this need to be configured. The plan is definitly to
work-around a missing IOMMU device in the IOMMU driver. But I am still
talking to some people to find out what exactly must be done, especially
with the indirect register spaces.
Joerg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists