On 11/06/2013 09:07 PM, Jason Gunthorpe wrote:
On Wed, Nov 06, 2013 at 08:38:33PM +0100, Gerlando Falauto wrote:
[...]
Each translation represents something concrete:
0x8 -> 0x82000000 0x00000000 0x00000008
This is the BAR 0 decoder of the PCI device
0x82000000 0x00000000 0x00000008 -> 0x82000000 0x1 8
This is the PCI bridge's memory window decoder
0x82000000 0x1 8 -> MBUS_ID(0x04, 0xe8) 8
This is the MBUS window associated with the PEX
MBUS_ID(0x04, 0xe8) 8 -> 0xe0000008
This is the physical CPU BUS address associated with the MBUS
window
Uhm, OK, sounds good. Except you must know the whole mapping in advance.
Fair enough.
Would that work without the whole mbus driver (I guess Ezequiel's)?
I'm dealing with 3.10.
Where does the 0x82000000 come from?
What about the 0x1 (second cell)?
Looks like it ends up at the beginning of the memory region for
PCIe, and that's no wonder since you only have a single device with
a single BAR... right?
The mapping of the FPGA bus into a BAR is done by a single ranges:
fpga@0 {
reg = <0x8 0 0 0 0>;
ranges = <0x00000000 0x82000000 0x00000000 0x00000000 0x8000000>;
gpio3: fpga_gpio@8 {
That ranges says 'put address 0 of the child bus at 0x82000000
0x00000000 0x00000000', which is the BAR 0 address, relative to the
bridge's memory window.
So suppose you also had a bigger BAR1 which would then shift your
GPIO block at @0xe8000000.
Until we get that figured out, where would you hardcode such offset then?
Since your BAR layout of your device is fixed you can adjust the
single ranges:
By "single" you mean that it's just *one* range, right?
ranges = <0x00000000 0x82000000 0x00000000 0x08000000 0x8000000>;
It is possible as well to do this in code in the FPGA driver.
Uhm... why? And how? You mean dynamically upgrading the ranges window?
How would you also deal with a second (let's say identical) device on BAR1?
ranges = <0x00000000 0x82000000 0x00000000 0x08000000 0x8000000 // BAR 0
0x10000000 0x82000000 0x00000000 0x08000000 0x8000000> // BAR 1
Aren't in this case the two regions aliased? Shouldn't the fourth column
on either row be 0x00000000? Like:
ranges = <0x00000000 0x82000000 0x00000000 0x00000000 0x8000000
// BAR 0
0x10000000 0x82000000 0x00000000 0x08000000 0x8000000>
// BAR 1
Use reg <0x10000abc xxx> to refer to the 2nd BAR. There are other ways
to organize things.
Now I completely lost you. According to the above description (BTW, I
like the double space to separate groups -- it makes this whole mess a
little messy!) the child address should have a single cell.
Why use two then?
I guess I could live with hardcoded values in the DT, as long as
they're easy to spot and there's only one per BAR/device.
Then it's easy to do a comparison with whatever gets assigned during
probing.
I'd see it as an interm step, pending on some kind of core support for
this sort of stuff.
Right.
Sorry for being pedantic, but I'd really like to get this straight once
and for all...
Thanks again,
Gerlando
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
