On Monday 23 November 2009 11:52:19 am Ira W. Snyder wrote: > On Fri, Nov 20, 2009 at 05:18:15PM -0700, Bjorn Helgaas wrote: > > On Monday 16 November 2009 04:41:27 pm Ira W. Snyder wrote: > > > On Mon, Nov 16, 2009 at 03:07:40PM -0800, Ira W. Snyder wrote: > > > > > > [ big snip ] > > > > > > > > > > > > > This looks like legacy IDE stuff for a device that is probably built into > > > > > the southbridge. Since it lives on PCI bus 0, I suppose these regions > > > > > should somehow be added as apertures that the host bridge claims. This > > > > > is all the sort of stuff that firmware is supposed to handle for you > > > > > when it builds the host bridge _CRS (if you have ACPI). > > > > > > > > > > I can't think of anything better than just adding these as hard-coded > > > > > apertures. > > > > > > > > > > > > > Ok. This makes sense, they are part of the IDE device, a function of the > > > > south bridge. Interestingly, they do not show up on the Force computer > > > > at all, only on the Trenton. > > > > > > > > ===== Force: ===== > > > > iws@labslcor4 ~ $ lspci -vvv -s 00:0f.1 > > > > 00:0f.1 IDE interface: Broadcom OSB4 IDE Controller (prog-if 8a [Master SecP PriP]) > > > > Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- > > > > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > > > > Latency: 64 > > > > Region 4: I/O ports at 1400 [size=16] > > > > Kernel driver in use: Serverworks_IDE > > > > > > > > These I/O ports *do* show up on Bridge 0, where I decoded them to be. > > > > They are 1000-140c. All of the I/O ports show up correctly in the bridge > > > > on the Force. > > > > > > > > iws@labslcor4 ~ $ lspci -vvv | grep 'I/O ports' > > > > Region 1: I/O ports at 1080 [size=64] > > > > Region 1: I/O ports at 10c0 [size=64] > > > > Region 1: I/O ports at 1000 [size=128] > > > > Region 4: I/O ports at 1400 [size=16] > > > > > > > > > > > > ===== Trenton: ===== > > > > iws@labslcor3 ~ $ lspci -vvv -s 00:0f.1 > > > > 00:0f.1 IDE interface: Broadcom OSB4 IDE Controller (prog-if 8a [Master SecP PriP]) > > > > Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- > > > > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > > > > Latency: 64 > > > > Region 0: [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [size=8] > > > > Region 1: [virtual] Memory at 000003f0 (type 3, non-prefetchable) [size=1] > > > > Region 2: [virtual] Memory at 00000170 (32-bit, non-prefetchable) [size=8] > > > > Region 3: [virtual] Memory at 00000370 (type 3, non-prefetchable) [size=1] > > Something interesting I noticed. These "virtual" memory regions only > show up on the 2.6.32-rc6 pci-next kernel. They do not show up at all on > a 2.6.18-92.el5 (Centos 5.2) kernel. One difference is the use of > libata PATA vs. the old IDE subsystem. > > What is a virtual memory region, anyway? Memory behind a southbridge? I have no idea what those are. To figure it out, I would look at the lspci source to see how it decides what is "virtual". > Also, the Trenton doesn't seem to show the IDE controller I/O ports > (ffa0) anywhere in bridge configuration space. The Force computer does > show them, along with the rest of the ports. > > I'm curious if the IDE interface on the Trenton even works, I've never > tested it. I would need a breakout board, which I don't own. > > I'm happy to ignore the IDE controller and just get the bits that allow > hotplug to work for PCI cards. Does this seem reasonable? I think we need some sort of generic PCI host bridge structure that describes the apertures it forwards downstream. You've figured out how to discover some of those apertures. For others (e.g., IDE), I think it would be reasonable to just add apertures for the downstream resources BIOS has assigned, on the assumption that BIOS did it correctly. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
