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:26:02 +0100 [thread overview]
Message-ID: <5281E61A.2070809@keymile.com> (raw)
In-Reply-To: <20131112091608.161f1347@skate>
Hi,
On 11/12/2013 09:16 AM, Thomas Petazzoni wrote:
> Dear Gerlando Falauto,
>
> On Tue, 12 Nov 2013 09:11:33 +0100, Gerlando Falauto wrote:
>
>>> 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?
>
> Well, in the context of the mvebu platforms (including Kirkwood), the
> problem is not so much the ranges in the pcie-controller node, but the
> ranges in the main soc { ... } node which encloses the description of
> the MBus. It is those ranges that need to be updated when a new window
> is created, or a window is removed. So the problem is not PCI related,
> but MBus related in this case, no?
I was actually referring to ranges within the PCI *device* (~leaf node).
So not thinking about mvebu, but rather about general PCI devices.
I see drivers/of/address.c implements some:
extern const __be32 *of_get_pci_address(struct device_node *dev, int bar_no,
u64 *size, unsigned int *flags);
extern int of_pci_address_to_resource(struct device_node *dev, int bar,
struct resource *r);
Which are not hooked to any ranges (of_bus) mechanisms nor any DT-aware
PCI device driver and that's where I got completely lost.
But I'm probably looking at it from a wrong perspective.
Thanks,
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:26:02 +0100 [thread overview]
Message-ID: <5281E61A.2070809@keymile.com> (raw)
In-Reply-To: <20131112091608.161f1347@skate>
Hi,
On 11/12/2013 09:16 AM, Thomas Petazzoni wrote:
> Dear Gerlando Falauto,
>
> On Tue, 12 Nov 2013 09:11:33 +0100, Gerlando Falauto wrote:
>
>>> 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?
>
> Well, in the context of the mvebu platforms (including Kirkwood), the
> problem is not so much the ranges in the pcie-controller node, but the
> ranges in the main soc { ... } node which encloses the description of
> the MBus. It is those ranges that need to be updated when a new window
> is created, or a window is removed. So the problem is not PCI related,
> but MBus related in this case, no?
I was actually referring to ranges within the PCI *device* (~leaf node).
So not thinking about mvebu, but rather about general PCI devices.
I see drivers/of/address.c implements some:
extern const __be32 *of_get_pci_address(struct device_node *dev, int bar_no,
u64 *size, unsigned int *flags);
extern int of_pci_address_to_resource(struct device_node *dev, int bar,
struct resource *r);
Which are not hooked to any ranges (of_bus) mechanisms nor any DT-aware
PCI device driver and that's where I got completely lost.
But I'm probably looking at it from a wrong perspective.
Thanks,
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:26 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
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 [this message]
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=5281E61A.2070809@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.