* Query: PCIe range entry at pcie@0 in dts files
@ 2011-03-22 4:18 Kushwaha Prabhakar-B32579
0 siblings, 0 replies; 3+ messages in thread
From: Kushwaha Prabhakar-B32579 @ 2011-03-22 4:18 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
Hi all,
I have query about usage of range field at pcie@0 under PCIe controller. P=
lease find snap shot from mpc8536_36.dts..
pci3: pcie@fffe0b000 {
compatible =3D "fsl,mpc8548-pcie";
device_type =3D "pci";
#interrupt-cells =3D <1>;
#size-cells =3D <2>;
#address-cells =3D <3>;
reg =3D <0xf 0xffe0b000 0 0x1000>;
bus-range =3D <0 0xff>;
ranges =3D <0x02000000 0 0xe0000000 0xc 0x20000000 0 0x20000000
0x01000000 0 0x00000000 0xf 0xffc30000 0 0x00010000>;
clock-frequency =3D <33333333>;
interrupt-parent =3D <&mpic>;
interrupts =3D <27 0x2>;
interrupt-map-mask =3D <0xf800 0 0 7>;
interrupt-map =3D <
/* IDSEL 0x0 */
0000 0 0 1 &mpic 8 1
0000 0 0 2 &mpic 9 1
0000 0 0 3 &mpic 10 1
0000 0 0 4 &mpic 11 1
>;
pcie@0 {
reg =3D <0 0 0 0 0>;
#size-cells =3D <2>;
#address-cells =3D <3>;
device_type =3D "pci";
ranges =3D <0x02000000 0 0xe0000000 --> child/port start address
0x02000000 0 0xe0000000 --> Parent bus address
0 0x20000000
0x01000000 0 0x00000000
0x01000000 0 0x00000000
0 0x00100000>;
};
};
Question:
A) is ranges filed of pcie@0 really required?
I just went through the code and found scan_OF_for_pci_dev() called from =
pci_busdev_to_OF_node() touches pcie@0 node. But, It does not even uses ran=
ge filed.=20
static struct device_node *scan_OF_for_pci_dev(struct device_node *parent,=
unsigned int devfn) {
---
---
for_each_child_of_node(parent, np) {
reg =3D of_get_property(np, "reg", &psize);=20
=20
---
---
if (!strcmp(np->name, "multifunc-device")) {=20
=20
}
I also checked "Power_ePAPR_APPROVED_v1.0.pdf". It never say range filed=
required for child bus.
B) if range field of pcie@0 required. why does child/port start address sam=
e as Parent bus address? Range property provides mapping of port address t=
o parent address space.
So the value should be 0x00000000. Means port's address starting from 0x000=
00000 to size 0x20000000 is mapped parent's 0xe0000000.
ranges =3D <0x02000000 0 0x00000000 --> Child/port's start address
0x02000000 0 0xe0000000 --> Parent bus address
0 0x20000000
0x01000000 0 0x00000000
0x01000000 0 0x00000000
0 0x00100000>;
--Prabhakar
^ permalink raw reply [flat|nested] 3+ messages in thread
* Query: PCIe range entry at pcie@0 in dts files
@ 2011-03-24 3:20 Kushwaha Prabhakar-B32579
2011-03-25 4:20 ` Kumar Gala
0 siblings, 1 reply; 3+ messages in thread
From: Kushwaha Prabhakar-B32579 @ 2011-03-24 3:20 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
Hi all,
I have query about usage of range field at pcie@0 under PCIe controller. P=
lease find snap shot from mpc8536_36.dts..
pci3: pcie@fffe0b000 {
compatible =3D "fsl,mpc8548-pcie";
device_type =3D "pci";
#interrupt-cells =3D <1>;
#size-cells =3D <2>;
#address-cells =3D <3>;
reg =3D <0xf 0xffe0b000 0 0x1000>;
bus-range =3D <0 0xff>;
ranges =3D <0x02000000 0 0xe0000000 0xc 0x20000000 0 0x20000000
0x01000000 0 0x00000000 0xf 0xffc30000 0 0x00010000>;
clock-frequency =3D <33333333>;
interrupt-parent =3D <&mpic>;
interrupts =3D <27 0x2>;
interrupt-map-mask =3D <0xf800 0 0 7>;
interrupt-map =3D <
/* IDSEL 0x0 */
0000 0 0 1 &mpic 8 1
0000 0 0 2 &mpic 9 1
0000 0 0 3 &mpic 10 1
0000 0 0 4 &mpic 11 1
>;
pcie@0 {
reg =3D <0 0 0 0 0>;
#size-cells =3D <2>;
#address-cells =3D <3>;
device_type =3D "pci";
ranges =3D <0x02000000 0 0xe0000000 --> child/port start address
0x02000000 0 0xe0000000 --> Parent bus address
0 0x20000000
0x01000000 0 0x00000000
0x01000000 0 0x00000000
0 0x00100000>;
};
};
Question:
A) is ranges filed of pcie@0 really required?
I just went through the code and found scan_OF_for_pci_dev() called from =
pci_busdev_to_OF_node() touches pcie@0 node. But, It does not even uses ran=
ge filed.=20
static struct device_node *scan_OF_for_pci_dev(struct device_node *parent,=
unsigned int devfn) {
---
---
for_each_child_of_node(parent, np) {
reg =3D of_get_property(np, "reg", &psize);=20
=20
---
---
if (!strcmp(np->name, "multifunc-device")) {=20
=20
}
I also checked "Power_ePAPR_APPROVED_v1.0.pdf". It never say range filed=
required for child bus.
B) if range field of pcie@0 required. why does child/port start address sam=
e as Parent bus address? Range property provides mapping of port address t=
o parent address space.
So the value should be 0x00000000. Means port's address starting from 0x000=
00000 to size 0x20000000 is mapped parent's 0xe0000000.
ranges =3D <0x02000000 0 0x00000000 --> Child/port's start address
0x02000000 0 0xe0000000 --> Parent bus address
0 0x20000000
0x01000000 0 0x00000000
0x01000000 0 0x00000000
0 0x00100000>;
--Prabhakar
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Query: PCIe range entry at pcie@0 in dts files
2011-03-24 3:20 Query: PCIe range entry at pcie@0 in dts files Kushwaha Prabhakar-B32579
@ 2011-03-25 4:20 ` Kumar Gala
0 siblings, 0 replies; 3+ messages in thread
From: Kumar Gala @ 2011-03-25 4:20 UTC (permalink / raw)
To: Kushwaha Prabhakar-B32579; +Cc: linuxppc-dev@lists.ozlabs.org
On Mar 23, 2011, at 10:20 PM, Kushwaha Prabhakar-B32579 wrote:
>=20
> Hi all,
>=20
> I have query about usage of range field at pcie@0 under PCIe =
controller. Please find snap shot from mpc8536_36.dts..
>=20
> pci3: pcie@fffe0b000 {
> compatible =3D "fsl,mpc8548-pcie";
> device_type =3D "pci";
> #interrupt-cells =3D <1>;
> #size-cells =3D <2>;
> #address-cells =3D <3>;
> reg =3D <0xf 0xffe0b000 0 0x1000>;
> bus-range =3D <0 0xff>;
> ranges =3D <0x02000000 0 0xe0000000 0xc 0x20000000 0 =
0x20000000
> 0x01000000 0 0x00000000 0xf 0xffc30000 0 =
0x00010000>;
> clock-frequency =3D <33333333>;
> interrupt-parent =3D <&mpic>;
> interrupts =3D <27 0x2>;
> interrupt-map-mask =3D <0xf800 0 0 7>;
> interrupt-map =3D <
> /* IDSEL 0x0 */
> 0000 0 0 1 &mpic 8 1
> 0000 0 0 2 &mpic 9 1
> 0000 0 0 3 &mpic 10 1
> 0000 0 0 4 &mpic 11 1
> >;
>=20
> pcie@0 {
> reg =3D <0 0 0 0 0>;
> #size-cells =3D <2>;
> #address-cells =3D <3>;
> device_type =3D "pci";
> ranges =3D <0x02000000 0 0xe0000000 --> =
child/port start address
> 0x02000000 0 0xe0000000 --> Parent bus =
address
> 0 0x20000000
>=20
> 0x01000000 0 0x00000000
> 0x01000000 0 0x00000000
> 0 0x00100000>;
> };
> };
>=20
> Question:
> A) is ranges filed of pcie@0 really required?
> I just went through the code and found scan_OF_for_pci_dev() =
called from pci_busdev_to_OF_node() touches pcie@0 node. But, It does =
not even uses range filed.=20
>=20
> static struct device_node *scan_OF_for_pci_dev(struct =
device_node *parent,unsigned int devfn) {
> ---
> ---
> for_each_child_of_node(parent, np) {
> reg =3D of_get_property(np, "reg", &psize);=20
>=20
> ---
> ---
> if (!strcmp(np->name, "multifunc-device")) {=20
> =20
> }
>=20
> I also checked "Power_ePAPR_APPROVED_v1.0.pdf". It never say range =
filed required for child bus.
Part of the reason for the range is to match PCIe semantics of RC having =
a transparent bridge.
>=20
> B) if range field of pcie@0 required. why does child/port start =
address same as Parent bus address? Range property provides mapping of =
port address to parent address space.
> So the value should be 0x00000000. Means port's address starting from =
0x00000000 to size 0x20000000 is mapped parent's 0xe0000000.
>=20
> ranges =3D <0x02000000 0 0x00000000 --> =
Child/port's start address
> 0x02000000 0 0xe0000000 --> Parent =
bus address
> 0 0x20000000
>=20
> 0x01000000 0 0x00000000
> 0x01000000 0 0x00000000
> 0 0x00100000>;
because the bridge is transparent.
- k=
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-03-25 4:21 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-24 3:20 Query: PCIe range entry at pcie@0 in dts files Kushwaha Prabhakar-B32579
2011-03-25 4:20 ` Kumar Gala
-- strict thread matches above, loose matches on Subject: below --
2011-03-22 4:18 Kushwaha Prabhakar-B32579
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).