All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jisheng Zhang <jszhang@marvell.com>
To: Jaehoon Chung <jh80.chung@samsung.com>
Cc: 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>,
	"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 10:24:13 +0800	[thread overview]
Message-ID: <20150417102413.705b1ca0@xhacker> (raw)
In-Reply-To: <55303EE1.1050108@samsung.com>

Hi Jaehoon,

On Thu, 16 Apr 2015 15:59:45 -0700
Jaehoon Chung <jh80.chung@samsung.com> wrote:

> 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 ? */

oops, there's no pad at all, dbi starts at 0xf7e40000, config space starts at 0xe0000000

so my pcie in my understanding is

pcie: pcie@e40000 {
	compatible = "...";
	reg = <0xe40000 0x10000>, <0xe0000000 0x8000000>;
	reg-names = "dbi", "config";
};

But the "/soc" ranges is defined as "<0 0xf7000000 0x1000000>;", so the config space
in the above dts is not correct.

My solution is change the "/soc" ranges as following:

soc {
	ranges;
	...
};

Is there any elegant solutions for this situation?

> 
> If there is not "config" into reg-names, it should be tried to find it into "ranges".

The pcie-designware driver prefers users define config space in "reg"

Thanks for your help,
Jisheng

> 
> 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: jszhang@marvell.com (Jisheng Zhang)
To: linux-arm-kernel@lists.infradead.org
Subject: [query] how to use "ranges" in device tree
Date: Fri, 17 Apr 2015 10:24:13 +0800	[thread overview]
Message-ID: <20150417102413.705b1ca0@xhacker> (raw)
In-Reply-To: <55303EE1.1050108@samsung.com>

Hi Jaehoon,

On Thu, 16 Apr 2015 15:59:45 -0700
Jaehoon Chung <jh80.chung@samsung.com> wrote:

> 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 ? */

oops, there's no pad at all, dbi starts at 0xf7e40000, config space starts at 0xe0000000

so my pcie in my understanding is

pcie: pcie at e40000 {
	compatible = "...";
	reg = <0xe40000 0x10000>, <0xe0000000 0x8000000>;
	reg-names = "dbi", "config";
};

But the "/soc" ranges is defined as "<0 0xf7000000 0x1000000>;", so the config space
in the above dts is not correct.

My solution is change the "/soc" ranges as following:

soc {
	ranges;
	...
};

Is there any elegant solutions for this situation?

> 
> If there is not "config" into reg-names, it should be tried to find it into "ranges".

The pcie-designware driver prefers users define config space in "reg"

Thanks for your help,
Jisheng

> 
> 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
> > 
> 

  reply	other threads:[~2015-04-17  2:27 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
2015-04-16 22:59   ` Jaehoon Chung
2015-04-17  2:24   ` Jisheng Zhang [this message]
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=20150417102413.705b1ca0@xhacker \
    --to=jszhang@marvell.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=cpgs@samsung.com \
    --cc=jh80.chung@samsung.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.