From: Jaehoon Chung <jh80.chung@samsung.com>
To: Jisheng Zhang <jszhang@marvell.com>,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
Arnd Bergmann <arnd@arndb.de>,
Bjorn Helgaas <bhelgaas@google.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>, CPGS <cpgs@samsung.com>
Subject: Re: [query] how to use "ranges" in device tree
Date: Fri, 17 Apr 2015 07:59:45 +0900 [thread overview]
Message-ID: <55303EE1.1050108@samsung.com> (raw)
In-Reply-To: <20150416215938.347caa68@xhacker>
Hi,
Well, I'm not sure..
But in my understanding..configuration range might be support both "ranges" and "config" of reg.
On 04/16/2015 10:59 PM, Jisheng Zhang wrote:
> Hi all,
>
> I didn't fully understand the "ranges" usage, here is one situation which I dunno
> how to handle.
>
> In arch/arm/boot/dts/berlin2q.dtsi, we describe the /soc ranges as
>
> ranges = <0 0xf7000000 0x1000000>;
>
> That's fine. Now there's a pci device based on pcie-designware.c which prefer
> put "config" space in reg. But the config space starts at 0xe0000000, due to
> the /soc ranges, the "config" space following pcie node is not correct in fact.
>
> soc {
> ranges = <0 0xf7000000 0x1000000>;
> ...
> pcie: pcie@e40000 {
> compatible = "...";
> reg = <0xe40000 0x10000>, <0xe0000000 0x8000000>;
> reg-names = "dbi", "pad", "config";
> ...
> };
> ...
> };
According to yours,
reg = <0xe40000 0x1000 /* dbi */
0xe000000 0x800000 /* pad */
0xf7000000 0x1000000>; /* config ? */
If there is not "config" into reg-names, it should be tried to find it into "ranges".
If my understanding is wrong, let me know, plz.
In my case,
reg = <0x156b0000 0x1000
0x15680000 0x1000
0x0c000000 0x1000>;
reg-names = "elbi", "phy", "config";
ranges = < ..... /* downstream I/O */
...... /* non-prefetchable memory */
Best Regards,
Jaehoon Chung
>
> How to define the "config" space in this situation? Did we need to change
> the /soc ranges as the following?
>
> soc {
> ranges;
> }
>
> Thanks in advance,
> Jisheng
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
WARNING: multiple messages have this Message-ID (diff)
From: jh80.chung@samsung.com (Jaehoon Chung)
To: linux-arm-kernel@lists.infradead.org
Subject: [query] how to use "ranges" in device tree
Date: Fri, 17 Apr 2015 07:59:45 +0900 [thread overview]
Message-ID: <55303EE1.1050108@samsung.com> (raw)
In-Reply-To: <20150416215938.347caa68@xhacker>
Hi,
Well, I'm not sure..
But in my understanding..configuration range might be support both "ranges" and "config" of reg.
On 04/16/2015 10:59 PM, Jisheng Zhang wrote:
> Hi all,
>
> I didn't fully understand the "ranges" usage, here is one situation which I dunno
> how to handle.
>
> In arch/arm/boot/dts/berlin2q.dtsi, we describe the /soc ranges as
>
> ranges = <0 0xf7000000 0x1000000>;
>
> That's fine. Now there's a pci device based on pcie-designware.c which prefer
> put "config" space in reg. But the config space starts at 0xe0000000, due to
> the /soc ranges, the "config" space following pcie node is not correct in fact.
>
> soc {
> ranges = <0 0xf7000000 0x1000000>;
> ...
> pcie: pcie at e40000 {
> compatible = "...";
> reg = <0xe40000 0x10000>, <0xe0000000 0x8000000>;
> reg-names = "dbi", "pad", "config";
> ...
> };
> ...
> };
According to yours,
reg = <0xe40000 0x1000 /* dbi */
0xe000000 0x800000 /* pad */
0xf7000000 0x1000000>; /* config ? */
If there is not "config" into reg-names, it should be tried to find it into "ranges".
If my understanding is wrong, let me know, plz.
In my case,
reg = <0x156b0000 0x1000
0x15680000 0x1000
0x0c000000 0x1000>;
reg-names = "elbi", "phy", "config";
ranges = < ..... /* downstream I/O */
...... /* non-prefetchable memory */
Best Regards,
Jaehoon Chung
>
> How to define the "config" space in this situation? Did we need to change
> the /soc ranges as the following?
>
> soc {
> ranges;
> }
>
> Thanks in advance,
> Jisheng
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
next prev parent reply other threads:[~2015-04-16 22:59 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-16 13:59 [query] how to use "ranges" in device tree Jisheng Zhang
2015-04-16 13:59 ` Jisheng Zhang
2015-04-16 22:59 ` Jaehoon Chung [this message]
2015-04-16 22:59 ` Jaehoon Chung
2015-04-17 2:24 ` Jisheng Zhang
2015-04-17 2:24 ` Jisheng Zhang
2015-04-17 3:50 ` Jisheng Zhang
2015-04-17 3:50 ` Jisheng Zhang
2015-04-17 8:32 ` Arnd Bergmann
2015-04-17 8:32 ` Arnd Bergmann
2015-04-17 8:45 ` Jisheng Zhang
2015-04-17 8:45 ` Jisheng Zhang
2015-04-17 9:38 ` Arnd Bergmann
2015-04-17 9:38 ` Arnd Bergmann
2015-04-17 8:38 ` Sebastian Hesselbarth
2015-04-17 8:38 ` Sebastian Hesselbarth
2015-04-17 8:51 ` Jisheng Zhang
2015-04-17 8:51 ` Jisheng Zhang
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=55303EE1.1050108@samsung.com \
--to=jh80.chung@samsung.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=cpgs@samsung.com \
--cc=jszhang@marvell.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=sebastian.hesselbarth@gmail.com \
/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.