On Thu, Feb 07, 2013 at 08:24:50AM +0000, Arnd Bergmann wrote: > Yes, but the mbus-matrix node in the example would need a ranges property > to map the addresses according to how the windows are set up. I'll hang on to this for next time the moving windows config to DT discussion comes up.. > > Maybe.. according to the standard the ranges in this stanza should > > reflect the bridge configuration, but that isn't known when the DT is > > written. An empty ranges means identity and that isn't really right > > either. > > Ok, I thought it was an identity mapping here. > > > Also, what should 'reg' be so that the PCI core binds the OF nodes > > properly? The standard says reg should have the configuration space > > address of the bridge, and I noticed Thierry was using something that > > almost looked like a config space address in his driver.. > > Well, that assumes that a bridge is addressed using configuration space, > which IIRC is normally the case but not here. With Thomas's driver each link has a PCI-PCI bridge in config space, and 'configuration space address' is that wonky format OF defines for encoding the bus/device/function number into the 3 dword address. So the correct thing is to put the bus/device/function of the PCI-PCI bridge for the link in the reg value. > I never really understood the 'assigned-addresses' property, but it looks > sensible. assigned-addresses does the same thing as reg in simple bus, but handles all the wonky PCI address translation > > - The CPU physical address window to use for the IO space > > is set via io-cpu-window, not much choice here, the PCI > > format ranges must be 0 based. > > I don't think I understand this part. Why can't you put this into > ranges as before? > > - 0x81000000 0x00000000 0x00000000 0x00000000 0x0 0xa0000 > + 0x81000000 0x00000000 0x00000000 0xc0000000 0x0 0xa0000 The OF PCI core translates 0x81000000 IO space addresess into a 'struct resource' tagged with IORESOURCE_IO. But 0xc0000000 is not an IORESOURCE_IO address, it is an IORESOURCE_MEM address.. So, I think with the current OF code this has to be 0, otherwise your IORESOURCE_IO's end up starting at 0xc000000 - but maybe there is some trickyness to work with in here? (Although none of this matters when Linux does resource assignment, the OF translation code is never enganged) But I agree, 0xc0000000 seems much better... To think about it from a different angle, what would you put in the 4th dword on x86? How do you describe the IO numberspace in DT on x86? Jason -- 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
