[PATCH v2 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
This patch add S/PDIF controller driver for Freescale SoC.
Reviewed-by: Lars-Peter Clausen l...@metafoo.de
Signed-off-by: Nicolin Chen b42...@freescale.com
---
.../devicetree/bindings/sound/fsl,spdif.txt| 62 +
sound/soc/fsl/Kconfig |3 +
sound/soc/fsl/Makefile |2 +
sound/soc/fsl/fsl_spdif.c | 1311
sound/soc/fsl/fsl_spdif.h | 227
5 files changed, 1605 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/fsl,spdif.txt
create mode 100644 sound/soc/fsl/fsl_spdif.c
create mode 100644 sound/soc/fsl/fsl_spdif.h
diff --git a/Documentation/devicetree/bindings/sound/fsl,spdif.txt
b/Documentation/devicetree/bindings/sound/fsl,spdif.txt
new file mode 100644
index 000..8b1bfe2
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,spdif.txt
@@ -0,0 +1,62 @@
+Freescale Sony/Philips Digital Interface Format (S/PDIF) Controller
+
+The Freescale S/PDIF audio block is a stereo transceiver that allows the
+processor to receive and transmit digital audio via an coaxial cable or
+a fibre cable.
+
+Required properties:
+
+ - compatible : Compatible list, contains fsl,fsl-spdif or SoC specific
+ fsl,imx6q-spdif, fsl,imx6sl-spdif.
+
+ - reg : Offset and length of the register set for the device.
+
+ - interrupts : Should contain spdif interrupt.
+
+ - dmas : Generic dma devicetree binding as described in
+ Documentation/devicetree/bindings/dma/dma.txt.
+
+ - dma-names : Two dmas have to be defined, tx and rx.
+
+ - clocks : (First) The phandle for the clock ID registered in clock tree.
+ There could be two clocks being set here, but only the first one, CORE
+ clock, is must.
+
+
+Optional properties:
+
+ - clocks : (Second) The phandle for the clock ID registered in clock tree.
+ There could be two clocks being set here, but the second one, TX clock is
+ optional. If absent, the TX clock will use CORE clock as default.
+
+ - clock-names : The names for the two clocks. It will be required only when
+ the second clock's present. If absent, the TX clock will use CORE clock as
+ default.
+
+ - tx-clk-source : The clock cources for Tx. Need to set this source according
+ to the SoC datasheet in SPDIF_STC section. If absent, the default source is
+ value 0x1 - CCM spdif0_clk_root input.
+
+ - rx-clk-source : The clock cource for Rx. Need to set this source according
+ to the SoC datasheet in SPDIF_SRPC section. If absent, the default source is
+ value 0x0 - if (DPLL Locked) SPDIF_RxClk else extal.
+
+
+Example:
+
+spdif: spdif@02004000 {
+ compatible = fsl,fsl-spdif;
+ reg = 0x02004000 0x4000;
+ interrupts = 0 52 0x04;
+ dmas = sdma 14 18 0,
+ sdma 15 18 0;
+ dma-names = rx, tx;
+
+ clocks = clks 197, clks 197;
+ clock-names = core, tx;
+
+ tx-clk-source = 0x1;
+ rx-clk-source = 0x0;
+
+ status = okay;
+};
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index c26449b..74f533b 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -1,6 +1,9 @@
config SND_SOC_FSL_SSI
tristate
+config SND_SOC_FSL_SPDIF
+ tristate
+
config SND_SOC_FSL_UTILS
tristate
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index d4b4aa8..4b5970e 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -12,9 +12,11 @@ obj-$(CONFIG_SND_SOC_P1022_RDK) += snd-soc-p1022-rdk.o
# Freescale PowerPC SSI/DMA Platform Support
snd-soc-fsl-ssi-objs := fsl_ssi.o
+snd-soc-fsl-spdif-objs := fsl_spdif.o
snd-soc-fsl-utils-objs := fsl_utils.o
snd-soc-fsl-dma-objs := fsl_dma.o
obj-$(CONFIG_SND_SOC_FSL_SSI) += snd-soc-fsl-ssi.o
+obj-$(CONFIG_SND_SOC_FSL_SPDIF) += snd-soc-fsl-spdif.o
obj-$(CONFIG_SND_SOC_FSL_UTILS) += snd-soc-fsl-utils.o
obj-$(CONFIG_SND_SOC_POWERPC_DMA) += snd-soc-fsl-dma.o
diff --git a/sound/soc/fsl/fsl_spdif.c b/sound/soc/fsl/fsl_spdif.c
new file mode 100644
index 000..8865499
--- /dev/null
+++ b/sound/soc/fsl/fsl_spdif.c
@@ -0,0 +1,1311 @@
+/*
+ * Freescale S/PDIF ALSA SoC Digital Audio Interface (DAI) driver
+ *
+ * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ *
+ * Based on stmp3xxx_spdif_dai.c
+ * Vladimir Barinov vbari...@embeddedalley.com
+ * Copyright 2008 SigmaTel, Inc
+ * Copyright 2008 Embedded Alley Solutions, Inc
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include linux/module.h
+#include linux/clk.h
+#include linux/of_address.h
+#include linux/of_device.h
+#include linux/of_irq.h
+
+#include sound/asoundef.h
+#include sound/soc.h
+#include sound/dmaengine_pcm.h
+
+#include fsl_spdif.h
+#include imx-pcm.h
+
+#define FSL_SPDIF_TXFIFO_WML 0x8
+#define FSL_SPDIF_RXFIFO_WML 0x8
+
+#define
[PATCH v2 0/2] Add freescale S/PDIF CPU DAI and machine drivers
Changelog: v1-v2: * Dropped one applied patch for spdif dummy codec drivers. * Use generic DMA DT binding. * Let spdif controller driver calculate the clock div. * Added one optional clock source for spdif tx. * Reivsed documentation accordingly. Nicolin Chen (2): ASoC: fsl: Add S/PDIF CPU DAI driver ASoC: fsl: Add S/PDIF machine driver .../devicetree/bindings/sound/fsl,spdif.txt| 62 + .../devicetree/bindings/sound/imx-audio-spdif.txt | 29 + sound/soc/fsl/Kconfig | 14 + sound/soc/fsl/Makefile |4 + sound/soc/fsl/fsl_spdif.c | 1311 sound/soc/fsl/fsl_spdif.h | 227 sound/soc/fsl/imx-spdif.c | 134 ++ 7 files changed, 1781 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/fsl,spdif.txt create mode 100644 Documentation/devicetree/bindings/sound/imx-audio-spdif.txt create mode 100644 sound/soc/fsl/fsl_spdif.c create mode 100644 sound/soc/fsl/fsl_spdif.h create mode 100644 sound/soc/fsl/imx-spdif.c ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 2/2] ASoC: fsl: Add S/PDIF machine driver
Add S/PDIF machine driver for Freescale i.MX series SoC.
Signed-off-by: Nicolin Chen b42...@freescale.com
---
.../devicetree/bindings/sound/imx-audio-spdif.txt | 29 +
sound/soc/fsl/Kconfig | 11 ++
sound/soc/fsl/Makefile |2 +
sound/soc/fsl/imx-spdif.c | 134
4 files changed, 176 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
create mode 100644 sound/soc/fsl/imx-spdif.c
diff --git a/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
b/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
new file mode 100644
index 000..9a3fa26
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
@@ -0,0 +1,29 @@
+Freescale i.MX audio complex with S/PDIF transceiver
+
+Required properties:
+
+ - compatible : fsl,imx-audio-spdif
+
+ - model : The user-visible name of this sound complex
+
+ - spdif-controller : The phandle of the i.MX S/PDIF controller
+
+
+Optional properties:
+
+ - spdif-transmitter : The phandle of the spdif-transmitter dummy codec
+
+ - spdif-receiver : The phandle of the spdif-receiver dummy codec
+
+* Note: At least one of these two properties should be set in the DT binding.
+
+
+Example:
+
+sound-spdif {
+ compatible = fsl,imx-audio-spdif;
+ model = imx-spdif;
+ spdif-controller = spdif;
+ spdif-transmitter = spdif_tx_codec;
+ spdif-receiver = spdif_rx_codec;
+};
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 74f533b..9043abc 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -195,6 +195,17 @@ config SND_SOC_IMX_SGTL5000
Say Y if you want to add support for SoC audio on an i.MX board with
a sgtl5000 codec.
+config SND_SOC_IMX_SPDIF
+ tristate SoC Audio support for i.MX boards with S/PDIF
+ select SND_SOC_IMX_PCM_DMA
+ select SND_SOC_FSL_SPDIF
+ select SND_SOC_FSL_UTILS
+ select SND_SOC_SPDIF
+ help
+ SoC Audio support for i.MX boards with S/PDIF
+ Say Y if you want to add support for SoC audio on an i.MX board with
+ a S/DPDIF.
+
config SND_SOC_IMX_MC13783
tristate SoC Audio support for I.MX boards with mc13783
depends on MFD_MC13783 ARCH_ARM
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index 4b5970e..e2aaff7 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -45,6 +45,7 @@ snd-soc-mx27vis-aic32x4-objs := mx27vis-aic32x4.o
snd-soc-wm1133-ev1-objs := wm1133-ev1.o
snd-soc-imx-sgtl5000-objs := imx-sgtl5000.o
snd-soc-imx-wm8962-objs := imx-wm8962.o
+snd-soc-imx-spdif-objs :=imx-spdif.o
snd-soc-imx-mc13783-objs := imx-mc13783.o
obj-$(CONFIG_SND_SOC_EUKREA_TLV320) += snd-soc-eukrea-tlv320.o
@@ -53,4 +54,5 @@ obj-$(CONFIG_SND_SOC_MX27VIS_AIC32X4) +=
snd-soc-mx27vis-aic32x4.o
obj-$(CONFIG_SND_MXC_SOC_WM1133_EV1) += snd-soc-wm1133-ev1.o
obj-$(CONFIG_SND_SOC_IMX_SGTL5000) += snd-soc-imx-sgtl5000.o
obj-$(CONFIG_SND_SOC_IMX_WM8962) += snd-soc-imx-wm8962.o
+obj-$(CONFIG_SND_SOC_IMX_SPDIF) += snd-soc-imx-spdif.o
obj-$(CONFIG_SND_SOC_IMX_MC13783) += snd-soc-imx-mc13783.o
diff --git a/sound/soc/fsl/imx-spdif.c b/sound/soc/fsl/imx-spdif.c
new file mode 100644
index 000..893f3d1
--- /dev/null
+++ b/sound/soc/fsl/imx-spdif.c
@@ -0,0 +1,134 @@
+/*
+ * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include linux/module.h
+#include linux/of_platform.h
+#include sound/soc.h
+
+struct imx_spdif_data {
+ struct snd_soc_dai_link dai[2];
+ struct snd_soc_card card;
+};
+
+static int imx_spdif_audio_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev-dev.of_node;
+ struct device_node *spdif_np, *codec_tx_np, *codec_rx_np;
+ struct platform_device *spdif_pdev;
+ struct imx_spdif_data *data;
+ int ret = 0, num_links = 0;
+
+ spdif_np = of_parse_phandle(np, spdif-controller, 0);
+ if (!spdif_np) {
+ dev_err(pdev-dev, failed to find spdif-controller\n);
+ ret = -EINVAL;
+ goto fail;
+ }
+
+ spdif_pdev = of_find_device_by_node(spdif_np);
+ if (!spdif_pdev) {
+ dev_err(pdev-dev, failed to find S/PDIF device\n);
+ ret = -EINVAL;
+ goto fail;
+ }
+
+ data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev, failed to allocate memory\n);
+ ret = -ENOMEM;
+ goto fail;
+ }
+
+ codec_tx_np = of_parse_phandle(np,
Re: [alsa-devel] [PATCH v2 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
On 08/05/2013 08:09 AM, Nicolin Chen wrote: This patch add S/PDIF controller driver for Freescale SoC. Reviewed-by: Lars-Peter Clausen l...@metafoo.de You are supposed to only add tags (Acked-by, Reviewed-by, Signed-off-by, etc.) for other people if they have explicitly said they are OK with it. Reviewed-by means that the person has looked at the current patch and thinks it looks good, not that the person has commented on a previous version of the patch. Signed-off-by: Nicolin Chen b42...@freescale.com [...] ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
On Mon, Aug 05, 2013 at 09:12:01AM +0200, Lars-Peter Clausen wrote: You are supposed to only add tags (Acked-by, Reviewed-by, Signed-off-by, etc.) for other people if they have explicitly said they are OK with it. Reviewed-by means that the person has looked at the current patch and thinks it looks good, not that the person has commented on a previous version of the patch. Oh, I was misunderstanding about it. Thank you for telling me this. I'll sent a v3 to remove the tag. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 0/2] Add freescale S/PDIF CPU DAI and machine drivers
Changelog: v2-v3: * Removed a wrong tag from the commit of patch-1. v1-v2: * Dropped one applied patch for spdif dummy codec drivers. * Use generic DMA DT binding. * Let spdif controller driver calculate the clock div. * Added one optional clock source for spdif tx. * Reivsed documentation accordingly. Nicolin Chen (2): ASoC: fsl: Add S/PDIF CPU DAI driver ASoC: fsl: Add S/PDIF machine driver .../devicetree/bindings/sound/fsl,spdif.txt| 62 + .../devicetree/bindings/sound/imx-audio-spdif.txt | 29 + sound/soc/fsl/Kconfig | 14 + sound/soc/fsl/Makefile |4 + sound/soc/fsl/fsl_spdif.c | 1311 sound/soc/fsl/fsl_spdif.h | 227 sound/soc/fsl/imx-spdif.c | 134 ++ 7 files changed, 1781 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/fsl,spdif.txt create mode 100644 Documentation/devicetree/bindings/sound/imx-audio-spdif.txt create mode 100644 sound/soc/fsl/fsl_spdif.c create mode 100644 sound/soc/fsl/fsl_spdif.h create mode 100644 sound/soc/fsl/imx-spdif.c ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
This patch add S/PDIF controller driver for Freescale SoC.
Signed-off-by: Nicolin Chen b42...@freescale.com
---
.../devicetree/bindings/sound/fsl,spdif.txt| 62 +
sound/soc/fsl/Kconfig |3 +
sound/soc/fsl/Makefile |2 +
sound/soc/fsl/fsl_spdif.c | 1311
sound/soc/fsl/fsl_spdif.h | 227
5 files changed, 1605 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/fsl,spdif.txt
create mode 100644 sound/soc/fsl/fsl_spdif.c
create mode 100644 sound/soc/fsl/fsl_spdif.h
diff --git a/Documentation/devicetree/bindings/sound/fsl,spdif.txt
b/Documentation/devicetree/bindings/sound/fsl,spdif.txt
new file mode 100644
index 000..8b1bfe2
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,spdif.txt
@@ -0,0 +1,62 @@
+Freescale Sony/Philips Digital Interface Format (S/PDIF) Controller
+
+The Freescale S/PDIF audio block is a stereo transceiver that allows the
+processor to receive and transmit digital audio via an coaxial cable or
+a fibre cable.
+
+Required properties:
+
+ - compatible : Compatible list, contains fsl,fsl-spdif or SoC specific
+ fsl,imx6q-spdif, fsl,imx6sl-spdif.
+
+ - reg : Offset and length of the register set for the device.
+
+ - interrupts : Should contain spdif interrupt.
+
+ - dmas : Generic dma devicetree binding as described in
+ Documentation/devicetree/bindings/dma/dma.txt.
+
+ - dma-names : Two dmas have to be defined, tx and rx.
+
+ - clocks : (First) The phandle for the clock ID registered in clock tree.
+ There could be two clocks being set here, but only the first one, CORE
+ clock, is must.
+
+
+Optional properties:
+
+ - clocks : (Second) The phandle for the clock ID registered in clock tree.
+ There could be two clocks being set here, but the second one, TX clock is
+ optional. If absent, the TX clock will use CORE clock as default.
+
+ - clock-names : The names for the two clocks. It will be required only when
+ the second clock's present. If absent, the TX clock will use CORE clock as
+ default.
+
+ - tx-clk-source : The clock cources for Tx. Need to set this source according
+ to the SoC datasheet in SPDIF_STC section. If absent, the default source is
+ value 0x1 - CCM spdif0_clk_root input.
+
+ - rx-clk-source : The clock cource for Rx. Need to set this source according
+ to the SoC datasheet in SPDIF_SRPC section. If absent, the default source is
+ value 0x0 - if (DPLL Locked) SPDIF_RxClk else extal.
+
+
+Example:
+
+spdif: spdif@02004000 {
+ compatible = fsl,fsl-spdif;
+ reg = 0x02004000 0x4000;
+ interrupts = 0 52 0x04;
+ dmas = sdma 14 18 0,
+ sdma 15 18 0;
+ dma-names = rx, tx;
+
+ clocks = clks 197, clks 197;
+ clock-names = core, tx;
+
+ tx-clk-source = 0x1;
+ rx-clk-source = 0x0;
+
+ status = okay;
+};
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index c26449b..74f533b 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -1,6 +1,9 @@
config SND_SOC_FSL_SSI
tristate
+config SND_SOC_FSL_SPDIF
+ tristate
+
config SND_SOC_FSL_UTILS
tristate
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index d4b4aa8..4b5970e 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -12,9 +12,11 @@ obj-$(CONFIG_SND_SOC_P1022_RDK) += snd-soc-p1022-rdk.o
# Freescale PowerPC SSI/DMA Platform Support
snd-soc-fsl-ssi-objs := fsl_ssi.o
+snd-soc-fsl-spdif-objs := fsl_spdif.o
snd-soc-fsl-utils-objs := fsl_utils.o
snd-soc-fsl-dma-objs := fsl_dma.o
obj-$(CONFIG_SND_SOC_FSL_SSI) += snd-soc-fsl-ssi.o
+obj-$(CONFIG_SND_SOC_FSL_SPDIF) += snd-soc-fsl-spdif.o
obj-$(CONFIG_SND_SOC_FSL_UTILS) += snd-soc-fsl-utils.o
obj-$(CONFIG_SND_SOC_POWERPC_DMA) += snd-soc-fsl-dma.o
diff --git a/sound/soc/fsl/fsl_spdif.c b/sound/soc/fsl/fsl_spdif.c
new file mode 100644
index 000..8865499
--- /dev/null
+++ b/sound/soc/fsl/fsl_spdif.c
@@ -0,0 +1,1311 @@
+/*
+ * Freescale S/PDIF ALSA SoC Digital Audio Interface (DAI) driver
+ *
+ * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ *
+ * Based on stmp3xxx_spdif_dai.c
+ * Vladimir Barinov vbari...@embeddedalley.com
+ * Copyright 2008 SigmaTel, Inc
+ * Copyright 2008 Embedded Alley Solutions, Inc
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include linux/module.h
+#include linux/clk.h
+#include linux/of_address.h
+#include linux/of_device.h
+#include linux/of_irq.h
+
+#include sound/asoundef.h
+#include sound/soc.h
+#include sound/dmaengine_pcm.h
+
+#include fsl_spdif.h
+#include imx-pcm.h
+
+#define FSL_SPDIF_TXFIFO_WML 0x8
+#define FSL_SPDIF_RXFIFO_WML 0x8
+
+#define INTR_FOR_PLAYBACK (INT_TXFIFO_RESYNC)
+#define
[PATCH v3 2/2] ASoC: fsl: Add S/PDIF machine driver
Add S/PDIF machine driver for Freescale i.MX series SoC.
Signed-off-by: Nicolin Chen b42...@freescale.com
---
.../devicetree/bindings/sound/imx-audio-spdif.txt | 29 +
sound/soc/fsl/Kconfig | 11 ++
sound/soc/fsl/Makefile |2 +
sound/soc/fsl/imx-spdif.c | 134
4 files changed, 176 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
create mode 100644 sound/soc/fsl/imx-spdif.c
diff --git a/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
b/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
new file mode 100644
index 000..9a3fa26
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
@@ -0,0 +1,29 @@
+Freescale i.MX audio complex with S/PDIF transceiver
+
+Required properties:
+
+ - compatible : fsl,imx-audio-spdif
+
+ - model : The user-visible name of this sound complex
+
+ - spdif-controller : The phandle of the i.MX S/PDIF controller
+
+
+Optional properties:
+
+ - spdif-transmitter : The phandle of the spdif-transmitter dummy codec
+
+ - spdif-receiver : The phandle of the spdif-receiver dummy codec
+
+* Note: At least one of these two properties should be set in the DT binding.
+
+
+Example:
+
+sound-spdif {
+ compatible = fsl,imx-audio-spdif;
+ model = imx-spdif;
+ spdif-controller = spdif;
+ spdif-transmitter = spdif_tx_codec;
+ spdif-receiver = spdif_rx_codec;
+};
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 74f533b..9043abc 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -195,6 +195,17 @@ config SND_SOC_IMX_SGTL5000
Say Y if you want to add support for SoC audio on an i.MX board with
a sgtl5000 codec.
+config SND_SOC_IMX_SPDIF
+ tristate SoC Audio support for i.MX boards with S/PDIF
+ select SND_SOC_IMX_PCM_DMA
+ select SND_SOC_FSL_SPDIF
+ select SND_SOC_FSL_UTILS
+ select SND_SOC_SPDIF
+ help
+ SoC Audio support for i.MX boards with S/PDIF
+ Say Y if you want to add support for SoC audio on an i.MX board with
+ a S/DPDIF.
+
config SND_SOC_IMX_MC13783
tristate SoC Audio support for I.MX boards with mc13783
depends on MFD_MC13783 ARCH_ARM
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index 4b5970e..e2aaff7 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -45,6 +45,7 @@ snd-soc-mx27vis-aic32x4-objs := mx27vis-aic32x4.o
snd-soc-wm1133-ev1-objs := wm1133-ev1.o
snd-soc-imx-sgtl5000-objs := imx-sgtl5000.o
snd-soc-imx-wm8962-objs := imx-wm8962.o
+snd-soc-imx-spdif-objs :=imx-spdif.o
snd-soc-imx-mc13783-objs := imx-mc13783.o
obj-$(CONFIG_SND_SOC_EUKREA_TLV320) += snd-soc-eukrea-tlv320.o
@@ -53,4 +54,5 @@ obj-$(CONFIG_SND_SOC_MX27VIS_AIC32X4) +=
snd-soc-mx27vis-aic32x4.o
obj-$(CONFIG_SND_MXC_SOC_WM1133_EV1) += snd-soc-wm1133-ev1.o
obj-$(CONFIG_SND_SOC_IMX_SGTL5000) += snd-soc-imx-sgtl5000.o
obj-$(CONFIG_SND_SOC_IMX_WM8962) += snd-soc-imx-wm8962.o
+obj-$(CONFIG_SND_SOC_IMX_SPDIF) += snd-soc-imx-spdif.o
obj-$(CONFIG_SND_SOC_IMX_MC13783) += snd-soc-imx-mc13783.o
diff --git a/sound/soc/fsl/imx-spdif.c b/sound/soc/fsl/imx-spdif.c
new file mode 100644
index 000..893f3d1
--- /dev/null
+++ b/sound/soc/fsl/imx-spdif.c
@@ -0,0 +1,134 @@
+/*
+ * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include linux/module.h
+#include linux/of_platform.h
+#include sound/soc.h
+
+struct imx_spdif_data {
+ struct snd_soc_dai_link dai[2];
+ struct snd_soc_card card;
+};
+
+static int imx_spdif_audio_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev-dev.of_node;
+ struct device_node *spdif_np, *codec_tx_np, *codec_rx_np;
+ struct platform_device *spdif_pdev;
+ struct imx_spdif_data *data;
+ int ret = 0, num_links = 0;
+
+ spdif_np = of_parse_phandle(np, spdif-controller, 0);
+ if (!spdif_np) {
+ dev_err(pdev-dev, failed to find spdif-controller\n);
+ ret = -EINVAL;
+ goto fail;
+ }
+
+ spdif_pdev = of_find_device_by_node(spdif_np);
+ if (!spdif_pdev) {
+ dev_err(pdev-dev, failed to find S/PDIF device\n);
+ ret = -EINVAL;
+ goto fail;
+ }
+
+ data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev, failed to allocate memory\n);
+ ret = -ENOMEM;
+ goto fail;
+ }
+
+ codec_tx_np = of_parse_phandle(np,
[PATCH 2/3] powerpc: Fix hypervisor facility unavaliable vector number
Currently if we take hypervisor facility unavaliable (from 0xf80/0x4f80) we mark it as an OS facility unavaliable (0xf60) as the two share the same code path. The becomes a problem in facility_unavailable_exception() as we aren't able to see the hypervisor facility unavailable exceptions. Below fixes this by duplication the required macros. Signed-off-by: Michael Neuling mi...@neuling.org --- arch/powerpc/kernel/exceptions-64s.S | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S index 4e00d22..902ca3c 100644 --- a/arch/powerpc/kernel/exceptions-64s.S +++ b/arch/powerpc/kernel/exceptions-64s.S @@ -848,7 +848,7 @@ hv_facility_unavailable_relon_trampoline: . = 0x4f80 SET_SCRATCH0(r13) EXCEPTION_PROLOG_0(PACA_EXGEN) - b facility_unavailable_relon_hv + b hv_facility_unavailable_relon_hv STD_RELON_EXCEPTION_PSERIES(0x5300, 0x1300, instruction_breakpoint) #ifdef CONFIG_PPC_DENORMALISATION @@ -1175,6 +1175,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX) b .ret_from_except STD_EXCEPTION_COMMON(0xf60, facility_unavailable, .facility_unavailable_exception) + STD_EXCEPTION_COMMON(0xf80, hv_facility_unavailable, .facility_unavailable_exception) .align 7 .globl __end_handlers @@ -1188,7 +1189,7 @@ __end_handlers: STD_RELON_EXCEPTION_PSERIES_OOL(0xf20, altivec_unavailable) STD_RELON_EXCEPTION_PSERIES_OOL(0xf40, vsx_unavailable) STD_RELON_EXCEPTION_PSERIES_OOL(0xf60, facility_unavailable) - STD_RELON_EXCEPTION_HV_OOL(0xf80, facility_unavailable) + STD_RELON_EXCEPTION_HV_OOL(0xf80, hv_facility_unavailable) #if defined(CONFIG_PPC_PSERIES) || defined(CONFIG_PPC_POWERNV) /* -- 1.8.1.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/3] powerpc: Rework setting up H/FSCR bit definitions
This reworks the Facility Status and Control Regsiter (FSCR) config bit definitions so that we can access the bit numbers. This will be useful when looking at the status in the facility unavailable interrupt. HFSCR and FSCR versions are the same, so reuse them. Signed-off-by: Michael Neuling mi...@neuling.org --- arch/powerpc/include/asm/reg.h | 31 --- 1 file changed, 20 insertions(+), 11 deletions(-) diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h index a6840e4..75199581 100644 --- a/arch/powerpc/include/asm/reg.h +++ b/arch/powerpc/include/asm/reg.h @@ -254,19 +254,28 @@ #define SPRN_HRMOR 0x139 /* Real mode offset register */ #define SPRN_HSRR0 0x13A /* Hypervisor Save/Restore 0 */ #define SPRN_HSRR1 0x13B /* Hypervisor Save/Restore 1 */ +/* HFSCR and FSCR bit numbers are the same */ +#define FSCR_TAR_LG8 /* Enable Target Address Register */ +#define FSCR_EBB_LG7 /* Enable Event Based Branching */ +#define FSCR_TM_LG 6 /* Enable Transactional Memory */ +#define FSCR_PM_LG 5 /* Enable prob/priv access to PMU SPRs */ +#define FSCR_BHRB_LG 4 /* Enable Branch History Rolling Buffer*/ +#define FSCR_DSCR_LG 2 /* Enable Data Stream Control Register */ +#define FSCR_VECVSX_LG 1 /* Enable VMX/VSX */ +#define FSCR_FP_LG 0 /* Enable Floating Point */ #define SPRN_FSCR 0x099 /* Facility Status Control Register */ -#define FSCR_TAR (1 (63-55)) /* Enable Target Address Register */ -#define FSCR_EBB (1 (63-56)) /* Enable Event Based Branching */ -#define FSCR_DSCR(1 (63-61)) /* Enable Data Stream Control Register */ +#define FSCR_TAR __MASK(FSCR_TAR_LG) +#define FSCR_EBB __MASK(FSCR_EBB_LG) +#define FSCR_DSCR__MASK(FSCR_DSCR_LG) #define SPRN_HFSCR 0xbe/* HV=1 Facility Status Control Register */ -#define HFSCR_TAR(1 (63-55)) /* Enable Target Address Register */ -#define HFSCR_EBB(1 (63-56)) /* Enable Event Based Branching */ -#define HFSCR_TM (1 (63-58)) /* Enable Transactional Memory */ -#define HFSCR_PM (1 (63-60)) /* Enable prob/priv access to PMU SPRs */ -#define HFSCR_BHRB (1 (63-59)) /* Enable Branch History Rolling Buffer*/ -#define HFSCR_DSCR (1 (63-61)) /* Enable Data Stream Control Register */ -#define HFSCR_VECVSX (1 (63-62)) /* Enable VMX/VSX */ -#define HFSCR_FP (1 (63-63)) /* Enable Floating Point */ +#define HFSCR_TAR__MASK(FSCR_TAR_LG) +#define HFSCR_EBB__MASK(FSCR_EBB_LG) +#define HFSCR_TM __MASK(FSCR_TM_LG) +#define HFSCR_PM __MASK(FSCR_PM_LG) +#define HFSCR_BHRB __MASK(FSCR_BHRB_LG) +#define HFSCR_DSCR __MASK(FSCR_DSCR_LG) +#define HFSCR_VECVSX __MASK(FSCR_VECVSX_LG) +#define HFSCR_FP __MASK(FSCR_FP_LG) #define SPRN_TAR 0x32f /* Target Address Register */ #define SPRN_LPCR 0x13E /* LPAR Control Register */ #define LPCR_VPM0(1ul (63-0)) -- 1.8.1.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/3] powerpc: Correctly context switch DSCR on POWER8
POWER8 allows the DSCR to be accessed directly from userspace via a new SPR
number 0x3 (Rather than 0x11. DSCR SPR number 0x11 is still used on POWER8 but
like POWER7, is only accessible in HV and OS modes). Currently, we allow this
by setting H/FSCR DSCR bit on boot.
Unfortunately this doesn't work, as the kernel needs to see the DSCR change so
that it knows to no longer restore the system wide version of DSCR on context
switch (ie. to set thread.dscr_inherit).
This clears the H/FSCR DSCR bit initially. If a process then accesses the DSCR
(via SPR 0x3), it'll trap into the kernel where we set thread.dscr_inherit in
facility_unavailable_exception().
We also change _switch() so that we set or clear the H/FSCR DSCR bit based on
the thread.dscr_inherit.
Signed-off-by: Michael Neuling mi...@neuling.org
---
arch/powerpc/kernel/cpu_setup_power.S | 8 --
arch/powerpc/kernel/entry_64.S| 27 +-
arch/powerpc/kernel/traps.c | 54 +--
3 files changed, 65 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/kernel/cpu_setup_power.S
b/arch/powerpc/kernel/cpu_setup_power.S
index 18b5b9c..c7a3b81 100644
--- a/arch/powerpc/kernel/cpu_setup_power.S
+++ b/arch/powerpc/kernel/cpu_setup_power.S
@@ -123,14 +123,18 @@ __init_LPCR:
__init_FSCR:
mfspr r3,SPRN_FSCR
- ori r3,r3,FSCR_TAR|FSCR_DSCR|FSCR_EBB
+ ori r3,r3,FSCR_TAR|FSCR_EBB
+ li r5,HFSCR_DSCR
+ andcr3,r3,r5
mtspr SPRN_FSCR,r3
blr
__init_HFSCR:
mfspr r3,SPRN_HFSCR
ori r3,r3,HFSCR_TAR|HFSCR_TM|HFSCR_BHRB|HFSCR_PM|\
- HFSCR_DSCR|HFSCR_VECVSX|HFSCR_FP|HFSCR_EBB
+ HFSCR_VECVSX|HFSCR_FP|HFSCR_EBB
+ li r5,HFSCR_DSCR
+ andcr3,r3,r5
mtspr SPRN_HFSCR,r3
blr
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index ab15b8d..4674fe6 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -584,9 +584,34 @@ BEGIN_FTR_SECTION
ld r7,DSCR_DEFAULT@toc(2)
ld r0,THREAD_DSCR(r4)
cmpwi r6,0
+ li r8, FSCR_DSCR
bne 1f
ld r0,0(r7)
-1: cmpdr0,r25
+ b 3f
+1:
+ BEGIN_FTR_SECTION_NESTED(70)
+ mfspr r6, SPRN_FSCR
+ or r6, r6, r8
+ mtspr SPRN_FSCR, r6
+BEGIN_FTR_SECTION_NESTED(69)
+ mfspr r6, SPRN_HFSCR
+ or r6, r6, r8
+ mtspr SPRN_HFSCR, r6
+END_FTR_SECTION_NESTED(CPU_FTR_HVMODE, CPU_FTR_HVMODE, 69)
+ b 4f
+ END_FTR_SECTION_NESTED(CPU_FTR_ARCH_207S, CPU_FTR_ARCH_207S, 70)
+3:
+ BEGIN_FTR_SECTION_NESTED(70)
+ mfspr r6, SPRN_FSCR
+ andcr6, r6, r8
+ mtspr SPRN_FSCR, r6
+BEGIN_FTR_SECTION_NESTED(69)
+ mfspr r6, SPRN_HFSCR
+ andcr6, r6, r8
+ mtspr SPRN_HFSCR, r6
+END_FTR_SECTION_NESTED(CPU_FTR_HVMODE, CPU_FTR_HVMODE, 69)
+ END_FTR_SECTION_NESTED(CPU_FTR_ARCH_207S, CPU_FTR_ARCH_207S, 70)
+4: cmpdr0,r25
beq 2f
mtspr SPRN_DSCR,r0
2:
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index bf33c22..be7930e 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -44,9 +44,7 @@
#include asm/machdep.h
#include asm/rtas.h
#include asm/pmc.h
-#ifdef CONFIG_PPC32
#include asm/reg.h
-#endif
#ifdef CONFIG_PMAC_BACKLIGHT
#include asm/backlight.h
#endif
@@ -1296,43 +1294,56 @@ void vsx_unavailable_exception(struct pt_regs *regs)
die(Unrecoverable VSX Unavailable Exception, regs, SIGABRT);
}
+#ifdef CONFIG_PPC64
void facility_unavailable_exception(struct pt_regs *regs)
{
static char *facility_strings[] = {
- FPU,
- VMX/VSX,
- DSCR,
- PMU SPRs,
- BHRB,
- TM,
- AT,
- EBB,
- TAR,
+ [FSCR_FP_LG] = FPU,
+ [FSCR_VECVSX_LG] = VMX/VSX,
+ [FSCR_DSCR_LG] = DSCR,
+ [FSCR_PM_LG] = PMU SPRs,
+ [FSCR_BHRB_LG] = BHRB,
+ [FSCR_TM_LG] = TM,
+ [FSCR_EBB_LG] = EBB,
+ [FSCR_TAR_LG] = TAR,
};
- char *facility, *prefix;
+ char *facility;
u64 value;
+ u8 status;
+ bool hv;
if (regs-trap == 0xf60) {
value = mfspr(SPRN_FSCR);
- prefix = ;
+ hv = false;
} else {
value = mfspr(SPRN_HFSCR);
- prefix = Hypervisor ;
+ hv = true;
}
- value = value 56;
+ status = value 56;
+
+ if (status ARRAY_SIZE(facility_strings))
+ facility = facility_strings[status];
+ else
+ facility = unknown;
+
+ if (status == FSCR_DSCR_LG) {
+ /* user wants to set it. Hence clear
Re: [PATCH 3/3] powerpc: Correctly context switch DSCR on POWER8
[This time from a good email address :-)]
Hi Mikey,
On Mon, 5 Aug 2013 17:28:06 +1000 Michael Neuling
mi...@neuling.org wrote:
+++ b/arch/powerpc/kernel/traps.c
@@ -1296,43 +1294,56 @@ void vsx_unavailable_exception(struct pt_regs *regs)
die(Unrecoverable VSX Unavailable Exception, regs, SIGABRT);
}
+#ifdef CONFIG_PPC64
void facility_unavailable_exception(struct pt_regs *regs)
{
static char *facility_strings[] = {
- FPU,
- VMX/VSX,
- DSCR,
- PMU SPRs,
- BHRB,
- TM,
- AT,
- EBB,
- TAR,
+ [FSCR_FP_LG] = FPU,
+ [FSCR_VECVSX_LG] = VMX/VSX,
+ [FSCR_DSCR_LG] = DSCR,
+ [FSCR_PM_LG] = PMU SPRs,
+ [FSCR_BHRB_LG] = BHRB,
+ [FSCR_TM_LG] = TM,
+ [FSCR_EBB_LG] = EBB,
+ [FSCR_TAR_LG] = TAR,
I assume that you intentionally dropped AT.
};
- char *facility, *prefix;
+ char *facility;
u64 value;
+ u8 status;
+ bool hv;
if (regs-trap == 0xf60) {
value = mfspr(SPRN_FSCR);
- prefix = ;
+ hv = false;
} else {
value = mfspr(SPRN_HFSCR);
- prefix = Hypervisor ;
+ hv = true;
}
Maybe:
hv = regs-trap == 0xf60;
if (hv)
value = mfspr(SPRN_HFSCR);
else
value = mfspr(SPRN_HFSCR);
or
value = mfspr(hv ? SPRN_HFSCR : SPRN_HFSCR);
- value = value 56;
+ status = value 56;
+
+ if (status ARRAY_SIZE(facility_strings))
+ facility = facility_strings[status];
+ else
+ facility = unknown;
For entries in the array that are not set, this will give facility ==
NULL. Is that what you intended?
pr_err(%sFacility '%s' unavailable, exception at 0x%lx, MSR=%lx\n,
- prefix, facility, regs-nip, regs-msr);
+hv ? Hypervisor :, facility, regs-nip, regs-msr);
... and this may attempt to print a NULL pointer with %s. Also please
put spaces around the : .
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgptDRKEGaoa9.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: therm_pm72 units, interface
On Sam, 2013-08-03 at 07:02 +1000, Benjamin Herrenschmidt wrote:
On Fri, 2013-08-02 at 18:52 +0200, Michel Dänzer wrote:
Thanks for the suggestion. The same windfarm modules were loaded in both
cases, but i2c_powermac wasn't loaded with the newer kernels. Loading it
manually fixes the problem.
How is i2c_powermac supposed to get loaded with current kernels?
It's a platform driver, but it's missing a module device-table
Can you try this completely untested patch ?
diff --git a/drivers/i2c/busses/i2c-powermac.c
b/drivers/i2c/busses/i2c-powermac.c
index 8dc90da..5af5153 100644
--- a/drivers/i2c/busses/i2c-powermac.c
+++ b/drivers/i2c/busses/i2c-powermac.c
@@ -458,9 +458,15 @@ static int i2c_powermac_probe(struct platform_device
*dev)
return rc;
}
+static const struct platform_device_id i2c_powermac_id = {
+ .name = i2c-powermac
+};
+MODULE_DEVICE_TABLE(platform, i2c_powermac_id);
+
static struct platform_driver i2c_powermac_driver = {
.probe = i2c_powermac_probe,
.remove = i2c_powermac_remove,
+ .id_table = *i2c_powermac_id,
This fails to build:
CC [M] drivers/i2c/busses/i2c-powermac.o
drivers/i2c/busses/i2c-powermac.c:469:14: error: invalid type argument of unary
‘*’ (have ‘const struct platform_device_id’)
make[1]: *** [drivers/i2c/busses/i2c-powermac.o] Error 1
The version below builds, but the module still doesn't get loaded
automagically (unless I'm missing some command I need to run between
copying the new module to /lib/modules/$(uname -r)/ and rebooting?).
Looking at other drivers in drivers/i2c/busses/, maybe
i2c_powermac_driver.driver needs an of_match_table entry?
diff --git a/drivers/i2c/busses/i2c-powermac.c
b/drivers/i2c/busses/i2c-powermac.c
index 8dc90da..74066fc 100644
--- a/drivers/i2c/busses/i2c-powermac.c
+++ b/drivers/i2c/busses/i2c-powermac.c
@@ -458,9 +458,19 @@ static int i2c_powermac_probe(struct
platform_device *dev)
return rc;
}
+static const struct platform_device_id i2c_powermac_id[] = {
+ {
+ .name = i2c-powermac
+ }, {
+ /* sentinel */
+ }
+};
+MODULE_DEVICE_TABLE(platform, i2c_powermac_id);
+
static struct platform_driver i2c_powermac_driver = {
.probe = i2c_powermac_probe,
.remove = i2c_powermac_remove,
+ .id_table = i2c_powermac_id,
.driver = {
.name = i2c-powermac,
.bus = platform_bus_type,
@@ -468,5 +478,3 @@ static struct platform_driver i2c_powermac_driver =
{
};
module_platform_driver(i2c_powermac_driver);
-
-MODULE_ALIAS(platform:i2c-powermac);
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: therm_pm72 units, interface
On Mon, 2013-08-05 at 11:13 +0200, Michel Dänzer wrote:
static struct platform_driver i2c_powermac_driver = {
.probe = i2c_powermac_probe,
.remove = i2c_powermac_remove,
+ .id_table = *i2c_powermac_id,
This fails to build:
CC [M] drivers/i2c/busses/i2c-powermac.o
drivers/i2c/busses/i2c-powermac.c:469:14: error: invalid type argument
of unary ‘*’ (have ‘const struct platform_device_id’)
make[1]: *** [drivers/i2c/busses/i2c-powermac.o] Error 1
Yeah, obvious typo, I said it was completely untested :-)
The version below builds, but the module still doesn't get loaded
automagically (unless I'm missing some command I need to run between
copying the new module to /lib/modules/$(uname -r)/ and rebooting?).
depmod -a ?
Looking at other drivers in drivers/i2c/busses/, maybe
i2c_powermac_driver.driver needs an of_match_table entry?
No, that would be messy, the driver is just an interface layer
on top of the low-i2c.c stuff in arch, which abstracts 3 different
i2c controllers and inconsistent device-tree representations. It's
done outside of the normal i2c framework because it's used in some
special contexts such as when running the platform functions, at early
boot or sleep/wakeup time. Also it's historical stuff I'd rather not
touch since I don't have that many different combos to test with
anymore.
However, the kernel creates platform device so the normal platform
matching mechanism should work... we might be missing something.
diff --git a/drivers/i2c/busses/i2c-powermac.c
b/drivers/i2c/busses/i2c-powermac.c
index 8dc90da..74066fc 100644
--- a/drivers/i2c/busses/i2c-powermac.c
+++ b/drivers/i2c/busses/i2c-powermac.c
@@ -458,9 +458,19 @@ static int i2c_powermac_probe(struct
platform_device *dev)
return rc;
}
+static const struct platform_device_id i2c_powermac_id[] = {
+ {
+ .name = i2c-powermac
+ }, {
+ /* sentinel */
+ }
+};
+MODULE_DEVICE_TABLE(platform, i2c_powermac_id);
+
static struct platform_driver i2c_powermac_driver = {
.probe = i2c_powermac_probe,
.remove = i2c_powermac_remove,
+ .id_table = i2c_powermac_id,
.driver = {
.name = i2c-powermac,
.bus = platform_bus_type,
@@ -468,5 +478,3 @@ static struct platform_driver i2c_powermac_driver
=
{
};
module_platform_driver(i2c_powermac_driver);
-
-MODULE_ALIAS(platform:i2c-powermac);
Maybe add the module alias back ? It shouldn't be necessary...
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] powerpc: Correctly context switch DSCR on POWER8
Stephen Rothwell s...@canb.auug.org.au wrote:
[This time from a good email address :-)]
Hi Mikey,
On Mon, 5 Aug 2013 17:28:06 +1000 Michael Neuling
mi...@neuling.org wrote:
+++ b/arch/powerpc/kernel/traps.c
@@ -1296,43 +1294,56 @@ void vsx_unavailable_exception(struct pt_regs *regs)
die(Unrecoverable VSX Unavailable Exception, regs, SIGABRT);
}
+#ifdef CONFIG_PPC64
void facility_unavailable_exception(struct pt_regs *regs)
{
static char *facility_strings[] = {
- FPU,
- VMX/VSX,
- DSCR,
- PMU SPRs,
- BHRB,
- TM,
- AT,
- EBB,
- TAR,
+ [FSCR_FP_LG] = FPU,
+ [FSCR_VECVSX_LG] = VMX/VSX,
+ [FSCR_DSCR_LG] = DSCR,
+ [FSCR_PM_LG] = PMU SPRs,
+ [FSCR_BHRB_LG] = BHRB,
+ [FSCR_TM_LG] = TM,
+ [FSCR_EBB_LG] = EBB,
+ [FSCR_TAR_LG] = TAR,
I assume that you intentionally dropped AT.
Yeah.
};
- char *facility, *prefix;
+ char *facility;
u64 value;
+ u8 status;
+ bool hv;
if (regs-trap == 0xf60) {
value = mfspr(SPRN_FSCR);
- prefix = ;
+ hv = false;
} else {
value = mfspr(SPRN_HFSCR);
- prefix = Hypervisor ;
+ hv = true;
}
Maybe:
hv = regs-trap == 0xf60;
if (hv)
value = mfspr(SPRN_HFSCR);
else
value = mfspr(SPRN_HFSCR);
or
value = mfspr(hv ? SPRN_HFSCR : SPRN_HFSCR);
ok.
- value = value 56;
+ status = value 56;
+
+ if (status ARRAY_SIZE(facility_strings))
+ facility = facility_strings[status];
+ else
+ facility = unknown;
For entries in the array that are not set, this will give facility ==
NULL. Is that what you intended?
No it wasn't, I'll catch that case, thanks.
pr_err(%sFacility '%s' unavailable, exception at 0x%lx, MSR=%lx\n,
- prefix, facility, regs-nip, regs-msr);
+ hv ? Hypervisor :, facility, regs-nip, regs-msr);
... and this may attempt to print a NULL pointer with %s. Also please
put spaces around the : .
OK.
Mikey
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] powerpc: Correctly context switch DSCR on POWER8
};
- char *facility, *prefix;
+ char *facility;
u64 value;
+ u8 status;
+ bool hv;
if (regs-trap == 0xf60) {
value = mfspr(SPRN_FSCR);
- prefix = ;
+ hv = false;
} else {
value = mfspr(SPRN_HFSCR);
- prefix = Hypervisor ;
+ hv = true;
}
Maybe:
hv = regs-trap == 0xf60;
if (hv)
value = mfspr(SPRN_HFSCR);
else
value = mfspr(SPRN_HFSCR);
or
value = mfspr(hv ? SPRN_HFSCR : SPRN_HFSCR);
ok.
So this doesn't work... I forgot that mfspr is just a macro around the
mfspr instruction, so we can't dynamically pass in the SPR number,
So I have to use your first version.
Mikey
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
Hi Nicolin,
Am Montag, den 05.08.2013, 15:29 +0800 schrieb Nicolin Chen:
This patch add S/PDIF controller driver for Freescale SoC.
Signed-off-by: Nicolin Chen b42...@freescale.com
---
.../devicetree/bindings/sound/fsl,spdif.txt| 62 +
sound/soc/fsl/Kconfig |3 +
sound/soc/fsl/Makefile |2 +
sound/soc/fsl/fsl_spdif.c | 1311
sound/soc/fsl/fsl_spdif.h | 227
5 files changed, 1605 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/fsl,spdif.txt
create mode 100644 sound/soc/fsl/fsl_spdif.c
create mode 100644 sound/soc/fsl/fsl_spdif.h
diff --git a/Documentation/devicetree/bindings/sound/fsl,spdif.txt
b/Documentation/devicetree/bindings/sound/fsl,spdif.txt
new file mode 100644
index 000..8b1bfe2
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,spdif.txt
@@ -0,0 +1,62 @@
+Freescale Sony/Philips Digital Interface Format (S/PDIF) Controller
+
+The Freescale S/PDIF audio block is a stereo transceiver that allows the
+processor to receive and transmit digital audio via an coaxial cable or
+a fibre cable.
+
+Required properties:
+
+ - compatible : Compatible list, contains fsl,fsl-spdif or SoC specific
+ fsl,imx6q-spdif, fsl,imx6sl-spdif.
i.MX53 also has this S/PDIF block.
+ - reg : Offset and length of the register set for the device.
+
+ - interrupts : Should contain spdif interrupt.
+
+ - dmas : Generic dma devicetree binding as described in
+ Documentation/devicetree/bindings/dma/dma.txt.
+
+ - dma-names : Two dmas have to be defined, tx and rx.
+
+ - clocks : (First) The phandle for the clock ID registered in clock tree.
+ There could be two clocks being set here, but only the first one, CORE
+ clock, is must.
+
+
+Optional properties:
+
+ - clocks : (Second) The phandle for the clock ID registered in clock tree.
+ There could be two clocks being set here, but the second one, TX clock is
+ optional. If absent, the TX clock will use CORE clock as default.
+
+ - clock-names : The names for the two clocks. It will be required only when
+ the second clock's present. If absent, the TX clock will use CORE clock as
+ default.
+
+ - tx-clk-source : The clock cources for Tx. Need to set this source
according
+ to the SoC datasheet in SPDIF_STC section. If absent, the default source is
+ value 0x1 - CCM spdif0_clk_root input.
+
+ - rx-clk-source : The clock cource for Rx. Need to set this source
according
+ to the SoC datasheet in SPDIF_SRPC section. If absent, the default source
is
+ value 0x0 - if (DPLL Locked) SPDIF_RxClk else extal.
This looks to me like a case of configuration data in the device tree.
Couldn't the tx/rx clock source be determined automatically or at least
the SoC specific clock sources to the mux be known to the driver, so
that we can use clock phandles here?
What happens if a different tx-clk-source is needed for 48 kHz than for
44.1 kHz?
+Example:
+
+spdif: spdif@02004000 {
+ compatible = fsl,fsl-spdif;
+ reg = 0x02004000 0x4000;
+ interrupts = 0 52 0x04;
+ dmas = sdma 14 18 0,
+sdma 15 18 0;
+ dma-names = rx, tx;
+
+ clocks = clks 197, clks 197;
+ clock-names = core, tx;
+
+ tx-clk-source = 0x1;
+ rx-clk-source = 0x0;
+
+ status = okay;
+};
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index c26449b..74f533b 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -1,6 +1,9 @@
config SND_SOC_FSL_SSI
tristate
+config SND_SOC_FSL_SPDIF
+ tristate
+
config SND_SOC_FSL_UTILS
tristate
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index d4b4aa8..4b5970e 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -12,9 +12,11 @@ obj-$(CONFIG_SND_SOC_P1022_RDK) += snd-soc-p1022-rdk.o
# Freescale PowerPC SSI/DMA Platform Support
snd-soc-fsl-ssi-objs := fsl_ssi.o
+snd-soc-fsl-spdif-objs := fsl_spdif.o
snd-soc-fsl-utils-objs := fsl_utils.o
snd-soc-fsl-dma-objs := fsl_dma.o
obj-$(CONFIG_SND_SOC_FSL_SSI) += snd-soc-fsl-ssi.o
+obj-$(CONFIG_SND_SOC_FSL_SPDIF) += snd-soc-fsl-spdif.o
obj-$(CONFIG_SND_SOC_FSL_UTILS) += snd-soc-fsl-utils.o
obj-$(CONFIG_SND_SOC_POWERPC_DMA) += snd-soc-fsl-dma.o
diff --git a/sound/soc/fsl/fsl_spdif.c b/sound/soc/fsl/fsl_spdif.c
new file mode 100644
index 000..8865499
--- /dev/null
+++ b/sound/soc/fsl/fsl_spdif.c
@@ -0,0 +1,1311 @@
+/*
+ * Freescale S/PDIF ALSA SoC Digital Audio Interface (DAI) driver
+ *
+ * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ *
+ * Based on stmp3xxx_spdif_dai.c
+ * Vladimir Barinov vbari...@embeddedalley.com
+ * Copyright 2008 SigmaTel, Inc
+ * Copyright 2008 Embedded Alley Solutions, Inc
+ *
+ * This file is licensed under the terms of the GNU
Re: therm_pm72 units, interface
On Mon, 2013-08-05 at 19:22 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2013-08-05 at 11:13 +0200, Michel Dänzer wrote:
The version below builds, but the module still doesn't get loaded
automagically (unless I'm missing some command I need to run between
copying the new module to /lib/modules/$(uname -r)/ and rebooting?).
depmod -a ?
I did that, sorry should have mentioned that.
@@ -468,5 +478,3 @@ static struct platform_driver i2c_powermac_driver
=
{
};
module_platform_driver(i2c_powermac_driver);
-
-MODULE_ALIAS(platform:i2c-powermac);
Maybe add the module alias back ? It shouldn't be necessary...
Doesn't help.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: therm_pm72 units, interface
On Mon, 2013-08-05 at 12:32 +0200, Michel Dänzer wrote:
I did that, sorry should have mentioned that.
@@ -468,5 +478,3 @@ static struct platform_driver
i2c_powermac_driver
=
{
};
module_platform_driver(i2c_powermac_driver);
-
-MODULE_ALIAS(platform:i2c-powermac);
Maybe add the module alias back ? It shouldn't be necessary...
Doesn't help.
Hrm, that might require some more involved debugging, figuring out
what's up with udev etc... that or maybe bisecting.
From what I can tell, we do attach an OF node to the platform device,
but since the driver has no of match table, we should still fallback to
the old platform matching style.
I think I see... adding Grant.
Grant, something broke the auto-loading the of i2c-powermac module. It's
a platform device, but while it does have a populated of_node, its
driver doesn't have an OF match table and relies on the old style
platform device matching.
That's broken with newer kernels, platform_uevent() calls
of_device_uevent_modalias() which sees the of_node and thus doesn't
return -ENOMEM, and we don't create a platform modalias anymore.
Is it legit to add several MODALIAS ? If yes we could add both ... if
not, we have a problem. Doing real OF matching with that critter is
tricky at best for various reasons but it needs the of_node because it
uses it to scan for children.
Any suggestion ?
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 3/3] powerpc: Correctly context switch DSCR on POWER8
POWER8 allows the DSCR to be accessed directly from userspace via a new SPR
number 0x3 (Rather than 0x11. DSCR SPR number 0x11 is still used on POWER8 but
like POWER7, is only accessible in HV and OS modes). Currently, we allow this
by setting H/FSCR DSCR bit on boot.
Unfortunately this doesn't work, as the kernel needs to see the DSCR change so
that it knows to no longer restore the system wide version of DSCR on context
switch (ie. to set thread.dscr_inherit).
This clears the H/FSCR DSCR bit initially. If a process then accesses the DSCR
(via SPR 0x3), it'll trap into the kernel where we set thread.dscr_inherit in
facility_unavailable_exception().
We also change _switch() so that we set or clear the H/FSCR DSCR bit based on
the thread.dscr_inherit.
Signed-off-by: Michael Neuling mi...@neuling.org
diff --git a/arch/powerpc/kernel/cpu_setup_power.S
b/arch/powerpc/kernel/cpu_setup_power.S
index 18b5b9c..c7a3b81 100644
--- a/arch/powerpc/kernel/cpu_setup_power.S
+++ b/arch/powerpc/kernel/cpu_setup_power.S
@@ -123,14 +123,18 @@ __init_LPCR:
__init_FSCR:
mfspr r3,SPRN_FSCR
- ori r3,r3,FSCR_TAR|FSCR_DSCR|FSCR_EBB
+ ori r3,r3,FSCR_TAR|FSCR_EBB
+ li r5,HFSCR_DSCR
+ andcr3,r3,r5
mtspr SPRN_FSCR,r3
blr
__init_HFSCR:
mfspr r3,SPRN_HFSCR
ori r3,r3,HFSCR_TAR|HFSCR_TM|HFSCR_BHRB|HFSCR_PM|\
- HFSCR_DSCR|HFSCR_VECVSX|HFSCR_FP|HFSCR_EBB
+ HFSCR_VECVSX|HFSCR_FP|HFSCR_EBB
+ li r5,HFSCR_DSCR
+ andcr3,r3,r5
mtspr SPRN_HFSCR,r3
blr
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index ab15b8d..4674fe6 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -584,9 +584,34 @@ BEGIN_FTR_SECTION
ld r7,DSCR_DEFAULT@toc(2)
ld r0,THREAD_DSCR(r4)
cmpwi r6,0
+ li r8, FSCR_DSCR
bne 1f
ld r0,0(r7)
-1: cmpdr0,r25
+ b 3f
+1:
+ BEGIN_FTR_SECTION_NESTED(70)
+ mfspr r6, SPRN_FSCR
+ or r6, r6, r8
+ mtspr SPRN_FSCR, r6
+BEGIN_FTR_SECTION_NESTED(69)
+ mfspr r6, SPRN_HFSCR
+ or r6, r6, r8
+ mtspr SPRN_HFSCR, r6
+END_FTR_SECTION_NESTED(CPU_FTR_HVMODE, CPU_FTR_HVMODE, 69)
+ b 4f
+ END_FTR_SECTION_NESTED(CPU_FTR_ARCH_207S, CPU_FTR_ARCH_207S, 70)
+3:
+ BEGIN_FTR_SECTION_NESTED(70)
+ mfspr r6, SPRN_FSCR
+ andcr6, r6, r8
+ mtspr SPRN_FSCR, r6
+BEGIN_FTR_SECTION_NESTED(69)
+ mfspr r6, SPRN_HFSCR
+ andcr6, r6, r8
+ mtspr SPRN_HFSCR, r6
+END_FTR_SECTION_NESTED(CPU_FTR_HVMODE, CPU_FTR_HVMODE, 69)
+ END_FTR_SECTION_NESTED(CPU_FTR_ARCH_207S, CPU_FTR_ARCH_207S, 70)
+4: cmpdr0,r25
beq 2f
mtspr SPRN_DSCR,r0
2:
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index bf33c22..e435bc0 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -44,9 +44,7 @@
#include asm/machdep.h
#include asm/rtas.h
#include asm/pmc.h
-#ifdef CONFIG_PPC32
#include asm/reg.h
-#endif
#ifdef CONFIG_PMAC_BACKLIGHT
#include asm/backlight.h
#endif
@@ -1296,43 +1294,54 @@ void vsx_unavailable_exception(struct pt_regs *regs)
die(Unrecoverable VSX Unavailable Exception, regs, SIGABRT);
}
+#ifdef CONFIG_PPC64
void facility_unavailable_exception(struct pt_regs *regs)
{
static char *facility_strings[] = {
- FPU,
- VMX/VSX,
- DSCR,
- PMU SPRs,
- BHRB,
- TM,
- AT,
- EBB,
- TAR,
+ [FSCR_FP_LG] = FPU,
+ [FSCR_VECVSX_LG] = VMX/VSX,
+ [FSCR_DSCR_LG] = DSCR,
+ [FSCR_PM_LG] = PMU SPRs,
+ [FSCR_BHRB_LG] = BHRB,
+ [FSCR_TM_LG] = TM,
+ [FSCR_EBB_LG] = EBB,
+ [FSCR_TAR_LG] = TAR,
};
- char *facility, *prefix;
+ char *facility = unknown;
u64 value;
+ u8 status;
+ bool hv;
- if (regs-trap == 0xf60) {
- value = mfspr(SPRN_FSCR);
- prefix = ;
- } else {
+ hv = (regs-trap == 0xf80);
+ if (hv)
value = mfspr(SPRN_HFSCR);
- prefix = Hypervisor ;
+ else
+ value = mfspr(SPRN_FSCR);
+
+ status = value 56;
+ if (status == FSCR_DSCR_LG) {
+ /* User is acessing the DSCR. Set the inherit bit and allow
+* the user to set it directly in future by setting via the
+* H/FSCR DSCR bit.
+*/
+ current-thread.dscr_inherit = 1;
+ if (hv)
+ mtspr(SPRN_HFSCR, value | HFSCR_DSCR);
+ else
+ mtspr(SPRN_FSCR, value | FSCR_DSCR);
+
Re: [PATCH v3 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
Hi Philipp, Thanks for the comments! I'll revise it and send a v4. Here is my reply to some parts of your question. On Mon, Aug 05, 2013 at 12:07:02PM +0200, Philipp Zabel wrote: This looks to me like a case of configuration data in the device tree. Couldn't the tx/rx clock source be determined automatically or at least the SoC specific clock sources to the mux be known to the driver, so that we can use clock phandles here? What happens if a different tx-clk-source is needed for 48 kHz than for 44.1 kHz? You are right about the case. I'll try to figure out a nicer way, including for the different sample-rate. Do we already have anything for this in the kernel? It could also be done using: u8 tmp = input; tmp = ((tmp 0b10101010) 1) | ((tmp 1) 0b10101010); tmp = ((tmp 0b11001100) 2) | ((tmp 2) 0b11001100); tmp = ((tmp 0b) 4) | ((tmp 4) 0b); return tmp; I was also wondering this question but I couldn't find it. And obviously your algorithm is better :) In principle, it should also be possible to let the SDMA engine only take the FIFOs' MSBs for S16_LE. Is this a limitation of the SDMA ROM script? You are right about the idea and the inference. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 5/6 v2] kvm: powerpc: booke: Add linux pte lookup like booke3s
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
Sent: Saturday, August 03, 2013 9:54 AM
To: Bhushan Bharat-R65777
Cc: Wood Scott-B07421; ag...@suse.de; kvm-...@vger.kernel.org;
k...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 5/6 v2] kvm: powerpc: booke: Add linux pte lookup like
booke3s
On Sat, 2013-08-03 at 02:58 +, Bhushan Bharat-R65777 wrote:
One of the problem I saw was that if I put this code in
asm/pgtable-32.h and asm/pgtable-64.h then pte_persent() and other
friend function (on which this code depends) are defined in pgtable.h.
And pgtable.h includes asm/pgtable-32.h and asm/pgtable-64.h before it
defines pte_present() and friends functions.
Ok I move wove this in asm/pgtable*.h, initially I fought with myself
to take this code in pgtable* but finally end up doing here (got
biased by book3s :)).
Is there a reason why these routines can not be completely generic in
pgtable.h
?
How about the generic function:
diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h
b/arch/powerpc/include/asm/pgtable-ppc64.h
index d257d98..21daf28 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -221,6 +221,27 @@ static inline unsigned long pte_update(struct mm_struct
*mm,
return old;
}
+static inline unsigned long pte_read(pte_t *p)
+{
+#ifdef PTE_ATOMIC_UPDATES
+ pte_t pte;
+ pte_t tmp;
+ __asm__ __volatile__ (
+ 1: ldarx %0,0,%3\n
+ andi. %1,%0,%4\n
+ bne-1b\n
+ ori %1,%0,%4\n
+ stdcx. %1,0,%3\n
+ bne-1b
+ : =r (pte), =r (tmp), =m (*p)
+ : r (p), i (_PAGE_BUSY)
+ : cc);
+
+ return pte;
+#else
+ return pte_val(*p);
+#endif
+#endif
+}
static inline int __ptep_test_and_clear_young(struct mm_struct *mm,
unsigned long addr, pte_t *ptep)
{
diff --git a/arch/powerpc/include/asm/pgtable.h
b/arch/powerpc/include/asm/pgtable.h
index 690c8c2..dad712c 100644
--- a/arch/powerpc/include/asm/pgtable.h
+++ b/arch/powerpc/include/asm/pgtable.h
@@ -254,6 +254,45 @@ static inline pte_t *find_linux_pte_or_hugepte(pgd_t
*pgdir, unsigned long ea,
}
#endif /* !CONFIG_HUGETLB_PAGE */
+static inline pte_t lookup_linux_pte(pgd_t *pgdir, unsigned long hva,
+int writing, unsigned long *pte_sizep)
+{
+ pte_t *ptep;
+ pte_t pte;
+ unsigned long ps = *pte_sizep;
+ unsigned int shift;
+
+ ptep = find_linux_pte_or_hugepte(pgdir, hva, shift);
+ if (!ptep)
+ return __pte(0);
+ if (shift)
+ *pte_sizep = 1ul shift;
+ else
+ *pte_sizep = PAGE_SIZE;
+
+ if (ps *pte_sizep)
+ return __pte(0);
+
+ if (!pte_present(*ptep))
+ return __pte(0);
+
+#ifdef CONFIG_PPC64
+ /* Lock PTE (set _PAGE_BUSY) and read */
+ pte = pte_read(ptep);
+#else
+ pte = pte_val(*ptep);
+#endif
+ if (pte_present(pte)) {
+ pte = pte_mkyoung(pte);
+ if (writing pte_write(pte))
+ pte = pte_mkdirty(pte);
+ }
+
+ *ptep = __pte(pte); /* 64bit: Also unlock pte (clear _PAGE_BUSY) */
+
+ return pte;
+}
+
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 17/31] clk: mpc512x: introduce COMMON_CLK for MPC512x
On Mon, Jul 22, 2013 at 01:14:44PM +0100, Gerhard Sittig wrote:
this change implements a clock driver for the MPC512x PowerPC platform
which follows the COMMON_CLK approach and uses common clock drivers
shared with other platforms
this driver implements the publicly announced set of clocks (which can
get referenced by means of symbolic identifiers from the dt-bindings
header file), as well as generates additional 'struct clk' items where
the SoC hardware cannot easily get mapped to the common primitives of
the clock API, or requires intermediate clock nodes to represent
clocks that have both gates and dividers
the previous PPC_CLOCK implementation is kept in place and remains in
parallel to the common clock implementation for test and comparison
during migration, a compile time option picks one of the two
alternatives (Kconfig switch, common clock used by default)
some of the clock items get pre-enabled in the clock driver to not have
them automatically disabled by the underlying clock subsystem because of
their being unused -- this approach is desirable because
- some of the clocks are useful to have for diagnostics and information
despite their not getting claimed by any drivers (CPU, internal and
external RAM, internal busses, boot media)
- some of the clocks aren't claimed by their peripheral drivers yet,
either because of missing driver support or because device tree specs
aren't available yet (but the workarounds will get removed as the
drivers get adjusted and the device tree provides the clock specs)
- some help introduce support for and migrate to the common
infrastructure, while more appropriate support for specific hardware
constraints isn't available yet (remaining changes are strictly
internal to the clock driver and won't affect peripheral drivers)
clkdev registration provides alias names for few clock items
- to not break those peripheral drivers which encode their component
index into the name that is used for clock lookup (UART, SPI, USB)
- to not break those drivers which use names for the clock lookup which
were encoded in the previous PPC_CLOCK implementation (NFC, VIU, CAN)
this workaround will get removed as these drivers get adjusted after
device tree based clock lookup has become available
Signed-off-by: Gerhard Sittig g...@denx.de
---
arch/powerpc/platforms/512x/Kconfig | 14 +-
arch/powerpc/platforms/512x/Makefile |4 +-
arch/powerpc/platforms/512x/clock-commonclk.c | 786
+
include/linux/clk-provider.h | 16 +
4 files changed, 818 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/platforms/512x/clock-commonclk.c
[...]
+static int get_freq_from_dt(char *propname)
+{
+ struct device_node *np;
+ const unsigned int *prop;
+ int val;
+
+ val = 0;
+ np = of_find_compatible_node(NULL, NULL, fsl,mpc5121-immr);
+ if (np) {
+ prop = of_get_property(np, propname, NULL);
+ if (prop)
+ val = *prop;
+ of_node_put(np);
+ }
+ return val;
+}
Can you not use of_property_read_u32 here rather than of_get_property?
Also, this seems rather unlike the common clock bindings method for
describing frequencies in the dt. Given there's nothing in mainline
using this yet, we can do it 'right' from the start.
[...]
+ /*
+* externally provided clocks (when implemented in hardware,
+* device tree may specify values which otherwise were unknown)
+*/
+ freq = get_freq_from_dt(psc_mclk_in);
+ if (!freq)
+ freq = 2500;
+ clks[MPC512x_CLK_PSC_MCLK_IN] = mpc512x_clk_fixed(psc_mclk_in,
freq);
+ freq = get_freq_from_dt(spdif_tx_in);
+ clks[MPC512x_CLK_SPDIF_TX_IN] = mpc512x_clk_fixed(spdif_tx_in,
freq);
+ freq = get_freq_from_dt(spdif_rx_in);
+ clks[MPC512x_CLK_SPDIF_TX_IN] = mpc512x_clk_fixed(spdif_rx_in,
freq);
Can we not just use fixed-clocks for these in the dt? It feels odd to
describe them in a compeltely differnet way in the dt, especially as
we'll have to maintain some backwards compatibility for a while...
I see for psc_mclk_in we assume a default value if not present. I'm not
sure how to handle that, but I assume there's some way of finding out if
we've already registered a clock output with the same name?
Thanks,
Mark.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PCIE device errors after linux kernel upgrade
[+cc linuxppc-dev] On Mon, Aug 5, 2013 at 5:17 AM, Leon Ravich lrav...@gmail.com wrote: Hi all , I am trying to upgrade ours embedded device (freescale powerPC P2020 cpu) linux kernel , till now we used 2.6.32 I am trying to upgrade to 3.8.13 . I took the source from freescale git: git://git.freescale.com/ppc/sdk/linux.git on our embedded device we have an FPGA connected through PCIE . on each boot we loading the rbf design to the FPGA and the rescan pci bus to let kernel detect it . during the rescan I getting error messages: genirq: Setting trigger mode 0 for irq 27 failed (mpc8xxx_irq_set_type+0x0/0xec) [ 22.060898] genirq: Setting trigger mode 0 for irq 28 failed (mpc8xxx_irq_set_type+0x0/0xec) [ 22.069461] genirq: Setting trigger mode 0 for irq 31 failed (mpc8xxx_irq_set_type+0x0/0xec) [ 22.078010] genirq: Setting trigger mode 0 for irq 32 failed (mpc8xxx_irq_set_type+0x0/0xec) [ 22.086576] genirq: Setting trigger mode 0 for irq 33 failed (mpc8xxx_irq_set_type+0x0/0xec) [ 22.095143] genirq: Setting trigger mode 0 for irq 37 failed (mpc8xxx_irq_set_type+0x0/0xec) [ 22.103715] genirq: Setting trigger mode 0 for irq 38 failed (mpc8xxx_irq_set_type+0x0/0xec) [ 22.112282] genirq: Setting trigger mode 0 for irq 39 failed (mpc8xxx_irq_set_type+0x0/0xec) Hmm, I don't know much about IRQ issues. [ 37.945785] pci :00:00.0: ignoring class 0x0b2000 (doesn't match header type 01) There's a recent patch related to this: http://lkml.kernel.org/r/1374823418-1550-1-git-send-email-chunhe@freescale.com [ 37.953640] PCIE error(s) detected [ 37.953858] pci :00:00.0: PCI bridge to [bus 01-ff] [ 37.953988] pci :00:00.0: BAR 8: assigned [mem 0xc000-0xdfff] [ 37.953994] pci :00:00.0: BAR 7: can't assign io (size 0x1) [ 37.954000] pci :01:00.0: BAR 0: assigned [mem 0xc000-0xc00f] [ 37.954013] pci :01:00.0: BAR 1: assigned [mem 0xc010-0xc017] [ 37.954025] pci :01:00.0: BAR 2: assigned [mem 0xc018-0xc01f] [ 37.954036] pci :00:00.0: PCI bridge to [bus 01] [ 37.954041] pci :00:00.0: bridge window [mem 0xc000-0xdfff] [ 38.007354] PCIE ERR_DR register: 0x8002 [ 38.011613] PCIE ERR_CAP_STAT register: 0x0041 [ 38.016392] PCIE ERR_CAP_R0 register: 0x0800 [ 38.020997] PCIE ERR_CAP_R1 register: 0x [ 38.025602] PCIE ERR_CAP_R2 register: 0x [ 38.030207] PCIE ERR_CAP_R3 register: 0x and after a few minutes I linux reboot it self, where can I start debugging it?? I'd start by applying the header quirk patch above, then comparing the complete console log (boot with ignore_loglevel) from 2.6.32 and 3.8.13. Bjorn ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/6 v2] kvm: powerpc: use caching attributes as per linux pte
On Sat, 2013-08-03 at 14:25 +1000, Benjamin Herrenschmidt wrote: On Sat, 2013-08-03 at 03:11 +, Bhushan Bharat-R65777 wrote: Could you explain why we need to set dirty/referenced on the PTE, when we didn't need to do that before? All we're getting from the PTE is wimg. We have MMU notifiers to take care of the page being unmapped, and we've already marked the page itself as dirty if the TLB entry is writeable. I pulled this code from book3s. Ben, can you describe why we need this on book3s ? If you let the guest write to the page you must set the dirty bit on the PTE (or the struct page, at least one of them), similar with accessed on any access. If you don't, the VM might swap the page out without writing it back to disk for example, assuming it contains no modified data. We've already marked the page itself as dirty using kvm_set_pfn_dirty(), and if the VM swaps it out we'll get an MMU notifier callback. If we marked the PTE dirty/accessed instead, is there any guarantee it will stay marked dirty/accessed until the next MMU notifier? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/6 v2] kvm: powerpc: use caching attributes as per linux pte
On Fri, 2013-08-02 at 22:11 -0500, Bhushan Bharat-R65777 wrote: How does wimg get set in the pfnmap case? Pfnmap is not kernel managed pages, right? So should we set I+G there ? It could depend on ppc_md.phys_mem_access_prot(). Can't you pull it from the PTE regardless of pfnmap? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/11] Add compression support to pstore
One more experiment - removed previous hack that disabled compression. Added a new hack to skip decompression. System died cleanly when I forced a panic. On reboot I found 3 files in pstore: -r--r--r-- 1 root root 3972 Aug 5 09:24 dmesg-erst-5908671953186586625 -r--r--r-- 1 root root 2565 Aug 5 09:24 dmesg-erst-5908671953186586626 -r--r--r-- 1 root root 4067 Aug 5 09:24 dmesg-erst-5908671953186586627 Using openssl zlib -d to decompress then ends up with some garbage at the end of the decompressed file - some text that should be there is missing. E.g. the tail of decompressed version of *625 ends with: 4Call Trace: 4 [815f85f4] dump_stack+0x45/0x56 4 [815f41ca] panic+0xc2/0x1cb 4 [815f4327] ? printk+0x54/0x56 4 [811cfe45] aegl+0x25/0x30 4 [811c719d] proc_reg_write+0x3d/0x80 4 [81165945] vfs_write+0xc5/0x1e0 4 [81165e32] SyS_write+0x52/0xa0 4 [81606882] system_call_fastpath+0x16/0x1b )c10^@^@^@^@^@^@^@^@^@ But my serial console logged this: Call Trace: [815f85f4] dump_stack+0x45/0x56 [815f41ca] panic+0xc2/0x1cb [815f4327] ? printk+0x54/0x56 [811cfe45] aegl+0x25/0x30 [811c719d] proc_reg_write+0x3d/0x80 [81165945] vfs_write+0xc5/0x1e0 [81165e32] SyS_write+0x52/0xa0 [81606882] system_call_fastpath+0x16/0x1b [ cut here ] WARNING: CPU: 18 PID: 381 at arch/x86/kernel/smp.c:124 native_smp_send_reschedule+0x5b/0x60() Modules linked in: CPU: 18 PID: 381 Comm: kworker/18:1 Not tainted 3.11.0-rc3-11-ge41db9e #6 -Tony ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 17/31] clk: mpc512x: introduce COMMON_CLK for MPC512x
On Mon, Aug 05, 2013 at 12:37 +0100, Mark Rutland wrote:
On Mon, Jul 22, 2013 at 01:14:44PM +0100, Gerhard Sittig wrote:
this change implements a clock driver for the MPC512x PowerPC platform
which follows the COMMON_CLK approach and uses common clock drivers
shared with other platforms
this driver implements the publicly announced set of clocks (which can
get referenced by means of symbolic identifiers from the dt-bindings
header file), as well as generates additional 'struct clk' items where
the SoC hardware cannot easily get mapped to the common primitives of
the clock API, or requires intermediate clock nodes to represent
clocks that have both gates and dividers
the previous PPC_CLOCK implementation is kept in place and remains in
parallel to the common clock implementation for test and comparison
during migration, a compile time option picks one of the two
alternatives (Kconfig switch, common clock used by default)
some of the clock items get pre-enabled in the clock driver to not have
them automatically disabled by the underlying clock subsystem because of
their being unused -- this approach is desirable because
- some of the clocks are useful to have for diagnostics and information
despite their not getting claimed by any drivers (CPU, internal and
external RAM, internal busses, boot media)
- some of the clocks aren't claimed by their peripheral drivers yet,
either because of missing driver support or because device tree specs
aren't available yet (but the workarounds will get removed as the
drivers get adjusted and the device tree provides the clock specs)
- some help introduce support for and migrate to the common
infrastructure, while more appropriate support for specific hardware
constraints isn't available yet (remaining changes are strictly
internal to the clock driver and won't affect peripheral drivers)
clkdev registration provides alias names for few clock items
- to not break those peripheral drivers which encode their component
index into the name that is used for clock lookup (UART, SPI, USB)
- to not break those drivers which use names for the clock lookup which
were encoded in the previous PPC_CLOCK implementation (NFC, VIU, CAN)
this workaround will get removed as these drivers get adjusted after
device tree based clock lookup has become available
Signed-off-by: Gerhard Sittig g...@denx.de
---
arch/powerpc/platforms/512x/Kconfig | 14 +-
arch/powerpc/platforms/512x/Makefile |4 +-
arch/powerpc/platforms/512x/clock-commonclk.c | 786
+
include/linux/clk-provider.h | 16 +
4 files changed, 818 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/platforms/512x/clock-commonclk.c
[...]
+static int get_freq_from_dt(char *propname)
+{
+ struct device_node *np;
+ const unsigned int *prop;
+ int val;
+
+ val = 0;
+ np = of_find_compatible_node(NULL, NULL, fsl,mpc5121-immr);
+ if (np) {
+ prop = of_get_property(np, propname, NULL);
+ if (prop)
+ val = *prop;
+ of_node_put(np);
+ }
+ return val;
+}
Can you not use of_property_read_u32 here rather than of_get_property?
Also, this seems rather unlike the common clock bindings method for
describing frequencies in the dt. Given there's nothing in mainline
using this yet, we can do it 'right' from the start.
This specific routine was taken in verbatim form from the former
PPC_CLOCK implementation. Although I could re-implement it in
other ways if that was considered necessary.
[...]
+ /*
+* externally provided clocks (when implemented in hardware,
+* device tree may specify values which otherwise were unknown)
+*/
+ freq = get_freq_from_dt(psc_mclk_in);
+ if (!freq)
+ freq = 2500;
+ clks[MPC512x_CLK_PSC_MCLK_IN] = mpc512x_clk_fixed(psc_mclk_in,
freq);
+ freq = get_freq_from_dt(spdif_tx_in);
+ clks[MPC512x_CLK_SPDIF_TX_IN] = mpc512x_clk_fixed(spdif_tx_in,
freq);
+ freq = get_freq_from_dt(spdif_rx_in);
+ clks[MPC512x_CLK_SPDIF_TX_IN] = mpc512x_clk_fixed(spdif_rx_in,
freq);
Can we not just use fixed-clocks for these in the dt? It feels odd to
describe them in a compeltely differnet way in the dt, especially as
we'll have to maintain some backwards compatibility for a while...
I see for psc_mclk_in we assume a default value if not present. I'm not
sure how to handle that, but I assume there's some way of finding out if
we've already registered a clock output with the same name?
I guess using fixed-clocks (i.e. clock items that completely get
described in the device tree, and are taken care of by a common
driver which attaches to anything that is said to be
Re: [PATCH v3 17/31] clk: mpc512x: introduce COMMON_CLK for MPC512x
Quoting Gerhard Sittig (2013-08-03 07:39:56) [ we are strictly talking about clocks and source code again, I have trimmed the CC: list to not spam the device tree ML or subsystem maintainers ] On Fri, Aug 02, 2013 at 16:30 -0700, Mike Turquette wrote: Quoting Gerhard Sittig (2013-07-23 06:14:06) [ summary: shared gate support desirable? approach acceptable? ] On Mon, Jul 22, 2013 at 14:14 +0200, Gerhard Sittig wrote: this change implements a clock driver for the MPC512x PowerPC platform which follows the COMMON_CLK approach and uses common clock drivers shared with other platforms [ ... ] some of the clock items get pre-enabled in the clock driver to not have them automatically disabled by the underlying clock subsystem because of their being unused -- this approach is desirable because [ ... ] - some help introduce support for and migrate to the common infrastructure, while more appropriate support for specific hardware constraints isn't available yet (remaining changes are strictly internal to the clock driver and won't affect peripheral drivers) This remark was related to the CAN clocks of the MPC512x SoC. Gerhard, Thanks for the patch (way far down below here). I'll check into it to see if that implementation looks OK. It would be helpful if another platform with shared gates could weigh in on whether the implementation works for them. Still, a shared gate solution is not a prerequisite for this series, correct? Well, the recent CAN driver related discussion suggested that I had a mental misconception there. The need for shared gates was felt because of mixing up unrelated paths in the clock tree. But the MCLK subtree is for bitrate generation, while the BDLC gate is for register access into the peripheral controller. Currently I'm investigating how I can cleanly tell those individual aspects apart. Telling the gate for register access (in ARM speak often referred to as 'ipg') from the bitrate generation (the 'per' clock, or 'mclk' here) seems so much more appropriate. After clean separation, and more testing to make sure nothing gets broken throughout the series, there will be v4. So shared gate support might have become obsolete for the MPC512x platform. But if others need it, the outlined approach (patch below) may be viable. The change to the common code is minimal. The use in the platform's clock driver was kind of overengineered for the case of exactly one such gate, but this immediately makes it a working approach for several gates, if others need it. I'll trim the motivation and just leave the suggested approach for shared gates here. Feel free to drop it or to only resurrect it as the need may re-arise later. So far nobody appears to have felt the need up to now ... You can drop it. If your platform does not need it and nobody else has said that they require shared gates then there is no reason to spend more time on it. Regards, Mike [ ... ] The question now is how to correctly support the situation where a gate is shared between subtrees yet isn't really part of any path within the subtrees. I really cannot find a single spot where to introduce the gate such that it's not duplicated. The appropriate solution would not be to pre-enable those clocks, but to either introduce another gate clock type which supports a shared reference, or to add support for the shared reference to the existing gate code. I'd rather not duplicate most or all of the code of clk-gate.c, instead I looked into how to add shared gate support to the existing driver. My question is whether the approach is acceptable. It adds minimal overhead and shall be OK for the enable/disable path from a technical POV. And it doesn't feel like too much of a stretch. But there may be non-technical reasons to reject the approach. I'd like to learn whether to follow that path before preparing another version of the patch series. The diffs were taken with the '-w -b' options to demonstrate their essence and not drown it in whitespace changes. The implementation assumes that the caller which registers the gate (the platform's clock driver) provides both the counter cell and the lock. And that all gates with a shared use counter use the same lock (which is satisfied as they all get registered from the same spot in the platform's clock driver). The CLK_IGNORE_UNUSED flag addresses a different problem. The SoC has four MSCAN components, while two of them are enabled in the device tree (the other two are present but disabled). So during probe two of the clocks get enabled. After probe all unused clocks automatically get disabled (that's another two). So the shared use counter drops to zero although components are in use, because disable, it's
Re: [PATCH 03/10] vfio: add external user support
On Tue, 2013-07-23 at 19:07 +1000, Alexey Kardashevskiy wrote: On 07/23/2013 12:23 PM, Alex Williamson wrote: On Tue, 2013-07-16 at 10:53 +1000, Alexey Kardashevskiy wrote: VFIO is designed to be used via ioctls on file descriptors returned by VFIO. However in some situations support for an external user is required. The first user is KVM on PPC64 (SPAPR TCE protocol) which is going to use the existing VFIO groups for exclusive access in real/virtual mode on a host to avoid passing map/unmap requests to the user space which would made things pretty slow. The protocol includes: 1. do normal VFIO init operation: - opening a new container; - attaching group(s) to it; - setting an IOMMU driver for a container. When IOMMU is set for a container, all groups in it are considered ready to use by an external user. 2. User space passes a group fd to an external user. The external user calls vfio_group_get_external_user() to verify that: - the group is initialized; - IOMMU is set for it. If both checks passed, vfio_group_get_external_user() increments the container user counter to prevent the VFIO group from disposal before KVM exits. 3. The external user calls vfio_external_user_iommu_id() to know an IOMMU ID. PPC64 KVM uses it to link logical bus number (LIOBN) with IOMMU ID. 4. When the external KVM finishes, it calls vfio_group_put_external_user() to release the VFIO group. This call decrements the container user counter. Everything gets released. The vfio: Limit group opens patch is also required for the consistency. Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru This looks fine to me. Is the plan to add this through the ppc tree again? Thanks, Nope, better to add this through your tree. And faster for sure :) Thanks! Applied to my next branch for v3.12. Thanks, Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Failure to detect PCI card
I have a PCI card (a Netgear FA331, vendor:device 100b:0020) that is failing to be detected by our PPC platform. This device works just fine in a PC, and other cards work just fine in the same PCI slot (we have an Intel 82540EM based card that works). But for some reason, neither u-boot nor the kernel detect this card. Any ideas why this might be? Thanks, Pete ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/11] Add compression support to pstore
See attachment for what I actually applied - I think I got what you suggested (I added a declaration for total_len). Forcing a panic worked some things were logged to pstore. But on reboot with your patches applied I'm still seeing a GP fault when pstore is mounted and we find compressed records and inflate them and install them into the pstore filesystem. Here's the oops: general protection fault: [#1] SMP Modules linked in: CPU: 29 PID: 10252 Comm: mount Not tainted 3.11.0-rc3-12-g73bec18 #2 Hardware name: Intel Corporation LH Pass ../SVRBD-ROW_T, BIOS SE5C600.86B.99.99.x059.091020121352 09/10/2012 task: 88082e934040 ti: 88082e2ec000 task.ti: 88082e2ec000 RIP: 0010:[8126d314] [8126d314] pstore_mkfile+0x84/0x410 RSP: 0018:88082e2edc70 EFLAGS: 00010007 RAX: 0246 RBX: 81ca7b20 RCX: 625f6963703e373c RDX: 00040004 RSI: 0004 RDI: 820aa7e8 RBP: 88082e2edd10 R08: 881026a48000 R09: R10: 88102d21efb8 R11: R12: 881026a48000 R13: 51ffe3560003 R14: R15: 4450 FS: 7fbd37a2d7e0() GS:88103fca() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7fbd37a47000 CR3: 00103dc78000 CR4: 000407e0 Stack: 881026a4c450 5227 81a3703d 881026a48000 2e2edd70 88103db34140 0001abaf 36383039 003a0fb8 881026a48000 88102d21e000 448a Call Trace: [8126dd7d] pstore_get_records+0xed/0x2c0 [8126cfa0] ? pstore_get_inode+0x50/0x50 [8126d042] pstore_fill_super+0xa2/0xc0 [811691f2] mount_single+0xa2/0xd0 [8126ce28] pstore_mount+0x18/0x20 [811693e3] mount_fs+0x43/0x1b0 [8112dc40] ? __alloc_percpu+0x10/0x20 [8118256f] vfs_kern_mount+0x6f/0x100 [81184a79] do_mount+0x259/0xa10 [81128bcb] ? strndup_user+0x5b/0x80 [811852be] SyS_mount+0x8e/0xe0 [81606802] system_call_fastpath+0x16/0x1b Code: 88 e8 f1 0f 39 00 48 8b 0d 0a 3a a2 00 48 81 f9 00 0d c9 81 75 15 eb 67 0f 1f 80 00 00 00 00 48 8b 09 48 81 f9 00 0d c9 81 74 54 44 39 71 18 75 ee 4c 39 69 20 75 e8 48 39 59 10 75 e2 48 89 c6 RIP [8126d314] pstore_mkfile+0x84/0x410 RSP 88082e2edc70 ---[ end trace 0e1dd8e3ccfa3dcc ]--- /etc/init.d/functions: line 530: 10252 Segmentation fault $@ Here's the start of my pstore_mkfile() code where the GP fault occurred: 8126d290 pstore_mkfile: 8126d290: e8 2b 91 39 00 callq 816063c0 __fentry__ 8126d295: 55 push %rbp 8126d296: 48 89 e5mov%rsp,%rbp 8126d299: 41 57 push %r15 8126d29b: 41 56 push %r14 8126d29d: 41 89 femov%edi,%r14d 8126d2a0: 48 c7 c7 e8 a7 0a 82mov$0x820aa7e8,%rdi 8126d2a7: 41 55 push %r13 8126d2a9: 49 89 d5mov%rdx,%r13 8126d2ac: 41 54 push %r12 8126d2ae: 53 push %rbx 8126d2af: 48 83 ec 78 sub$0x78,%rsp 8126d2b3: 89 4d 84mov%ecx,-0x7c(%rbp) 8126d2b6: 48 89 b5 70 ff ff ffmov%rsi,-0x90(%rbp) 8126d2bd: 65 48 8b 04 25 28 00mov%gs:0x28,%rax 8126d2c4: 00 00 8126d2c6: 48 89 45 d0 mov%rax,-0x30(%rbp) 8126d2ca: 31 c0 xor%eax,%eax 8126d2cc: 48 8b 05 0d d5 e3 00mov 0xe3d50d(%rip),%rax# 820aa7e0 pstore_sb 8126d2d3: 4c 89 85 78 ff ff ffmov%r8,-0x88(%rbp) 8126d2da: 44 89 4d 80 mov%r9d,-0x80(%rbp) 8126d2de: 48 8b 5d 28 mov0x28(%rbp),%rbx 8126d2e2: 48 8b 40 60 mov0x60(%rax),%rax 8126d2e6: 48 89 45 88 mov%rax,-0x78(%rbp) 8126d2ea: e8 f1 0f 39 00 callq 815fe2e0 _raw_spin_lock_irqsave 8126d2ef: 48 8b 0d 0a 3a a2 00mov 0xa23a0a(%rip),%rcx# 81c90d00 allpstore 8126d2f6: 48 81 f9 00 0d c9 81cmp$0x81c90d00,%rcx 8126d2fd: 75 15 jne 8126d314 pstore_mkfile+0x84 8126d2ff: eb 67 jmp 8126d368 pstore_mkfile+0xd8 8126d301: 0f 1f 80 00 00 00 00nopl 0x0(%rax) 8126d308: 48 8b 09mov(%rcx),%rcx 8126d30b: 48 81 f9 00 0d c9 81cmp$0x81c90d00,%rcx 8126d312: 74 54 je 8126d368 pstore_mkfile+0xd8 8126d314: 44
Re: Failure to detect PCI card
On Mon, 5 Aug 2013 10:58:01 -0700 Peter LaDow pet...@gocougs.wsu.edu wrote: I have a PCI card (a Netgear FA331, vendor:device 100b:0020) that is failing to be detected by our PPC platform. This device works just fine in a PC, and other cards work just fine in the same PCI slot (we have an Intel 82540EM based card that works). But for some reason, neither u-boot nor the kernel detect this card. Any ideas why this might be? Maybe this card needs bigger delay to respond after PCI reset. You can try to re-build U-Boot with defined CONFIG_PCI_BOOTDELAY. Use 1000 for CONFIG_PCI_BOOTDELAY in the first step and if detection works, try to decrease this value. HTH, Anatolij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Failure to detect PCI card
Dear Peter LaDow, In message can8q1ed-ytd1l7e9tajyeldcz5rcfdi0mdwu_h6hax0-3fj...@mail.gmail.com you wrote: I have a PCI card (a Netgear FA331, vendor:device 100b:0020) that is failing to be detected by our PPC platform. This device works just fine in a PC, and other cards work just fine in the same PCI slot (we have an Intel 82540EM based card that works). But for some reason, neither u-boot nor the kernel detect this card. Any ideas why this might be? Is there any chance that this card has some BIOS (like most graphic adapters do) which needs to run to put the card into an operative state (like by initializing any DRAM memory on the card)? OK, I would normally not expect such on a 10/100 PCI Ethernet network adapter, but I don't know this card at all... Do you know if this card works in any other non-x86 system at all? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Quote from a recent meeting: We are going to continue having these meetings everyday until I find out why no work is getting done. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Failure to detect PCI card
On Mon, Aug 5, 2013 at 11:25 AM, Anatolij Gustschin ag...@denx.de wrote: Maybe this card needs bigger delay to respond after PCI reset. You can try to re-build U-Boot with defined CONFIG_PCI_BOOTDELAY. Use 1000 for CONFIG_PCI_BOOTDELAY in the first step and if detection works, try to decrease this value. I'll give this a try. But a generic question. Does the kernel depend upon u-boot to initialize the PCI configuration? And, I know this is a u-boot specific question, but will u-boot ignore any PCI device it doesn't know about? Thus I have to enable a specific device in the u-boot configuration for u-boot to recognize it (and from there, have the kernel recognize it)? On Mon, Aug 5, 2013 at 11:32 AM, Wolfgang Denk w...@denx.de wrote: Is there any chance that this card has some BIOS (like most graphic adapters do) which needs to run to put the card into an operative state (like by initializing any DRAM memory on the card)? OK, I would normally not expect such on a 10/100 PCI Ethernet network adapter, but I don't know this card at all... Not that I'm aware of. I suppose the EEPROM to read in the configuration/MAC address? But I wouldn't think an option ROM would be present. Do you know if this card works in any other non-x86 system at all? Don't have any other non-x86 systems to try out. We have an MPC8349E-mITX board, but the PCI slot doesn't detect anything at all (not even our 82540EM based board). And this card doesn't work there either. Thanks, Pete ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/6 v2] kvm: powerpc: booke: Add linux pte lookup like booke3s
On Mon, 2013-08-05 at 09:27 -0500, Bhushan Bharat-R65777 wrote:
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
Sent: Saturday, August 03, 2013 9:54 AM
To: Bhushan Bharat-R65777
Cc: Wood Scott-B07421; ag...@suse.de; kvm-...@vger.kernel.org;
k...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 5/6 v2] kvm: powerpc: booke: Add linux pte lookup like
booke3s
On Sat, 2013-08-03 at 02:58 +, Bhushan Bharat-R65777 wrote:
One of the problem I saw was that if I put this code in
asm/pgtable-32.h and asm/pgtable-64.h then pte_persent() and other
friend function (on which this code depends) are defined in pgtable.h.
And pgtable.h includes asm/pgtable-32.h and asm/pgtable-64.h before it
defines pte_present() and friends functions.
Ok I move wove this in asm/pgtable*.h, initially I fought with myself
to take this code in pgtable* but finally end up doing here (got
biased by book3s :)).
Is there a reason why these routines can not be completely generic in
pgtable.h
?
How about the generic function:
diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h
b/arch/powerpc/include/asm/pgtable-ppc64.h
index d257d98..21daf28 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -221,6 +221,27 @@ static inline unsigned long pte_update(struct mm_struct
*mm,
return old;
}
+static inline unsigned long pte_read(pte_t *p)
+{
+#ifdef PTE_ATOMIC_UPDATES
+ pte_t pte;
+ pte_t tmp;
+ __asm__ __volatile__ (
+ 1: ldarx %0,0,%3\n
+ andi. %1,%0,%4\n
+ bne-1b\n
+ ori %1,%0,%4\n
+ stdcx. %1,0,%3\n
+ bne-1b
+ : =r (pte), =r (tmp), =m (*p)
+ : r (p), i (_PAGE_BUSY)
+ : cc);
+
+ return pte;
+#else
+ return pte_val(*p);
+#endif
+#endif
+}
static inline int __ptep_test_and_clear_young(struct mm_struct *mm,
unsigned long addr, pte_t *ptep)
Please leave a blank line between functions.
{
diff --git a/arch/powerpc/include/asm/pgtable.h
b/arch/powerpc/include/asm/pgtable.h
index 690c8c2..dad712c 100644
--- a/arch/powerpc/include/asm/pgtable.h
+++ b/arch/powerpc/include/asm/pgtable.h
@@ -254,6 +254,45 @@ static inline pte_t *find_linux_pte_or_hugepte(pgd_t
*pgdir, unsigned long ea,
}
#endif /* !CONFIG_HUGETLB_PAGE */
+static inline pte_t lookup_linux_pte(pgd_t *pgdir, unsigned long hva,
+int writing, unsigned long *pte_sizep)
The name implies that it just reads the PTE. Setting accessed/dirty
shouldn't be an undocumented side-effect. Why can't the caller do that
(or a different function that the caller calls afterward if desired)?
Though even then you have the undocumented side effect of locking the
PTE on certain targets.
+{
+ pte_t *ptep;
+ pte_t pte;
+ unsigned long ps = *pte_sizep;
+ unsigned int shift;
+
+ ptep = find_linux_pte_or_hugepte(pgdir, hva, shift);
+ if (!ptep)
+ return __pte(0);
+ if (shift)
+ *pte_sizep = 1ul shift;
+ else
+ *pte_sizep = PAGE_SIZE;
+
+ if (ps *pte_sizep)
+ return __pte(0);
+
+ if (!pte_present(*ptep))
+ return __pte(0);
+
+#ifdef CONFIG_PPC64
+ /* Lock PTE (set _PAGE_BUSY) and read */
+ pte = pte_read(ptep);
+#else
+ pte = pte_val(*ptep);
+#endif
What about 32-bit platforms that need atomic PTEs?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/11] Add compression support to pstore
Hi Tony, On Monday 05 August 2013 11:52 PM, Tony Luck wrote: See attachment for what I actually applied - I think I got what you suggested (I added a declaration for total_len). Forcing a panic worked some things were logged to pstore. But on reboot with your patches applied I'm still seeing a GP fault when pstore is mounted and we find compressed records and inflate them and install them into the pstore filesystem. Here's the oops: general protection fault: [#1] SMP Modules linked in: CPU: 29 PID: 10252 Comm: mount Not tainted 3.11.0-rc3-12-g73bec18 #2 Hardware name: Intel Corporation LH Pass ../SVRBD-ROW_T, BIOS SE5C600.86B.99.99.x059.091020121352 09/10/2012 task: 88082e934040 ti: 88082e2ec000 task.ti: 88082e2ec000 RIP: 0010:[8126d314] [8126d314] pstore_mkfile+0x84/0x410 RSP: 0018:88082e2edc70 EFLAGS: 00010007 RAX: 0246 RBX: 81ca7b20 RCX: 625f6963703e373c RDX: 00040004 RSI: 0004 RDI: 820aa7e8 RBP: 88082e2edd10 R08: 881026a48000 R09: R10: 88102d21efb8 R11: R12: 881026a48000 R13: 51ffe3560003 R14: R15: 4450 FS: 7fbd37a2d7e0() GS:88103fca() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7fbd37a47000 CR3: 00103dc78000 CR4: 000407e0 Stack: 881026a4c450 5227 81a3703d 881026a48000 2e2edd70 88103db34140 0001abaf 36383039 003a0fb8 881026a48000 88102d21e000 448a Call Trace: [8126dd7d] pstore_get_records+0xed/0x2c0 [8126cfa0] ? pstore_get_inode+0x50/0x50 [8126d042] pstore_fill_super+0xa2/0xc0 [811691f2] mount_single+0xa2/0xd0 [8126ce28] pstore_mount+0x18/0x20 [811693e3] mount_fs+0x43/0x1b0 [8112dc40] ? __alloc_percpu+0x10/0x20 [8118256f] vfs_kern_mount+0x6f/0x100 [81184a79] do_mount+0x259/0xa10 [81128bcb] ? strndup_user+0x5b/0x80 [811852be] SyS_mount+0x8e/0xe0 [81606802] system_call_fastpath+0x16/0x1b Code: 88 e8 f1 0f 39 00 48 8b 0d 0a 3a a2 00 48 81 f9 00 0d c9 81 75 15 eb 67 0f 1f 80 00 00 00 00 48 8b 09 48 81 f9 00 0d c9 81 74 54 44 39 71 18 75 ee 4c 39 69 20 75 e8 48 39 59 10 75 e2 48 89 c6 RIP [8126d314] pstore_mkfile+0x84/0x410 RSP 88082e2edc70 ---[ end trace 0e1dd8e3ccfa3dcc ]--- /etc/init.d/functions: line 530: 10252 Segmentation fault $@ Here's the start of my pstore_mkfile() code where the GP fault occurred: 8126d290 pstore_mkfile: 8126d290: e8 2b 91 39 00 callq 816063c0 __fentry__ 8126d295: 55 push %rbp 8126d296: 48 89 e5mov%rsp,%rbp 8126d299: 41 57 push %r15 8126d29b: 41 56 push %r14 8126d29d: 41 89 femov%edi,%r14d 8126d2a0: 48 c7 c7 e8 a7 0a 82mov$0x820aa7e8,%rdi 8126d2a7: 41 55 push %r13 8126d2a9: 49 89 d5mov%rdx,%r13 8126d2ac: 41 54 push %r12 8126d2ae: 53 push %rbx 8126d2af: 48 83 ec 78 sub$0x78,%rsp 8126d2b3: 89 4d 84mov%ecx,-0x7c(%rbp) 8126d2b6: 48 89 b5 70 ff ff ffmov%rsi,-0x90(%rbp) 8126d2bd: 65 48 8b 04 25 28 00mov%gs:0x28,%rax 8126d2c4: 00 00 8126d2c6: 48 89 45 d0 mov%rax,-0x30(%rbp) 8126d2ca: 31 c0 xor%eax,%eax 8126d2cc: 48 8b 05 0d d5 e3 00mov 0xe3d50d(%rip),%rax# 820aa7e0 pstore_sb 8126d2d3: 4c 89 85 78 ff ff ffmov%r8,-0x88(%rbp) 8126d2da: 44 89 4d 80 mov%r9d,-0x80(%rbp) 8126d2de: 48 8b 5d 28 mov0x28(%rbp),%rbx 8126d2e2: 48 8b 40 60 mov0x60(%rax),%rax 8126d2e6: 48 89 45 88 mov%rax,-0x78(%rbp) 8126d2ea: e8 f1 0f 39 00 callq 815fe2e0 _raw_spin_lock_irqsave 8126d2ef: 48 8b 0d 0a 3a a2 00mov 0xa23a0a(%rip),%rcx# 81c90d00 allpstore 8126d2f6: 48 81 f9 00 0d c9 81cmp$0x81c90d00,%rcx 8126d2fd: 75 15 jne 8126d314 pstore_mkfile+0x84 8126d2ff: eb 67 jmp 8126d368 pstore_mkfile+0xd8 8126d301: 0f 1f 80 00 00 00 00nopl 0x0(%rax) 8126d308: 48 8b 09mov(%rcx),%rcx 8126d30b: 48 81 f9 00 0d c9 81cmp$0x81c90d00,%rcx 8126d312: 74 54
[PATCH v3 1/2] powerpc: Add smp_generic_cpu_bootable
Cell and PSeries both implemented their own versions of a
cpu_bootable smp_op which do the same thing (well, the PSeries
one has support for more than 2 threads). Copy the PSeries one
to generic code, and rename it smp_generic_cpu_bootable.
Signed-off-by: Andy Fleming aflem...@freescale.com
---
v3: Removed EXPORT_SYMBOL()
v2: Removed Change-Id
arch/powerpc/include/asm/smp.h |2 ++
arch/powerpc/kernel/smp.c | 22 ++
2 files changed, 24 insertions(+)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index 48cfc85..9a5e71b 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -186,6 +186,8 @@ extern int smt_enabled_at_boot;
extern int smp_mpic_probe(void);
extern void smp_mpic_setup_cpu(int cpu);
extern int smp_generic_kick_cpu(int nr);
+extern int smp_generic_cpu_bootable(unsigned int nr);
+
extern void smp_generic_give_timebase(void);
extern void smp_generic_take_timebase(void);
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 38b0ba6..d947735 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -81,6 +81,28 @@ int smt_enabled_at_boot = 1;
static void (*crash_ipi_function_ptr)(struct pt_regs *) = NULL;
+/*
+ * Returns 1 if the specified cpu should be brought up during boot.
+ * Used to inhibit booting threads if they've been disabled or
+ * limited on the command line
+ */
+int smp_generic_cpu_bootable(unsigned int nr)
+{
+ /* Special case - we inhibit secondary thread startup
+* during boot if the user requests it.
+*/
+ if (system_state == SYSTEM_BOOTING cpu_has_feature(CPU_FTR_SMT)) {
+ if (!smt_enabled_at_boot cpu_thread_in_core(nr) != 0)
+ return 0;
+ if (smt_enabled_at_boot
+cpu_thread_in_core(nr) = smt_enabled_at_boot)
+ return 0;
+ }
+
+ return 1;
+}
+
+
#ifdef CONFIG_PPC64
int smp_generic_kick_cpu(int nr)
{
--
1.7.9.7
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 2/2] powerpc: Convert platforms to smp_generic_cpu_bootable
T4, Cell, powernv, and pseries had the same implementation, so switch
them to use a generic version. A2 apparently had a version, but
removed it at some point, so we remove the declaration, too.
Signed-off-by: Andy Fleming aflem...@freescale.com
---
v3: No change
v2: Removed Change-Id
arch/powerpc/platforms/85xx/smp.c|1 +
arch/powerpc/platforms/cell/smp.c| 15 +--
arch/powerpc/platforms/powernv/smp.c | 18 +-
arch/powerpc/platforms/pseries/smp.c | 18 +-
arch/powerpc/platforms/wsp/wsp.h |1 -
5 files changed, 4 insertions(+), 49 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/smp.c
b/arch/powerpc/platforms/85xx/smp.c
index 5ced4f5..ea9c626 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -255,6 +255,7 @@ out:
struct smp_ops_t smp_85xx_ops = {
.kick_cpu = smp_85xx_kick_cpu,
+ .cpu_bootable = smp_generic_cpu_bootable,
#ifdef CONFIG_HOTPLUG_CPU
.cpu_disable= generic_cpu_disable,
.cpu_die= generic_cpu_die,
diff --git a/arch/powerpc/platforms/cell/smp.c
b/arch/powerpc/platforms/cell/smp.c
index f75f6fc..90745ea 100644
--- a/arch/powerpc/platforms/cell/smp.c
+++ b/arch/powerpc/platforms/cell/smp.c
@@ -136,25 +136,12 @@ static int smp_cell_kick_cpu(int nr)
return 0;
}
-static int smp_cell_cpu_bootable(unsigned int nr)
-{
- /* Special case - we inhibit secondary thread startup
-* during boot if the user requests it. Odd-numbered
-* cpus are assumed to be secondary threads.
-*/
- if (system_state == SYSTEM_BOOTING
- cpu_has_feature(CPU_FTR_SMT)
- !smt_enabled_at_boot cpu_thread_in_core(nr) != 0)
- return 0;
-
- return 1;
-}
static struct smp_ops_t bpa_iic_smp_ops = {
.message_pass = iic_message_pass,
.probe = smp_iic_probe,
.kick_cpu = smp_cell_kick_cpu,
.setup_cpu = smp_cell_setup_cpu,
- .cpu_bootable = smp_cell_cpu_bootable,
+ .cpu_bootable = smp_generic_cpu_bootable,
};
/* This is called very early */
diff --git a/arch/powerpc/platforms/powernv/smp.c
b/arch/powerpc/platforms/powernv/smp.c
index 89e3857..908672b 100644
--- a/arch/powerpc/platforms/powernv/smp.c
+++ b/arch/powerpc/platforms/powernv/smp.c
@@ -46,22 +46,6 @@ static void pnv_smp_setup_cpu(int cpu)
xics_setup_cpu();
}
-static int pnv_smp_cpu_bootable(unsigned int nr)
-{
- /* Special case - we inhibit secondary thread startup
-* during boot if the user requests it.
-*/
- if (system_state == SYSTEM_BOOTING cpu_has_feature(CPU_FTR_SMT)) {
- if (!smt_enabled_at_boot cpu_thread_in_core(nr) != 0)
- return 0;
- if (smt_enabled_at_boot
-cpu_thread_in_core(nr) = smt_enabled_at_boot)
- return 0;
- }
-
- return 1;
-}
-
int pnv_smp_kick_cpu(int nr)
{
unsigned int pcpu = get_hard_smp_processor_id(nr);
@@ -195,7 +179,7 @@ static struct smp_ops_t pnv_smp_ops = {
.probe = xics_smp_probe,
.kick_cpu = pnv_smp_kick_cpu,
.setup_cpu = pnv_smp_setup_cpu,
- .cpu_bootable = pnv_smp_cpu_bootable,
+ .cpu_bootable = smp_generic_cpu_bootable,
#ifdef CONFIG_HOTPLUG_CPU
.cpu_disable= pnv_smp_cpu_disable,
.cpu_die= generic_cpu_die,
diff --git a/arch/powerpc/platforms/pseries/smp.c
b/arch/powerpc/platforms/pseries/smp.c
index 306643c..ca2d1f6 100644
--- a/arch/powerpc/platforms/pseries/smp.c
+++ b/arch/powerpc/platforms/pseries/smp.c
@@ -187,22 +187,6 @@ static int smp_pSeries_kick_cpu(int nr)
return 0;
}
-static int smp_pSeries_cpu_bootable(unsigned int nr)
-{
- /* Special case - we inhibit secondary thread startup
-* during boot if the user requests it.
-*/
- if (system_state == SYSTEM_BOOTING cpu_has_feature(CPU_FTR_SMT)) {
- if (!smt_enabled_at_boot cpu_thread_in_core(nr) != 0)
- return 0;
- if (smt_enabled_at_boot
-cpu_thread_in_core(nr) = smt_enabled_at_boot)
- return 0;
- }
-
- return 1;
-}
-
/* Only used on systems that support multiple IPI mechanisms */
static void pSeries_cause_ipi_mux(int cpu, unsigned long data)
{
@@ -237,7 +221,7 @@ static struct smp_ops_t pSeries_xics_smp_ops = {
.probe = pSeries_smp_probe,
.kick_cpu = smp_pSeries_kick_cpu,
.setup_cpu = smp_xics_setup_cpu,
- .cpu_bootable = smp_pSeries_cpu_bootable,
+ .cpu_bootable = smp_generic_cpu_bootable,
};
/* This is called very early */
diff --git a/arch/powerpc/platforms/wsp/wsp.h b/arch/powerpc/platforms/wsp/wsp.h
index 62ef21a..a563a8a 100644
--- a/arch/powerpc/platforms/wsp/wsp.h
+++ b/arch/powerpc/platforms/wsp/wsp.h
@@
Re: Failure to detect PCI card
On Mon, Aug 5, 2013 at 11:25 AM, Anatolij Gustschin ag...@denx.de wrote: Maybe this card needs bigger delay to respond after PCI reset. You can try to re-build U-Boot with defined CONFIG_PCI_BOOTDELAY. Use 1000 for CONFIG_PCI_BOOTDELAY in the first step and if detection works, try to decrease this value. That didn't work. But perhaps the problem is because these are older PCI parts, and don't implement ECAM (only the older CAM)? I don't think u-boot limits itself... Thanks, Pete ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Failure to detect PCI card
Hi Pete, On Mon, Aug 5, 2013 at 11:25 AM, Anatolij Gustschin ag...@denx.de wrote: Maybe this card needs bigger delay to respond after PCI reset. You can try to re-build U-Boot with defined CONFIG_PCI_BOOTDELAY. Use 1000 for CONFIG_PCI_BOOTDELAY in the first step and if detection works, try to decrease this value. That didn't work. But perhaps the problem is because these are older PCI parts, and don't implement ECAM (only the older CAM)? I don't think u-boot limits itself... Since you're looking for suggestions (apologies if these are too obvious); 1. Have you checked the power supplies on the PCI board? PCI boards can be powered from 3.3V or 5V, or both. I've had old PCs that only supply one or the other rail, and various evaluation boards that only supply 3.3V. If you can put together a working x86 setup that detects the board, then you could poke around and see what voltages exist on some of the decoupling components, then plug it into your real system, and see what voltages you measure there. 2. Have you probed the PCI bus using a bus analyzer or scope? If you have a PCI bus analyzer (or can find someone with one), plug it in and see what happens at power-on (there should be configuration cycles). At a minimum, if you have a 'scope, see if the PCI configuration space access handshakes are active during power-on. 3. Is debugging this PCI card worth your time? Sometimes the solution involves tossing old hardware in the trash. Cheers, Dave ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Failure to detect PCI card
On Mon, Aug 5, 2013 at 1:27 PM, David Hawkins d...@ovro.caltech.edu wrote: 1. Have you checked the power supplies on the PCI board? PCI boards can be powered from 3.3V or 5V, or both. I've had old PCs that only supply one or the other rail, and various evaluation boards that only supply 3.3V. If you can put together a working x86 setup that detects the board, then you could poke around and see what voltages exist on some of the decoupling components, then plug it into your real system, and see what voltages you measure there. These are universal boards. Our board does only support only 3V3 (and is slotted as such). 2. Have you probed the PCI bus using a bus analyzer or scope? If you have a PCI bus analyzer (or can find someone with one), plug it in and see what happens at power-on (there should be configuration cycles). At a minimum, if you have a 'scope, see if the PCI configuration space access handshakes are active during power-on. Hmm...I do have one. But I can't get both the analyzer and the card in the system in at the same time. 3. Is debugging this PCI card worth your time? Sometimes the solution involves tossing old hardware in the trash. Well, this is part of the ongoing work regarding the incoming PCI memory corruption. We are going down the path of abandoning the 82540 for our platform because we can't seem to track down the corruption. So we are looking at other chipsets which we can purchase, which include this National (now TI) chipset on the Netgear FA331. If we could find a PCI (_not_ PCIe) card to test with that seems to work... Interestingly, I have an older 3com 3C905TXM exhibiting the same behavior. Both of these are older cards (they even came with drivers on--gasp--floppies!). Maybe the lack of a 5V supply is an issue... Thanks, Pete ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Failure to detect PCI card
Hi Pete, 1. Have you checked the power supplies on the PCI board? PCI boards can be powered from 3.3V or 5V, or both. I've had old PCs that only supply one or the other rail, and various evaluation boards that only supply 3.3V. If you can put together a working x86 setup that detects the board, then you could poke around and see what voltages exist on some of the decoupling components, then plug it into your real system, and see what voltages you measure there. These are universal boards. Our board does only support only 3V3 (and is slotted as such). Ok. 2. Have you probed the PCI bus using a bus analyzer or scope? If you have a PCI bus analyzer (or can find someone with one), plug it in and see what happens at power-on (there should be configuration cycles). At a minimum, if you have a 'scope, see if the PCI configuration space access handshakes are active during power-on. Hmm...I do have one. But I can't get both the analyzer and the card in the system in at the same time. My analyzer has an extender card that you first plug in, and then plug the board into that ... any chance someone in your organization has one of those cards? Alternatively, confirm the board works in a machine that has more than one slot, and if it does not, use the analyzer to see what is happening. 3. Is debugging this PCI card worth your time? Sometimes the solution involves tossing old hardware in the trash. Well, this is part of the ongoing work regarding the incoming PCI memory corruption. Ok, I recall seeing that thread. We are going down the path of abandoning the 82540 for our platform because we can't seem to track down the corruption. So we are looking at other chipsets which we can purchase, which include this National (now TI) chipset on the Netgear FA331. If we could find a PCI (_not_ PCIe) card to test with that seems to work... Interestingly, I have an older 3com 3C905TXM exhibiting the same behavior. Both of these are older cards (they even came with drivers on--gasp--floppies!). Maybe the lack of a 5V supply is an issue... If you're looking for a PCI target that you can completely control, then if you have an FPGA guy in your company, perhaps he can dig up a low-cost PCI card that you can configure as a PCI master to emulate the functions of a network card. Actually, before going down that route, I would get a PCI extender that you can use to trace the traffic with your board. Does the network card use 33MHz or 66MHz? Cheers, Dave ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Add device file bindings for MAPLE
On Thu, 2013-08-01 at 11:05 -0500, Kumar Gala wrote: On Aug 1, 2013, at 6:02 AM, Shaveta Leekha wrote: Signed-off-by: Shaveta Leekha shav...@freescale.com --- .../devicetree/bindings/powerpc/fsl/maple.txt | 30 1 files changed, 30 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/maple.txt diff --git a/Documentation/devicetree/bindings/powerpc/fsl/maple.txt b/Documentation/devicetree/bindings/powerpc/fsl/maple.txt new file mode 100644 index 000..da51c5f --- /dev/null +++ b/Documentation/devicetree/bindings/powerpc/fsl/maple.txt @@ -0,0 +1,30 @@ +* Freescale MAPLE Multi Accelerator Platform Engine Baseband 3 + (MAPLE-B3)device nodes + +Supported chips: +Example: B4860 + +Required properties: + +- compatible: Should contain fsl,maple-b3-liodn as the value + This identifies Multi Accelerator Platform Engine + Baseband 3 block.This representation is required + for doing the PAMU/LIODN programming on the Linux side. This compatible makes no sense, we shouldn't be marking a full HW block with some name that is just intended for LIODN convenance. The point is we're not describing the whole block here, because the rest of the block is owned by an external entity (the DSP cores). Is this version 3 of the block? If so a name like fsl,maple-v3 or fsl,maple-v3.0 would be more appropriate. - k + +- reg: offset and length of the register set for the device + +Devices that have LIODNs need to specify links to the parent PAMU controller +(the actual PAMU controller that this device is connected to) and a pointer to +the LIODN register, if applicable. Does Maple not have any IRQs associated with it? maple-liodn doesn't. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Failure to detect PCI card
Hi Pete, Actually, before going down that route, I would get a PCI extender that you can use to trace the traffic with your board. Does the network card use 33MHz or 66MHz? I wonder if something like this board: http://www.logicsupply.com/products/pci122_dflex can be used to make a single PCI slot into two PCI slots. You could then plug your analyzer into the second slot. For $30 it might be worth a shot ... Cheers, Dave ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/11] Add compression support to pstore
This patch seems to fix the garbage at the end problem. Booting an old kernel and using openssl decodes them OK. Still have problems booting if there are any compressed images in ERST to be inflated. -Tony ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Failure to detect PCI card
On Mon, Aug 5, 2013 at 2:08 PM, David Hawkins d...@ovro.caltech.edu wrote: My analyzer has an extender card that you first plug in, and then plug the board into that ... any chance someone in your organization has one of those cards? Alternatively, confirm the board works in a machine that has more than one slot, and if it does not, use the analyzer to see what is happening. Mine has an extender as well, but it is a 5V only extender (such as the one you pointed out). I'll ask the HW guys if they have a 3V somewhere. Now, I'm not a PCI expoert, but, I can do PCI transactions via u-boot. And probing the PCI space via u-boot reveals nothing on 00:14.0 (the place where our 82540 typically shows up). Indeed, it returns all FF's, so I presume that means nothing is there. And enabling PCI_ENUM is u-boot causes an exception when I try 'pci enum' (with an older version of u-boot) or hangs u-boot (in 2013.07). If you're looking for a PCI target that you can completely control, then if you have an FPGA guy in your company, perhaps he can dig up a low-cost PCI card that you can configure as a PCI master to emulate the functions of a network card. Well, we do have an FPGA hanging off the bus. But getting an RTL guy to do thishmmm. I'll have to explore more. Actually, before going down that route, I would get a PCI extender that you can use to trace the traffic with your board. Does the network card use 33MHz or 66MHz? It's at 33MHz. I just need to find a 3V extender somewhere... Thanks, Pete ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Add device file bindings for MAPLE
On Thu, 2013-08-01 at 16:32 +0530, Shaveta Leekha wrote:
Signed-off-by: Shaveta Leekha shav...@freescale.com
---
.../devicetree/bindings/powerpc/fsl/maple.txt | 30
1 files changed, 30 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/maple.txt
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/maple.txt
b/Documentation/devicetree/bindings/powerpc/fsl/maple.txt
new file mode 100644
index 000..da51c5f
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/maple.txt
@@ -0,0 +1,30 @@
+* Freescale MAPLE Multi Accelerator Platform Engine Baseband 3
+ (MAPLE-B3)device nodes
+
+Supported chips:
+Example: B4860
+
+Required properties:
+
+- compatible:Should contain fsl,maple-b3-liodn as the value
+ This identifies Multi Accelerator Platform Engine
+ Baseband 3 block.This representation is required
+ for doing the PAMU/LIODN programming on the Linux side.
Device tree bindings should not talk about particular OSes or use cases
(except for use case information that is part of the AMP partitioning,
and thus not at the discretion of the OS). Just say that this
identifies the LIODN register of the block.
+
+- reg: offset and length of the register set for the device
+
+Devices that have LIODNs need to specify links to the parent PAMU controller
+(the actual PAMU controller that this device is connected to) and a pointer
to
+the LIODN register, if applicable.
+
+- fsl,iommu-parent
+ : phandle
+ This property should be present
+
+Example:
+ /* B4860 */
+ maple@80 {
+ compatible = fsl,maple-b3-liodn;
+ reg = 0x800 0x1;
Unit address doesn't match reg (missing/extra zero).
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Add device file bindings for MAPLE
On Aug 5, 2013, at 4:11 PM, Scott Wood wrote: On Thu, 2013-08-01 at 11:05 -0500, Kumar Gala wrote: On Aug 1, 2013, at 6:02 AM, Shaveta Leekha wrote: Signed-off-by: Shaveta Leekha shav...@freescale.com --- .../devicetree/bindings/powerpc/fsl/maple.txt | 30 1 files changed, 30 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/maple.txt diff --git a/Documentation/devicetree/bindings/powerpc/fsl/maple.txt b/Documentation/devicetree/bindings/powerpc/fsl/maple.txt new file mode 100644 index 000..da51c5f --- /dev/null +++ b/Documentation/devicetree/bindings/powerpc/fsl/maple.txt @@ -0,0 +1,30 @@ +* Freescale MAPLE Multi Accelerator Platform Engine Baseband 3 + (MAPLE-B3)device nodes + +Supported chips: +Example: B4860 + +Required properties: + +- compatible: Should contain fsl,maple-b3-liodn as the value + This identifies Multi Accelerator Platform Engine + Baseband 3 block.This representation is required + for doing the PAMU/LIODN programming on the Linux side. This compatible makes no sense, we shouldn't be marking a full HW block with some name that is just intended for LIODN convenance. The point is we're not describing the whole block here, because the rest of the block is owned by an external entity (the DSP cores). So the binding should make that far more clear that the MAPLE would be controlled by DSP SW. Is this version 3 of the block? If so a name like fsl,maple-v3 or fsl,maple-v3.0 would be more appropriate. - k + +- reg: offset and length of the register set for the device + So the reg should limit itself to the LIODN registers only. +Devices that have LIODNs need to specify links to the parent PAMU controller +(the actual PAMU controller that this device is connected to) and a pointer to +the LIODN register, if applicable. Does Maple not have any IRQs associated with it? maple-liodn doesn't. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Failure to detect PCI card
On Mon, Aug 5, 2013 at 1:27 PM, David Hawkins d...@ovro.caltech.edu wrote: 2. Have you probed the PCI bus using a bus analyzer or scope? Ok. I managed to find someone with a bus extender, and have connected both our analyzer and card. With a working card (the 82540EM based card), I see configuration reads on 0x0004, 0x0008, and 0x0010 succeed. The 4 and 8 correspond to the IDSEL's for our on-board ethernet (also 82540 based) and our FPGA, respectively (these configuration addresses match the IDSEL on our schematic, and these accesses are present when no card is plugged into the expansion slot). The 0x10 corresponds with the 82540 based network card. All the vendor/device id's make sense. However, replacing the 82540 based card with either a 3com 3C905TXM or the Netgear FA331, there is no response on the 0x10 IDSEL line. Thus it appears these cards are NOT responding to configuration reads. I think I have to break out the scope and probe around for the 5V/3V. I wouldn't think that the supplies are the issue since these are universal cards, and as I understand it either 3V3 _or_ 5V can be present, so these should work fine. Yet they aren't responding to PCI configuration cycles. I'll have to do more digging. Thanks, Pete ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Failure to detect PCI card
On Mon, Aug 5, 2013 at 4:07 PM, Peter LaDow pet...@gocougs.wsu.edu wrote: However, replacing the 82540 based card with either a 3com 3C905TXM or the Netgear FA331, there is no response on the 0x10 IDSEL line. Thus it appears these cards are NOT responding to configuration reads. I think I have to break out the scope and probe around for the 5V/3V. I wouldn't think that the supplies are the issue since these are universal cards, and as I understand it either 3V3 _or_ 5V can be present, so these should work fine. Yet they aren't responding to PCI configuration cycles. A few more notes. I tried a variety of other cards, such as a PCI modem (WinMode, ack), a WinTV card, and a PCI based 802.11 card. All of them enumerate perfectly. Perhaps it is a BIOS option ROM like you suggested earlier. The 3c90xC reference manual I found (http://people.freebsd.org/~wpaul/3Com/3c90xc.pdf) mentions an option ROM (and there is an Atmel part stuffed). I can't find any technical information on the FA331 (yet), so I don't know about it. But regardless, wouldn't enumeration have to occur before any option ROM could even be used? Thanks, Pete ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 6/8] powerpc: introduce early_get_first_memblock_info
On Sun, 2013-08-04 at 08:45 +0800, Kevin Hao wrote:
On Fri, Jul 26, 2013 at 07:18:01PM -0500, Scott Wood wrote:
+ * This function run before early_init_devtree, so we have to init
+ * initial_boot_params. Since early_init_dt_scan_memory_ppc will be
+ * executed again in early_init_devtree, we have to reinitialize the
+ * memblock data before return.
+ */
+void __init early_get_first_memblock_info(void *params,
phys_addr_t *size)
+{
+ /* Setup flat device-tree pointer */
+ initial_boot_params = params;
+
+ /* Scan memory nodes and rebuild MEMBLOCKs */
+ of_scan_flat_dt(early_init_dt_scan_root, NULL);
+ of_scan_flat_dt(early_init_dt_scan_memory_ppc, NULL);
+
+ if (size)
+ *size = first_memblock_size;
+
+ /* Undo what early_init_dt_scan_memory_ppc does to memblock */
+ memblock_reinit();
+}
+#endif
Wouldn't it be simpler to set a flag so that
early_init_dt_add_memory_arch() doesn't mess with memblocks on the
first pass?
Do you mean something like this?
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 9a69d2d..e861394 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -523,6 +523,10 @@ static int __init early_init_dt_scan_memory_ppc(unsigned
long node,
void __init early_init_dt_add_memory_arch(u64 base, u64 size)
{
+#if defined(CONFIG_RELOCATABLE) defined(CONFIG_FSL_BOOKE)
+ static int first_time = 1;
+#endif
+
#ifdef CONFIG_PPC64
if (iommu_is_off) {
if (base = 0x8000ul)
@@ -541,6 +545,13 @@ void __init early_init_dt_add_memory_arch(u64 base, u64
size)
}
/* Add the chunk to the MEMBLOCK list */
+
+#if defined(CONFIG_RELOCATABLE) defined(CONFIG_FSL_BOOKE)
+ if (first_time) {
+ first_time = 0;
+ return;
+ }
+#endif
memblock_add(base, size);
}
I think it'd be clearer for it to be an external variable that gets set
by the relocation code -- plus, the above wouldn't work if this gets
called twice due to having multiple memory regions.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 7/8] powerpc/fsl_booke: make sure PAGE_OFFSET map to memstart_addr for relocatable kernel
On Sun, 2013-08-04 at 08:50 +0800, Kevin Hao wrote: On Fri, Jul 26, 2013 at 07:17:57PM -0500, Scott Wood wrote: diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm/fsl_booke_mmu.c index 8f60ef8..dd283fd 100644 --- a/arch/powerpc/mm/fsl_booke_mmu.c +++ b/arch/powerpc/mm/fsl_booke_mmu.c @@ -224,7 +224,7 @@ void __init adjust_total_lowmem(void) i = switch_to_as1(); __max_low_memory = map_mem_in_cams(ram, CONFIG_LOWMEM_CAM_NUM); - restore_to_as0(i); + restore_to_as0(i, 0, 0); The device tree virtual address is zero? No. But if the __pa(PAGE_OFFSET in AS0) is equal to __pa(PAGE_OFFSET in AS1), that mean we don't need to do another relocation and the device tree virtual address is useless in this case. The documentation of restore_to_as0() should make it clear that r5 is ignored if r4 is zero. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 7/8] powerpc/fsl_booke: make sure PAGE_OFFSET map to memstart_addr for relocatable kernel
On Thu, 2013-07-04 at 20:54 +0800, Kevin Hao wrote: @@ -1222,6 +1266,9 @@ _GLOBAL(switch_to_as1) /* * Restore to the address space 0 and also invalidate the tlb entry created * by switch_to_as1. + * r3 - the tlb entry which should be invalidated + * r4 - __pa(PAGE_OFFSET in AS0) - pa(PAGE_OFFSET in AS1) + * r5 - device tree virtual address */ _GLOBAL(restore_to_as0) [snip] diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h index 3a65644..8280dbb 100644 --- a/arch/powerpc/mm/mmu_decl.h +++ b/arch/powerpc/mm/mmu_decl.h @@ -149,7 +149,7 @@ extern void MMU_init_hw(void); extern unsigned long mmu_mapin_ram(unsigned long top); extern void adjust_total_lowmem(void); extern int switch_to_as1(void); -extern void restore_to_as0(int); +extern void restore_to_as0(int, int, void *); int seems wrong for the second argument. Shouldn't it be phys_addr_t? Also, please use parameter names. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 5/6 v2] kvm: powerpc: booke: Add linux pte lookup like booke3s
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, August 06, 2013 12:49 AM
To: Bhushan Bharat-R65777
Cc: Benjamin Herrenschmidt; Wood Scott-B07421; ag...@suse.de; kvm-
p...@vger.kernel.org; k...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 5/6 v2] kvm: powerpc: booke: Add linux pte lookup like
booke3s
On Mon, 2013-08-05 at 09:27 -0500, Bhushan Bharat-R65777 wrote:
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
Sent: Saturday, August 03, 2013 9:54 AM
To: Bhushan Bharat-R65777
Cc: Wood Scott-B07421; ag...@suse.de; kvm-...@vger.kernel.org;
k...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 5/6 v2] kvm: powerpc: booke: Add linux pte
lookup like booke3s
On Sat, 2013-08-03 at 02:58 +, Bhushan Bharat-R65777 wrote:
One of the problem I saw was that if I put this code in
asm/pgtable-32.h and asm/pgtable-64.h then pte_persent() and other
friend function (on which this code depends) are defined in pgtable.h.
And pgtable.h includes asm/pgtable-32.h and asm/pgtable-64.h
before it defines pte_present() and friends functions.
Ok I move wove this in asm/pgtable*.h, initially I fought with
myself to take this code in pgtable* but finally end up doing here
(got biased by book3s :)).
Is there a reason why these routines can not be completely generic
in pgtable.h ?
How about the generic function:
diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h
b/arch/powerpc/include/asm/pgtable-ppc64.h
index d257d98..21daf28 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -221,6 +221,27 @@ static inline unsigned long pte_update(struct mm_struct
*mm,
return old;
}
+static inline unsigned long pte_read(pte_t *p) { #ifdef
+PTE_ATOMIC_UPDATES
+ pte_t pte;
+ pte_t tmp;
+ __asm__ __volatile__ (
+ 1: ldarx %0,0,%3\n
+ andi. %1,%0,%4\n
+ bne-1b\n
+ ori %1,%0,%4\n
+ stdcx. %1,0,%3\n
+ bne-1b
+ : =r (pte), =r (tmp), =m (*p)
+ : r (p), i (_PAGE_BUSY)
+ : cc);
+
+ return pte;
+#else
+ return pte_val(*p);
+#endif
+#endif
+}
static inline int __ptep_test_and_clear_young(struct mm_struct *mm,
unsigned long addr,
pte_t *ptep)
Please leave a blank line between functions.
{
diff --git a/arch/powerpc/include/asm/pgtable.h
b/arch/powerpc/include/asm/pgtable.h
index 690c8c2..dad712c 100644
--- a/arch/powerpc/include/asm/pgtable.h
+++ b/arch/powerpc/include/asm/pgtable.h
@@ -254,6 +254,45 @@ static inline pte_t
*find_linux_pte_or_hugepte(pgd_t *pgdir, unsigned long ea, } #endif
/* !CONFIG_HUGETLB_PAGE */
+static inline pte_t lookup_linux_pte(pgd_t *pgdir, unsigned long hva,
+int writing, unsigned long
+*pte_sizep)
The name implies that it just reads the PTE. Setting accessed/dirty shouldn't
be an undocumented side-effect.
Ok, will rename and document.
Why can't the caller do that (or a different
function that the caller calls afterward if desired)?
The current implementation in book3s is;
1) find a pte/hugepte
2) return null if pte not present
3) take _PAGE_BUSY lock
4) set accessed/dirty
5) clear _PAGE_BUSY.
What I tried was
1) find a pte/hugepte
2) return null if pte not present
3) return pte (not take lock by not setting _PAGE_BUSY)
4) then user calls __ptep_set_access_flags() to atomic update the
dirty/accessed flags in pte.
- but the benchmark results were not good
- Also can there be race as we do not take lock in step 3 and update in step 4 ?
Though even then you have the undocumented side effect of locking the PTE on
certain targets.
+{
+ pte_t *ptep;
+ pte_t pte;
+ unsigned long ps = *pte_sizep;
+ unsigned int shift;
+
+ ptep = find_linux_pte_or_hugepte(pgdir, hva, shift);
+ if (!ptep)
+ return __pte(0);
+ if (shift)
+ *pte_sizep = 1ul shift;
+ else
+ *pte_sizep = PAGE_SIZE;
+
+ if (ps *pte_sizep)
+ return __pte(0);
+
+ if (!pte_present(*ptep))
+ return __pte(0);
+
+#ifdef CONFIG_PPC64
+ /* Lock PTE (set _PAGE_BUSY) and read */
+ pte = pte_read(ptep);
+#else
+ pte = pte_val(*ptep);
+#endif
What about 32-bit platforms that need atomic PTEs?
I called __ptep_set_access_flags() for both 32/64bit (for 64bit I was not
calling pte_read()), which handles atomic updates. Somehow the benchmark result
were not good, will try again.
Thanks
-Bharat
-Scott
___
Linuxppc-dev mailing list
Re: [PATCH v2 6/8] powerpc: introduce early_get_first_memblock_info
On Mon, Aug 05, 2013 at 06:59:28PM -0500, Scott Wood wrote: On Sun, 2013-08-04 at 08:45 +0800, Kevin Hao wrote: memblock_add(base, size); snip } I think it'd be clearer for it to be an external variable that gets set by the relocation code -- plus, the above wouldn't work if this gets called twice due to having multiple memory regions. Got it. Thanks, Kevin -Scott pgpGkxlBJhcVW.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 7/8] powerpc/fsl_booke: make sure PAGE_OFFSET map to memstart_addr for relocatable kernel
On Mon, Aug 05, 2013 at 07:10:06PM -0500, Scott Wood wrote: On Sun, 2013-08-04 at 08:50 +0800, Kevin Hao wrote: On Fri, Jul 26, 2013 at 07:17:57PM -0500, Scott Wood wrote: diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm/fsl_booke_mmu.c index 8f60ef8..dd283fd 100644 --- a/arch/powerpc/mm/fsl_booke_mmu.c +++ b/arch/powerpc/mm/fsl_booke_mmu.c @@ -224,7 +224,7 @@ void __init adjust_total_lowmem(void) i = switch_to_as1(); __max_low_memory = map_mem_in_cams(ram, CONFIG_LOWMEM_CAM_NUM); -restore_to_as0(i); +restore_to_as0(i, 0, 0); The device tree virtual address is zero? No. But if the __pa(PAGE_OFFSET in AS0) is equal to __pa(PAGE_OFFSET in AS1), that mean we don't need to do another relocation and the device tree virtual address is useless in this case. The documentation of restore_to_as0() should make it clear that r5 is ignored if r4 is zero. OK, will add. Thanks, Kevin -Scott pgpkR9S0bUIcI.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 7/8] powerpc/fsl_booke: make sure PAGE_OFFSET map to memstart_addr for relocatable kernel
On Mon, Aug 05, 2013 at 07:14:00PM -0500, Scott Wood wrote: On Thu, 2013-07-04 at 20:54 +0800, Kevin Hao wrote: @@ -1222,6 +1266,9 @@ _GLOBAL(switch_to_as1) /* * Restore to the address space 0 and also invalidate the tlb entry created * by switch_to_as1. + * r3 - the tlb entry which should be invalidated + * r4 - __pa(PAGE_OFFSET in AS0) - pa(PAGE_OFFSET in AS1) + * r5 - device tree virtual address */ _GLOBAL(restore_to_as0) [snip] diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h index 3a65644..8280dbb 100644 --- a/arch/powerpc/mm/mmu_decl.h +++ b/arch/powerpc/mm/mmu_decl.h @@ -149,7 +149,7 @@ extern void MMU_init_hw(void); extern unsigned long mmu_mapin_ram(unsigned long top); extern void adjust_total_lowmem(void); extern int switch_to_as1(void); -extern void restore_to_as0(int); +extern void restore_to_as0(int, int, void *); int seems wrong for the second argument. Shouldn't it be phys_addr_t? This is the offset between __pa(PAGE_OFFSET in AS0) and __pa(PAGE_OFFSET in AS1). And the max offset should never exceed 768M. So a int type is safe here and using this type also avoid the ugly #ifdef CONFIG_PHYS_64BIT. Also, please use parameter names. Sure. Thanks, Kevin -Scott pgpwn9LUSY7M9.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Failure to detect PCI card
Hi Pete, On Mon, Aug 5, 2013 at 4:07 PM, Peter LaDow pet...@gocougs.wsu.edu wrote: However, replacing the 82540 based card with either a 3com 3C905TXM or the Netgear FA331, there is no response on the 0x10 IDSEL line. Thus it appears these cards are NOT responding to configuration reads. I think I have to break out the scope and probe around for the 5V/3V. I wouldn't think that the supplies are the issue since these are universal cards, and as I understand it either 3V3 _or_ 5V can be present, so these should work fine. Yet they aren't responding to PCI configuration cycles. It depends on what you define Universal PCI as :) My definition is that the board works with either 5V or 3.3V PCI signals. However, that definition does not tell you where the device draws power from. I suspect the lack of either the 5V or 3.3V power rail to the card might be the problem. Did you probe the PCI edge connect to see what supplies were present? A few more notes. I tried a variety of other cards, such as a PCI modem (WinMode, ack), a WinTV card, and a PCI based 802.11 card. All of them enumerate perfectly. These could all be 3.3V cards ... Perhaps it is a BIOS option ROM like you suggested earlier. The 3c90xC reference manual I found (http://people.freebsd.org/~wpaul/3Com/3c90xc.pdf) mentions an option ROM (and there is an Atmel part stuffed). I can't find any technical information on the FA331 (yet), so I don't know about it. But regardless, wouldn't enumeration have to occur before any option ROM could even be used? I've never had a card with an option ROM, so can't comment. I'd have to look at the PCI spec. If you want me to look, let me know. Cheers, Dave ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
