On Tue, Jun 18, 2013 at 08:22:08PM +0200, Arnd Bergmann wrote: > > > > Arnd, we've discussed this at length with you while getting the PCIe > > > > driver merged, and we've explained this to you numerous times. Could > > > > you please understand that any of your proposal that suggests writing > > > > down static windows for PCIe devices will not work? > > > > > > Where did I suggest static windows for PCIe devices? > > > > Where does your new proposal buys us anything useful compared to the > > existing PCIe DT binding that has been discussed at length with you? > > I'm pretty sure I explained the idea above originally and was ignored. > Jason Gunthorpe might remember better, but I think he liked it when I > originally proposed doing it this way.
I remember it took a bit to understand your proposal, but I thought it could work, but I admit I forget all the little details now :( Ah, if I can just rephrase simply - the notion was to move the determination of the aperture to use dynmic allocation and then restructure the ranges around the mbus target, since they no longer need to encode the aperture. My concern: dynamically sizing the aperture is hard. There are three apertures that need to be picked, and the PCI core code has no support for dynamic apertures. Getting the aperture from the DT is a functional compromise. > * Since the host physical address for the PCIe memory space window > is set up dynamically anyway, there is no reason to hardcode it in > DT. We want it to be as large as possible, and this way the mbus > driver can just pick the largest free area itself after setting up > all the other mappings from the ranges property. This seems to get really complicated if the mbus driver is ever required to support dynamic mappings.. If PCI-E claims all memory and then you modprobe something it could fail. IMHO, I go back to my original thoughts. There is no real need for any of this to be dynamic, we can use the values in the DT, presumably set by the bootloader and things will work well. The added complexity and failure modes for dynamic is simply not worth it.. Jason _______________________________________________ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
