On 04/03/2017 14:49, Ard Biesheuvel wrote: > On 4 March 2017 at 13:07, Mason wrote: > >> My current understanding is that I must find a large area in the memory >> map where there is NOTHING (no RAM, no registers). Then I can specify >> this area in the "ranges" prop of my DT node, to be used as a >> non-prefetchable memory address range. > > 'Finding' a memory area suggests that you could pick a range at random > and put that in the DT. This is *not* the case. > > The PCIe controller hardware needs to know that it needs to decode > that range, i.e., it needs to forward memory accesses that hit this > window. You need to figure out how this is configured on the h/w that > you are using. My confusion level is at 11 :-) I'll sleep on it, then take a fresh look at the PCIe controller register map. I know there is a way to configure mappings in the RC BAR0, e.g. the MSI doorbell is in MMIO space, and devices need to write there to request an interrupt. But I thought all the range stuff was configured at run-time by the PCI framework itself, using standard registers. I still need to investigate "I/O and prefetchable mem behind bridge", as pointed out by Bjorn. >>> The DT node that describes the host bridge should simply describe >>> which MMIO regions are used by the device. This is no different from >>> any other MMO peripheral. >> >> In my limited experience, the DT node for PCI is, by far, the most >> complex node I've had to write. > > Yes, but that is not the point. My point is that the information you > put in the DT should reflect *reality* in one way or the other. Every > value you put there should match the current configuration of the h/w > IP block. The HW designers are never sure how SW will use the block, so they often make everything under the sun SW-configurable. For example, the RC BAR0 is actually split into 8 "regions" which can map to arbitrary areas in the physical address space. So I don't think there is an actual "current configuration of the h/w IP block". Regards.
