* RE: [PATCH 1/6] powerpc/fsl-booke: Add initial silicon device tree files for B4860QDS
From: Leekha Shaveta-B20052 @ 2013-03-18 7:41 UTC (permalink / raw)
To: Timur Tabi, Kumar Gala
Cc: Mehresh Ramneek-B31383, Zhao Chenhui-B35336, Lian Minghuan-B31939,
Tang Yuantian-B29983, Fleming Andy-AFLEMING, Sethi Varun-B16395,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAOZdJXV5UgT71j5XJH8K6DnfE-SUVL2jE7yNZUhE+gstb_33tQ@mail.gmail.com>
-----Original Message-----
From: Timur Tabi [mailto:timur@tabi.org]=20
Sent: Friday, March 15, 2013 6:38 PM
To: Leekha Shaveta-B20052
Cc: linuxppc-dev@lists.ozlabs.org; Zhao Chenhui-B35336; Lian Minghuan-B3193=
9; Tang Yuantian-B29983; Fleming Andy-AFLEMING; Mehresh Ramneek-B31383; Set=
hi Varun-B16395
Subject: Re: [PATCH 1/6] powerpc/fsl-booke: Add initial silicon device tree=
files for B4860QDS
On Fri, Mar 15, 2013 at 2:55 AM, Shaveta Leekha <shaveta@freescale.com> wro=
te:
> + iommu@20000 {
> + compatible =3D "fsl,pamu-v1.0", "fsl,pamu";
> + reg =3D <0x20000 0x4000>;
> + interrupts =3D <
> + 24 2 0 0
> + 16 2 1 1>;
> + };
You need to add the PAMU topology.
[SL] Thanks for reviewing the patches.
These patches are on similar lines as T4 initial support
In due course of time, we plan to add pamu topology and pamu related suppor=
t in various devices both for T4 and B4.
Kumar can you please suggest?
Regards,
Shaveta
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* KVM breaking the ppc64_defconfig UP build
From: Michael Ellerman @ 2013-03-18 7:01 UTC (permalink / raw)
To: linuxppc-dev, paulus, benh
Hi guys,
The ppc64_defconfig build with CONFIG_SMP=n (ie. UP) is broken by KVM:
arch/powerpc/kvm/book3s_hv.c:1855:2: error: implicit declaration of function 'inhibit_secondary_onlining'
arch/powerpc/kvm/book3s_hv.c:1862:2: error: implicit declaration of function 'uninhibit_secondary_onlining'
http://kisskb.ellerman.id.au/kisskb/buildresult/8400164/
The fix for that is fairly easy.
Once that's fixed there is breakage in arch/powerpc/kvm/book3s_hv_interrupts.S
caused by us calling smp_send_reschedule() to cause a self-IPI on 970.
It's not clear to me how we fix that one, any ideas?
cheers
^ permalink raw reply
* RE: [PATCH 4/6] powerpc/fsl-booke: Add initial B4420QDS board device tree
From: Leekha Shaveta-B20052 @ 2013-03-18 7:00 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <78325CC6-01B7-4A81-A4E9-40188B7994DE@kernel.crashing.org>
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
Sent: Saturday, March 16, 2013 2:02 AM
To: Leekha Shaveta-B20052
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 4/6] powerpc/fsl-booke: Add initial B4420QDS board devi=
ce tree
On Mar 15, 2013, at 2:55 AM, Shaveta Leekha wrote:
> Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
> ---
> arch/powerpc/boot/dts/b4420qds.dts | 168=20
> ++++++++++++++++++++++++++++++++++++
> 1 files changed, 168 insertions(+), 0 deletions(-) create mode 100644=20
> arch/powerpc/boot/dts/b4420qds.dts
If B4420 and B4860 qds are same board, refactor this into a b4qds.dtsi file=
for common board features like NOR, NAND, SPI, SDHC, etc.
[SL] will work on refactoring and send new set of patches soon. Thanks for =
the feedback.
Regards,
Shaveta
=20
- k
^ permalink raw reply
* RE: [PATCH 1/6] powerpc/fsl-booke: Add initial silicon device tree files for B4860QDS
From: Leekha Shaveta-B20052 @ 2013-03-18 6:59 UTC (permalink / raw)
To: Kumar Gala
Cc: Li Yang-R58472, Zhao Chenhui-B35336, Mehresh Ramneek-B31383,
Lian Minghuan-B31939, Tang Yuantian-B29983, Fleming Andy-AFLEMING,
Sethi Varun-B16395, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <112ADD30-18A2-4147-B185-46841D0119BD@kernel.crashing.org>
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
Sent: Saturday, March 16, 2013 2:00 AM
To: Leekha Shaveta-B20052
Cc: linuxppc-dev@lists.ozlabs.org; Zhao Chenhui-B35336; Li Yang-R58472; Tan=
g Yuantian-B29983; Sethi Varun-B16395; Lian Minghuan-B31939; Mehresh Ramnee=
k-B31383; Fleming Andy-AFLEMING
Subject: Re: [PATCH 1/6] powerpc/fsl-booke: Add initial silicon device tree=
files for B4860QDS
On Mar 15, 2013, at 2:55 AM, Shaveta Leekha wrote:
> Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
> Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com>
> Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
> Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
> Signed-off-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> ---
> arch/powerpc/boot/dts/fsl/b4860si-post.dtsi | 184 ++++++++++++++++++++++=
+++++
> arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi | 80 ++++++++++++
> 2 files changed, 264 insertions(+), 0 deletions(-) create mode 100644=20
> arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
> create mode 100644 arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
* SEC node is missing
* DCSR nodes are missing.
- k
[SL] will add sec node, same reply for dcsr.
>=20
> diff --git a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi=20
> b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
> new file mode 100644
> index 0000000..2db68b2
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
> @@ -0,0 +1,184 @@
> +/*
> + * B4860 Silicon/SoC Device Tree Source (post include)
> + *
> + * Copyright 2012 Freescale Semiconductor Inc.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions ar=
e met:
> + * * Redistributions of source code must retain the above copyright
> + * notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above copyrig=
ht
> + * notice, this list of conditions and the following disclaimer in=
the
> + * documentation and/or other materials provided with the distribu=
tion.
> + * * Neither the name of Freescale Semiconductor nor the
> + * names of its contributors may be used to endorse or promote pro=
ducts
> + * derived from this software without specific prior written permi=
ssion.
> + *
> + *
> + * ALTERNATIVELY, this software may be distributed under the terms of=20
> +the
> + * GNU General Public License ("GPL") as published by the Free=20
> +Software
> + * Foundation, either version 2 of that License or (at your option)=20
> +any
> + * later version.
> + *
> + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND=20
> +ANY
> + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE=20
> +IMPLIED
> + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE=20
> +ARE
> + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE=20
> +FOR ANY
> + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL=20
> +DAMAGES
> + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR=20
> +SERVICES;
> + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER=20
> +CAUSED AND
> + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,=20
> +OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE=20
> +USE OF THIS
> + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +&ifc {
> + #address-cells =3D <2>;
> + #size-cells =3D <1>;
> + compatible =3D "fsl,ifc", "simple-bus";
> + interrupts =3D <25 2 0 0>;
> +};
> +
> +/* controller at 0x200000 */
> +&pci0 {
> + compatible =3D "fsl,b4860-pcie", "fsl,qoriq-pcie-v2.4";
> + device_type =3D "pci";
> + #size-cells =3D <2>;
> + #address-cells =3D <3>;
> + bus-range =3D <0x0 0xff>;
> + interrupts =3D <20 2 0 0>;
> + pcie@0 {
> + #interrupt-cells =3D <1>;
> + #size-cells =3D <2>;
> + #address-cells =3D <3>;
> + device_type =3D "pci";
> + interrupts =3D <20 2 0 0>;
> + interrupt-map-mask =3D <0xf800 0 0 7>;
> + interrupt-map =3D <
> + /* IDSEL 0x0 */
> + 0000 0 0 1 &mpic 40 1 0 0
> + 0000 0 0 2 &mpic 1 1 0 0
> + 0000 0 0 3 &mpic 2 1 0 0
> + 0000 0 0 4 &mpic 3 1 0 0
> + >;
> + };
> +};
> +
> +&rio {
> + compatible =3D "fsl,srio";
> + interrupts =3D <16 2 1 11>;
> + #address-cells =3D <2>;
> + #size-cells =3D <2>;
> + ranges;
> +
> + port1 {
> + #address-cells =3D <2>;
> + #size-cells =3D <2>;
> + cell-index =3D <1>;
> + };
> +
> + port2 {
> + #address-cells =3D <2>;
> + #size-cells =3D <2>;
> + cell-index =3D <2>;
> + };
> +};
> +
> +&soc {
> + #address-cells =3D <1>;
> + #size-cells =3D <1>;
> + device_type =3D "soc";
> + compatible =3D "simple-bus";
> +
> + soc-sram-error {
> + compatible =3D "fsl,soc-sram-error";
> + interrupts =3D <16 2 1 2>;
> + };
> +
> + corenet-law@0 {
> + compatible =3D "fsl,corenet-law";
> + reg =3D <0x0 0x1000>;
> + fsl,num-laws =3D <32>;
> + };
> +
> + ddr1: memory-controller@8000 {
> + compatible =3D "fsl,qoriq-memory-controller-v4.5", "fsl,qoriq-memory-c=
ontroller";
> + reg =3D <0x8000 0x1000>;
> + interrupts =3D <16 2 1 8>;
> + };
> +
> + ddr2: memory-controller@9000 {
> + compatible =3D "fsl,qoriq-memory-controller-v4.5","fsl,qoriq-memory-co=
ntroller";
> + reg =3D <0x9000 0x1000>;
> + interrupts =3D <16 2 1 9>;
> + };
> +
> + cpc: l3-cache-controller@10000 {
> + compatible =3D "fsl,p5020-l3-cache-controller", "fsl,p4080-l3-cache-co=
ntroller", "cache";
> + reg =3D <0x10000 0x1000
> + 0x11000 0x1000>;
> + interrupts =3D <16 2 1 4
> + 16 2 1 5>;
> + };
> +
> + corenet-cf@18000 {
> + compatible =3D "fsl,corenet-cf";
> + reg =3D <0x18000 0x1000>;
> + interrupts =3D <16 2 1 0>;
> + fsl,ccf-num-csdids =3D <32>;
> + fsl,ccf-num-snoopids =3D <32>;
> + };
> +
> + iommu@20000 {
> + compatible =3D "fsl,pamu-v1.0", "fsl,pamu";
> + reg =3D <0x20000 0x4000>;
> + interrupts =3D <
> + 24 2 0 0
> + 16 2 1 1>;
> + };
> +
> +/include/ "qoriq-mpic.dtsi"
> +
> + guts: global-utilities@e0000 {
> + compatible =3D "fsl,b4860-device-config";
> + reg =3D <0xe0000 0xe00>;
> + fsl,has-rstcr;
> + fsl,liodn-bits =3D <12>;
> + };
> +
> + clockgen: global-utilities@e1000 {
> + compatible =3D "fsl,b4860-clockgen", "fsl,qoriq-clockgen-2";
> + reg =3D <0xe1000 0x1000>;
> + };
> +
> + rcpm: global-utilities@e2000 {
> + compatible =3D "fsl,b4860-rcpm", "fsl,qoriq-rcpm-2";
> + reg =3D <0xe2000 0x1000>;
> + };
> +
> +/include/ "qoriq-dma-0.dtsi"
> +/include/ "qoriq-dma-1.dtsi"
> +
> +/include/ "qonverge-usb2-dr-0.dtsi"
> + usb0: usb@210000 {
> + compatible =3D "fsl-usb2-dr-v2.4", "fsl-usb2-dr";
> + };
> +
> +/include/ "qoriq-espi-0.dtsi"
> + spi@110000 {
> + fsl,espi-num-chipselects =3D <4>;
> + };
> +
> +/include/ "qoriq-esdhc-0.dtsi"
> + sdhc@114000 {
> + sdhci,auto-cmd12;
> + };
> +/include/ "qoriq-i2c-0.dtsi"
> +/include/ "qoriq-i2c-1.dtsi"
> +/include/ "qoriq-duart-0.dtsi"
> +/include/ "qoriq-duart-1.dtsi"
> +
> + L2: l2-cache-controller@c20000 {
> + next-level-cache =3D <&cpc>;
should have compatible & reg nodes
[SL] agree. Will add=20
> + };
> +};
[ snip ]
- k
Regards,
Shaveta
^ permalink raw reply
* RE: [PATCH 2/6] powerpc/fsl-booke: Add initial B4860QDS board device tree
From: Leekha Shaveta-B20052 @ 2013-03-18 6:31 UTC (permalink / raw)
To: Kumar Gala
Cc: Fleming Andy-AFLEMING, Aggrwal Poonam-B10812,
linuxppc-dev@lists.ozlabs.org, Lian Minghuan-B31939,
Mehresh Ramneek-B31383
In-Reply-To: <7EB2D4A9-A5BC-4958-9AD8-51B254666356@kernel.crashing.org>
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
Sent: Saturday, March 16, 2013 1:57 AM
To: Leekha Shaveta-B20052
Cc: linuxppc-dev@lists.ozlabs.org; Lian Minghuan-B31939; Fleming Andy-AFLEM=
ING; Aggrwal Poonam-B10812; Mehresh Ramneek-B31383
Subject: Re: [PATCH 2/6] powerpc/fsl-booke: Add initial B4860QDS board devi=
ce tree
On Mar 15, 2013, at 2:55 AM, Shaveta Leekha wrote:
> Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
> Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
> Signed-off-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/boot/dts/b4860qds.dts | 178=20
> ++++++++++++++++++++++++++++++++++++
> 1 files changed, 178 insertions(+), 0 deletions(-) create mode 100644=20
> arch/powerpc/boot/dts/b4860qds.dts
>=20
> diff --git a/arch/powerpc/boot/dts/b4860qds.dts=20
> b/arch/powerpc/boot/dts/b4860qds.dts
> new file mode 100644
> index 0000000..ae6ac05
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/b4860qds.dts
> @@ -0,0 +1,178 @@
> +/*
> + * B4860DS Device Tree Source
> + *
> + * Copyright 2012 Freescale Semiconductor Inc.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions ar=
e met:
> + * * Redistributions of source code must retain the above copyright
> + * notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above copyrig=
ht
> + * notice, this list of conditions and the following disclaimer in=
the
> + * documentation and/or other materials provided with the distribu=
tion.
> + * * Neither the name of Freescale Semiconductor nor the
> + * names of its contributors may be used to endorse or promote pro=
ducts
> + * derived from this software without specific prior written permi=
ssion.
> + *
> + *
> + * ALTERNATIVELY, this software may be distributed under the terms of=20
> +the
> + * GNU General Public License ("GPL") as published by the Free=20
> +Software
> + * Foundation, either version 2 of that License or (at your option)=20
> +any
> + * later version.
> + *
> + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND=20
> +ANY
> + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE=20
> +IMPLIED
> + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE=20
> +ARE
> + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE=20
> +FOR ANY
> + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL=20
> +DAMAGES
> + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR=20
> +SERVICES;
> + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER=20
> +CAUSED AND
> + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,=20
> +OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE=20
> +USE OF THIS
> + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +/include/ "fsl/b4860si-pre.dtsi"
> +
> +/ {
> + model =3D "fsl,B4860QDS";
> + compatible =3D "fsl,B4860QDS";
> + #address-cells =3D <2>;
> + #size-cells =3D <2>;
> + interrupt-parent =3D <&mpic>;
> +
> + ifc: localbus@ffe124000 {
> + reg =3D <0xf 0xfe124000 0 0x2000>;
> + ranges =3D <0 0 0xf 0xe8000000 0x08000000
> + 2 0 0xf 0xff800000 0x00010000
> + 3 0 0xf 0xffdf0000 0x00008000>;
> +
> + nor@0,0 {
> + #address-cells =3D <1>;
> + #size-cells =3D <1>;
> + compatible =3D "cfi-flash";
> + reg =3D <0x0 0x0 0x8000000>;
> + bank-width =3D <2>;
> + device-width =3D <1>;
> + };
> +
> + nand@2,0 {
> + #address-cells =3D <1>;
> + #size-cells =3D <1>;
> + compatible =3D "fsl,ifc-nand";
> + reg =3D <0x2 0x0 0x10000>;
> +
> + partition@0 {
> + /* This location must not be altered */
> + /* 1MB for u-boot Bootloader Image */
> + reg =3D <0x0 0x00100000>;
> + label =3D "NAND U-Boot Image";
> + read-only;
> + };
> +
> + partition@100000 {
> + /* 1MB for DTB Image */
> + reg =3D <0x00100000 0x00100000>;
> + label =3D "NAND DTB Image";
> + };
> +
> + partition@200000 {
> + /* 10MB for Linux Kernel Image */
> + reg =3D <0x00200000 0x00A00000>;
> + label =3D "NAND Linux Kernel Image";
> + };
> +
> + partition@c00000 {
> + /* 500MB for Root file System Image */
> + reg =3D <0x00c00000 0x1F400000>;
> + label =3D "NAND RFS Image";
> + };
> + };
> +
> + board-control@3,0 {
> + compatible =3D "fsl,b4860qds-fpga", "fsl,fpga-qixis";
> + reg =3D <3 0 0x300>;
> + };
> + };
> +
dscr nodes are missing and should be included
[SL] I don't have much idea about dcsr nodes structure and their respective=
testing, also couldn't find then in T4 device tree files. I have added ini=
tial device trees. Dcsr may be added later as updation. What do you say? =20
> + memory {
> + device_type =3D "memory";
> + };
> +
> + soc: soc@ffe000000 {
> + ranges =3D <0x00000000 0xf 0xfe000000 0x1000000>;
> + reg =3D <0xf 0xfe000000 0 0x00001000>;
> + spi@110000 {
> + flash@0 {
> + #address-cells =3D <1>;
> + #size-cells =3D <1>;
> + compatible =3D "sst,sst25wf040";
> + reg =3D <0>;
> + spi-max-frequency =3D <40000000>; /* input clock */
> + };
> + };
> +
> + sdhc@114000 {
> + status =3D "disabled";
> + };
> +
> + i2c@118000 {
> + eeprom@50 {
> + compatible =3D "at24,24c64";
> + reg =3D <0x50>;
> + };
> + eeprom@51 {
> + compatible =3D "at24,24c256";
> + reg =3D <0x51>;
> + };
> + eeprom@53 {
> + compatible =3D "at24,24c256";
> + reg =3D <0x53>;
> + };
> + eeprom@57 {
> + compatible =3D "at24,24c256";
> + reg =3D <0x57>;
> + };
> + rtc@68 {
> + compatible =3D "dallas,ds3232";
> + reg =3D <0x68>;
> + interrupts =3D <0x1 0x1 0 0>;
there is no IRQ for RTC on the board.
[SL] will remove it.=20
> + };
> + };
> +
> + usb@210000 {
> + dr_mode =3D "host";
> + phy_type =3D "ulpi";
> + };
> +
> + };
> +
> + pci0: pcie@ffe200000 {
> + reg =3D <0xf 0xfe200000 0 0x10000>;
> + ranges =3D <0x02000000 0 0xe0000000 0xc 0x00000000 0x0 0x20000000
> + 0x01000000 0 0x00000000 0xf 0xf8000000 0x0 0x00010000>;
> + pcie@0 {
> + ranges =3D <0x02000000 0 0xe0000000
> + 0x02000000 0 0xe0000000
> + 0 0x20000000
> +
> + 0x01000000 0 0x00000000
> + 0x01000000 0 0x00000000
> + 0 0x00010000>;
> + };
> + };
> +
> + rio: rapidio@ffe0c0000 {
> + reg =3D <0xf 0xfe0c0000 0 0x11000>;
> +
> + port1 {
> + ranges =3D <0 0 0xc 0x20000000 0 0x10000000>;
> + };
> + port2 {
> + ranges =3D <0 0 0xc 0x30000000 0 0x10000000>;
> + };
> + };
> +
> +};
> +
> +/include/ "fsl/b4860si-post.dtsi"
> --
> 1.7.6.GIT
>=20
Regards,
Shaveta
=20
^ permalink raw reply
* RE: [PATCH 5/6] powerpc/fsl-booke: Add B4_QDS board support
From: Leekha Shaveta-B20052 @ 2013-03-18 6:28 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <69F32D25-11C5-414D-A23A-AD25C9CCF9C6@kernel.crashing.org>
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
Sent: Friday, March 15, 2013 9:28 PM
To: Leekha Shaveta-B20052
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 5/6] powerpc/fsl-booke: Add B4_QDS board support
On Mar 15, 2013, at 2:55 AM, Shaveta Leekha wrote:
> - Add support for B4 board's personalities in board file b4_qds.c, It=20
> is common for B4 personalities B4860 and B4420QDS
> - Add B4QDS support in Kconfig and Makefile
Code also references a B4220, what about it?
[SL] I have added the basic support for it in board file as it's one of the=
personality of
B4, missed it in description. But device trees for this has not been create=
d and tested.
So what do you suggest here:
Should I add it here in B4 board support or should I remove its references =
altogether?
>=20
> B4860QDS is a high-performance computing evaluation, development and=20
> test platform supporting the B4860 QorIQ Power Architecture processor,=20
> with following major features:
>=20
> - Four dual-threaded e6500 Power Architecture processors
> organized in one cluster-each core runs up to 1.8 GHz
> - Two DDR3/3L controllers for high-speed memory interface each
> runs at up to 1866.67 MHz
> - CoreNet fabric that fully supports coherency using MESI protocol
> between the e6500 cores, SC3900 FVP cores, memories and
> external interfaces.
> - Data Path Acceleration Architecture having FMAN, QMan, BMan, SEC 5.3=
and RMAN
> - Large internal cache memory with snooping and stashing capabilities
> - Sixteen 10-GHz SerDes lanes that serve:
> - Two SRIO interfaces. Each supports up to 4 lanes and
> a total of up to 8 lanes
> - Up to 8-lanes Common Public Radio Interface (CPRI) controller
> for glue-less antenna connection
> - Two 10-Gbit Ethernet controllers (10GEC)
> - Six 1G/2.5-Gbit Ethernet controllers for network communications
> - PCI Express controller
> - Debug (Aurora)
> - Various system peripherals
>=20
> B4420 is a reduced personality of B4860 with fewer core/clusters(both=20
> SC3900 and e6500), fewer DDR controllers, fewer serdes lanes, fewer SGMII=
interfaces and reduced target frequencies.
>=20
> Key differences between B4860 and B4420:
> B4420 has:
> - Fewer e6500 cores:
> 1 cluster with 2 e6500 cores
> - Fewer SC3900 cores/clusters:
> 1 cluster with 2 SC3900 cores per cluster
> - Single DDRC
> - 2X 4 lane serdes
> - 3 SGMII interfaces
> - no sRIO
> - no 10G
>=20
> Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
> ---
> arch/powerpc/platforms/85xx/Kconfig | 16 +++++
> arch/powerpc/platforms/85xx/Makefile | 1 +
> arch/powerpc/platforms/85xx/b4_qds.c | 102=20
> ++++++++++++++++++++++++++++++++++
> 3 files changed, 119 insertions(+), 0 deletions(-) create mode 100644=20
> arch/powerpc/platforms/85xx/b4_qds.c
>=20
> diff --git a/arch/powerpc/platforms/85xx/Kconfig=20
> b/arch/powerpc/platforms/85xx/Kconfig
> index 31dc066..7bbd522 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -262,6 +262,22 @@ config SGY_CTS1000
>=20
> endif # PPC32
>=20
> +config B4_QDS
> + bool "Freescale B4 QDS"
> + select DEFAULT_UIMAGE
> + select E500
> + select PPC_E500MC
> + select PHYS_64BIT
> + select SWIOTLB
> + select MPC8xxx_GPIO
should be:
select GENERIC_GPIO
select ARCH_REQUIRE_GPIOLIB
[SL] will change it.
=20
> + select HAS_RAPIDIO
> + select PPC_EPAPR_HV_PIC
> + help
> + This option enables support for the B4 QDS board
> + The B4 application development system B4 QDS is a complete
> + debugging environment intended for engineers developing
> + applications for the B4.
> +
Should be in the if PPC64 section with T4240 QDS support
[SL] ok=20
> config P5020_DS
> bool "Freescale P5020 DS"
> select DEFAULT_UIMAGE
> diff --git a/arch/powerpc/platforms/85xx/Makefile=20
> b/arch/powerpc/platforms/85xx/Makefile
> index 712e233..a12ae2d 100644
> --- a/arch/powerpc/platforms/85xx/Makefile
> +++ b/arch/powerpc/platforms/85xx/Makefile
> @@ -6,6 +6,7 @@ obj-$(CONFIG_SMP) +=3D smp.o obj-y +=3D common.o
>=20
> obj-$(CONFIG_BSC9131_RDB) +=3D bsc913x_rdb.o
> +obj-$(CONFIG_B4_QDS) +=3D b4_qds.o corenet_ds.o
> obj-$(CONFIG_MPC8540_ADS) +=3D mpc85xx_ads.o
> obj-$(CONFIG_MPC8560_ADS) +=3D mpc85xx_ads.o
> obj-$(CONFIG_MPC85xx_CDS) +=3D mpc85xx_cds.o diff --git=20
> a/arch/powerpc/platforms/85xx/b4_qds.c=20
> b/arch/powerpc/platforms/85xx/b4_qds.c
> new file mode 100644
> index 0000000..0c6702f
> --- /dev/null
> +++ b/arch/powerpc/platforms/85xx/b4_qds.c
> @@ -0,0 +1,102 @@
> +/*
> + * B4 QDS Setup
> + * Should apply for QDS platform of B4860 and it's personalities.
> + * viz B4860/B4420/B4220QDS
> + *
> + * Copyright 2012 Freescale Semiconductor Inc.
> + *
> + * This program is free software; you can redistribute it and/or=20
> +modify it
> + * under the terms of the GNU General Public License as published=20
> +by the
> + * Free Software Foundation; either version 2 of the License, or=20
> +(at your
> + * option) any later version.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/pci.h>
> +#include <linux/kdev_t.h>
> +#include <linux/delay.h>
> +#include <linux/interrupt.h>
> +#include <linux/phy.h>
> +
> +#include <asm/time.h>
> +#include <asm/machdep.h>
> +#include <asm/pci-bridge.h>
> +#include <mm/mmu_decl.h>
> +#include <asm/prom.h>
> +#include <asm/udbg.h>
> +#include <asm/mpic.h>
> +
> +#include <linux/of_platform.h>
> +#include <sysdev/fsl_soc.h>
> +#include <sysdev/fsl_pci.h>
> +#include <asm/ehv_pic.h>
> +
> +#include "corenet_ds.h"
> +
> +/*
> + * Called very early, device-tree isn't unflattened */ static int=20
> +__init b4_qds_probe(void) {
> + unsigned long root =3D of_get_flat_dt_root(); #ifdef CONFIG_SMP
> + extern struct smp_ops_t smp_85xx_ops; #endif
> +
> + if ((of_flat_dt_is_compatible(root, "fsl,B4860QDS")) ||
> + (of_flat_dt_is_compatible(root, "fsl,B4420QDS")) ||
> + (of_flat_dt_is_compatible(root, "fsl,B4220QDS")))
> + return 1;
> +
> + /* Check if we're running under the Freescale hypervisor */
> + if ((of_flat_dt_is_compatible(root, "fsl,B4860QDS-hv")) ||
> + (of_flat_dt_is_compatible(root, "fsl,B4420QDS-hv")) ||
> + (of_flat_dt_is_compatible(root, "fsl,B4220QDS-hv"))) {
> + ppc_md.init_IRQ =3D ehv_pic_init;
> + ppc_md.get_irq =3D ehv_pic_get_irq;
> + ppc_md.restart =3D fsl_hv_restart;
> + ppc_md.power_off =3D fsl_hv_halt;
> + ppc_md.halt =3D fsl_hv_halt;
> +#ifdef CONFIG_SMP
> + /*
> + * Disable the timebase sync operations because we can't write
> + * to the timebase registers under the hypervisor.
> + */
> + smp_85xx_ops.give_timebase =3D NULL;
> + smp_85xx_ops.take_timebase =3D NULL;
> +#endif
> + return 1;
> + }
> +
> + return 0;
> +}
> +
> +define_machine(b4_qds) {
> + .name =3D "B4 QDS",
> + .probe =3D b4_qds_probe,
> + .setup_arch =3D corenet_ds_setup_arch,
> + .init_IRQ =3D corenet_ds_pic_init,
> +#ifdef CONFIG_PCI
> + .pcibios_fixup_bus =3D fsl_pcibios_fixup_bus,
> +#endif
> +/* coreint doesn't play nice with lazy EE, use legacy mpic for now */=20
> +#ifdef CONFIG_PPC64
> + .get_irq =3D mpic_get_irq,
> +#else
> + .get_irq =3D mpic_get_coreint_irq,
> +#endif
> + .restart =3D fsl_rstcr_restart,
> + .calibrate_decr =3D generic_calibrate_decr,
> + .progress =3D udbg_progress,
> +#ifdef CONFIG_PPC64
> + .power_save =3D book3e_idle,
> +#else
> + .power_save =3D e500_idle,
> +#endif
> +};
> +
> +machine_arch_initcall(b4_qds, corenet_ds_publish_devices);
> +
> +#ifdef CONFIG_SWIOTLB
> +machine_arch_initcall(b4_qds, swiotlb_setup_bus_notifier); #endif
> --
> 1.7.6.GIT
>=20
>=20
Regards,
Shaveta
=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2013-03-18 5:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, Linux Kernel list
Hi Linus !
Here's a few powerpc fixes for 3.9, mostly regressions (though not all
from 3.9 merge window) that we've been hammering into shape over the
last couple of weeks. They fix booting on Cell and G5 among other
things (yes, we've been a bit sloppy with older machines this time
around).
Cheers,
Ben.
The following changes since commit 7c6baa304b841673d3a55ea4fcf9a5cbf7a1674b:
Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2013-03-11 07:54:29 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
for you to fetch changes up to af81d7878c641629f2693ae3fdaf74b4af14dfca:
powerpc: Rename USER_ESID_BITS* to ESID_BITS* (2013-03-17 12:45:44 +1100)
----------------------------------------------------------------
Aneesh Kumar K.V (3):
powerpc: Make VSID_BITS* dependency explicit
powerpc: Update kernel VSID range
powerpc: Rename USER_ESID_BITS* to ESID_BITS*
Anton Blanchard (1):
powerpc: Fix -mcmodel=medium breakage in prom_init.c
Benjamin Herrenschmidt (2):
powerpc: Fix STAB initialization
powerpc: Fix cputable entry for 970MP rev 1.0
Michael Neuling (1):
powerpc/ptrace: Fix brk.len used uninitialised
Paul Bolle (1):
powerpc: Remove last traces of POWER4_ONLY
Stephen Rothwell (1):
powerpc: Make sure that we alays include CONFIG_BINFMT_ELF
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/mmu-hash64.h | 128 ++++++++++++++++----------------
arch/powerpc/kernel/cputable.c | 2 +-
arch/powerpc/kernel/exceptions-64s.S | 34 ++++++---
arch/powerpc/kernel/prom_init.c | 14 ++--
arch/powerpc/kernel/ptrace.c | 1 +
arch/powerpc/kvm/book3s_64_mmu_host.c | 4 +-
arch/powerpc/mm/hash_utils_64.c | 22 ++++--
arch/powerpc/mm/mmu_context_hash64.c | 11 +--
arch/powerpc/mm/pgtable_64.c | 2 +-
arch/powerpc/mm/slb_low.S | 50 ++++++-------
arch/powerpc/mm/tlb_hash64.c | 2 +-
arch/powerpc/platforms/Kconfig.cputype | 6 +-
13 files changed, 150 insertions(+), 127 deletions(-)
^ permalink raw reply
* Re: [PATCH 1/9] powerpc,kvm: fix imbalance srcu_read_[un]lock()
From: Paul Mackerras @ 2013-03-17 21:26 UTC (permalink / raw)
To: Lai Jiangshan
Cc: kvm, Gleb Natapov, Marcelo Tosatti, Alexander Graf, kvm-ppc,
linux-kernel, Andrew Morton, Paul E. McKenney, linuxppc-dev
In-Reply-To: <1363366257-4886-2-git-send-email-laijs@cn.fujitsu.com>
On Sat, Mar 16, 2013 at 12:50:49AM +0800, Lai Jiangshan wrote:
> At the point of up_out label in kvmppc_hv_setup_htab_rma(),
> srcu read lock is still held.
>
> We have to release it before return.
>
> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
> Cc: Marcelo Tosatti <mtosatti@redhat.com>
> Cc: Gleb Natapov <gleb@redhat.com>
> Cc: Alexander Graf <agraf@suse.de>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: kvm@vger.kernel.org
> Cc: kvm-ppc@vger.kernel.org
> ---
> arch/powerpc/kvm/book3s_hv.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 80dcc53..c26740e 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -1799,7 +1799,7 @@ static int kvmppc_hv_setup_htab_rma(struct kvm_vcpu *vcpu)
>
> up_out:
> up_read(¤t->mm->mmap_sem);
> - goto out;
> + goto out_srcu;
Acked-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* RE: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu implementation.
From: Sethi Varun-B16395 @ 2013-03-17 15:49 UTC (permalink / raw)
To: Yoder Stuart-B08248, Kumar Gala
Cc: Wood Scott-B07421, joro@8bytes.org, linux-kernel@vger.kernel.org,
iommu@lists.linux-foundation.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <9F6FE96B71CF29479FF1CDC8046E1503586936@039-SN1MPN1-002.039d.mgd.msft.net>
> -----Original Message-----
> From: Yoder Stuart-B08248
> Sent: Friday, March 15, 2013 2:45 AM
> To: Kumar Gala; Sethi Varun-B16395
> Cc: joro@8bytes.org; iommu@lists.linux-foundation.org; linuxppc-
> dev@lists.ozlabs.org; linux-kernel@vger.kernel.org;
> benh@kernel.crashing.org; Wood Scott-B07421
> Subject: RE: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu
> implementation.
>=20
>=20
>=20
> > -----Original Message-----
> > From: Kumar Gala [mailto:galak@kernel.crashing.org]
> > Sent: Thursday, March 14, 2013 3:20 PM
> > To: Sethi Varun-B16395
> > Cc: joro@8bytes.org; iommu@lists.linux-foundation.org;
> > linuxppc-dev@lists.ozlabs.org; linux- kernel@vger.kernel.org;
> > benh@kernel.crashing.org; Wood Scott-B07421; Yoder Stuart-B08248
> > Subject: Re: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu
> implementation.
> >
> >
> > On Mar 13, 2013, at 1:49 PM, Varun Sethi wrote:
> >
> > > +/*
> > > + * Table of SVRs and the corresponding PORT_ID values.
> > > + *
> > > + * All future CoreNet-enabled SOCs will have this erratum fixed, so
> > > +this table
> > > + * should never need to be updated. SVRs are guaranteed to be
> > > +unique, so
> > > + * there is no worry that a future SOC will inadvertently have one
> > > +of these
> > > + * values.
> > > + */
> >
> > Maybe add to the comment about what port_id represents
>=20
> When you update the comment, I would also suggest identifying the
> specific errata here (A-004510) so that it's easy to reference back to
> the specific issue this code is fixing.
[Sethi Varun-B16395] Ok
-Varun
^ permalink raw reply
* RE: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu implementation.
From: Sethi Varun-B16395 @ 2013-03-17 15:49 UTC (permalink / raw)
To: Kumar Gala
Cc: Wood Scott-B07421, joro@8bytes.org, linux-kernel@vger.kernel.org,
Yoder Stuart-B08248, iommu@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <DF9A711B-63AF-411C-84E4-0C9F61A2EB21@kernel.crashing.org>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Friday, March 15, 2013 1:53 AM
> To: Sethi Varun-B16395
> Cc: joro@8bytes.org; linux-kernel@vger.kernel.org; Yoder Stuart-B08248;
> iommu@lists.linux-foundation.org; Wood Scott-B07421; linuxppc-
> dev@lists.ozlabs.org
> Subject: Re: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu
> implementation.
>=20
>=20
> On Mar 14, 2013, at 3:20 PM, Kumar Gala wrote:
>=20
> >
> > On Mar 13, 2013, at 1:49 PM, Varun Sethi wrote:
> >
> >> +/*
> >> + * Table of SVRs and the corresponding PORT_ID values.
> >> + *
> >> + * All future CoreNet-enabled SOCs will have this erratum fixed, so
> >> +this table
> >> + * should never need to be updated. SVRs are guaranteed to be
> >> +unique, so
> >> + * there is no worry that a future SOC will inadvertently have one
> >> +of these
> >> + * values.
> >> + */
> >
> > Maybe add to the comment about what port_id represents
>=20
> also, add reference to the erratum #/id/name
>=20
[Sethi Varun-B16395] Ok.
-Varun
^ permalink raw reply
* RE: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu implementation.
From: Sethi Varun-B16395 @ 2013-03-17 15:48 UTC (permalink / raw)
To: Kumar Gala
Cc: Wood Scott-B07421, linux-kernel@vger.kernel.org,
Yoder Stuart-B08248, iommu@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <0080B56D-8417-41B9-8341-665457D04DE6@kernel.crashing.org>
> -----Original Message-----
> From: iommu-bounces@lists.linux-foundation.org [mailto:iommu-
> bounces@lists.linux-foundation.org] On Behalf Of Kumar Gala
> Sent: Friday, March 15, 2013 1:50 AM
> To: Sethi Varun-B16395
> Cc: benh@kernel.crashing.org; linux-kernel@vger.kernel.org; Yoder Stuart-
> B08248; iommu@lists.linux-foundation.org; Wood Scott-B07421; linuxppc-
> dev@lists.ozlabs.org
> Subject: Re: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu
> implementation.
>=20
>=20
> On Mar 13, 2013, at 1:49 PM, Varun Sethi wrote:
>=20
> > +/*
> > + * Table of SVRs and the corresponding PORT_ID values.
> > + *
> > + * All future CoreNet-enabled SOCs will have this erratum fixed, so
> > +this table
> > + * should never need to be updated. SVRs are guaranteed to be
> > +unique, so
> > + * there is no worry that a future SOC will inadvertently have one of
> > +these
> > + * values.
> > + */
>=20
> Maybe add to the comment about what port_id represents
>=20
[Sethi Varun-B16395] ok.
> > +static const struct {
> > + u32 svr;
> > + u32 port_id;
> > +} port_id_map[] =3D {
> > + {0x82100010, 0xFF000000}, /* P2040 1.0 */
> > + {0x82100011, 0xFF000000}, /* P2040 1.1 */
> > + {0x82100110, 0xFF000000}, /* P2041 1.0 */
> > + {0x82100111, 0xFF000000}, /* P2041 1.1 */
> > + {0x82110310, 0xFF000000}, /* P3041 1.0 */
> > + {0x82110311, 0xFF000000}, /* P3041 1.1 */
> > + {0x82010020, 0xFFF80000}, /* P4040 2.0 */
> > + {0x82000020, 0xFFF80000}, /* P4080 2.0 */
> > + {0x82210010, 0xFC000000}, /* P5010 1.0 */
> > + {0x82210020, 0xFC000000}, /* P5010 2.0 */
> > + {0x82200010, 0xFC000000}, /* P5020 1.0 */
> > + {0x82050010, 0xFF800000}, /* P5021 1.0 */
> > + {0x82040010, 0xFF800000}, /* P5040 1.0 */
> > +};
> > +
> > +#define SVR_SECURITY 0x80000 /* The Security (E) bit */
> > +
> > +static int __init fsl_pamu_probe(struct platform_device *pdev) {
> > + void __iomem *pamu_regs =3D NULL;
> > + struct ccsr_guts __iomem *guts_regs =3D NULL;
> > + u32 pamubypenr, pamu_counter;
> > + unsigned long pamu_reg_off;
> > + unsigned long pamu_reg_base;
> > + struct pamu_isr_data *data;
> > + struct device_node *guts_node;
> > + u64 size;
> > + struct page *p;
> > + int ret =3D 0;
> > + int irq;
> > + phys_addr_t ppaact_phys;
> > + phys_addr_t spaact_phys;
> > + phys_addr_t omt_phys;
> > + size_t mem_size =3D 0;
> > + unsigned int order =3D 0;
> > + u32 csd_port_id =3D 0;
> > + unsigned i;
> > + /*
> > + * enumerate all PAMUs and allocate and setup PAMU tables
> > + * for each of them,
> > + * NOTE : All PAMUs share the same LIODN tables.
> > + */
> > +
> > + pamu_regs =3D of_iomap(pdev->dev.of_node, 0);
> > + if (!pamu_regs) {
> > + dev_err(&pdev->dev, "ioremap of PAMU node failed\n");
> > + return -ENOMEM;
> > + }
> > + of_get_address(pdev->dev.of_node, 0, &size, NULL);
> > +
> > + irq =3D irq_of_parse_and_map(pdev->dev.of_node, 0);
> > + if (irq =3D=3D NO_IRQ) {
> > + dev_warn(&pdev->dev, "no interrupts listed in PAMU node\n");
> > + goto error;
> > + }
> > +
> > + data =3D kzalloc(sizeof(struct pamu_isr_data), GFP_KERNEL);
> > + if (!data) {
> > + iounmap(pamu_regs);
> > + return -ENOMEM;
> > + }
> > + data->pamu_reg_base =3D pamu_regs;
> > + data->count =3D size / PAMU_OFFSET;
> > +
> > + /* The ISR needs access to the regs, so we won't iounmap them */
> > + ret =3D request_irq(irq, pamu_av_isr, 0, "pamu", data);
> > + if (ret < 0) {
> > + dev_err(&pdev->dev, "error %i installing ISR for irq %i\n",
> > + ret, irq);
> > + goto error;
> > + }
> > +
> > + guts_node =3D of_find_compatible_node(NULL, NULL,
> > + "fsl,qoriq-device-config-1.0");
>=20
> This doesn't work for T4 or B4 device trees.
>=20
[Sethi Varun-B16395]hmm.... I need to use the dcfg space for this.
> > + if (!guts_node) {
> > + dev_err(&pdev->dev, "could not find GUTS node %s\n",
> > + pdev->dev.of_node->full_name);
> > + ret =3D -ENODEV;
> > + goto error;
> > + }
> > +
> > + guts_regs =3D of_iomap(guts_node, 0);
> > + of_node_put(guts_node);
> > + if (!guts_regs) {
> > + dev_err(&pdev->dev, "ioremap of GUTS node failed\n");
> > + ret =3D -ENODEV;
> > + goto error;
> > + }
> > +
> > + /* read in the PAMU capability registers */
> > + get_pamu_cap_values((unsigned long)pamu_regs);
> > + /*
> > + * To simplify the allocation of a coherency domain, we allocate
> the
> > + * PAACT and the OMT in the same memory buffer. Unfortunately,
> this
> > + * wastes more memory compared to allocating the buffers
> separately.
> > + */
> > + /* Determine how much memory we need */
> > + mem_size =3D (PAGE_SIZE << get_order(PAACT_SIZE)) +
> > + (PAGE_SIZE << get_order(SPAACT_SIZE)) +
> > + (PAGE_SIZE << get_order(OMT_SIZE));
> > + order =3D get_order(mem_size);
> > +
> > + p =3D alloc_pages(GFP_KERNEL | __GFP_ZERO, order);
> > + if (!p) {
> > + dev_err(&pdev->dev, "unable to allocate PAACT/SPAACT/OMT
> block\n");
> > + ret =3D -ENOMEM;
> > + goto error;
> > + }
> > +
> > + ppaact =3D page_address(p);
> > + ppaact_phys =3D page_to_phys(p);
> > +
> > + /* Make sure the memory is naturally aligned */
> > + if (ppaact_phys & ((PAGE_SIZE << order) - 1)) {
> > + dev_err(&pdev->dev, "PAACT/OMT block is unaligned\n");
> > + ret =3D -ENOMEM;
> > + goto error;
> > + }
> > +
> > + spaact =3D (void *)ppaact + (PAGE_SIZE << get_order(PAACT_SIZE));
> > + omt =3D (void *)spaact + (PAGE_SIZE << get_order(SPAACT_SIZE));
> > +
> > + dev_dbg(&pdev->dev, "ppaact virt=3D%p phys=3D0x%llx\n", ppaact,
> > + (unsigned long long) ppaact_phys);
> > +
> > + /* Check to see if we need to implement the work-around on this SOC
> > +*/
> > +
> > + /* Determine the Port ID for our coherence subdomain */
> > + for (i =3D 0; i < ARRAY_SIZE(port_id_map); i++) {
> > + if (port_id_map[i].svr =3D=3D (mfspr(SPRN_SVR) & ~SVR_SECURITY))
> {
> > + csd_port_id =3D port_id_map[i].port_id;
> > + dev_dbg(&pdev->dev, "found matching SVR %08x\n",
> > + port_id_map[i].svr);
> > + break;
> > + }
> > + }
> > +
> > + if (csd_port_id) {
> > + dev_dbg(&pdev->dev, "creating coherency subdomain at address
> "
> > + "0x%llx, size %zu, port id 0x%08x", ppaact_phys,
> > + mem_size, csd_port_id);
> > +
> > + ret =3D create_csd(ppaact_phys, mem_size, csd_port_id);
> > + if (ret) {
> > + dev_err(&pdev->dev, "could not create coherence "
> > + "subdomain\n");
> > + return ret;
> > + }
> > + }
> > +
> > + spaact_phys =3D virt_to_phys(spaact);
> > + omt_phys =3D virt_to_phys(omt);
> > +
> > + spaace_pool =3D gen_pool_create(ilog2(sizeof(struct paace)), -1);
> > + if (!spaace_pool) {
> > + ret =3D -ENOMEM;
> > + dev_err(&pdev->dev, "PAMU : failed to allocate spaace gen
> pool\n");
> > + goto error;
> > + }
> > +
> > + ret =3D gen_pool_add(spaace_pool, (unsigned long)spaact, SPAACT_SIZE,
> -1);
> > + if (ret)
> > + goto error_genpool;
> > +
> > + pamubypenr =3D in_be32(&guts_regs->pamubypenr);
> > +
> > + for (pamu_reg_off =3D 0, pamu_counter =3D 0x80000000; pamu_reg_off <
> size;
> > + pamu_reg_off +=3D PAMU_OFFSET, pamu_counter >>=3D 1) {
> > +
> > + pamu_reg_base =3D (unsigned long) pamu_regs + pamu_reg_off;
> > + setup_one_pamu(pamu_reg_base, pamu_reg_off, ppaact_phys,
> > + spaact_phys, omt_phys);
> > + /* Disable PAMU bypass for this PAMU */
> > + pamubypenr &=3D ~pamu_counter;
> > + }
> > +
> > + setup_omt(omt);
> > +
> > + /* Enable all relevant PAMU(s) */
> > + out_be32(&guts_regs->pamubypenr, pamubypenr);
> > +
> > + iounmap(guts_regs);
> > +
> > + /* Enable DMA for the LIODNs in the device tree*/
> > +
> > + setup_liodns();
> > +
> > + return 0;
> > +
> > +error_genpool:
> > + gen_pool_destroy(spaace_pool);
> > +
> > +error:
> > + if (irq !=3D NO_IRQ)
> > + free_irq(irq, 0);
>=20
> Should be:
>=20
> free_irq(irq, data);
>=20
[Sethi Varun-B16395] Yes.
> > +
> > + if (pamu_regs)
> > + iounmap(pamu_regs);
> > +
> > + if (guts_regs)
> > + iounmap(guts_regs);
> > +
> > + if (ppaact)
> > + free_pages((unsigned long)ppaact, order);
> > +
> > + ppaact =3D NULL;
> > +
>=20
> you alloc data, shouldn't you free it ?
>=20
[Sethi Varun-B16395] Yes.
-Varun
^ permalink raw reply
* Re: Kernel panic on PowerMac G5 while scanning for SMU sensors
From: Phileas Fogg @ 2013-03-17 12:42 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <5145B20C.2090104@mail.ru>
On 03/17/2013 01:07 PM, Phileas Fogg wrote:
>
> I wanted to read the temperature sensors of my PowerMac G5 11,2.
> For that i installed the lm-sensors package, run 'sensors-detect'
> command and my Linux 3.8.2 kernel paniced in
>
> _smu_i2c_low_completion_
>
> with this message
>
> 'Unable to handle kernel paging request for data at address 0x00000008.'
>
> Regards
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
A further analysis showed that it crashes in _smu_i2c_complete_command_
which is called from _smu_i2c_low_completion_.
This line caused the panic:
list_del(&cmd->link);
regards
^ permalink raw reply
* Kernel panic on PowerMac G5 while scanning for SMU sensors
From: Phileas Fogg @ 2013-03-17 12:07 UTC (permalink / raw)
To: linuxppc-dev
I wanted to read the temperature sensors of my PowerMac G5 11,2.
For that i installed the lm-sensors package, run 'sensors-detect'
command and my Linux 3.8.2 kernel paniced in
_smu_i2c_low_completion_
with this message
'Unable to handle kernel paging request for data at address 0x00000008.'
Regards
^ permalink raw reply
* Re: [PATCH] powerpc: add Book E support to 64-bit hibernation
From: Johannes Berg @ 2013-03-15 15:22 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Wang Dongsheng
In-Reply-To: <1363279961.28440.4@snotra>
On Thu, 2013-03-14 at 11:52 -0500, Scott Wood wrote:
> > > +#ifdef CONFIG_PPC_BOOK3S_64
> > > /* can't use RESTORE_SPECIAL(MSR) */
> > > ld r0, SL_MSR(r11)
> > > mtmsrd r0, 0
> >
> > Unfortunately, I forgot the reason for this comment, and didn't put a
> > better one (almost 6 years ago!!)
> If it's because book3s needs mtmsrd instead of mtmsr, that doesn't
> apply to booke.
Indeed, looking at the code again now that seems pretty obvious.
Looking at the patch again, I'd be a little concerned about the lack of
cache flushing, seems a bit odd but I'm sure you know what you're doing
(and I don't know book3e at all, and hardly remember book3s -- or even
that name...) :-)
johannes
^ permalink raw reply
* Re: [PATCH 2/3] VFIO: VFIO_DEVICE_SET_ADDR_MAPPING command
From: Benjamin Herrenschmidt @ 2013-03-16 5:37 UTC (permalink / raw)
To: Gavin Shan; +Cc: aik, Alex Williamson, linuxppc-dev, kvm
In-Reply-To: <20130316013417.GA3873@shangw.(null)>
On Sat, 2013-03-16 at 09:34 +0800, Gavin Shan wrote:
> >Could you explain further how this will be used? How the device is
> >exposed to a guest is entirely a userspace construct, so why does vfio
> >need to know or care about this? I had assumed for AER that QEMU would
> >do the translation from host to guest address space.
> >
>
> The weak IOCTL function (vfio_pci_arch_ioctl) was introduced by previous
> patch. The PowerNV platform is going to override it to figure out the
> information for EEH core to use. On the other hand, QEMU will runs into
> the IOCTL command while opening (creating) one VFIO device.
>
> Though I'm not familiar with AER very much. AER is quite different from
> EEH. The EEH functionality implemented in PHB instead of in PCI device
> core. So we don't care AER stuff in EEH directly :-)
To give Alex a bit more background...
EEH is our IBM specific error handling facility which is a superset of AER.
IE. In addition to AER's error detection and logging, it adds a layer of
error detection at the host bridge level (such as iommu violations etc...)
and a mechanism for handling and recovering from errors. This is tied to
our iommu domain stuff (our PE's) and our device "freezing" capability
among others.
With VFIO + KVM, we want to implement most of the EEH support for guests in
the host kernel. The reason is multipart and we can discuss this separately
as some of it might well be debatable (mostly it's more convenient that way
because we hook into the underlying HW/FW EEH which isn't directly userspace
accessible so we don't have to add a new layer of kernel -> user API in
addition to the VFIO stuff), but there's at least one aspect of it that drives
this requirement more strongly which is performance:
When EEH is enabled, whenever any MMIO returns all 1's, the kernel will do
a firmware call to query the EEH state of the device and check whether it
has been frozen. On some devices, that can be a performance issue, and
going all the way to qemu for that would be horribly expensive.
So we want at least a way to handle that call in the kernel and for that we
need at least some way of mapping things there.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 3/3] VFIO: Direct access config reg without capability
From: Benjamin Herrenschmidt @ 2013-03-16 5:30 UTC (permalink / raw)
To: Alex Williamson; +Cc: aik, linuxppc-dev, Gavin Shan, kvm
In-Reply-To: <1363376468.16793.18.camel@ul30vt.home>
On Fri, 2013-03-15 at 13:41 -0600, Alex Williamson wrote:
>
> This basically gives userspace free access to any regions that aren't
> covered by known capabilities.
And ?
I mean seriously :-) We already had that discussion ... trying to
"protect" config space is just plain doomed. There is no point.
It makes sense to do things like emulate BARs etc... for things to
function properly under some circumstances/setups where you can't just
expose the original BAR values to the guest and have the HW take care of
it but you *must* be prepared to deal with anything in config space
being changed without you knowing about it.
Devices *will* have backdoors via MMIO. Period. You cannot rely on those
not existing, whether they are documented or not.
If you can't cope with the config space accesses then you aren't
properly isolated. It can be deemed acceptable (depends what you use
your VMs for) but that I mean is that any config space
filtering/emulation for the sake of "security" is ... pointless.
Doing it for functionality to work at all (ie BAR emulation) is fine,
but that's about it. IE. As a mean of security it's pointless.
> We have no idea what this might expose on some devices.
No more than we have any idea what MMIO mapping of the device register
space exposes :-)
> I'd like to support be2net, but what's the minimal
> access that it needs? Can we provide 2 or 4 bytes of read-only access
> at offset 0x7c for just that device? Is it always 0x7c? Let's split
> this patch from the series since it's clearly dealing with something
> independent. Thanks,
Ben.
^ permalink raw reply
* Re: [PATCH 3/3] VFIO: Direct access config reg without capability
From: Gavin Shan @ 2013-03-16 3:34 UTC (permalink / raw)
To: Alex Williamson; +Cc: aik, linuxppc-dev, Gavin Shan, kvm
In-Reply-To: <1363376468.16793.18.camel@ul30vt.home>
On Fri, Mar 15, 2013 at 01:41:08PM -0600, Alex Williamson wrote:
>On Fri, 2013-03-15 at 15:26 +0800, Gavin Shan wrote:
>> The config registers in [0, 0x40] is being supported by VFIO. Apart
>> from that, the other config registers should be coverred by PCI or
>> PCIe capability. However, there might have some PCI devices (be2net)
>> who has config registers (0x7c) out of [0, 0x40], and don't have
>> corresponding PCI or PCIe capability. VFIO will return 0x0 on reading
>> those registers and writing is dropped. It caused the be2net driver
>> fails to be loaded because 0x0 returned from its config register 0x7c.
>>
>> The patch changes the behaviour so that those config registers out
>> of [0, 0x40] and don't have corresponding PCI or PCIe capability
>> will be accessed directly.
>
>This basically gives userspace free access to any regions that aren't
>covered by known capabilities. We have no idea what this might expose
>on some devices. I'd like to support be2net, but what's the minimal
>access that it needs? Can we provide 2 or 4 bytes of read-only access
>at offset 0x7c for just that device? Is it always 0x7c? Let's split
>this patch from the series since it's clearly dealing with something
>independent. Thanks,
>
0x7c is just one example. Actually, benet driver also need access other
uncoverred config registers like 0x58/0xf0/0xfc (by capabilities) in orde
to make the device work well. All of those uncoverred config registers
are really business of specific device itself. I think we might not bother
their accessing attributes. So exporting those uncoverred registers to
user space might be the reasonable choice.
If we really want to control the accessing attributes for those uncoverred
registers, we might introduce some mechanism to check the vendor/device ID
and read/write to the uncoverred registers according the specified bits.
All of that requires fully understanding the usage of those uncoverred registers.
Yes, I will split this one from the patchset.
Thanks,
Gavin
>> Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
>> ---
>> drivers/vfio/pci/vfio_pci_config.c | 31 ++++++++++++++++++++-----------
>> 1 files changed, 20 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/vfio/pci/vfio_pci_config.c b/drivers/vfio/pci/vfio_pci_config.c
>> index 964ff22..5ea3afb 100644
>> --- a/drivers/vfio/pci/vfio_pci_config.c
>> +++ b/drivers/vfio/pci/vfio_pci_config.c
>> @@ -1471,18 +1471,27 @@ static ssize_t vfio_config_do_rw(struct vfio_pci_device *vdev, char __user *buf,
>>
>> cap_id = vdev->pci_config_map[*ppos / 4];
>>
>> + /*
>> + * Some PCI device config registers might not be coverred by
>> + * capability and useful. We will enable direct access to
>> + * those registers.
>> + */
>> if (cap_id == PCI_CAP_ID_INVALID) {
>> - if (iswrite)
>> - return ret; /* drop */
>> -
>> - /*
>> - * Per PCI spec 3.0, section 6.1, reads from reserved and
>> - * unimplemented registers return 0
>> - */
>> - if (copy_to_user(buf, &val, count))
>> - return -EFAULT;
>> -
>> - return ret;
>> + if (iswrite) {
>> + if (copy_from_user(&val, buf, count))
>> + return -EFAULT;
>> + ret = vfio_user_config_write(vdev->pdev, (int)(*ppos),
>> + val, count);
>> + return ret ? ret : count;
>> + } else {
>> + ret = vfio_user_config_read(vdev->pdev, (int)(*ppos),
>> + &val, count);
>> + if (ret)
>> + return ret;
>> + if (copy_to_user(buf, &val, count))
>> + return -EFAULT;
>> + return count;
>> + }
>> }
>>
>> /*
>
>
>
^ permalink raw reply
* Re: [PATCH 2/3] VFIO: VFIO_DEVICE_SET_ADDR_MAPPING command
From: Gavin Shan @ 2013-03-16 1:34 UTC (permalink / raw)
To: Alex Williamson; +Cc: aik, linuxppc-dev, Gavin Shan, kvm
In-Reply-To: <1363375740.16793.12.camel@ul30vt.home>
On Fri, Mar 15, 2013 at 01:29:00PM -0600, Alex Williamson wrote:
>On Fri, 2013-03-15 at 15:26 +0800, Gavin Shan wrote:
>> The address (domain/bus/slot/function) of the passed PCI device
>> looks quite different from perspective of host and guest. Some
>> architectures like PPC need to setup the mapping in host. The patch
>> introduces additional VFIO device IOCTL command to address that.
>
>Could you explain further how this will be used? How the device is
>exposed to a guest is entirely a userspace construct, so why does vfio
>need to know or care about this? I had assumed for AER that QEMU would
>do the translation from host to guest address space.
>
The weak IOCTL function (vfio_pci_arch_ioctl) was introduced by previous
patch. The PowerNV platform is going to override it to figure out the
information for EEH core to use. On the other hand, QEMU will runs into
the IOCTL command while opening (creating) one VFIO device.
Though I'm not familiar with AER very much. AER is quite different from
EEH. The EEH functionality implemented in PHB instead of in PCI device
core. So we don't care AER stuff in EEH directly :-)
>> Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
>> ---
>> include/uapi/linux/vfio.h | 16 ++++++++++++++++
>> 1 files changed, 16 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
>> index 6e58d9b..ecc4f38 100644
>> --- a/include/uapi/linux/vfio.h
>> +++ b/include/uapi/linux/vfio.h
>> @@ -289,6 +289,22 @@ struct vfio_irq_set {
>> */
>> #define VFIO_DEVICE_RESET _IO(VFIO_TYPE, VFIO_BASE + 11)
>>
>> +/**
>> + * VFIO_DEVICE_SET_ADDR_MAPPING - _IO(VFIO_TYPE, VFIO_BASE + 12)
>> + *
>> + * The address, which comprised of domain/bus/slot/function looks
>> + * different between host and guest. We need to setup the mapping
>> + * in host for some architectures like PPC so that the passed PCI
>> + * devices could support RTAS smoothly.
>> + */
>> +struct vfio_addr_mapping {
>> + __u64 buid;
>
>What's a buid? Thanks,
>
BUID means "Bus Unit Identifier". BUID is the identifier for specific PHB.
Firmware figures it out and expose to OS through device-tree. For VFIO case,
the QEMU figures it out and expose to guest eventually. It's notable that
the PHB (including buid) figured out by QEMU is virtual and something like
container :-)
>> + __u8 bus;
>> + __u8 slot;
>> + __u8 func;
>> +};
>> +#define VFIO_DEVICE_SET_ADDR_MAPPING _IO(VFIO_TYPE, VFIO_BASE + 12)
>> +
>> /*
>> * The VFIO-PCI bus driver makes use of the following fixed region and
>> * IRQ index mapping. Unimplemented regions return a size of zero.
>
Thanks,
Gavin
^ permalink raw reply
* Re: [PATCH 4/6] powerpc/fsl-booke: Add initial B4420QDS board device tree
From: Kumar Gala @ 2013-03-15 20:31 UTC (permalink / raw)
To: Shaveta Leekha; +Cc: linuxppc-dev
In-Reply-To: <1363334109-21922-4-git-send-email-shaveta@freescale.com>
On Mar 15, 2013, at 2:55 AM, Shaveta Leekha wrote:
> Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
> ---
> arch/powerpc/boot/dts/b4420qds.dts | 168 =
++++++++++++++++++++++++++++++++++++
> 1 files changed, 168 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/b4420qds.dts
If B4420 and B4860 qds are same board, refactor this into a b4qds.dtsi =
file for common board features like NOR, NAND, SPI, SDHC, etc.
- k=
^ permalink raw reply
* Re: [PATCH 3/6] powerpc/fsl-booke: Add initial silicon device tree files for B4420QDS
From: Kumar Gala @ 2013-03-15 20:30 UTC (permalink / raw)
To: Shaveta Leekha; +Cc: Andy Fleming, linuxppc-dev, Zhao Chenhui
In-Reply-To: <1363334109-21922-3-git-send-email-shaveta@freescale.com>
On Mar 15, 2013, at 2:55 AM, Shaveta Leekha wrote:
> Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
> Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> ---
> arch/powerpc/boot/dts/fsl/b4420si-post.dtsi | 151 =
+++++++++++++++++++++++++++
> arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi | 70 ++++++++++++
> 2 files changed, 221 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
> create mode 100644 arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
Similar comments to B4860 dts files.
- k=
^ permalink raw reply
* Re: [PATCH 1/6] powerpc/fsl-booke: Add initial silicon device tree files for B4860QDS
From: Kumar Gala @ 2013-03-15 20:29 UTC (permalink / raw)
To: Shaveta Leekha
Cc: Zhao Chenhui, Minghuan Lian, Tang Yuantian, Andy Fleming,
Ramneek Mehresh, Varun Sethi, linuxppc-dev
In-Reply-To: <1363334109-21922-1-git-send-email-shaveta@freescale.com>
On Mar 15, 2013, at 2:55 AM, Shaveta Leekha wrote:
> Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
> Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com>
> Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
> Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
> Signed-off-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> ---
> arch/powerpc/boot/dts/fsl/b4860si-post.dtsi | 184 =
+++++++++++++++++++++++++++
> arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi | 80 ++++++++++++
> 2 files changed, 264 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
> create mode 100644 arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
* SEC node is missing
* DCSR nodes are missing.
- k
>=20
> diff --git a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi =
b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
> new file mode 100644
> index 0000000..2db68b2
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
> @@ -0,0 +1,184 @@
> +/*
> + * B4860 Silicon/SoC Device Tree Source (post include)
> + *
> + * Copyright 2012 Freescale Semiconductor Inc.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions =
are met:
> + * * Redistributions of source code must retain the above =
copyright
> + * notice, this list of conditions and the following =
disclaimer.
> + * * Redistributions in binary form must reproduce the above =
copyright
> + * notice, this list of conditions and the following disclaimer =
in the
> + * documentation and/or other materials provided with the =
distribution.
> + * * Neither the name of Freescale Semiconductor nor the
> + * names of its contributors may be used to endorse or promote =
products
> + * derived from this software without specific prior written =
permission.
> + *
> + *
> + * ALTERNATIVELY, this software may be distributed under the terms of =
the
> + * GNU General Public License ("GPL") as published by the Free =
Software
> + * Foundation, either version 2 of that License or (at your option) =
any
> + * later version.
> + *
> + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND =
ANY
> + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE =
IMPLIED
> + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE =
ARE
> + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE =
FOR ANY
> + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL =
DAMAGES
> + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR =
SERVICES;
> + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER =
CAUSED AND
> + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, =
OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE =
USE OF THIS
> + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +&ifc {
> + #address-cells =3D <2>;
> + #size-cells =3D <1>;
> + compatible =3D "fsl,ifc", "simple-bus";
> + interrupts =3D <25 2 0 0>;
> +};
> +
> +/* controller at 0x200000 */
> +&pci0 {
> + compatible =3D "fsl,b4860-pcie", "fsl,qoriq-pcie-v2.4";
> + device_type =3D "pci";
> + #size-cells =3D <2>;
> + #address-cells =3D <3>;
> + bus-range =3D <0x0 0xff>;
> + interrupts =3D <20 2 0 0>;
> + pcie@0 {
> + #interrupt-cells =3D <1>;
> + #size-cells =3D <2>;
> + #address-cells =3D <3>;
> + device_type =3D "pci";
> + interrupts =3D <20 2 0 0>;
> + interrupt-map-mask =3D <0xf800 0 0 7>;
> + interrupt-map =3D <
> + /* IDSEL 0x0 */
> + 0000 0 0 1 &mpic 40 1 0 0
> + 0000 0 0 2 &mpic 1 1 0 0
> + 0000 0 0 3 &mpic 2 1 0 0
> + 0000 0 0 4 &mpic 3 1 0 0
> + >;
> + };
> +};
> +
> +&rio {
> + compatible =3D "fsl,srio";
> + interrupts =3D <16 2 1 11>;
> + #address-cells =3D <2>;
> + #size-cells =3D <2>;
> + ranges;
> +
> + port1 {
> + #address-cells =3D <2>;
> + #size-cells =3D <2>;
> + cell-index =3D <1>;
> + };
> +
> + port2 {
> + #address-cells =3D <2>;
> + #size-cells =3D <2>;
> + cell-index =3D <2>;
> + };
> +};
> +
> +&soc {
> + #address-cells =3D <1>;
> + #size-cells =3D <1>;
> + device_type =3D "soc";
> + compatible =3D "simple-bus";
> +
> + soc-sram-error {
> + compatible =3D "fsl,soc-sram-error";
> + interrupts =3D <16 2 1 2>;
> + };
> +
> + corenet-law@0 {
> + compatible =3D "fsl,corenet-law";
> + reg =3D <0x0 0x1000>;
> + fsl,num-laws =3D <32>;
> + };
> +
> + ddr1: memory-controller@8000 {
> + compatible =3D "fsl,qoriq-memory-controller-v4.5", =
"fsl,qoriq-memory-controller";
> + reg =3D <0x8000 0x1000>;
> + interrupts =3D <16 2 1 8>;
> + };
> +
> + ddr2: memory-controller@9000 {
> + compatible =3D =
"fsl,qoriq-memory-controller-v4.5","fsl,qoriq-memory-controller";
> + reg =3D <0x9000 0x1000>;
> + interrupts =3D <16 2 1 9>;
> + };
> +
> + cpc: l3-cache-controller@10000 {
> + compatible =3D "fsl,p5020-l3-cache-controller", =
"fsl,p4080-l3-cache-controller", "cache";
> + reg =3D <0x10000 0x1000
> + 0x11000 0x1000>;
> + interrupts =3D <16 2 1 4
> + 16 2 1 5>;
> + };
> +
> + corenet-cf@18000 {
> + compatible =3D "fsl,corenet-cf";
> + reg =3D <0x18000 0x1000>;
> + interrupts =3D <16 2 1 0>;
> + fsl,ccf-num-csdids =3D <32>;
> + fsl,ccf-num-snoopids =3D <32>;
> + };
> +
> + iommu@20000 {
> + compatible =3D "fsl,pamu-v1.0", "fsl,pamu";
> + reg =3D <0x20000 0x4000>;
> + interrupts =3D <
> + 24 2 0 0
> + 16 2 1 1>;
> + };
> +
> +/include/ "qoriq-mpic.dtsi"
> +
> + guts: global-utilities@e0000 {
> + compatible =3D "fsl,b4860-device-config";
> + reg =3D <0xe0000 0xe00>;
> + fsl,has-rstcr;
> + fsl,liodn-bits =3D <12>;
> + };
> +
> + clockgen: global-utilities@e1000 {
> + compatible =3D "fsl,b4860-clockgen", =
"fsl,qoriq-clockgen-2";
> + reg =3D <0xe1000 0x1000>;
> + };
> +
> + rcpm: global-utilities@e2000 {
> + compatible =3D "fsl,b4860-rcpm", "fsl,qoriq-rcpm-2";
> + reg =3D <0xe2000 0x1000>;
> + };
> +
> +/include/ "qoriq-dma-0.dtsi"
> +/include/ "qoriq-dma-1.dtsi"
> +
> +/include/ "qonverge-usb2-dr-0.dtsi"
> + usb0: usb@210000 {
> + compatible =3D "fsl-usb2-dr-v2.4", "fsl-usb2-dr";
> + };
> +
> +/include/ "qoriq-espi-0.dtsi"
> + spi@110000 {
> + fsl,espi-num-chipselects =3D <4>;
> + };
> +
> +/include/ "qoriq-esdhc-0.dtsi"
> + sdhc@114000 {
> + sdhci,auto-cmd12;
> + };
> +/include/ "qoriq-i2c-0.dtsi"
> +/include/ "qoriq-i2c-1.dtsi"
> +/include/ "qoriq-duart-0.dtsi"
> +/include/ "qoriq-duart-1.dtsi"
> +
> + L2: l2-cache-controller@c20000 {
> + next-level-cache =3D <&cpc>;
should have compatible & reg nodes
> + };
> +};
[ snip ]
- k=
^ permalink raw reply
* Re: [PATCH 2/6] powerpc/fsl-booke: Add initial B4860QDS board device tree
From: Kumar Gala @ 2013-03-15 20:26 UTC (permalink / raw)
To: Shaveta Leekha
Cc: Minghuan Lian, linuxppc-dev, Andy Fleming, Poonam Aggrwal,
Ramneek Mehresh
In-Reply-To: <1363334109-21922-2-git-send-email-shaveta@freescale.com>
On Mar 15, 2013, at 2:55 AM, Shaveta Leekha wrote:
> Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
> Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
> Signed-off-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/boot/dts/b4860qds.dts | 178 =
++++++++++++++++++++++++++++++++++++
> 1 files changed, 178 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/b4860qds.dts
>=20
> diff --git a/arch/powerpc/boot/dts/b4860qds.dts =
b/arch/powerpc/boot/dts/b4860qds.dts
> new file mode 100644
> index 0000000..ae6ac05
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/b4860qds.dts
> @@ -0,0 +1,178 @@
> +/*
> + * B4860DS Device Tree Source
> + *
> + * Copyright 2012 Freescale Semiconductor Inc.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions =
are met:
> + * * Redistributions of source code must retain the above =
copyright
> + * notice, this list of conditions and the following =
disclaimer.
> + * * Redistributions in binary form must reproduce the above =
copyright
> + * notice, this list of conditions and the following disclaimer =
in the
> + * documentation and/or other materials provided with the =
distribution.
> + * * Neither the name of Freescale Semiconductor nor the
> + * names of its contributors may be used to endorse or promote =
products
> + * derived from this software without specific prior written =
permission.
> + *
> + *
> + * ALTERNATIVELY, this software may be distributed under the terms of =
the
> + * GNU General Public License ("GPL") as published by the Free =
Software
> + * Foundation, either version 2 of that License or (at your option) =
any
> + * later version.
> + *
> + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND =
ANY
> + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE =
IMPLIED
> + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE =
ARE
> + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE =
FOR ANY
> + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL =
DAMAGES
> + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR =
SERVICES;
> + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER =
CAUSED AND
> + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, =
OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE =
USE OF THIS
> + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +/include/ "fsl/b4860si-pre.dtsi"
> +
> +/ {
> + model =3D "fsl,B4860QDS";
> + compatible =3D "fsl,B4860QDS";
> + #address-cells =3D <2>;
> + #size-cells =3D <2>;
> + interrupt-parent =3D <&mpic>;
> +
> + ifc: localbus@ffe124000 {
> + reg =3D <0xf 0xfe124000 0 0x2000>;
> + ranges =3D <0 0 0xf 0xe8000000 0x08000000
> + 2 0 0xf 0xff800000 0x00010000
> + 3 0 0xf 0xffdf0000 0x00008000>;
> +
> + nor@0,0 {
> + #address-cells =3D <1>;
> + #size-cells =3D <1>;
> + compatible =3D "cfi-flash";
> + reg =3D <0x0 0x0 0x8000000>;
> + bank-width =3D <2>;
> + device-width =3D <1>;
> + };
> +
> + nand@2,0 {
> + #address-cells =3D <1>;
> + #size-cells =3D <1>;
> + compatible =3D "fsl,ifc-nand";
> + reg =3D <0x2 0x0 0x10000>;
> +
> + partition@0 {
> + /* This location must not be altered */
> + /* 1MB for u-boot Bootloader Image */
> + reg =3D <0x0 0x00100000>;
> + label =3D "NAND U-Boot Image";
> + read-only;
> + };
> +
> + partition@100000 {
> + /* 1MB for DTB Image */
> + reg =3D <0x00100000 0x00100000>;
> + label =3D "NAND DTB Image";
> + };
> +
> + partition@200000 {
> + /* 10MB for Linux Kernel Image */
> + reg =3D <0x00200000 0x00A00000>;
> + label =3D "NAND Linux Kernel Image";
> + };
> +
> + partition@c00000 {
> + /* 500MB for Root file System Image */
> + reg =3D <0x00c00000 0x1F400000>;
> + label =3D "NAND RFS Image";
> + };
> + };
> +
> + board-control@3,0 {
> + compatible =3D "fsl,b4860qds-fpga", =
"fsl,fpga-qixis";
> + reg =3D <3 0 0x300>;
> + };
> + };
> +
dscr nodes are missing and should be included
> + memory {
> + device_type =3D "memory";
> + };
> +
> + soc: soc@ffe000000 {
> + ranges =3D <0x00000000 0xf 0xfe000000 0x1000000>;
> + reg =3D <0xf 0xfe000000 0 0x00001000>;
> + spi@110000 {
> + flash@0 {
> + #address-cells =3D <1>;
> + #size-cells =3D <1>;
> + compatible =3D "sst,sst25wf040";
> + reg =3D <0>;
> + spi-max-frequency =3D <40000000>; /* =
input clock */
> + };
> + };
> +
> + sdhc@114000 {
> + status =3D "disabled";
> + };
> +
> + i2c@118000 {
> + eeprom@50 {
> + compatible =3D "at24,24c64";
> + reg =3D <0x50>;
> + };
> + eeprom@51 {
> + compatible =3D "at24,24c256";
> + reg =3D <0x51>;
> + };
> + eeprom@53 {
> + compatible =3D "at24,24c256";
> + reg =3D <0x53>;
> + };
> + eeprom@57 {
> + compatible =3D "at24,24c256";
> + reg =3D <0x57>;
> + };
> + rtc@68 {
> + compatible =3D "dallas,ds3232";
> + reg =3D <0x68>;
> + interrupts =3D <0x1 0x1 0 0>;
there is no IRQ for RTC on the board.
> + };
> + };
> +
> + usb@210000 {
> + dr_mode =3D "host";
> + phy_type =3D "ulpi";
> + };
> +
> + };
> +
> + pci0: pcie@ffe200000 {
> + reg =3D <0xf 0xfe200000 0 0x10000>;
> + ranges =3D <0x02000000 0 0xe0000000 0xc 0x00000000 0x0 =
0x20000000
> + 0x01000000 0 0x00000000 0xf 0xf8000000 0x0 =
0x00010000>;
> + pcie@0 {
> + ranges =3D <0x02000000 0 0xe0000000
> + 0x02000000 0 0xe0000000
> + 0 0x20000000
> +
> + 0x01000000 0 0x00000000
> + 0x01000000 0 0x00000000
> + 0 0x00010000>;
> + };
> + };
> +
> + rio: rapidio@ffe0c0000 {
> + reg =3D <0xf 0xfe0c0000 0 0x11000>;
> +
> + port1 {
> + ranges =3D <0 0 0xc 0x20000000 0 0x10000000>;
> + };
> + port2 {
> + ranges =3D <0 0 0xc 0x30000000 0 0x10000000>;
> + };
> + };
> +
> +};
> +
> +/include/ "fsl/b4860si-post.dtsi"
> --=20
> 1.7.6.GIT
>=20
^ permalink raw reply
* Re: [PATCH 3/3] VFIO: Direct access config reg without capability
From: Alex Williamson @ 2013-03-15 19:41 UTC (permalink / raw)
To: Gavin Shan; +Cc: aik, linuxppc-dev, kvm
In-Reply-To: <1363332390-12754-4-git-send-email-shangw@linux.vnet.ibm.com>
On Fri, 2013-03-15 at 15:26 +0800, Gavin Shan wrote:
> The config registers in [0, 0x40] is being supported by VFIO. Apart
> from that, the other config registers should be coverred by PCI or
> PCIe capability. However, there might have some PCI devices (be2net)
> who has config registers (0x7c) out of [0, 0x40], and don't have
> corresponding PCI or PCIe capability. VFIO will return 0x0 on reading
> those registers and writing is dropped. It caused the be2net driver
> fails to be loaded because 0x0 returned from its config register 0x7c.
>
> The patch changes the behaviour so that those config registers out
> of [0, 0x40] and don't have corresponding PCI or PCIe capability
> will be accessed directly.
This basically gives userspace free access to any regions that aren't
covered by known capabilities. We have no idea what this might expose
on some devices. I'd like to support be2net, but what's the minimal
access that it needs? Can we provide 2 or 4 bytes of read-only access
at offset 0x7c for just that device? Is it always 0x7c? Let's split
this patch from the series since it's clearly dealing with something
independent. Thanks,
Alex
> Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
> ---
> drivers/vfio/pci/vfio_pci_config.c | 31 ++++++++++++++++++++-----------
> 1 files changed, 20 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/vfio/pci/vfio_pci_config.c b/drivers/vfio/pci/vfio_pci_config.c
> index 964ff22..5ea3afb 100644
> --- a/drivers/vfio/pci/vfio_pci_config.c
> +++ b/drivers/vfio/pci/vfio_pci_config.c
> @@ -1471,18 +1471,27 @@ static ssize_t vfio_config_do_rw(struct vfio_pci_device *vdev, char __user *buf,
>
> cap_id = vdev->pci_config_map[*ppos / 4];
>
> + /*
> + * Some PCI device config registers might not be coverred by
> + * capability and useful. We will enable direct access to
> + * those registers.
> + */
> if (cap_id == PCI_CAP_ID_INVALID) {
> - if (iswrite)
> - return ret; /* drop */
> -
> - /*
> - * Per PCI spec 3.0, section 6.1, reads from reserved and
> - * unimplemented registers return 0
> - */
> - if (copy_to_user(buf, &val, count))
> - return -EFAULT;
> -
> - return ret;
> + if (iswrite) {
> + if (copy_from_user(&val, buf, count))
> + return -EFAULT;
> + ret = vfio_user_config_write(vdev->pdev, (int)(*ppos),
> + val, count);
> + return ret ? ret : count;
> + } else {
> + ret = vfio_user_config_read(vdev->pdev, (int)(*ppos),
> + &val, count);
> + if (ret)
> + return ret;
> + if (copy_to_user(buf, &val, count))
> + return -EFAULT;
> + return count;
> + }
> }
>
> /*
^ permalink raw reply
* Re: [PATCH 2/3] VFIO: VFIO_DEVICE_SET_ADDR_MAPPING command
From: Alex Williamson @ 2013-03-15 19:29 UTC (permalink / raw)
To: Gavin Shan; +Cc: aik, linuxppc-dev, kvm
In-Reply-To: <1363332390-12754-3-git-send-email-shangw@linux.vnet.ibm.com>
On Fri, 2013-03-15 at 15:26 +0800, Gavin Shan wrote:
> The address (domain/bus/slot/function) of the passed PCI device
> looks quite different from perspective of host and guest. Some
> architectures like PPC need to setup the mapping in host. The patch
> introduces additional VFIO device IOCTL command to address that.
Could you explain further how this will be used? How the device is
exposed to a guest is entirely a userspace construct, so why does vfio
need to know or care about this? I had assumed for AER that QEMU would
do the translation from host to guest address space.
> Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
> ---
> include/uapi/linux/vfio.h | 16 ++++++++++++++++
> 1 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index 6e58d9b..ecc4f38 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -289,6 +289,22 @@ struct vfio_irq_set {
> */
> #define VFIO_DEVICE_RESET _IO(VFIO_TYPE, VFIO_BASE + 11)
>
> +/**
> + * VFIO_DEVICE_SET_ADDR_MAPPING - _IO(VFIO_TYPE, VFIO_BASE + 12)
> + *
> + * The address, which comprised of domain/bus/slot/function looks
> + * different between host and guest. We need to setup the mapping
> + * in host for some architectures like PPC so that the passed PCI
> + * devices could support RTAS smoothly.
> + */
> +struct vfio_addr_mapping {
> + __u64 buid;
What's a buid? Thanks,
Alex
> + __u8 bus;
> + __u8 slot;
> + __u8 func;
> +};
> +#define VFIO_DEVICE_SET_ADDR_MAPPING _IO(VFIO_TYPE, VFIO_BASE + 12)
> +
> /*
> * The VFIO-PCI bus driver makes use of the following fixed region and
> * IRQ index mapping. Unimplemented regions return a size of zero.
^ permalink raw reply
* Re: [PATCH 3/4 v2] net: mvmdio: enhance driver to support SMI error/done interrupts
From: Russell King - ARM Linux @ 2013-03-15 18:05 UTC (permalink / raw)
To: Florian Fainelli
Cc: Thomas Petazzoni, Andrew Lunn, Jason Cooper, linux-doc,
devicetree-discuss, linux-kernel, Rob Herring, netdev,
Paul Mackerras, linux-arm-kernel, Rob Landley, Greg Kroah-Hartman,
linuxppc-dev, davem, Lennert Buytenhek
In-Reply-To: <1363284515-9865-4-git-send-email-florian@openwrt.org>
On Thu, Mar 14, 2013 at 07:08:34PM +0100, Florian Fainelli wrote:
> + if (dev->err_interrupt == NO_IRQ) {
...
> + init_waitqueue_head(&dev->smi_busy_wait);
> +
> + dev->err_interrupt = platform_get_irq(pdev, 0);
> + if (dev->err_interrupt != -ENXIO) {
...
> + } else
> + dev->err_interrupt = NO_IRQ;
FYI, NO_IRQ is not supposed to be used anymore (we're supposed to be
removing it). platform_get_irq() returns negative numbers for failure,
so why not test for < 0 in both the above tests, or maybe <= 0 (as
IRQ0 is also not supposed to be valid.)?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox