* RE: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS
From: Xie Shaohui-B21989 @ 2013-08-27 10:51 UTC (permalink / raw)
To: Wood Scott-B07421, Anthony Foiani
Cc: Robert P.J.Day, linuxppc-dev@lists.ozlabs.org, Li Yang-Leo-R58472,
Adrian Bunk
In-Reply-To: <20130823192532.GA29205@home.buserror.net>
> As for the property name, I'd prefer "fsl,sata-speed-limit" or "fsl,sata-
> max-generation". Shaohui, do the driver bits look OK?
[S.H] The driver part is OK.=20
I also tested it on p5040, the SATA worked as expected.
Best Regards,=20
Shaohui Xie
^ permalink raw reply
* [PATCH v8 3/3] DMA: Freescale: update driver to support 8-channel DMA engine
From: hongbo.zhang @ 2013-08-27 10:42 UTC (permalink / raw)
To: rob.herring, pawel.moll, mark.rutland, swarren, ian.campbell,
vinod.koul, djbw
Cc: Hongbo Zhang, devicetree, linuxppc-dev, linux-kernel
In-Reply-To: <1377600123-5746-1-git-send-email-hongbo.zhang@freescale.com>
From: Hongbo Zhang <hongbo.zhang@freescale.com>
This patch adds support to 8-channel DMA engine, thus the driver works for both
the new 8-channel and the legacy 4-channel DMA engines.
Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
---
drivers/dma/Kconfig | 9 +++++----
drivers/dma/fsldma.c | 9 ++++++---
drivers/dma/fsldma.h | 2 +-
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 6825957..3979c65 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -89,14 +89,15 @@ config AT_HDMAC
Support the Atmel AHB DMA controller.
config FSL_DMA
- tristate "Freescale Elo and Elo Plus DMA support"
+ tristate "Freescale Elo series DMA support"
depends on FSL_SOC
select DMA_ENGINE
select ASYNC_TX_ENABLE_CHANNEL_SWITCH
---help---
- Enable support for the Freescale Elo and Elo Plus DMA controllers.
- The Elo is the DMA controller on some 82xx and 83xx parts, and the
- Elo Plus is the DMA controller on 85xx and 86xx parts.
+ Enable support for the Freescale Elo series DMA controllers.
+ The Elo is the DMA controller on some mpc82xx and mpc83xx parts, the
+ EloPlus is on mpc85xx and mpc86xx and Pxxx parts, and the Elo3 is on
+ some Txxx and Bxxx parts.
config MPC512X_DMA
tristate "Freescale MPC512x built-in DMA engine support"
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 49e8fbd..16a9a48 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1261,7 +1261,9 @@ static int fsl_dma_chan_probe(struct fsldma_device *fdev,
WARN_ON(fdev->feature != chan->feature);
chan->dev = fdev->dev;
- chan->id = ((res.start - 0x100) & 0xfff) >> 7;
+ chan->id = (res.start & 0xfff) < 0x300 ?
+ ((res.start - 0x100) & 0xfff) >> 7 :
+ ((res.start - 0x200) & 0xfff) >> 7;
if (chan->id >= FSL_DMA_MAX_CHANS_PER_DEVICE) {
dev_err(fdev->dev, "too many channels for device\n");
err = -EINVAL;
@@ -1434,6 +1436,7 @@ static int fsldma_of_remove(struct platform_device *op)
}
static const struct of_device_id fsldma_of_ids[] = {
+ { .compatible = "fsl,elo3-dma", },
{ .compatible = "fsl,eloplus-dma", },
{ .compatible = "fsl,elo-dma", },
{}
@@ -1455,7 +1458,7 @@ static struct platform_driver fsldma_of_driver = {
static __init int fsldma_init(void)
{
- pr_info("Freescale Elo / Elo Plus DMA driver\n");
+ pr_info("Freescale Elo series DMA driver\n");
return platform_driver_register(&fsldma_of_driver);
}
@@ -1467,5 +1470,5 @@ static void __exit fsldma_exit(void)
subsys_initcall(fsldma_init);
module_exit(fsldma_exit);
-MODULE_DESCRIPTION("Freescale Elo / Elo Plus DMA driver");
+MODULE_DESCRIPTION("Freescale Elo series DMA driver");
MODULE_LICENSE("GPL");
diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
index f5c3879..1ffc244 100644
--- a/drivers/dma/fsldma.h
+++ b/drivers/dma/fsldma.h
@@ -112,7 +112,7 @@ struct fsldma_chan_regs {
};
struct fsldma_chan;
-#define FSL_DMA_MAX_CHANS_PER_DEVICE 4
+#define FSL_DMA_MAX_CHANS_PER_DEVICE 8
struct fsldma_device {
void __iomem *regs; /* DGSR register base */
--
1.7.9.5
^ permalink raw reply related
* [PATCH v8 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
From: hongbo.zhang @ 2013-08-27 10:42 UTC (permalink / raw)
To: rob.herring, pawel.moll, mark.rutland, swarren, ian.campbell,
vinod.koul, djbw
Cc: Hongbo Zhang, devicetree, linuxppc-dev, linux-kernel
In-Reply-To: <1377600123-5746-1-git-send-email-hongbo.zhang@freescale.com>
From: Hongbo Zhang <hongbo.zhang@freescale.com>
Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds
the device tree nodes for them.
Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
---
.../devicetree/bindings/powerpc/fsl/dma.txt | 66 ++++++++++++++++
arch/powerpc/boot/dts/fsl/b4si-post.dtsi | 4 +-
arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 81 ++++++++++++++++++++
arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 81 ++++++++++++++++++++
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 4 +-
5 files changed, 232 insertions(+), 4 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
index ddf17af..10fd031 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
@@ -126,6 +126,72 @@ Example:
};
};
+** Freescale Elo3 DMA Controller
+ This is EloPlus controller with 8 channels, used in Freescale Txxx and Bxxx
+ series chips, such as t1040, t4240, b4860.
+
+Required properties:
+
+- compatible : must include "fsl,elo3-dma"
+- reg : <registers specifier for DMA general status reg>
+- ranges : describes the mapping between the address space of the
+ DMA channels and the address space of the DMA controller
+
+- DMA channel nodes:
+ - compatible : must include "fsl,eloplus-dma-channel"
+ - reg : <registers specifier for channel>
+ - interrupts : <interrupt specifier for DMA channel IRQ>
+ - interrupt-parent : optional, if needed for interrupt mapping
+
+Example:
+dma@100300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,elo3-dma";
+ reg = <0x100300 0x4 0x100600 0x4>;
+ ranges = <0x0 0x100100 0x500>;
+ dma-channel@0 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x0 0x80>;
+ interrupts = <28 2 0 0>;
+ };
+ dma-channel@80 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x80 0x80>;
+ interrupts = <29 2 0 0>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x100 0x80>;
+ interrupts = <30 2 0 0>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x180 0x80>;
+ interrupts = <31 2 0 0>;
+ };
+ dma-channel@300 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x300 0x80>;
+ interrupts = <76 2 0 0>;
+ };
+ dma-channel@380 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x380 0x80>;
+ interrupts = <77 2 0 0>;
+ };
+ dma-channel@400 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x400 0x80>;
+ interrupts = <78 2 0 0>;
+ };
+ dma-channel@480 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x480 0x80>;
+ interrupts = <79 2 0 0>;
+ };
+};
+
Note on DMA channel compatible properties: The compatible property must say
"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel" to be used by the Elo DMA
driver (fsldma). Any DMA channel used by fsldma cannot be used by another
diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
index 7399154..ea53ea1 100644
--- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
@@ -223,13 +223,13 @@
reg = <0xe2000 0x1000>;
};
-/include/ "qoriq-dma-0.dtsi"
+/include/ "elo3-dma-0.dtsi"
dma@100300 {
fsl,iommu-parent = <&pamu0>;
fsl,liodn-reg = <&guts 0x580>; /* DMA1LIODNR */
};
-/include/ "qoriq-dma-1.dtsi"
+/include/ "elo3-dma-1.dtsi"
dma@101300 {
fsl,iommu-parent = <&pamu0>;
fsl,liodn-reg = <&guts 0x584>; /* DMA2LIODNR */
diff --git a/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi b/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
new file mode 100644
index 0000000..69a3277
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
@@ -0,0 +1,81 @@
+/*
+ * QorIQ DMA device tree stub [ controller @ offset 0x100000 ]
+ *
+ * Copyright 2013 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.
+ */
+
+dma0: dma@100300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,elo3-dma";
+ reg = <0x100300 0x4 0x100600 0x4>;
+ ranges = <0x0 0x100100 0x500>;
+ dma-channel@0 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x0 0x80>;
+ interrupts = <28 2 0 0>;
+ };
+ dma-channel@80 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x80 0x80>;
+ interrupts = <29 2 0 0>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x100 0x80>;
+ interrupts = <30 2 0 0>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x180 0x80>;
+ interrupts = <31 2 0 0>;
+ };
+ dma-channel@300 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x300 0x80>;
+ interrupts = <76 2 0 0>;
+ };
+ dma-channel@380 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x380 0x80>;
+ interrupts = <77 2 0 0>;
+ };
+ dma-channel@400 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x400 0x80>;
+ interrupts = <78 2 0 0>;
+ };
+ dma-channel@480 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x480 0x80>;
+ interrupts = <79 2 0 0>;
+ };
+};
diff --git a/arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi b/arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
new file mode 100644
index 0000000..d410948
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
@@ -0,0 +1,81 @@
+/*
+ * QorIQ DMA device tree stub [ controller @ offset 0x101000 ]
+ *
+ * Copyright 2013 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.
+ */
+
+dma1: dma@101300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,elo3-dma";
+ reg = <0x101300 0x4 0x101600 0x4>;
+ ranges = <0x0 0x101100 0x500>;
+ dma-channel@0 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x0 0x80>;
+ interrupts = <32 2 0 0>;
+ };
+ dma-channel@80 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x80 0x80>;
+ interrupts = <33 2 0 0>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x100 0x80>;
+ interrupts = <34 2 0 0>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x180 0x80>;
+ interrupts = <35 2 0 0>;
+ };
+ dma-channel@300 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x300 0x80>;
+ interrupts = <80 2 0 0>;
+ };
+ dma-channel@380 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x380 0x80>;
+ interrupts = <81 2 0 0>;
+ };
+ dma-channel@400 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x400 0x80>;
+ interrupts = <82 2 0 0>;
+ };
+ dma-channel@480 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x480 0x80>;
+ interrupts = <83 2 0 0>;
+ };
+};
diff --git a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
index bd611a9..ec95c60 100644
--- a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
@@ -387,8 +387,8 @@
reg = <0xea000 0x4000>;
};
-/include/ "qoriq-dma-0.dtsi"
-/include/ "qoriq-dma-1.dtsi"
+/include/ "elo3-dma-0.dtsi"
+/include/ "elo3-dma-1.dtsi"
/include/ "qoriq-espi-0.dtsi"
spi@110000 {
--
1.7.9.5
^ permalink raw reply related
* [PATCH v8 1/3] DMA: Freescale: revise device tree binding document
From: hongbo.zhang @ 2013-08-27 10:42 UTC (permalink / raw)
To: rob.herring, pawel.moll, mark.rutland, swarren, ian.campbell,
vinod.koul, djbw
Cc: Hongbo Zhang, devicetree, linuxppc-dev, linux-kernel
In-Reply-To: <1377600123-5746-1-git-send-email-hongbo.zhang@freescale.com>
From: Hongbo Zhang <hongbo.zhang@freescale.com>
This patch updates the discription of each type of DMA controller and its
channels, it is preparation for adding another new DMA controller binding, it
also fixes some defects of indent for text alignment at the same time.
Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
---
.../devicetree/bindings/powerpc/fsl/dma.txt | 62 +++++++++-----------
1 file changed, 27 insertions(+), 35 deletions(-)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
index 2a4b4bc..ddf17af 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
@@ -1,33 +1,29 @@
-* Freescale 83xx DMA Controller
+* Freescale DMA Controllers
-Freescale PowerPC 83xx have on chip general purpose DMA controllers.
+** Freescale Elo DMA Controller
+ This is a little-endian DMA controller, used in Freescale mpc83xx series
+ chips such as mpc8315, mpc8349, mpc8379 etc.
Required properties:
-- compatible : compatible list, contains 2 entries, first is
- "fsl,CHIP-dma", where CHIP is the processor
- (mpc8349, mpc8360, etc.) and the second is
- "fsl,elo-dma"
-- reg : <registers mapping for DMA general status reg>
-- ranges : Should be defined as specified in 1) to describe the
- DMA controller channels.
+- compatible : must include "fsl,elo-dma"
+- reg : <registers specifier for DMA general status reg>
+- ranges : describes the mapping between the address space of the
+ DMA channels and the address space of the DMA controller
- cell-index : controller index. 0 for controller @ 0x8100
-- interrupts : <interrupt mapping for DMA IRQ>
+- interrupts : <interrupt specifier for DMA IRQ>
- interrupt-parent : optional, if needed for interrupt mapping
-
- DMA channel nodes:
- - compatible : compatible list, contains 2 entries, first is
- "fsl,CHIP-dma-channel", where CHIP is the processor
- (mpc8349, mpc8350, etc.) and the second is
- "fsl,elo-dma-channel". However, see note below.
- - reg : <registers mapping for channel>
+ - compatible : must include "fsl,elo-dma-channel"
+ However, see note below.
+ - reg : <registers specifier for channel>
- cell-index : dma channel index starts at 0.
Optional properties:
- - interrupts : <interrupt mapping for DMA channel IRQ>
- (on 83xx this is expected to be identical to
- the interrupts property of the parent node)
+ - interrupts : <interrupt specifier for DMA channel IRQ>
+ (on 83xx this is expected to be identical to
+ the interrupts property of the parent node)
- interrupt-parent : optional, if needed for interrupt mapping
Example:
@@ -70,30 +66,26 @@ Example:
};
};
-* Freescale 85xx/86xx DMA Controller
-
-Freescale PowerPC 85xx/86xx have on chip general purpose DMA controllers.
+** Freescale EloPlus DMA Controller
+ This is DMA controller with extended addresses and chaining, mainly used in
+ Freescale mpc85xx/86xx, Pxxx and BSC series chips, such as mpc8540, mpc8641
+ p4080, bsc9131 etc.
Required properties:
-- compatible : compatible list, contains 2 entries, first is
- "fsl,CHIP-dma", where CHIP is the processor
- (mpc8540, mpc8540, etc.) and the second is
- "fsl,eloplus-dma"
-- reg : <registers mapping for DMA general status reg>
+- compatible : must include "fsl,eloplus-dma"
+- reg : <registers specifier for DMA general status reg>
- cell-index : controller index. 0 for controller @ 0x21000,
1 for controller @ 0xc000
-- ranges : Should be defined as specified in 1) to describe the
- DMA controller channels.
+- ranges : describes the mapping between the address space of the
+ DMA channels and the address space of the DMA controller
- DMA channel nodes:
- - compatible : compatible list, contains 2 entries, first is
- "fsl,CHIP-dma-channel", where CHIP is the processor
- (mpc8540, mpc8560, etc.) and the second is
- "fsl,eloplus-dma-channel". However, see note below.
+ - compatible : must include "fsl,eloplus-dma-channel"
+ However, see note below.
- cell-index : dma channel index starts at 0.
- - reg : <registers mapping for channel>
- - interrupts : <interrupt mapping for DMA channel IRQ>
+ - reg : <registers specifier for channel>
+ - interrupts : <interrupt specifier for DMA channel IRQ>
- interrupt-parent : optional, if needed for interrupt mapping
Example:
--
1.7.9.5
^ permalink raw reply related
* [PATCH v8 0/3] DMA: Freescale: Add support for 8-channel DMA engine
From: hongbo.zhang @ 2013-08-27 10:42 UTC (permalink / raw)
To: rob.herring, pawel.moll, mark.rutland, swarren, ian.campbell,
vinod.koul, djbw
Cc: Hongbo Zhang, devicetree, linuxppc-dev, linux-kernel
From: Hongbo Zhang <hongbo.zhang@freescale.com>
Hi DMA and DT maintainers, please have a look at these V8 patches.
Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch set
adds support this DMA engine.
V7->V8 changes:
- change the word "mapping" to "specifier" for reg and interrupts description
V6->V7 changes:
- only remove unnecessary "CHIP-dma" explanations in [1/3]
V5->V6 changes:
- minor updates of descriptions in binding document and Kconfig
- remove [4/4], that should be another patch in future
V4->V5 changes:
- update description in the dt binding document, to make it more resonable
- add new patch [4/4] to eliminate a compiling warning which already exists
for a long time
V3->V4 changes:
- introduce new patch [1/3] to revise the legacy dma binding document
- and then add new paragraph to describe new dt node binding in [2/3]
- rebase to latest kernel v3.11-rc1
V2->V3 changes:
- edit Documentation/devicetree/bindings/powerpc/fsl/dma.txt
- edit text string in Kconfig and the driver files, using "elo series" to
mention all the current "elo*"
V1->V2 changes:
- removed the codes handling the register dgsr1, since it isn't used currently
- renamed the DMA DT compatible to "fsl,elo3-dma"
- renamed the new dts files to "elo3-dma-<n>.dtsi"
Hongbo Zhang (3):
DMA: Freescale: revise device tree binding document
DMA: Freescale: Add new 8-channel DMA engine device tree nodes
DMA: Freescale: update driver to support 8-channel DMA engine
.../devicetree/bindings/powerpc/fsl/dma.txt | 128 ++++++++++++++------
arch/powerpc/boot/dts/fsl/b4si-post.dtsi | 4 +-
arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 81 +++++++++++++
arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 81 +++++++++++++
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 4 +-
drivers/dma/Kconfig | 9 +-
drivers/dma/fsldma.c | 9 +-
drivers/dma/fsldma.h | 2 +-
8 files changed, 271 insertions(+), 47 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
--
1.7.9.5
^ permalink raw reply
* Re: [RFC PATCH v2 06/11] pstore: Add decompression support to pstore
From: Aruna Balakrishnaiah @ 2013-08-27 9:39 UTC (permalink / raw)
To: Seiji Aguchi
Cc: jkenisto@linux.vnet.ibm.com, tony.luck@intel.com,
keescook@chromium.org, mahesh@linux.vnet.ibm.com,
ccross@android.com, linux-kernel@vger.kernel.org,
linuxppc-dev@ozlabs.org, cbouatmailru@gmail.com
In-Reply-To: <A5ED84D3BB3A384992CBB9C77DEDA4D443E8F0B8@USINDEM103.corp.hds.com>
On Friday 23 August 2013 04:34 AM, Seiji Aguchi wrote:
>
>> -----Original Message-----
>> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Aruna Balakrishnaiah
>> Sent: Friday, August 16, 2013 9:18 AM
>> To: linuxppc-dev@ozlabs.org; tony.luck@intel.com; linux-kernel@vger.kernel.org; keescook@chromium.org
>> Cc: jkenisto@linux.vnet.ibm.com; ananth@in.ibm.com; benh@kernel.crashing.org; cbouatmailru@gmail.com;
>> mahesh@linux.vnet.ibm.com; ccross@android.com
>> Subject: [RFC PATCH v2 06/11] pstore: Add decompression support to pstore
>>
>> Based on the flag 'compressed' set or not, pstore will decompress the
>> data returning a plain text file. If decompression fails for a particular
>> record it will have the compressed data in the file which can be
>> decompressed with 'openssl' command line tool.
> If the decompression fails and openssl doesn't work, the worst case is that users can't read the entry.
> In that case, pstore is meaningless at all.
If decompression fails and openssl doesn't work. We have python module zlib to
decompress
the zlib data. zlib.decompress() should do the trick.
> Also, for users who want to get a single panic message, a compression is not needed.
>
> So, I think we still have to support non-compression mode.
> (IMO, pstore can take kdump as a model. Kdump supports both compression and non-compression mode.)
>
> But, if you think my comment is outside this patchset, it's OK.
> We can make it with a separate patch.
>
> Seiji
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* [PATCH] powerpc/powernv: Create opal sysfs directory
From: Vasant Hegde @ 2013-08-27 9:39 UTC (permalink / raw)
To: linuxppc-dev, benh
Create /sys/firmware/opal directory. We wil use this
interface to fetch opal error logs, firmware update, etc.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/opal.h | 3 +++
arch/powerpc/platforms/powernv/opal.c | 21 ++++++++++++++++++++-
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index ba6ffe6..4432b7a 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -523,6 +523,9 @@ typedef struct oppanel_line {
uint64_t line_len;
} oppanel_line_t;
+/* /sys/firmware/opal */
+extern struct kobject *opal_kobj;
+
/* API functions */
int64_t opal_console_write(int64_t term_number, int64_t *length,
const uint8_t *buffer);
diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c
index 106301f..1c48a68 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -17,11 +17,15 @@
#include <linux/interrupt.h>
#include <linux/notifier.h>
#include <linux/slab.h>
+#include <linux/kobject.h>
#include <asm/opal.h>
#include <asm/firmware.h>
#include "powernv.h"
+/* /sys/firmware/opal */
+struct kobject *opal_kobj;
+
struct opal {
u64 base;
u64 entry;
@@ -369,6 +373,17 @@ static irqreturn_t opal_interrupt(int irq, void *data)
return IRQ_HANDLED;
}
+static int opal_sysfs_init(void)
+{
+ opal_kobj = kobject_create_and_add("opal", firmware_kobj);
+ if (!opal_kobj) {
+ pr_warn("kobject_create_and_add opal failed\n");
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
static int __init opal_init(void)
{
struct device_node *np, *consoles;
@@ -412,7 +427,11 @@ static int __init opal_init(void)
" (0x%x)\n", rc, irq, hwirq);
opal_irqs[i] = irq;
}
- return 0;
+
+ /* Create "opal" kobject under /sys/firmware */
+ rc = opal_sysfs_init();
+
+ return rc;
}
subsys_initcall(opal_init);
^ permalink raw reply related
* RE: [PATCH 0/2] fs: supply inode uid/gid setting interface
From: David Laight @ 2013-08-27 9:20 UTC (permalink / raw)
To: Rui Xiang, Greg KH
Cc: linux-s390, linux-ia64, linux-rdma, netdev, linux-usb,
linux-kernel, linux-mm, viro, v9fs-developer, linux-fsdevel,
cgroups, linuxppc-dev
In-Reply-To: <5217100E.6080506@huawei.com>
> Subject: Re: [PATCH 0/2] fs: supply inode uid/gid setting interface
>=20
> On 2013/8/23 12:10, Greg KH wrote:
> > On Fri, Aug 23, 2013 at 10:48:36AM +0800, Rui Xiang wrote:
> >> This patchset implements an accessor functions to set uid/gid
> >> in inode struct. Just finish code clean up.
> >
> > Why?
> >
> It can introduce a new function to reduce some codes.
> Just clean up.
In what sense is it a 'cleanup' ?
To my mind it just means that anyone reading the code has
to go and look at another file in order to see what the
function does (it might be expected to be more complex).
It also adds run time cost, while probably not directly
measurable I suspect it more than doubles the execution
time of that code fragment - do that everywhere and the
system will run like a sick pig.
The only real use for accessor functions is when you
don't want the structure offset to be public.
In this case that is obviously not the case since
all the drivers are directly accessing other members
of the structure.
David
^ permalink raw reply
* Re: [PATCH] powerpc: Work around gcc miscompilation of __pa() on 64-bit
From: Paul Mackerras @ 2013-08-27 9:03 UTC (permalink / raw)
To: Alan Modra; +Cc: linuxppc-dev
In-Reply-To: <20130827071235.GQ3430@bubble.grove.modra.org>
On Tue, Aug 27, 2013 at 04:42:35PM +0930, Alan Modra wrote:
> On Tue, Aug 27, 2013 at 04:07:49PM +1000, Paul Mackerras wrote:
> > On 64-bit, __pa(&static_var) gets miscompiled by recent versions of
> > gcc as something like:
> >
> > addis 3,2,.LANCHOR1+4611686018427387904@toc@ha
> > addi 3,3,.LANCHOR1+4611686018427387904@toc@l
>
> I might argue that this isn't a miscompilation, since -mcmodel=medium
> assumes everything can be accessed within +/-2G of the toc pointer,
And there's the bug right there... the assumption that this number
that I want to compute is the address of something that can be
accessed. It isn't, and gcc shouldn't treat it as such (not unless I
do something like subsequently casting it back to a pointer and
dereferencing that).
> but it's definitely a problem since gas and/or ld don't give an
> overflow error. They would except for the fact that our ABI has a
> hole in it.
Well, that and the fact that the code in gcc that generates
instructions to compute addresses blindly uses addis; addi even when
the offset involved is way too large for that to possibly work.
Paul.
^ permalink raw reply
* [PATCH v2 3/3] powerpc/85xx: add hardware automatically enter pw20 state
From: Dongsheng Wang @ 2013-08-27 8:41 UTC (permalink / raw)
To: scottwood, galak; +Cc: linuxppc-dev, Wang Dongsheng
In-Reply-To: <1377592900-5020-1-git-send-email-dongsheng.wang@freescale.com>
From: Wang Dongsheng <dongsheng.wang@freescale.com>
Using hardware features make core automatically enter PW20 state.
Set a TB count to hardware, the effective count begins when PW10
is entered. When the effective period has expired, the core will
proceed from PW10 to PW20 if no exit conditions have occurred during
the period.
Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
---
Remove:
delete setup_idle_hw_governor function.
delete "Fix erratum" for rev1.
Move:
move setup_* into __setup/restore_cpu_e6500.
diff --git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h
index 8364bbe..e846495 100644
--- a/arch/powerpc/include/asm/reg_booke.h
+++ b/arch/powerpc/include/asm/reg_booke.h
@@ -219,6 +219,7 @@
/* Bit definitions for PWRMGTCR0. */
#define PWRMGTCR0_ALTIVEC_IDLE (1 << 22) /* Altivec idle enable */
+#define PWRMGTCR0_PW20_WAIT (1 << 14) /* PW20 state enable bit */
/* Bit definitions for the MCSR. */
#define MCSR_MCS 0x80000000 /* Machine Check Summary */
diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index 90bbb46..295ccb5 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -59,6 +59,7 @@ _GLOBAL(__setup_cpu_e6500)
bl .setup_altivec_ivors
#endif
bl setup_altivec_idle
+ bl setup_pw20_idle
bl __setup_cpu_e5500
mtlr r6
blr
@@ -121,6 +122,7 @@ _GLOBAL(__restore_cpu_e6500)
mflr r5
bl .setup_altivec_ivors
bl setup_altivec_idle
+ bl setup_pw20_idle
bl __restore_cpu_e5500
mtlr r5
blr
diff --git a/arch/powerpc/platforms/85xx/common.c b/arch/powerpc/platforms/85xx/common.c
index 93b563b..cdd526e 100644
--- a/arch/powerpc/platforms/85xx/common.c
+++ b/arch/powerpc/platforms/85xx/common.c
@@ -15,12 +15,22 @@
#define ALTIVEC_COUNT_OFFSET 16
#define ALTIVEC_IDLE_COUNT_MASK 0x003f0000
+#define PW20_COUNT_OFFSET 8
+#define PW20_IDLE_COUNT_MASK 0x00003f00
/*
* FIXME - We don't know the AltiVec application scenarios.
*/
#define ALTIVEC_IDLE_TIME_BIT 14 /* 1ms */
+/*
+ * FIXME - We don't know, what time should we let the core into PW20 state.
+ * because we don't know the current state of the cpu load. And threads are
+ * independent, so we can not know the state of different thread has been
+ * idle.
+ */
+#define PW20_IDLE_TIME_BIT 14 /* 1ms */
+
static struct of_device_id __initdata mpc85xx_common_ids[] = {
{ .type = "soc", },
{ .compatible = "soc", },
@@ -125,3 +135,25 @@ void setup_altivec_idle(void)
mtspr(SPRN_PWRMGTCR0, altivec_idle);
}
+
+void setup_pw20_idle(void)
+{
+ u32 pw20_idle;
+
+ if (!has_pw20_altivec_idle())
+ return;
+
+ pw20_idle = mfspr(SPRN_PWRMGTCR0);
+
+ /* Set PW20_WAIT bit, Enable PW20 State */
+ pw20_idle |= PWRMGTCR0_PW20_WAIT;
+
+ /* Set Automatic PW20 Core Idle Count */
+ /* clear count */
+ pw20_idle &= ~PW20_IDLE_COUNT_MASK;
+
+ /* set count */
+ pw20_idle |= ((MAX_BIT - PW20_IDLE_TIME_BIT) << PW20_COUNT_OFFSET);
+
+ mtspr(SPRN_PWRMGTCR0, pw20_idle);
+}
--
1.8.0
^ permalink raw reply related
* [PATCH v2 2/3] powerpc/85xx: add hardware automatically enter altivec idle state
From: Dongsheng Wang @ 2013-08-27 8:41 UTC (permalink / raw)
To: scottwood, galak; +Cc: linuxppc-dev, Wang Dongsheng
In-Reply-To: <1377592900-5020-1-git-send-email-dongsheng.wang@freescale.com>
From: Wang Dongsheng <dongsheng.wang@freescale.com>
Each core's AltiVec unit may be placed into a power savings mode
by turning off power to the unit. Core hardware will automatically
power down the AltiVec unit after no AltiVec instructions have
executed in N cycles. The AltiVec power-control is triggered by hardware.
Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
---
*v2:
Remove:
delete setup_idle_hw_governor function.
delete "Fix erratum" for rev1.
Move:
move setup_* into __setup/restore_cpu_e6500.
diff --git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h
index 86ede76..8364bbe 100644
--- a/arch/powerpc/include/asm/reg_booke.h
+++ b/arch/powerpc/include/asm/reg_booke.h
@@ -217,6 +217,9 @@
#define CCR1_DPC 0x00000100 /* Disable L1 I-Cache/D-Cache parity checking */
#define CCR1_TCS 0x00000080 /* Timer Clock Select */
+/* Bit definitions for PWRMGTCR0. */
+#define PWRMGTCR0_ALTIVEC_IDLE (1 << 22) /* Altivec idle enable */
+
/* Bit definitions for the MCSR. */
#define MCSR_MCS 0x80000000 /* Machine Check Summary */
#define MCSR_IB 0x40000000 /* Instruction PLB Error */
diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index bfb18c7..90bbb46 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -58,6 +58,7 @@ _GLOBAL(__setup_cpu_e6500)
#ifdef CONFIG_PPC64
bl .setup_altivec_ivors
#endif
+ bl setup_altivec_idle
bl __setup_cpu_e5500
mtlr r6
blr
@@ -119,6 +120,7 @@ _GLOBAL(__setup_cpu_e5500)
_GLOBAL(__restore_cpu_e6500)
mflr r5
bl .setup_altivec_ivors
+ bl setup_altivec_idle
bl __restore_cpu_e5500
mtlr r5
blr
diff --git a/arch/powerpc/platforms/85xx/common.c b/arch/powerpc/platforms/85xx/common.c
index d0861a0..93b563b 100644
--- a/arch/powerpc/platforms/85xx/common.c
+++ b/arch/powerpc/platforms/85xx/common.c
@@ -11,6 +11,16 @@
#include "mpc85xx.h"
+#define MAX_BIT 64
+
+#define ALTIVEC_COUNT_OFFSET 16
+#define ALTIVEC_IDLE_COUNT_MASK 0x003f0000
+
+/*
+ * FIXME - We don't know the AltiVec application scenarios.
+ */
+#define ALTIVEC_IDLE_TIME_BIT 14 /* 1ms */
+
static struct of_device_id __initdata mpc85xx_common_ids[] = {
{ .type = "soc", },
{ .compatible = "soc", },
@@ -80,3 +90,38 @@ void __init mpc85xx_cpm2_pic_init(void)
irq_set_chained_handler(irq, cpm2_cascade);
}
#endif
+
+static bool has_pw20_altivec_idle(void)
+{
+ u32 pvr;
+
+ pvr = mfspr(SPRN_PVR);
+
+ /* PW20 & AltiVec idle feature only exists for E6500 */
+ if (PVR_VER(pvr) != PVR_VER_E6500)
+ return false;
+
+ return true;
+}
+
+void setup_altivec_idle(void)
+{
+ u32 altivec_idle;
+
+ if (!has_pw20_altivec_idle())
+ return;
+
+ /* Enable Altivec Idle */
+ altivec_idle = mfspr(SPRN_PWRMGTCR0);
+ altivec_idle |= PWRMGTCR0_ALTIVEC_IDLE;
+
+ /* Set Automatic AltiVec Idle Count */
+ /* clear count */
+ altivec_idle &= ~ALTIVEC_IDLE_COUNT_MASK;
+
+ /* set count */
+ altivec_idle |=
+ ((MAX_BIT - ALTIVEC_IDLE_TIME_BIT) << ALTIVEC_COUNT_OFFSET);
+
+ mtspr(SPRN_PWRMGTCR0, altivec_idle);
+}
--
1.8.0
^ permalink raw reply related
* [PATCH v2 1/3] powerpc/fsl: add E6500 PVR and SPRN_PWRMGTCR0 define
From: Dongsheng Wang @ 2013-08-27 8:41 UTC (permalink / raw)
To: scottwood, galak; +Cc: linuxppc-dev, Wang Dongsheng
From: Wang Dongsheng <dongsheng.wang@freescale.com>
E6500 PVR and SPRN_PWRMGTCR0 will be used in subsequent pw20/altivec idle patches.
Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index 64264bf..d4160ca 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -1053,6 +1053,8 @@
#define PVR_8560 0x80200000
#define PVR_VER_E500V1 0x8020
#define PVR_VER_E500V2 0x8021
+#define PVR_VER_E6500 0x8040
+
/*
* For the 8xx processors, all of them report the same PVR family for
* the PowerPC core. The various versions of these processors must be
diff --git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h
index ed8f836..86ede76 100644
--- a/arch/powerpc/include/asm/reg_booke.h
+++ b/arch/powerpc/include/asm/reg_booke.h
@@ -170,6 +170,7 @@
#define SPRN_L2CSR1 0x3FA /* L2 Data Cache Control and Status Register 1 */
#define SPRN_DCCR 0x3FA /* Data Cache Cacheability Register */
#define SPRN_ICCR 0x3FB /* Instruction Cache Cacheability Register */
+#define SPRN_PWRMGTCR0 0x3FB /* Power management control register 0 */
#define SPRN_SVR 0x3FF /* System Version Register */
/*
--
1.8.0
^ permalink raw reply related
* Re: [PATCH v8] KVM: PPC: reserve a capability and ioctl numbers for realmode VFIO
From: Alexey Kardashevskiy @ 2013-08-27 8:42 UTC (permalink / raw)
To: Gleb Natapov
Cc: kvm, Alexander Graf, linux-kernel, Paul Mackerras, linuxppc-dev,
David Gibson
In-Reply-To: <20130827075600.GE22899@redhat.com>
On 08/27/2013 05:56 PM, Gleb Natapov wrote:
> On Thu, Aug 15, 2013 at 05:49:26PM +1000, Alexey Kardashevskiy wrote:
>> This is to reserve a capablity number for upcoming support
>> of VFIO-IOMMU DMA operations in real mode.
>>
>> The last ioctl in the group which KVM_CREATE_SPAPR_TCE_IOMMU is added to
>> is 0xac, the next two numbers are taken - 0xad for KVM_KVMCLOCK_CTRL and
> 0xac was also taken by KVM_SET_ONE_REG :(
>
>> 0xae for KVM_ARM_VCPU_INIT. So the KVM_CREATE_SPAPR_TCE_IOMMU ioclt gets
>> 0xaf.
>>
>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>
>> ---
>> Changes:
>> 2013/08/15 v8:
>> * fixed comment again
>>
>> 2013/08/15:
>> * fixed mistype in comments
>> * fixed commit message which says what uses ioctls 0xad and 0xae
>>
>> 2013/07/16:
>> * changed the number
>>
>> 2013/07/11:
>> * changed order in a file, added comment about a gap in ioctl number
>> ---
>> include/uapi/linux/kvm.h | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
>> index 99c2533..bd94127 100644
>> --- a/include/uapi/linux/kvm.h
>> +++ b/include/uapi/linux/kvm.h
>> @@ -668,6 +668,7 @@ struct kvm_ppc_smmu_info {
>> #define KVM_CAP_IRQ_XICS 92
>> #define KVM_CAP_ARM_EL1_32BIT 93
>> #define KVM_CAP_SPAPR_MULTITCE 94
>> +#define KVM_CAP_SPAPR_TCE_IOMMU 95
>>
>> #ifdef KVM_CAP_IRQ_ROUTING
>>
>> @@ -933,6 +934,11 @@ struct kvm_s390_ucas_mapping {
>> #define KVM_ARM_SET_DEVICE_ADDR _IOW(KVMIO, 0xab, struct kvm_arm_device_addr)
>> /* Available with KVM_CAP_PPC_RTAS */
>> #define KVM_PPC_RTAS_DEFINE_TOKEN _IOW(KVMIO, 0xac, struct kvm_rtas_token_args)
>> +/* 0xad is taken by KVM_KVMCLOCK_CTRL */
>> +/* 0xae is taken by KVM_ARM_VCPU_INIT */
>> +/* Available with KVM_CAP_SPAPR_TCE_IOMMU */
>> +#define KVM_CREATE_SPAPR_TCE_IOMMU _IOW(KVMIO, 0xaf, \
>> + struct kvm_create_spapr_tce_iommu)
>>
> Why not use KVM_CREATE_DEVICE API for that?
Because when I came up with my ioctl first time, it was not in upstream and
since then nobody pointed me to this new ioctl :)
So my stuff is not going to upstream again. Heh. Ok. I'll implement it.
>
>> /* ioctl for vm fd */
>> #define KVM_CREATE_DEVICE _IOWR(KVMIO, 0xe0, struct kvm_create_device)
--
Alexey
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/irq: remove the unneeded flag PACA_IRQ_EE_EDGE
From: Kevin Hao @ 2013-08-27 8:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc
In-Reply-To: <1377590004.3819.120.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 963 bytes --]
On Tue, Aug 27, 2013 at 05:53:24PM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2013-04-11 at 09:32 +0800, Kevin Hao wrote:
> > In order to support the Book3E external proxy, the flag
> > PACA_IRQ_EE_EDGE was introduced in patch 7230c564 (powerpc: Rework
> > lazy-interrupt handling). But it turns out that this is not needed.
> > And it is also not used by any code in the current kernel. According
> > to the PowerISA 2.0.6, the content of EPR (External Proxy Register)
> > is valid until MSR[EE] is set to 1. Since we never enable the hard irq
> > before replaying a external interrupt. That means we still can get
> > the valid interrupt vector from EPR when replaying irq.
>
> I assume you understand why that patch is broken and this is superseeded
> by your more recent series to actually make use of PACA_IRQ_EE_EDGE
> right ? :-)
Yes.
>
> (Just making sure I can take that one out of patchwork).
Definitely.
Thanks,
Kevin
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH v8] KVM: PPC: reserve a capability and ioctl numbers for realmode VFIO
From: Gleb Natapov @ 2013-08-27 7:56 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: kvm, Alexander Graf, linux-kernel, Paul Mackerras, linuxppc-dev,
David Gibson
In-Reply-To: <1376552966-8529-1-git-send-email-aik@ozlabs.ru>
On Thu, Aug 15, 2013 at 05:49:26PM +1000, Alexey Kardashevskiy wrote:
> This is to reserve a capablity number for upcoming support
> of VFIO-IOMMU DMA operations in real mode.
>
> The last ioctl in the group which KVM_CREATE_SPAPR_TCE_IOMMU is added to
> is 0xac, the next two numbers are taken - 0xad for KVM_KVMCLOCK_CTRL and
0xac was also taken by KVM_SET_ONE_REG :(
> 0xae for KVM_ARM_VCPU_INIT. So the KVM_CREATE_SPAPR_TCE_IOMMU ioclt gets
> 0xaf.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>
> ---
> Changes:
> 2013/08/15 v8:
> * fixed comment again
>
> 2013/08/15:
> * fixed mistype in comments
> * fixed commit message which says what uses ioctls 0xad and 0xae
>
> 2013/07/16:
> * changed the number
>
> 2013/07/11:
> * changed order in a file, added comment about a gap in ioctl number
> ---
> include/uapi/linux/kvm.h | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 99c2533..bd94127 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -668,6 +668,7 @@ struct kvm_ppc_smmu_info {
> #define KVM_CAP_IRQ_XICS 92
> #define KVM_CAP_ARM_EL1_32BIT 93
> #define KVM_CAP_SPAPR_MULTITCE 94
> +#define KVM_CAP_SPAPR_TCE_IOMMU 95
>
> #ifdef KVM_CAP_IRQ_ROUTING
>
> @@ -933,6 +934,11 @@ struct kvm_s390_ucas_mapping {
> #define KVM_ARM_SET_DEVICE_ADDR _IOW(KVMIO, 0xab, struct kvm_arm_device_addr)
> /* Available with KVM_CAP_PPC_RTAS */
> #define KVM_PPC_RTAS_DEFINE_TOKEN _IOW(KVMIO, 0xac, struct kvm_rtas_token_args)
> +/* 0xad is taken by KVM_KVMCLOCK_CTRL */
> +/* 0xae is taken by KVM_ARM_VCPU_INIT */
> +/* Available with KVM_CAP_SPAPR_TCE_IOMMU */
> +#define KVM_CREATE_SPAPR_TCE_IOMMU _IOW(KVMIO, 0xaf, \
> + struct kvm_create_spapr_tce_iommu)
>
Why not use KVM_CREATE_DEVICE API for that?
> /* ioctl for vm fd */
> #define KVM_CREATE_DEVICE _IOWR(KVMIO, 0xe0, struct kvm_create_device)
> --
> 1.8.3.2
--
Gleb.
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/irq: remove the unneeded flag PACA_IRQ_EE_EDGE
From: Benjamin Herrenschmidt @ 2013-08-27 7:53 UTC (permalink / raw)
To: Kevin Hao; +Cc: linuxppc
In-Reply-To: <1365643954-20798-2-git-send-email-haokexin@gmail.com>
On Thu, 2013-04-11 at 09:32 +0800, Kevin Hao wrote:
> In order to support the Book3E external proxy, the flag
> PACA_IRQ_EE_EDGE was introduced in patch 7230c564 (powerpc: Rework
> lazy-interrupt handling). But it turns out that this is not needed.
> And it is also not used by any code in the current kernel. According
> to the PowerISA 2.0.6, the content of EPR (External Proxy Register)
> is valid until MSR[EE] is set to 1. Since we never enable the hard irq
> before replaying a external interrupt. That means we still can get
> the valid interrupt vector from EPR when replaying irq.
I assume you understand why that patch is broken and this is superseeded
by your more recent series to actually make use of PACA_IRQ_EE_EDGE
right ? :-)
(Just making sure I can take that one out of patchwork).
> Signed-off-by: Kevin Hao <haokexin@gmail.com>
> ---
> arch/powerpc/include/asm/hw_irq.h | 1 -
> arch/powerpc/kernel/exceptions-64e.S | 1 -
> arch/powerpc/kernel/irq.c | 8 --------
> 3 files changed, 10 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/hw_irq.h b/arch/powerpc/include/asm/hw_irq.h
> index e45c494..8bf0789 100644
> --- a/arch/powerpc/include/asm/hw_irq.h
> +++ b/arch/powerpc/include/asm/hw_irq.h
> @@ -24,7 +24,6 @@
> #define PACA_IRQ_DBELL 0x02
> #define PACA_IRQ_EE 0x04
> #define PACA_IRQ_DEC 0x08 /* Or FIT */
> -#define PACA_IRQ_EE_EDGE 0x10 /* BookE only */
>
> #endif /* CONFIG_PPC64 */
>
> diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S
> index 42a756e..64f2fbd 100644
> --- a/arch/powerpc/kernel/exceptions-64e.S
> +++ b/arch/powerpc/kernel/exceptions-64e.S
> @@ -701,7 +701,6 @@ kernel_dbg_exc:
> .endm
>
> masked_interrupt_book3e_0x500:
> - // XXX When adding support for EPR, use PACA_IRQ_EE_EDGE
> masked_interrupt_book3e PACA_IRQ_EE 1
>
> masked_interrupt_book3e_0x900:
> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> index 4f97fe3..dbc1c05 100644
> --- a/arch/powerpc/kernel/irq.c
> +++ b/arch/powerpc/kernel/irq.c
> @@ -171,14 +171,6 @@ notrace unsigned int __check_irq_replay(void)
> return 0x500;
>
> #ifdef CONFIG_PPC_BOOK3E
> - /* Finally check if an EPR external interrupt happened
> - * this bit is typically set if we need to handle another
> - * "edge" interrupt from within the MPIC "EPR" handler
> - */
> - local_paca->irq_happened &= ~PACA_IRQ_EE_EDGE;
> - if (happened & PACA_IRQ_EE_EDGE)
> - return 0x500;
> -
> local_paca->irq_happened &= ~PACA_IRQ_DBELL;
> if (happened & PACA_IRQ_DBELL)
> return 0x280;
^ permalink raw reply
* [PATCH] powerpc: Set the NOTE type for SPE regset
From: Suzuki K. Poulose @ 2013-08-27 7:52 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, aneesh.kumar, Roland McGrath
The regset defintion for SPE doesn't have the core_note_type
set, which prevents it from being dumped. Add the note type
NT_PPC_SPE for SPE regset.
Signed-off-by: Suzuki K Poulose <suzuki@in.ibm.com>
Cc: Roland McGrath <roland@hack.frob.com>
---
arch/powerpc/kernel/ptrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 9a0d24c..16edc5d 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -657,7 +657,7 @@ static const struct user_regset native_regsets[] = {
#endif
#ifdef CONFIG_SPE
[REGSET_SPE] = {
- .n = 35,
+ .core_note_type = NT_PPC_SPE, .n = 35,
.size = sizeof(u32), .align = sizeof(u32),
.active = evr_active, .get = evr_get, .set = evr_set
},
^ permalink raw reply related
* Re: [PATCH] i2c: powermac: fix return path on error
From: Benjamin Herrenschmidt @ 2013-08-27 7:42 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, linux-i2c
In-Reply-To: <1376918295-6961-1-git-send-email-wsa@the-dreams.de>
On Mon, 2013-08-19 at 15:18 +0200, Wolfram Sang wrote:
> We want to bail out immediately if i2c_add_adapter failed and not try to
> register child nodes with a nilled adapter structure.
>
> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> drivers/i2c/busses/i2c-powermac.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-powermac.c b/drivers/i2c/busses/i2c-powermac.c
> index 8dc90da..bb81773 100644
> --- a/drivers/i2c/busses/i2c-powermac.c
> +++ b/drivers/i2c/busses/i2c-powermac.c
> @@ -446,6 +446,7 @@ static int i2c_powermac_probe(struct platform_device *dev)
> printk(KERN_ERR "i2c-powermac: Adapter %s registration "
> "failed\n", adapter->name);
> memset(adapter, 0, sizeof(*adapter));
> + return rc;
> }
>
> printk(KERN_INFO "PowerMac i2c bus %s registered\n", adapter->name);
> @@ -455,7 +456,7 @@ static int i2c_powermac_probe(struct platform_device *dev)
> */
> i2c_powermac_register_devices(adapter, bus);
>
> - return rc;
> + return 0;
> }
>
> static struct platform_driver i2c_powermac_driver = {
^ permalink raw reply
* Re: [PATCH v2 2/2] Register bootmem pages
From: Benjamin Herrenschmidt @ 2013-08-27 7:39 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linuxppc-dev
In-Reply-To: <1377575091.3819.97.camel@pasglop>
On Tue, 2013-08-27 at 13:44 +1000, Benjamin Herrenschmidt wrote:
> So I still feel very uncomfortable with that stuff ....
>
> For example, x86 calls register_page_bootmem_info_node() at boot time,
> which does that strange "get_page_bootmem" on the NODE_DATA itself at
> boot time, we don't. Should we ?
Bah, call me an idiot ... I was looking at the code without your patch
and not realizing that this is exactly what your patch does :-)
.../...
> There's a whole pile of totally undocumented / uncommented generic code
> with horrible function names in there whose sematic is very very
> unclear.
>
> Now, if we call that thing, are we expected to have
> register_paqe_bootmem_memmap() to actually do something right? I assume
> that means actually calling get_page_bootmem() on the various struct
> page that comprise the vmemmap.
>
> Well, we can probably implement that since we maintain a list of all the
> vmemap pages... However, we don't implement vmemmap_free(). Should we ?
This still stands, should we actually "register" the pages of the
vmemmap or not ?
What happens if we remove a chunk of memory and then plug it back in ?
Will it try to re-create a new vmemmap chunk for that area (where we
haven't removed the previous one) ? That might cause problems if we end
up putting duplicate entries in the hash table ... should we implement
vmemmap_free and actual unmap the segments ?
> Cheers,
> Ben.
>
> >
> > ---
> > arch/powerpc/mm/init_64.c | 4 ++++
> > arch/powerpc/mm/mem.c | 9 +++++++++
> > mm/Kconfig | 2 +-
> > 3 files changed, 14 insertions(+), 1 deletion(-)
> >
> > Index: linux/arch/powerpc/mm/init_64.c
> > ===================================================================
> > --- linux.orig/arch/powerpc/mm/init_64.c
> > +++ linux/arch/powerpc/mm/init_64.c
> > @@ -300,5 +300,9 @@ void vmemmap_free(unsigned long start, u
> > {
> > }
> >
> > +void register_page_bootmem_memmap(unsigned long section_nr,
> > + struct page *start_page, unsigned long size)
> > +{
> > +}
> > #endif /* CONFIG_SPARSEMEM_VMEMMAP */
> >
> > Index: linux/arch/powerpc/mm/mem.c
> > ===================================================================
> > --- linux.orig/arch/powerpc/mm/mem.c
> > +++ linux/arch/powerpc/mm/mem.c
> > @@ -297,12 +297,21 @@ void __init paging_init(void)
> > }
> > #endif /* ! CONFIG_NEED_MULTIPLE_NODES */
> >
> > +static void __init register_page_bootmem_info(void)
> > +{
> > + int i;
> > +
> > + for_each_online_node(i)
> > + register_page_bootmem_info_node(NODE_DATA(i));
> > +}
> > +
> > void __init mem_init(void)
> > {
> > #ifdef CONFIG_SWIOTLB
> > swiotlb_init(0);
> > #endif
> >
> > + register_page_bootmem_info();
> > high_memory = (void *) __va(max_low_pfn * PAGE_SIZE);
> > set_max_mapnr(max_pfn);
> > free_all_bootmem();
> > Index: linux/mm/Kconfig
> > ===================================================================
> > --- linux.orig/mm/Kconfig
> > +++ linux/mm/Kconfig
> > @@ -183,7 +183,7 @@ config MEMORY_HOTPLUG_SPARSE
> > config MEMORY_HOTREMOVE
> > bool "Allow for memory hot remove"
> > select MEMORY_ISOLATION
> > - select HAVE_BOOTMEM_INFO_NODE if X86_64
> > + select HAVE_BOOTMEM_INFO_NODE if (X86_64 || PPC64)
> > depends on MEMORY_HOTPLUG && ARCH_ENABLE_MEMORY_HOTREMOVE
> > depends on MIGRATION
> >
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH 02/10] KVM: PPC: reserve a capability number for multitce support
From: Benjamin Herrenschmidt @ 2013-08-27 7:35 UTC (permalink / raw)
To: Gleb Natapov
Cc: kvm, linux-doc, Alexey Kardashevskiy, linux-kernel, kvm-ppc,
Alexander Graf, Paul Mackerras, linuxppc-dev
In-Reply-To: <20130827064114.GC22899@redhat.com>
On Tue, 2013-08-27 at 09:41 +0300, Gleb Natapov wrote:
> > Oh and Alexey mentions that there are two capabilities and you only
> > applied one :-)
> >
> Another one is:
> [PATCH v8] KVM: PPC: reserve a capability and ioctl numbers for
> realmode VFIO
> ?
Yes, thanks !
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 02/10] KVM: PPC: reserve a capability number for multitce support
From: Benjamin Herrenschmidt @ 2013-08-27 7:34 UTC (permalink / raw)
To: Gleb Natapov
Cc: kvm, linux-doc, Alexey Kardashevskiy, linux-kernel, kvm-ppc,
Alexander Graf, Paul Mackerras, linuxppc-dev
In-Reply-To: <20130827064026.GB22899@redhat.com>
On Tue, 2013-08-27 at 09:40 +0300, Gleb Natapov wrote:
> > Thanks. Since it's not in a topic branch that I can pull, I'm going to
> > just cherry-pick them. However, they are in your "queue" branch, not
> > "next" branch. Should I still assume this is a stable branch and that
> > the numbers aren't going to change ?
> >
> Queue will become next after I will test it and if test will fail the
> commit hash may change, but since you are going to cherry-pick and this
> does not preserve commit hash it does not matter.
Right, as long as the actual cap and ioctl numbers remain stable :-)
Cheers,
Ben.
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2013-08-27 7:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, Linux Kernel list
Hi Linus !
Here are 3 bug fixes that should probably go into 3.11 since I'm also
tagging them for stable.
Once fixes our old /proc/powerpc/lparcfg file which provides partition
informations when running under our hypervisor and also acts as a
user-triggerable Oops when hot :-(
The other two respectively are a one liner to fix a HVSI protocol
handshake problem causing the console to fail to show up on a bunch of
machines until we reach userspace, which I deem annoying enough to
warrant going to stable, and a nasty gcc miscompile causing us to
pass virtual instead of physical addresses to the firmware under some
circumstances.
Cheers,
Ben.
The following changes since commit 28e61cc466d8daace4b0f04ba2b83e0bd68f5832:
powerpc/tm: Fix context switching TAR, PPR and DSCR SPRs (2013-08-09 18:07:12 +1000)
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 d220980b701d838560a70de691b53be007e99e78:
powerpc/hvsi: Increase handshake timeout from 200ms to 400ms. (2013-08-27 16:59:56 +1000)
----------------------------------------------------------------
Benjamin Herrenschmidt (1):
powerpc: Don't Oops when accessing /proc/powerpc/lparcfg without hypervisor
Eugene Surovegin (1):
powerpc/hvsi: Increase handshake timeout from 200ms to 400ms.
Paul Mackerras (1):
powerpc: Work around gcc miscompilation of __pa() on 64-bit
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/page.h | 10 ++++++++++
arch/powerpc/kernel/lparcfg.c | 22 +++++++++-------------
drivers/tty/hvc/hvsi_lib.c | 4 ++--
4 files changed, 22 insertions(+), 15 deletions(-)
^ permalink raw reply
* Re: [PATCH] powerpc: Work around gcc miscompilation of __pa() on 64-bit
From: Alan Modra @ 2013-08-27 7:12 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20130827060749.GA16462@drongo>
On Tue, Aug 27, 2013 at 04:07:49PM +1000, Paul Mackerras wrote:
> On 64-bit, __pa(&static_var) gets miscompiled by recent versions of
> gcc as something like:
>
> addis 3,2,.LANCHOR1+4611686018427387904@toc@ha
> addi 3,3,.LANCHOR1+4611686018427387904@toc@l
I might argue that this isn't a miscompilation, since -mcmodel=medium
assumes everything can be accessed within +/-2G of the toc pointer,
but it's definitely a problem since gas and/or ld don't give an
overflow error. They would except for the fact that our ABI has a
hole in it.
We have relocs that error on 16-bit overflow, eg.
addi 3,2,x@toc
will give an error if x is more than +/-32k from the toc pointer, but
@ha and _HA/_HI relocs don't error on 32-bit overflow. (They can't,
because they were really designed to be used in HIHGESTA, HIGHERA, HA,
LO sequences to build up 64-bit values.)
The proper fix is to define a whole slew of new relocations and reloc
specifiers, and modify everything to use them, but that seems like too
much bother. I had ideas once upon a time to implement gas and ld
options that makes @ha and _HA report overflows, but haven't found one
of those round tuits.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply
* Re: [PATCH 02/10] KVM: PPC: reserve a capability number for multitce support
From: Gleb Natapov @ 2013-08-27 6:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: kvm, linux-doc, Alexey Kardashevskiy, linux-kernel, kvm-ppc,
Alexander Graf, Paul Mackerras, linuxppc-dev
In-Reply-To: <1377577362.3819.103.camel@pasglop>
On Tue, Aug 27, 2013 at 02:22:42PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2013-08-27 at 14:19 +1000, Benjamin Herrenschmidt wrote:
> > On Mon, 2013-08-26 at 15:37 +0300, Gleb Natapov wrote:
> > > > Gleb, any chance you can put this (and the next one) into a tree to
> > > > "lock in" the numbers ?
> > > >
> > > Applied it. Sorry for slow response, was on vocation and still go
> > > through the email backlog.
> >
> > Thanks. Since it's not in a topic branch that I can pull, I'm going to
> > just cherry-pick them. However, they are in your "queue" branch, not
> > "next" branch. Should I still assume this is a stable branch and that
> > the numbers aren't going to change ?
>
> Oh and Alexey mentions that there are two capabilities and you only
> applied one :-)
>
Another one is:
[PATCH v8] KVM: PPC: reserve a capability and ioctl numbers for realmode VFIO
?
--
Gleb.
^ permalink raw reply
* [PATCH] powerpc: Don't Oops when accessing /proc/powerpc/lparcfg without hypervisor
From: Benjamin Herrenschmidt @ 2013-08-27 6:41 UTC (permalink / raw)
To: linuxppc-dev
/proc/powerpc/lparcfg is an ancient facility (though still actively used)
which allows access to some informations relative to the partition when
running underneath a PAPR compliant hypervisor.
It makes no sense on non-pseries machines. However, currently, not only
can it be created on these if the kernel has pseries support, but accessing
it on such a machine will crash due to trying to do hypervisor calls.
In fact, it should also not do HV calls on older pseries that didn't have
an hypervisor either.
Finally, it has the plumbing to be a module but is a "bool" Kconfig option.
This fixes the whole lot by turning it into a machine_device_initcall
that is only created on pseries, and adding the necessary hypervisor
check before calling the H_GET_EM_PARMS hypercall
CC: <stable@vger.kernel.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Next I'll move it to arch/powerpc/platforms/pseries but in a separate
patch.
arch/powerpc/kernel/lparcfg.c | 22 +++++++++-------------
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/kernel/lparcfg.c b/arch/powerpc/kernel/lparcfg.c
index d92f387..e2a0a16 100644
--- a/arch/powerpc/kernel/lparcfg.c
+++ b/arch/powerpc/kernel/lparcfg.c
@@ -35,7 +35,13 @@
#include <asm/vdso_datapage.h>
#include <asm/vio.h>
#include <asm/mmu.h>
+#include <asm/machdep.h>
+
+/*
+ * This isn't a module but we expose that to userspace
+ * via /proc so leave the definitions here
+ */
#define MODULE_VERS "1.9"
#define MODULE_NAME "lparcfg"
@@ -418,7 +424,8 @@ static void parse_em_data(struct seq_file *m)
{
unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
- if (plpar_hcall(H_GET_EM_PARMS, retbuf) == H_SUCCESS)
+ if (firmware_has_feature(FW_FEATURE_LPAR) &&
+ plpar_hcall(H_GET_EM_PARMS, retbuf) == H_SUCCESS)
seq_printf(m, "power_mode_data=%016lx\n", retbuf[0]);
}
@@ -677,7 +684,6 @@ static int lparcfg_open(struct inode *inode, struct file *file)
}
static const struct file_operations lparcfg_fops = {
- .owner = THIS_MODULE,
.read = seq_read,
.write = lparcfg_write,
.open = lparcfg_open,
@@ -699,14 +705,4 @@ static int __init lparcfg_init(void)
}
return 0;
}
-
-static void __exit lparcfg_cleanup(void)
-{
- remove_proc_subtree("powerpc/lparcfg", NULL);
-}
-
-module_init(lparcfg_init);
-module_exit(lparcfg_cleanup);
-MODULE_DESCRIPTION("Interface for LPAR configuration data");
-MODULE_AUTHOR("Dave Engebretsen");
-MODULE_LICENSE("GPL");
+machine_device_initcall(pseries, lparcfg_init);
^ permalink raw reply related
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