From: gerlando.falauto@keymile.com (Gerlando Falauto)
To: linux-arm-kernel@lists.infradead.org
Subject: address translation for PCIe-to-localbus bridge
Date: Tue, 12 Nov 2013 09:11:33 +0100 [thread overview]
Message-ID: <5281E2B5.3080701@keymile.com> (raw)
In-Reply-To: <20131112080512.3992b2e4@skate>
On 11/12/2013 08:05 AM, Thomas Petazzoni wrote:
> Dear Grant Likely,
>
> On Mon, 11 Nov 2013 15:50:50 +0000, Grant Likely wrote:
>
>>> So the mbus would register an address xlate for its node that is
>>> called instead of ranges parsing. For the example in my last message
>>> the FPGA driver would register an xlate that made addresses relative
>>> to its own BAR0 address.
>>
>> There are already bus-specific transations available. Take a look at
>> struct of_bus in drivers/of/address.c
>
> Hum, right, but unless I'm wrong the of_busses[] array of struct of_bus
> is fixed in drivers/of/address.c, and as it is, there is no way for a
> specific bus driver to provide its own struct of_bus.
That was exactly my understanding as well, and that's where I was
expecting some trickery to happen.
> So that would need to be extended, right?
The other approach I was foreseeing was to implement a way of
dynamically updating the DT when the PCI subsystem enumerates the
devices and assigns memory areas (namely, I would expect the ranges
property to reflect that). But this would imply a standard way of
defining the ranges property (I would expect something like <bar#
start_addr length>, with an arguable number of cells). And I could
not find any such definition in the PCI bus binding document, so I'm
probably completely off-track here. Aren't I?
After all, we should expect a driver to behave (and expect) the same of
the DT, regardless of whether enumeration was performed by firmware or
by the OS itself. Or am I wrong on this too?
Thanks guys!
Gerlando
WARNING: multiple messages have this Message-ID (diff)
From: Gerlando Falauto <gerlando.falauto-SkAbAL50j+5BDgjK7y7TUQ@public.gmane.org>
To: Thomas Petazzoni
<thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Cc: Grant Likely
<grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>,
Jason Gunthorpe
<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>,
Lior Amsalem <alior-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Thierry Reding
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Ezequiel Garcia
<ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
Gregory Cl??ment
<gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: address translation for PCIe-to-localbus bridge
Date: Tue, 12 Nov 2013 09:11:33 +0100 [thread overview]
Message-ID: <5281E2B5.3080701@keymile.com> (raw)
In-Reply-To: <20131112080512.3992b2e4@skate>
On 11/12/2013 08:05 AM, Thomas Petazzoni wrote:
> Dear Grant Likely,
>
> On Mon, 11 Nov 2013 15:50:50 +0000, Grant Likely wrote:
>
>>> So the mbus would register an address xlate for its node that is
>>> called instead of ranges parsing. For the example in my last message
>>> the FPGA driver would register an xlate that made addresses relative
>>> to its own BAR0 address.
>>
>> There are already bus-specific transations available. Take a look at
>> struct of_bus in drivers/of/address.c
>
> Hum, right, but unless I'm wrong the of_busses[] array of struct of_bus
> is fixed in drivers/of/address.c, and as it is, there is no way for a
> specific bus driver to provide its own struct of_bus.
That was exactly my understanding as well, and that's where I was
expecting some trickery to happen.
> So that would need to be extended, right?
The other approach I was foreseeing was to implement a way of
dynamically updating the DT when the PCI subsystem enumerates the
devices and assigns memory areas (namely, I would expect the ranges
property to reflect that). But this would imply a standard way of
defining the ranges property (I would expect something like <bar#
start_addr length>, with an arguable number of cells). And I could
not find any such definition in the PCI bus binding document, so I'm
probably completely off-track here. Aren't I?
After all, we should expect a driver to behave (and expect) the same of
the DT, regardless of whether enumeration was performed by firmware or
by the OS itself. Or am I wrong on this too?
Thanks guys!
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-12 8:11 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
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 [this message]
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=5281E2B5.3080701@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.