RFC drivers: port PCIe designware to new DT parsing API
Get series with b4
b4 am 20150120103925.GE5398@red-moonVersions newest first
- v1 RFC Latest0 of 3 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 3 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC PATCH 0/3] drivers: port PCIe designware to new DT parsing API
Quoted 11 lines · Arnd Bergmann
Quoted 9 lines · 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.
Quoted 1 line
Nice idea, that could be similar to
platform_get_resource().
I like the idea too, it should simplify the API implementation.
Quoted 3 lines
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