Messages in this thread | | | Subject | Re: PATCH 2.4.0 parisc PCI support | Date | Wed, 07 Mar 2001 17:27:57 -0800 | From | Grant Grundler <> |
| |
Ivan Kokshaysky wrote: ... > Well, it seems that I finally see what is wrong with your code, and > why it worked in your case. You assume that "window" resources of > the bridge are already known when we call pbus_assign_resources_sorted(). > This is incorrect.
Oh...do we know the "sizes" of all child resources from the bus walk? I'll check that and see if it can be safely changed.
> Probably you rely on pci_read_bridge_bases() doing > something meaningful (I looked at the parisc pci code in current 2.4.x, > don't know about your CVS tree).
Nope - don't call that for A500 (machines with PDC PAT)...that might in fact be another problem later related to some PDC (aka BIOS) changes.
> Yes, at least some of the DEC bridges > after power-up/reset have 0s in base/limit registers. This means > that you have ranges 0000-0fff (4K) for IO and 00000000-000fffff (1M) > for MEM. Obviously it's enough to hold all resources on the > cards you've tested, but it won't work in common case. There is > a lot of reasons why; just a couple of them: > - according to PPB specification, base/limits registers of the bridge > after reset are *undefined*, so you'll probably have troubles > with non-DEC bridges. > - there is a number of alpha systems with a built-in PCI-PCI bridge > and real PCI slots behind it. Obviously 4K/1M isn't enough for > these systems, and it was the main reason of rewriting that code. > etc etc etc.
Yup - I think you are right on all counts here. I'll rework the parisc code tonight/tomorrow and see if I can get rid of the contentious generic PCI changes. I should be able to.
> Basically, you won't know bridge "window" size for a given bus until > you'll have allocated *all* devices on *all* its child busses.
Linux doesn't. It's possible to deal with window register size in the initial bus walk (where BAR sizes are determined).
> Besides, including bridge resources in the "sort lists" is meaningless, > since these resources have fixed alignment - 4K for IO and 1M for MEM, > unlike "regular" ones, which alignment == size.
The alignment would have to be handled correctly and I thought pcibios_align_resource() did that. I see now the arch/parisc one doesn't and others probably don't either. Let me think about this more...
> Unfortunately I haven't anything with a bridge handy at the moment > to test that patch. Besides, we'll have here a sort of holidays till > Sunday. So maybe next week...
np. thanks.
> > > I don't think existing PCI code is very "dirty". > > I hope so. :-)
:^)
> However, some problems need to be worked out: > 1. generic vs. arch code - we've already discussed some of these > 2. Prefetchable Memory - do we need to deal with it? Though looking > at modern x86 systems I tend to keep it disabled :-)
Ditto for parisc.
> 3. pdev_enable_device() - it's a bit ugly, confuses people and > possibly is not needed at all.
Agreed.
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/
| |