From: gerlando.falauto@keymile.com (Gerlando Falauto)
To: linux-arm-kernel@lists.infradead.org
Subject: address translation for PCIe-to-localbus bridge
Date: Wed, 06 Nov 2013 13:50:52 +0100 [thread overview]
Message-ID: <527A3B2C.6070209@keymile.com> (raw)
In-Reply-To: <20131106122317.GA8806@ulmo.nvidia.com>
Hi Thierry,
thanks again for your patience!
On 11/06/2013 01:23 PM, Thierry Reding wrote:
> On Wed, Nov 06, 2013 at 11:27:15AM +0100, Gerlando Falauto wrote:
>> Hi everyone,
>>
>> I am currently trying to describe an external device within a device
>> tree in a Kirkwood design.
>> Such device is accessed through a local (parallel) bus. Since
>> Kirkwood does not provide such an interface, we added a custom FPGA
>> (PCIe device) which implements a PCIe-to-localbus bridge.
>> So essentially BAR0 provides the configuration space for such a
>> bridge, and BAR1 provides a remapped area where accesses to the
>> localbus can be performed. BAR2 and BAR3 provide other functions.
>>
>> So with the appropriate reg encoding of the PCI device, the PCI
>> driver for the FPGA will automatically get an of_node.
>>
>> My question is: is there any way I can describe this external device
>> (I believe as a child node of the PCI device), so that a call to
>> of_address_to_resource() (or equivalent) from its driver will
>> automatically translate a localbus address (e.g. 0x0000abcd) to
>> whatever address was assigned to BAR1 (in my case 0xe0000000 ->
>> 0xe000abcd)?
>
> Perhaps I don't understand properly, but what good is the local bus
> address to any driver? I mean you'll have to have a PCI driver to bind
> to the PCI device, right?
Correct, and that's the PCI driver for the FPGA, which is (among other
things) a PCI-to-localbus bridge.
> And that PCI driver will only need to obtain
> the register addresses from BAR1,
Correct.
> then access that region.
That's not 100% right. The PCI driver will only _provide_ the region for
BAR1 (as it is a bridge), not _access_ it.
> Why would you need to have it translated via DT?
Because it would be a *separate* driver, the one handling the /external/
"slave" device, to use that region.
In principle, if I wanted to reuse that same external device on a
completely different architecture (which *does* natively provide a
localbus) I should be able to move that same device node together with
its driver. Provided the node is under the right bus, and translation is
configured properly in the device tree, it should then work out of the
box. Or am I completely mistaken?
What I did now (and it works) was to put the device node for the
external device right under the main bus,
/ {
...
ocp at f1000000 {
slave at 0,0 {
...
compatible = "keymile,slave";
reg = <0xe0000000 0x200>;
};
};
};
where "0xe0000000" is hardcoded, being the result of the dynamic assignment:
pci 0000:01:00.0: BAR 1: assigned [mem 0xe0000000-0xe7ffffff]
I'd like to avoid that, saying "slave at 0,0 is accessible through the
memory area 0x0-0x200 within BAR1 of device 0 on bus 1".
Thanks again,
Gerlando
WARNING: multiple messages have this Message-ID (diff)
From: Gerlando Falauto <gerlando.falauto-SkAbAL50j+5BDgjK7y7TUQ@public.gmane.org>
To: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Thomas Petazzoni
<thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
Jason Gunthorpe
<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
Subject: Re: address translation for PCIe-to-localbus bridge
Date: Wed, 06 Nov 2013 13:50:52 +0100 [thread overview]
Message-ID: <527A3B2C.6070209@keymile.com> (raw)
In-Reply-To: <20131106122317.GA8806-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org>
Hi Thierry,
thanks again for your patience!
On 11/06/2013 01:23 PM, Thierry Reding wrote:
> On Wed, Nov 06, 2013 at 11:27:15AM +0100, Gerlando Falauto wrote:
>> Hi everyone,
>>
>> I am currently trying to describe an external device within a device
>> tree in a Kirkwood design.
>> Such device is accessed through a local (parallel) bus. Since
>> Kirkwood does not provide such an interface, we added a custom FPGA
>> (PCIe device) which implements a PCIe-to-localbus bridge.
>> So essentially BAR0 provides the configuration space for such a
>> bridge, and BAR1 provides a remapped area where accesses to the
>> localbus can be performed. BAR2 and BAR3 provide other functions.
>>
>> So with the appropriate reg encoding of the PCI device, the PCI
>> driver for the FPGA will automatically get an of_node.
>>
>> My question is: is there any way I can describe this external device
>> (I believe as a child node of the PCI device), so that a call to
>> of_address_to_resource() (or equivalent) from its driver will
>> automatically translate a localbus address (e.g. 0x0000abcd) to
>> whatever address was assigned to BAR1 (in my case 0xe0000000 ->
>> 0xe000abcd)?
>
> Perhaps I don't understand properly, but what good is the local bus
> address to any driver? I mean you'll have to have a PCI driver to bind
> to the PCI device, right?
Correct, and that's the PCI driver for the FPGA, which is (among other
things) a PCI-to-localbus bridge.
> And that PCI driver will only need to obtain
> the register addresses from BAR1,
Correct.
> then access that region.
That's not 100% right. The PCI driver will only _provide_ the region for
BAR1 (as it is a bridge), not _access_ it.
> Why would you need to have it translated via DT?
Because it would be a *separate* driver, the one handling the /external/
"slave" device, to use that region.
In principle, if I wanted to reuse that same external device on a
completely different architecture (which *does* natively provide a
localbus) I should be able to move that same device node together with
its driver. Provided the node is under the right bus, and translation is
configured properly in the device tree, it should then work out of the
box. Or am I completely mistaken?
What I did now (and it works) was to put the device node for the
external device right under the main bus,
/ {
...
ocp@f1000000 {
slave@0,0 {
...
compatible = "keymile,slave";
reg = <0xe0000000 0x200>;
};
};
};
where "0xe0000000" is hardcoded, being the result of the dynamic assignment:
pci 0000:01:00.0: BAR 1: assigned [mem 0xe0000000-0xe7ffffff]
I'd like to avoid that, saying "slave@0,0 is accessible through the
memory area 0x0-0x200 within BAR1 of device 0 on bus 1".
Thanks again,
Gerlando
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2013-11-06 12:50 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-06 10:27 address translation for PCIe-to-localbus bridge Gerlando Falauto
2013-11-06 10:27 ` Gerlando Falauto
2013-11-06 12:23 ` Thierry Reding
2013-11-06 12:23 ` Thierry Reding
2013-11-06 12:50 ` Gerlando Falauto [this message]
2013-11-06 12:50 ` Gerlando Falauto
2013-11-06 17:36 ` Jason Gunthorpe
2013-11-06 17:36 ` Jason Gunthorpe
2013-11-06 18:03 ` Thomas Petazzoni
2013-11-06 18:03 ` Thomas Petazzoni
2013-11-06 18:24 ` Jason Gunthorpe
2013-11-06 18:24 ` Jason Gunthorpe
2013-11-06 19:00 ` Thomas Petazzoni
2013-11-06 19:00 ` Thomas Petazzoni
2013-11-11 15:50 ` Grant Likely
2013-11-11 15:50 ` Grant Likely
2013-11-12 7:05 ` Thomas Petazzoni
2013-11-12 7:05 ` Thomas Petazzoni
2013-11-12 8:11 ` Gerlando Falauto
2013-11-12 8:11 ` Gerlando Falauto
2013-11-12 8:16 ` Thomas Petazzoni
2013-11-12 8:16 ` Thomas Petazzoni
2013-11-12 8:26 ` Gerlando Falauto
2013-11-12 8:26 ` Gerlando Falauto
2013-11-13 6:26 ` Grant Likely
2013-11-13 6:26 ` Grant Likely
2013-11-12 8:51 ` Grant Likely
2013-11-12 8:51 ` Grant Likely
2013-11-06 18:33 ` Pantelis Antoniou
2013-11-06 18:33 ` Pantelis Antoniou
2013-11-06 18:56 ` Jason Gunthorpe
2013-11-06 18:56 ` Jason Gunthorpe
2013-11-06 19:16 ` Pantelis Antoniou
2013-11-06 19:16 ` Pantelis Antoniou
2013-11-06 19:50 ` Jason Gunthorpe
2013-11-06 19:50 ` Jason Gunthorpe
2013-11-06 19:38 ` Gerlando Falauto
2013-11-06 19:38 ` Gerlando Falauto
2013-11-06 20:07 ` Jason Gunthorpe
2013-11-06 20:07 ` Jason Gunthorpe
2013-11-07 9:07 ` Gerlando Falauto
2013-11-07 9:07 ` Gerlando Falauto
2013-11-07 17:01 ` Jason Gunthorpe
2013-11-07 17:01 ` Jason Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=527A3B2C.6070209@keymile.com \
--to=gerlando.falauto@keymile.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.