* [PATCH v2 0/9] ARM: multi-platform kconfig cleanup and mach-virt removal
From: Marc Zyngier @ 2014-02-12 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1726732.KPDAFqxz2K@wuerfel>
On 12/02/14 16:53, Arnd Bergmann wrote:
>
> On the topic of V6, we don't support CPU_V6T2 at all, though I assume that
> there is an ARM1156 core tile for integrator and realview, and we support
> running the V6/V6K parts with MMU turned off. Would all revisions of ARM1156
> work with CPU_V6K and !MMU?
CPU_V6 and !MMU should work. V6K might, but that requires close
inspection (WFE, SEV shouldn't be used in UP context)...
Full disclosure: I happen to have a *brand new*, freshly unwrapped
ARM1156 core tile for a Versatile EB. All it requires is a victim with
time on their hand...
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 3/3] mfd: axp20x: Add bindings documentation
From: Mark Brown @ 2014-02-12 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391875428-6281-4-git-send-email-carlo@caione.org>
On Sat, Feb 08, 2014 at 05:03:48PM +0100, Carlo Caione wrote:
> Bindings documentation for the axp20x driver. In this file also two
> sub-nodes (PEK and regulators) are documented.
You probably want to CC bindings to the maintianers for the relevant
subsystes too.
> + - dcdc-freq : defines the work frequency of DC-DC where
> + F=(1+dcdc-freq*5%)*1.5MHz
It sees a bit nicer to either have this be the frequency and work back
to the register setting or name it after the register field that gets
updated as a result. I'm also not sure what *5% means - I'm guessing
it's *0.05 but it'd be clearer to just write that.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140212/a4448312/attachment.sig>
^ permalink raw reply
* [PATCH v3 07/11] watchdog: xilinx: Use of_property_read_u32
From: Guenter Roeck @ 2014-02-12 17:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7cbb10853a343c9d488346596f604909ab0668b9.1392212059.git.michal.simek@xilinx.com>
Hi Michal,
On Wed, Feb 12, 2014 at 02:41:21PM +0100, Michal Simek wrote:
> Use of_property_read_u32 functions to clean probe function.
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> ---
>
> Changes in v3:
> - Remove one if checking and use variable directly
>
Looks good.
Another comment/remark.
>
> - pfreq = (u32 *)of_get_property(pdev->dev.of_node,
> - "clock-frequency", NULL);
> -
> - if (pfreq == NULL) {
> + rc = of_property_read_u32(pdev->dev.of_node, "clock-frequency", &pfreq);
> + if (rc) {
> dev_warn(&pdev->dev,
> "The watchdog clock frequency cannot be obtained\n");
> no_timeout = true;
> }
>
> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
> - "xlnx,wdt-interval", NULL);
> - if (tmptr == NULL) {
> + rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-interval",
> + &xdev->wdt_interval);
> + if (rc) {
> dev_warn(&pdev->dev,
> "Parameter \"xlnx,wdt-interval\" not found\n");
> no_timeout = true;
> - } else {
> - xdev->wdt_interval = *tmptr;
> }
>
> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
> - "xlnx,wdt-enable-once", NULL);
> - if (tmptr == NULL) {
> + rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-enable-once",
> + &enable_once);
> + if (rc)
> dev_warn(&pdev->dev,
> "Parameter \"xlnx,wdt-enable-once\" not found\n");
> - watchdog_set_nowayout(xilinx_wdt_wdd, true);
> - }
All the above properties are optional. Is a warning really
warranted in this case ? I usually associate a warning with
something that is wrong, which is not the case here.
I would encourage you to drop those warnings, but that should be
a separate patch.
Thanks,
Guenter
^ permalink raw reply
* [PATCH v2 0/9] ARM: multi-platform kconfig cleanup and mach-virt removal
From: Will Deacon @ 2014-02-12 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52FBAB51.4050401@arm.com>
On Wed, Feb 12, 2014 at 05:11:45PM +0000, Marc Zyngier wrote:
> On 12/02/14 16:53, Arnd Bergmann wrote:
> >
> > On the topic of V6, we don't support CPU_V6T2 at all, though I assume that
> > there is an ARM1156 core tile for integrator and realview, and we support
> > running the V6/V6K parts with MMU turned off. Would all revisions of ARM1156
> > work with CPU_V6K and !MMU?
>
> CPU_V6 and !MMU should work. V6K might, but that requires close
> inspection (WFE, SEV shouldn't be used in UP context)...
Well I can boot Debian on my 1136 r0p1 (no v6k) using a v6/v7 kernel, so the
lack of MMU shouldn't change that. The main issue was booting the same
kernel on an A15, which resulted in speculative interrupt acks on the GIC
(fix sitting in rmk's tree [ARM: 7954/1: mm: remove remaining domain support
from ARMv6]).
Will
^ permalink raw reply
* [linux-sunxi] Re: [PATCH 3/3] mfd: axp20x: Add bindings documentation
From: Mark Brown @ 2014-02-12 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOQ7t2ZT-3OnG-1BjGS9c6jdbzt1rDHRQ9ptOaXbewypiG_oBw@mail.gmail.com>
On Mon, Feb 10, 2014 at 11:38:47PM +0100, Carlo Caione wrote:
> On Mon, Feb 10, 2014 at 11:01 PM, Maxime Ripard
> > Ok. What's the difference between the two then?
> Honestly I have no idea. For what I have seen (core, PEK and
> regulators) AXP202 and AXP209 are identical.
I'd guess something in the electrical or mechanical specs (eg, maximum
current draws or packaging which are often related anyway), it's quite
common to get multiple PMICs that are silicon identical but differently
packaged or binned.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140212/95bb7c52/attachment.sig>
^ permalink raw reply
* [GIT PULL] bcm pinctrl rename
From: Christian Daudt @ 2014-02-12 17:20 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit b28a960c42fcd9cfc987441fa6d1c1a471f0f9ed:
Linux 3.14-rc2 (2014-02-09 18:15:47 -0800)
are available in the git repository at:
git://github.com/broadcom/bcm11351.git tags/bcm-for-3.14-pinctrl-rename
for you to fetch changes up to f5310a1712b68c7f83539fce6ebbfb6f0f510f5b:
Update dtsi with new pinctrl compatible string (2014-02-12 09:06:53 -0800)
----------------------------------------------------------------
Renaming pinctrl code to keep in line with rest of bcm mobile
Given that this driver has been in the works for a while, it
was written prior to the code standardizing on bcm-based naming.
this patchset brings it in line with the remainder of the code.
----------------------------------------------------------------
Sherman Yin (4):
pinctrl: Rename Broadcom Capri pinctrl binding
pinctrl: Rename Broadcom Capri pinctrl driver
Update bcm_defconfig with new pinctrl CONFIG
Update dtsi with new pinctrl compatible string
.../bindings/pinctrl/{brcm,capri-pinctrl.txt =>
brcm,bcm11351-pinctrl.txt} | 8 +-
arch/arm/boot/dts/bcm11351.dtsi
| 2 +-
arch/arm/configs/bcm_defconfig
| 2 +-
drivers/pinctrl/Kconfig
| 8 +-
drivers/pinctrl/Makefile
| 2 +-
drivers/pinctrl/pinctrl-bcm281xx.c
| 1461 ++++++++++++++++++++++++++++++++++++++
drivers/pinctrl/pinctrl-capri.c
| 1454 -------------------------------------
7 files changed, 1472 insertions(+), 1465 deletions(-)
rename Documentation/devicetree/bindings/pinctrl/{brcm,capri-pinctrl.txt
=> brcm,bcm11351-pinctrl.txt} (98%)
create mode 100644 drivers/pinctrl/pinctrl-bcm281xx.c
delete mode 100644 drivers/pinctrl/pinctrl-capri.c
^ permalink raw reply
* [PATCH v2 0/7] Audio support for Armada 370 DB
From: Thomas Petazzoni @ 2014-02-12 17:20 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This series of patches enable audio support on the Marvell Armada 370
Development Board. Since both the I2S controller on the SoC side and
the I2C audio codec are already supported by the kernel, the amount of
work is fairly limited.
Changes since v1:
* Drop patches "sound: codec: add Device Tree binding to cs42l51" and
" sound: soc: enable Kirkwood driver for mvebu platforms" since
they have been applied by Mark Brown.
* Set DAI format directly in the snd_soc_dai_link structure instead
of separately calling snd_soc_dai_set_fmt(). Suggested by Mark
Brown.
* Do not call snd_soc_dapm_enable_pin(), as Mark Brown mentionned
that DAPM widgets default to enabled. It allowed to entirely remove
the dai_init operation.
* Use devm_snd_soc_register_card() instead of
snd_soc_register_card(), as suggested by Mark Brown.
* Wrote a Device Tree binding document for the DT binding introduced
by this driver. Requested by Mark Brown.
* Use the DT to look up the controller and the codec, as suggested by
Mark Brown.
* Add S/PDIF support, which has been successfully tested. I've kept
it as separate patches (for both the ASoC machine driver, and the
Device Tree bits), so that it can be reviewed and applied
separately.
* Modified the commit title so that they contain "ASoC", as requested
by Mark Brown.
Patches 1 and 2 are to be reviewed/applied by the ASoC maintainer Mark
Brown, while patches 3 to 7 are to be reviewed/applied by the ARM
mvebu maintainers.
Note that the audio support for Armada 370 also needs a fix to the
CS42L51, which is being discussed with the author of the change that
apparently introduced the problem (see discussion at
http://mailman.alsa-project.org/pipermail/alsa-devel/2014-January/071916.html).
Thanks,
Thomas
Thomas Petazzoni (7):
sound: ASoC: add ASoC board driver for Armada 370 DB
sound: ASoC: add S/PDIF support to Armada 370 DB ASoC driver
ARM: mvebu: add audio I2S controller to Armada 370 Device Tree
ARM: mvebu: add I2C0 muxing option for Armada 370 SoC
ARM: mvebu: add audio support to Armada 370 DB
ARM: mvebu: enable S/PDIF audio in Armada 370 DB Device Tree
ARM: mvebu: enable audio options in mvebu_defconfig
.../bindings/sound/armada-370db-audio.txt | 27 ++++
arch/arm/boot/dts/armada-370-db.dts | 56 ++++++++
arch/arm/boot/dts/armada-370.dtsi | 28 ++++
arch/arm/configs/mvebu_defconfig | 5 +
sound/soc/kirkwood/Kconfig | 9 ++
sound/soc/kirkwood/Makefile | 2 +
sound/soc/kirkwood/armada-370-db.c | 148 +++++++++++++++++++++
7 files changed, 275 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/armada-370db-audio.txt
create mode 100644 sound/soc/kirkwood/armada-370-db.c
--
1.8.3.2
^ permalink raw reply
* [PATCH v2 1/7] sound: ASoC: add ASoC board driver for Armada 370 DB
From: Thomas Petazzoni @ 2014-02-12 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392225662-20431-1-git-send-email-thomas.petazzoni@free-electrons.com>
This commit adds a simple ASoC board driver fo the Armada 370
Development Board, which connects the audio unit of the Armada 370 SoC
to the I2C-based CS42L51.
For now, only the analog audio input and output through the CS42L51
are supported, but a followup patch adds S/PDIF support to this
driver.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
.../bindings/sound/armada-370db-audio.txt | 24 +++++
sound/soc/kirkwood/Kconfig | 8 ++
sound/soc/kirkwood/Makefile | 2 +
sound/soc/kirkwood/armada-370-db.c | 120 +++++++++++++++++++++
4 files changed, 154 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/armada-370db-audio.txt
create mode 100644 sound/soc/kirkwood/armada-370-db.c
diff --git a/Documentation/devicetree/bindings/sound/armada-370db-audio.txt b/Documentation/devicetree/bindings/sound/armada-370db-audio.txt
new file mode 100644
index 0000000..3893b4d
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/armada-370db-audio.txt
@@ -0,0 +1,24 @@
+Device Tree bindings for the Armada 370 DB audio
+================================================
+
+These Device Tree bindings are used to describe the audio complex
+found on the Armada 370 DB platform.
+
+Mandatory properties:
+
+ * compatible: must be "marvell,a370db-audio"
+
+ * marvell,audio-controller: a phandle that points to the audio
+ controller of the Armada 370 SoC.
+
+ * marvell,audio-codec: a phandle that points to the analog audio
+ codec connected to the Armada 370 SoC.
+
+Example:
+
+ sound {
+ compatible = "marvell,a370db-audio";
+ marvell,audio-controller = <&audio_controller>;
+ marvell,audio-codec = <&audio_codec>;
+ status = "okay";
+ };
diff --git a/sound/soc/kirkwood/Kconfig b/sound/soc/kirkwood/Kconfig
index 764a0ef..2dc3ecf 100644
--- a/sound/soc/kirkwood/Kconfig
+++ b/sound/soc/kirkwood/Kconfig
@@ -6,6 +6,14 @@ config SND_KIRKWOOD_SOC
the Kirkwood I2S interface. You will also need to select the
audio interfaces to support below.
+config SND_KIRKWOOD_SOC_ARMADA370_DB
+ tristate "SoC Audio support for Armada 370 DB"
+ depends on SND_KIRKWOOD_SOC && (ARCH_MVEBU || COMPILE_TEST) && I2C
+ select SND_SOC_CS42L51
+ help
+ Say Y if you want to add support for SoC audio on
+ the Armada 370 Development Board.
+
config SND_KIRKWOOD_SOC_OPENRD
tristate "SoC Audio support for Kirkwood Openrd Client"
depends on SND_KIRKWOOD_SOC && (MACH_OPENRD_CLIENT || MACH_OPENRD_ULTIMATE || COMPILE_TEST)
diff --git a/sound/soc/kirkwood/Makefile b/sound/soc/kirkwood/Makefile
index 9e78138..7c1d8fe 100644
--- a/sound/soc/kirkwood/Makefile
+++ b/sound/soc/kirkwood/Makefile
@@ -4,6 +4,8 @@ obj-$(CONFIG_SND_KIRKWOOD_SOC) += snd-soc-kirkwood.o
snd-soc-openrd-objs := kirkwood-openrd.o
snd-soc-t5325-objs := kirkwood-t5325.o
+snd-soc-armada-370-db-objs := armada-370-db.o
+obj-$(CONFIG_SND_KIRKWOOD_SOC_ARMADA370_DB) += snd-soc-armada-370-db.o
obj-$(CONFIG_SND_KIRKWOOD_SOC_OPENRD) += snd-soc-openrd.o
obj-$(CONFIG_SND_KIRKWOOD_SOC_T5325) += snd-soc-t5325.o
diff --git a/sound/soc/kirkwood/armada-370-db.c b/sound/soc/kirkwood/armada-370-db.c
new file mode 100644
index 0000000..977639b
--- /dev/null
+++ b/sound/soc/kirkwood/armada-370-db.c
@@ -0,0 +1,120 @@
+/*
+ * Copyright (C) 2014 Marvell
+ *
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ */
+
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/interrupt.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <sound/soc.h>
+#include <linux/of.h>
+#include <linux/platform_data/asoc-kirkwood.h>
+#include "../codecs/cs42l51.h"
+
+static int a370db_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params)
+{
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct snd_soc_dai *codec_dai = rtd->codec_dai;
+ unsigned int freq;
+
+ switch (params_rate(params)) {
+ default:
+ case 44100:
+ freq = 11289600;
+ break;
+ case 48000:
+ freq = 12288000;
+ break;
+ case 96000:
+ freq = 24576000;
+ break;
+ }
+
+ return snd_soc_dai_set_sysclk(codec_dai, 0, freq, SND_SOC_CLOCK_IN);
+}
+
+static struct snd_soc_ops a370db_ops = {
+ .hw_params = a370db_hw_params,
+};
+
+static const struct snd_soc_dapm_widget a370db_dapm_widgets[] = {
+ SND_SOC_DAPM_HP("Out Jack", NULL),
+ SND_SOC_DAPM_LINE("In Jack", NULL),
+};
+
+static const struct snd_soc_dapm_route a370db_route[] = {
+ { "Out Jack", NULL, "HPL" },
+ { "Out Jack", NULL, "HPR" },
+ { "AIN1L", NULL, "In Jack" },
+ { "AIN1L", NULL, "In Jack" },
+};
+
+static struct snd_soc_dai_link a370db_dai[] = {
+{
+ .name = "CS42L51",
+ .stream_name = "analog",
+ .cpu_dai_name = "i2s",
+ .codec_dai_name = "cs42l51-hifi",
+ .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_CBS_CFS,
+ .ops = &a370db_ops,
+},
+};
+
+static struct snd_soc_card a370db = {
+ .name = "a370db",
+ .owner = THIS_MODULE,
+ .dai_link = a370db_dai,
+ .num_links = ARRAY_SIZE(a370db_dai),
+ .dapm_widgets = a370db_dapm_widgets,
+ .num_dapm_widgets = ARRAY_SIZE(a370db_dapm_widgets),
+ .dapm_routes = a370db_route,
+ .num_dapm_routes = ARRAY_SIZE(a370db_route),
+};
+
+static int a370db_probe(struct platform_device *pdev)
+{
+ struct snd_soc_card *card = &a370db;
+
+ card->dev = &pdev->dev;
+
+ a370db_dai[0].cpu_of_node =
+ of_parse_phandle(pdev->dev.of_node,
+ "marvell,audio-controller", 0);
+ a370db_dai[0].platform_of_node = a370db_dai[0].cpu_of_node;
+
+ a370db_dai[0].codec_of_node =
+ of_parse_phandle(pdev->dev.of_node,
+ "marvell,audio-codec", 0);
+
+ return devm_snd_soc_register_card(card->dev, card);
+}
+
+static const struct of_device_id a370db_dt_ids[] = {
+ { .compatible = "marvell,a370db-audio" },
+ { },
+};
+
+static struct platform_driver a370db_driver = {
+ .driver = {
+ .name = "a370db-audio",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(a370db_dt_ids),
+ },
+ .probe = a370db_probe,
+};
+
+module_platform_driver(a370db_driver);
+
+MODULE_AUTHOR("Thomas Petazzoni <thomas.petazzoni@free-electrons.com>");
+MODULE_DESCRIPTION("ALSA SoC a370db audio client");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:a370db-audio");
--
1.8.3.2
^ permalink raw reply related
* [PATCH v2 2/7] sound: ASoC: add S/PDIF support to Armada 370 DB ASoC driver
From: Thomas Petazzoni @ 2014-02-12 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392225662-20431-1-git-send-email-thomas.petazzoni@free-electrons.com>
The Armada 370 DB board not only has analog audio input/output, but
also S/PDIF input/output. This commit adds support for S/PDIF in the
ASoC machine driver of the Armada 370 DB platform, and adjusts the
Device Tree bindings documentation accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
.../bindings/sound/armada-370db-audio.txt | 9 ++++---
sound/soc/kirkwood/Kconfig | 1 +
sound/soc/kirkwood/armada-370-db.c | 28 ++++++++++++++++++++++
3 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/armada-370db-audio.txt b/Documentation/devicetree/bindings/sound/armada-370db-audio.txt
index 3893b4d..bf984d2 100644
--- a/Documentation/devicetree/bindings/sound/armada-370db-audio.txt
+++ b/Documentation/devicetree/bindings/sound/armada-370db-audio.txt
@@ -11,14 +11,17 @@ Mandatory properties:
* marvell,audio-controller: a phandle that points to the audio
controller of the Armada 370 SoC.
- * marvell,audio-codec: a phandle that points to the analog audio
- codec connected to the Armada 370 SoC.
+ * marvell,audio-codec: a set of three phandles that points to:
+
+ 1/ the analog audio codec connected to the Armada 370 SoC
+ 2/ the S/PDIF transceiver
+ 3/ the S/PDIF receiver
Example:
sound {
compatible = "marvell,a370db-audio";
marvell,audio-controller = <&audio_controller>;
- marvell,audio-codec = <&audio_codec>;
+ marvell,audio-codec = <&audio_codec &spdif_out &spdif_in>;
status = "okay";
};
diff --git a/sound/soc/kirkwood/Kconfig b/sound/soc/kirkwood/Kconfig
index 2dc3ecf..49f8437 100644
--- a/sound/soc/kirkwood/Kconfig
+++ b/sound/soc/kirkwood/Kconfig
@@ -10,6 +10,7 @@ config SND_KIRKWOOD_SOC_ARMADA370_DB
tristate "SoC Audio support for Armada 370 DB"
depends on SND_KIRKWOOD_SOC && (ARCH_MVEBU || COMPILE_TEST) && I2C
select SND_SOC_CS42L51
+ select SND_SOC_SPDIF
help
Say Y if you want to add support for SoC audio on
the Armada 370 Development Board.
diff --git a/sound/soc/kirkwood/armada-370-db.c b/sound/soc/kirkwood/armada-370-db.c
index 977639b..c443338 100644
--- a/sound/soc/kirkwood/armada-370-db.c
+++ b/sound/soc/kirkwood/armada-370-db.c
@@ -67,6 +67,20 @@ static struct snd_soc_dai_link a370db_dai[] = {
.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_CBS_CFS,
.ops = &a370db_ops,
},
+{
+ .name = "S/PDIF out",
+ .stream_name = "spdif-out",
+ .cpu_dai_name = "spdif",
+ .codec_dai_name = "dit-hifi",
+ .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_CBS_CFS,
+},
+{
+ .name = "S/PDIF in",
+ .stream_name = "spdif-in",
+ .cpu_dai_name = "spdif",
+ .codec_dai_name = "dir-hifi",
+ .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_CBS_CFS,
+},
};
static struct snd_soc_card a370db = {
@@ -95,6 +109,20 @@ static int a370db_probe(struct platform_device *pdev)
of_parse_phandle(pdev->dev.of_node,
"marvell,audio-codec", 0);
+ a370db_dai[1].cpu_of_node = a370db_dai[0].cpu_of_node;
+ a370db_dai[1].platform_of_node = a370db_dai[0].cpu_of_node;
+
+ a370db_dai[1].codec_of_node =
+ of_parse_phandle(pdev->dev.of_node,
+ "marvell,audio-codec", 1);
+
+ a370db_dai[2].cpu_of_node = a370db_dai[0].cpu_of_node;
+ a370db_dai[2].platform_of_node = a370db_dai[0].cpu_of_node;
+
+ a370db_dai[2].codec_of_node =
+ of_parse_phandle(pdev->dev.of_node,
+ "marvell,audio-codec", 2);
+
return devm_snd_soc_register_card(card->dev, card);
}
--
1.8.3.2
^ permalink raw reply related
* [PATCH v2 3/7] ARM: mvebu: add audio I2S controller to Armada 370 Device Tree
From: Thomas Petazzoni @ 2014-02-12 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392225662-20431-1-git-send-email-thomas.petazzoni@free-electrons.com>
The Armada 370 SoC has an I2S audio controller. This commit adds the
description of this controller to the Device Tree describing this SoC,
as well as two possible muxing configurations for the I2S bus pins.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/boot/dts/armada-370.dtsi | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index 0d8530c..e3f4c18 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -132,6 +132,20 @@
"mpp51", "mpp52", "mpp53";
marvell,function = "sd0";
};
+
+ i2s_pins1: i2s-pins1 {
+ marvell,pins = "mpp5", "mpp6", "mpp7",
+ "mpp8", "mpp9", "mpp10",
+ "mpp12", "mpp13";
+ marvell,function = "audio";
+ };
+
+ i2s_pins2: i2s-pins2 {
+ marvell,pins = "mpp49", "mpp47", "mpp50",
+ "mpp59", "mpp57", "mpp61",
+ "mpp62", "mpp60", "mpp58";
+ marvell,function = "audio";
+ };
};
gpio0: gpio at 18100 {
@@ -196,6 +210,15 @@
clocks = <&coreclk 2>;
};
+ audio_controller: audio-controller at 30000 {
+ compatible = "marvell,armada370-audio";
+ reg = <0x30000 0x4000>;
+ interrupts = <93>;
+ clocks = <&gateclk 0>;
+ clock-names = "internal";
+ status = "disabled";
+ };
+
usb at 50000 {
clocks = <&coreclk 0>;
};
--
1.8.3.2
^ permalink raw reply related
* [PATCH v2 4/7] ARM: mvebu: add I2C0 muxing option for Armada 370 SoC
From: Thomas Petazzoni @ 2014-02-12 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392225662-20431-1-git-send-email-thomas.petazzoni@free-electrons.com>
This commit adds a pin-muxing configuration for the I2C0 bus of the
Armada 370, which is used on the Armada 370 DB platform to interface
with the CS42L51 audio codec.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/boot/dts/armada-370.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index e3f4c18..6f216f0 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -133,6 +133,11 @@
marvell,function = "sd0";
};
+ i2c0_pins: i2c0-pins {
+ marvell,pins = "mpp2", "mpp3";
+ marvell,function = "i2c0";
+ };
+
i2s_pins1: i2s-pins1 {
marvell,pins = "mpp5", "mpp6", "mpp7",
"mpp8", "mpp9", "mpp10",
--
1.8.3.2
^ permalink raw reply related
* [PATCH v2 5/7] ARM: mvebu: add audio support to Armada 370 DB
From: Thomas Petazzoni @ 2014-02-12 17:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392225662-20431-1-git-send-email-thomas.petazzoni@free-electrons.com>
This commit adds the necessary Device Tree informations to enable
audio support on the Armada 370 DB platform. In details it:
* Instantiates the CS42L51 audio codec on the I2C0 bus, and
configures this bus with the appropriate pin-muxing configuration.
* Enables the I2S audio controller, and configures it with the
appropriate pin-muxing configuration.
* Through hog pins, ensures that the other pins possibly used for I2S
are muxed with another function than I2S.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/boot/dts/armada-370-db.dts | 48 +++++++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index 08a56bc..7df1866 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -64,6 +64,22 @@
phy-mode = "rgmii-id";
};
+ i2c at 11000 {
+ pinctrl-0 = <&i2c0_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ audio_codec: audio-codec at 4a {
+ compatible = "cirrus,cs42l51";
+ reg = <0x4a>;
+ };
+ };
+
+ audio-controller at 30000 {
+ pinctrl-0 = <&i2s_pins2>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
+
mvsdio at d4000 {
pinctrl-0 = <&sdio_pins1>;
pinctrl-names = "default";
@@ -80,6 +96,30 @@
broken-cd;
};
+ pinctrl {
+ /*
+ * These pins might be muxed as I2S by
+ * the bootloader, but it conflicts
+ * with the real I2S pins that are
+ * muxed using i2s_pins. We must mux
+ * those pins to a function other than
+ * I2S.
+ */
+ pinctrl-0 = <&hog_pins1 &hog_pins2>;
+ pinctrl-names = "default";
+
+ hog_pins1: hog-pins1 {
+ marvell,pins = "mpp6", "mpp8", "mpp10",
+ "mpp12", "mpp13";
+ marvell,function = "gpio";
+ };
+
+ hog_pins2: hog-pins2 {
+ marvell,pins = "mpp5", "mpp7", "mpp9";
+ marvell,function = "gpo";
+ };
+ };
+
usb at 50000 {
status = "okay";
};
@@ -112,10 +152,18 @@
/* Port 0, Lane 0 */
status = "okay";
};
+
pcie at 2,0 {
/* Port 1, Lane 0 */
status = "okay";
};
};
};
+
+ sound {
+ compatible = "marvell,a370db-audio";
+ marvell,audio-controller = <&audio_controller>;
+ marvell,audio-codec = <&audio_codec>;
+ status = "okay";
+ };
};
--
1.8.3.2
^ permalink raw reply related
* [PATCH v2 6/7] ARM: mvebu: enable S/PDIF audio in Armada 370 DB Device Tree
From: Thomas Petazzoni @ 2014-02-12 17:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392225662-20431-1-git-send-email-thomas.petazzoni@free-electrons.com>
In addition to the analog audio input and output, the Armada 370 DB
also has S/PDIF input and output optical connectors. This commit
improves the Device Tree description of the Armada 370 DB platform to
enable the S/PDIF support.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/boot/dts/armada-370-db.dts | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index 7df1866..82f238a 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -163,7 +163,15 @@
sound {
compatible = "marvell,a370db-audio";
marvell,audio-controller = <&audio_controller>;
- marvell,audio-codec = <&audio_codec>;
+ marvell,audio-codec = <&audio_codec &spdif_out &spdif_in>;
status = "okay";
};
+
+ spdif_out: spdif-out {
+ compatible = "linux,spdif-dit";
+ };
+
+ spdif_in: spdif-in {
+ compatible = "linux,spdif-dir";
+ };
};
--
1.8.3.2
^ permalink raw reply related
* [PATCH v2 7/7] ARM: mvebu: enable audio options in mvebu_defconfig
From: Thomas Petazzoni @ 2014-02-12 17:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392225662-20431-1-git-send-email-thomas.petazzoni@free-electrons.com>
Since at least the Armada 370 SoC has audio support, it makes sense to
enable the corresponding kernel configuration options in
mvebu_defconfig.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/configs/mvebu_defconfig | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index 0f4511d..5c58559 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -62,6 +62,11 @@ CONFIG_GPIOLIB=y
CONFIG_GPIO_SYSFS=y
CONFIG_THERMAL=y
CONFIG_ARMADA_THERMAL=y
+CONFIG_SOUND=y
+CONFIG_SND=y
+CONFIG_SND_SOC=y
+CONFIG_SND_KIRKWOOD_SOC=y
+CONFIG_SND_KIRKWOOD_SOC_ARMADA370_DB=y
CONFIG_USB_SUPPORT=y
CONFIG_USB=y
CONFIG_USB_EHCI_HCD=y
--
1.8.3.2
^ permalink raw reply related
* [PATCH] ARM: dts: imx6qdl-sabresd: Do not place regulator nodes under simple-bus
From: Fabio Estevam @ 2014-02-12 17:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212152050.GA28749@S2101-09.ap.freescale.net>
On Wed, Feb 12, 2014 at 1:20 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
> On Wed, Feb 12, 2014 at 01:57:36PM +0000, Mark Rutland wrote:
>> As it stands, the dts are buggy. I can appreciate that you don't feel
>> this is important, but I do. It's not just an IMX issue, there is
>> widespread misunderstanding and abuse of simple-bus.
>>
>> Said abuse is relying on current Linux implementation details, and that
>> can and will create problems if and when probing code is changed.
>
> The reality is the code already gets no chance to change on this regard,
> considering the requirement that we need to maintain the interface
> between kernel and DT as ABI. The dts have been there like this for
> 10 kernel releases or so.
What breakage do you see with this patch?
^ permalink raw reply
* [PATCH v3 0/2] ASoC: atmel_ssc_dai: add option to choose clock
From: Mark Brown @ 2014-02-12 17:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392012586-30790-1-git-send-email-voice.shen@atmel.com>
On Mon, Feb 10, 2014 at 02:09:44PM +0800, Bo Shen wrote:
> When SSC work in slave mode, the clock can come from TK pin and also
> can come from RK pin, this is hardware design decided. So, make it
> available to choose where the clock from.
Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140212/dbd09126/attachment.sig>
^ permalink raw reply
* [PATCH RFC v2 00/35] Second preview of imx-drm cleanup series
From: Philipp Zabel @ 2014-02-12 17:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212095606.GM26684@n2100.arm.linux.org.uk>
Am Mittwoch, den 12.02.2014, 09:56 +0000 schrieb Russell King - ARM
Linux:
> On Mon, Feb 10, 2014 at 12:28:03PM +0000, Russell King - ARM Linux wrote:
> > This is the latest revision of my series cleaning up imx-drm and
> > hopefully getting it ready to be moved out of drivers/staging.
> > This series is updated to v3.14-rc2.
> >
> > Since the last round of patches were posted, the component support
> > has been merged into mainline, and thus dropped from this series.
> > Greg has taken the first three patches and merged them into his
> > linux-next tree - however, I include them here for completness.
> >
> > Most of the comments from last time still apply, and I'll look at
> > incorporating some of the other patches that were posted in the
> > coming week.
> >
> > If I can have some acks for this, I'll start sending some of it to
> > Greg - I'd like to at least get the five or six initial imx-hdmi
> > patches to Greg and queued up for the next merge window sooner
> > rather than later, preferably getting most of this ready for that
> > window too.
>
> So far, only the first few patches have been acked by one person. What
> about the remainder? There's been no comments on them either...
With the understanding that I loathe the current DT bindings, which are
not the fault of this series:
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
regards
Philipp
^ permalink raw reply
* [PATCH v4 3/8] at91: dt: Add at91sam9261 dt SoC support
From: Alexandre Belloni @ 2014-02-12 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392199607-27452-4-git-send-email-jjhiblot@traphandler.com>
Hi,
On 12/02/2014 at 11:06:42 +0100, Jean-Jacques Hiblot wrote :
> This patch adds support for the Device Tree on a sam9261-based platform
>
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
> ---
> arch/arm/boot/dts/at91sam9261.dtsi | 740 +++++++++++++++++++++++++++++++++++++
> arch/arm/mach-at91/at91sam9261.c | 17 +
> 2 files changed, 757 insertions(+)
> create mode 100644 arch/arm/boot/dts/at91sam9261.dtsi
[...]
> +
> + apb {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + tcb0: timer at fffa0000 {
> + compatible = "atmel,at91rm9200-tcb";
> + reg = <0xfffa0000 0x100>;
> + interrupts = < 17 IRQ_TYPE_LEVEL_HIGH 0
> + 18 IRQ_TYPE_LEVEL_HIGH 0
> + 19 IRQ_TYPE_LEVEL_HIGH 0
> + >;
> + clocks = <&tc0_clk>, <&tc1_clk>, <&tc2_clk>;
> + clock-names = "t0_clk", "t1_clk", "t2_clk";
> + };
> +
> + usb1: gadget at fffa4000 {
> + compatible = "atmel,at91rm9200-udc";
> + reg = <0xfffa4000 0x4000>;
> + interrupts = <10 IRQ_TYPE_LEVEL_HIGH 2>;
> + clocks = <&usb>, <&udc_clk>, <&udpck>;
> + clock-names = "usb_clk", "udc_clk", "udpck";
> + status = "disabled";
> + };
> +
> + mmc0: mmc at fffa8000 {
> + compatible = "atmel,hsmci";
> + reg = <0xfffa8000 0x600>;
> + interrupts = <9 IRQ_TYPE_LEVEL_HIGH 0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_mmc0_clk>, <&pinctrl_mmc0_slot0_cmd_dat0>, <&pinctrl_mmc0_slot0_dat1_3>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&mci0_clk>;
> + clock-names = "mci_clk";
> + status = "disabled";
> + };
> +
> + i2c0: i2c at fffac000 {
> + compatible = "atmel,at91sam9261-i2c";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c_twi>;
> + reg = <0xfffac000 0x100>;
> + interrupts = <11 IRQ_TYPE_LEVEL_HIGH 6>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&twi0_clk>;
> + status = "disabled";
> + };
> +
> + usart0: serial at fffb0000 {
> + compatible = "atmel,at91sam9260-usart";
> + reg = <0xfffb0000 0x200>;
> + interrupts = <6 IRQ_TYPE_LEVEL_HIGH 5>;
> + atmel,use-dma-rx;
> + atmel,use-dma-tx;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usart0>;
> + clocks = <&usart0_clk>;
> + clock-names = "usart";
> + status = "disabled";
> + };
> +
> + usart1: serial at fffb4000 {
> + compatible = "atmel,at91sam9260-usart";
> + reg = <0xfffb4000 0x200>;
> + interrupts = <7 IRQ_TYPE_LEVEL_HIGH 5>;
> + atmel,use-dma-rx;
> + atmel,use-dma-tx;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usart1>;
> + clocks = <&usart1_clk>;
> + clock-names = "usart";
> + status = "disabled";
> + };
> +
> + usart2: serial at fffb8000{
> + compatible = "atmel,at91sam9260-usart";
> + reg = <0xfffb8000 0x200>;
> + interrupts = <8 IRQ_TYPE_LEVEL_HIGH 5>;
> + atmel,use-dma-rx;
> + atmel,use-dma-tx;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usart2>;
> + clocks = <&usart2_clk>;
> + clock-names = "usart";
> + status = "disabled";
> + };
> +
> + ssc0: ssc at fffbc000 {
> + compatible = "atmel,at91rm9200-ssc";
> + reg = <0xfffbc000 0x4000>;
> + interrupts = <14 IRQ_TYPE_LEVEL_HIGH 5>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
> + status = "disabled";
> + };
> +
> + ssc1: ssc at fffc0000 {
> + compatible = "atmel,at91rm9200-ssc";
> + reg = <0xfffc0000 0x4000>;
> + interrupts = <15 IRQ_TYPE_LEVEL_HIGH 5>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ssc1_tx &pinctrl_ssc1_rx>;
> + status = "disabled";
> + };
> +
> + spi0: spi at fffc8000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "atmel,at91rm9200-spi";
> + reg = <0xfffc8000 0x200>;
> + cs-gpios = <0>, <0>, <0>, <0>;
> + interrupts = <12 IRQ_TYPE_LEVEL_HIGH 3>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_spi0>;
> + clocks = <&spi0_clk>;
> + clock-names = "spi_clk";
> + status = "disabled";
> + };
> +
> + spi1: spi at fffcc000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "atmel,at91rm9200-spi";
> + reg = <0xfffcc000 0x200>;
> + interrupts = <13 IRQ_TYPE_LEVEL_HIGH 3>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_spi1>;
> + clocks = <&spi1_clk>;
> + clock-names = "spi_clk";
> + status = "disabled";
> + };
> +
> + ramc: ramc at ffffea00 {
> + compatible = "atmel,at91sam9260-sdramc";
> + reg = <0xffffea00 0x200>;
> + };
> +
You probably copied/pasted it but according to the block diagram, the
sdram controller is not under the apb.
> + matrix: matrix at ffffee00 {
> + compatible = "atmel,at91sam9261-bus-matrix";
> + reg = <0xffffee00 0x200>;
> + };
> +
Same here, the apb is actually under the bus matrix.
I don't know whether it can be represented another way though.
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [RFC/PATCH 0/3] Add devicetree scanning for randomness
From: Jason Cooper @ 2014-02-12 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201402121251.06280.arnd@arndb.de>
Laura,
Sorry to hijack the thread (sort of). :)
+ Kees Cook
On Wed, Feb 12, 2014 at 12:51:05PM +0100, Arnd Bergmann wrote:
> On Wednesday 12 February 2014, Laura Abbott wrote:
> > This is an RFC to seed the random number pool earlier when using devicetree.
> > The big issue this is trying to solve is the fact that the stack canary for
> > ARM tends to be the same across bootups of the same device. This is because
> > the random number pools do not get initialized until after the canary has
> > been set up. The canary can be moved later, but in general there is still
> > no way to reliably get random numbers early for other features (e.g. vector
> > randomization).
>
> Implementation-wise this looks reasonable, and it obviously addresses a
> very real problem.
>
> > The goal here is to allow devices to add to the random pools via
> > add_device_randomness or some other method of their chosing at FDT time.
> > I realize that ARCH_RANDOM is already available but this didn't work because
> > 1) ARCH_RANDOM is not multi-platform compatible without added
> > infrastructure to ARM
>
> That could certainly be done, but I agree that a more generic
> approach like you did is nicer. One thing that might be useful
> would be to wire up your OF_RANDOM infrastructure as a generic
> implementation of ARCH_RANDOM, and merge your header file into
> include/asm-generic/archrandom.h, with an added way to call
> arch_get_random_long() for the devices you add.
>
> > The big reason to skip ARCH_RANDOM though is that the random number generation
> > we have would be reasonable if only seeded earlier.
>
> Yes, makes sense.
>
> I also wonder if we should add a 'trivial' implementation that just
> reads a DT property full of random numbers to use as either an initial
> seed, or to feed into arch_get_random_long(). This would allow the
> boot loader to pass any entropy it has already gathered into the kernel,
> but leaves the danger that people might pass static not-so-random data
> through a precompiled dtb file ;-). If we get the boot loaders to be
> smart enough, doing only this would be a much simpler kernel implementation
> than your suggestion, but I'm not sure how far I want to trust boot loaders.
I brought this up at last weeks devicetree irc meeting. My goal is to
provide early randomness for kaslr on ARM. Currently, my idea is modify
the init script to save an additional random seed from /dev/urandom to
/boot/random-seed.
The bootloader would then load this file into ram, and pass the
address/size to the kernel either via dt, or commandline. kaslr (run in
the decompressor) would consume some of this randomness, and then
random.c would consume the rest in a non-crediting initialization.
While not ideal, it works in absence of an HRNG, and is no worse than
the current situation of storing the seed in /var/lib/misc/random-seed.
It also doesn't require modification of the bootloaders. Just an
updated kernel, and update the bootloader environment to load the
seed.
Unfortunately, it's an idea so far. I have one project to get off of my
plate, then this is next :)
thx,
Jason.
^ permalink raw reply
* [PATCH v4 2/8] at91: pinctrl: don't request GPIOs used for interrupts but lock them as IRQ
From: Nicolas Ferre @ 2014-02-12 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392199607-27452-3-git-send-email-jjhiblot@traphandler.com>
On 12/02/2014 11:06, Jean-Jacques Hiblot :
> During the xlate stage of the DT interrupt parsing, the at91 pinctrl driver
> requests the GPIOs that are described as interrupt sources. This prevents a
> driver to request the gpio later to get its electrical value.
> This patch replaces the gpio_request with a gpio_lock_as_irq to prevent the
> gpio to be set as an ouput while allowing a subsequent gpio_request to succeed
>
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
But I suspect it may go through another patch: the pinctrl one: add
Linux W. to the recipient list please.
Thanks,
> ---
> drivers/pinctrl/pinctrl-at91.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
> index d990e33..db55b96 100644
> --- a/drivers/pinctrl/pinctrl-at91.c
> +++ b/drivers/pinctrl/pinctrl-at91.c
> @@ -1478,18 +1478,17 @@ static int at91_gpio_irq_domain_xlate(struct irq_domain *d,
> {
> struct at91_gpio_chip *at91_gpio = d->host_data;
> int ret;
> - int pin = at91_gpio->chip.base + intspec[0];
>
> if (WARN_ON(intsize < 2))
> return -EINVAL;
> *out_hwirq = intspec[0];
> *out_type = intspec[1] & IRQ_TYPE_SENSE_MASK;
>
> - ret = gpio_request(pin, ctrlr->full_name);
> + ret = gpio_lock_as_irq(&at91_gpio->chip, intspec[0]);
> if (ret)
> return ret;
>
> - ret = gpio_direction_input(pin);
> + ret = at91_gpio_direction_input(&at91_gpio->chip, intspec[0]);
> if (ret)
> return ret;
>
>
--
Nicolas Ferre
^ permalink raw reply
* Toggling gpio pins while powering down
From: Jasbir Matharu @ 2014-02-12 17:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212075743.GD30814@lunn.ch>
Thanks look useful l'll look at extending it.
Now only problem is that I need to include code from another drivers
pm_power_off function because its a singleton. Would be nice to have
the facility to register pm_power_off functions from each driver and
call them from the singleton.
On Wednesday, February 12, 2014, Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Tue, Feb 11, 2014 at 07:33:11PM +0000, Jasbir Matharu wrote:
> > I'm trying to determine the correct way of toggling gpio pins when the
> > soc is powering down to enter low power mode. My current crude
> > implementation is perform these within a pm_power_off function however
> > this is currently done within the board file by checking for a
> > compatible board type (ugly). The alternative would be create a driver
> > and implement the pm_power_off function within. However given there
> > could many drivers implementing a pm_power_off functions there's no
> > guarantee mine will be called? Another requirement is that the gpio
> > need to be set in the correct order.
>
> Have you seen:
>
> drivers/power/reset/gpio-poweroff.c
>
> It currently only allows for a single gpio, but it would not be too
> hard to extend it for multiple gpios.
>
> Andrew
>
^ permalink raw reply
* [PATCH v4] gpio: davinci: reuse for keystone soc
From: Grygorii Strashko @ 2014-02-12 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbrs==tpUBs=WLWkt0frBcSMRDRokOn2tvP-1gt7Qq3+w@mail.gmail.com>
Hi Linus,
On 02/12/2014 05:03 PM, Linus Walleij wrote:
> On Wed, Feb 5, 2014 at 4:47 PM, Grygorii Strashko
> <grygorii.strashko@ti.com> wrote:
>
>> The similar GPIO HW block is used by keystone SoCs as
>> in Davinci SoCs.
>> Hence, reuse Davinci GPIO driver for Keystone taking into
>> account that Keystone contains ARM GIC IRQ controller which
>> is implemented using IRQ Chip.
>>
>> Documentation:
>> http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf
>>
>> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>> ---
>> Changes in v4:
>> - rebased on top of v3.14 +
>> [patch] gpio: davinci: signedness bug in davinci_gpio_irq_setup()
>
> I tried applying this and it does not apply on the "devel" branch
> in the GPIO tree. Since I haven't touched one line of code in the
> DaVinci driver since v3.14-rc1 I seriously doubt that this is
> rebased on v3.14[-rc].
>
> Can you please rebase the patch onto v3.14-rc1 for real and
> resend it?
Sorry, But I've to clarify that this patch is based on:
http://www.spinics.net/lists/linux-kernel-janitors/msg18017.html
[patch] gpio: davinci: signedness bug in davinci_gpio_irq_setup()
And I did it to avoid merge conflicts between these two patches.
Is it possible to apply above one first? It's not in any of your
branches.
Of Course, I can re-base this patch on clean v3.14-rc1, but then merge
conflict will happen with "gpio: davinci: signedness.." patch.
Regards,
- grygorii
^ permalink raw reply
* [PATCH v2 0/9] ARM: multi-platform kconfig cleanup and mach-virt removal
From: Arnd Bergmann @ 2014-02-12 18:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212171621.GI29132@mudshark.cambridge.arm.com>
On Wednesday 12 February 2014 17:16:21 Will Deacon wrote:
> On Wed, Feb 12, 2014 at 05:11:45PM +0000, Marc Zyngier wrote:
> > On 12/02/14 16:53, Arnd Bergmann wrote:
> > >
> > > On the topic of V6, we don't support CPU_V6T2 at all, though I assume that
> > > there is an ARM1156 core tile for integrator and realview, and we support
> > > running the V6/V6K parts with MMU turned off. Would all revisions of ARM1156
> > > work with CPU_V6K and !MMU?
> >
> > CPU_V6 and !MMU should work. V6K might, but that requires close
> > inspection (WFE, SEV shouldn't be used in UP context)...
>
> Well I can boot Debian on my 1136 r0p1 (no v6k) using a v6/v7 kernel, so the
> lack of MMU shouldn't change that.
I was more worried about ARM1156 not being a strict superset of V6K, i.e.
stuff other than the MMU missing from it that the kernel would rely on.
Arnd
^ permalink raw reply
* [PATCH 2/3] PCI: ARM: add support for virtual PCI host controller
From: Will Deacon @ 2014-02-12 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140207175410.GC16263@obsidianresearch.com>
On Fri, Feb 07, 2014 at 05:54:10PM +0000, Jason Gunthorpe wrote:
> On Fri, Feb 07, 2014 at 11:46:07AM +0000, Will Deacon wrote:
>
> > > In practice, there can be various ways that a system requires something
> > > more complex:
> > >
> > > * You can have a memory space range that puts PCI bus address zero
> > > at the start of the pci->mem resource. In this case, you have
> > > mem_offset = pci->mem.start. We should probably try not to do
> > > this, but there is existing hardware doing it.
> >
> > If it's not the common case, then the generic driver might not need to care
> > (at least, initially).
>
> Something to think about, other people are going to reference this
> driver when writing drivers for their own hardware, it would be nice
> to see it perfect..
>
> AFAIK, the job is fairly simple, when you call pci_add_resource_offset
> for memory compute the offset from
> of_pci_range.pci_addr - of_pci_range.cpu_addr
>
> (or is it the other way around ?)
I think it's the other way round: bus = cpu - offset, then Arnd's example of
PCI bus 0 works out as: 0 = cpu - pci->mem_start.
I added that to my driver, but I get some weird looking bus addresses in
dmesg:
[ 0.307585] pci-arm-generic 40000000.pci: PCI host bridge to bus 0000:00
[ 0.307601] pci_bus 0000:00: root bus resource [io 0x0000-0xffff]
[ 0.307615] pci_bus 0000:00: root bus resource [mem 0x00000000-0x3effffff] (bus address [0xffffffffbf000000-0xfffffffffdffffff])
Looking at drivers/pci/probe.c, it seems to think that res->start - offset
gives a bus address, which implies that the resources are indeed *CPU*
addresses.
Are you sure pci_add_resource_offset wants bus addresses?
Will
^ permalink raw reply
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family
From: Catalin Marinas @ 2014-02-12 18:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B1132DDA-ECB1-4971-98AE-6DDDDD985CFB@codeaurora.org>
On 12 Feb 2014, at 16:25, Kumar Gala <galak@codeaurora.org> wrote:
> On Feb 12, 2014, at 4:38 AM, Catalin Marinas <catalin.marinas@arm.com> wrote:
>
>> On Tue, Feb 11, 2014 at 11:39:27PM +0000, Olof Johansson wrote:
>>> On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
>>>> This patch adds support for Samsung GH7 SoC in arm64/Kconfig.
>>>>
>>>> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
>>>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>>>
>>> The overhead of building one more device tree isn't very large, and I
>>> don't see any other need to have a Kconfig entry per SoC at this time.
>>> It's of course up to Catalin, but you might just want to always
>>> compile all dts files instead.
>>
>> For arm64, I thought of getting rid of ARCH_* Kconfig entries entirely,
>> only that I haven't heard any strong opinion either way (in which case
>> I'll do it, with a risk of single Image getting bigger and bigger and
>> people needing smaller Image can trim their .config).
>
> One reason to keep around ARCH_* is for drivers shared between arm and arm64 that depend on it.
We already converted some of them (those depending on ARCH_VEXPRESS) to
just depend on ARM64. Ideally, at some point I?d like to see them as
defaulting to modules but I don?t think we are there yet (we had some
discussions at the last KS, I?m not sure anyone started looking into
this).
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox