Messages in this thread | | | Subject | Re: PATCH 2.4.0 parisc PCI support | Date | Mon, 05 Mar 2001 14:16:05 -0800 | From | Grant Grundler <> |
| |
Ivan Kokshaysky wrote: > On Fri, Mar 02, 2001 at 11:32:35AM -0800, Grant Grundler wrote: > > Code in parisc-linux CVS (based on 2.4.0) does boot on my OB800 > > (133Mhz Pentium), C3000, and A500 with PCI-PCI bridge support > > working. I'm quite certain PCI-PCI bridge configuration (ie BIOS > > didn't configure the bridge) support was broken. > > I believe it isn't. ;-) It works on various alphas including > configurations with chained PCI-PCI bridges.
Ok. I overlooked the changes in arch/alpha/kernel/pci.c:pcibios_fixup_bus(). (As you know, things changed alot between -test10 and -test12)
> Some comments on the patch: > > > +** If I/O or MEM ranges are overlapping, that's a BIOS bug. > > No. As we reallocate everything, it is quite possible that we'll > have temporary overlaps during setup with resources allocated > by BIOS. I'm not sure if it is harmful though.
The other part of the comment I added was: +** Disabling *all* devices is bad. Console, root, etc get +** disabled this way.
I can't debug with *all* devices disabled.
Normally, the whole point of resource mgt is to (a) avoid overlaps and (b) reflect the state of the HW. I thought the arch specific code was responsible for setting the HW state and resource mgt state congruent. If the arch/alpha code wants everything reallocated anyway, why not have the arch code disable the HW during the bus walk in pcibios_fixup_bus() before calling pci_assign_unassigned_resources()?
(I'm looking at 2.4.0 linux/arch/alpha/kernel/pci.c:common_init_pci() )
FYI, under PDC PAT (eg A500), unused devices are left in the "power on" state (which AFAIK, implies disabled).
> > +#ifdef __hppa__ > > +/* XXX FIXME > > +** PCI_BRIDGE_CONTROL and PCI_COMMAND programming need to be revisited > > +** to support FBB. Make all this crud "configurable" by the arch specific > > +** (ie "PCI BIOS") support and the ifdef __hppa__ crap can go away then. > > +*/ > > Agreed. Something like pcibios_set_bridge_control().
possibly...I have another problem I wanted to solve - FBB support.
I think generic Fast Back-Back support wants a new field in struct pci_bus (u32 bridge_ctl) to save and manage the FBB state (and SERR/PERR). Arch support would need a way to initialize bridge_ctl *before* pci_do_scan_bus() is called to indicate FBB is or is not supported by the parent PCI bus controller (either HBA or PCI-PCI Bridge).
Originally I was thinking of seperating the "root" bus allocation from pci_scan_bus(). But calling pcibios_set_bridge_control() before the bus walk would work too if it passes struct pci_bus * as the parameter. And that could allow arch specific control over SERR/PERR bits as well.
In pcibios_fixup_bus(), the arch code could check FBB state to see if it should be enabled on that HBA or not. Ideally, generic code would fully handle FBB for PCI-PCI secondary busses. Perhaps the FBB test could be in pci_setup_bridge() but I'm not sure if that would work for all arches (ie not sure off hand which uses pci_setup_bridge()).
[ deleted code changes in drivers/pci/setup-bus.c:pbus_assign_resources() driver/pci/setup-res.c:pdev_sort_resources() ]
> This change totally breaks PCI allocation logic. > Probably you assign PCI-PCI bridge windows in arch specific code - why?
I think my change in pdev_sort_resources() permitted it to occur in generic code. parisc HBA code only calls request_resources for resources assigned by firmware to the HBA.
> The only thing you need is to set up the root bus resources > properly and generic code will do the rest.
hmmm...Code in alpha's pcibios_fixup_bus() modifies PCI-PCI Bridge resources. It wouldn't if your statement were literally true.
I reversed the two changes in my tree to see what breaks on A500:
| lba version TR4.0 (0x5) found at 0xfffffffffed3c000 | lba_fixup_bus(0x0000000018b4b780) bus 48 sysdata 0x0000000018b4a800 | lba_fixup_bus() LBA I/O Port [30000/3ffff]/100 | lba_fixup_bus() LBA LMMIO [fffffffffb000000/fffffffffb7fffff]/200 | lba_fixup_bus(0x0000000018b4b880) bus 49 sysdata 0x0000000018b4a800 | lba_fixup_bus(0x0000000018b4b980) bus 50 sysdata 0x0000000018b4a800 | PCI: Failed to allocate resource 0 for 31:04.0 | PCI: Failed to allocate resource 0 for 31:04.1
[ I have a 4-port 100BT card and a 2-port 100BT/896 SCSI "combo" card installed in bus 48 - both have PCI-PCI bridges. No resources are available for any devices under either PPB. ]
... | tulip: eth1: I/O region (0xfffffffffffd0000@0x31000) unavailable, aborting ... | sym53c896-6: rev 0x5 on pci bus 49 device 4 function 0 irq 320 | sym53c896-6: ID 7, Fast-40, Parity Checking | sym53c896-6: on-chip RAM at 0xfffffffffb100000 | CACHE TEST FAILED: reg dstat-sstat2 readback ffffffff. | CACHE INCORRECTLY CONFIGURED. ...
Should I try to follow alpha's pcibios_fixup_bus() and add the code following (linux 2.4.0, arch/alpha/kernel/pci.c line 256)
/* This is a bridge. Do not care how it's initialized, just link its resources to the bus ones */
to the parisc pcibios_fixup_bus() ?
Or do you want to change how alpha works to follow what you said? I would prefer this but it doesn't matter ATM; just needs to work.
thanks! grant
Grant Grundler parisc-linux {PCI|IOMMU|SMP} hacker +1.408.447.7253 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |