[PATCH] powerpc: Never handle VSX alignment exceptions from kernel
The VSX alignment handler needs to write out the existing VSX state to memory before operating on it (flush_vsx_to_thread()). If we take a VSX alignment exception in the kernel bad things will happen. It looks like we could write the kernel state out to the user process, or we could handle the kernel exception using data from the user process (depending if MSR_VSX is set or not). Worse still, if the code to read or write the VSX state causes an alignment exception, we will recurse forever. I ended up with hundreds of megabytes of kernel stack to look through as a result. Floating point and SPE code have similar issues but already include a user check. Add the same check to emulate_vsx(). Signed-off-by: Anton Blanchard --- Index: b/arch/powerpc/kernel/align.c === --- a/arch/powerpc/kernel/align.c +++ b/arch/powerpc/kernel/align.c @@ -651,6 +651,10 @@ static int emulate_vsx(unsigned char __u int sw = 0; int i, j; + /* userland only */ + if (unlikely(!user_mode(regs))) + return 0; + flush_vsx_to_thread(current); if (reg < 32) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
On Mon, Aug 19, 2013 at 10:54:33AM +0100, Mark Rutland wrote: > > I guess it's better to drop the 'imx6q-spdif' here? > > That depends: > > * If the two IP blocks are identical, only the "imx35-spdif" name is > necessary, and we can forget about "fsl,imx6q-spdif". > > * If "fsl,imx6q-spdif" is a strict superset of "fsl,imx35-spdif", having > both names documented and in a compatible list for a "fsl,imx6q-spdif" > device makes sense. Practically, I found it's very useful to have "fsl,-" in the device compatible property in .dtsi, even when device driver does not match it right now. For this example, I still prefer to have the following line for spdif device in imx6q.dtsi. compatible = "fsl,imx6q-spdif", "fsl,imx35-spdif"; The reason for that is we usually do not see all the differences of an IP block from one SoC to another when we firstly define the bindings for the device by looking at hardware reference manual. Some programming model differences are only identified when we're actually programming. That said, if some day we find there is difference between imx6q-spdif and imx35-spdif to be handled when we add something new to the driver, we only need to add "fsl,imx6q-spdif" as a new compatible into device driver and bindings document. The existing device tree would need no update to work with the new kernel driver. Shawn > > * If "fsl,imx6q-spdif" is a variation of "fsl,imx35-spdif", and the > "fsl,imx6q-spdif" cannot always be treated identically to a > "fsl,imx35-spdif", then it makes sense to have separate compatible > strings, with a device being listed as either "fsl,imx6q-spdif" or > "fsl,imx35-spdif". ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: BUG_ON and gcc don't mix
On Tue, Aug 20, 2013 at 02:02:11PM +0930, Alan Modra wrote: > On Tue, Aug 20, 2013 at 12:37:50PM +1000, Anton Blanchard wrote: > > address of the trap instruction for our bug exception table. Maybe > > we need a gcc builtin in which we can get a label on the trap > > instruction. Would that be possible? > > Not your actual _EMIT_BUG_ENTRY, but something like this ought to work. > The only trick here is not putting anything after __builtin_trap().. Doh! I guess the whole point was to get the condition folded into the trap, which is foiled by emitting an asm between the condition and buildin_trap(). -- Alan Modra Australia Development Lab, IBM ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: BUG_ON and gcc don't mix
On Tue, Aug 20, 2013 at 12:37:50PM +1000, Anton Blanchard wrote:
> address of the trap instruction for our bug exception table. Maybe
> we need a gcc builtin in which we can get a label on the trap
> instruction. Would that be possible?
Not your actual _EMIT_BUG_ENTRY, but something like this ought to work.
The only trick here is not putting anything after __builtin_trap()..
#define BUG_ON(x) do { \
if (x) {\
__asm__ __volatile__ ("\n1:"\
"\t.section __bug_table,\"a\"" \
"\n\t.long 1b" \
"\n\t.previous"); \
__builtin_trap(); \
} \
} while (0)
int foo(unsigned int *bar)
{
unsigned int holder_cpu;
holder_cpu = *bar & 0x;
BUG_ON(holder_cpu >= 32);
return 1;
}
--
Alan Modra
Australia Development Lab, IBM
--
Alan Modra
Australia Development Lab, IBM
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: BUG_ON and gcc don't mix
On Tue, 2013-08-20 at 12:37 +1000, Anton Blanchard wrote: >0: 00 00 23 a1 lhz r9,0(r3) >4: 01 00 60 38 li r3,1 >8: 20 00 a9 0c twlgei r9,32 >c: 20 00 80 4e blr > > Nice! I remember chasing this down before and the issue is we need the > address of the trap instruction for our bug exception table. Maybe > we need a gcc builtin in which we can get a label on the trap > instruction. Would that be possible? I suppose we can always just do a label before builtin_trap and have the BUG code search a few instructions :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v9 2/2] ASoC: fsl: Add S/PDIF machine driver
This patch implements a device-tree-only machine driver for Freescale
i.MX series Soc. It works with spdif_transmitter/spdif_receiver and
fsl_spdif.c drivers.
Signed-off-by: Nicolin Chen
---
.../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 cd088cc..a708380 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -193,6 +193,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 && 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
+#include
+#include
+
+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
[PATCH v9 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
This patch implements a device-tree-only CPU DAI driver for Freescale
S/PDIF controller that supports stereo playback and record feature.
Signed-off-by: Nicolin Chen
---
.../devicetree/bindings/sound/fsl,spdif.txt| 54 +
sound/soc/fsl/Kconfig |3 +
sound/soc/fsl/Makefile |2 +
sound/soc/fsl/fsl_spdif.c | 1236
sound/soc/fsl/fsl_spdif.h | 191 +++
5 files changed, 1486 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..f2ae335
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,spdif.txt
@@ -0,0 +1,54 @@
+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, must contain "fsl,imx35-spdif".
+
+ - reg : Offset and length of the register set for the device.
+
+ - interrupts : Contains the 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 : Contains an entry for each entry in clock-names.
+
+ - clock-names : Includes the following entries:
+ "core" The core clock of spdif controller
+ "rxtx<0-7>" Clock source list for tx and rx clock.
+ This clock list should be identical to
+ the source list connecting to the spdif
+ clock mux in "SPDIF Transceiver Clock
+ Diagram" of SoC reference manual. It
+ can also be referred to TxClk_Source
+ bit of register SPDIF_STC.
+
+Example:
+
+spdif: spdif@02004000 {
+ compatible = "fsl,imx35-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 3>,
+ <&clks 197>, <&clks 107>,
+ <&clks 0>, <&clks 118>,
+ <&clks 62>, <&clks 139>,
+ <&clks 0>;
+ clock-names = "core", "rxtx0",
+ "rxtx1", "rxtx2",
+ "rxtx3", "rxtx4",
+ "rxtx5", "rxtx6",
+ "rxtx7";
+
+ status = "okay";
+};
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 3a4808d..cd088cc 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..42a4382
--- /dev/null
+++ b/sound/soc/fsl/fsl_spdif.c
@@ -0,0 +1,1236 @@
+/*
+ * Freescale S/PDIF ALSA SoC Digital Audio Interface (DAI) driver
+ *
+ * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ *
+ * Based on stmp3xxx_spdif_dai.c
+ * Vladimir Barinov
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#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 INTR_FOR_CAPTURE (INT_SYM_ERR | INT_BIT_ERR | INT_URX_FUL |
INT_URX_OV|\
+ INT_QRX_FUL | INT_QRX_OV | INT_UQ_SYNC | INT_UQ_ERR |\
+ INT_RXFIFO_RESYNC | INT_LOSS_LOCK | INT_DPLL_LOCKED)
+
+/* Index list for the values that has if (DPLL Locked) condition */
[PATCH v9 0/2] Add freescale S/PDIF CPU DAI and machine drivers
Changelog: v8->v9: * Use bool instead of atomic_t. * Use clk_prepare_enable() instead. * Dropped dumpregs(). * Dropped unnecessary clk_round_rate(). * Dropped unused clock source enum. * Revised dev_err() message. v7->v8: * Revised DT binding doc. * Revised dev_err() error msg. * Check return value of clk_set_rate(). v6->v7: * Removed extra comma in array. * Revised some comments. * Added some dev_err(). * Check the return value of soft reset. * Use bitrev8() instead of extra reverse_bits(). * Use cache_bypass as default for regmap. v5->v6: * Sorted out rxtx clk source in DT binding. * Use devm_() functions. * Use platform_get_resource() instead. v4->v5: * Dropped rx/tx-clksrc-names DT bindings. * Use standard clock binding instead to pass the clock source list. * Update the compatible list by using "imx35", the first SoC that has spdif. v3->v4: * Use regmap for CPU DAI driver. * Use individual clock source for 32KHz, 44KHz, 48KHz playback. * Determine clock source configuration from 'clocks' entry. * Added imx53 to compatible list, merged imx6q and imx6dl in the list. * Improve the algorism of reverse_bits(). * Dropped the unneeded clk_put(). 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| 54 + .../devicetree/bindings/sound/imx-audio-spdif.txt | 29 + sound/soc/fsl/Kconfig | 14 + sound/soc/fsl/Makefile |4 + sound/soc/fsl/fsl_spdif.c | 1236 sound/soc/fsl/fsl_spdif.h | 191 +++ sound/soc/fsl/imx-spdif.c | 134 +++ 7 files changed, 1662 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
Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100.
Scott Wood wrote on 08/20/2013 10:44:31 AM: > From: Scott Wood > To: Stephen N Chivers > Cc: Chris Proctor , Kumar Gala > , , > > Date: 08/20/2013 10:44 AM > Subject: Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for > Motorola/Emerson MVME5100. > > On Mon, 2013-08-19 at 07:58 +1100, Stephen N Chivers wrote: > > The serial console setup in 'legacy_serial' does not support reg-shift > > or reg-offset properties and so a preferred_console is not added by it. > > The DTS file for the board does specify the register shift so that > > 'of_serial' will correctly setup the UARTS. But that is too late, the > > preferred console will be tty0 as the .config derived from > > ppc6xx_defconfig > > has CONF_VT_CONSOLE set. In the test kernels I have built 'con_init' in > > the VT support is always called before serial8250_console_init. > > Are you setting console=ttyS0, on the kernel command line? > Yes, most certainly. During the testing was specifying the command line in the dts as doing so in the .config would be wrong. When booting got: Linux/PowerPC Load: console=ttyS0,9600 ip=dhcp root=/dev/nfs So no problem there. > > I did try modifying legacy_serial to correctly support the tsi-bridge > > UARTS and add the preferred console but encountered even more problems > > in 8250_core when registering the serial console (to the point of > > having a silently panic'ing kernel). > > > > So I think for the moment, the board will need its own default config. > > Which config symbol is relevant here? > On reflection, maybe it wasn't panicing as in the configuration I was using the boot times were quite protracted, something to do with the network setup and e100 PHY initialisation. (Embedding the e100 firmware in the kernel appears to fix that). But at the point at which I gave up chasing the problem, the machine was not showing any sign of life within what would be regarded as "normal" times. As to config symbol I don't know. This may be the first attempt to combine PPC6xx configurations with their embedded brethren. What is certain that there is an incompatibility between what is required for the "quirks" of the MVME-5100 onboard UARTS and the configuration required for the non-embedded PPC6xx platforms. > -Scott > > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 2/2] Register bootmem pages
Previous commit 46723bfa540... introduced a new config option
HAVE_BOOTMEM_INFO_NODE that ended up breaking memory hot-remove for ppc
when sparse vmemmap is not defined.
This patch defines HAVE_BOOTMEM_INFO_NODE for ppc and adds the call to
register_page_bootmem_info_node. Without this we get a BUG_ON for memory
hot remove in put_page_bootmem().
This also adds a stub for register_page_bootmem_memmap to allow ppc to build
with sparse vmemmap defined.
Signed-off-by: Nathan Fontenot
---
---
arch/powerpc/mm/init_64.c |4
arch/powerpc/mm/mem.c |9 +
mm/Kconfig|2 +-
3 files changed, 14 insertions(+), 1 deletion(-)
Index: linux/arch/powerpc/mm/init_64.c
===
--- linux.orig/arch/powerpc/mm/init_64.c
+++ linux/arch/powerpc/mm/init_64.c
@@ -300,5 +300,9 @@ void vmemmap_free(unsigned long start, u
{
}
+void register_page_bootmem_memmap(unsigned long section_nr,
+ struct page *start_page, unsigned long size)
+{
+}
#endif /* CONFIG_SPARSEMEM_VMEMMAP */
Index: linux/arch/powerpc/mm/mem.c
===
--- linux.orig/arch/powerpc/mm/mem.c
+++ linux/arch/powerpc/mm/mem.c
@@ -297,12 +297,21 @@ void __init paging_init(void)
}
#endif /* ! CONFIG_NEED_MULTIPLE_NODES */
+static void __init register_page_bootmem_info(void)
+{
+ int i;
+
+ for_each_online_node(i)
+ register_page_bootmem_info_node(NODE_DATA(i));
+}
+
void __init mem_init(void)
{
#ifdef CONFIG_SWIOTLB
swiotlb_init(0);
#endif
+ register_page_bootmem_info();
high_memory = (void *) __va(max_low_pfn * PAGE_SIZE);
set_max_mapnr(max_pfn);
free_all_bootmem();
Index: linux/mm/Kconfig
===
--- linux.orig/mm/Kconfig
+++ linux/mm/Kconfig
@@ -183,7 +183,7 @@ config MEMORY_HOTPLUG_SPARSE
config MEMORY_HOTREMOVE
bool "Allow for memory hot remove"
select MEMORY_ISOLATION
- select HAVE_BOOTMEM_INFO_NODE if X86_64
+ select HAVE_BOOTMEM_INFO_NODE if (X86_64 || PPC64)
depends on MEMORY_HOTPLUG && ARCH_ENABLE_MEMORY_HOTREMOVE
depends on MIGRATION
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 1/2] Mark Memory Resources as busy
Memory I/O resources need to be marked as busy or else we cannot remove them when doing memory hot remove. Signed-off-by: Nathan Fontenot --- arch/powerpc/mm/mem.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux/arch/powerpc/mm/mem.c === --- linux.orig/arch/powerpc/mm/mem.c +++ linux/arch/powerpc/mm/mem.c @@ -514,7 +514,7 @@ static int add_system_ram_resources(void res->name = "System RAM"; res->start = base; res->end = base + size - 1; - res->flags = IORESOURCE_MEM; + res->flags = IORESOURCE_MEM | IORESOURCE_BUSY; WARN_ON(request_resource(&iomem_resource, res) < 0); } } ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] Correct Memory Hotplug for Power
Memory hotplug on Power is currently broken, these two patches correct the issues needed to get memory hotplug working again. This update marks memory resources that are added at boot time are also marked as busy. It sounds a bit counter intuitive but the core mm code will not free memory resources if they are not marked as busy. This also ensures that bootmem memory is is registered at boot time. A previous commit (46723bfa540...) that enabled memory hotplug remove with SPARSE_VMEMMAP enabled broke this on Power. Additional patches to follow to correct the current memory hotplug implementation on Power. Nathan Fontenot Updates for v2: - The WARN_ONCE is removed from the added register_page_bootmem_memmap() routine. I have been able to verify that memory hotplug works with SPARSE_VMEMMAP enabled and do not think the warning is needed. --- arch/powerpc/mm/mem.c |9 + linux/arch/powerpc/mm/init_64.c |4 linux/arch/powerpc/mm/mem.c |2 +- linux/mm/Kconfig|2 +- 4 files changed, 15 insertions(+), 2 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
On Mon, Aug 19, 2013 at 03:35:58PM -0600, Stephen Warren wrote: > > + "core" The core clock of spdif controller > > + "rxtx<0-7>" Clock source list for tx and rx clock. > > + This clock list should be identical to > > + the source list connecting to the spdif > > + clock mux in "SPDIF Transceiver Clock > > + Diagram" of SoC reference manual. It > > + can also be referred to TxClk_Source > > + bit of register SPDIF_STC. > > So, the HW block has 1 clock input, yet there's a mux somewhere else in > the SoC which has 8 inputs? > > If so, I'm not completely sure it's correct to reference anything other > than the "core" clock in this binding. I think the other clocks would be > more suitably represented in the system-level "sound card" binding that > I guess patch 2/2 (which I haven't read yet) adds, since I assume those > clock are more to do with system-level clock tree setup decisions, and > might not even exist in some other SoC that included this IP block. > > What do others think, assuming I'm correct about my HW design assumptions? The core clock is being only needed when accessing registers of this IP. Thus, in the driver, I let regmap handle it. While the other 8 clocks are actual reference clocks for Tx. Tx clock needs to select one of them that can easily derive a child clock matching the tx sample rate. This is essential for the IP, so I don't think it's nicer to put into machine driver. Thank you Nicolin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
BUG_ON and gcc don't mix
Hi,
I noticed our BUG_ON macros were taking a large number of instructions.
I've built a testcase to analyse it:
#if defined(ASMBUG)
#define BUG_ON(x) do { \
__asm__ __volatile__("tdnei %0,0\n" : : "r" ((long)(x))); \
} while (0)
#elif defined(BUILTIN)
#define BUG_ON(x) do { \
if (x) \
__builtin_trap(); \
} while (0)
#else
#define BUG_ON(x) do { \
if (x) { \
__asm__ __volatile__("twi 31,0,0\n"); \
__builtin_unreachable(); \
} \
} while (0)
#endif
int foo(unsigned int *bar)
{
unsigned int holder_cpu;
holder_cpu = *bar & 0x;
BUG_ON(holder_cpu >= 32);
return 1;
}
3 versions. First our current upstream behaviour (-DASMBUG):
0: 00 00 23 a1 lhz r9,0(r3)
4: 1f 00 89 2b cmplwi cr7,r9,31
8: 26 00 20 7d mfcrr9
c: fe f7 29 55 rlwinm r9,r9,30,31,31
10: 00 00 09 0b tdnei r9,0
14: 01 00 60 38 li r3,1
18: 20 00 80 4e blr
What a load of work. We do the compare, then pull it out of the
condition register and do some more work. We are trying to help gcc
but it seems to be backfiring. Let's try doing a simple version in c:
0: 00 00 23 a1 lhz r9,0(r3)
4: 1f 00 89 2b cmplwi cr7,r9,31
8: 0c 00 9d 41 bgt cr7,14
c: 01 00 60 38 li r3,1
10: 20 00 80 4e blr
14: 00 00 e0 0f twuir0,0
Better, we branch out of line to do the trap. But if we could do a
conditional trap properly then we should be able to do even better
(-DBUILTIN):
0: 00 00 23 a1 lhz r9,0(r3)
4: 01 00 60 38 li r3,1
8: 20 00 a9 0c twlgei r9,32
c: 20 00 80 4e blr
Nice! I remember chasing this down before and the issue is we need the
address of the trap instruction for our bug exception table. Maybe
we need a gcc builtin in which we can get a label on the trap
instruction. Would that be possible?
Anton
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
Thank you Sascha, I'll revise them all in v9
On Mon, Aug 19, 2013 at 02:34:49PM +0200, Sascha Hauer wrote:
> Hi Nicolas,
>
> Some misc other comments inline.
>
> On Mon, Aug 19, 2013 at 08:08:48PM +0800, Nicolin Chen wrote:
> > This patch implements a device-tree-only CPU DAI driver for Freescale
> > +
> > +struct fsl_spdif_priv {
> > + struct spdif_mixer_control fsl_spdif_control;
> > + struct snd_soc_dai_driver cpu_dai_drv;
> > + struct platform_device *pdev;
> > + struct regmap *regmap;
> > + atomic_t dpll_locked;
>
> You don't need an atomic_t to track a bool variable. Use a plain bool or
> int instead.
>
> > + u8 txclk_div[SPDIF_TXRATE_MAX];
> > + u8 txclk_src[SPDIF_TXRATE_MAX];
> > + u8 rxclk_src;
> > + struct clk *txclk[SPDIF_TXRATE_MAX];
> > + struct clk *rxclk;
> > + struct snd_dmaengine_dai_dma_data dma_params_tx;
> > + struct snd_dmaengine_dai_dma_data dma_params_rx;
> > +
> > + /* The name space will be allocated dynamically */
> > + char name[0];
> > +};
> > +
> > +
> > +#ifdef DEBUG
> > +static void dumpregs(struct fsl_spdif_priv *spdif_priv)
> > +{
> > + struct regmap *regmap = spdif_priv->regmap;
> > + struct platform_device *pdev = spdif_priv->pdev;
> > + u32 val, i;
> > + int ret;
> > +
> > + /* Valid address set of SPDIF is {[0x0-0x38], 0x44, 0x50} */
> > + for (i = 0 ; i <= REG_SPDIF_STC; i += 4) {
> > + ret = regmap_read(regmap, REG_SPDIF_SCR + i, &val);
> > + if (!ret)
> > + dev_dbg(&pdev->dev, "REG 0x%02x = 0x%06x\n", i, val);
> > + }
> > +}
> > +#else
> > +static void dumpregs(struct fsl_spdif_priv *spdif_priv) {}
> > +#endif
>
> Is this needed? regmap provides a register dump in debugfs.
>
> > +
> > +static int spdif_clk_set_rate(struct clk *clk, unsigned long rate)
> > +{
> > + unsigned long rate_actual;
> > +
> > + rate_actual = clk_round_rate(clk, rate);
> > + return clk_set_rate(clk, rate_actual);
> > +}
>
> clk_round_rate returns the rate which clk_set_rate would set if called
> with the same rate. The clk_round_rate() is unnecessary.
>
> > +
> > + dev_dbg(&pdev->dev, "expected clock rate = %d\n",
> > + (int)(64 * sample_rate * div));
> > + dev_dbg(&pdev->dev, "acutal clock rate = %d\n",
> > + (int)clk_get_rate(spdif_priv->txclk[rate]));
>
> s/acutal/actual/
>
> Also please use %ld instead of casting the unsigned long to int.
>
> > +
> > + dev_dbg(&pdev->dev, "FreqMeas: %d\n", (int)freqmeas);
> > + dev_dbg(&pdev->dev, "BusclkFreq: %d\n", (int)busclk_freq);
> > + dev_dbg(&pdev->dev, "RxRate: %d\n", (int)tmpval64);
>
> Get rid of the casts
>
> > +
> > + spdif_priv = devm_kzalloc(&pdev->dev,
> > + sizeof(struct fsl_spdif_priv) + strlen(np->name) + 1,
> > GFP_KERNEL);
> > + if (!spdif_priv) {
> > + dev_err(&pdev->dev, "could not allocate DAI object\n");
>
> Please drop this message. You'll never see it.
>
> > +
> > + for (i = 0; i < SPDIF_TXRATE_MAX; i++) {
> > + ret = fsl_spdif_probe_txclk(spdif_priv, i);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + /* Prepare rx/tx clock */
> > + clk_prepare(spdif_priv->rxclk);
> > + for (i = 0; i < SPDIF_TXRATE_MAX; i++)
> > + clk_prepare(spdif_priv->txclk[i]);
>
> Why do you prepare all clocks instead of the one you actually use? Also,
> no need to do this here. You can use clk_prepare_enable instead where
> you have clk_enable now.
>
> > +
> > +/* SPDIF rx clock source */
> > +enum spdif_rxclk_src {
> > + SRPC_CLKSRC_0 = 0,
> > + SRPC_CLKSRC_1,
> > + SRPC_CLKSRC_2,
> > + SRPC_CLKSRC_3,
> > + SRPC_CLKSRC_4,
> > + SRPC_CLKSRC_5,
> > + SRPC_CLKSRC_6,
> > + SRPC_CLKSRC_7,
> > + SRPC_CLKSRC_8,
> > + SRPC_CLKSRC_9,
> > + SRPC_CLKSRC_10,
> > + SRPC_CLKSRC_11,
> > + SRPC_CLKSRC_12,
> > + SRPC_CLKSRC_13,
> > + SRPC_CLKSRC_14,
> > + SRPC_CLKSRC_15,
> > +};
>
> These are unused and look unnecessary.
>
> > +
> > +/* SPDIF tx clksrc */
> > +enum spdif_txclk_src {
> > + STC_TXCLK_SRC_0 = 0,
> > + STC_TXCLK_SRC_1,
> > + STC_TXCLK_SRC_2,
> > + STC_TXCLK_SRC_3,
> > + STC_TXCLK_SRC_4,
> > + STC_TXCLK_SRC_5,
> > + STC_TXCLK_SRC_6,
> > + STC_TXCLK_SRC_7,
> > +};
>
> Also unused.
>
> Sascha
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100.
Scott Wood wrote on 08/09/2013 11:35:20 AM:
> From: Scott Wood
> To: Stephen N Chivers
> Cc: , , Chris Proctor
> ,
> Date: 08/09/2013 11:36 AM
> Subject: Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for
> Motorola/Emerson MVME5100.
>
> On Thu, 2013-08-08 at 11:03 +1100, Stephen N Chivers wrote:
> > Add support for the Motorola/Emerson MVME5100 Single Board Computer.
> >
> > The MVME5100 is a 6U form factor VME64 computer with:
> >
> > - A single MPC7410 or MPC750 CPU
> > - A HAWK Processor Host Bridge (CPU to PCI) and
> > MultiProcessor Interrupt Controller (MPIC)
> > - Up to 500Mb of onboard memory
> > - A M48T37 Real Time Clock (RTC) and Non-Volatile Memory chip
> > - Two 16550 compatible UARTS
> > - Two Intel E100 Fast Ethernets
> > - Two PCI Mezzanine Card (PMC) Slots
> > - PPCBug Firmware
> >
> > The HAWK PHB/MPIC is compatible with the MPC10x devices.
> >
> > There is no onboard disk support. This is usually provided by
installing a
> > PMC
> > in first PMC slot.
> >
> > This patch revives the board support, it was present in early 2.6
> > series kernels. The board support in those days was by Matt Porter of
> > MontaVista Software.
> >
> > CSC Australia has around 31 of these boards in service. The kernel in
use
> > for the boards is based on 2.6.31. The boards are operated without
disks
> > from a file server.
> >
> > This patch is based on linux-3.11-rc4 and has been boot tested.
> >
> > Signed-off-by: Stephen Chivers
> > ---
> > arch/powerpc/boot/dts/mvme5100.dts| 195 ++
> > arch/powerpc/boot/mvme5100.c | 28 +
> > arch/powerpc/configs/mvme5100_defconfig | 2597
> > +
> > arch/powerpc/platforms/embedded6xx/mvme5100.c | 288 +++
> > 4 files changed, 3108 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/dts/mvme5100.dts
> > b/arch/powerpc/boot/dts/mvme5100.dts
> > new file mode 100644
> > index 000..17fdbc7
> > --- /dev/null
> > +++ b/arch/powerpc/boot/dts/mvme5100.dts
> > @@ -0,0 +1,195 @@
> > +/*
> > + * Device Tree Souce for Motorola/Emerson MVME5100.
> > + *
> > + * Copyright 2013 CSC Australia Pty. Ltd.
> > + *
> > + * 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.
> > + */
> > +
> > +/dts-v1/;
> > +
> > +/ {
> > + model = "MVME5100";
> > + compatible = "MVME5100";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + aliases {
> > + serial0 = &serial0;
> > + pci0 = &pci0;
> > + };
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + PowerPC,7410 {
> > + device_type = "cpu";
> > + reg = <0x0>;
> > + /* Following required by dtc but not used */
> > + d-cache-line-size = <32>;
> > + i-cache-line-size = <32>;
> > + i-cache-size = <32768>;
> > + d-cache-size = <32768>;
> > + timebase-frequency = <2500>;
> > + clock-frequency = <5>;
> > +bus-frequency = <1>;
>
> What does "following" mean? certainly some of those are used, such as
> timebase-frequency. In any case, it's not the device tree's job to
> document which properties are used by Linux.
>
Agreed. Will remove.
The words were/are in the KuroboxHG.dts I modelled this dts on.
> > + };
> > + };
> > +
> > + memory {
> > + device_type = "memory";
> > + reg = <0x0 0x2000>;
> > + };
> > +
> > + hawk@fef8 {
>
> Unit address does not match reg.
>
Will make it hawk@fef8.
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + device_type = "soc";
>
> Is this really an SoC? In any case, this use of device_type is
> deprecated.
>
That was part of my early attempts to get legacy_serial to set up
the UARTS.
> > + compatible = "mpc10x";
>
> Don't use wildcards in compatible strings.
>
> simple-bus may be applicable here (in addition to a specific
> compatible).
>
The HAWK ASIC is a difficult beast. I still cannot get a positive
identification as to what it is (Motorola/Freescale part number
unknown, not even the part number on the chip on the board helps).
The best I can come up with is that it is a tsi108 without
the ethenets.
So device_type will be tsi-bridge and compatible will be
tsi108-bridge.
> > + store-gathering = <0>;
> > + ranges = <0x0 0xfef8 0x1>;
> > + reg = <0xfef8 0x1>;
>
> Where is "store-gathering" documented?
>
[PATCH] sata: fsl: save irqs while coalescing
Scott Wood indicated this should go to the SATA addresses as well as,
or maybe even instead of, the PPC list.
-- 8< --
Before this patch, I was seeing the following lockdep splat on my
MPC8315 (PPC32) target:
[9.086051] =
[9.090393] [ INFO: inconsistent lock state ]
[9.094744] 3.9.7-ajf-gc39503d #1 Not tainted
[9.099087] -
[9.103432] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
[9.109431] scsi_eh_1/39 [HC1[1]:SC0[0]:HE0:SE1] takes:
[9.114642] (&(&host->lock)->rlock){?.+...}, at: []
sata_fsl_interrupt+0x50/0x250
[9.123137] {HARDIRQ-ON-W} state was registered at:
[9.128004] [] lock_acquire+0x90/0xf4
[9.132737] [] _raw_spin_lock+0x34/0x4c
[9.137645] [] fsl_sata_set_irq_coalescing+0x68/0x100
[9.143750] [] sata_fsl_init_controller+0xa8/0xc0
[9.149505] [] sata_fsl_probe+0x17c/0x2e8
[9.154568] [] driver_probe_device+0x90/0x248
[9.159987] [] __driver_attach+0xc4/0xc8
[9.164964] [] bus_for_each_dev+0x5c/0xa8
[9.170028] [] bus_add_driver+0x100/0x26c
[9.175091] [] driver_register+0x88/0x198
[9.180155] [] do_one_initcall+0x58/0x1b4
[9.185226] [] kernel_init_freeable+0x118/0x1c0
[9.190823] [] kernel_init+0x18/0x108
[9.195542] [] ret_from_kernel_thread+0x64/0x6c
[9.201142] irq event stamp: 160
[9.204366] hardirqs last enabled at (159): []
_raw_spin_unlock_irq+0x30/0x50
[9.212469] hardirqs last disabled at (160): []
reenable_mmu+0x30/0x88
[9.219867] softirqs last enabled at (144): []
__do_softirq+0x168/0x218
[9.227435] softirqs last disabled at (137): []
irq_exit+0xa8/0xb4
[9.234481]
[9.234481] other info that might help us debug this:
[9.240995] Possible unsafe locking scenario:
[9.240995]
[9.246898]CPU0
[9.249337]
[9.251776] lock(&(&host->lock)->rlock);
[9.255878]
[9.258492] lock(&(&host->lock)->rlock);
[9.262765]
[9.262765] *** DEADLOCK ***
[9.262765]
[9.268684] no locks held by scsi_eh_1/39.
[9.272767]
[9.272767] stack backtrace:
[9.277117] Call Trace:
[9.279589] [cfff9da0] [c0008504] show_stack+0x48/0x150 (unreliable)
[9.285972] [cfff9de0] [c0447d5c] print_usage_bug.part.35+0x268/0x27c
[9.292425] [cfff9e10] [c006ace4] mark_lock+0x2ac/0x658
[9.297660] [cfff9e40] [c006b7e4] __lock_acquire+0x754/0x1840
[9.303414] [cfff9ee0] [c006cdb8] lock_acquire+0x90/0xf4
[9.308745] [cfff9f20] [c043ef04] _raw_spin_lock+0x34/0x4c
[9.314250] [cfff9f30] [c02f4168] sata_fsl_interrupt+0x50/0x250
[9.320187] [cfff9f70] [c0079ff0] handle_irq_event_percpu+0x90/0x254
[9.326547] [cfff9fc0] [c007a1fc] handle_irq_event+0x48/0x78
[9.332220] [cfff9fe0] [c007c95c] handle_level_irq+0x9c/0x104
[9.337981] [cfff9ff0] [c000d978] call_handle_irq+0x18/0x28
[9.343568] [cc7139f0] [c000608c] do_IRQ+0xf0/0x1a8
[9.348464] [cc713a20] [c000fc8c] ret_from_except+0x0/0x14
[9.353983] --- Exception: 501 at _raw_spin_unlock_irq+0x40/0x50
[9.353983] LR = _raw_spin_unlock_irq+0x30/0x50
[9.364839] [cc713af0] [c043db10] wait_for_common+0xac/0x188
[9.370513] [cc713b30] [c02ddee4] ata_exec_internal_sg+0x2b0/0x4f0
[9.376699] [cc713be0] [c02de18c] ata_exec_internal+0x68/0xa8
[9.382454] [cc713c20] [c02de4b8] ata_dev_read_id+0x158/0x594
[9.388205] [cc713ca0] [c02ec244] ata_eh_recover+0xd88/0x13d0
[9.393962] [cc713d20] [c02f2520] sata_pmp_error_handler+0xc0/0x8ac
[9.400234] [cc713dd0] [c02ecdc8] ata_scsi_port_error_handler+0x464/0x5e8
[9.407023] [cc713e10] [c02ecfd0] ata_scsi_error+0x84/0xb8
[9.412528] [cc713e40] [c02c4974] scsi_error_handler+0xd8/0x47c
[9.418457] [cc713eb0] [c004737c] kthread+0xa8/0xac
[9.423355] [cc713f40] [c000f6b8] ret_from_kernel_thread+0x64/0x6c
This fix was suggested by Bhushan Bharat , and
was discussed in email at:
http://linuxppc.10917.n7.nabble.com/MPC8315-reboot-failure-lockdep-splat-possibly-related-tp75162.html
Same patch successfully tested with 3.9.7. linux-next compiled but
not tested on hardware.
This patch is based off linux-next tag next-20130819
(which is commit 66a01bae29d11916c09f9f5a937cafe7d402e4a5 )
Signed-off-by: Anthony Foiani
---
drivers/ata/sata_fsl.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index 19720a0..851bd3f 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -293,6 +293,7 @@ static void fsl_sata_set_irq_coalescing(struct ata_host
*host,
{
struct sata_fsl_host_priv *host_priv = host->private_data;
void __iomem *hcr_base = host_priv->hcr_base;
+ unsigned long flags;
if (coun
Re: [PATCH 1/3 V4] mmc:core: parse voltage from device-tree
Hi, Anton and all
I had update this patchset.
Is there any change need?
If so let me know.
Thanks.
On 08/12/2013 09:39 AM, Haijun Zhang wrote:
Add function to support get voltage from device-tree.
If there are voltage-range specified in device-tree node, this function
will parse it and return the available voltage mask.
Signed-off-by: Haijun Zhang
---
changes for V4:
- Add new parameter mask to return voltages.
changes for V3:
- Correct the type of return value.
drivers/mmc/core/core.c | 44
include/linux/mmc/core.h | 2 ++
2 files changed, 46 insertions(+)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 49a5bca..b9b9fb6 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1196,6 +1197,49 @@ u32 mmc_vddrange_to_ocrmask(int vdd_min, int vdd_max)
}
EXPORT_SYMBOL(mmc_vddrange_to_ocrmask);
+#ifdef CONFIG_OF
+
+/**
+ * mmc_of_parse_voltage - return mask of supported voltages
+ * @np: The device node need to be parsed.
+ * @mask: mask of voltages available for MMC/SD/SDIO
+ *
+ * 1. Return zero on success.
+ * 2. Return negative errno: voltage-range is invalid.
+ */
+int mmc_of_parse_voltage(struct device_node *np, u32 *mask)
+{
+ const u32 *voltage_ranges;
+ int num_ranges, i;
+
+ voltage_ranges = of_get_property(np, "voltage-ranges", &num_ranges);
+ num_ranges = num_ranges / sizeof(*voltage_ranges) / 2;
+ if (!voltage_ranges || !num_ranges) {
+ pr_info("%s: voltage-ranges unspecified\n", np->full_name);
+ return -EINVAL;
+ }
+
+ for (i = 0; i < num_ranges; i++) {
+ const int j = i * 2;
+ u32 ocr_mask;
+
+ ocr_mask = mmc_vddrange_to_ocrmask(
+ be32_to_cpu(voltage_ranges[j]),
+ be32_to_cpu(voltage_ranges[j + 1]));
+ if (!ocr_mask) {
+ pr_err("%s: voltage-range #%d is invalid\n",
+ np->full_name, i);
+ return -EINVAL;
+ }
+ *mask |= ocr_mask;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(mmc_of_parse_voltage);
+
+#endif /* CONFIG_OF */
+
#ifdef CONFIG_REGULATOR
/**
diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h
index 443243b..da51bec 100644
--- a/include/linux/mmc/core.h
+++ b/include/linux/mmc/core.h
@@ -208,6 +208,8 @@ static inline void mmc_claim_host(struct mmc_host *host)
__mmc_claim_host(host, NULL);
}
+struct device_node;
extern u32 mmc_vddrange_to_ocrmask(int vdd_min, int vdd_max);
+extern int mmc_of_parse_voltage(struct device_node *np, u32 *mask);
#endif /* LINUX_MMC_CORE_H */
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Pull request: scottwood/linux.git next
On Mon, 2013-08-19 at 19:49 -0400, Josh Boyer wrote: > > I think mfspr works everywhere we care about but I might be mistaken :-) > > I don't think anybody have tried booting a 403 in a long time. I > > would be surprised if it still worked. > > I think I have one buried somewhere in my garage. I'm not digging it out. Don't :-) I'm thinking of removing the code... been wanting to do that for a while, I'd be surprised if it still worked anyway. How much RAM do these things have ? Probably not enough for a recent kernel... Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100.
On Mon, 2013-08-19 at 07:58 +1100, Stephen N Chivers wrote: > The serial console setup in 'legacy_serial' does not support reg-shift > or reg-offset properties and so a preferred_console is not added by it. > The DTS file for the board does specify the register shift so that > 'of_serial' will correctly setup the UARTS. But that is too late, the > preferred console will be tty0 as the .config derived from > ppc6xx_defconfig > has CONF_VT_CONSOLE set. In the test kernels I have built 'con_init' in > the VT support is always called before serial8250_console_init. Are you setting console=ttyS0, on the kernel command line? > I did try modifying legacy_serial to correctly support the tsi-bridge > UARTS and add the preferred console but encountered even more problems > in 8250_core when registering the serial console (to the point of > having a silently panic'ing kernel). > > So I think for the moment, the board will need its own default config. Which config symbol is relevant here? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/85xx: add hardware automatically enter altivec idle state
On Sun, 2013-08-18 at 21:53 -0500, Wang Dongsheng-B40534 wrote: > Thanks for your feedback. > > > -Original Message- > > From: Wood Scott-B07421 > > Sent: Saturday, August 17, 2013 12:51 AM > > To: Kumar Gala > > Cc: Wang Dongsheng-B40534; linuxppc-dev@lists.ozlabs.org > > Subject: Re: [PATCH 1/2] powerpc/85xx: add hardware automatically enter > > altivec idle state > > > > On Fri, 2013-08-16 at 06:02 -0500, Kumar Gala wrote: > > > On Aug 16, 2013, at 2:23 AM, Dongsheng Wang wrote: > > > > > > > From: Wang Dongsheng > > > > > > > > Each core's AltiVec unit may be placed into a power savings mode > > > > by turning off power to the unit. Core hardware will automatically > > > > power down the AltiVec unit after no AltiVec instructions have > > > > executed in N cycles. The AltiVec power-control is triggered by > > hardware. > > > > > > > > Signed-off-by: Wang Dongsheng > > > > > > Why treat this as a idle HW governor vs just some one time setup at > > boot of the time delay? > > > > It is being done as one-time setup, despite the function name. > > > > Maybe it should be moved into __setup/restore_cpu_e6500 (BTW, we really > > should refactor those to reduce duplication) with the timebase bit > > number hardcoded rather than a time in us. > > > The frequency of the different platforms timebase is not the same. It's close enough. Remember, this number is a vague initial guess, not something that's been carefully calibrated. Though, it would make it harder to substitute the number with one that's been more carefully calibrated... but wouldn't different chips possibly have different optimal delays anyway? > If we use it, we need to set different timebase bit on each platform. > That is why I did not put the code in __setup/restore_cpu_e6500, I need > use tb_ticks_per_usec to get timebase bit. So we only need to set a time > for each platform, and not set different timebase bit. It just seems wrong to have an ad-hoc mechanism for running core-specific code when we have cputable... If we really need this, maybe we should add a "cpu_setup_late" function pointer. With your patch, when does the power management register get set when hot plugging a cpu? > > As for the PVR check, the upstream kernel doesn't need to care about > > rev1, so knowing it's an e6500 is good enough. > > > But AltiVec idle & PW20 cannot work on rev1 platform. > We didn't have to deal with it? Upstream does not run on rev1. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] sata: fsl: save irqs while coalescing
On Mon, 2013-08-19 at 12:15 -0600, Anthony Foiani wrote:
> diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
> index 19720a0..851bd3f 100644
> --- a/drivers/ata/sata_fsl.c
> +++ b/drivers/ata/sata_fsl.c
> @@ -293,6 +293,7 @@ static void fsl_sata_set_irq_coalescing(struct ata_host
> *host,
> {
> struct sata_fsl_host_priv *host_priv = host->private_data;
> void __iomem *hcr_base = host_priv->hcr_base;
> + unsigned long flags;
>
> if (count > ICC_MAX_INT_COUNT_THRESHOLD)
> count = ICC_MAX_INT_COUNT_THRESHOLD;
> @@ -305,12 +306,12 @@ static void fsl_sata_set_irq_coalescing(struct ata_host
> *host,
> (count > ICC_MIN_INT_COUNT_THRESHOLD))
> ticks = ICC_SAFE_INT_TICKS;
>
> - spin_lock(&host->lock);
> + spin_lock_irqsave(&host->lock, flags);
> iowrite32((count << 24 | ticks), hcr_base + ICC);
>
> intr_coalescing_count = count;
> intr_coalescing_ticks = ticks;
> - spin_unlock(&host->lock);
> + spin_unlock_irqrestore(&host->lock, flags);
This should go to the SATA list and maintainer.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8 2/2] ASoC: fsl: Add S/PDIF machine driver
On Mon, Aug 19, 2013 at 03:39:26PM -0600, Stephen Warren wrote: > On 08/19/2013 06:08 AM, Nicolin Chen wrote: > > This patch implements a device-tree-only machine driver for Freescale > > i.MX series Soc. It works with spdif_transmitter/spdif_receiver and > > fsl_spdif.c drivers. > > > diff --git a/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt > > b/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt > > +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. > Those object truly don't exist in HW and only exist due to internal > details of Linux's ASoC subsystem. They will physically exist if they're usefully present on the board (in the sense that they're there and can be pointed at) - there will be either a TOSLINK optical connector or (less commonly) an electrical connector breaking the signal out to go elsewhere though they don't have any interaction with software usually which is more what you mean here. > Or, to map the properties more directly to HW, perhaps name the property > "spdif-tx-jack-exists", or even "spdif-tx-jack" and make it a phandle to > a node that represents the actual S/PDIF connector? S/PDIF is also sometimes used as an interconnect between devices - some CODECs have S/PDIF I/O (more normally used as an external connector on the box). This is most frequently seen as a way to plumb HDMI in since some HDMI devices seem to provide this as a legacy interconnect, though it can get used just for regular CODECs as well. Using this machine driver would probably be a bit of an abuse for some applications, though with things like the HDMI one the goal of the hardware is to be dropped into a driver like this so perhaps it makes sense and is useful anyway. Equally well it'd be good to get this stuff actually merged, it seems to have been surprisingly time consuming thus far... signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
Quoting Mark Rutland (2013-08-19 02:35:43) > On Sat, Aug 17, 2013 at 04:17:18PM +0100, Tomasz Figa wrote: > > On Saturday 17 of August 2013 16:53:16 Sascha Hauer wrote: > > > On Sat, Aug 17, 2013 at 02:28:04PM +0200, Tomasz Figa wrote: > > > > > > > Also I would make this option required. Use a dummy clock for > > > > > > > mux > > > > > > > inputs that are grounded for a specific SoC. > > > > > > > > > > > > Some clocks are not from CCM and we haven't defined in > > > > > > imx6q-clk.txt, > > > > > > so in most cases we can't provide a phandle for them, eg: > > > > > > spdif_ext. > > > > > > I think it's a bit hard to force it to be 'required'. An > > > > > > 'optional' > > > > > > looks more flexible to me and a default one is ensured even if > > > > > > it's > > > > > > missing. > > > > > > > > > > <&clks 0> is the dummy clock. This can be used for all input clocks > > > > > not > > > > > defined by the SoC. > > > > > > > > Where does this assumption come from? Is it documented anywhere? > > > > > > This is how all i.MX clock bindings currently are. See > > > Documentation/devicetree/bindings/clock/imx*-clock.txt > > > > OK, thanks. > > > > I guess we need some discussion on dummy clocks vs skipped clocks. I think > > we want some consistency on this, don't we? > > > > If we really need a dummy clock, then we might also want a generic way to > > specify it. > > What do we actually mean by a "dummy clock"? We already have bindings > for "fixed-clock" and co friends describe relatively simple > preconfigured clocks. Some platforms have a fake clock which defines noops callbacks and basically doesn't do anything. This is analogous to the dummy regulator implementation. A central one could be registered by the clock core, as is done by the regulator core. I'll add this to the todo list. Regards, Mike > > If a clock isn't actually wired, we shouldn't describe it at all, or > we're describing what Linux wants to think rather than what the hardware > actually is. That can easily be handled with clock-names. > > Thanks, > Mark. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Pull request: scottwood/linux.git next
On Mon, Aug 19, 2013 at 7:47 PM, Benjamin Herrenschmidt wrote: > On Mon, 2013-08-19 at 17:56 -0500, Scott Wood wrote: >> If we use the generic CPU target then mftb won't get turned into mfspr >> (I assume this is what you meant by "tricky asm"). Does mfspr work >> everywhere, including from userspace? Or do we need to patch? What >> about 403GCX which seems to need some special SPR (I could leave the >> existing ifdef alone, but what about vdso)? > > I think mfspr works everywhere we care about but I might be mistaken :-) > I don't think anybody have tried booting a 403 in a long time. I > would be surprised if it still worked. I think I have one buried somewhere in my garage. I'm not digging it out. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Pull request: scottwood/linux.git next
On Mon, 2013-08-19 at 17:56 -0500, Scott Wood wrote: > If we use the generic CPU target then mftb won't get turned into mfspr > (I assume this is what you meant by "tricky asm"). Does mfspr work > everywhere, including from userspace? Or do we need to patch? What > about 403GCX which seems to need some special SPR (I could leave the > existing ifdef alone, but what about vdso)? I think mfspr works everywhere we care about but I might be mistaken :-) I don't think anybody have tried booting a 403 in a long time. I would be surprised if it still worked. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Pull request: scottwood/linux.git next
On Thu, 2013-08-15 at 07:01 +1000, Benjamin Herrenschmidt wrote: > On Wed, 2013-08-14 at 12:02 -0500, Scott Wood wrote: > > On Wed, 2013-08-14 at 14:18 +1000, Benjamin Herrenschmidt wrote: > > > On Thu, 2013-08-08 at 17:45 -0500, Scott Wood wrote: > > > > powerpc/e500: Update compilation flags with core specific > > > > options > > > > > > This breaks the build for my FSL test configs. For some reason gcc 4.7.3 > > > doesn't know about -mcpu=e5500 > > > > Ugh. I guess that's what I get for using toolchains provided internally > > rather than building them myself > > :-) > > I recommend you use one of tony's on kernel.org, that way you have > something that matches what other people use :-) It looks like -mcpu=e500mc64 has been supported for a while. > > > Additionally, on 64-bit, that means one can no longer make a kernel that > > > does both A2 and e5500... > > > > Other than the toolchain issue, I'm not sure how this is worse than it > > was before, when such a kernel would have had -Wa,-me500 forced. > > Probably similarly bad though it did work ... but if you are touching > it, may as well do it right... There are worms inside that can... > > What -mcpu value should be used in such a combined kernel? > > Good question. We lack a generic booke option. What about powerpc64 ? > > A default like that is fine as long as tricky asm uses the macros for > that and the *optional* -mcpu= option is available (and you can put > it in defconfig). > > It might be worth asking gcc to add something like -march= > or something like that though. If we use the generic CPU target then mftb won't get turned into mfspr (I assume this is what you meant by "tricky asm"). Does mfspr work everywhere, including from userspace? Or do we need to patch? What about 403GCX which seems to need some special SPR (I could leave the existing ifdef alone, but what about vdso)? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] i2c: move of helpers into the core
On 08/19/2013 05:04 PM, Rafael J. Wysocki wrote: > On Monday, August 19, 2013 03:19:18 PM Wolfram Sang wrote: >> I2C of helpers used to live in of_i2c.c but experience (from SPI) shows >> that it is much cleaner to have this in the core. This also removes a >> circular dependency between the helpers and the core, and so we can >> finally register child nodes in the core instead of doing this manually >> in each driver. So, fix the drivers and documentation, too. > > Perhaps we should do the analogous for ACPI then? > > Rafael Aargh. Why quote the entire patch just to say one line? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] i2c: move of helpers into the core
On Monday, August 19, 2013 03:19:18 PM Wolfram Sang wrote: > I2C of helpers used to live in of_i2c.c but experience (from SPI) shows > that it is much cleaner to have this in the core. This also removes a > circular dependency between the helpers and the core, and so we can > finally register child nodes in the core instead of doing this manually > in each driver. So, fix the drivers and documentation, too. Perhaps we should do the analogous for ACPI then? Rafael > Signed-off-by: Wolfram Sang > --- > Documentation/acpi/enumeration.txt |1 - > drivers/i2c/busses/i2c-at91.c |3 - > drivers/i2c/busses/i2c-cpm.c|6 -- > drivers/i2c/busses/i2c-davinci.c|2 - > drivers/i2c/busses/i2c-designware-platdrv.c |2 - > drivers/i2c/busses/i2c-gpio.c |3 - > drivers/i2c/busses/i2c-i801.c |2 - > drivers/i2c/busses/i2c-ibm_iic.c|4 - > drivers/i2c/busses/i2c-imx.c|3 - > drivers/i2c/busses/i2c-mpc.c|2 - > drivers/i2c/busses/i2c-mv64xxx.c|3 - > drivers/i2c/busses/i2c-mxs.c|3 - > drivers/i2c/busses/i2c-nomadik.c|3 - > drivers/i2c/busses/i2c-ocores.c |3 - > drivers/i2c/busses/i2c-octeon.c |3 - > drivers/i2c/busses/i2c-omap.c |3 - > drivers/i2c/busses/i2c-pnx.c|3 - > drivers/i2c/busses/i2c-powermac.c |9 +- > drivers/i2c/busses/i2c-pxa.c|2 - > drivers/i2c/busses/i2c-s3c2410.c|2 - > drivers/i2c/busses/i2c-sh_mobile.c |2 - > drivers/i2c/busses/i2c-sirf.c |3 - > drivers/i2c/busses/i2c-stu300.c |2 - > drivers/i2c/busses/i2c-tegra.c |3 - > drivers/i2c/busses/i2c-versatile.c |2 - > drivers/i2c/busses/i2c-wmt.c|3 - > drivers/i2c/busses/i2c-xiic.c |3 - > drivers/i2c/i2c-core.c | 107 - > drivers/i2c/i2c-mux.c |3 - > drivers/i2c/muxes/i2c-arb-gpio-challenge.c |1 - > drivers/i2c/muxes/i2c-mux-gpio.c|1 - > drivers/i2c/muxes/i2c-mux-pinctrl.c |1 - > drivers/media/platform/exynos4-is/fimc-is-i2c.c |3 - > drivers/of/Kconfig |6 -- > drivers/of/Makefile |1 - > drivers/of/of_i2c.c | 114 > --- > include/linux/i2c.h | 20 > include/linux/of_i2c.h | 46 - > 38 files changed, 130 insertions(+), 253 deletions(-) > delete mode 100644 drivers/of/of_i2c.c > delete mode 100644 include/linux/of_i2c.h > > diff --git a/Documentation/acpi/enumeration.txt > b/Documentation/acpi/enumeration.txt > index d9be7a9..958266e 100644 > --- a/Documentation/acpi/enumeration.txt > +++ b/Documentation/acpi/enumeration.txt > @@ -238,7 +238,6 @@ An I2C bus (controller) driver does: > if (ret) > /* handle error */ > > - of_i2c_register_devices(adapter); > /* Enumerate the slave devices behind this bus via ACPI */ > acpi_i2c_register_devices(adapter); > > diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c > index 6bb839b..fd05930 100644 > --- a/drivers/i2c/busses/i2c-at91.c > +++ b/drivers/i2c/busses/i2c-at91.c > @@ -28,7 +28,6 @@ > #include > #include > #include > -#include > #include > #include > #include > @@ -775,8 +774,6 @@ static int at91_twi_probe(struct platform_device *pdev) > return rc; > } > > - of_i2c_register_devices(&dev->adapter); > - > dev_info(dev->dev, "AT91 i2c bus driver.\n"); > return 0; > } > diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c > index 2e1f7eb..b2b8aa9 100644 > --- a/drivers/i2c/busses/i2c-cpm.c > +++ b/drivers/i2c/busses/i2c-cpm.c > @@ -42,7 +42,6 @@ > #include > #include > #include > -#include > #include > #include > > @@ -681,11 +680,6 @@ static int cpm_i2c_probe(struct platform_device *ofdev) > dev_dbg(&ofdev->dev, "hw routines for %s registered.\n", > cpm->adap.name); > > - /* > - * register OF I2C devices > - */ > - of_i2c_register_devices(&cpm->adap); > - > return 0; > out_shut: > cpm_i2c_shutdown(cpm); > diff --git a/drivers/i2c/busses/i2c-davinci.c > b/drivers/i2c/busses/i2c-davinci.c > index fa55605..62be3b3 100644 > --- a/drivers/i2c/busses/i2c-davinci.c > +++ b/drivers/i2c/busses/i2c-davinci.c > @@ -38,7 +38,6 @@ > #include > #include > #include > -#include > #include > > #include > @@ -728,7 +727,6 @@ static int davinci_i2c_
Re: [PATCH RESEND] i2c: move of helpers into the core
On Mon, Aug 19, 2013 at 07:59:40PM +0200, Wolfram Sang wrote:
[...]
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
[...]
> +#if IS_ENABLED(CONFIG_OF)
> +static void of_i2c_register_devices(struct i2c_adapter *adap)
> +{
[...]
> +}
[...]
> +#endif /* CONFIG_OF */
Isn't this missing the dummy implementation for !OF.
> static int i2c_do_add_adapter(struct i2c_driver *driver,
> struct i2c_adapter *adap)
> {
> @@ -1058,6 +1160,8 @@ static int i2c_register_adapter(struct i2c_adapter
> *adap)
>
> exit_recovery:
> /* create pre-declared device nodes */
> + of_i2c_register_devices(adap);
Alternatively you could remove the of_i2c_register_devices() from the
"#ifdef CONFIG_OF" block so that it will always be compiled. You could
turn the above into
if (IS_ENABLED(CONFIG_OF))
of_i2c_register_devices(adap);
and let the compiler throw the static function away if it sees that the
condition is always false.
Thierry
pgpoeSdfeBJmZ.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Critical Interrupt Input
Support does appear to be present but there is a problem returning back to
user space I suspect.
What fails is it causes Linux user space programs to get Segmentation
errors.
Issuing a simple ls causes a segmentation fault sometimes. The shell gets
terminated
and you cannot log back in. INIT: Id "T0" respawning too fast: disabled
for 5 minutes pops up.
However, the critical interrupt handler keeps running. I know this by
adding the reading
of a physical I/O location in the handler and can see it is being read on
the scope.
The only code in the handler is below.
void critintr_handler(void *dev)
{
critintrcount++; // increment a variable
iodata = *piom; // read an I/O location
mtdcr(0x0c0, 0x2000); // clear critical interrupt
}
Below is a log of the type of crashes that occur:
root@10.34.9.213:/opt/ppmac/ktest# ls
Segmentation fault
root@10.34.9.213:/opt/ppmac/ktest# ls
Segmentation fault
root@10.34.9.213:/opt/ppmac/ktest# ls
Makefilektest.cktest.ko ktest.mod.o modules.order
Module.symvers ktest.cbp ktest.mod.c ktest.o
root@10.34.9.213:/opt/ppmac/ktest# ls
Debian GNU/Linux 7 powerpmac ttyS0
powerpmac login: root
Debian GNU/Linux 7 powerpmac ttyS0
powerpmac login: root
Debian GNU/Linux 7 powerpmac ttyS0
powerpmac login: root
Debian GNU/Linux 7 powerpmac ttyS0
powerpmac login: root
Password:
Last login: Thu Nov 30 20:42:16 UTC 1933 on ttyS0
Linux powerpmac 3.2.21-aspen_2.01.09 #10 Mon Aug 19 08:49:12 PDT 2013 ppc
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
INIT: Id "T0" respawning too fast: disabled for 5 minutes
From: "Benjamin Herrenschmidt"
Sent: Saturday, August 17, 2013 3:05 PM
To: "Kumar Gala"
Cc: linuxppc-dev@lists.ozlabs.org, hbaus...@deltatau.com
Subject: Re: Critical Interrupt Input
On Fri, 2013-08-16 at 06:04 -0500, Kumar Gala wrote:
> The 44x low level code needs to handle exception stacks properly for
> this to work. Since its possible to have a critical exception occur
> while in a normal exception level, you have to have proper saving of
> additional register state and a stack frame for the critical
> exception, etc. I'm not sure if that was ever done for 44x.
Don't 44x and FSL BookE share the same macros ? I would think 44x does
indeed implement the same crit support as e500...
What does the crash look like ?
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Outbound scan for Spam or Virus by Barracuda at Delta Tau
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RESEND] i2c: move of helpers into the core
On 08/19/2013 07:59 PM, Wolfram Sang wrote:
> I2C of helpers used to live in of_i2c.c but experience (from SPI) shows
> that it is much cleaner to have this in the core. This also removes a
> circular dependency between the helpers and the core, and so we can
> finally register child nodes in the core instead of doing this manually
> in each driver. So, fix the drivers and documentation, too.
>
> Signed-off-by: Wolfram Sang
> ---
>
> Sigh, hitting the CC threshold on vger again. So resending to the lists only.
> BTW this patch is based on -rc4 and was tested on an AT91 board. More tests
> very welcome. Thanks!
>
>
> drivers/i2c/busses/i2c-s3c2410.c|2 -
> drivers/media/platform/exynos4-is/fimc-is-i2c.c |3 -
For these:
Acked-by: Sylwester Nawrocki
However this patch fails to apply onto either v3.11-rc4 or v3.11-rc6:
Applying: i2c: move of helpers into the core
fatal: sha1 information is lacking or useless
(drivers/i2c/busses/i2c-powermac.c).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 i2c: move of helpers into the core
One nitpick below..
[...]
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index f32ca29..321b7ca 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -23,7 +23,11 @@
> SMBus 2.0 support by Mark Studebaker and
> Jean Delvare
> Mux support by Rodolfo Giometti and
> - Michael Lawnick */
> + Michael Lawnick
> + OF support is copyright (c) 2008 Jochen Friedrich
> + (based on a previous patch from Jon Smirl ) and
> + (c) 2013 Wolfram Sang
> + */
>
> #include
> #include
> @@ -35,7 +39,9 @@
> #include
> #include
> #include
> +#include
> #include
> +#include
> #include
> #include
> #include
> @@ -954,6 +960,102 @@ static void i2c_scan_static_board_info(struct
> i2c_adapter *adapter)
> up_read(&__i2c_board_lock);
> }
>
> +/* of support code */
/* OF support code */
or
/*
* Device Tree support code.
*/
?
> +#if IS_ENABLED(CONFIG_OF)
> +static void of_i2c_register_devices(struct i2c_adapter *adap)
> +{
> + void *result;
> + struct device_node *node;
> +
> + /* Only register child devices if the adapter has a node pointer set */
> + if (!adap->dev.of_node)
> + return;
> +
> + dev_dbg(&adap->dev, "of_i2c: walking child nodes\n");
> +
> + for_each_available_child_of_node(adap->dev.of_node, node) {
> + struct i2c_board_info info = {};
> + struct dev_archdata dev_ad = {};
> + const __be32 *addr;
> + int len;
> +
> + dev_dbg(&adap->dev, "of_i2c: register %s\n", node->full_name);
> +
> + if (of_modalias_node(node, info.type, sizeof(info.type)) < 0) {
> + dev_err(&adap->dev, "of_i2c: modalias failure on %s\n",
> + node->full_name);
> + continue;
> + }
> +
> + addr = of_get_property(node, "reg", &len);
> + if (!addr || (len < sizeof(int))) {
> + dev_err(&adap->dev, "of_i2c: invalid reg on %s\n",
> + node->full_name);
> + continue;
> + }
> +
> + info.addr = be32_to_cpup(addr);
> + if (info.addr > (1 << 10) - 1) {
> + dev_err(&adap->dev, "of_i2c: invalid addr=%x on %s\n",
> + info.addr, node->full_name);
> + continue;
> + }
> +
> + info.irq = irq_of_parse_and_map(node, 0);
> + info.of_node = of_node_get(node);
> + info.archdata = &dev_ad;
> +
> + if (of_get_property(node, "wakeup-source", NULL))
> + info.flags |= I2C_CLIENT_WAKE;
> +
> + request_module("%s%s", I2C_MODULE_PREFIX, info.type);
> +
> + result = i2c_new_device(adap, &info);
> + if (result == NULL) {
> + dev_err(&adap->dev, "of_i2c: Failure registering %s\n",
> + node->full_name);
> + of_node_put(node);
> + irq_dispose_mapping(info.irq);
> + continue;
> + }
> + }
> +}
> +
> +static int of_dev_node_match(struct device *dev, void *data)
> +{
> + return dev->of_node == data;
> +}
> +
> +/* must call put_device() when done with returned i2c_client device */
> +struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
> +{
> + struct device *dev;
> +
> + dev = bus_find_device(&i2c_bus_type, NULL, node,
> + of_dev_node_match);
> + if (!dev)
> + return NULL;
> +
> + return i2c_verify_client(dev);
> +}
> +EXPORT_SYMBOL(of_find_i2c_adapter_by_node);
> +
> +/* must call put_device() when done with returned i2c_adapter device */
> +struct i2c_adapter *of_
[PATCH] sata: fsl: save irqs while coalescing
Before this patch, I was seeing the following lockdep splat on my
MPC8315 (PPC32) target:
[9.086051] =
[9.090393] [ INFO: inconsistent lock state ]
[9.094744] 3.9.7-ajf-gc39503d #1 Not tainted
[9.099087] -
[9.103432] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
[9.109431] scsi_eh_1/39 [HC1[1]:SC0[0]:HE0:SE1] takes:
[9.114642] (&(&host->lock)->rlock){?.+...}, at: []
sata_fsl_interrupt+0x50/0x250
[9.123137] {HARDIRQ-ON-W} state was registered at:
[9.128004] [] lock_acquire+0x90/0xf4
[9.132737] [] _raw_spin_lock+0x34/0x4c
[9.137645] [] fsl_sata_set_irq_coalescing+0x68/0x100
[9.143750] [] sata_fsl_init_controller+0xa8/0xc0
[9.149505] [] sata_fsl_probe+0x17c/0x2e8
[9.154568] [] driver_probe_device+0x90/0x248
[9.159987] [] __driver_attach+0xc4/0xc8
[9.164964] [] bus_for_each_dev+0x5c/0xa8
[9.170028] [] bus_add_driver+0x100/0x26c
[9.175091] [] driver_register+0x88/0x198
[9.180155] [] do_one_initcall+0x58/0x1b4
[9.185226] [] kernel_init_freeable+0x118/0x1c0
[9.190823] [] kernel_init+0x18/0x108
[9.195542] [] ret_from_kernel_thread+0x64/0x6c
[9.201142] irq event stamp: 160
[9.204366] hardirqs last enabled at (159): []
_raw_spin_unlock_irq+0x30/0x50
[9.212469] hardirqs last disabled at (160): []
reenable_mmu+0x30/0x88
[9.219867] softirqs last enabled at (144): []
__do_softirq+0x168/0x218
[9.227435] softirqs last disabled at (137): []
irq_exit+0xa8/0xb4
[9.234481]
[9.234481] other info that might help us debug this:
[9.240995] Possible unsafe locking scenario:
[9.240995]
[9.246898]CPU0
[9.249337]
[9.251776] lock(&(&host->lock)->rlock);
[9.255878]
[9.258492] lock(&(&host->lock)->rlock);
[9.262765]
[9.262765] *** DEADLOCK ***
[9.262765]
[9.268684] no locks held by scsi_eh_1/39.
[9.272767]
[9.272767] stack backtrace:
[9.277117] Call Trace:
[9.279589] [cfff9da0] [c0008504] show_stack+0x48/0x150 (unreliable)
[9.285972] [cfff9de0] [c0447d5c] print_usage_bug.part.35+0x268/0x27c
[9.292425] [cfff9e10] [c006ace4] mark_lock+0x2ac/0x658
[9.297660] [cfff9e40] [c006b7e4] __lock_acquire+0x754/0x1840
[9.303414] [cfff9ee0] [c006cdb8] lock_acquire+0x90/0xf4
[9.308745] [cfff9f20] [c043ef04] _raw_spin_lock+0x34/0x4c
[9.314250] [cfff9f30] [c02f4168] sata_fsl_interrupt+0x50/0x250
[9.320187] [cfff9f70] [c0079ff0] handle_irq_event_percpu+0x90/0x254
[9.326547] [cfff9fc0] [c007a1fc] handle_irq_event+0x48/0x78
[9.332220] [cfff9fe0] [c007c95c] handle_level_irq+0x9c/0x104
[9.337981] [cfff9ff0] [c000d978] call_handle_irq+0x18/0x28
[9.343568] [cc7139f0] [c000608c] do_IRQ+0xf0/0x1a8
[9.348464] [cc713a20] [c000fc8c] ret_from_except+0x0/0x14
[9.353983] --- Exception: 501 at _raw_spin_unlock_irq+0x40/0x50
[9.353983] LR = _raw_spin_unlock_irq+0x30/0x50
[9.364839] [cc713af0] [c043db10] wait_for_common+0xac/0x188
[9.370513] [cc713b30] [c02ddee4] ata_exec_internal_sg+0x2b0/0x4f0
[9.376699] [cc713be0] [c02de18c] ata_exec_internal+0x68/0xa8
[9.382454] [cc713c20] [c02de4b8] ata_dev_read_id+0x158/0x594
[9.388205] [cc713ca0] [c02ec244] ata_eh_recover+0xd88/0x13d0
[9.393962] [cc713d20] [c02f2520] sata_pmp_error_handler+0xc0/0x8ac
[9.400234] [cc713dd0] [c02ecdc8] ata_scsi_port_error_handler+0x464/0x5e8
[9.407023] [cc713e10] [c02ecfd0] ata_scsi_error+0x84/0xb8
[9.412528] [cc713e40] [c02c4974] scsi_error_handler+0xd8/0x47c
[9.418457] [cc713eb0] [c004737c] kthread+0xa8/0xac
[9.423355] [cc713f40] [c000f6b8] ret_from_kernel_thread+0x64/0x6c
This fix was suggested by Bhushan Bharat , and
was discussed in email at:
http://linuxppc.10917.n7.nabble.com/MPC8315-reboot-failure-lockdep-splat-possibly-related-tp75162.html
Same patch successfully tested with 3.9.7. linux-next compiled but
not tested on hardware.
This patch is based off linux-next tag next-20130819
(which is commit 66a01bae29d11916c09f9f5a937cafe7d402e4a5 )
Signed-off-by: Anthony Foiani
---
drivers/ata/sata_fsl.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index 19720a0..851bd3f 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -293,6 +293,7 @@ static void fsl_sata_set_irq_coalescing(struct ata_host
*host,
{
struct sata_fsl_host_priv *host_priv = host->private_data;
void __iomem *hcr_base = host_priv->hcr_base;
+ unsigned long flags;
if (count > ICC_MAX_INT_COUNT_THRESHOLD)
count = ICC_MAX_INT_COUNT_THRESHOLD;
@@ -305,12 +306,12 @@ static v
Re: [PATCH RESEND] i2c: move of helpers into the core
On 08/19/2013 12:59 PM, Wolfram Sang wrote: > I2C of helpers used to live in of_i2c.c but experience (from SPI) shows > that it is much cleaner to have this in the core. This also removes a > circular dependency between the helpers and the core, and so we can > finally register child nodes in the core instead of doing this manually > in each driver. So, fix the drivers and documentation, too. > > Signed-off-by: Wolfram Sang > --- Glad to see this. Acked-by: Rob Herring > > Sigh, hitting the CC threshold on vger again. So resending to the lists only. > BTW this patch is based on -rc4 and was tested on an AT91 board. More tests > very welcome. Thanks! > > > Documentation/acpi/enumeration.txt |1 - > drivers/i2c/busses/i2c-at91.c |3 - > drivers/i2c/busses/i2c-cpm.c|6 -- > drivers/i2c/busses/i2c-davinci.c|2 - > drivers/i2c/busses/i2c-designware-platdrv.c |2 - > drivers/i2c/busses/i2c-gpio.c |3 - > drivers/i2c/busses/i2c-i801.c |2 - > drivers/i2c/busses/i2c-ibm_iic.c|4 - > drivers/i2c/busses/i2c-imx.c|3 - > drivers/i2c/busses/i2c-mpc.c|2 - > drivers/i2c/busses/i2c-mv64xxx.c|3 - > drivers/i2c/busses/i2c-mxs.c|3 - > drivers/i2c/busses/i2c-nomadik.c|3 - > drivers/i2c/busses/i2c-ocores.c |3 - > drivers/i2c/busses/i2c-octeon.c |3 - > drivers/i2c/busses/i2c-omap.c |3 - > drivers/i2c/busses/i2c-pnx.c|3 - > drivers/i2c/busses/i2c-powermac.c |9 +- > drivers/i2c/busses/i2c-pxa.c|2 - > drivers/i2c/busses/i2c-s3c2410.c|2 - > drivers/i2c/busses/i2c-sh_mobile.c |2 - > drivers/i2c/busses/i2c-sirf.c |3 - > drivers/i2c/busses/i2c-stu300.c |2 - > drivers/i2c/busses/i2c-tegra.c |3 - > drivers/i2c/busses/i2c-versatile.c |2 - > drivers/i2c/busses/i2c-wmt.c|3 - > drivers/i2c/busses/i2c-xiic.c |3 - > drivers/i2c/i2c-core.c | 107 - > drivers/i2c/i2c-mux.c |3 - > drivers/i2c/muxes/i2c-arb-gpio-challenge.c |1 - > drivers/i2c/muxes/i2c-mux-gpio.c|1 - > drivers/i2c/muxes/i2c-mux-pinctrl.c |1 - > drivers/media/platform/exynos4-is/fimc-is-i2c.c |3 - > drivers/of/Kconfig |6 -- > drivers/of/Makefile |1 - > drivers/of/of_i2c.c | 114 > --- > include/linux/i2c.h | 20 > include/linux/of_i2c.h | 46 - > 38 files changed, 130 insertions(+), 253 deletions(-) > delete mode 100644 drivers/of/of_i2c.c > delete mode 100644 include/linux/of_i2c.h > > diff --git a/Documentation/acpi/enumeration.txt > b/Documentation/acpi/enumeration.txt > index d9be7a9..958266e 100644 > --- a/Documentation/acpi/enumeration.txt > +++ b/Documentation/acpi/enumeration.txt > @@ -238,7 +238,6 @@ An I2C bus (controller) driver does: > if (ret) > /* handle error */ > > - of_i2c_register_devices(adapter); > /* Enumerate the slave devices behind this bus via ACPI */ > acpi_i2c_register_devices(adapter); > > diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c > index 6bb839b..fd05930 100644 > --- a/drivers/i2c/busses/i2c-at91.c > +++ b/drivers/i2c/busses/i2c-at91.c > @@ -28,7 +28,6 @@ > #include > #include > #include > -#include > #include > #include > #include > @@ -775,8 +774,6 @@ static int at91_twi_probe(struct platform_device *pdev) > return rc; > } > > - of_i2c_register_devices(&dev->adapter); > - > dev_info(dev->dev, "AT91 i2c bus driver.\n"); > return 0; > } > diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c > index 2e1f7eb..b2b8aa9 100644 > --- a/drivers/i2c/busses/i2c-cpm.c > +++ b/drivers/i2c/busses/i2c-cpm.c > @@ -42,7 +42,6 @@ > #include > #include > #include > -#include > #include > #include > > @@ -681,11 +680,6 @@ static int cpm_i2c_probe(struct platform_device *ofdev) > dev_dbg(&ofdev->dev, "hw routines for %s registered.\n", > cpm->adap.name); > > - /* > - * register OF I2C devices > - */ > - of_i2c_register_devices(&cpm->adap); > - > return 0; > out_shut: > cpm_i2c_shutdown(cpm); > diff --git a/drivers/i2c/busses/i2c-davinci.c > b/drivers/i2c/busses/i2c-davinci.c > index fa55605..62be3b3 100644 > --- a/drivers/i2c/busses/i2c-davinci.c > +++ b/drivers/i2c/busses
Re: [PATCH v8 2/2] ASoC: fsl: Add S/PDIF machine driver
On 08/19/2013 06:08 AM, Nicolin Chen wrote: > This patch implements a device-tree-only machine driver for Freescale > i.MX series Soc. It works with spdif_transmitter/spdif_receiver and > fsl_spdif.c drivers. > diff --git a/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt > b/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt > +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. Those object truly don't exist in HW and only exist due to internal details of Linux's ASoC subsystem. Instead, you should register any SPDIF rx/tx dummy CODEC internally to the machine driver. Perhaps you'll still need properties to indicate which of the RX and TX paths of the HW block are actually connected to anything on the board. Perhaps a Boolean property "spdif-tx" to indicate TX support, otherwise RX support is assumed? Or, to map the properties more directly to HW, perhaps name the property "spdif-tx-jack-exists", or even "spdif-tx-jack" and make it a phandle to a node that represents the actual S/PDIF connector? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
On 08/19/2013 06:08 AM, Nicolin Chen wrote: > This patch implements a device-tree-only CPU DAI driver for Freescale > S/PDIF controller that supports stereo playback and record feature. > diff --git a/Documentation/devicetree/bindings/sound/fsl,spdif.txt > b/Documentation/devicetree/bindings/sound/fsl,spdif.txt > +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. Well, the cable type is more a property of the components that are hooked to the SoC signals that this module drives, so are somewhat out of scope of this binding document. However, this is nit-picky comment, and I'm not too worried about it. > + - clock-names : Includes the following entries: > + "core" The core clock of spdif controller > + "rxtx<0-7>" Clock source list for tx and rx clock. > + This clock list should be identical to > + the source list connecting to the spdif > + clock mux in "SPDIF Transceiver Clock > + Diagram" of SoC reference manual. It > + can also be referred to TxClk_Source > + bit of register SPDIF_STC. So, the HW block has 1 clock input, yet there's a mux somewhere else in the SoC which has 8 inputs? If so, I'm not completely sure it's correct to reference anything other than the "core" clock in this binding. I think the other clocks would be more suitably represented in the system-level "sound card" binding that I guess patch 2/2 (which I haven't read yet) adds, since I assume those clock are more to do with system-level clock tree setup decisions, and might not even exist in some other SoC that included this IP block. What do others think, assuming I'm correct about my HW design assumptions? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RESEND] i2c: move of helpers into the core
On Mon, Aug 19, 2013 at 09:46:04PM +0200, Thierry Reding wrote:
> On Mon, Aug 19, 2013 at 07:59:40PM +0200, Wolfram Sang wrote:
> [...]
> > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> [...]
> > +#if IS_ENABLED(CONFIG_OF)
> > +static void of_i2c_register_devices(struct i2c_adapter *adap)
> > +{
> [...]
> > +}
> [...]
> > +#endif /* CONFIG_OF */
>
> Isn't this missing the dummy implementation for !OF.
Argh, will fix...
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Critical Interrupt Input
The easy thing is to start to experimenting with scratch/preserve registers :)
On 8/20/13, Benjamin Herrenschmidt wrote:
> On Mon, 2013-08-19 at 12:00 -0700, Henry Bausley wrote:
>>
>> Support does appear to be present but there is a problem returning
>> back to user space I suspect.
>
> Probably a problem with TLB misses vs. crit interrupts.
>
> A critical interrupt can re-enter a TLB miss.
>
> I can see two potential issues there:
>
> - A bug where we don't properly restore "something" (I thought we did
> save and restore MMUCR though, but that's worth dbl checking if it works
> properly) accross the crit entry/exit
>
> - Something in your crit code causing a TLB miss (the
> kernel .text/.data/.bss should be bolted but anything else can). We
> don't currently support re-entering the TLB miss that way.
>
> If we were to support the latter, we'd need to detect on entering a crit
> that the PC is within the TLB miss handler, and setup a return context
> to the original instruction (replay the miss) rather than trying to
> resume it..
>
> Cheers,
> Ben.
>
>> What fails is it causes Linux user space programs to get Segmentation
>> errors.
>> Issuing a simple ls causes a segmentation fault sometimes. The shell
>> gets terminated
>> and you cannot log back in. INIT: Id "T0" respawning too fast:
>> disabled for 5 minutes pops up.
>>
>> However, the critical interrupt handler keeps running. I know this by
>> adding the reading
>> of a physical I/O location in the handler and can see it is being read
>> on the scope.
>>
>>
>> The only code in the handler is below.
>>
>> void critintr_handler(void *dev)
>> {
>> critintrcount++; // increment a variable
>> iodata = *piom; // read an I/O location
>> mtdcr(0x0c0, 0x2000); // clear critical interrupt
>> }
>>
>>
>> Below is a log of the type of crashes that occur:
>>
>> root@10.34.9.213:/opt/ppmac/ktest# ls
>> Segmentation fault
>> root@10.34.9.213:/opt/ppmac/ktest# ls
>> Segmentation fault
>> root@10.34.9.213:/opt/ppmac/ktest# ls
>> Makefilektest.cktest.ko ktest.mod.o modules.order
>> Module.symvers ktest.cbp ktest.mod.c ktest.o
>> root@10.34.9.213:/opt/ppmac/ktest# ls
>>
>> Debian GNU/Linux 7 powerpmac ttyS0
>>
>> powerpmac login: root
>>
>> Debian GNU/Linux 7 powerpmac ttyS0
>>
>> powerpmac login: root
>>
>> Debian GNU/Linux 7 powerpmac ttyS0
>>
>> powerpmac login: root
>>
>> Debian GNU/Linux 7 powerpmac ttyS0
>>
>> powerpmac login: root
>> Password:
>> Last login: Thu Nov 30 20:42:16 UTC 1933 on ttyS0
>> Linux powerpmac 3.2.21-aspen_2.01.09 #10 Mon Aug 19 08:49:12 PDT 2013
>> ppc
>>
>> The programs included with the Debian GNU/Linux system are free
>> software;
>> the exact distribution terms for each program are described in the
>> individual files in /usr/share/doc/*/copyright.
>>
>> Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
>> permitted by applicable law.
>> INIT: Id "T0" respawning too fast: disabled for 5 minutes
>>
>>
>> __
>> From: "Benjamin Herrenschmidt"
>> Sent: Saturday, August 17, 2013 3:05 PM
>> To: "Kumar Gala"
>> Cc: linuxppc-dev@lists.ozlabs.org, hbaus...@deltatau.com
>> Subject: Re: Critical Interrupt Input
>>
>> On Fri, 2013-08-16 at 06:04 -0500, Kumar Gala wrote:
>> > The 44x low level code needs to handle exception stacks properly for
>> > this to work. Since its possible to have a critical exception occur
>> > while in a normal exception level, you have to have proper saving of
>> > additional register state and a stack frame for the critical
>> > exception, etc. I'm not sure if that was ever done for 44x.
>>
>> Don't 44x and FSL BookE share the same macros ? I would think 44x does
>> indeed implement the same crit support as e500...
>>
>> What does the crash look like ?
>>
>> Ben.
>>
>>
>> ___
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>
>>
>> ÂÂ
>
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
--
Regards,
Denis
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Critical Interrupt Input
On Mon, 2013-08-19 at 12:00 -0700, Henry Bausley wrote:
>
> Support does appear to be present but there is a problem returning
> back to user space I suspect.
Probably a problem with TLB misses vs. crit interrupts.
A critical interrupt can re-enter a TLB miss.
I can see two potential issues there:
- A bug where we don't properly restore "something" (I thought we did
save and restore MMUCR though, but that's worth dbl checking if it works
properly) accross the crit entry/exit
- Something in your crit code causing a TLB miss (the
kernel .text/.data/.bss should be bolted but anything else can). We
don't currently support re-entering the TLB miss that way.
If we were to support the latter, we'd need to detect on entering a crit
that the PC is within the TLB miss handler, and setup a return context
to the original instruction (replay the miss) rather than trying to
resume it..
Cheers,
Ben.
> What fails is it causes Linux user space programs to get Segmentation
> errors.
> Issuing a simple ls causes a segmentation fault sometimes. The shell
> gets terminated
> and you cannot log back in. INIT: Id "T0" respawning too fast:
> disabled for 5 minutes pops up.
>
> However, the critical interrupt handler keeps running. I know this by
> adding the reading
> of a physical I/O location in the handler and can see it is being read
> on the scope.
>
>
> The only code in the handler is below.
>
> void critintr_handler(void *dev)
> {
> critintrcount++; // increment a variable
> iodata = *piom; // read an I/O location
> mtdcr(0x0c0, 0x2000); // clear critical interrupt
> }
>
>
> Below is a log of the type of crashes that occur:
>
> root@10.34.9.213:/opt/ppmac/ktest# ls
> Segmentation fault
> root@10.34.9.213:/opt/ppmac/ktest# ls
> Segmentation fault
> root@10.34.9.213:/opt/ppmac/ktest# ls
> Makefilektest.cktest.ko ktest.mod.o modules.order
> Module.symvers ktest.cbp ktest.mod.c ktest.o
> root@10.34.9.213:/opt/ppmac/ktest# ls
>
> Debian GNU/Linux 7 powerpmac ttyS0
>
> powerpmac login: root
>
> Debian GNU/Linux 7 powerpmac ttyS0
>
> powerpmac login: root
>
> Debian GNU/Linux 7 powerpmac ttyS0
>
> powerpmac login: root
>
> Debian GNU/Linux 7 powerpmac ttyS0
>
> powerpmac login: root
> Password:
> Last login: Thu Nov 30 20:42:16 UTC 1933 on ttyS0
> Linux powerpmac 3.2.21-aspen_2.01.09 #10 Mon Aug 19 08:49:12 PDT 2013
> ppc
>
> The programs included with the Debian GNU/Linux system are free
> software;
> the exact distribution terms for each program are described in the
> individual files in /usr/share/doc/*/copyright.
>
> Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
> permitted by applicable law.
> INIT: Id "T0" respawning too fast: disabled for 5 minutes
>
>
> __
> From: "Benjamin Herrenschmidt"
> Sent: Saturday, August 17, 2013 3:05 PM
> To: "Kumar Gala"
> Cc: linuxppc-dev@lists.ozlabs.org, hbaus...@deltatau.com
> Subject: Re: Critical Interrupt Input
>
> On Fri, 2013-08-16 at 06:04 -0500, Kumar Gala wrote:
> > The 44x low level code needs to handle exception stacks properly for
> > this to work. Since its possible to have a critical exception occur
> > while in a normal exception level, you have to have proper saving of
> > additional register state and a stack frame for the critical
> > exception, etc. I'm not sure if that was ever done for 44x.
>
> Don't 44x and FSL BookE share the same macros ? I would think 44x does
> indeed implement the same crit support as e500...
>
> What does the crash look like ?
>
> Ben.
>
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
> ÂÂ
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RESEND] i2c: move of helpers into the core
On Mon, Aug 19, 2013 at 07:59:40PM +0200, Wolfram Sang wrote: > I2C of helpers used to live in of_i2c.c but experience (from SPI) shows > that it is much cleaner to have this in the core. This also removes a > circular dependency between the helpers and the core, and so we can > finally register child nodes in the core instead of doing this manually > in each driver. So, fix the drivers and documentation, too. > > Signed-off-by: Wolfram Sang for i2c-omap.c: Reviewed-by: Felipe Balbi -- balbi signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RESEND] i2c: move of helpers into the core
> However this patch fails to apply onto either v3.11-rc4 or v3.11-rc6: Argh, did not drop the MPC patch before rebasing :( So either pick the patch "i2c: powermac: fix return path on error" before, pull the branch [1], or force me to resend ;) Thanks! [1] git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/core-with-of signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH V3 3/5] powerpc/cpuidle: Generic powerpc backend cpuidle driver.
On Mon, 2013-08-19 at 15:48 +0530, Deepthi Dharwar wrote: > Hi Dongsheng, > > On 08/19/2013 11:22 AM, Wang Dongsheng-B40534 wrote: > > I think we should move the states and handle function to > > arch/power/platform* > > The states and handle function is belong to backend driver, not for this, > > different platform have different state. > > Different platforms to make their own deal with these states. > > > > I think we cannot put all the status of different platforms and handler in > > this driver. > > The idea here is a single powerpc back-end driver, which does a runtime > detection of the platform it is running and choose the right > idle states table. This was one of outcome of V2 discussion. I see a lot more in there than just detecting a platform and choosing a driver. > I feel there is no harm in keeping the state information in the same > file. We do have x86, which has all its variants information in one > file. One place will have all the idle consolidated information of > all the platform variants. If community does feel, we need to > have just the states information in arch specific file, we can do so. What actual functionality is common to all powerpc but not common to other arches? > >> diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig > >> index 0e2cd5c..99ee5d4 100644 > >> --- a/drivers/cpuidle/Kconfig > >> +++ b/drivers/cpuidle/Kconfig > >> @@ -42,6 +42,13 @@ config CPU_IDLE_ZYNQ > >>help > >> Select this to enable cpuidle on Xilinx Zynq processors. > >> > >> +config CPU_IDLE_POWERPC > >> + bool "CPU Idle driver for POWERPC platforms" > >> + depends on PPC64 > > > > Why not PPC? > > PPC64 seems to a good place to began the consolidation work. This > patch-set has not been tested for PPC32 currently. PPC64 is a bad place to start if you want it to be generic, because it means you'll end up growing dependencies on other things that are PPC64 only. There are too many arbitrary 32/64 differences as is. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH RESEND] i2c: move of helpers into the core
I2C of helpers used to live in of_i2c.c but experience (from SPI) shows that it is much cleaner to have this in the core. This also removes a circular dependency between the helpers and the core, and so we can finally register child nodes in the core instead of doing this manually in each driver. So, fix the drivers and documentation, too. Signed-off-by: Wolfram Sang --- Sigh, hitting the CC threshold on vger again. So resending to the lists only. BTW this patch is based on -rc4 and was tested on an AT91 board. More tests very welcome. Thanks! Documentation/acpi/enumeration.txt |1 - drivers/i2c/busses/i2c-at91.c |3 - drivers/i2c/busses/i2c-cpm.c|6 -- drivers/i2c/busses/i2c-davinci.c|2 - drivers/i2c/busses/i2c-designware-platdrv.c |2 - drivers/i2c/busses/i2c-gpio.c |3 - drivers/i2c/busses/i2c-i801.c |2 - drivers/i2c/busses/i2c-ibm_iic.c|4 - drivers/i2c/busses/i2c-imx.c|3 - drivers/i2c/busses/i2c-mpc.c|2 - drivers/i2c/busses/i2c-mv64xxx.c|3 - drivers/i2c/busses/i2c-mxs.c|3 - drivers/i2c/busses/i2c-nomadik.c|3 - drivers/i2c/busses/i2c-ocores.c |3 - drivers/i2c/busses/i2c-octeon.c |3 - drivers/i2c/busses/i2c-omap.c |3 - drivers/i2c/busses/i2c-pnx.c|3 - drivers/i2c/busses/i2c-powermac.c |9 +- drivers/i2c/busses/i2c-pxa.c|2 - drivers/i2c/busses/i2c-s3c2410.c|2 - drivers/i2c/busses/i2c-sh_mobile.c |2 - drivers/i2c/busses/i2c-sirf.c |3 - drivers/i2c/busses/i2c-stu300.c |2 - drivers/i2c/busses/i2c-tegra.c |3 - drivers/i2c/busses/i2c-versatile.c |2 - drivers/i2c/busses/i2c-wmt.c|3 - drivers/i2c/busses/i2c-xiic.c |3 - drivers/i2c/i2c-core.c | 107 - drivers/i2c/i2c-mux.c |3 - drivers/i2c/muxes/i2c-arb-gpio-challenge.c |1 - drivers/i2c/muxes/i2c-mux-gpio.c|1 - drivers/i2c/muxes/i2c-mux-pinctrl.c |1 - drivers/media/platform/exynos4-is/fimc-is-i2c.c |3 - drivers/of/Kconfig |6 -- drivers/of/Makefile |1 - drivers/of/of_i2c.c | 114 --- include/linux/i2c.h | 20 include/linux/of_i2c.h | 46 - 38 files changed, 130 insertions(+), 253 deletions(-) delete mode 100644 drivers/of/of_i2c.c delete mode 100644 include/linux/of_i2c.h diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt index d9be7a9..958266e 100644 --- a/Documentation/acpi/enumeration.txt +++ b/Documentation/acpi/enumeration.txt @@ -238,7 +238,6 @@ An I2C bus (controller) driver does: if (ret) /* handle error */ - of_i2c_register_devices(adapter); /* Enumerate the slave devices behind this bus via ACPI */ acpi_i2c_register_devices(adapter); diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c index 6bb839b..fd05930 100644 --- a/drivers/i2c/busses/i2c-at91.c +++ b/drivers/i2c/busses/i2c-at91.c @@ -28,7 +28,6 @@ #include #include #include -#include #include #include #include @@ -775,8 +774,6 @@ static int at91_twi_probe(struct platform_device *pdev) return rc; } - of_i2c_register_devices(&dev->adapter); - dev_info(dev->dev, "AT91 i2c bus driver.\n"); return 0; } diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c index 2e1f7eb..b2b8aa9 100644 --- a/drivers/i2c/busses/i2c-cpm.c +++ b/drivers/i2c/busses/i2c-cpm.c @@ -42,7 +42,6 @@ #include #include #include -#include #include #include @@ -681,11 +680,6 @@ static int cpm_i2c_probe(struct platform_device *ofdev) dev_dbg(&ofdev->dev, "hw routines for %s registered.\n", cpm->adap.name); - /* -* register OF I2C devices -*/ - of_i2c_register_devices(&cpm->adap); - return 0; out_shut: cpm_i2c_shutdown(cpm); diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c index fa55605..62be3b3 100644 --- a/drivers/i2c/busses/i2c-davinci.c +++ b/drivers/i2c/busses/i2c-davinci.c @@ -38,7 +38,6 @@ #include #include #include -#include #include #include @@ -728,7 +727,6 @@ static int davinci_i2c_probe(struct platform_device *pdev) dev_err(&pdev->dev, "failure adding adapter\n"); goto err_unuse_clocks; }
Re: [RFC PATCH v2 00/11] Add (de)compression support to pstore
On Sat, Aug 17, 2013 at 11:32 AM, Kees Cook wrote: > Yeah, this is great. While I haven't tested it myself yet, the code > seems to be in good shape. I acked the ram piece separately, but > consider the entire series: > > Reviewed-by: Kees Cook Applied. This should show up in linux-next tomorrow. Anyone using efivars as the pstore backend? Testing reports (positive or negative) appreciated. -Tony ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/4] hotplug, powerpc, x86: Remove cpu_hotplug_driver_lock()
On Mon, 2013-08-19 at 10:20 -0500, Nathan Fontenot wrote: > On 08/17/2013 02:46 PM, Toshi Kani wrote: > > cpu_hotplug_driver_lock() serializes CPU online/offline operations > > when ARCH_CPU_PROBE_RELEASE is set. This lock interface is no longer > > necessary with the following reason: > > > > - lock_device_hotplug() now protects CPU online/offline operations, > >including the probe & release interfaces enabled by > >ARCH_CPU_PROBE_RELEASE. The use of cpu_hotplug_driver_lock() is > >redundant. > > - cpu_hotplug_driver_lock() is only valid when ARCH_CPU_PROBE_RELEASE > >is defined, which is misleading and is only enabled on powerpc. > > > > This patch removes the cpu_hotplug_driver_lock() interface. As > > a result, ARCH_CPU_PROBE_RELEASE only enables / disables the cpu > > probe & release interface as intended. There is no functional change > > in this patch. > > > > Signed-off-by: Toshi Kani > > Reviewed-by: Nathan Fontenot Thanks Nathan! -Toshi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/4] hotplug, powerpc, x86: Remove cpu_hotplug_driver_lock()
On 08/17/2013 02:46 PM, Toshi Kani wrote:
> cpu_hotplug_driver_lock() serializes CPU online/offline operations
> when ARCH_CPU_PROBE_RELEASE is set. This lock interface is no longer
> necessary with the following reason:
>
> - lock_device_hotplug() now protects CPU online/offline operations,
>including the probe & release interfaces enabled by
>ARCH_CPU_PROBE_RELEASE. The use of cpu_hotplug_driver_lock() is
>redundant.
> - cpu_hotplug_driver_lock() is only valid when ARCH_CPU_PROBE_RELEASE
>is defined, which is misleading and is only enabled on powerpc.
>
> This patch removes the cpu_hotplug_driver_lock() interface. As
> a result, ARCH_CPU_PROBE_RELEASE only enables / disables the cpu
> probe & release interface as intended. There is no functional change
> in this patch.
>
> Signed-off-by: Toshi Kani
Reviewed-by: Nathan Fontenot
> ---
> Performed build test only on powerpc.
> ---
> arch/powerpc/kernel/smp.c | 12 --
> arch/powerpc/platforms/pseries/dlpar.c | 40
>
> arch/x86/kernel/topology.c |2 --
> drivers/base/cpu.c | 10 +---
> include/linux/cpu.h| 13 --
> 5 files changed, 16 insertions(+), 61 deletions(-)
>
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 38b0ba6..1667269 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -763,18 +763,6 @@ void __cpu_die(unsigned int cpu)
> smp_ops->cpu_die(cpu);
> }
>
> -static DEFINE_MUTEX(powerpc_cpu_hotplug_driver_mutex);
> -
> -void cpu_hotplug_driver_lock()
> -{
> - mutex_lock(&powerpc_cpu_hotplug_driver_mutex);
> -}
> -
> -void cpu_hotplug_driver_unlock()
> -{
> - mutex_unlock(&powerpc_cpu_hotplug_driver_mutex);
> -}
> -
> void cpu_die(void)
> {
> if (ppc_md.cpu_die)
> diff --git a/arch/powerpc/platforms/pseries/dlpar.c
> b/arch/powerpc/platforms/pseries/dlpar.c
> index a1a7b9a..e39325d 100644
> --- a/arch/powerpc/platforms/pseries/dlpar.c
> +++ b/arch/powerpc/platforms/pseries/dlpar.c
> @@ -387,18 +387,13 @@ static ssize_t dlpar_cpu_probe(const char *buf, size_t
> count)
> char *cpu_name;
> int rc;
>
> - cpu_hotplug_driver_lock();
> rc = strict_strtoul(buf, 0, &drc_index);
> - if (rc) {
> - rc = -EINVAL;
> - goto out;
> - }
> + if (rc)
> + return -EINVAL;
>
> dn = dlpar_configure_connector(drc_index);
> - if (!dn) {
> - rc = -EINVAL;
> - goto out;
> - }
> + if (!dn)
> + return -EINVAL;
>
> /* configure-connector reports cpus as living in the base
>* directory of the device tree. CPUs actually live in the
> @@ -407,8 +402,7 @@ static ssize_t dlpar_cpu_probe(const char *buf, size_t
> count)
> cpu_name = kasprintf(GFP_KERNEL, "/cpus%s", dn->full_name);
> if (!cpu_name) {
> dlpar_free_cc_nodes(dn);
> - rc = -ENOMEM;
> - goto out;
> + return -ENOMEM;
> }
>
> kfree(dn->full_name);
> @@ -417,22 +411,21 @@ static ssize_t dlpar_cpu_probe(const char *buf, size_t
> count)
> rc = dlpar_acquire_drc(drc_index);
> if (rc) {
> dlpar_free_cc_nodes(dn);
> - rc = -EINVAL;
> - goto out;
> + return -EINVAL;
> }
>
> rc = dlpar_attach_node(dn);
> if (rc) {
> dlpar_release_drc(drc_index);
> dlpar_free_cc_nodes(dn);
> - goto out;
> + return rc;
> }
>
> rc = dlpar_online_cpu(dn);
> -out:
> - cpu_hotplug_driver_unlock();
> + if (rc)
> + return rc;
>
> - return rc ? rc : count;
> + return count;
> }
>
> static int dlpar_offline_cpu(struct device_node *dn)
> @@ -505,30 +498,27 @@ static ssize_t dlpar_cpu_release(const char *buf,
> size_t count)
> return -EINVAL;
> }
>
> - cpu_hotplug_driver_lock();
> rc = dlpar_offline_cpu(dn);
> if (rc) {
> of_node_put(dn);
> - rc = -EINVAL;
> - goto out;
> + return -EINVAL;
> }
>
> rc = dlpar_release_drc(*drc_index);
> if (rc) {
> of_node_put(dn);
> - goto out;
> + return rc;
> }
>
> rc = dlpar_detach_node(dn);
> if (rc) {
> dlpar_acquire_drc(*drc_index);
> - goto out;
> + return rc;
> }
>
> of_node_put(dn);
> -out:
> - cpu_hotplug_driver_unlock();
> - return rc ? rc : count;
> +
> + return count;
> }
>
> static int __init pseries_dlpar_init(void)
> diff --git a/arch/x86/kernel/topology.c b/arch/x86/kernel/topology.c
> index a3f35eb..649b010 100644
> --- a/arch/x86/kernel/topology.c
> +++ b/arch/x86/kernel/topology.c
> @@ -66,7 +66,6 @@ int __ref _debug_hotplug_cpu(int cpu,
Re: [PATCH 0/4] Unify CPU hotplug lock interface
On Sun, 2013-08-18 at 03:02 +0200, Rafael J. Wysocki wrote: > On Saturday, August 17, 2013 01:46:55 PM Toshi Kani wrote: > > lock_device_hotplug() was recently introduced to serialize CPU & Memory > > online/offline and hotplug operations, along with sysfs online interface > > restructure (commit 4f3549d7). With this new locking scheme, > > cpu_hotplug_driver_lock() is redundant and is no longer necessary. > > > > This patchset makes sure that lock_device_hotplug() covers all CPU online/ > > offline interfaces, and then removes cpu_hotplug_driver_lock(). > > > > The patchset is based on Linus's tree, 3.11.0-rc5. > > Nice series, thanks a lot for taking care of this! Thanks Rafael! -Toshi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/4] hotplug, x86: Add hotplug lock to missing places
On Sat, 2013-08-17 at 16:15 -0700, Greg KH wrote: > On Sat, Aug 17, 2013 at 01:46:57PM -0600, Toshi Kani wrote: > > lock_device_hotplug() serializes CPU & Memory online/offline and hotplug > > operations. However, this lock is not held in the debug interfaces below > > that initiate CPU online/offline operations. > > > > - _debug_hotplug_cpu(), cpu0 hotplug test interface enabled by > >CONFIG_DEBUG_HOTPLUG_CPU0. > > - cpu_probe_store() and cpu_release_store(), cpu hotplug test interface > >enabled by CONFIG_ARCH_CPU_PROBE_RELEASE. > > > > This patch changes the above interfaces to hold lock_device_hotplug(). > > > > Signed-off-by: Toshi Kani > > --- > > arch/x86/kernel/topology.c |2 ++ > > drivers/base/cpu.c | 16 ++-- > > 2 files changed, 16 insertions(+), 2 deletions(-) > > Acked-by: Greg Kroah-Hartman Thanks Greg! -Toshi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 8/8] powerpc/pseries: child nodes are not detached by dlpar_detach_node
On 08/15/2013 12:23 AM, Tyrel Datwyler wrote:
> Calls to dlpar_detach_node do not iterate over child nodes detaching them as
> well. By iterating and detaching the child nodes we ensure that they have the
> OF_DETACHED flag set and that their reference counts are decremented such that
> the node will be freed from memory by of_node_release.
>
> Signed-off-by: Tyrel Datwyler
Acked-by: Nathan Fontenot
> ---
> arch/powerpc/platforms/pseries/dlpar.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/powerpc/platforms/pseries/dlpar.c
> b/arch/powerpc/platforms/pseries/dlpar.c
> index 4ea667d..7cfdaae 100644
> --- a/arch/powerpc/platforms/pseries/dlpar.c
> +++ b/arch/powerpc/platforms/pseries/dlpar.c
> @@ -286,8 +286,15 @@ int dlpar_attach_node(struct device_node *dn)
>
> int dlpar_detach_node(struct device_node *dn)
> {
> + struct device_node *child;
> int rc;
>
> + child = of_get_next_child(dn, NULL);
> + while (child) {
> + dlpar_detach_node(child);
> + child = of_get_next_child(dn, child);
> + }
> +
> rc = of_detach_node(dn);
> if (rc)
> return rc;
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 3/4] powerpc: refactor of_get_cpu_node to support other architectures
On 19/08/13 14:02, Rob Herring wrote:
> On 08/19/2013 05:19 AM, Mark Rutland wrote:
>> On Sat, Aug 17, 2013 at 11:09:36PM +0100, Benjamin Herrenschmidt wrote:
>>> On Sat, 2013-08-17 at 12:50 +0200, Tomasz Figa wrote:
I wonder how would this handle uniprocessor ARM (pre-v7) cores, for
which
the updated bindings[1] define #address-cells = <0> and so no reg
property.
[1] - http://thread.gmane.org/gmane.linux.ports.arm.kernel/260795
>>>
>>> Why did you do that in the binding ? That sounds like looking to create
>>> problems ...
>>>
>>> Traditionally, UP setups just used "0" as the "reg" property on other
>>> architectures, why do differently ?
>>
>> The decision was taken because we defined our reg property to refer to
>> the MPIDR register's Aff{2,1,0} bitfields, and on UP cores before v7
>> there's no MPIDR register at all. Given there can only be a single CPU
>> in that case, describing a register that wasn't present didn't seem
>> necessary or helpful.
>
> What exactly reg represents is up to the binding definition, but it
> still should be present IMO. I don't see any issue with it being
> different for pre-v7.
>
Yes it's better to have 'reg' with value 0 than not having it.
Otherwise this generic of_get_cpu_node implementation would need some
_hack_ to handle that case.
Regards,
Sudeep
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/8] powerpc/pseries: add mising of_node_put in delete_dt_node
On 08/15/2013 12:23 AM, Tyrel Datwyler wrote: > The node to be detached is retrieved via its phandle by a call to > of_find_node_by_phandle which increments the ref count. We need a matching > call to of_node_put to decrement the ref count and ensure the node is > actually freed. > > Signed-off-by: Tyrel Datwyler Acked-by: Nathan Fontenot > --- > arch/powerpc/platforms/pseries/mobility.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/powerpc/platforms/pseries/mobility.c > b/arch/powerpc/platforms/pseries/mobility.c > index ff102e2..cde4e0a 100644 > --- a/arch/powerpc/platforms/pseries/mobility.c > +++ b/arch/powerpc/platforms/pseries/mobility.c > @@ -62,6 +62,7 @@ static int delete_dt_node(u32 phandle) > return -ENOENT; > > dlpar_detach_node(dn); > + of_node_put(dn); > return 0; > } > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/8] powerpc/pseries: make dlpar_configure_connector parent node aware
On 08/15/2013 12:23 AM, Tyrel Datwyler wrote:
> Currently the device nodes created in the device subtree returned by a call to
> dlpar_configure_connector are all named in the root node. This is because the
> the node name in the work area returned by ibm,configure-connector rtas call
> only contains the node name and not the entire node path. Passing the parent
> node where the new subtree will be created to dlpar_configure_connector allows
> the correct node path to be prefixed in the full_name field.
>
> Signed-off-by: Tyrel Datwyler
Acked-by: Nathan Fontenot
> ---
> arch/powerpc/platforms/pseries/dlpar.c| 55
> ---
> arch/powerpc/platforms/pseries/mobility.c | 11 +++
> arch/powerpc/platforms/pseries/pseries.h | 2 +-
> 3 files changed, 34 insertions(+), 34 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/dlpar.c
> b/arch/powerpc/platforms/pseries/dlpar.c
> index c855233..4ea667d 100644
> --- a/arch/powerpc/platforms/pseries/dlpar.c
> +++ b/arch/powerpc/platforms/pseries/dlpar.c
> @@ -63,21 +63,24 @@ static struct property *dlpar_parse_cc_property(struct
> cc_workarea *ccwa)
> return prop;
> }
>
> -static struct device_node *dlpar_parse_cc_node(struct cc_workarea *ccwa)
> +static struct device_node *dlpar_parse_cc_node(struct cc_workarea *ccwa,
> +const char *path)
> {
> struct device_node *dn;
> char *name;
>
> + /* If parent node path is "/" advance path to NULL terminator to
> + * prevent double leading slashs in full_name.
> + */
> + if (!path[1])
> + path++;
> +
> dn = kzalloc(sizeof(*dn), GFP_KERNEL);
> if (!dn)
> return NULL;
>
> - /* The configure connector reported name does not contain a
> - * preceding '/', so we allocate a buffer large enough to
> - * prepend this to the full_name.
> - */
> name = (char *)ccwa + ccwa->name_offset;
> - dn->full_name = kasprintf(GFP_KERNEL, "/%s", name);
> + dn->full_name = kasprintf(GFP_KERNEL, "%s/%s", path, name);
> if (!dn->full_name) {
> kfree(dn);
> return NULL;
> @@ -123,7 +126,8 @@ void dlpar_free_cc_nodes(struct device_node *dn)
> #define CALL_AGAIN -2
> #define ERR_CFG_USE -9003
>
> -struct device_node *dlpar_configure_connector(u32 drc_index)
> +struct device_node *dlpar_configure_connector(u32 drc_index,
> + struct device_node *parent)
> {
> struct device_node *dn;
> struct device_node *first_dn = NULL;
> @@ -132,6 +136,7 @@ struct device_node *dlpar_configure_connector(u32
> drc_index)
> struct property *last_property = NULL;
> struct cc_workarea *ccwa;
> char *data_buf;
> + const char *parent_path = parent->full_name;
> int cc_token;
> int rc = -1;
>
> @@ -165,7 +170,7 @@ struct device_node *dlpar_configure_connector(u32
> drc_index)
> break;
>
> case NEXT_SIBLING:
> - dn = dlpar_parse_cc_node(ccwa);
> + dn = dlpar_parse_cc_node(ccwa, parent_path);
> if (!dn)
> goto cc_error;
>
> @@ -175,13 +180,17 @@ struct device_node *dlpar_configure_connector(u32
> drc_index)
> break;
>
> case NEXT_CHILD:
> - dn = dlpar_parse_cc_node(ccwa);
> + if (first_dn)
> + parent_path = last_dn->full_name;
> +
> + dn = dlpar_parse_cc_node(ccwa, parent_path);
> if (!dn)
> goto cc_error;
>
> - if (!first_dn)
> + if (!first_dn) {
> + dn->parent = parent;
> first_dn = dn;
> - else {
> + } else {
> dn->parent = last_dn;
> if (last_dn)
> last_dn->child = dn;
> @@ -205,6 +214,7 @@ struct device_node *dlpar_configure_connector(u32
> drc_index)
>
> case PREV_PARENT:
> last_dn = last_dn->parent;
> + parent_path = last_dn->parent->full_name;
> break;
>
> case CALL_AGAIN:
> @@ -383,9 +393,8 @@ out:
>
> static ssize_t dlpar_cpu_probe(const char *buf, size_t count)
> {
> - struct device_node *dn;
> + struct device_node *dn, *parent;
> unsigned long drc_index;
> - char *cpu_name;
> int rc;
>
> cpu_hotplug_driver_lock();
> @@ -395,25 +404,19 @@ static ssize_t dlpar_cpu_probe(const char *buf, size_t
> count)
> goto out;
> }
>
> - dn = dlpar_configure_connector(drc_index);
> - if (!dn) {
> - rc = -EINVAL;
> + parent = of_f
Re: [PATCH 5/8] powerpc/pseries: do all node initialization in dlpar_parse_cc_node
On 08/15/2013 12:23 AM, Tyrel Datwyler wrote:
> Currently the OF_DYNAMIC and kref initialization for a node happens in
> dlpar_attach_node. However, a node passed to dlpar_attach_node may be a tree
> containing child nodes, and no initialization traversal is done on the
> tree. Since the children never get their kref initialized or the OF_DYNAMIC
> flag set these nodes are prevented from ever being released from memory
> should they become detached. This initialization step is better done at the
> time each node is allocated in dlpar_parse_cc_node.
>
> Signed-off-by: Tyrel Datwyler
Acked-by: Nathan Fontenot
> ---
> arch/powerpc/platforms/pseries/dlpar.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/dlpar.c
> b/arch/powerpc/platforms/pseries/dlpar.c
> index a1a7b9a..c855233 100644
> --- a/arch/powerpc/platforms/pseries/dlpar.c
> +++ b/arch/powerpc/platforms/pseries/dlpar.c
> @@ -83,6 +83,9 @@ static struct device_node *dlpar_parse_cc_node(struct
> cc_workarea *ccwa)
> return NULL;
> }
>
> + of_node_set_flag(dn, OF_DYNAMIC);
> + kref_init(&dn->kref);
> +
> return dn;
> }
>
> @@ -256,8 +259,6 @@ int dlpar_attach_node(struct device_node *dn)
> {
> int rc;
>
> - of_node_set_flag(dn, OF_DYNAMIC);
> - kref_init(&dn->kref);
> dn->parent = derive_parent(dn->full_name);
> if (!dn->parent)
> return -ENOMEM;
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/8] powerpc/pseries: fix parsing of initial node path in update_dt_node
On 08/15/2013 12:23 AM, Tyrel Datwyler wrote:
> On the first call to ibm,update-properties for a node the first property
> returned is the full node path. Currently this is not parsed correctly by the
> update_dt_node function. Commit 2e9b7b0 attempted to fix this, but was
> incorrect as it made a wrong assumption about the layout of the first
> property in the work area. Further, if ibm,update-properties must be called
> multiple times for the same node this special property should only be skipped
> after the initial call. The first property descriptor returned consists of
> the property name, property value length, and property value. The property
> name is an empty string, property length is encoded in 4 byte integer, and
> the property value is the node path.
>
> Signed-off-by: Tyrel Datwyler
Acked-by: Nathan Fontenot
> ---
> arch/powerpc/platforms/pseries/mobility.c | 21 +++--
> 1 file changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/mobility.c
> b/arch/powerpc/platforms/pseries/mobility.c
> index 023e354..ed5426f 100644
> --- a/arch/powerpc/platforms/pseries/mobility.c
> +++ b/arch/powerpc/platforms/pseries/mobility.c
> @@ -161,18 +161,19 @@ static int update_dt_node(u32 phandle, s32 scope)
>
> prop_data = rtas_buf + sizeof(*upwa);
>
> - /* The first element of the buffer is the path of the node
> - * being updated in the form of a 8 byte string length
> - * followed by the string. Skip past this to get to the
> - * properties being updated.
> + /* On the first call to ibm,update-properties for a node the
> + * the first property value descriptor contains an empty
> + * property name, the property value length encoded as u32,
> + * and the property value is the node path being updated.
>*/
> - vd = *prop_data++;
> - prop_data += vd;
> + if (*prop_data == 0) {
> + prop_data++;
> + vd = *(u32 *)prop_data;
> + prop_data += vd + sizeof(vd);
> + upwa->nprops--;
> + }
>
> - /* The path we skipped over is counted as one of the elements
> - * returned so start counting at one.
> - */
> - for (i = 1; i < upwa->nprops; i++) {
> + for (i = 0; i < upwa->nprops; i++) {
> char *prop_name;
>
> prop_name = prop_data;
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/8] powerpc/pseries: pack update_props_workarea to map correctly to rtas buffer header
On 08/15/2013 12:23 AM, Tyrel Datwyler wrote:
> The work area buffer returned by the ibm,update-properties rtas call contains
> 20 bytes of header information prior to the property value descriptor data.
> Currently update_dt_node tries to advance over this header using sizeof(upwa).
> The update_props_workarea struct contains 20 bytes worth of fields, that map
> to the relevant header data, but the sizeof the structure is 24 bytes due to
> 4 bytes of padding at the end of the structure. Packing the structure ensures
> that we don't advance too far over the rtas buffer.
>
> Signed-off-by: Tyrel Datwyler
Acked-by: Nathan Fontenot
> ---
> arch/powerpc/platforms/pseries/mobility.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/pseries/mobility.c
> b/arch/powerpc/platforms/pseries/mobility.c
> index aaae85d..023e354 100644
> --- a/arch/powerpc/platforms/pseries/mobility.c
> +++ b/arch/powerpc/platforms/pseries/mobility.c
> @@ -28,7 +28,7 @@ struct update_props_workarea {
> u32 state;
> u64 reserved;
> u32 nprops;
> -};
> +} __packed;
>
> #define NODE_ACTION_MASK 0xff00
> #define NODE_COUNT_MASK 0x00ff
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/8] powerpc/pseries: fix over writing of rtas return code in update_dt_node
On 08/15/2013 12:23 AM, Tyrel Datwyler wrote:
> The rc variable is initially used to store the return code from the
> ibm,update-properties rtas call which returns 0 or 1 on success. A return
> code of 1 indicates that ibm,update-properties must be called again for the
> node. However, the rc variable is overwritten by a call to update_dt_prop
> which returns 0 on success. This results in ibm,update-properties not being
> called again for the given node when the rtas call rc was previously 1.
>
> Signed-off-by: Tyrel Datwyler
Acked-by: Nathan Fontenot
> ---
> arch/powerpc/platforms/pseries/mobility.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/mobility.c
> b/arch/powerpc/platforms/pseries/mobility.c
> index f28abee..aaae85d 100644
> --- a/arch/powerpc/platforms/pseries/mobility.c
> +++ b/arch/powerpc/platforms/pseries/mobility.c
> @@ -130,7 +130,7 @@ static int update_dt_node(u32 phandle, s32 scope)
> struct update_props_workarea *upwa;
> struct device_node *dn;
> struct property *prop = NULL;
> - int i, rc;
> + int i, rc, rtas_rc;
> char *prop_data;
> char *rtas_buf;
> int update_properties_token;
> @@ -154,9 +154,9 @@ static int update_dt_node(u32 phandle, s32 scope)
> upwa->phandle = phandle;
>
> do {
> - rc = mobility_rtas_call(update_properties_token, rtas_buf,
> + rtas_rc = mobility_rtas_call(update_properties_token, rtas_buf,
> scope);
> - if (rc < 0)
> + if (rtas_rc < 0)
> break;
>
> prop_data = rtas_buf + sizeof(*upwa);
> @@ -202,7 +202,7 @@ static int update_dt_node(u32 phandle, s32 scope)
> prop_data += vd;
> }
> }
> - } while (rc == 1);
> + } while (rtas_rc == 1);
>
> of_node_put(dn);
> kfree(rtas_buf);
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/8] powerpc/pseries: fix creation of loop in device node property list
On 08/15/2013 12:23 AM, Tyrel Datwyler wrote:
> The update_dt_prop helper function fails to set the IN/OUT parameter prop to
> NULL after a complete property has been parsed from the work area returned by
> the ibm,update-properties rtas function. This results in the property list of
> the device node being updated is corrupted and becomes a loop since the same
> property structure is used repeatedly.
>
> Signed-off-by: Tyrel Datwyler
Acked-by: Nathan Fontenot
> ---
> arch/powerpc/platforms/pseries/mobility.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/pseries/mobility.c
> b/arch/powerpc/platforms/pseries/mobility.c
> index 3d01eee..f28abee 100644
> --- a/arch/powerpc/platforms/pseries/mobility.c
> +++ b/arch/powerpc/platforms/pseries/mobility.c
> @@ -119,7 +119,7 @@ static int update_dt_property(struct device_node *dn,
> struct property **prop,
>
> if (!more) {
> of_update_property(dn, new_prop);
> - new_prop = NULL;
> + *prop = NULL;
> }
>
> return 0;
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 4/4] of: move of_get_cpu_node implementation to DT core library
On 19/08/13 14:11, Rob Herring wrote:
> On 08/16/2013 12:39 PM, Sudeep KarkadaNagesha wrote:
>> From: Sudeep KarkadaNagesha
>>
>> This patch moves the generalized implementation of of_get_cpu_node from
>> PowerPC to DT core library, thereby adding support for retrieving cpu
>> node for a given logical cpu index on any architecture.
>>
>> The CPU subsystem can now use this function to assign of_node in the
>> cpu device while registering CPUs.
>>
>> It is recommended to use these helper function only in pre-SMP/early
>> initialisation stages to retrieve CPU device node pointers in logical
>> ordering. Once the cpu devices are registered, it can be retrieved easily
>> from cpu device of_node which avoids unnecessary parsing and matching.
>>
>> Cc: Rob Herring
>> Cc: Grant Likely
>> Cc: Benjamin Herrenschmidt
>> Signed-off-by: Sudeep KarkadaNagesha
>
> [snip]
>
>> +/**
>> + * of_get_cpu_node - Get device node associated with the given logical CPU
>> + *
>> + * @cpu: CPU number(logical index) for which device node is required
>> + * @thread: if not NULL, local thread number within the physical core is
>> + * returned
>> + *
>> + * The main purpose of this function is to retrieve the device node for the
>> + * given logical CPU index. It should be used to initialize the of_node in
>> + * cpu device. Once of_node in cpu device is populated, all the further
>> + * references can use that instead.
>> + *
>> + * CPU logical to physical index mapping is architecture specific and is
>> built
>> + * before booting secondary cores. This function uses arch_match_cpu_phys_id
>> + * which can be overridden by architecture specific implementation.
>> + *
>> + * Returns a node pointer for the logical cpu if found, else NULL.
>> + */
>> +struct device_node *of_get_cpu_node(int cpu, unsigned int *thread)
>> +{
>> +struct device_node *cpun, *cpus;
>> +
>> +cpus = of_find_node_by_path("/cpus");
>> +if (!cpus) {
>> +pr_warn("Missing cpus node, bailing out\n");
>> +return NULL;
>> +}
>> +
>> +for_each_child_of_node(cpus, cpun) {
>> +if (of_node_cmp(cpun->type, "cpu"))
>> +continue;
>> +#ifdef CONFIG_PPC
>
> You don't really need this ifdef as this function should never succeed
> on other arches. Alternatively, you can use "IS_ENABLED(CONFIG_PPC)"
> instead.
>
Agreed, I can remove it as long as no other architecture use that
property. It's just to avoid checking for it on other architectures.
I will use IS_ENABLED as you suggested.
> Otherwise,
>
> Acked-by: Rob Herring
>
Thanks.
Regards,
Sudeep
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] i2c: move of helpers into the core
I2C of helpers used to live in of_i2c.c but experience (from SPI) shows that it is much cleaner to have this in the core. This also removes a circular dependency between the helpers and the core, and so we can finally register child nodes in the core instead of doing this manually in each driver. So, fix the drivers and documentation, too. Signed-off-by: Wolfram Sang --- Documentation/acpi/enumeration.txt |1 - drivers/i2c/busses/i2c-at91.c |3 - drivers/i2c/busses/i2c-cpm.c|6 -- drivers/i2c/busses/i2c-davinci.c|2 - drivers/i2c/busses/i2c-designware-platdrv.c |2 - drivers/i2c/busses/i2c-gpio.c |3 - drivers/i2c/busses/i2c-i801.c |2 - drivers/i2c/busses/i2c-ibm_iic.c|4 - drivers/i2c/busses/i2c-imx.c|3 - drivers/i2c/busses/i2c-mpc.c|2 - drivers/i2c/busses/i2c-mv64xxx.c|3 - drivers/i2c/busses/i2c-mxs.c|3 - drivers/i2c/busses/i2c-nomadik.c|3 - drivers/i2c/busses/i2c-ocores.c |3 - drivers/i2c/busses/i2c-octeon.c |3 - drivers/i2c/busses/i2c-omap.c |3 - drivers/i2c/busses/i2c-pnx.c|3 - drivers/i2c/busses/i2c-powermac.c |9 +- drivers/i2c/busses/i2c-pxa.c|2 - drivers/i2c/busses/i2c-s3c2410.c|2 - drivers/i2c/busses/i2c-sh_mobile.c |2 - drivers/i2c/busses/i2c-sirf.c |3 - drivers/i2c/busses/i2c-stu300.c |2 - drivers/i2c/busses/i2c-tegra.c |3 - drivers/i2c/busses/i2c-versatile.c |2 - drivers/i2c/busses/i2c-wmt.c|3 - drivers/i2c/busses/i2c-xiic.c |3 - drivers/i2c/i2c-core.c | 107 - drivers/i2c/i2c-mux.c |3 - drivers/i2c/muxes/i2c-arb-gpio-challenge.c |1 - drivers/i2c/muxes/i2c-mux-gpio.c|1 - drivers/i2c/muxes/i2c-mux-pinctrl.c |1 - drivers/media/platform/exynos4-is/fimc-is-i2c.c |3 - drivers/of/Kconfig |6 -- drivers/of/Makefile |1 - drivers/of/of_i2c.c | 114 --- include/linux/i2c.h | 20 include/linux/of_i2c.h | 46 - 38 files changed, 130 insertions(+), 253 deletions(-) delete mode 100644 drivers/of/of_i2c.c delete mode 100644 include/linux/of_i2c.h diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt index d9be7a9..958266e 100644 --- a/Documentation/acpi/enumeration.txt +++ b/Documentation/acpi/enumeration.txt @@ -238,7 +238,6 @@ An I2C bus (controller) driver does: if (ret) /* handle error */ - of_i2c_register_devices(adapter); /* Enumerate the slave devices behind this bus via ACPI */ acpi_i2c_register_devices(adapter); diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c index 6bb839b..fd05930 100644 --- a/drivers/i2c/busses/i2c-at91.c +++ b/drivers/i2c/busses/i2c-at91.c @@ -28,7 +28,6 @@ #include #include #include -#include #include #include #include @@ -775,8 +774,6 @@ static int at91_twi_probe(struct platform_device *pdev) return rc; } - of_i2c_register_devices(&dev->adapter); - dev_info(dev->dev, "AT91 i2c bus driver.\n"); return 0; } diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c index 2e1f7eb..b2b8aa9 100644 --- a/drivers/i2c/busses/i2c-cpm.c +++ b/drivers/i2c/busses/i2c-cpm.c @@ -42,7 +42,6 @@ #include #include #include -#include #include #include @@ -681,11 +680,6 @@ static int cpm_i2c_probe(struct platform_device *ofdev) dev_dbg(&ofdev->dev, "hw routines for %s registered.\n", cpm->adap.name); - /* -* register OF I2C devices -*/ - of_i2c_register_devices(&cpm->adap); - return 0; out_shut: cpm_i2c_shutdown(cpm); diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c index fa55605..62be3b3 100644 --- a/drivers/i2c/busses/i2c-davinci.c +++ b/drivers/i2c/busses/i2c-davinci.c @@ -38,7 +38,6 @@ #include #include #include -#include #include #include @@ -728,7 +727,6 @@ static int davinci_i2c_probe(struct platform_device *pdev) dev_err(&pdev->dev, "failure adding adapter\n"); goto err_unuse_clocks; } - of_i2c_register_devices(adap); return 0; diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c index 4c5fada.
[PATCH] i2c: powermac: fix return path on error
We want to bail out immediately if i2c_add_adapter failed and not try to
register child nodes with a nilled adapter structure.
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-powermac.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-powermac.c
b/drivers/i2c/busses/i2c-powermac.c
index 8dc90da..bb81773 100644
--- a/drivers/i2c/busses/i2c-powermac.c
+++ b/drivers/i2c/busses/i2c-powermac.c
@@ -446,6 +446,7 @@ static int i2c_powermac_probe(struct platform_device *dev)
printk(KERN_ERR "i2c-powermac: Adapter %s registration "
"failed\n", adapter->name);
memset(adapter, 0, sizeof(*adapter));
+ return rc;
}
printk(KERN_INFO "PowerMac i2c bus %s registered\n", adapter->name);
@@ -455,7 +456,7 @@ static int i2c_powermac_probe(struct platform_device *dev)
*/
i2c_powermac_register_devices(adapter, bus);
- return rc;
+ return 0;
}
static struct platform_driver i2c_powermac_driver = {
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 4/4] of: move of_get_cpu_node implementation to DT core library
On 08/16/2013 12:39 PM, Sudeep KarkadaNagesha wrote:
> From: Sudeep KarkadaNagesha
>
> This patch moves the generalized implementation of of_get_cpu_node from
> PowerPC to DT core library, thereby adding support for retrieving cpu
> node for a given logical cpu index on any architecture.
>
> The CPU subsystem can now use this function to assign of_node in the
> cpu device while registering CPUs.
>
> It is recommended to use these helper function only in pre-SMP/early
> initialisation stages to retrieve CPU device node pointers in logical
> ordering. Once the cpu devices are registered, it can be retrieved easily
> from cpu device of_node which avoids unnecessary parsing and matching.
>
> Cc: Rob Herring
> Cc: Grant Likely
> Cc: Benjamin Herrenschmidt
> Signed-off-by: Sudeep KarkadaNagesha
[snip]
> +/**
> + * of_get_cpu_node - Get device node associated with the given logical CPU
> + *
> + * @cpu: CPU number(logical index) for which device node is required
> + * @thread: if not NULL, local thread number within the physical core is
> + * returned
> + *
> + * The main purpose of this function is to retrieve the device node for the
> + * given logical CPU index. It should be used to initialize the of_node in
> + * cpu device. Once of_node in cpu device is populated, all the further
> + * references can use that instead.
> + *
> + * CPU logical to physical index mapping is architecture specific and is
> built
> + * before booting secondary cores. This function uses arch_match_cpu_phys_id
> + * which can be overridden by architecture specific implementation.
> + *
> + * Returns a node pointer for the logical cpu if found, else NULL.
> + */
> +struct device_node *of_get_cpu_node(int cpu, unsigned int *thread)
> +{
> + struct device_node *cpun, *cpus;
> +
> + cpus = of_find_node_by_path("/cpus");
> + if (!cpus) {
> + pr_warn("Missing cpus node, bailing out\n");
> + return NULL;
> + }
> +
> + for_each_child_of_node(cpus, cpun) {
> + if (of_node_cmp(cpun->type, "cpu"))
> + continue;
> +#ifdef CONFIG_PPC
You don't really need this ifdef as this function should never succeed
on other arches. Alternatively, you can use "IS_ENABLED(CONFIG_PPC)"
instead.
Otherwise,
Acked-by: Rob Herring
Rob
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 3/4] powerpc: refactor of_get_cpu_node to support other architectures
On 08/19/2013 05:19 AM, Mark Rutland wrote:
> On Sat, Aug 17, 2013 at 11:09:36PM +0100, Benjamin Herrenschmidt wrote:
>> On Sat, 2013-08-17 at 12:50 +0200, Tomasz Figa wrote:
>>> I wonder how would this handle uniprocessor ARM (pre-v7) cores, for
>>> which
>>> the updated bindings[1] define #address-cells = <0> and so no reg
>>> property.
>>>
>>> [1] - http://thread.gmane.org/gmane.linux.ports.arm.kernel/260795
>>
>> Why did you do that in the binding ? That sounds like looking to create
>> problems ...
>>
>> Traditionally, UP setups just used "0" as the "reg" property on other
>> architectures, why do differently ?
>
> The decision was taken because we defined our reg property to refer to
> the MPIDR register's Aff{2,1,0} bitfields, and on UP cores before v7
> there's no MPIDR register at all. Given there can only be a single CPU
> in that case, describing a register that wasn't present didn't seem
> necessary or helpful.
What exactly reg represents is up to the binding definition, but it
still should be present IMO. I don't see any issue with it being
different for pre-v7.
Rob
>
> Thanks,
> Mark.
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: add the missing required isync for the coherent icache flush
On Mon, 2013-08-19 at 19:50 +0800, Kevin Hao wrote: > On Mon, Aug 19, 2013 at 01:37:17PM +1000, Benjamin Herrenschmidt wrote: > > On Mon, 2013-08-19 at 13:36 +1000, Benjamin Herrenschmidt wrote: > > > > > The semantic of this function is to make data executable. Even if the > > > implementation has a snooping icache, it *still* needs to make sure > > > prefetched code is tossed out of the pipeline which is what isync > > > should provide. > > > > > > The architecture actually specifies that. > > > > In fact, on P5 and later, I think we are supposed to do a single dummy > > icbi followed by sync and isync. > > Do you mean something like this? But why? It has to do with making sure prefetched and/or speculated instructions are properly tossed. My understanding is that icbi basically tells the ifetch buffers to drop it, sync orders the icbi and isync ensures its execution has been synchronized. At least I *think* that's the required sequence, I have to dbl check the arch, maybe tomorrow. I wouldn't be surprise if we also need a sync before the icbi to order the actual stores to memory that might have modified instructions with the icbi. Cheers, Ben. > diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S > index d74fefb..8fcdec7 100644 > --- a/arch/powerpc/kernel/misc_64.S > +++ b/arch/powerpc/kernel/misc_64.S > @@ -69,6 +69,8 @@ PPC64_CACHES: > > _KPROBE(flush_icache_range) > BEGIN_FTR_SECTION > + icbi0,r3 > + sync > isync > blr > END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE) > @@ -209,6 +211,8 @@ _GLOBAL(flush_inval_dcache_range) > */ > _GLOBAL(__flush_dcache_icache) > BEGIN_FTR_SECTION > + icbi0,r3 > + sync > isync > blr > END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE) > > Thanks, > Kevin > > > > > Cheers, > > Ben. > > > > > Cheers, > > > Ben. > > > > > > > > blr > > > > > END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE) > > > > > rlwinm r3,r3,0,0,31-PAGE_SHIFT /* Get page base address > > > > > */ > > > > > @@ -474,6 +475,7 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_44x) > > > > > */ > > > > > _GLOBAL(__flush_dcache_icache_phys) > > > > > BEGIN_FTR_SECTION > > > > > + isync > > > > > blr /* for 601, do nothing > > > > > */ > > > > > END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE) > > > > > mfmsr r10 > > > > > diff --git a/arch/powerpc/kernel/misc_64.S > > > > > b/arch/powerpc/kernel/misc_64.S > > > > > index 992a78e..d74fefb 100644 > > > > > --- a/arch/powerpc/kernel/misc_64.S > > > > > +++ b/arch/powerpc/kernel/misc_64.S > > > > > @@ -69,6 +69,7 @@ PPC64_CACHES: > > > > > > > > > > _KPROBE(flush_icache_range) > > > > > BEGIN_FTR_SECTION > > > > > + isync > > > > > blr > > > > > END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE) > > > > > /* > > > > > -- > > > > > 1.8.3.1 > > > > > > > > > > ___ > > > > > Linuxppc-dev mailing list > > > > > Linuxppc-dev@lists.ozlabs.org > > > > > https://lists.ozlabs.org/listinfo/linuxppc-dev > > > > > > > > > > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
Hi Nicolas,
Some misc other comments inline.
On Mon, Aug 19, 2013 at 08:08:48PM +0800, Nicolin Chen wrote:
> This patch implements a device-tree-only CPU DAI driver for Freescale
> +
> +struct fsl_spdif_priv {
> + struct spdif_mixer_control fsl_spdif_control;
> + struct snd_soc_dai_driver cpu_dai_drv;
> + struct platform_device *pdev;
> + struct regmap *regmap;
> + atomic_t dpll_locked;
You don't need an atomic_t to track a bool variable. Use a plain bool or
int instead.
> + u8 txclk_div[SPDIF_TXRATE_MAX];
> + u8 txclk_src[SPDIF_TXRATE_MAX];
> + u8 rxclk_src;
> + struct clk *txclk[SPDIF_TXRATE_MAX];
> + struct clk *rxclk;
> + struct snd_dmaengine_dai_dma_data dma_params_tx;
> + struct snd_dmaengine_dai_dma_data dma_params_rx;
> +
> + /* The name space will be allocated dynamically */
> + char name[0];
> +};
> +
> +
> +#ifdef DEBUG
> +static void dumpregs(struct fsl_spdif_priv *spdif_priv)
> +{
> + struct regmap *regmap = spdif_priv->regmap;
> + struct platform_device *pdev = spdif_priv->pdev;
> + u32 val, i;
> + int ret;
> +
> + /* Valid address set of SPDIF is {[0x0-0x38], 0x44, 0x50} */
> + for (i = 0 ; i <= REG_SPDIF_STC; i += 4) {
> + ret = regmap_read(regmap, REG_SPDIF_SCR + i, &val);
> + if (!ret)
> + dev_dbg(&pdev->dev, "REG 0x%02x = 0x%06x\n", i, val);
> + }
> +}
> +#else
> +static void dumpregs(struct fsl_spdif_priv *spdif_priv) {}
> +#endif
Is this needed? regmap provides a register dump in debugfs.
> +
> +static int spdif_clk_set_rate(struct clk *clk, unsigned long rate)
> +{
> + unsigned long rate_actual;
> +
> + rate_actual = clk_round_rate(clk, rate);
> + return clk_set_rate(clk, rate_actual);
> +}
clk_round_rate returns the rate which clk_set_rate would set if called
with the same rate. The clk_round_rate() is unnecessary.
> +
> + dev_dbg(&pdev->dev, "expected clock rate = %d\n",
> + (int)(64 * sample_rate * div));
> + dev_dbg(&pdev->dev, "acutal clock rate = %d\n",
> + (int)clk_get_rate(spdif_priv->txclk[rate]));
s/acutal/actual/
Also please use %ld instead of casting the unsigned long to int.
> +
> + dev_dbg(&pdev->dev, "FreqMeas: %d\n", (int)freqmeas);
> + dev_dbg(&pdev->dev, "BusclkFreq: %d\n", (int)busclk_freq);
> + dev_dbg(&pdev->dev, "RxRate: %d\n", (int)tmpval64);
Get rid of the casts
> +
> + spdif_priv = devm_kzalloc(&pdev->dev,
> + sizeof(struct fsl_spdif_priv) + strlen(np->name) + 1,
> GFP_KERNEL);
> + if (!spdif_priv) {
> + dev_err(&pdev->dev, "could not allocate DAI object\n");
Please drop this message. You'll never see it.
> +
> + for (i = 0; i < SPDIF_TXRATE_MAX; i++) {
> + ret = fsl_spdif_probe_txclk(spdif_priv, i);
> + if (ret)
> + return ret;
> + }
> +
> + /* Prepare rx/tx clock */
> + clk_prepare(spdif_priv->rxclk);
> + for (i = 0; i < SPDIF_TXRATE_MAX; i++)
> + clk_prepare(spdif_priv->txclk[i]);
Why do you prepare all clocks instead of the one you actually use? Also,
no need to do this here. You can use clk_prepare_enable instead where
you have clk_enable now.
> +
> +/* SPDIF rx clock source */
> +enum spdif_rxclk_src {
> + SRPC_CLKSRC_0 = 0,
> + SRPC_CLKSRC_1,
> + SRPC_CLKSRC_2,
> + SRPC_CLKSRC_3,
> + SRPC_CLKSRC_4,
> + SRPC_CLKSRC_5,
> + SRPC_CLKSRC_6,
> + SRPC_CLKSRC_7,
> + SRPC_CLKSRC_8,
> + SRPC_CLKSRC_9,
> + SRPC_CLKSRC_10,
> + SRPC_CLKSRC_11,
> + SRPC_CLKSRC_12,
> + SRPC_CLKSRC_13,
> + SRPC_CLKSRC_14,
> + SRPC_CLKSRC_15,
> +};
These are unused and look unnecessary.
> +
> +/* SPDIF tx clksrc */
> +enum spdif_txclk_src {
> + STC_TXCLK_SRC_0 = 0,
> + STC_TXCLK_SRC_1,
> + STC_TXCLK_SRC_2,
> + STC_TXCLK_SRC_3,
> + STC_TXCLK_SRC_4,
> + STC_TXCLK_SRC_5,
> + STC_TXCLK_SRC_6,
> + STC_TXCLK_SRC_7,
> +};
Also unused.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH][RFC] pci: fsl: rework PCIe driver compatible with Layerscape
The Freescale's Layerscape series processors will use ARM cores.
The LS1's PCIe controllers is the same as T4240's. So it's better
the PCIe controller driver can support PowerPC and ARM
simultaneously. This patch is for this purpose. It derives
the common functions from arch/powerpc/sysdev/fsl_pci.c to
drivers/pci/host/pcie-fsl.c and leaves several platform-dependent
functions which should be implemented in platform files.
Signed-off-by: Minghuan Lian
---
Based on upstream master 3.11-rc6
The function has been tested on P5020DS and P3041DS and T4240QDS boards
For mpc83xx and mpc86xx, I only did compile test.
arch/powerpc/Kconfig | 1 +
arch/powerpc/sysdev/fsl_pci.c | 591 ++
arch/powerpc/sysdev/fsl_pci.h | 91 --
drivers/edac/mpc85xx_edac.c | 10 -
drivers/pci/host/Kconfig | 4 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pcie-fsl.c | 734 ++
include/linux/fsl/fsl-pcie.h | 176 ++
8 files changed, 1008 insertions(+), 600 deletions(-)
create mode 100644 drivers/pci/host/pcie-fsl.c
create mode 100644 include/linux/fsl/fsl-pcie.h
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index dbd9d3c..66b51a8 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -671,6 +671,7 @@ config FSL_SOC
config FSL_PCI
bool
+ select PCIE_FSL if FSL_SOC_BOOKE || PPC_86xx
select PPC_INDIRECT_PCI
select PCI_QUIRKS
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 46ac1dd..a05a9e1 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -1,7 +1,7 @@
/*
* MPC83xx/85xx/86xx PCI/PCIE support routing.
*
- * Copyright 2007-2012 Freescale Semiconductor, Inc.
+ * Copyright 2007-2013 Freescale Semiconductor, Inc.
* Copyright 2008-2009 MontaVista Software, Inc.
*
* Initial author: Xianghua Xiao
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -54,60 +55,17 @@ static void quirk_fsl_pcie_header(struct pci_dev *dev)
return;
}
-static int fsl_indirect_read_config(struct pci_bus *, unsigned int,
- int, int, u32 *);
-
-static int fsl_pcie_check_link(struct pci_controller *hose)
-{
- u32 val = 0;
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID,
quirk_fsl_pcie_header);
- if (hose->indirect_type & PPC_INDIRECT_TYPE_FSL_CFG_REG_LINK) {
- if (hose->ops->read == fsl_indirect_read_config) {
- struct pci_bus bus;
- bus.number = 0;
- bus.sysdata = hose;
- bus.ops = hose->ops;
- indirect_read_config(&bus, 0, PCIE_LTSSM, 4, &val);
- } else
- early_read_config_dword(hose, 0, 0, PCIE_LTSSM, &val);
- if (val < PCIE_LTSSM_L0)
- return 1;
- } else {
- struct ccsr_pci __iomem *pci = hose->private_data;
- /* for PCIe IP rev 3.0 or greater use CSR0 for link state */
- val = (in_be32(&pci->pex_csr0) & PEX_CSR0_LTSSM_MASK)
- >> PEX_CSR0_LTSSM_SHIFT;
- if (val != PEX_CSR0_LTSSM_L0)
- return 1;
- }
+#if defined(CONFIG_FSL_SOC_BOOKE) || defined(CONFIG_PPC_86xx)
- return 0;
-}
+#define MAX_PHYS_ADDR_BITS 40
-static int fsl_indirect_read_config(struct pci_bus *bus, unsigned int devfn,
- int offset, int len, u32 *val)
+u64 fsl_pci64_dma_offset(void)
{
- struct pci_controller *hose = pci_bus_to_host(bus);
-
- if (fsl_pcie_check_link(hose))
- hose->indirect_type |= PPC_INDIRECT_TYPE_NO_PCIE_LINK;
- else
- hose->indirect_type &= ~PPC_INDIRECT_TYPE_NO_PCIE_LINK;
-
- return indirect_read_config(bus, devfn, offset, len, val);
+ return 1ull << MAX_PHYS_ADDR_BITS;
}
-#if defined(CONFIG_FSL_SOC_BOOKE) || defined(CONFIG_PPC_86xx)
-
-static struct pci_ops fsl_indirect_pcie_ops =
-{
- .read = fsl_indirect_read_config,
- .write = indirect_write_config,
-};
-
-#define MAX_PHYS_ADDR_BITS 40
-static u64 pci64_dma_offset = 1ull << MAX_PHYS_ADDR_BITS;
-
static int fsl_pci_dma_set_mask(struct device *dev, u64 dma_mask)
{
if (!dev->dma_mask || !dma_supported(dev, dma_mask))
@@ -121,300 +79,36 @@ static int fsl_pci_dma_set_mask(struct device *dev, u64
dma_mask)
if ((dev->bus == &pci_bus_type) &&
dma_mask >= DMA_BIT_MASK(MAX_PHYS_ADDR_BITS)) {
set_dma_ops(dev, &dma_direct_ops);
- set_dma_offset(dev, pci64_dma_offset);
+ set_dma_offset(dev, fsl_pci64_dma_offset());
}
*dev->dma_mask = dma_mask;
return 0;
}
-static int setup_one_atmu(struct ccsr_pci __iomem *pci,
- unsigned int index, const struct
[PATCH v4 2/7] net: ucc_geth: use platform_{get,set}_drvdata()
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &ofdev->dev,
so we can directly pass a struct platform_device.
Signed-off-by: Libo Chen
---
drivers/net/ethernet/freescale/ucc_geth.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c
b/drivers/net/ethernet/freescale/ucc_geth.c
index 3c43dac..533885c 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -3911,8 +3911,7 @@ static int ucc_geth_probe(struct platform_device* ofdev)
static int ucc_geth_remove(struct platform_device* ofdev)
{
- struct device *device = &ofdev->dev;
- struct net_device *dev = dev_get_drvdata(device);
+ struct net_device *dev = platform_get_drvdata(ofdev);
struct ucc_geth_private *ugeth = netdev_priv(dev);
unregister_netdev(dev);
--
1.7.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 0/7] net: use platform_{get,set}_drvdata()
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
so we can directly pass a struct platform_device.
changelog v4:
remove modify about happy_meal_pci_probe && happy_meal_pci_remove
changelog v3:
remove modify about dev_set_drvdata()
changelog v2:
this version add modify record about dev_set_drvdata().
Libo Chen (7):
net: fsl_pq_mdio: use platform_{get,set}_drvdata()
net: ucc_geth: use platform_{get,set}_drvdata()
net: fec_mpc52xx_phy: use platform_{get,set}_drvdata()
net: sunbmac: use platform_{get,set}_drvdata()
net: sunhme: use platform_{get,set}_drvdata()
net: xilinx_emaclite: use platform_{get,set}_drvdata()
net: davinci_mdio: use platform_{get,set}_drvdata()
drivers/net/ethernet/freescale/fec_mpc52xx_phy.c |3 +--
drivers/net/ethernet/freescale/fsl_pq_mdio.c |2 +-
drivers/net/ethernet/freescale/ucc_geth.c|3 +--
drivers/net/ethernet/sun/sunbmac.c |2 +-
drivers/net/ethernet/sun/sunhme.c|2 +-
drivers/net/ethernet/ti/davinci_mdio.c |3 +--
drivers/net/ethernet/xilinx/xilinx_emaclite.c|3 +--
7 files changed, 7 insertions(+), 11 deletions(-)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v8 2/2] ASoC: fsl: Add S/PDIF machine driver
This patch implements a device-tree-only machine driver for Freescale
i.MX series Soc. It works with spdif_transmitter/spdif_receiver and
fsl_spdif.c drivers.
Signed-off-by: Nicolin Chen
---
.../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 cd088cc..a708380 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -193,6 +193,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 && 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
+#include
+#include
+
+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
[PATCH v8 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
This patch implements a device-tree-only CPU DAI driver for Freescale
S/PDIF controller that supports stereo playback and record feature.
Signed-off-by: Nicolin Chen
---
.../devicetree/bindings/sound/fsl,spdif.txt| 54 +
sound/soc/fsl/Kconfig |3 +
sound/soc/fsl/Makefile |2 +
sound/soc/fsl/fsl_spdif.c | 1281
sound/soc/fsl/fsl_spdif.h | 224
5 files changed, 1564 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..f2ae335
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,spdif.txt
@@ -0,0 +1,54 @@
+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, must contain "fsl,imx35-spdif".
+
+ - reg : Offset and length of the register set for the device.
+
+ - interrupts : Contains the 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 : Contains an entry for each entry in clock-names.
+
+ - clock-names : Includes the following entries:
+ "core" The core clock of spdif controller
+ "rxtx<0-7>" Clock source list for tx and rx clock.
+ This clock list should be identical to
+ the source list connecting to the spdif
+ clock mux in "SPDIF Transceiver Clock
+ Diagram" of SoC reference manual. It
+ can also be referred to TxClk_Source
+ bit of register SPDIF_STC.
+
+Example:
+
+spdif: spdif@02004000 {
+ compatible = "fsl,imx35-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 3>,
+ <&clks 197>, <&clks 107>,
+ <&clks 0>, <&clks 118>,
+ <&clks 62>, <&clks 139>,
+ <&clks 0>;
+ clock-names = "core", "rxtx0",
+ "rxtx1", "rxtx2",
+ "rxtx3", "rxtx4",
+ "rxtx5", "rxtx6",
+ "rxtx7";
+
+ status = "okay";
+};
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 3a4808d..cd088cc 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..b7f97a3
--- /dev/null
+++ b/sound/soc/fsl/fsl_spdif.c
@@ -0,0 +1,1281 @@
+/*
+ * Freescale S/PDIF ALSA SoC Digital Audio Interface (DAI) driver
+ *
+ * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ *
+ * Based on stmp3xxx_spdif_dai.c
+ * Vladimir Barinov
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#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 INTR_FOR_CAPTURE (INT_SYM_ERR | INT_BIT_ERR | INT_URX_FUL |
INT_URX_OV|\
+ INT_QRX_FUL | INT_QRX_OV | INT_UQ_SYNC | INT_UQ_ERR |\
+ INT_RXFIFO_RESYNC | INT_LOSS_LOCK | INT_DPLL_LOCKED)
+
+/* Index list for the values that has if (DPLL Locked) condition */
[PATCH v8 0/2] Add freescale S/PDIF CPU DAI and machine drivers
Changelog: v7->v8: * Revised DT binding doc. * Revised dev_err() error msg. * Check return value of clk_set_rate(). v6->v7: * Removed extra comma in array. * Revised some comments. * Added some dev_err(). * Check the return value of soft reset. * Use bitrev8() instead of extra reverse_bits(). * Use cache_bypass as default for regmap. v5->v6: * Sorted out rxtx clk source in DT binding. * Use devm_() functions. * Use platform_get_resource() instead. v4->v5: * Dropped rx/tx-clksrc-names DT bindings. * Use standard clock binding instead to pass the clock source list. * Update the compatible list by using "imx35", the first SoC that has spdif. v3->v4: * Use regmap for CPU DAI driver. * Use individual clock source for 32KHz, 44KHz, 48KHz playback. * Determine clock source configuration from 'clocks' entry. * Added imx53 to compatible list, merged imx6q and imx6dl in the list. * Improve the algorism of reverse_bits(). * Dropped the unneeded clk_put(). 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| 54 + .../devicetree/bindings/sound/imx-audio-spdif.txt | 29 + sound/soc/fsl/Kconfig | 14 + sound/soc/fsl/Makefile |4 + sound/soc/fsl/fsl_spdif.c | 1281 sound/soc/fsl/fsl_spdif.h | 224 sound/soc/fsl/imx-spdif.c | 134 ++ 7 files changed, 1740 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
Re: [PATCH] powerpc: add the missing required isync for the coherent icache flush
On Mon, Aug 19, 2013 at 01:37:17PM +1000, Benjamin Herrenschmidt wrote: > On Mon, 2013-08-19 at 13:36 +1000, Benjamin Herrenschmidt wrote: > > > The semantic of this function is to make data executable. Even if the > > implementation has a snooping icache, it *still* needs to make sure > > prefetched code is tossed out of the pipeline which is what isync > > should provide. > > > > The architecture actually specifies that. > > In fact, on P5 and later, I think we are supposed to do a single dummy > icbi followed by sync and isync. Do you mean something like this? But why? diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S index d74fefb..8fcdec7 100644 --- a/arch/powerpc/kernel/misc_64.S +++ b/arch/powerpc/kernel/misc_64.S @@ -69,6 +69,8 @@ PPC64_CACHES: _KPROBE(flush_icache_range) BEGIN_FTR_SECTION + icbi0,r3 + sync isync blr END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE) @@ -209,6 +211,8 @@ _GLOBAL(flush_inval_dcache_range) */ _GLOBAL(__flush_dcache_icache) BEGIN_FTR_SECTION + icbi0,r3 + sync isync blr END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE) Thanks, Kevin > > Cheers, > Ben. > > > Cheers, > > Ben. > > > > > > blr > > > > END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE) > > > > rlwinm r3,r3,0,0,31-PAGE_SHIFT /* Get page base address > > > > */ > > > > @@ -474,6 +475,7 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_44x) > > > > */ > > > > _GLOBAL(__flush_dcache_icache_phys) > > > > BEGIN_FTR_SECTION > > > > + isync > > > > blr /* for 601, do nothing > > > > */ > > > > END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE) > > > > mfmsr r10 > > > > diff --git a/arch/powerpc/kernel/misc_64.S > > > > b/arch/powerpc/kernel/misc_64.S > > > > index 992a78e..d74fefb 100644 > > > > --- a/arch/powerpc/kernel/misc_64.S > > > > +++ b/arch/powerpc/kernel/misc_64.S > > > > @@ -69,6 +69,7 @@ PPC64_CACHES: > > > > > > > > _KPROBE(flush_icache_range) > > > > BEGIN_FTR_SECTION > > > > + isync > > > > blr > > > > END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE) > > > > /* > > > > -- > > > > 1.8.3.1 > > > > > > > > ___ > > > > Linuxppc-dev mailing list > > > > Linuxppc-dev@lists.ozlabs.org > > > > https://lists.ozlabs.org/listinfo/linuxppc-dev > > > > > > > pgpN2v5WaB7z1.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 2/2] ASoC: fsl: Add S/PDIF machine driver
On Mon, Aug 19, 2013 at 12:31:21PM +0100, Mark Rutland wrote: > On Mon, Aug 19, 2013 at 11:52:01AM +0100, Mark Brown wrote: > > This is intended to allow userspace to distinguish between systems that > > are electrically identical but physically distinct, for example when > > multiple systems are derived from the same reference design. > I see. Surely if there's some meaning imparted to userspace by the model > name, there's a contract there that we should document (the set of valid > model names and what they correspond to)? In theory I guess. In practice I doubt many people will bother and I'd expect zero productive result from those that do. > I'm not sure I understand why userspace needs to know what the system is > if we've adequately described how it's wired and what its capabilities > are. However, I'm not at all familiar with the way we handle audio, so > please forgive my naivety there :) The physical form of the system can have a substantial impact on how people want to configure it at runtime even if there is no software visible difference. Coefficients can be chosen to work with plastics, or volumes adjusted for expected user positioning with respect to the hardware for example. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
On Mon, Aug 19, 2013 at 12:13:49PM +0100, Mark Rutland wrote: > > > > > > + "rxtx<0-7>" Clock source list for tx and rx clock. > > > > > > + This clock list should be identical to > > > > > > + the source list connecting to the spdif > > > > > > + clock mux in "SPDIF Transceiver Clock > > > > > > + Diagram" of SoC reference manual. It > > > > > > + can also be referred to TxClk_Source > > > > > > + bit of register SPDIF_STC. > > Actually there's a clock mux for TxClk and it's connecting with 8 clock > > sources. So the TxClk_Source bit show the connection between its value > > with the correspond source on the clock mux: > > > > TxClk_Source000 XTAL clk input > > 001 CCM spdif0_clk_root input > > 010 asrc_clk input > > 011 spdif_extclk input, from pads > > 100 esai_hckt input > > 101 frequency divided ipg_clk input > > 110 mlb_clk input > > 111 mlb phy clk input > > Ah. So are these the actual input names on the mux, or the names of the > outputs that are wired up to the mux? If the former, these may be better > clock-names than rxtx<0-7>. The clock names are actually different with different SoC. The list above is only for i.MX6Q. So we can't specify these names here, because the driver then would need to maintain a clock names list for different SoC as well. > Is there a similar Rx mux? Both Tx and RX clocks can be derived from the Tx mux. > Given the "rxtx<0-7>" names you've given these clocks, are there 8 clock > inputs that get duplicated within the spdif block and fed into both > muxes, or are there 16 external inputs that happen to be two groups of 8 > identical sets of clocks in systems so far? I think you can refer to the RM, since you just got it. The diagram doesn't show which one you mentioned is true. But I think we can understand in both ways. I'm going to send a v8. So I think I don't need to modify the description right? Thank you Nicolin Chen ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 2/2] ASoC: fsl: Add S/PDIF machine driver
On Mon, Aug 19, 2013 at 11:52:01AM +0100, Mark Brown wrote: > On Mon, Aug 19, 2013 at 11:01:43AM +0100, Mark Rutland wrote: > > On Mon, Aug 19, 2013 at 10:50:43AM +0100, Nicolin Chen wrote: > > > > The phrase "user-visible" is being used in many current docs, I don't > > > dare to change it unless a sage gives me a suggestion. > > > I can see that there is entrenched usage, but this really seems to be > > embedding Linux-specific implementation details into the dt. I don't see > > why the driver cannot select a sensible name, but perhaps I'm missing > > something. > > > Mark, is there any reason we need to handle the user-visible name of the > > device this way? > > This is intended to allow userspace to distinguish between systems that > are electrically identical but physically distinct, for example when > multiple systems are derived from the same reference design. I see. Surely if there's some meaning imparted to userspace by the model name, there's a contract there that we should document (the set of valid model names and what they correspond to)? I'm not sure I understand why userspace needs to know what the system is if we've adequately described how it's wired and what its capabilities are. However, I'm not at all familiar with the way we handle audio, so please forgive my naivety there :) Thanks, Mark. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 2/2] ASoC: fsl: Add S/PDIF machine driver
On Mon, Aug 19, 2013 at 11:21:06AM +0100, Nicolin Chen wrote: > On Mon, Aug 19, 2013 at 11:01:43AM +0100, Mark Rutland wrote: > > > At least they are separate drivers as I mentioned in the commit comments. > > > > I'm not sure that the boundary of Linux drivers should necessarily > > determine the way we carve up the description of IP blocks, though > > presumably it's a pretty sensible way of carving it up or we wouldn't > > have done it. > > I'm not sure if I understand your point correctly. But in fact the IP driver > is not being carved up. The spdif-transmitter and spdif-receiver are basically > dummy codec drivers. All the IP-related codes are implemented in fsl_spdif.c, > the PATCH 1/2 you just reviewed. I see. Sorry for the noise there, that's an artifact of my not full understanding of the ASoC bindings. > > > Is there any public documentation on the i.MX S/PDIF hardware block(s)? > > http://cache.freescale.com/files/32bit/doc/ref_manual/IMX6DQRM.pdf > Cheers! Mark. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
On Mon, Aug 19, 2013 at 11:13:04AM +0100, Nicolin Chen wrote: > On Mon, Aug 19, 2013 at 10:54:33AM +0100, Mark Rutland wrote: > > > I see, so 'Compatible list, must contains "fsl,imx35-spdif"' would be > > > okay? > > > > While that needs to be mentioned, other values which might be present > > (e.g. "fsl,imx6q-spdif") must be mentioned, or we can't rely on them > > if we want to use them in future from drivers to provide additional > > information (and thus they're useless). > > Well, imx6q-spdif is identical to the imx35-spdif. So I think the > 'must contains 35' would be enough for the current case. If any > future modification happens to the list, I can update this doc later. > > > > > > > > > + - interrupts : Contains spdif interrupt. > > > > > > > > Is that the only interrupt the device generates? > > > > > > Yes, how could I improve this description? > > > > It's probably not possible to make it much clearar to be honest, > > "Contains the sole interrupt generated by the device" might be a little > > overkill. > > Then I keep it no-change :) Ok :) > > > > > > > + "rxtx<0-7>" Clock source list for tx and rx clock. > > > > > + This clock list should be identical to > > > > > + the source list connecting to the spdif > > > > > + clock mux in "SPDIF Transceiver Clock > > > > > + Diagram" of SoC reference manual. It > > > > > + can also be referred to TxClk_Source > > > > > + bit of register SPDIF_STC. > > > > The list is also identical to the TxClk_Source bit value list of > > > register SPDIF_STC. > > > > What I don't understand is how the value of the SPDIF_STC register > > within the spdif IP block can describe the necessary details of clocks > > coming from an external clock provider. > > > > What do the TxClk_Source bits represent? The configuration of the clock > > inputs on the spdif IP block, or the outputs on some clock provider? Are > > they writeable, or configured at integration time? If the clock provider > > were replaced with another arbitrary clock provider, what would they > > represent? > > > Actually there's a clock mux for TxClk and it's connecting with 8 clock > sources. So the TxClk_Source bit show the connection between its value > with the correspond source on the clock mux: > > TxClk_Source 000 XTAL clk input > 001 CCM spdif0_clk_root input > 010 asrc_clk input > 011 spdif_extclk input, from pads > 100 esai_hckt input > 101 frequency divided ipg_clk input > 110 mlb_clk input > 111 mlb phy clk input Ah. So are these the actual input names on the mux, or the names of the outputs that are wired up to the mux? If the former, these may be better clock-names than rxtx<0-7>. Is there a similar Rx mux? Given the "rxtx<0-7>" names you've given these clocks, are there 8 clock inputs that get duplicated within the spdif block and fed into both muxes, or are there 16 external inputs that happen to be two groups of 8 identical sets of clocks in systems so far? > > > > > I guess it's better to drop the 'imx6q-spdif' here? > > > > That depends: > > > > * If the two IP blocks are identical, only the "imx35-spdif" name is > > necessary, and we can forget about "fsl,imx6q-spdif". > > > > * If "fsl,imx6q-spdif" is a strict superset of "fsl,imx35-spdif", having > > both names documented and in a compatible list for a "fsl,imx6q-spdif" > > device makes sense. > > > > * If "fsl,imx6q-spdif" is a variation of "fsl,imx35-spdif", and the > > "fsl,imx6q-spdif" cannot always be treated identically to a > > "fsl,imx35-spdif", then it makes sense to have separate compatible > > strings, with a device being listed as either "fsl,imx6q-spdif" or > > "fsl,imx35-spdif". > > > > I don't know enough about the hardware to make that judgement call. > > Thank you for explaining! I will choose A, because they are internally > identical except their external clock sources. Ok, that sounds like the right course of action to me. Thanks, Mark. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 2/2] ASoC: fsl: Add S/PDIF machine driver
On Mon, Aug 19, 2013 at 11:01:43AM +0100, Mark Rutland wrote: > On Mon, Aug 19, 2013 at 10:50:43AM +0100, Nicolin Chen wrote: > > The phrase "user-visible" is being used in many current docs, I don't > > dare to change it unless a sage gives me a suggestion. > I can see that there is entrenched usage, but this really seems to be > embedding Linux-specific implementation details into the dt. I don't see > why the driver cannot select a sensible name, but perhaps I'm missing > something. > Mark, is there any reason we need to handle the user-visible name of the > device this way? This is intended to allow userspace to distinguish between systems that are electrically identical but physically distinct, for example when multiple systems are derived from the same reference design. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 2/2] ASoC: fsl: Add S/PDIF machine driver
Am Montag, den 19.08.2013, 11:01 +0100 schrieb Mark Rutland: > On Mon, Aug 19, 2013 at 10:50:43AM +0100, Nicolin Chen wrote: > > Hi, > > > > On Mon, Aug 19, 2013 at 10:24:58AM +0100, Mark Rutland wrote: > > > Is this used semantically, or is it a completely arbitrary string? In > > > either case I don't see why the compatible string doesn't give the > > > driver enough to have a sensible value. > > > > > > I'm confused as to why we need this. The phrase "user-visible" in a > > > device description seems very odd. > > > > The string would be in the ALSA device list: > > ALSA device list: > > #0: imx-spdif > > > > I think it can be a sort of arbitrary as long as users know which this > > device exactly is when they catch the name by 'aplay -l' or 'arecord -l' > > > > The phrase "user-visible" is being used in many current docs, I don't > > dare to change it unless a sage gives me a suggestion. > > I can see that there is entrenched usage, but this really seems to be > embedding Linux-specific implementation details into the dt. I don't see > why the driver cannot select a sensible name, but perhaps I'm missing > something. > > Mark, is there any reason we need to handle the user-visible name of the > device this way? > > > > > > > + > > > > + - 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. > > > > > > Are all four units (comlpex,controller,transmitter,receiver) really > > > separate blocks? > > > > At least they are separate drivers as I mentioned in the commit comments. > > I'm not sure that the boundary of Linux drivers should necessarily > determine the way we carve up the description of IP blocks, though > presumably it's a pretty sensible way of carving it up or we wouldn't > have done it. The transmitter and receiver can be real external codec devices with S/PDIF input or output pads connected to the i.MX S/PDIF. One example would be the Analog Devices ADV7612 HDMI receiver, which can output audio taken from HDMI input via S/PDIF (just as via I2S). The dummy codec devices are just needed if the S/PDIF pads are directly routed to externally accessible connectors. regards Philipp ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 2/2] ASoC: fsl: Add S/PDIF machine driver
On Mon, Aug 19, 2013 at 11:01:43AM +0100, Mark Rutland wrote: > > At least they are separate drivers as I mentioned in the commit comments. > > I'm not sure that the boundary of Linux drivers should necessarily > determine the way we carve up the description of IP blocks, though > presumably it's a pretty sensible way of carving it up or we wouldn't > have done it. I'm not sure if I understand your point correctly. But in fact the IP driver is not being carved up. The spdif-transmitter and spdif-receiver are basically dummy codec drivers. All the IP-related codes are implemented in fsl_spdif.c, the PATCH 1/2 you just reviewed. > Is there any public documentation on the i.MX S/PDIF hardware block(s)? http://cache.freescale.com/files/32bit/doc/ref_manual/IMX6DQRM.pdf Thank you, Nicolin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 4/4] of: move of_get_cpu_node implementation to DT core library
On 16/08/13 23:14, Benjamin Herrenschmidt wrote: > On Fri, 2013-08-16 at 18:39 +0100, Sudeep KarkadaNagesha wrote: >> +#ifdef CONFIG_PPC >> + /* Check for historical "ibm,ppc-interrupt-server#s" property >> +* for thread ids on PowerPC. If it doesn't exist fallback to >> +* standard "reg" property. >> +*/ >> + if (__of_find_n_match_cpu_property(cpun, >> + "ibm,ppc-interrupt-server#s", cpu, thread)) >> + return cpun; >> +#endif > > It's not "historical". It's still very much in use and well defined in PAPR > :-) > By historical, I meant it should not be used in future bindings. Ah, sorry missed it in ePAPR, because its not under CPU node section. What's more interesting is that ePAPR has it as an example for non-standard property names :) Can I mark it as custom/non-standard instead ? I mainly want to indicate that we need to use 'reg' property and not introduce any more custom properties for thread ids. Can I add your ACK with this comment fixed ? Regards, Sudeep ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 3/4] powerpc: refactor of_get_cpu_node to support other architectures
On Sat, Aug 17, 2013 at 11:09:36PM +0100, Benjamin Herrenschmidt wrote:
> On Sat, 2013-08-17 at 12:50 +0200, Tomasz Figa wrote:
> > I wonder how would this handle uniprocessor ARM (pre-v7) cores, for
> > which
> > the updated bindings[1] define #address-cells = <0> and so no reg
> > property.
> >
> > [1] - http://thread.gmane.org/gmane.linux.ports.arm.kernel/260795
>
> Why did you do that in the binding ? That sounds like looking to create
> problems ...
>
> Traditionally, UP setups just used "0" as the "reg" property on other
> architectures, why do differently ?
The decision was taken because we defined our reg property to refer to
the MPIDR register's Aff{2,1,0} bitfields, and on UP cores before v7
there's no MPIDR register at all. Given there can only be a single CPU
in that case, describing a register that wasn't present didn't seem
necessary or helpful.
Thanks,
Mark.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH V3 3/5] powerpc/cpuidle: Generic powerpc backend cpuidle driver.
Hi Dongsheng,
On 08/19/2013 11:22 AM, Wang Dongsheng-B40534 wrote:
> I think we should move the states and handle function to arch/power/platform*
> The states and handle function is belong to backend driver, not for this,
> different platform have different state.
> Different platforms to make their own deal with these states.
>
> I think we cannot put all the status of different platforms and handler in
> this driver.
The idea here is a single powerpc back-end driver, which does a runtime
detection of the platform it is running and choose the right
idle states table. This was one of outcome of V2 discussion.
I feel there is no harm in keeping the state information in the same
file. We do have x86, which has all its variants information in one
file. One place will have all the idle consolidated information of
all the platform variants. If community does feel, we need to
have just the states information in arch specific file, we can do so.
>> diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
>> index 0e2cd5c..99ee5d4 100644
>> --- a/drivers/cpuidle/Kconfig
>> +++ b/drivers/cpuidle/Kconfig
>> @@ -42,6 +42,13 @@ config CPU_IDLE_ZYNQ
>> help
>>Select this to enable cpuidle on Xilinx Zynq processors.
>>
>> +config CPU_IDLE_POWERPC
>> +bool "CPU Idle driver for POWERPC platforms"
>> +depends on PPC64
>
> Why not PPC?
PPC64 seems to a good place to began the consolidation work. This
patch-set has not been tested for PPC32 currently.
>
>> +default y
>> +help
>> + Select this option to enable processor idle state management
>> + for POWERPC platform.
>> endif
>>
>> config ARCH_NEEDS_CPU_IDLE_COUPLED
>> diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
>> index 8767a7b..d12e205 100644
>> --- a/drivers/cpuidle/Makefile
>> +++ b/drivers/cpuidle/Makefile
>> @@ -8,3 +8,5 @@ obj-$(CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED) += coupled.o
>> obj-$(CONFIG_CPU_IDLE_CALXEDA) += cpuidle-calxeda.o
>> obj-$(CONFIG_ARCH_KIRKWOOD) += cpuidle-kirkwood.o
>> obj-$(CONFIG_CPU_IDLE_ZYNQ) += cpuidle-zynq.o
>> +
>> +obj-$(CONFIG_CPU_IDLE_POWERPC) += cpuidle-powerpc.o
>> diff --git a/drivers/cpuidle/cpuidle-powerpc.c b/drivers/cpuidle/cpuidle-
>> powerpc.c
>> new file mode 100644
>> index 000..5756085
>> --- /dev/null
>> +++ b/drivers/cpuidle/cpuidle-powerpc.c
>> @@ -0,0 +1,361 @@
>> +/*
>> + * processor_idle - idle state cpuidle driver.
>> + * Adapted from drivers/idle/intel_idle.c and
>> + * drivers/acpi/processor_idle.c
>> + *
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +struct cpuidle_driver powerpc_idle_driver = {
>> +.name = "powerpc_idle",
>> +.owner= THIS_MODULE,
>> +};
>> +
>> +#define MAX_IDLE_STATE_COUNT2
>> +
>> +static int max_idle_state = MAX_IDLE_STATE_COUNT - 1;
> If this is a generic driver, do not define MAX_IDLE_STATE_COUNT, because we
> don't know how many state on other platforms.
>
> How about using ARRAY_SIZE to get the max idle state?
>
Yes, I do agree. We need a generic way to return the no of idle states.
>> +static struct cpuidle_device __percpu *powerpc_cpuidle_devices;
>> +static struct cpuidle_state *cpuidle_state_table;
>> +
> Should be remove all about *device*.
> If the notifier handle using device, you can use
> "cpuidle_devices"(include/linux/cpuidle.h).
The hotplug notifier has a dependency to the cpu device struct.
Yes, I agree using this is way to go forward. As outlined in the cover
cpuidle cleanups will be taken in subsequent versions.
>> +static inline void idle_loop_prolog(unsigned long *in_purr)
>> +{
>> +*in_purr = mfspr(SPRN_PURR);
>> +/*
>> + * Indicate to the HV that we are idle. Now would be
>> + * a good time to find other work to dispatch.
>> + */
>> +set_lppaca_idle(1);
>> +}
>> +
>> +static inline void idle_loop_epilog(unsigned long in_purr)
>> +{
>> +add_lppaca_wait_state(mfspr(SPRN_PURR) - in_purr);
>> +set_lppaca_idle(0);
>> +}
>> +
>> +static int snooze_loop(struct cpuidle_device *dev,
>> +struct cpuidle_driver *drv,
>> +int index)
>> +{
>> +unsigned long in_purr;
>> +
>> +idle_loop_prolog(&in_purr);
>> +local_irq_enable();
>> +set_thread_flag(TIF_POLLING_NRFLAG);
>> +
>> +while (!need_resched()) {
>> +ppc64_runlatch_off();
>> +HMT_low();
>> +HMT_very_low();
>> +}
>> +
>> +HMT_medium();
>> +clear_thread_flag(TIF_POLLING_NRFLAG);
>> +smp_mb();
>> +
>> +idle_loop_epilog(in_purr);
>> +
>> +return index;
>> +}
>> +
>> +static void check_and_cede_processor(void)
>> +{
>> +/*
>> + * Ensure our interrupt state is properly tracked,
>> + * also checks if no interrupt has occurred while we
>> + * were soft-disabled
>> + */
>>
Re: [PATCH v7 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
On Mon, Aug 19, 2013 at 10:54:33AM +0100, Mark Rutland wrote: > > I see, so 'Compatible list, must contains "fsl,imx35-spdif"' would be okay? > > While that needs to be mentioned, other values which might be present > (e.g. "fsl,imx6q-spdif") must be mentioned, or we can't rely on them > if we want to use them in future from drivers to provide additional > information (and thus they're useless). Well, imx6q-spdif is identical to the imx35-spdif. So I think the 'must contains 35' would be enough for the current case. If any future modification happens to the list, I can update this doc later. > > > > > > + - interrupts : Contains spdif interrupt. > > > > > > Is that the only interrupt the device generates? > > > > Yes, how could I improve this description? > > It's probably not possible to make it much clearar to be honest, > "Contains the sole interrupt generated by the device" might be a little > overkill. Then I keep it no-change :) > > > > + "rxtx<0-7>" Clock source list for tx and rx clock. > > > > + This clock list should be identical to > > > > + the source list connecting to the spdif > > > > + clock mux in "SPDIF Transceiver Clock > > > > + Diagram" of SoC reference manual. It > > > > + can also be referred to TxClk_Source > > > > + bit of register SPDIF_STC. > > The list is also identical to the TxClk_Source bit value list of > > register SPDIF_STC. > > What I don't understand is how the value of the SPDIF_STC register > within the spdif IP block can describe the necessary details of clocks > coming from an external clock provider. > > What do the TxClk_Source bits represent? The configuration of the clock > inputs on the spdif IP block, or the outputs on some clock provider? Are > they writeable, or configured at integration time? If the clock provider > were replaced with another arbitrary clock provider, what would they > represent? Actually there's a clock mux for TxClk and it's connecting with 8 clock sources. So the TxClk_Source bit show the connection between its value with the correspond source on the clock mux: TxClk_Source000 XTAL clk input 001 CCM spdif0_clk_root input 010 asrc_clk input 011 spdif_extclk input, from pads 100 esai_hckt input 101 frequency divided ipg_clk input 110 mlb_clk input 111 mlb phy clk input > > I guess it's better to drop the 'imx6q-spdif' here? > > That depends: > > * If the two IP blocks are identical, only the "imx35-spdif" name is > necessary, and we can forget about "fsl,imx6q-spdif". > > * If "fsl,imx6q-spdif" is a strict superset of "fsl,imx35-spdif", having > both names documented and in a compatible list for a "fsl,imx6q-spdif" > device makes sense. > > * If "fsl,imx6q-spdif" is a variation of "fsl,imx35-spdif", and the > "fsl,imx6q-spdif" cannot always be treated identically to a > "fsl,imx35-spdif", then it makes sense to have separate compatible > strings, with a device being listed as either "fsl,imx6q-spdif" or > "fsl,imx35-spdif". > > I don't know enough about the hardware to make that judgement call. Thank you for explaining! I will choose A, because they are internally identical except their external clock sources. Best regards, Nicolin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 3/4] powerpc: refactor of_get_cpu_node to support other architectures
On 16/08/13 23:13, Benjamin Herrenschmidt wrote:
> On Fri, 2013-08-16 at 18:39 +0100, Sudeep KarkadaNagesha wrote:
>> +static bool __of_find_n_match_cpu_property(struct device_node *cpun,
>> + const char *prop_name, int cpu, unsigned int
>> *thread)
>> +{
>> + const __be32 *cell;
>> + int ac, prop_len, tid;
>> + u64 hwid;
>> +
>> + ac = of_n_addr_cells(cpun);
>> + cell = of_get_property(cpun, prop_name, &prop_len);
>> + if (!cell)
>> + return false;
>> + prop_len /= sizeof(*cell);
>> + for (tid = 0; tid < prop_len; tid++) {
>> + hwid = of_read_number(cell, ac);
>> + if (arch_match_cpu_phys_id(cpu, hwid)) {
>> + if (thread)
>> + *thread = tid;
>> + return true;
>> + }
>> + cell += ac;
>> + }
>> + return false;
>> +}
>
> The only problem I can see here is if "ac" is not 1, that will not work
> for the ibm,ppc-interrupt-server#s case. IE. The latter is always 1 cell
> per entry, only "reg" depends on #address-cells.
>
> However that's only a theorical problem since on ppc #address-cells of
> /cpus is always 1...
>
Ok agreed, but I assume in future if thread ids need 2 ac, it would use
standard 'reg' instead of 'ibm,ppc-interrupt-server#' property.
So I assume the above function is generic and need not be modified to
handle non '1' ac case with non standard 'ibm,ppc-interrupt-server#'.
Regards,
Sudeep
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 2/2] ASoC: fsl: Add S/PDIF machine driver
On Mon, Aug 19, 2013 at 10:50:43AM +0100, Nicolin Chen wrote: > Hi, > > On Mon, Aug 19, 2013 at 10:24:58AM +0100, Mark Rutland wrote: > > Is this used semantically, or is it a completely arbitrary string? In > > either case I don't see why the compatible string doesn't give the > > driver enough to have a sensible value. > > > > I'm confused as to why we need this. The phrase "user-visible" in a > > device description seems very odd. > > The string would be in the ALSA device list: > ALSA device list: > #0: imx-spdif > > I think it can be a sort of arbitrary as long as users know which this > device exactly is when they catch the name by 'aplay -l' or 'arecord -l' > > The phrase "user-visible" is being used in many current docs, I don't > dare to change it unless a sage gives me a suggestion. I can see that there is entrenched usage, but this really seems to be embedding Linux-specific implementation details into the dt. I don't see why the driver cannot select a sensible name, but perhaps I'm missing something. Mark, is there any reason we need to handle the user-visible name of the device this way? > > > > + > > > + - 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. > > > > Are all four units (comlpex,controller,transmitter,receiver) really > > separate blocks? > > At least they are separate drivers as I mentioned in the commit comments. I'm not sure that the boundary of Linux drivers should necessarily determine the way we carve up the description of IP blocks, though presumably it's a pretty sensible way of carving it up or we wouldn't have done it. Is there any public documentation on the i.MX S/PDIF hardware block(s)? Thanks, Mark. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
On Mon, Aug 19, 2013 at 10:34:24AM +0100, Nicolin Chen wrote:
> Hi Mark,
>
>Thank you for the commenst. I'll Fix them in v8.
>
>Here are some remaining question:
>
> On Mon, Aug 19, 2013 at 10:18:09AM +0100, Mark Rutland wrote:
> > > +Required properties:
> > > +
> > > + - compatible : Compatible list, contains "fsl,-spdif".
> >
> > What are valid values for ? The binding should mention this. There
> > are bindings that don't, but they need to be fixed. Undocumented ABIs
> > are a bad idea.
>
> I see, so 'Compatible list, must contains "fsl,imx35-spdif"' would be okay?
While that needs to be mentioned, other values which might be present
(e.g. "fsl,imx6q-spdif") must be mentioned, or we can't rely on them
if we want to use them in future from drivers to provide additional
information (and thus they're useless).
>
> > > + - interrupts : Contains spdif interrupt.
> >
> > Is that the only interrupt the device generates?
>
> Yes, how could I improve this description?
It's probably not possible to make it much clearar to be honest,
"Contains the sole interrupt generated by the device" might be a little
overkill.
>
>
> > > + "core" The core clock of spdif controller
> > > + "rxtx<0-7>" Clock source list for tx and rx clock.
> > > + This clock list should be identical to
> > > + the source list connecting to the spdif
> > > + clock mux in "SPDIF Transceiver Clock
> > > + Diagram" of SoC reference manual. It
> > > + can also be referred to TxClk_Source
> > > + bit of register SPDIF_STC.
> >
> > Could you elaborate on the last sentence? I'm not sure exactly what you
> > meant.
>
> The list is also identical to the TxClk_Source bit value list of
> register SPDIF_STC.
What I don't understand is how the value of the SPDIF_STC register
within the spdif IP block can describe the necessary details of clocks
coming from an external clock provider.
What do the TxClk_Source bits represent? The configuration of the clock
inputs on the spdif IP block, or the outputs on some clock provider? Are
they writeable, or configured at integration time? If the clock provider
were replaced with another arbitrary clock provider, what would they
represent?
>
> >
> > > +
> > > +Example:
> > > +
> > > +spdif: spdif@02004000 {
> > > + compatible = "fsl,imx6q-spdif",
> > > + "fsl,imx35-spdif";
> >
> > Is "fsl,imx35-spdif" necessary in the list, or is it not the case all
> > "fsl,-spdif" variants are compatible with it?
> >
> > That should be mentioned along with the list of valid compatible
> > strings.
>
> I guess it's better to drop the 'imx6q-spdif' here?
That depends:
* If the two IP blocks are identical, only the "imx35-spdif" name is
necessary, and we can forget about "fsl,imx6q-spdif".
* If "fsl,imx6q-spdif" is a strict superset of "fsl,imx35-spdif", having
both names documented and in a compatible list for a "fsl,imx6q-spdif"
device makes sense.
* If "fsl,imx6q-spdif" is a variation of "fsl,imx35-spdif", and the
"fsl,imx6q-spdif" cannot always be treated identically to a
"fsl,imx35-spdif", then it makes sense to have separate compatible
strings, with a device being listed as either "fsl,imx6q-spdif" or
"fsl,imx35-spdif".
I don't know enough about the hardware to make that judgement call.
Cheers,
Mark.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 2/2] ASoC: fsl: Add S/PDIF machine driver
Hi, On Mon, Aug 19, 2013 at 10:24:58AM +0100, Mark Rutland wrote: > Is this used semantically, or is it a completely arbitrary string? In > either case I don't see why the compatible string doesn't give the > driver enough to have a sensible value. > > I'm confused as to why we need this. The phrase "user-visible" in a > device description seems very odd. The string would be in the ALSA device list: ALSA device list: #0: imx-spdif I think it can be a sort of arbitrary as long as users know which this device exactly is when they catch the name by 'aplay -l' or 'arecord -l' The phrase "user-visible" is being used in many current docs, I don't dare to change it unless a sage gives me a suggestion. > > + > > + - 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. > > Are all four units (comlpex,controller,transmitter,receiver) really > separate blocks? At least they are separate drivers as I mentioned in the commit comments. Thank you, Nicolin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
On Sat, Aug 17, 2013 at 04:17:18PM +0100, Tomasz Figa wrote: > On Saturday 17 of August 2013 16:53:16 Sascha Hauer wrote: > > On Sat, Aug 17, 2013 at 02:28:04PM +0200, Tomasz Figa wrote: > > > > > > Also I would make this option required. Use a dummy clock for > > > > > > mux > > > > > > inputs that are grounded for a specific SoC. > > > > > > > > > > Some clocks are not from CCM and we haven't defined in > > > > > imx6q-clk.txt, > > > > > so in most cases we can't provide a phandle for them, eg: > > > > > spdif_ext. > > > > > I think it's a bit hard to force it to be 'required'. An > > > > > 'optional' > > > > > looks more flexible to me and a default one is ensured even if > > > > > it's > > > > > missing. > > > > > > > > <&clks 0> is the dummy clock. This can be used for all input clocks > > > > not > > > > defined by the SoC. > > > > > > Where does this assumption come from? Is it documented anywhere? > > > > This is how all i.MX clock bindings currently are. See > > Documentation/devicetree/bindings/clock/imx*-clock.txt > > OK, thanks. > > I guess we need some discussion on dummy clocks vs skipped clocks. I think > we want some consistency on this, don't we? > > If we really need a dummy clock, then we might also want a generic way to > specify it. What do we actually mean by a "dummy clock"? We already have bindings for "fixed-clock" and co friends describe relatively simple preconfigured clocks. If a clock isn't actually wired, we shouldn't describe it at all, or we're describing what Linux wants to think rather than what the hardware actually is. That can easily be handled with clock-names. Thanks, Mark. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
Hi Mark,
Thank you for the commenst. I'll Fix them in v8.
Here are some remaining question:
On Mon, Aug 19, 2013 at 10:18:09AM +0100, Mark Rutland wrote:
> > +Required properties:
> > +
> > + - compatible : Compatible list, contains "fsl,-spdif".
>
> What are valid values for ? The binding should mention this. There
> are bindings that don't, but they need to be fixed. Undocumented ABIs
> are a bad idea.
I see, so 'Compatible list, must contains "fsl,imx35-spdif"' would be okay?
> > + - interrupts : Contains spdif interrupt.
>
> Is that the only interrupt the device generates?
Yes, how could I improve this description?
> > + "core" The core clock of spdif controller
> > + "rxtx<0-7>" Clock source list for tx and rx clock.
> > + This clock list should be identical to
> > + the source list connecting to the spdif
> > + clock mux in "SPDIF Transceiver Clock
> > + Diagram" of SoC reference manual. It
> > + can also be referred to TxClk_Source
> > + bit of register SPDIF_STC.
>
> Could you elaborate on the last sentence? I'm not sure exactly what you
> meant.
The list is also identical to the TxClk_Source bit value list of
register SPDIF_STC.
>
> > +
> > +Example:
> > +
> > +spdif: spdif@02004000 {
> > + compatible = "fsl,imx6q-spdif",
> > + "fsl,imx35-spdif";
>
> Is "fsl,imx35-spdif" necessary in the list, or is it not the case all
> "fsl,-spdif" variants are compatible with it?
>
> That should be mentioned along with the list of valid compatible
> strings.
I guess it's better to drop the 'imx6q-spdif' here?
Thank you,
Nicolin
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 2/2] ASoC: fsl: Add S/PDIF machine driver
On Mon, Aug 19, 2013 at 09:35:22AM +0100, Nicolin Chen wrote: > This patch implements a device-tree-only machine driver for Freescale > i.MX series Soc. It works with spdif_transmitter/spdif_receiver and > fsl_spdif.c drivers. > > Signed-off-by: Nicolin Chen > --- > .../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 Is this used semantically, or is it a completely arbitrary string? In either case I don't see why the compatible string doesn't give the driver enough to have a sensible value. I'm confused as to why we need this. The phrase "user-visible" in a device description seems very odd. > + > + - 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. Are all four units (comlpex,controller,transmitter,receiver) really separate blocks? Thanks, Mark. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
On Mon, Aug 19, 2013 at 09:35:21AM +0100, Nicolin Chen wrote:
> This patch implements a device-tree-only CPU DAI driver for Freescale
> S/PDIF controller that supports stereo playback and record feature.
>
> Signed-off-by: Nicolin Chen
> ---
> .../devicetree/bindings/sound/fsl,spdif.txt| 56 +
> sound/soc/fsl/Kconfig |3 +
> sound/soc/fsl/Makefile |2 +
> sound/soc/fsl/fsl_spdif.c | 1277
>
> sound/soc/fsl/fsl_spdif.h | 224
> 5 files changed, 1562 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..e9caf1c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/fsl,spdif.txt
> @@ -0,0 +1,56 @@
> +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,-spdif".
What are valid values for ? The binding should mention this. There
are bindings that don't, but they need to be fixed. Undocumented ABIs
are a bad idea.
> +
> + - reg : Offset and length of the register set for the device.
> +
> + - interrupts : Contains spdif interrupt.
Is that the only interrupt the device generates?
> +
> + - 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 : Contains an entry for each entry in clock-names.
> +
> + - clock-names : Includes the following entries:
> + namedescription
I don't think you need this line, it's obvious enough without it.
> + "core" The core clock of spdif controller
> + "rxtx<0-7>" Clock source list for tx and rx clock.
> + This clock list should be identical to
> + the source list connecting to the spdif
> + clock mux in "SPDIF Transceiver Clock
> + Diagram" of SoC reference manual. It
> + can also be referred to TxClk_Source
> + bit of register SPDIF_STC.
Could you elaborate on the last sentence? I'm not sure exactly what you
meant.
> +
> +Example:
> +
> +spdif: spdif@02004000 {
> + compatible = "fsl,imx6q-spdif",
> + "fsl,imx35-spdif";
Is "fsl,imx35-spdif" necessary in the list, or is it not the case all
"fsl,-spdif" variants are compatible with it?
That should be mentioned along with the list of valid compatible
strings.
> + reg = <0x02004000 0x4000>;
> + interrupts = <0 52 0x04>;
> + dmas = <&sdma 14 18 0>,
> + <&sdma 15 18 0>;
> + dma-names = "rx", "tx";
> +
> + clocks = <&clks 197>, <&clks 3>,
> + <&clks 197>, <&clks 107>,
> + <&clks 0>, <&clks 118>,
> + <&clks 62>, <&clks 139>,
> + <&clks 0>;
> + clock-names = "core", "rxtx0",
> + "rxtx1", "rxtx2",
> + "rxtx3", "rxtx4",
> + "rxtx5", "rxtx6",
> + "rxtx7";
> +
> + status = "okay";
> +};
[...]
> +static int spdif_clk_set_rate(struct clk *clk, unsigned long rate)
> +{
> + unsigned long rate_actual;
> +
> + rate_actual = clk_round_rate(clk, rate);
> + clk_set_rate(clk, rate_actual);
> +
> + return 0;
> +}
Can't clk_set_rate fail?
[...]
> + /* Select clock source for rx/tx clock */
> + spdif_priv->rxclk = devm_clk_get(&pdev->dev, "rxtx1");
> + if (IS_ERR(spdif_priv->rxclk)) {
> + dev_err(&pdev->dev, "no rxtx1 property in devicetree\n");
Saying "no rxtx1 clock in devicetree" would be clearer.
[...]
> +static const struct of_device_id fsl_spdif_dt_ids[] = {
> + { .compatible = "fsl,imx35-spdif", },
> + {}
> +};
So "fsl,imx35-spdif" *must* be in the compatible list. The binding
should mention this.
Thanks,
Mark.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v7 2/2] ASoC: fsl: Add S/PDIF machine driver
This patch implements a device-tree-only machine driver for Freescale
i.MX series Soc. It works with spdif_transmitter/spdif_receiver and
fsl_spdif.c drivers.
Signed-off-by: Nicolin Chen
---
.../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 cd088cc..a708380 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -193,6 +193,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 && 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
+#include
+#include
+
+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
[PATCH v7 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
This patch implements a device-tree-only CPU DAI driver for Freescale
S/PDIF controller that supports stereo playback and record feature.
Signed-off-by: Nicolin Chen
---
.../devicetree/bindings/sound/fsl,spdif.txt| 56 +
sound/soc/fsl/Kconfig |3 +
sound/soc/fsl/Makefile |2 +
sound/soc/fsl/fsl_spdif.c | 1277
sound/soc/fsl/fsl_spdif.h | 224
5 files changed, 1562 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..e9caf1c
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,spdif.txt
@@ -0,0 +1,56 @@
+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,-spdif".
+
+ - reg : Offset and length of the register set for the device.
+
+ - interrupts : Contains 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 : Contains an entry for each entry in clock-names.
+
+ - clock-names : Includes the following entries:
+ namedescription
+ "core" The core clock of spdif controller
+ "rxtx<0-7>" Clock source list for tx and rx clock.
+ This clock list should be identical to
+ the source list connecting to the spdif
+ clock mux in "SPDIF Transceiver Clock
+ Diagram" of SoC reference manual. It
+ can also be referred to TxClk_Source
+ bit of register SPDIF_STC.
+
+Example:
+
+spdif: spdif@02004000 {
+ compatible = "fsl,imx6q-spdif",
+ "fsl,imx35-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 3>,
+ <&clks 197>, <&clks 107>,
+ <&clks 0>, <&clks 118>,
+ <&clks 62>, <&clks 139>,
+ <&clks 0>;
+ clock-names = "core", "rxtx0",
+ "rxtx1", "rxtx2",
+ "rxtx3", "rxtx4",
+ "rxtx5", "rxtx6",
+ "rxtx7";
+
+ status = "okay";
+};
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 3a4808d..cd088cc 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..4274f2c
--- /dev/null
+++ b/sound/soc/fsl/fsl_spdif.c
@@ -0,0 +1,1277 @@
+/*
+ * Freescale S/PDIF ALSA SoC Digital Audio Interface (DAI) driver
+ *
+ * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ *
+ * Based on stmp3xxx_spdif_dai.c
+ * Vladimir Barinov
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#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 INTR_FOR_CAPTURE (INT_SYM_ERR | INT_BIT_ERR | INT_URX_FUL |
INT_URX_OV|\
+ INT_QRX_FUL | INT_QRX_OV | INT_UQ_SYNC | INT_UQ_ERR |\
+ INT_RXFIFO_RESYNC | INT_LOSS_LOCK | INT_DPLL_LOCKED)
+
+/* Index
[PATCH v7 0/2] Add freescale S/PDIF CPU DAI and machine drivers
Changelog: v6->v7: * Removed extra comma in array. * Revised some comments. * Added some dev_err(). * Check the return value of soft reset. * Use bitrev8() instead of extra reverse_bits(). * Use cache_bypass as default for regmap. v5->v6: * Sorted out rxtx clk source in DT binding. * Use devm_() functions. * Use platform_get_resource() instead. v4->v5: * Dropped rx/tx-clksrc-names DT bindings. * Use standard clock binding instead to pass the clock source list. * Update the compatible list by using "imx35", the first SoC that has spdif. v3->v4: * Use regmap for CPU DAI driver. * Use individual clock source for 32KHz, 44KHz, 48KHz playback. * Determine clock source configuration from 'clocks' entry. * Added imx53 to compatible list, merged imx6q and imx6dl in the list. * Improve the algorism of reverse_bits(). * Dropped the unneeded clk_put(). 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| 56 + .../devicetree/bindings/sound/imx-audio-spdif.txt | 29 + sound/soc/fsl/Kconfig | 14 + sound/soc/fsl/Makefile |4 + sound/soc/fsl/fsl_spdif.c | 1277 sound/soc/fsl/fsl_spdif.h | 224 sound/soc/fsl/imx-spdif.c | 134 ++ 7 files changed, 1738 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
