All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.