* Re: [PATCH 1/1] For MPC831x the bus probing function needs the fixup to assign addresses to the PCI devices as it was for MPC85xx and MPC86xx. The fixup of the bridge vendor and device ID should be done early in PCI probing. Else the bridge is not detected as FIXUP_HEADER is called too late.
From: Kumar Gala @ 2013-03-18 14:58 UTC (permalink / raw)
To: Sergey Gerasimov
Cc: linuxppc-dev, linux-kernel, Paul Mackerras, Timur Tabi,
Jia Hongtao
In-Reply-To: <1363614636-1142-1-git-send-email-Sergey.Gerasimov@astrosoft-development.com>
On Mar 18, 2013, at 8:50 AM, Sergey Gerasimov wrote:
> Signed-off-by: Sergey Gerasimov =
<Sergey.Gerasimov@astrosoft-development.com>
> ---
> arch/powerpc/sysdev/fsl_pci.c | 71 =
+++++++++++++++++++++----------------------
> 1 file changed, 34 insertions(+), 37 deletions(-)
>=20
Can you repost with subject and commit log fixed? It appears your =
subject & commit message are merged.
> diff --git a/arch/powerpc/sysdev/fsl_pci.c =
b/arch/powerpc/sysdev/fsl_pci.c
> index 682084d..2e41a68 100644
> --- a/arch/powerpc/sysdev/fsl_pci.c
> +++ b/arch/powerpc/sysdev/fsl_pci.c
> @@ -64,6 +64,34 @@ static int __init fsl_pcie_check_link(struct =
pci_controller *hose)
> return 0;
> }
>=20
> +void fsl_pcibios_fixup_bus(struct pci_bus *bus)
> +{
> + struct pci_controller *hose =3D (struct pci_controller *) =
bus->sysdata;
> + int i;
> +
> +
> + if ((bus->parent =3D=3D hose->bus)
> + && ((fsl_pcie_bus_fixup
> + && pci_bus_find_capability(bus, 0, =
PCI_CAP_ID_EXP))
> + || (hose->indirect_type
> + & =
PPC_INDIRECT_TYPE_NO_PCIE_LINK))) {
> + for (i =3D 0; i < 4; ++i) {
> + struct resource *res =3D bus->resource[i];
> + struct resource *par =3D =
bus->parent->resource[i];
> + if (res) {
> + res->start =3D 0;
> + res->end =3D 0;
> + res->flags =3D 0;
> + }
> + if (res && par) {
> + res->start =3D par->start;
> + res->end =3D par->end;
> + res->flags =3D par->flags;
> + }
> + }
> + }
> +}
> +
> #if defined(CONFIG_FSL_SOC_BOOKE) || defined(CONFIG_PPC_86xx)
>=20
> #define MAX_PHYS_ADDR_BITS 40
> @@ -384,42 +412,6 @@ static void __init setup_pci_cmd(struct =
pci_controller *hose)
> }
> }
>=20
> -void fsl_pcibios_fixup_bus(struct pci_bus *bus)
> -{
> - struct pci_controller *hose =3D pci_bus_to_host(bus);
> - int i, is_pcie =3D 0, no_link;
> -
> - /* The root complex bridge comes up with bogus resources,
> - * we copy the PHB ones in.
> - *
> - * With the current generic PCI code, the PHB bus no longer
> - * has bus->resource[0..4] set, so things are a bit more
> - * tricky.
> - */
> -
> - if (fsl_pcie_bus_fixup)
> - is_pcie =3D early_find_capability(hose, 0, 0, =
PCI_CAP_ID_EXP);
> - no_link =3D !!(hose->indirect_type & =
PPC_INDIRECT_TYPE_NO_PCIE_LINK);
> -
> - if (bus->parent =3D=3D hose->bus && (is_pcie || no_link)) {
> - for (i =3D 0; i < PCI_BRIDGE_RESOURCE_NUM; ++i) {
> - struct resource *res =3D bus->resource[i];
> - struct resource *par;
> -
> - if (!res)
> - continue;
> - if (i =3D=3D 0)
> - par =3D &hose->io_resource;
> - else if (i < 4)
> - par =3D &hose->mem_resources[i-1];
> - else par =3D NULL;
> -
> - res->start =3D par ? par->start : 0;
> - res->end =3D par ? par->end : 0;
> - res->flags =3D par ? par->flags : 0;
> - }
> - }
> -}
>=20
> int __init fsl_add_bridge(struct platform_device *pdev, int =
is_primary)
> {
> @@ -515,7 +507,8 @@ no_bridge:
> }
> #endif /* CONFIG_FSL_SOC_BOOKE || CONFIG_PPC_86xx */
>=20
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID, =
quirk_fsl_pcie_header);
> +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID,
> + quirk_fsl_pcie_header);
why does this need to be done EARLY?
> #if defined(CONFIG_PPC_83xx) || defined(CONFIG_PPC_MPC512x)
> struct mpc83xx_pcie_priv {
> @@ -813,6 +806,10 @@ u64 fsl_pci_immrbar_base(struct pci_controller =
*hose)
> }
> #endif
>=20
> +
> +
> +
> +
don't add extra whitespace
> #if defined(CONFIG_FSL_SOC_BOOKE) || defined(CONFIG_PPC_86xx)
> if (!is_mpc83xx_pci) {
> u32 base;
> --=20
> 1.7.11.7
^ permalink raw reply
* Re: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu implementation.
From: Kumar Gala @ 2013-03-18 14:59 UTC (permalink / raw)
To: Sethi Varun-B16395
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: <C5ECD7A89D1DC44195F34B25E172658D40ABB4@039-SN2MPN1-013.039d.mgd.msft.net>
On Mar 17, 2013, at 10:48 AM, Sethi Varun-B16395 wrote:
>>>=20
>>> + 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.
Let's see with the SoC arch's if something like =
"fsl,qoriq-device-config-2.0" makes sense for T4 & B4.
- k=
^ permalink raw reply
* Re: [PATCH 2/6] powerpc/fsl-booke: Add initial B4860QDS board device tree
From: Kumar Gala @ 2013-03-18 15:02 UTC (permalink / raw)
To: Leekha Shaveta-B20052
Cc: Fleming Andy-AFLEMING, Aggrwal Poonam-B10812,
linuxppc-dev@lists.ozlabs.org, Lian Minghuan-B31939,
Mehresh Ramneek-B31383
In-Reply-To: <E12D2F89F87F4A49B0320A4C2DE7E749144AA5@039-SN2MPN1-011.039d.mgd.msft.net>
On Mar 18, 2013, at 1:31 AM, Leekha Shaveta-B20052 wrote:
>=20
>=20
> -----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-AFLEMING; Aggrwal Poonam-B10812; Mehresh Ramneek-B31383
> Subject: Re: [PATCH 2/6] powerpc/fsl-booke: Add initial B4860QDS board =
device tree
>=20
>=20
> On Mar 15, 2013, at 2:55 AM, Shaveta Leekha wrote:
>=20
>> 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 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=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>;
>> + };
>> + };
>> +
>=20
> 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 initial device trees. Dcsr may be added later as updation. =
What do you say? =20
I'll add them to T4, but if you look at the internal FSL SDK tree you =
will see they've been added for T4 & B4.
>=20
>=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>;
>=20
> there is no IRQ for RTC on the board.
> [SL] will remove it.=20
>=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
>=20
>=20
> Regards,
> Shaveta
>=20
>=20
^ permalink raw reply
* Re: [PATCH 1/6] powerpc/fsl-booke: Add initial silicon device tree files for B4860QDS
From: Kumar Gala @ 2013-03-18 15:03 UTC (permalink / raw)
To: Leekha Shaveta-B20052
Cc: Zhao Chenhui-B35336, Mehresh Ramneek-B31383, Timur Tabi,
Lian Minghuan-B31939, Tang Yuantian-B29983, Fleming Andy-AFLEMING,
Sethi Varun-B16395, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <E12D2F89F87F4A49B0320A4C2DE7E749144B3C@039-SN2MPN1-011.039d.mgd.msft.net>
On Mar 18, 2013, at 2:41 AM, Leekha Shaveta-B20052 wrote:
>=20
>=20
> -----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-B31939; Tang Yuantian-B29983; Fleming Andy-AFLEMING; Mehresh =
Ramneek-B31383; Sethi Varun-B16395
> Subject: Re: [PATCH 1/6] powerpc/fsl-booke: Add initial silicon device =
tree files for B4860QDS
>=20
> On Fri, Mar 15, 2013 at 2:55 AM, Shaveta Leekha =
<shaveta@freescale.com> wrote:
>=20
>=20
>> + iommu@20000 {
>> + compatible =3D "fsl,pamu-v1.0", "fsl,pamu";
>> + reg =3D <0x20000 0x4000>;
>> + interrupts =3D <
>> + 24 2 0 0
>> + 16 2 1 1>;
>> + };
>=20
> 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 =
support in various devices both for T4 and B4.
> Kumar can you please suggest?
I can help with the B4 topology as its reasonable well described, I've =
been working on trying to get the info to finish T4.
- k=
^ permalink raw reply
* [PATCH] powerpc/fsl-booke: Update T4240 device config node in device
From: Kumar Gala @ 2013-03-18 19:10 UTC (permalink / raw)
To: linuxppc-dev
As the T4240 is based on corenet chassis v2.0 spec we update the global
utilities (GUTS) device config compatiable to reflect this.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
index 2b17699..1d72926 100644
--- a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
@@ -357,7 +357,7 @@
/include/ "qoriq-mpic.dtsi"
guts: global-utilities@e0000 {
- compatible = "fsl,t4240-device-config";
+ compatible = "fsl,t4240-device-config", "fsl,qoriq-device-config-2.0";
reg = <0xe0000 0xe00>;
fsl,has-rstcr;
fsl,liodn-bits = <12>;
--
1.7.9.7
^ permalink raw reply related
* [PATCH 2/2] powerpc/fsl-booke: Update DCSR EPU device tree entries
From: Kumar Gala @ 2013-03-18 19:11 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stephen George
In-Reply-To: <1363633870-3894-1-git-send-email-galak@kernel.crashing.org>
From: Stephen George <Stephen.George@freescale.com>
Identifies the epu as compatible with Chassis v1 Debug IP.
Signed-off-by: Stephen George <Stephen.George@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi b/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
index 69ac1ac..dc6cc5a 100644
--- a/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
@@ -155,7 +155,7 @@
compatible = "fsl,dcsr", "simple-bus";
dcsr-epu@0 {
- compatible = "fsl,dcsr-epu";
+ compatible = "fsl,p2041-dcsr-epu", "fsl,dcsr-epu";
interrupts = <52 2 0 0
84 2 0 0
85 2 0 0>;
diff --git a/arch/powerpc/boot/dts/fsl/p3041si-post.dtsi b/arch/powerpc/boot/dts/fsl/p3041si-post.dtsi
index 9b5a81a..3fa1e22 100644
--- a/arch/powerpc/boot/dts/fsl/p3041si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p3041si-post.dtsi
@@ -182,7 +182,7 @@
compatible = "fsl,dcsr", "simple-bus";
dcsr-epu@0 {
- compatible = "fsl,dcsr-epu";
+ compatible = "fsl,p3041-dcsr-epu", "fsl,dcsr-epu";
interrupts = <52 2 0 0
84 2 0 0
85 2 0 0>;
diff --git a/arch/powerpc/boot/dts/fsl/p4080si-post.dtsi b/arch/powerpc/boot/dts/fsl/p4080si-post.dtsi
index 19859ad..34769a7 100644
--- a/arch/powerpc/boot/dts/fsl/p4080si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p4080si-post.dtsi
@@ -156,7 +156,7 @@
compatible = "fsl,dcsr", "simple-bus";
dcsr-epu@0 {
- compatible = "fsl,dcsr-epu";
+ compatible = "fsl,p4080-dcsr-epu", "fsl,dcsr-epu";
interrupts = <52 2 0 0
84 2 0 0
85 2 0 0>;
diff --git a/arch/powerpc/boot/dts/fsl/p5020si-post.dtsi b/arch/powerpc/boot/dts/fsl/p5020si-post.dtsi
index 9ea77c3..bc3ae5a 100644
--- a/arch/powerpc/boot/dts/fsl/p5020si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p5020si-post.dtsi
@@ -184,7 +184,7 @@
compatible = "fsl,dcsr", "simple-bus";
dcsr-epu@0 {
- compatible = "fsl,dcsr-epu";
+ compatible = "fsl,p5020-dcsr-epu", "fsl,dcsr-epu";
interrupts = <52 2 0 0
84 2 0 0
85 2 0 0>;
diff --git a/arch/powerpc/boot/dts/fsl/p5040si-post.dtsi b/arch/powerpc/boot/dts/fsl/p5040si-post.dtsi
index 97f8c26..a91897f 100644
--- a/arch/powerpc/boot/dts/fsl/p5040si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p5040si-post.dtsi
@@ -129,7 +129,7 @@
compatible = "fsl,dcsr", "simple-bus";
dcsr-epu@0 {
- compatible = "fsl,dcsr-epu";
+ compatible = "fsl,p5040-dcsr-epu", "fsl,dcsr-epu";
interrupts = <52 2 0 0
84 2 0 0
85 2 0 0>;
--
1.7.9.7
^ permalink raw reply related
* [PATCH 1/2] powerpc/fsl-booke: Added device tree DCSR entries for
From: Kumar Gala @ 2013-03-18 19:11 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stephen George
From: Stephen George <Stephen.George@freescale.com>
Signed-off-by: Stephen George <Stephen.George@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 131 +++++++++++++++++++++++++++
arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi | 25 ++---
arch/powerpc/boot/dts/t4240qds.dts | 4 +
3 files changed, 148 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
index 376b958..2b17699 100644
--- a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
@@ -159,6 +159,137 @@
};
};
+&dcsr {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,dcsr", "simple-bus";
+
+ dcsr-epu@0 {
+ compatible = "fsl,t4240-dcsr-epu", "fsl,dcsr-epu";
+ interrupts = <52 2 0 0
+ 84 2 0 0
+ 85 2 0 0
+ 94 2 0 0
+ 95 2 0 0>;
+ reg = <0x0 0x1000>;
+ };
+ dcsr-npc {
+ compatible = "fsl,t4240-dcsr-cnpc", "fsl,dcsr-cnpc";
+ reg = <0x1000 0x1000 0x1002000 0x10000>;
+ };
+ dcsr-nxc@2000 {
+ compatible = "fsl,dcsr-nxc";
+ reg = <0x2000 0x1000>;
+ };
+ dcsr-corenet {
+ compatible = "fsl,dcsr-corenet";
+ reg = <0x8000 0x1000 0x1A000 0x1000>;
+ };
+ dcsr-dpaa@9000 {
+ compatible = "fsl,t4240-dcsr-dpaa", "fsl,dcsr-dpaa";
+ reg = <0x9000 0x1000>;
+ };
+ dcsr-ocn@11000 {
+ compatible = "fsl,t4240-dcsr-ocn", "fsl,dcsr-ocn";
+ reg = <0x11000 0x1000>;
+ };
+ dcsr-ddr@12000 {
+ compatible = "fsl,dcsr-ddr";
+ dev-handle = <&ddr1>;
+ reg = <0x12000 0x1000>;
+ };
+ dcsr-ddr@13000 {
+ compatible = "fsl,dcsr-ddr";
+ dev-handle = <&ddr2>;
+ reg = <0x13000 0x1000>;
+ };
+ dcsr-ddr@14000 {
+ compatible = "fsl,dcsr-ddr";
+ dev-handle = <&ddr3>;
+ reg = <0x14000 0x1000>;
+ };
+ dcsr-nal@18000 {
+ compatible = "fsl,t4240-dcsr-nal", "fsl,dcsr-nal";
+ reg = <0x18000 0x1000>;
+ };
+ dcsr-rcpm@22000 {
+ compatible = "fsl,t4240-dcsr-rcpm", "fsl,dcsr-rcpm";
+ reg = <0x22000 0x1000>;
+ };
+ dcsr-snpc@30000 {
+ compatible = "fsl,t4240-dcsr-snpc", "fsl,dcsr-snpc";
+ reg = <0x30000 0x1000 0x1022000 0x10000>;
+ };
+ dcsr-snpc@31000 {
+ compatible = "fsl,t4240-dcsr-snpc", "fsl,dcsr-snpc";
+ reg = <0x31000 0x1000 0x1042000 0x10000>;
+ };
+ dcsr-snpc@32000 {
+ compatible = "fsl,t4240-dcsr-snpc", "fsl,dcsr-snpc";
+ reg = <0x32000 0x1000 0x1062000 0x10000>;
+ };
+ dcsr-cpu-sb-proxy@100000 {
+ compatible = "fsl,dcsr-e6500-sb-proxy", "fsl,dcsr-cpu-sb-proxy";
+ cpu-handle = <&cpu0>;
+ reg = <0x100000 0x1000 0x101000 0x1000>;
+ };
+ dcsr-cpu-sb-proxy@108000 {
+ compatible = "fsl,dcsr-e6500-sb-proxy", "fsl,dcsr-cpu-sb-proxy";
+ cpu-handle = <&cpu1>;
+ reg = <0x108000 0x1000 0x109000 0x1000>;
+ };
+ dcsr-cpu-sb-proxy@110000 {
+ compatible = "fsl,dcsr-e6500-sb-proxy", "fsl,dcsr-cpu-sb-proxy";
+ cpu-handle = <&cpu2>;
+ reg = <0x110000 0x1000 0x111000 0x1000>;
+ };
+ dcsr-cpu-sb-proxy@118000 {
+ compatible = "fsl,dcsr-e6500-sb-proxy", "fsl,dcsr-cpu-sb-proxy";
+ cpu-handle = <&cpu3>;
+ reg = <0x118000 0x1000 0x119000 0x1000>;
+ };
+ dcsr-cpu-sb-proxy@120000 {
+ compatible = "fsl,dcsr-e6500-sb-proxy", "fsl,dcsr-cpu-sb-proxy";
+ cpu-handle = <&cpu4>;
+ reg = <0x120000 0x1000 0x121000 0x1000>;
+ };
+ dcsr-cpu-sb-proxy@128000 {
+ compatible = "fsl,dcsr-e6500-sb-proxy", "fsl,dcsr-cpu-sb-proxy";
+ cpu-handle = <&cpu5>;
+ reg = <0x128000 0x1000 0x129000 0x1000>;
+ };
+ dcsr-cpu-sb-proxy@130000 {
+ compatible = "fsl,dcsr-e6500-sb-proxy", "fsl,dcsr-cpu-sb-proxy";
+ cpu-handle = <&cpu6>;
+ reg = <0x130000 0x1000 0x131000 0x1000>;
+ };
+ dcsr-cpu-sb-proxy@138000 {
+ compatible = "fsl,dcsr-e6500-sb-proxy", "fsl,dcsr-cpu-sb-proxy";
+ cpu-handle = <&cpu7>;
+ reg = <0x138000 0x1000 0x139000 0x1000>;
+ };
+ dcsr-cpu-sb-proxy@140000 {
+ compatible = "fsl,dcsr-e6500-sb-proxy", "fsl,dcsr-cpu-sb-proxy";
+ cpu-handle = <&cpu8>;
+ reg = <0x140000 0x1000 0x141000 0x1000>;
+ };
+ dcsr-cpu-sb-proxy@148000 {
+ compatible = "fsl,dcsr-e6500-sb-proxy", "fsl,dcsr-cpu-sb-proxy";
+ cpu-handle = <&cpu9>;
+ reg = <0x148000 0x1000 0x149000 0x1000>;
+ };
+ dcsr-cpu-sb-proxy@150000 {
+ compatible = "fsl,dcsr-e6500-sb-proxy", "fsl,dcsr-cpu-sb-proxy";
+ cpu-handle = <&cpu10>;
+ reg = <0x150000 0x1000 0x151000 0x1000>;
+ };
+ dcsr-cpu-sb-proxy@158000 {
+ compatible = "fsl,dcsr-e6500-sb-proxy", "fsl,dcsr-cpu-sb-proxy";
+ cpu-handle = <&cpu11>;
+ reg = <0x158000 0x1000 0x159000 0x1000>;
+ };
+};
+
&soc {
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi b/arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi
index 12af298..9b39a43 100644
--- a/arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi
@@ -44,6 +44,7 @@
aliases {
ccsr = &soc;
+ dcsr = &dcsr;
serial0 = &serial0;
serial1 = &serial1;
@@ -63,62 +64,62 @@
#address-cells = <1>;
#size-cells = <0>;
- PowerPC,e6500@0 {
+ cpu0: PowerPC,e6500@0 {
device_type = "cpu";
reg = <0 1>;
next-level-cache = <&L2_1>;
};
- PowerPC,e6500@1 {
+ cpu1: PowerPC,e6500@1 {
device_type = "cpu";
reg = <2 3>;
next-level-cache = <&L2_1>;
};
- PowerPC,e6500@2 {
+ cpu2: PowerPC,e6500@2 {
device_type = "cpu";
reg = <4 5>;
next-level-cache = <&L2_1>;
};
- PowerPC,e6500@3 {
+ cpu3: PowerPC,e6500@3 {
device_type = "cpu";
reg = <6 7>;
next-level-cache = <&L2_1>;
};
- PowerPC,e6500@4 {
+ cpu4: PowerPC,e6500@4 {
device_type = "cpu";
reg = <8 9>;
next-level-cache = <&L2_2>;
};
- PowerPC,e6500@5 {
+ cpu5: PowerPC,e6500@5 {
device_type = "cpu";
reg = <10 11>;
next-level-cache = <&L2_2>;
};
- PowerPC,e6500@6 {
+ cpu6: PowerPC,e6500@6 {
device_type = "cpu";
reg = <12 13>;
next-level-cache = <&L2_2>;
};
- PowerPC,e6500@7 {
+ cpu7: PowerPC,e6500@7 {
device_type = "cpu";
reg = <14 15>;
next-level-cache = <&L2_2>;
};
- PowerPC,e6500@8 {
+ cpu8: PowerPC,e6500@8 {
device_type = "cpu";
reg = <16 17>;
next-level-cache = <&L2_3>;
};
- PowerPC,e6500@9 {
+ cpu9: PowerPC,e6500@9 {
device_type = "cpu";
reg = <18 19>;
next-level-cache = <&L2_3>;
};
- PowerPC,e6500@10 {
+ cpu10: PowerPC,e6500@10 {
device_type = "cpu";
reg = <20 21>;
next-level-cache = <&L2_3>;
};
- PowerPC,e6500@11 {
+ cpu11: PowerPC,e6500@11 {
device_type = "cpu";
reg = <22 23>;
next-level-cache = <&L2_3>;
diff --git a/arch/powerpc/boot/dts/t4240qds.dts b/arch/powerpc/boot/dts/t4240qds.dts
index 83b479f..0555976 100644
--- a/arch/powerpc/boot/dts/t4240qds.dts
+++ b/arch/powerpc/boot/dts/t4240qds.dts
@@ -100,6 +100,10 @@
device_type = "memory";
};
+ dcsr: dcsr@f00000000 {
+ ranges = <0x00000000 0xf 0x00000000 0x01072000>;
+ };
+
soc: soc@ffe000000 {
ranges = <0x00000000 0xf 0xfe000000 0x1000000>;
reg = <0xf 0xfe000000 0 0x00001000>;
--
1.7.9.7
^ permalink raw reply related
* Re: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu implementation.
From: Kumar Gala @ 2013-03-18 19:12 UTC (permalink / raw)
To: Sethi Varun-B16395
Cc: Wood Scott-B07421, iommu@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Yoder Stuart-B08248
In-Reply-To: <CCCE947A-1C24-40C2-9341-BBF3F5C00D98@kernel.crashing.org>
On Mar 18, 2013, at 9:59 AM, Kumar Gala wrote:
>=20
> On Mar 17, 2013, at 10:48 AM, Sethi Varun-B16395 wrote:
>=20
>>>>=20
>>>> + 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.
>=20
> Let's see with the SoC arch's if something like =
"fsl,qoriq-device-config-2.0" makes sense for T4 & B4.
Based on discuss, I've sent patch for T4 dts to use =
"fsl,qoriq-device-config-2.0", so please update PAMU code to use that =
string.
- k
^ permalink raw reply
* Re: [PATCH 1/1] Add a new platform tree for ib8315. Also add the DTS and the defconfig for that board.
From: Kumar Gala @ 2013-03-18 20:18 UTC (permalink / raw)
To: Sergey Gerasimov; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <1363614452-1109-1-git-send-email-Sergey.Gerasimov@astrosoft-development.com>
On Mar 18, 2013, at 8:47 AM, Sergey Gerasimov wrote:
> Signed-off-by: Sergey Gerasimov =
<Sergey.Gerasimov@astrosoft-development.com>
> ---
> arch/powerpc/boot/dts/ib8315.dts | 490 +++++++
> arch/powerpc/configs/83xx/ib8315_defconfig | 2121 =
++++++++++++++++++++++++++++
> arch/powerpc/platforms/83xx/Kconfig | 7 +
> arch/powerpc/platforms/83xx/Makefile | 1 +
> arch/powerpc/platforms/83xx/tqm8315.c | 137 ++
> 5 files changed, 2756 insertions(+)
> create mode 100644 arch/powerpc/boot/dts/ib8315.dts
> create mode 100644 arch/powerpc/configs/83xx/ib8315_defconfig
> create mode 100644 arch/powerpc/platforms/83xx/tqm8315.c
Is there some relationship of this board with the TQM8315?
- k=
^ permalink raw reply
* Re: [PATCH 2/3] VFIO: VFIO_DEVICE_SET_ADDR_MAPPING command
From: Alex Williamson @ 2013-03-18 21:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: aik, linuxppc-dev, Gavin Shan, kvm
In-Reply-To: <1363412256.1244.20.camel@pasglop>
On Sat, 2013-03-16 at 06:37 +0100, Benjamin Herrenschmidt wrote:
> 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.
There's no notification mechanism when a PHB is frozen? I suppose
notification would be asynchronous so you risk data for every read that
happens in the interim. So the choices are a) tell the host kernel the
mapping, b) tell the guest kernel the mapping, c) identity mapping, or
d) qemu intercept?
Presumably your firmware call to query the EEH is not going through
VFIO, so is VFIO the appropriate place to setup this mapping? As you
say, this seems like just a convenient place to put it even though it
really has nothing to do with the VFIO kernel component. QEMU has this
information and could register it with the host kernel through other
means if available. Maybe the mapping should be registered with KVM if
that's how the EEH data is accessed. I'm not yet sold on why this
mapping is registered here. Thanks,
Alex
^ permalink raw reply
* Re: [PATCH 3/3] VFIO: Direct access config reg without capability
From: Alex Williamson @ 2013-03-18 21:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: aik, linuxppc-dev, Gavin Shan, kvm
In-Reply-To: <1363411807.1244.13.camel@pasglop>
On Sat, 2013-03-16 at 06:30 +0100, Benjamin Herrenschmidt wrote:
> 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 :-)
Yeah, yeah. Ok, I can't come up with a reasonable argument otherwise,
it'll give us better device support, and I believe pci-assign has always
done this. I'll take another look at the patch. Thanks,
Alex
^ permalink raw reply
* Re: [PATCH] powerpc: add Book E support to 64-bit hibernation
From: Scott Wood @ 2013-03-18 22:12 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, Wang Dongsheng
In-Reply-To: <1363360926.8656.5.camel@jlt4.sipsolutions.net>
On 03/15/2013 10:22:06 AM, Johannes Berg wrote:
> 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 =20
> put a
> > > better one (almost 6 years ago!!)
>=20
> > If it's because book3s needs mtmsrd instead of mtmsr, that doesn't
> > apply to booke.
>=20
> Indeed, looking at the code again now that seems pretty obvious.
>=20
> Looking at the patch again, I'd be a little concerned about the lack =20
> of
> cache flushing, seems a bit odd but I'm sure you know what you're =20
> doing
> (and I don't know book3e at all, and hardly remember book3s -- or even
> that name...) :-)
Could you elaborate on why book3s flushes the way it does? What's =20
special about the first 32 MiB? If it's to cover kernel code, why =20
would that be changing from what's already there?
-Scott=
^ permalink raw reply
* [PATCH] sgy-cts1000: Remove __dev* attributes
From: Ben Collins @ 2013-03-18 23:19 UTC (permalink / raw)
To: Linus Torvalds
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Somehow the driver snuck in with these still in it.
Signed-off-by: Ben Collins <ben.c@servergy.com>
---
arch/powerpc/platforms/85xx/sgy_cts1000.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/sgy_cts1000.c =
b/arch/powerpc/platforms/85xx/sgy_cts1000.c
index 611e92f..7179726 100644
--- a/arch/powerpc/platforms/85xx/sgy_cts1000.c
+++ b/arch/powerpc/platforms/85xx/sgy_cts1000.c
@@ -69,7 +69,7 @@ static irqreturn_t gpio_halt_irq(int irq, void =
*__data)
return IRQ_HANDLED;
};
=20
-static int __devinit gpio_halt_probe(struct platform_device *pdev)
+static int gpio_halt_probe(struct platform_device *pdev)
{
enum of_gpio_flags flags;
struct device_node *node =3D pdev->dev.of_node;
@@ -128,7 +128,7 @@ static int __devinit gpio_halt_probe(struct =
platform_device *pdev)
return 0;
}
=20
-static int __devexit gpio_halt_remove(struct platform_device *pdev)
+static int gpio_halt_remove(struct platform_device *pdev)
{
if (halt_node) {
int gpio =3D of_get_gpio(halt_node, 0);
@@ -165,7 +165,7 @@ static struct platform_driver gpio_halt_driver =3D {
.of_match_table =3D gpio_halt_match,
},
.probe =3D gpio_halt_probe,
- .remove =3D __devexit_p(gpio_halt_remove),
+ .remove =3D gpio_halt_remove,
};
=20
module_platform_driver(gpio_halt_driver);
--=20
1.8.1.2
--
Servergy : http://www.servergy.com/
SwissDisk : http://www.swissdisk.com/
Ubuntu : http://www.ubuntu.com/
My Blog : http://ben-collins.blogspot.com/
^ permalink raw reply related
* Re: [PATCH][UPSTEAM] powerpc/mpic: add irq_set_wake support
From: Scott Wood @ 2013-03-18 23:36 UTC (permalink / raw)
To: Wang Dongsheng; +Cc: linuxppc-dev
In-Reply-To: <1359601823-9861-1-git-send-email-dongsheng.wang@freescale.com>
On 01/30/2013 09:10:23 PM, Wang Dongsheng wrote:
> Add irq_set_wake support. Just add IRQF_NO_SUSPEND to =20
> desc->action->flag.
> So the wake up interrupt will not be disable in suspend_device_irqs.
>=20
> Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
> ---
> arch/powerpc/sysdev/mpic.c | 15 +++++++++++++++
> 1 files changed, 15 insertions(+), 0 deletions(-)
>=20
> diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> index 9c6e535..2ed0220 100644
> --- a/arch/powerpc/sysdev/mpic.c
> +++ b/arch/powerpc/sysdev/mpic.c
> @@ -920,6 +920,18 @@ int mpic_set_irq_type(struct irq_data *d, =20
> unsigned int flow_type)
> return IRQ_SET_MASK_OK_NOCOPY;
> }
>=20
> +static int mpic_irq_set_wake(struct irq_data *d, unsigned int on)
> +{
> + struct irq_desc *desc =3D container_of(d, struct irq_desc, =20
> irq_data);
> +
> + if (on)
> + desc->action->flags |=3D IRQF_NO_SUSPEND;
> + else
> + desc->action->flags &=3D ~IRQF_NO_SUSPEND;
> +
> + return 0;
> +}
This should really be something like fsl_mpic_irq_set_wake() and only =20
set when we have an FSL MPIC.
> void mpic_set_vector(unsigned int virq, unsigned int vector)
> {
> struct mpic *mpic =3D mpic_from_irq(virq);
> @@ -957,6 +969,7 @@ static struct irq_chip mpic_irq_chip =3D {
> .irq_unmask =3D mpic_unmask_irq,
> .irq_eoi =3D mpic_end_irq,
> .irq_set_type =3D mpic_set_irq_type,
> + .irq_set_wake =3D mpic_irq_set_wake,
> };
>=20
> #ifdef CONFIG_SMP
> @@ -971,6 +984,7 @@ static struct irq_chip mpic_tm_chip =3D {
> .irq_mask =3D mpic_mask_tm,
> .irq_unmask =3D mpic_unmask_tm,
> .irq_eoi =3D mpic_end_irq,
> + .irq_set_wake =3D mpic_irq_set_wake,
> };
>=20
> #ifdef CONFIG_MPIC_U3_HT_IRQS
> @@ -981,6 +995,7 @@ static struct irq_chip mpic_irq_ht_chip =3D {
> .irq_unmask =3D mpic_unmask_ht_irq,
> .irq_eoi =3D mpic_end_ht_irq,
> .irq_set_type =3D mpic_set_irq_type,
> + .irq_set_wake =3D mpic_irq_set_wake,
> };
> #endif /* CONFIG_MPIC_U3_HT_IRQS */
Why ht?
-Scott=
^ permalink raw reply
* Re: [PATCH 2/3] powerpc/mpic: add global timer support
From: Scott Wood @ 2013-03-18 23:46 UTC (permalink / raw)
To: Wang Dongsheng; +Cc: kumar.gala, linuxppc-dev, Wang Dongsheng
In-Reply-To: <1362728327-21013-2-git-send-email-dongsheng.wang@freescale.com>
On 03/08/2013 01:38:46 AM, Wang Dongsheng wrote:
> The MPIC global timer is a hardware timer inside the Freescale PIC =20
> comply
> to Open-PIC standard. When the timer is timeout of the specified =20
> interval,
> the hardware timer generates an interrupt. The driver currently is =20
> only
> tested on fsl chip, but it can potentially support other global timers
> complying to Open-PIC standard.
>=20
> The two independent groups of global timer on fsl chip, group A and =20
> group B,
> are identical in their functionality, except that they appear at =20
> different
> locations within the PIC register map. The hardware timer can be =20
> cascaded to
> create timers larger than the default 31-bit global timers. Timer =20
> cascade
> fields allow configuration of up to two 63-bit timers. But These two =20
> groups
> of timers cannot be cascaded together.
>=20
> It can be used as a wakeup source for low power modes. It also could =20
> be used
> as periodical timer for protocols, drivers and etc.
>=20
> Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> arch/powerpc/include/asm/mpic_timer.h | 46 +++
> arch/powerpc/platforms/Kconfig | 12 +
> arch/powerpc/sysdev/Makefile | 1 +
> arch/powerpc/sysdev/mpic_timer.c | 606 =20
> +++++++++++++++++++++++++++++++++
> 4 files changed, 665 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/include/asm/mpic_timer.h
> create mode 100644 arch/powerpc/sysdev/mpic_timer.c
>=20
> diff --git a/arch/powerpc/include/asm/mpic_timer.h =20
> b/arch/powerpc/include/asm/mpic_timer.h
> new file mode 100644
> index 0000000..0e23cd4
> --- /dev/null
> +++ b/arch/powerpc/include/asm/mpic_timer.h
> @@ -0,0 +1,46 @@
> +/*
> + * arch/powerpc/include/asm/mpic_timer.h
> + *
> + * Header file for Mpic Global Timer
> + *
> + * Copyright 2013 Freescale Semiconductor, Inc.
> + *
> + * Author: Wang Dongsheng <Dongsheng.Wang@freescale.com>
> + * Li Yang <leoli@freescale.com>
> + *
> + * 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 by =20
> the
> + * Free Software Foundation; either version 2 of the License, or (at =20
> your
> + * option) any later version.
> + */
> +
> +#ifndef __MPIC_TIMER__
> +#define __MPIC_TIMER__
> +
> +#include <linux/interrupt.h>
> +#include <linux/time.h>
> +
> +struct mpic_timer {
> + void *dev;
> + struct cascade_priv *cascade_handle;
> + unsigned int num;
> + unsigned int irq;
> +};
> +
> +#ifdef CONFIG_MPIC_TIMER
> +struct mpic_timer *mpic_request_timer(irq_handler_t fn, void *dev,
> + const struct timeval *time);
> +void mpic_start_timer(struct mpic_timer *handle);
> +void mpic_stop_timer(struct mpic_timer *handle);
> +void mpic_get_remain_time(struct mpic_timer *handle, struct timeval =20
> *time);
> +void mpic_free_timer(struct mpic_timer *handle);
> +#else
> +struct mpic_timer *mpic_request_timer(irq_handler_t fn, void *dev,
> + const struct timeval *time) { return NULL; }
> +void mpic_start_timer(struct mpic_timer *handle) { }
> +void mpic_stop_timer(struct mpic_timer *handle) { }
> +void mpic_get_remain_time(struct mpic_timer *handle, struct timeval =20
> *time) { }
> +void mpic_free_timer(struct mpic_timer *handle) { }
> +#endif
I'm not sure how useful these stubs are...
> +config MPIC_TIMER
> + bool "MPIC Global Timer"
> + depends on MPIC && FSL_SOC
> + default n
> + help
> + The MPIC global timer is a hardware timer inside the
> + Freescale PIC comply to Open-PIC standard. When the
s/comply to/complying with/
s/Open-PIC/OpenPIC/
> + timer is timeout of the specified interval, the hardware
s/timer is timeout of the specified interval/specified interval times =20
out/
> + timer generates an interrupt. The driver currently is
> + only tested on fsl chip, but it can potentially support
> + other global timers complying to Open-PIC standard.
s/to Open-PIC/with the OpenPIC/
> +static void convert_ticks_to_time(struct timer_group_priv *priv,
> + const u64 ticks, struct timeval *time)
> +{
> + u64 tmp_sec;
> + u32 rem_us;
> + u32 div;
> +
> + if (!(priv->flags & FSL_GLOBAL_TIMER)) {
> + time->tv_sec =3D (__kernel_time_t)
> + div_u64_rem(ticks, priv->timerfreq, &rem_us);
> + tmp_sec =3D (u64)time->tv_sec * (u64)priv->timerfreq;
> + time->tv_usec =3D (__kernel_suseconds_t)
> + div_u64((ticks - tmp_sec) * 1000000, =20
> priv->timerfreq);
> +
> + return;
> + }
> +
> + div =3D (1 << (MPIC_TIMER_TCR_CLKDIV_64 >> 8)) * 8;
> +
> + time->tv_sec =3D (__kernel_time_t)div_u64(ticks, priv->timerfreq =20
> / div);
> + tmp_sec =3D div_u64((u64)time->tv_sec * (u64)priv->timerfreq, =20
> div);
> +
> + time->tv_usec =3D (__kernel_suseconds_t)
> + div_u64((ticks - tmp_sec) * 1000000, priv->timerfreq / =20
> div);
> +
> + return;
Why don't you just adjust the clock frequency up front for CLKDIV_64,
rather than introduce alternate (and untested!) code paths throughout =20
the
driver?
> + list_for_each_entry(priv, &timer_group_list, node) {
> + ret =3D convert_time_to_ticks(priv, time, &ticks);
> + if (ret < 0)
> + return NULL;
> +
> + if (ticks > MAX_TICKS) {
> + if (!(priv->flags & FSL_GLOBAL_TIMER))
> + return NULL;
> +
> + timer =3D get_cascade_timer(priv, ticks);
> + if (!timer)
> + continue;
> + else
> + return timer;
> + }
if (!timer)
continue;
return timer;
-Scott=
^ permalink raw reply
* Re: [PATCH 3/3] powerpc/fsl: add MPIC timer wakeup support
From: Scott Wood @ 2013-03-19 0:30 UTC (permalink / raw)
To: Wang Dongsheng; +Cc: kumar.gala, linuxppc-dev, Wang Dongsheng, Zhao Chenhui
In-Reply-To: <1362728327-21013-3-git-send-email-dongsheng.wang@freescale.com>
On 03/08/2013 01:38:47 AM, Wang Dongsheng wrote:
> The driver provides a way to wake up the system by the MPIC timer.
>=20
> For example,
> echo 5 > /sys/devices/system/mpic/timer_wakeup
> echo standby > /sys/power/state
>=20
> After 5 seconds the MPIC timer will generate an interrupt to wake up
> the system.
>=20
> Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
> Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
Does this work with deep sleep (echo mem > /sys/power/state on mpc8536, =20
p1022, etc) or just regular sleep?
> ---
> arch/powerpc/platforms/Kconfig | 9 ++
> arch/powerpc/sysdev/Makefile | 1 +
> arch/powerpc/sysdev/fsl_mpic_timer_wakeup.c | 185 =20
> +++++++++++++++++++++++++++
> 3 files changed, 195 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/sysdev/fsl_mpic_timer_wakeup.c
>=20
> diff --git a/arch/powerpc/platforms/Kconfig =20
> b/arch/powerpc/platforms/Kconfig
> index 5af04fa..487c37f 100644
> --- a/arch/powerpc/platforms/Kconfig
> +++ b/arch/powerpc/platforms/Kconfig
> @@ -99,6 +99,15 @@ config MPIC_TIMER
> only tested on fsl chip, but it can potentially support
> other global timers complying to Open-PIC standard.
>=20
> +config FSL_MPIC_TIMER_WAKEUP
> + tristate "Freescale MPIC global timer wakeup driver"
> + depends on FSL_SOC && MPIC_TIMER
> + default n
> + help
> + This is only for freescale powerpc platform.
This sentence is redundant... It already says "Freescale MPIC" in the =20
name and depends on "FSL_SOC && MPIC_TIMER".
> +static irqreturn_t fsl_mpic_timer_irq(int irq, void *dev_id)
> +{
> + struct fsl_mpic_timer_wakeup *wakeup =3D dev_id;
> +
> + schedule_work(&wakeup->free_work);
> + return IRQ_HANDLED;
> +}
return wakeup->timer ? IRQ_HANDLED : IRQ_NONE;
> +
> +static ssize_t fsl_timer_wakeup_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct timeval interval;
> + int val =3D 0;
> +
> + mutex_lock(&sysfs_lock);
> + if (fsl_wakeup->timer) {
> + mpic_get_remain_time(fsl_wakeup->timer, &interval);
> + val =3D interval.tv_sec + 1;
> + }
> + mutex_unlock(&sysfs_lock);
> +
> + return sprintf(buf, "%d\n", val);
> +}
> +
> +static ssize_t fsl_timer_wakeup_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf,
> + size_t count)
> +{
> + struct timeval interval;
> + int ret;
> +
> + interval.tv_usec =3D 0;
> + if (kstrtol(buf, 0, &interval.tv_sec))
> + return -EINVAL;
I don't think the buffer will NUL-terminated... Ordinarily there'll be
an LF terminator, but you can't rely on that (many other sysfs =20
attributes
seem to, though...).
> + mutex_lock(&sysfs_lock);
> +
> + if (fsl_wakeup->timer && !interval.tv_sec) {
> + disable_irq_wake(fsl_wakeup->timer->irq);
> + mpic_free_timer(fsl_wakeup->timer);
> + fsl_wakeup->timer =3D NULL;
> + mutex_unlock(&sysfs_lock);
> +
> + return count;
> + }
> +
> + if (fsl_wakeup->timer) {
> + mutex_unlock(&sysfs_lock);
> + return -EBUSY;
> + }
So to change an already-set timer you have to set it to zero and then to
what you want? Why not just do:
if (fsl_wakeup->timer) {
disable_irq_wake(...);
mpic_free_timer(...);
fsl_wakeup_timer =3D NULL;
}
if (!interval.tv_sec) {
mutex_unlock(&sysfs_lock);
return count;
}
> + ret =3D subsys_system_register(&mpic_subsys, NULL);
> + if (ret)
> + goto err;
Maybe arch/powerpc/sysdev/mpic.c should be doing this?
> +
> + for (i =3D 0; mpic_attributes[i]; i++) {
> + ret =3D device_create_file(mpic_subsys.dev_root,
> + mpic_attributes[i]);
> + if (ret)
> + goto err2;
> + }
Is this code ever going to register more than one?
-Scott=
^ permalink raw reply
* [PATCH for 3.9] powerpc/ps3: Update ps3_defconfig
From: Geoff Levand @ 2013-03-19 1:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: cbe-oss-dev, linuxppc-dev
In-Reply-To: <cover.1360810584.git.geoff@infradead.org>
Refresh and set CONFIG_RD_LZMA=y.
Signed-off-by: Geoff Levand <geoff@infradead.org>
---
Hi Ben,
This sets CONFIG_RD_LZMA=y, which is needed to boot with
newer initrd images.
Please apply for 3.9.
Also available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geoff/ps3-linux.git for-powerpc
-Geoff
arch/powerpc/configs/ps3_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/configs/ps3_defconfig b/arch/powerpc/configs/ps3_defconfig
index 7a5c15f..f791962 100644
--- a/arch/powerpc/configs/ps3_defconfig
+++ b/arch/powerpc/configs/ps3_defconfig
@@ -3,11 +3,11 @@ CONFIG_TUNE_CELL=y
CONFIG_ALTIVEC=y
CONFIG_SMP=y
CONFIG_NR_CPUS=2
-CONFIG_EXPERIMENTAL=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_BLK_DEV_INITRD=y
+CONFIG_RD_LZMA=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_EMBEDDED=y
# CONFIG_PERF_EVENTS is not set
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 2/3] VFIO: VFIO_DEVICE_SET_ADDR_MAPPING command
From: Gavin Shan @ 2013-03-19 3:24 UTC (permalink / raw)
To: Alex Williamson; +Cc: aik, linuxppc-dev, Gavin Shan, kvm
In-Reply-To: <1363640474.24132.433.camel@bling.home>
On Mon, Mar 18, 2013 at 03:01:14PM -0600, Alex Williamson wrote:
>On Sat, 2013-03-16 at 06:37 +0100, Benjamin Herrenschmidt wrote:
>> 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.
>
>There's no notification mechanism when a PHB is frozen? I suppose
>notification would be asynchronous so you risk data for every read that
>happens in the interim. So the choices are a) tell the host kernel the
>mapping, b) tell the guest kernel the mapping, c) identity mapping, or
>d) qemu intercept?
>
We do have dedicated interrupts on detecting frozen PHB on host side.
However, the guest has to poll/check the frozen state (frozen PE) during
access to config or MMIO space. For the recommended methods, (a) is what
we want to do with the patchset. (b) seems infeasible since the guest
shouldn't be aware of hypervisor (e.g. KVM or PowerVM) it's running on
top of, it's hard to polish the guest to do it. (d) sounds applicable
since the QEMU should know the address (BDF) of host and guest devices.
However, we still need let the host EEH core know that which PCI device
has been passed to guest and the best place to do that would be when opening
the corresponding VFIO PCI device. In turn, it will still need weak function
for ppc platform to override it. Why we not directly take (a) to finish
everything in one VFIO IOCTL command?
Sorry, Alex. I didn't understand (c) well :-)
>Presumably your firmware call to query the EEH is not going through
>VFIO, so is VFIO the appropriate place to setup this mapping? As you
>say, this seems like just a convenient place to put it even though it
>really has nothing to do with the VFIO kernel component. QEMU has this
>information and could register it with the host kernel through other
>means if available. Maybe the mapping should be registered with KVM if
>that's how the EEH data is accessed. I'm not yet sold on why this
>mapping is registered here. Thanks,
>
Yes, EEH firmware call needn't going through VFIO. However, EEH has
very close relationship with PCI and so VFIO-PCI does. Eventually, EEH
has close relationship with VFIO-PCI :-)
Thanks,
Gavin
^ permalink raw reply
* Re: [PATCH 2/3] VFIO: VFIO_DEVICE_SET_ADDR_MAPPING command
From: Alex Williamson @ 2013-03-19 4:18 UTC (permalink / raw)
To: Gavin Shan; +Cc: aik, linuxppc-dev, kvm
In-Reply-To: <20130319032410.GA22591@shangw.(null)>
On Tue, 2013-03-19 at 11:24 +0800, Gavin Shan wrote:
> On Mon, Mar 18, 2013 at 03:01:14PM -0600, Alex Williamson wrote:
> >On Sat, 2013-03-16 at 06:37 +0100, Benjamin Herrenschmidt wrote:
> >> 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.
> >
> >There's no notification mechanism when a PHB is frozen? I suppose
> >notification would be asynchronous so you risk data for every read that
> >happens in the interim. So the choices are a) tell the host kernel the
> >mapping, b) tell the guest kernel the mapping, c) identity mapping, or
> >d) qemu intercept?
> >
>
> We do have dedicated interrupts on detecting frozen PHB on host side.
> However, the guest has to poll/check the frozen state (frozen PE) during
> access to config or MMIO space.
Can you make use of something like this to notify the guest:
https://github.com/awilliam/linux-vfio/commit/dad9f8972e04cd081a028d8fb1249d746d97fc03
As a first step this only notifies QEMU, but the plan is to forward that
on to the guest. If we can leverage similar interfaces between AER and
EEH, I'd obviously like to do that.
> For the recommended methods, (a) is what
> we want to do with the patchset. (b) seems infeasible since the guest
> shouldn't be aware of hypervisor (e.g. KVM or PowerVM) it's running on
> top of, it's hard to polish the guest to do it. (d) sounds applicable
> since the QEMU should know the address (BDF) of host and guest devices.
> However, we still need let the host EEH core know that which PCI device
> has been passed to guest and the best place to do that would be when opening
> the corresponding VFIO PCI device. In turn, it will still need weak function
> for ppc platform to override it. Why we not directly take (a) to finish
> everything in one VFIO IOCTL command?
Because it seems like VFIO is just being used as a relay and has no
purpose knowing this information on it's own. It's just a convenient
place to host the ioctl, but that alone is not a good enough reason to
put it there.
> Sorry, Alex. I didn't understand (c) well :-)
(c) is if the buid/bus/slot/func exposed to the guest matches the same
for the host, then there's no need for mapping translation.
> >Presumably your firmware call to query the EEH is not going through
> >VFIO, so is VFIO the appropriate place to setup this mapping? As you
> >say, this seems like just a convenient place to put it even though it
> >really has nothing to do with the VFIO kernel component. QEMU has this
> >information and could register it with the host kernel through other
> >means if available. Maybe the mapping should be registered with KVM if
> >that's how the EEH data is accessed. I'm not yet sold on why this
> >mapping is registered here. Thanks,
> >
>
> Yes, EEH firmware call needn't going through VFIO. However, EEH has
> very close relationship with PCI and so VFIO-PCI does. Eventually, EEH
> has close relationship with VFIO-PCI :-)
Is there some plan to do more with EEH through VFIO in the future or are
we just talking about some kind of weird associative property to sell
this ioctl? Thanks,
Alex
^ permalink raw reply
* Re: [PATCH 2/3] VFIO: VFIO_DEVICE_SET_ADDR_MAPPING command
From: Benjamin Herrenschmidt @ 2013-03-19 4:45 UTC (permalink / raw)
To: Alex Williamson; +Cc: aik, linuxppc-dev, Gavin Shan, kvm
In-Reply-To: <1363666721.24132.472.camel@bling.home>
On Mon, 2013-03-18 at 22:18 -0600, Alex Williamson wrote:
> > Yes, EEH firmware call needn't going through VFIO. However, EEH has
> > very close relationship with PCI and so VFIO-PCI does. Eventually, EEH
> > has close relationship with VFIO-PCI :-)
>
> Is there some plan to do more with EEH through VFIO in the future or are
> we just talking about some kind of weird associative property to sell
> this ioctl? Thanks,
Well, I'm not sure how 'weird' that is but it makes sense to me... VFIO
is the mechanism that virtualizes access to a PCI device and provides
interfaces to qemu & kvm to access it &| map it.
Or rather VFIO-PCI is.
At a basic level it provides ... the basic PCI interfaces, ie, config
space access (with or without filtering), interrupts, etc...
In our environment, EEH is just another functionality of PCI really.
The firmware calls used by the guest to do that fall into more or less
the same category as the ones used for PCI config space accesses,
manipulation of DMA windows, etc... Similar to host (though guest
and host use a different FW interface for various reasons).
So it's very natural to "transport" these via VFIO-PCI like everything
else, I don't see a more natural place to put the ioctl's we need for
qemu to be able to access the EEH state, trigger EEH (un)isolation,
resets, etc...
Fundamentally, the design should be for VFIO-PCI to provide some specific
ioctls for EEH that userspace programs such as qemu can use, and then
re-expose those APIs to the guest.
In addition, to do some of it in the kernel for performance reason, we
want to establish that mapping, but I see that as a VFIO "accelerator".
IE. Whatever is going to respond to the EEH calls from the guest in-kernel
will have to share state with the rest of the EEH stuff provided to qemu
by vfio-pci.
Ben.
^ permalink raw reply
* RE: [PATCH 5/6] powerpc/fsl-booke: Add B4_QDS board support
From: Leekha Shaveta-B20052 @ 2013-03-19 6:07 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6F89A437-E585-4426-8DA9-36B2D85BF590@kernel.crashing.org>
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
Sent: Monday, March 18, 2013 8:26 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 18, 2013, at 1:28 AM, Leekha Shaveta-B20052 wrote:
>=20
>=20
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> 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
>=20
>=20
> On Mar 15, 2013, at 2:55 AM, Shaveta Leekha wrote:
>=20
>> - Add support for B4 board's personalities in board file b4_qds.c,=20
>> It is common for B4 personalities B4860 and B4420QDS
>> - Add B4QDS support in Kconfig and Makefile
>=20
> Code also references a B4220, what about it?
> [SL] I have added the basic support for it in board file as it's one=20
> of the personality of B4, missed it in description. But device trees for =
this has not been created and tested.
> So what do you suggest here:
> Should I add it here in B4 board support or should I remove its reference=
s altogether?
What's the difference between B4220 and B4420 or B4860?
- k
[SL] B4220 is again a reduced personality of B4 with some differences like:
Even lesser Number of cores than B4860 and B4420, lesser number of SerDes =
lanes and some difference in other peripherals.
=09
BR,
Shaveta
>=20
>>=20
>> B4860QDS is a high-performance computing evaluation, development and=20
>> test platform supporting the B4860 QorIQ Power Architecture=20
>> processor, 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 SGMI=
I 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
>> ++++++++++++++++++++++++++++++++++
>> 3 files changed, 119 insertions(+), 0 deletions(-) create mode 100644=20
>> arch/powerpc/platforms/85xx/b4_qds.c
^ permalink raw reply
* RE: [PATCH 2/6] powerpc/fsl-booke: Add initial B4860QDS board device tree
From: Leekha Shaveta-B20052 @ 2013-03-19 6:11 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: <5594D9B8-885F-4A02-9F7D-B6BFA8BD84C8@kernel.crashing.org>
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
Sent: Monday, March 18, 2013 8:33 PM
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 18, 2013, at 1:31 AM, Leekha Shaveta-B20052 wrote:
>=20
>=20
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Saturday, March 16, 2013 1:57 AM
> To: Leekha Shaveta-B20052
> Cc: linuxppc-dev@lists.ozlabs.org; Lian Minghuan-B31939; Fleming=20
> Andy-AFLEMING; Aggrwal Poonam-B10812; Mehresh Ramneek-B31383
> Subject: Re: [PATCH 2/6] powerpc/fsl-booke: Add initial B4860QDS board=20
> device tree
>=20
>=20
> On Mar 15, 2013, at 2:55 AM, Shaveta Leekha wrote:
>=20
>> 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=20
>> 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=20
>> +without
>> + * modification, are permitted provided that the following conditions a=
re 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 copyri=
ght
>> + * notice, this list of conditions and the following disclaimer i=
n the
>> + * documentation and/or other materials provided with the distrib=
ution.
>> + * * Neither the name of Freescale Semiconductor nor the
>> + * names of its contributors may be used to endorse or promote pr=
oducts
>> + * derived from this software without specific prior written perm=
ission.
>> + *
>> + *
>> + * ALTERNATIVELY, this software may be distributed under the terms=20
>> +of 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''=20
>> +AND ANY
>> + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE=20
>> +IMPLIED
>> + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR=20
>> +PURPOSE ARE
>> + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE=20
>> +FOR ANY
>> + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR=20
>> +CONSEQUENTIAL DAMAGES
>> + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS=20
>> +OR SERVICES;
>> + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER=20
>> +CAUSED AND
>> + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT=20
>> +LIABILITY, 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>;
>> + };
>> + };
>> +
>=20
> dscr nodes are missing and should be included [SL] I don't have much=20
> idea about dcsr nodes structure and their respective testing, also couldn=
't find then in T4 device tree files. I have added initial device trees. Dc=
sr may be added later as updation. What do you say?
I'll add them to T4, but if you look at the internal FSL SDK tree you will =
see they've been added for T4 & B4.
[SL] Ok, will add them.
>=20
>=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>;
>=20
> there is no IRQ for RTC on the board.
> [SL] will remove it.=20
>=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
>=20
>=20
> Regards,
> Shaveta
>=20
>=20
^ permalink raw reply
* RE: [PATCH 1/6] powerpc/fsl-booke: Add initial silicon device tree files for B4860QDS
From: Leekha Shaveta-B20052 @ 2013-03-19 6:13 UTC (permalink / raw)
To: Kumar Gala
Cc: Zhao Chenhui-B35336, Mehresh Ramneek-B31383, Timur Tabi,
Lian Minghuan-B31939, Tang Yuantian-B29983, Fleming Andy-AFLEMING,
Sethi Varun-B16395, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <9B5470DD-595E-4234-B462-1232745D8F9F@kernel.crashing.org>
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
Sent: Monday, March 18, 2013 8:34 PM
To: Leekha Shaveta-B20052
Cc: Timur Tabi; linuxppc-dev@lists.ozlabs.org; Zhao Chenhui-B35336; Lian Mi=
nghuan-B31939; Tang Yuantian-B29983; Fleming Andy-AFLEMING; Mehresh Ramneek=
-B31383; Sethi Varun-B16395
Subject: Re: [PATCH 1/6] powerpc/fsl-booke: Add initial silicon device tree=
files for B4860QDS
On Mar 18, 2013, at 2:41 AM, Leekha Shaveta-B20052 wrote:
>=20
>=20
> -----Original Message-----
> From: Timur Tabi [mailto:timur@tabi.org]
> Sent: Friday, March 15, 2013 6:38 PM
> To: Leekha Shaveta-B20052
> Cc: linuxppc-dev@lists.ozlabs.org; Zhao Chenhui-B35336; Lian=20
> Minghuan-B31939; Tang Yuantian-B29983; Fleming Andy-AFLEMING; Mehresh=20
> Ramneek-B31383; Sethi Varun-B16395
> Subject: Re: [PATCH 1/6] powerpc/fsl-booke: Add initial silicon device=20
> tree files for B4860QDS
>=20
> On Fri, Mar 15, 2013 at 2:55 AM, Shaveta Leekha <shaveta@freescale.com> w=
rote:
>=20
>=20
>> + iommu@20000 {
>> + compatible =3D "fsl,pamu-v1.0", "fsl,pamu";
>> + reg =3D <0x20000 0x4000>;
>> + interrupts =3D <
>> + 24 2 0 0
>> + 16 2 1 1>;
>> + };
>=20
> 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=20
> of time, we plan to add pamu topology and pamu related support in various=
devices both for T4 and B4.
> Kumar can you please suggest?
I can help with the B4 topology as its reasonable well described, I've been=
working on trying to get the info to finish T4.
[SL] I have seen your patches to add PAMU topology in B4. Should I include =
them in my set of patches or you would send them above my initial set of pa=
tches?
BR,
Shaveta
- k
^ permalink raw reply
* RE: [PATCH 2/6] powerpc/fsl-booke: Add initial B4860QDS board device tree
From: Leekha Shaveta-B20052 @ 2013-03-19 6:23 UTC (permalink / raw)
To: Kumar Gala
Cc: Aggrwal Poonam-B10812, Mehresh Ramneek-B31383,
Lian Minghuan-B31939, Leekha Shaveta-B20052,
Fleming Andy-AFLEMING, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <5594D9B8-885F-4A02-9F7D-B6BFA8BD84C8@kernel.crashing.org>
-----Original Message-----
From: Leekha Shaveta-B20052=20
Sent: Tuesday, March 19, 2013 11:41 AM
To: 'Kumar Gala'
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
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
Sent: Monday, March 18, 2013 8:33 PM
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 18, 2013, at 1:31 AM, Leekha Shaveta-B20052 wrote:
>=20
>=20
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Saturday, March 16, 2013 1:57 AM
> To: Leekha Shaveta-B20052
> Cc: linuxppc-dev@lists.ozlabs.org; Lian Minghuan-B31939; Fleming=20
> Andy-AFLEMING; Aggrwal Poonam-B10812; Mehresh Ramneek-B31383
> Subject: Re: [PATCH 2/6] powerpc/fsl-booke: Add initial B4860QDS board=20
> device tree
>=20
>=20
> On Mar 15, 2013, at 2:55 AM, Shaveta Leekha wrote:
>=20
>> 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=20
>> 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=20
>> +without
>> + * modification, are permitted provided that the following conditions a=
re 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 copyri=
ght
>> + * notice, this list of conditions and the following disclaimer i=
n the
>> + * documentation and/or other materials provided with the distrib=
ution.
>> + * * Neither the name of Freescale Semiconductor nor the
>> + * names of its contributors may be used to endorse or promote pr=
oducts
>> + * derived from this software without specific prior written perm=
ission.
>> + *
>> + *
>> + * ALTERNATIVELY, this software may be distributed under the terms=20
>> +of 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''=20
>> +AND ANY
>> + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE=20
>> +IMPLIED
>> + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR=20
>> +PURPOSE ARE
>> + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE=20
>> +FOR ANY
>> + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR=20
>> +CONSEQUENTIAL DAMAGES
>> + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS=20
>> +OR SERVICES;
>> + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER=20
>> +CAUSED AND
>> + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT=20
>> +LIABILITY, 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>;
>> + };
>> + };
>> +
>=20
> dscr nodes are missing and should be included [SL] I don't have much=20
> idea about dcsr nodes structure and their respective testing, also couldn=
't find then in T4 device tree files. I have added initial device trees. Dc=
sr may be added later as updation. What do you say?
I'll add them to T4, but if you look at the internal FSL SDK tree you will =
see they've been added for T4 & B4.
[SL] Ok, will add them.
Can you please point me to the patch or codebase where dcsr nodes are added=
in B4?=20
BR,
Shaveta
>=20
>=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>;
>=20
> there is no IRQ for RTC on the board.
> [SL] will remove it.=20
>=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
>=20
>=20
> Regards,
> Shaveta
>=20
>=20
^ permalink raw reply
* RE: [PATCH 3/3] powerpc/fsl: add MPIC timer wakeup support
From: Wang Dongsheng-B40534 @ 2013-03-19 6:25 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: Gala Kumar-B11780, linuxppc-dev@lists.ozlabs.org, Li Yang-R58472,
Zhao Chenhui-B35336
In-Reply-To: <1363653058.27435.24@snotra>
Hi Scoot,
Thanks for reviewing.
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Tuesday, March 19, 2013 8:31 AM
> To: Wang Dongsheng-B40534
> Cc: Gala Kumar-B11780; linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-
> B40534; Zhao Chenhui-B35336; Li Yang-R58472
> Subject: Re: [PATCH 3/3] powerpc/fsl: add MPIC timer wakeup support
>=20
> On 03/08/2013 01:38:47 AM, Wang Dongsheng wrote:
> > The driver provides a way to wake up the system by the MPIC timer.
> >
> > For example,
> > echo 5 > /sys/devices/system/mpic/timer_wakeup
> > echo standby > /sys/power/state
> >
> > After 5 seconds the MPIC timer will generate an interrupt to wake up
> > the system.
> >
> > Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
> > Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> > Signed-off-by: Li Yang <leoli@freescale.com>
>=20
> Does this work with deep sleep (echo mem > /sys/power/state on mpc8536,
> p1022, etc) or just regular sleep?
>=20
The deep sleep can also work.
> > ---
> > arch/powerpc/platforms/Kconfig | 9 ++
> > arch/powerpc/sysdev/Makefile | 1 +
> > arch/powerpc/sysdev/fsl_mpic_timer_wakeup.c | 185
> > +++++++++++++++++++++++++++
> > 3 files changed, 195 insertions(+), 0 deletions(-) create mode
> > 100644 arch/powerpc/sysdev/fsl_mpic_timer_wakeup.c
> >
> > diff --git a/arch/powerpc/platforms/Kconfig
> > b/arch/powerpc/platforms/Kconfig index 5af04fa..487c37f 100644
> > --- a/arch/powerpc/platforms/Kconfig
> > +++ b/arch/powerpc/platforms/Kconfig
> > @@ -99,6 +99,15 @@ config MPIC_TIMER
> > only tested on fsl chip, but it can potentially support
> > other global timers complying to Open-PIC standard.
> >
> > +config FSL_MPIC_TIMER_WAKEUP
> > + tristate "Freescale MPIC global timer wakeup driver"
> > + depends on FSL_SOC && MPIC_TIMER
> > + default n
> > + help
> > + This is only for freescale powerpc platform.
>=20
> This sentence is redundant... It already says "Freescale MPIC" in the
> name and depends on "FSL_SOC && MPIC_TIMER".
>=20
Um...yes, I will remove it.
=20
> > +static irqreturn_t fsl_mpic_timer_irq(int irq, void *dev_id) {
> > + struct fsl_mpic_timer_wakeup *wakeup =3D dev_id;
> > +
> > + schedule_work(&wakeup->free_work);
> > + return IRQ_HANDLED;
> > +}
>=20
> return wakeup->timer ? IRQ_HANDLED : IRQ_NONE;
>=20
Looks better, thanks.
> > +
> > +static ssize_t fsl_timer_wakeup_show(struct device *dev,
> > + struct device_attribute *attr,
> > + char *buf)
> > +{
> > + struct timeval interval;
> > + int val =3D 0;
> > +
> > + mutex_lock(&sysfs_lock);
> > + if (fsl_wakeup->timer) {
> > + mpic_get_remain_time(fsl_wakeup->timer, &interval);
> > + val =3D interval.tv_sec + 1;
> > + }
> > + mutex_unlock(&sysfs_lock);
> > +
> > + return sprintf(buf, "%d\n", val);
> > +}
> > +
> > +static ssize_t fsl_timer_wakeup_store(struct device *dev,
> > + struct device_attribute *attr,
> > + const char *buf,
> > + size_t count)
> > +{
> > + struct timeval interval;
> > + int ret;
> > +
> > + interval.tv_usec =3D 0;
> > + if (kstrtol(buf, 0, &interval.tv_sec))
> > + return -EINVAL;
>=20
> I don't think the buffer will NUL-terminated... Ordinarily there'll be
> an LF terminator, but you can't rely on that (many other sysfs attributes
> seem to, though...).
>=20
I think we don't need to care about LF terminator.
The kstrtol--> _kstrtoull has been done.
> > + mutex_lock(&sysfs_lock);
> > +
> > + if (fsl_wakeup->timer && !interval.tv_sec) {
> > + disable_irq_wake(fsl_wakeup->timer->irq);
> > + mpic_free_timer(fsl_wakeup->timer);
> > + fsl_wakeup->timer =3D NULL;
> > + mutex_unlock(&sysfs_lock);
> > +
> > + return count;
> > + }
> > +
> > + if (fsl_wakeup->timer) {
> > + mutex_unlock(&sysfs_lock);
> > + return -EBUSY;
> > + }
>=20
> So to change an already-set timer you have to set it to zero and then to
> what you want? Why not just do:
>=20
> if (fsl_wakeup->timer) {
> disable_irq_wake(...);
> mpic_free_timer(...);
> fsl_wakeup_timer =3D NULL;
> }
>=20
> if (!interval.tv_sec) {
> mutex_unlock(&sysfs_lock);
> return count;
> }
>=20
You can't break up the it.
if echo zero the code will cancel the timer that is currently running.
Not echo non-zero value just zero to cancel.
> > + ret =3D subsys_system_register(&mpic_subsys, NULL);
> > + if (ret)
> > + goto err;
>=20
> Maybe arch/powerpc/sysdev/mpic.c should be doing this?
>=20
This can be registered by mpic. Maybe better than here.
> > +
> > + for (i =3D 0; mpic_attributes[i]; i++) {
> > + ret =3D device_create_file(mpic_subsys.dev_root,
> > + mpic_attributes[i]);
> > + if (ret)
> > + goto err2;
> > + }
>=20
> Is this code ever going to register more than one?
>=20
No, just one. I only keep the style here.
If you don't think it's necessary I can remove this loop.
^ 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