On Mon, Jan 19, 2015 at 04:59:00PM +0000, Arnd Bergmann wrote: > On Monday 19 January 2015 10:40:39 Rob Herring wrote: > > > > I don't really like exposing ranges to host drivers. We've worked to > > not do that. So perhaps we need to rethink the API. I think we need to > > provide each range as a pair of resources which are the CPU address > > and PCI address. Perhaps an iterator is kind of pointless here. We do > > different things for each one. Are there cases with more than a single > > i/o space, non-prefetch memory and prefetch memory range? Perhaps we > > should just get the i/o and memory resources as separate calls. Just > > tossing out some ideas here. > > Nice idea, that could be similar to platform_get_resource(). I like the idea too, it should simplify the API implementation. > We probably also need the distinction between CPU address and (parent) > bus address here. In most drivers they are the same, but we actually > need to program the latter one into the PCI host bridge registers. Yes, CPU untranslated addresses are a pain in the back. I wrote the series at it is to avoid changing the API, but I agree that's a bit convoluted, which means we should refactor it. I think the API should always return a pair of CPU-PCI resources as Rob said, and provide an "on-demand" request for untranslated addresses, since their usage is not that common (at the moment). I need to think about that, we might even return a triplet, I hate doing that since I fear it might be a one-off need for PCIe designware. Lorenzo -- 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
