Using the generic host PCIe driver

Mason slash.tmp at free.fr
Sat Mar 4 06:33:47 PST 2017


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.



More information about the linux-arm-kernel mailing list