On Thu, Mar 14, 2013 at 10:09:26PM +0100, Thierry Reding wrote:

> > ranges = <0x82000000 0 0x80000000  0x80000000  0 0x00001000   /* port 0 
> > registers */
> >       0x82000000 0 0x80001000  0x80001000  0 0x00001000   /* port 1 
> > registers */
> >       0x81000000 0          0  0x82000000  0 0x00010000   /* downstream I/O 
> > */
> >       0x82000000 0 0xa0000000  0xa0000000  0 0x10000000   /* 
> > non-prefetchable memory */
> >       0xc2000000 0 0xb0000000  0xb0000000  0 0x10000000>; /* prefetchable 
> > memory */
> > 
> > Which says 'access to CPU address 0xa0000000 produces a PCI-E memory TLP 
> > with
> > address 0xa0000000' - this is the 'normal' case, I assume that is what
> > happens on tegra?
> > 
> > It also says 'access to CPU address 0x82000000 produces a PCI-E IO TLP
> > with address 0' - this translation is something Linux typically
> > expects..
> 
> Both of the above paragraphs are true. However accesses to the windows
> at 0x80000000 and 0x80001000 don't generate memory TLPs but type 0
> configuration space TLPs.

By my understanding access to 0x80000000/0x80001000 doesn't generate
any externally visible TLPs?

IHMO modeling this register space as a controller-internal MMIO region
associated with the bridge is reasonable... After all, you are
iomapping it and accessing it with readl/writel - those are MMIO
functions..

> So my first instinct was to make the first cell of the first two entries
> 0, but that doesn't work, since the OF core expects to find either
> memory or I/O spaces. 

Right, there is no specified way to translate config ss through
ranges.

Regards,
Jason
_______________________________________________
devicetree-discuss mailing list
[email protected]
https://lists.ozlabs.org/listinfo/devicetree-discuss

Reply via email to