x86 pci: Add option to not assign BAR's if not already assigned
in [Kernel]
|
Prev: [PATCH 2/8] x86/mrst: add cpu type detection for Medfield
Next: virtio_blk: Use blk-iopoll for host->guest notify
From: Jesse Barnes on 14 May 2010 19:40 On Fri, 14 May 2010 16:32:07 -0700 "H. Peter Anvin" <hpa(a)zytor.com> wrote: > On 05/14/2010 04:28 PM, Jesse Barnes wrote: > > On Fri, 14 May 2010 16:20:45 -0700 > > "H. Peter Anvin" <hpa(a)zytor.com> wrote: > > > >> On 05/14/2010 03:47 PM, Jesse Barnes wrote: > >>> > >>> Wow and they're using cards that want to use I/O space? Funky. It's > >>> too late to get this into 2.6.34, but that can't be what you were > >>> expecting... I don't see a problem with getting something like this in > >>> for 2.6.35. > >>> > >> > >> Most cards on the market provide I/O BARs as a convenience to legacy > >> BIOSes; they don't need the I/O BAR functionality from inside a > >> full-featured OS. There are a few, key, exceptions, mainly in the form > >> of legacy-interface devices like UARTs and VGA (note that VGA has its > >> own routing bits and is therefore unaffected by this problem.) > > > > Yeah, it's the "legacy" part that I'm questioning. I'm just lamenting > > that it's dying off so slowly... > > > > And yes, VGA is an unfortunate standard. > > > > 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! -- Jesse Barnes, Intel Open Source Technology Center -- 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: Jesse Barnes on 14 May 2010 20:10 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! -- Jesse Barnes, Intel Open Source Technology Center -- 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: Jesse Barnes on 28 May 2010 15:40 On Fri, 28 May 2010 10:10:16 -0700 Mike Travis <travis(a)sgi.com> wrote: > > > 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? Applied to my linux-next branch, thanks. -- Jesse Barnes, Intel Open Source Technology Center -- 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: Jesse Barnes on 2 Jun 2010 12:00 On Wed, 02 Jun 2010 17:47:23 +0200 "H. Peter Anvin" <hpa(a)zytor.com> wrote: > On 06/02/2010 05:45 PM, Bjorn Helgaas wrote: > > On Wednesday, June 02, 2010 01:31:18 am H. Peter Anvin wrote: > >> On 06/01/2010 03:49 PM, Bjorn Helgaas wrote: > >>>> > >>>> BIOS still assigns the MMIO BAR's so the devices are alive. > >>> > >>> I'm sorry; I don't follow this. BIOS assigns MMIO BARs regardless > >>> of whether we have your patch. > >> > >> I'm assuming that that Mike is implying is that the allocation code runs > >> out of I/O space and as a result shuts down the entire device. > > > > Yeah, that's why I asked about a deeper problem. There's not really a > > "shut down this device" flag, so the only way I can think of that we > > might make a device completely unusable is if we release all the device > > resources and then fail to reassign them. > > > > A concrete example, e.g., a dmesg log, would go a long ways toward > > clarifying this. > > > > That's what I thought, which I guess means my original question to Mike > still stands... I thought the whole reason for this was hotplug; we don't want to exhaust I/O space unnecessarily by allocating resources for BARs the BIOS didn't assign so we can keep them around for later hotplug activity. If there's some other issue, it's not too late to drop this patch. Mike or Mike, can you clarify? -- Jesse Barnes, Intel Open Source Technology Center -- 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: Jesse Barnes on 8 Jun 2010 21:30
On Tue, 08 Jun 2010 17:53:19 -0700 "H. Peter Anvin" <hpa(a)zytor.com> wrote: > On 06/02/2010 08:53 AM, Jesse Barnes wrote: > >> > >> That's what I thought, which I guess means my original question to Mike > >> still stands... > > > > I thought the whole reason for this was hotplug; we don't want to > > exhaust I/O space unnecessarily by allocating resources for BARs the > > BIOS didn't assign so we can keep them around for later hotplug > > activity. > > > > If there's some other issue, it's not too late to drop this patch. > > > > Okay, now... this means that if a device that the BIOS doesn't know > about, but which needs I/O addresses, then it will work if hotplugged, > but not if it is plugged in on system boot? Depends on the BIOS interactions on this platform; if the kernel ends up doing all the allocations itself, we'll allocate space for every BAR unconditionally, meaning that any hotplugged device should work. But really the SGI guys should comment here. -- Jesse Barnes, Intel Open Source Technology Center -- 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/ |