x86 pci: Add option to not assign BAR's if not already assigned
in [Kernel]
|
Prev: x86 pci: Add option to not assign BAR's if not already assigned
Next: pci: check caps from sysfs file open to read device dependent config space
From: H. Peter Anvin on 14 May 2010 20:20 On 05/14/2010 05:00 PM, Jesse Barnes wrote: > On Fri, 14 May 2010 16:39:59 -0700 > "H. Peter Anvin" <hpa(a)zytor.com> wrote: > >> On 05/14/2010 04:34 PM, Jesse Barnes wrote: >>>> I'm not lamenting that fact, because my experience is that what ends up >>>> replacing it is often far worse. Consider UARTs -- no MMU dependencies >>>> at all, can be accessed with four lines of assembly, and compare it to >>>> EHCI debug port, the driver for which is over 900 lines in the Linux >>>> kernel -- and that assumes that you're already in flat mode. >>> >>> Heh, you're so old and crufty! >> >> I know. Debugging is so 20th century. > > Yeah, get with the times. Debugging on today's machines means you have > to look up register block offsets in ACPI, run some AML to setup your > debug port, and then load a microkernel onto the debug device to get > your vnc enabled debug console! > An excellent plan! Cannot fail! -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mike Travis on 14 May 2010 22:30 .... We're somewhat fortunate in that our Legacy I/O > devices are confined to those on the first blade, and all of these > other devices are on other blades (PCI segments 1+). By "somewhat" I meant we'd be way more fortunate without the legacy I/O devices at all! But hpa is right, 4 lines of assembler is way better than (900?) lines of C. My feeling is that if a CPU needs legacy i/o it should be built into the chip. HAH! ;-) The BIOS should just list the machine resources, in a "non-BIOS" way, (oh wait, that's ACPI! :*) Cheers! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mike Travis on 28 May 2010 13:00 Any further consideration for this patch, or has it been rejected? Thanks, Mike Mike Travis wrote: > Subject: [Patch 1/1] x86 pci: Add option to not assign BAR's if not > already assigned > From: Mike Habeck <habeck(a)sgi.com> > > The Linux kernel assigns BARs that a BIOS did not assign, most likely > to handle broken BIOSes that didn't enumerate the devices correctly. > On UV the BIOS purposely doesn't assign I/O BARs for certain devices/ > drivers we know don't use them (examples, LSI SAS, Qlogic FC, ...). > We purposely don't assign these I/O BARs because I/O Space is a very > limited resource. There is only 64k of I/O Space, and in a PCIe > topology that space gets divided up into 4k chucks (this is due to > the fact that a pci-to-pci bridge's I/O decoder is aligned at 4k)... > Thus a system can have at most 16 cards with I/O BARs: (64k / 4k = 16) > > SGI needs to scale to >16 devices with I/O BARs. So by not assigning > I/O BARs on devices we know don't use them, we can do that (iff the > kernel doesn't go and assign these BARs that the BIOS purposely didn't > assign). > > This patch will not assign a resource to a device BAR if that BAR was > not assigned by the BIOS, and the kernel cmdline option 'pci=nobar' > was specified. This patch is closely modeled after the 'pci=norom' > option that currently exists in the tree. > > Signed-off-by: Mike Habeck <habeck(a)sgi.com> > Signed-off-by: Mike Travis <travis(a)sgi.com> > --- > Documentation/kernel-parameters.txt | 2 ++ > arch/x86/include/asm/pci_x86.h | 1 + > arch/x86/pci/common.c | 20 ++++++++++++++++++++ > 3 files changed, 23 insertions(+) > > --- linux.orig/Documentation/kernel-parameters.txt > +++ linux/Documentation/kernel-parameters.txt > @@ -1935,6 +1935,8 @@ and is between 256 and 4096 characters. > norom [X86] Do not assign address space to > expansion ROMs that do not already have > BIOS assigned address ranges. > + nobar [X86] Do not assign address space to the > + BARs that weren't assigned by the BIOS. > irqmask=0xMMMM [X86] Set a bit mask of IRQs allowed to be > assigned automatically to PCI devices. You can > make the kernel exclude IRQs of your ISA cards > --- linux.orig/arch/x86/include/asm/pci_x86.h > +++ linux/arch/x86/include/asm/pci_x86.h > @@ -30,6 +30,7 @@ > #define PCI_HAS_IO_ECS 0x40000 > #define PCI_NOASSIGN_ROMS 0x80000 > #define PCI_ROOT_NO_CRS 0x100000 > +#define PCI_NOASSIGN_BARS 0x200000 > > extern unsigned int pci_probe; > extern unsigned long pirq_table_addr; > --- linux.orig/arch/x86/pci/common.c > +++ linux/arch/x86/pci/common.c > @@ -125,6 +125,23 @@ void __init dmi_check_skip_isa_align(voi > static void __devinit pcibios_fixup_device_resources(struct pci_dev *dev) > { > struct resource *rom_r = &dev->resource[PCI_ROM_RESOURCE]; > + struct resource *bar_r; > + int bar; > + > + if (pci_probe & PCI_NOASSIGN_BARS) { > + /* > + * If the BIOS did not assign the BAR, zero out the > + * resource so the kernel doesn't attmept to assign > + * it later on in pci_assign_unassigned_resources > + */ > + for (bar = 0; bar <= PCI_STD_RESOURCE_END; bar++) { > + bar_r = &dev->resource[bar]; > + if (bar_r->start == 0 && bar_r->end != 0) { > + bar_r->flags = 0; > + bar_r->end = 0; > + } > + } > + } > > if (pci_probe & PCI_NOASSIGN_ROMS) { > if (rom_r->parent) > @@ -509,6 +526,9 @@ char * __devinit pcibios_setup(char *st > } else if (!strcmp(str, "norom")) { > pci_probe |= PCI_NOASSIGN_ROMS; > return NULL; > + } else if (!strcmp(str, "nobar")) { > + pci_probe |= PCI_NOASSIGN_BARS; > + return NULL; > } else if (!strcmp(str, "assign-busses")) { > pci_probe |= PCI_ASSIGN_ALL_BUSSES; > return NULL; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 28 May 2010 13:10 On 05/28/2010 09:53 AM, Mike Travis wrote: > Any further consideration for this patch, or has it been rejected? Well, it's really up to Jesse, but as far as I can see, this patch is a net loss of functionality and doesn't actually add anything. Without this patch, some resources that were not assigned by BIOS will be unreachable. With this patch, *all* resources that were not assigned by BIOS will be unreachable... -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mike Travis on 28 May 2010 13:20
H. Peter Anvin wrote: > On 05/28/2010 09:53 AM, Mike Travis wrote: >> Any further consideration for this patch, or has it been rejected? > > Well, it's really up to Jesse, but as far as I can see, this patch is a > net loss of functionality and doesn't actually add anything. Without > this patch, some resources that were not assigned by BIOS will be > unreachable. With this patch, *all* resources that were not assigned by > BIOS will be unreachable... > > -hpa > Apparently you're missing the point of the patch? The patch is needed because BIOS is purposely not assigning I/O BAR's to devices that won't use them, freeing up the resource for devices that do need them. Where is the "all" resources that are not reachable? Thanks, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |