[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140426091031.GA10166@pd.tnic>
Date: Sat, 26 Apr 2014 11:10:31 +0200
From: Borislav Petkov <bp@...e.de>
To: Myron Stowe <myron.stowe@...il.com>
Cc: Myron Stowe <myron.stowe@...hat.com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
linux-pci <linux-pci@...r.kernel.org>,
Suravee Suthikulpanit <suravee.suthikulpanit@....com>,
Aravind Gopalakrishnan <aravind.gopalakrishnan@....com>,
kim.naru@....com, daniel@...ascale.com,
Thomas Gleixner <tglx@...utronix.de>, mingo@...hat.com,
hpa@...or.com, x86 <x86@...nel.org>, sp@...ascale.com,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Robert Richter <rric@...nel.org>
Subject: Re: [PATCH v2 2/5] x86/PCI: Support additional MMIO range
capabilities
+ Robert.
On Fri, Apr 25, 2014 at 04:24:31PM -0600, Myron Stowe wrote:
> On Sun, Apr 20, 2014 at 1:59 AM, Borislav Petkov <bp@...e.de> wrote:
> > Drop Andreas' old email address from CC as it keeps bouncing.
> >
> > On Sat, Apr 19, 2014 at 03:52:20PM +0200, Borislav Petkov wrote:
> >> > -static void __init pci_enable_pci_io_ecs(void)
> >> > +static void __init pci_enable_pci_io_ecs(u8 bus, u8 slot)
> >> > {
> >> > #ifdef CONFIG_AMD_NB
> >> > unsigned int i, n;
> >> > + u8 limit;
> >> >
> >> > for (n = i = 0; !n && amd_nb_bus_dev_ranges[i].dev_limit; ++i) {
> >> > - u8 bus = amd_nb_bus_dev_ranges[i].bus;
> >> > - u8 slot = amd_nb_bus_dev_ranges[i].dev_base;
> >> > - u8 limit = amd_nb_bus_dev_ranges[i].dev_limit;
> >> > + /* Try matching for the bus range */
> >> > + if ((bus != amd_nb_bus_dev_ranges[i].bus) ||
> >> > + (slot != amd_nb_bus_dev_ranges[i].dev_base))
> >> > + continue;
> >> > +
> >> > + limit = amd_nb_bus_dev_ranges[i].dev_limit;
> >> >
> >> > + /* Setup all northbridges within the range */
> >> > for (; slot < limit; ++slot) {
> >> > u32 val = read_pci_config(bus, slot, 3, 0);
> >> > -
> >> > - if (!early_is_amd_nb(val))
> >> > + if (!val)
> >> > continue;
> >> >
> >> > val = read_pci_config(bus, slot, 3, 0x8c);
> >> > @@ -375,13 +457,14 @@ static void __init pci_enable_pci_io_ecs(void)
> >> > val |= ENABLE_CF8_EXT_CFG >> 32;
> >>
> >> What a fun shifting!
> >>
> >> Maybe you should do
> >>
> >> #define ENABLE_CF8_EXT_CFG BIT(46 - 32)
> >>
> >> to show exactly what you mean and how the bit is defined in MSR NB_CFG1
> >> and also show how the high 32-bits are mapped into F3x8c, while at it.
> >>
> >> And then you can drop the shifting at the call site.
> >
> > Ok, I see another fun with this ECS enabling:
> >
> > There's a enable_pci_io_ecs() which enables ECS through the NB_CFG MSR
> > which is called as part of the notifier *and* there's a PCI write to
> > that same bit in pci_enable_pci_io_ecs() which iterates over all NBs.
> >
> > So, AFAICT, we do it twice and the second time is not needed. Which
> > means, you probably can drop pci_enable_pci_io_ecs() completely and use
> > solely the notifier?
>
> It does look as if there is some duplication with respect to setting
> MSR_AMD64_NB_CFG's (which is aliased at D18F3x8c [1])
> ENABLE_CF8_EXT_CFG enable bit but there are at least a couple of
> differences.
>
> enable_pci_io_ecs() only sets the bit on one NB whereas
> pci_enable_pci_io_ecs iterates over all the NBs (as you mentioned
> above). The other difference has something to do with Xen; see the
> origin of pci_enable_pci_io_ecs - commit 24d9b70b8.
Of course it is xen - what else?! We do have to carry special code in
baremetal just for it because it is special and we all can't seem to get
enough of its crap.
Oh well, I guess we should at least comment this and refer to 24d9b70b8
so that the explanation is right there, in the code.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
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