* [PATCH v2] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Bartlomiej Zolnierkiewicz @ 2016-12-15 11:55 UTC (permalink / raw)
To: linux-arm-kernel
Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
(for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
cooling maps to account for new OPPs.
Since new OPPs are not available on all Exynos5422/5800 boards modify
dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
Tested on Odroid-XU3 and XU3 Lite.
Cc: Doug Anderson <dianders@chromium.org>
Cc: Javier Martinez Canillas <javier@osg.samsung.com>
Cc: Andreas Faerber <afaerber@suse.de>
Cc: Thomas Abraham <thomas.ab@samsung.com>
Cc: Ben Gamari <ben@smart-cactus.org>
Cc: Arjun K V <arjun.kv@samsung.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
---
v2:
- added comments about limitations of SoC revisions used by Odroid-XU3 Lite and
Peach Pi boards (suggested by Javier)
- removed redundant opp_a7_14 label
- added Arjun to Cc:
Javier, could you test it on Peach Pi board?
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 ++++++-------
arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 22 +++++++++++++++++++++
arch/arm/boot/dts/exynos5800-peach-pi.dts | 9 ++++++++
arch/arm/boot/dts/exynos5800.dtsi | 15 ++++++++++++++
4 files changed, 53 insertions(+), 7 deletions(-)
Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
===================================================================
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-15 12:43:54.365955950 +0100
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-15 12:43:54.361955949 +0100
@@ -118,7 +118,7 @@
/*
* When reaching cpu_alert3, reduce CPU
* by 2 steps. On Exynos5422/5800 that would
- * be: 1600 MHz and 1100 MHz.
+ * (usually) be: 1800 MHz and 1200 MHz.
*/
map3 {
trip = <&cpu_alert3>;
@@ -131,16 +131,16 @@
/*
* When reaching cpu_alert4, reduce CPU
- * further, down to 600 MHz (11 steps for big,
- * 7 steps for LITTLE).
+ * further, down to 600 MHz (13 steps for big,
+ * 8 steps for LITTLE).
*/
- map5 {
+ cooling_map5: map5 {
trip = <&cpu_alert4>;
- cooling-device = <&cpu0 3 7>;
+ cooling-device = <&cpu0 3 8>;
};
- map6 {
+ cooling_map6: map6 {
trip = <&cpu_alert4>;
- cooling-device = <&cpu4 3 11>;
+ cooling-device = <&cpu4 3 13>;
};
};
};
Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
===================================================================
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-15 12:43:54.365955950 +0100
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-15 12:43:54.361955949 +0100
@@ -21,6 +21,28 @@
compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
};
+/*
+ * Odroid XU3-Lite board uses SoC revision with lower maximum frequencies
+ * than Odroid XU3/XU4 boards: 1.8 GHz for A15 cores & 1.3 GHz for A7 cores.
+ * Therefore we need to update OPPs tables and thermal maps accordingly.
+ */
+&cluster_a15_opp_table {
+ /delete-node/opp at 2000000000;
+ /delete-node/opp at 1900000000;
+};
+
+&cluster_a7_opp_table {
+ /delete-node/opp at 1400000000;
+};
+
+&cooling_map5 {
+ cooling-device = <&cpu0 3 7>;
+};
+
+&cooling_map6 {
+ cooling-device = <&cpu4 3 11>;
+};
+
&pwm {
/*
* PWM 0 -- fan
Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
===================================================================
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-15 12:43:54.365955950 +0100
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-15 12:43:54.361955949 +0100
@@ -146,6 +146,15 @@
vdd-supply = <&ldo9_reg>;
};
+/*
+ * Peach Pi board uses SoC revision with lower maximum frequency for A7 cores
+ * (1.3 GHz instead of 1.4 GHz) than Odroid XU3/XU4 boards. Thus we need to
+ * update A7 OPPs table accordingly.
+ */
+&cluster_a7_opp_table {
+ /delete-property/opp at 1400000000;
+};
+
&cpu0 {
cpu-supply = <&buck2_reg>;
};
Index: b/arch/arm/boot/dts/exynos5800.dtsi
===================================================================
--- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-15 12:43:54.365955950 +0100
+++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-15 12:43:54.361955949 +0100
@@ -24,6 +24,16 @@
};
&cluster_a15_opp_table {
+ opp at 2000000000 {
+ opp-hz = /bits/ 64 <2000000000>;
+ opp-microvolt = <1250000>;
+ clock-latency-ns = <140000>;
+ };
+ opp at 1900000000 {
+ opp-hz = /bits/ 64 <1900000000>;
+ opp-microvolt = <1250000>;
+ clock-latency-ns = <140000>;
+ };
opp at 1700000000 {
opp-microvolt = <1250000>;
};
@@ -85,6 +95,11 @@
};
&cluster_a7_opp_table {
+ opp at 1400000000 {
+ opp-hz = /bits/ 64 <1400000000>;
+ opp-microvolt = <1250000>;
+ clock-latency-ns = <140000>;
+ };
opp at 1300000000 {
opp-microvolt = <1250000>;
};
^ permalink raw reply
* Linux crashes when trying to online secondary core
From: Mark Rutland @ 2016-12-15 12:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1147ef90-7877-e4d2-bb2b-5c4fa8d3144b@free.fr>
On Thu, Dec 15, 2016 at 11:35:12AM +0100, Mason wrote:
> On 14/12/2016 18:47, Mason wrote:
> > On 14/12/2016 18:08, Thomas Gleixner wrote:
> >> Does the patch below fix the issue?
> >> diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
> >> index 22acee76cf4c..2594c287b078 100644
> >> --- a/include/linux/cpuhotplug.h
> >> +++ b/include/linux/cpuhotplug.h
> >> @@ -101,7 +101,6 @@ enum cpuhp_state {
> >> CPUHP_AP_ARM_L2X0_STARTING,
> >> CPUHP_AP_ARM_ARCH_TIMER_STARTING,
> >> CPUHP_AP_ARM_GLOBAL_TIMER_STARTING,
> >> - CPUHP_AP_DUMMY_TIMER_STARTING,
> >> CPUHP_AP_JCORE_TIMER_STARTING,
> >> CPUHP_AP_EXYNOS4_MCT_TIMER_STARTING,
> >> CPUHP_AP_ARM_TWD_STARTING,
> >> @@ -111,6 +110,7 @@ enum cpuhp_state {
> >> CPUHP_AP_MARCO_TIMER_STARTING,
> >> CPUHP_AP_MIPS_GIC_TIMER_STARTING,
> >> CPUHP_AP_ARC_TIMER_STARTING,
> >> + CPUHP_AP_DUMMY_TIMER_STARTING,
> >> CPUHP_AP_KVM_STARTING,
> >> CPUHP_AP_KVM_ARM_VGIC_INIT_STARTING,
> >> CPUHP_AP_KVM_ARM_VGIC_STARTING,
> > It does seem to fix the problem:
> > I reverted your patch, and the kernel blows up again.
> >
> > So what's the problem, and how does your patch solve it?
>
> Link to the original report:
> https://marc.info/?l=linux-arm-kernel&m=148173152524746&w=2
>
> Forgot to CC Robin Murphy, who had provided valuable input
> in similar circumstances a few months back.
>
> Also add LKML, since this doesn't appear to be ARM-specific.
>
> Do I need to specify which device tree I was using?
This is already fixed in the linux-tip tree, with commit messages
describing the fix.
It's specific to a few clocksources, due to their hotplug callbacks
occuring later than the dummy timer. That triggers the bug fixed in:
https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=timers/urgent&id=c1a9eeb938b5433947e5ea22f89baff3182e7075
The relevant timers were fixed in:
https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=smp/urgent&id=9bf11ecce5a2758e5a097c2f3a13d08552d0d6f9
Thanks,
Mark.
^ permalink raw reply
* [PATCH v2] ARM: dts: sunxi: Change node name for pwrseq pin on Olinuxino-lime2-emmc
From: Maxime Ripard @ 2016-12-15 12:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161215123533.f7e2373d2a9eb113ee7b0600@bidouilliste.com>
On Thu, Dec 15, 2016 at 12:35:33PM +0100, Emmanuel Vadot wrote:
>
> Hi Maxime,
>
> On Wed, 14 Dec 2016 16:30:13 +0100
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>
> > On Wed, Dec 14, 2016 at 03:57:24PM +0100, Emmanuel Vadot wrote:
> > > The node name for the power seq pin is mmc2 at 0 like the mmc2_pins_a one.
> > > This makes the original node (mmc2_pins_a) scrapped out of the dtb and
> > > result in a unusable eMMC if U-Boot didn't configured the pins to the
> > > correct functions.
> > >
> > > Changes since v1:
> > > * Rename the node mmc2-rst-pin
> >
> > That changelog should be after the ---. Removed it and applied.
> >
> > Thanks!
> > Maxime
>
> Sorry, still kinda new at doing patches for Linux, will be more
> carefull next time.
> Quick question, when you say applied, applied where exactly ? I had a
> quick look at your branches on git.kernel.org didn't find anything.
In general, my tree on kernel.org.
In this case, my local tree for now. We're right in the middle of the
merge window for 4.10, so in order not to pollute next and not to
confuse everyone (or rebasing a branch at some point), I just gather
the patches here. I'll publish a branch based on 4.10 as soon as
4.10-rc1 is released.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161215/74075136/attachment.sig>
^ permalink raw reply
* Applied "ASoC: atmel: tse850: rely on the ssc to register as a cpu dai by itself" to the asoc tree
From: Mark Brown @ 2016-12-15 12:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481052157-23400-3-git-send-email-peda@axentia.se>
The patch
ASoC: atmel: tse850: rely on the ssc to register as a cpu dai by itself
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From ca8c7f233fa2c40e2a23f982dc33d947f28ad207 Mon Sep 17 00:00:00 2001
From: Peter Rosin <peda@axentia.se>
Date: Tue, 6 Dec 2016 20:22:37 +0100
Subject: [PATCH] ASoC: atmel: tse850: rely on the ssc to register as a cpu dai
by itself
This breaks devicetree compatibility, but in this case that is ok. All
affected units are either on my desk, or running an even older version
of the driver that is not compatible with the upstreamed version anyway
(and when these other units are eventually updated, they will get a
fresh dtb as well, so that is not a significant problem either).
All of that is of course assuming that noone else has managed to build
something that can use this driver, but that seems extremely improbable.
Signed-off-by: Peter Rosin <peda@axentia.se>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
.../bindings/sound/axentia,tse850-pcm5142.txt | 11 ++++++++---
sound/soc/atmel/tse850-pcm5142.c | 23 +++-------------------
2 files changed, 11 insertions(+), 23 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt b/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
index 5b9b38f578bb..fdb25b492514 100644
--- a/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
+++ b/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
@@ -2,8 +2,7 @@ Devicetree bindings for the Axentia TSE-850 audio complex
Required properties:
- compatible: "axentia,tse850-pcm5142"
- - axentia,ssc-controller: The phandle of the atmel SSC controller used as
- cpu dai.
+ - axentia,cpu-dai: The phandle of the cpu dai.
- axentia,audio-codec: The phandle of the PCM5142 codec.
- axentia,add-gpios: gpio specifier that controls the mixer.
- axentia,loop1-gpios: gpio specifier that controls loop relays on channel 1.
@@ -43,6 +42,12 @@ the PCM5142 codec.
Example:
+ &ssc0 {
+ #sound-dai-cells = <0>;
+
+ status = "okay";
+ };
+
&i2c {
codec: pcm5142 at 4c {
compatible = "ti,pcm5142";
@@ -77,7 +82,7 @@ Example:
sound {
compatible = "axentia,tse850-pcm5142";
- axentia,ssc-controller = <&ssc0>;
+ axentia,cpu-dai = <&ssc0>;
axentia,audio-codec = <&codec>;
axentia,add-gpios = <&pioA 8 GPIO_ACTIVE_LOW>;
diff --git a/sound/soc/atmel/tse850-pcm5142.c b/sound/soc/atmel/tse850-pcm5142.c
index ac6a814c8ecf..a72c7d642026 100644
--- a/sound/soc/atmel/tse850-pcm5142.c
+++ b/sound/soc/atmel/tse850-pcm5142.c
@@ -51,11 +51,7 @@
#include <sound/soc.h>
#include <sound/pcm_params.h>
-#include "atmel_ssc_dai.h"
-
struct tse850_priv {
- int ssc_id;
-
struct gpio_desc *add;
struct gpio_desc *loop1;
struct gpio_desc *loop2;
@@ -329,23 +325,20 @@ static int tse850_dt_init(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct device_node *codec_np, *cpu_np;
- struct snd_soc_card *card = &tse850_card;
struct snd_soc_dai_link *dailink = &tse850_dailink;
- struct tse850_priv *tse850 = snd_soc_card_get_drvdata(card);
if (!np) {
dev_err(&pdev->dev, "only device tree supported\n");
return -EINVAL;
}
- cpu_np = of_parse_phandle(np, "axentia,ssc-controller", 0);
+ cpu_np = of_parse_phandle(np, "axentia,cpu-dai", 0);
if (!cpu_np) {
- dev_err(&pdev->dev, "failed to get dai and pcm info\n");
+ dev_err(&pdev->dev, "failed to get cpu dai\n");
return -EINVAL;
}
dailink->cpu_of_node = cpu_np;
dailink->platform_of_node = cpu_np;
- tse850->ssc_id = of_alias_get_id(cpu_np, "ssc");
of_node_put(cpu_np);
codec_np = of_parse_phandle(np, "axentia,audio-codec", 0);
@@ -415,23 +408,14 @@ static int tse850_probe(struct platform_device *pdev)
return ret;
}
- ret = atmel_ssc_set_audio(tse850->ssc_id);
- if (ret != 0) {
- dev_err(dev,
- "failed to set SSC %d for audio\n", tse850->ssc_id);
- goto err_disable_ana;
- }
-
ret = snd_soc_register_card(card);
if (ret) {
dev_err(dev, "snd_soc_register_card failed\n");
- goto err_put_audio;
+ goto err_disable_ana;
}
return 0;
-err_put_audio:
- atmel_ssc_put_audio(tse850->ssc_id);
err_disable_ana:
regulator_disable(tse850->ana);
return ret;
@@ -443,7 +427,6 @@ static int tse850_remove(struct platform_device *pdev)
struct tse850_priv *tse850 = snd_soc_card_get_drvdata(card);
snd_soc_unregister_card(card);
- atmel_ssc_put_audio(tse850->ssc_id);
regulator_disable(tse850->ana);
return 0;
--
2.11.0
^ permalink raw reply related
* Applied "misc: atmel-ssc: register as sound DAI if #sound-dai-cells is present" to the asoc tree
From: Mark Brown @ 2016-12-15 12:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480593549-6464-2-git-send-email-peda@axentia.se>
The patch
misc: atmel-ssc: register as sound DAI if #sound-dai-cells is present
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From e8314d7d53c8b050aac2828a5de5f28a997b468b Mon Sep 17 00:00:00 2001
From: Peter Rosin <peda@axentia.se>
Date: Tue, 6 Dec 2016 20:22:36 +0100
Subject: [PATCH] misc: atmel-ssc: register as sound DAI if #sound-dai-cells is
present
The SSC is currently not usable with the ASoC simple-audio-card, as
every SSC audio user has to build a platform driver that may do as
little as calling atmel_ssc_set_audio/atmel_ssc_put_audio (which
allocates the SSC and registers a DAI with the ASoC subsystem).
So, have that happen automatically, if the #sound-dai-cells property
is present in devicetree, which it has to be anyway for simple audio
card to work.
Signed-off-by: Peter Rosin <peda@axentia.se>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
.../devicetree/bindings/misc/atmel-ssc.txt | 2 +
drivers/misc/atmel-ssc.c | 50 ++++++++++++++++++++++
include/linux/atmel-ssc.h | 1 +
3 files changed, 53 insertions(+)
diff --git a/Documentation/devicetree/bindings/misc/atmel-ssc.txt b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
index efc98ea1f23d..f8629bb73945 100644
--- a/Documentation/devicetree/bindings/misc/atmel-ssc.txt
+++ b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
@@ -24,6 +24,8 @@ Optional properties:
this parameter to choose where the clock from.
- By default the clock is from TK pin, if the clock from RK pin, this
property is needed.
+ - #sound-dai-cells: Should contain <0>.
+ - This property makes the SSC into an automatically registered DAI.
Examples:
- PDC transfer:
diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
index 0516ecda54d3..b2a0340f277e 100644
--- a/drivers/misc/atmel-ssc.c
+++ b/drivers/misc/atmel-ssc.c
@@ -20,6 +20,8 @@
#include <linux/of.h>
+#include "../../sound/soc/atmel/atmel_ssc_dai.h"
+
/* Serialize access to ssc_list and user count */
static DEFINE_SPINLOCK(user_lock);
static LIST_HEAD(ssc_list);
@@ -145,6 +147,49 @@ static inline const struct atmel_ssc_platform_data * __init
platform_get_device_id(pdev)->driver_data;
}
+#ifdef CONFIG_SND_ATMEL_SOC_SSC
+static int ssc_sound_dai_probe(struct ssc_device *ssc)
+{
+ struct device_node *np = ssc->pdev->dev.of_node;
+ int ret;
+ int id;
+
+ ssc->sound_dai = false;
+
+ if (!of_property_read_bool(np, "#sound-dai-cells"))
+ return 0;
+
+ id = of_alias_get_id(np, "ssc");
+ if (id < 0)
+ return id;
+
+ ret = atmel_ssc_set_audio(id);
+ ssc->sound_dai = !ret;
+
+ return ret;
+}
+
+static void ssc_sound_dai_remove(struct ssc_device *ssc)
+{
+ if (!ssc->sound_dai)
+ return;
+
+ atmel_ssc_put_audio(of_alias_get_id(ssc->pdev->dev.of_node, "ssc"));
+}
+#else
+static inline int ssc_sound_dai_probe(struct ssc_device *ssc)
+{
+ if (of_property_read_bool(ssc->pdev->dev.of_node, "#sound-dai-cells"))
+ return -ENOTSUPP;
+
+ return 0;
+}
+
+static inline void ssc_sound_dai_remove(struct ssc_device *ssc)
+{
+}
+#endif
+
static int ssc_probe(struct platform_device *pdev)
{
struct resource *regs;
@@ -204,6 +249,9 @@ static int ssc_probe(struct platform_device *pdev)
dev_info(&pdev->dev, "Atmel SSC device at 0x%p (irq %d)\n",
ssc->regs, ssc->irq);
+ if (ssc_sound_dai_probe(ssc))
+ dev_err(&pdev->dev, "failed to auto-setup ssc for audio\n");
+
return 0;
}
@@ -211,6 +259,8 @@ static int ssc_remove(struct platform_device *pdev)
{
struct ssc_device *ssc = platform_get_drvdata(pdev);
+ ssc_sound_dai_remove(ssc);
+
spin_lock(&user_lock);
list_del(&ssc->list);
spin_unlock(&user_lock);
diff --git a/include/linux/atmel-ssc.h b/include/linux/atmel-ssc.h
index 7c0f6549898b..fdb545101ede 100644
--- a/include/linux/atmel-ssc.h
+++ b/include/linux/atmel-ssc.h
@@ -20,6 +20,7 @@ struct ssc_device {
int user;
int irq;
bool clk_from_rk_pin;
+ bool sound_dai;
};
struct ssc_device * __must_check ssc_request(unsigned int ssc_num);
--
2.11.0
^ permalink raw reply related
* Applied "ASoC: samsung: Remove tests of member address" to the asoc tree
From: Mark Brown @ 2016-12-15 12:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481363471-21364-1-git-send-email-krzk@kernel.org>
The patch
ASoC: samsung: Remove tests of member address
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 409c69be433b819c924a8d1c457a835bc6d51700 Mon Sep 17 00:00:00 2001
From: Krzysztof Kozlowski <krzk@kernel.org>
Date: Sat, 10 Dec 2016 11:51:11 +0200
Subject: [PATCH] ASoC: samsung: Remove tests of member address
The driver was checking for non-NULL address of struct's members:
- s3c_audio_pdata->type (union),
- s3c_audio_pdata->type.i2s (embedded struct).
This is pointless as these will be always non-NULL. The 's3c_audio_pdata'
is always initialized in static memory so it will be zeroed.
Additionally the 'type' member was an union with only one member.
It is safe to reorganize the structures to get rid of useless union and
checks for addresses to fix the coccinelle warning:
>> sound/soc/samsung/i2s.c:1270:2-4: ERROR: test of a variable/field address
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
arch/arm/mach-s3c64xx/dev-audio.c | 4 +---
include/linux/platform_data/asoc-s3c.h | 6 ++----
sound/soc/samsung/i2s.c | 10 ++--------
3 files changed, 5 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/dev-audio.c b/arch/arm/mach-s3c64xx/dev-audio.c
index b57783371d52..247dcc0b691e 100644
--- a/arch/arm/mach-s3c64xx/dev-audio.c
+++ b/arch/arm/mach-s3c64xx/dev-audio.c
@@ -106,9 +106,7 @@ static struct s3c_audio_pdata i2sv4_pdata = {
.dma_playback = DMACH_HSI_I2SV40_TX,
.dma_capture = DMACH_HSI_I2SV40_RX,
.type = {
- .i2s = {
- .quirks = QUIRK_PRI_6CHAN,
- },
+ .quirks = QUIRK_PRI_6CHAN,
},
};
diff --git a/include/linux/platform_data/asoc-s3c.h b/include/linux/platform_data/asoc-s3c.h
index 15bf56ee8af7..90641a5daaf0 100644
--- a/include/linux/platform_data/asoc-s3c.h
+++ b/include/linux/platform_data/asoc-s3c.h
@@ -18,7 +18,7 @@
extern void s3c64xx_ac97_setup_gpio(int);
-struct samsung_i2s {
+struct samsung_i2s_type {
/* If the Primary DAI has 5.1 Channels */
#define QUIRK_PRI_6CHAN (1 << 0)
/* If the I2S block has a Stereo Overlay Channel */
@@ -47,7 +47,5 @@ struct s3c_audio_pdata {
void *dma_capture;
void *dma_play_sec;
void *dma_capture_mic;
- union {
- struct samsung_i2s i2s;
- } type;
+ struct samsung_i2s_type type;
};
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index e00974bc5616..d55326289a4a 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -1218,7 +1218,6 @@ static int samsung_i2s_probe(struct platform_device *pdev)
{
struct i2s_dai *pri_dai, *sec_dai = NULL;
struct s3c_audio_pdata *i2s_pdata = pdev->dev.platform_data;
- struct samsung_i2s *i2s_cfg = NULL;
struct resource *res;
u32 regs_base, quirks = 0, idma_addr = 0;
struct device_node *np = pdev->dev.of_node;
@@ -1267,13 +1266,8 @@ static int samsung_i2s_probe(struct platform_device *pdev)
pri_dai->dma_capture.filter_data = i2s_pdata->dma_capture;
pri_dai->filter = i2s_pdata->dma_filter;
- if (&i2s_pdata->type)
- i2s_cfg = &i2s_pdata->type.i2s;
-
- if (i2s_cfg) {
- quirks = i2s_cfg->quirks;
- idma_addr = i2s_cfg->idma_addr;
- }
+ quirks = i2s_pdata->type.quirks;
+ idma_addr = i2s_pdata->type.idma_addr;
} else {
quirks = i2s_dai_data->quirks;
if (of_property_read_u32(np, "samsung,idma-addr",
--
2.11.0
^ permalink raw reply related
* [PATCH 0/3] clkdev: add devm_get_clk_from_child()
From: Mark Brown @ 2016-12-15 12:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8737hyymo9.wl%kuninori.morimoto.gx@renesas.com>
On Fri, Dec 09, 2016 at 12:25:48AM +0000, Kuninori Morimoto wrote:
> Mark, I think I should re-post 2nd patch (3rd will be dropped) after
> merge window ? There will be no branch dependency
Should be fine without but obviously if it looks like it's gone AWOL
then reposting would be good.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161215/d9c5690a/attachment.sig>
^ permalink raw reply
* [PATCH v3 0/5] boot-wrapper: arm64: Xen support
From: Andre Przywara @ 2016-12-15 12:27 UTC (permalink / raw)
To: linux-arm-kernel
These patches allow to include a Xen hypervisor binary into a boot-wrapper
ELF file, so that a Foundation Platform or a Fast Model can boot a Xen
system (including a Dom0 kernel).
The original patches have been around for a while, so this series is
merely an update to apply on the latest boot-wrapper HEAD. Also I fixed
minor things here and there (like increasing Xen's load address to
accomodate for Dom0 kernels bigger than 16 MB) and addressed Julien's
review comments.
For testing this just add: "--with-xen=/path/to/src/xen/xen" to the
./configure command line and feed the resulting xen-system.axf file to
the model.
Also this release folds in a cross-compilation fix to avoid pointless
merge conflicts.
Cheers,
Andre.
Changelog v1 .. v2:
- use "xen-cmdline" instead of bootargs as parameter and variable name
- move hunk in patch 1/4 to make patch 2/4 smaller
- replace AC_FILE_CHECK macro usage to fix cross compilation
Changelog v2 .. v3:
- fix spelling typos as pointed out by Julien
- include cross-compilation fix
- add Tested-by: and Reviewed-by: tags
Andre Przywara (1):
configure: fix file detection when cross-compiling
Christoffer Dall (3):
Support for building in a Xen binary
Xen: Support adding DT nodes
Explicitly clean linux-system.axf and xen-system.axf
Ian Campbell (1):
Xen: Select correct dom0 console
.gitignore | 1 +
Makefile.am | 35 +++++++++++++++++++++++------------
boot_common.c | 4 ++--
configure.ac | 52 ++++++++++++++++++++++++++++++++++++++++++++++------
model.lds.S | 14 ++++++++++++++
5 files changed, 86 insertions(+), 20 deletions(-)
--
2.9.0
^ permalink raw reply
* [PATCH v3 1/5] configure: fix file detection when cross-compiling
From: Andre Przywara @ 2016-12-15 12:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161215122718.21422-1-andre.przywara@arm.com>
The autotools documentation states that AC_CHECK_FILE cannot be used when
cross-compiling [1], because it's meant to check files in the target
system, not on the build host. When just giving --host on the configure
command line, the script detects cross compilation rather late; and as the
file test just happens to execute earlier, this works anyway.
However if one gives both --host and --build, cross compilation is
detected very early and ./configure complains:
checking for /src/linux-arm64... configure: error: cannot check for file existence when cross compiling
So replace the checkfile macro usage with a simple "test -f" call (which
is the recommended way of checking for files on the build host) and output
proper error messages.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
[1] https://www.gnu.org/software/autoconf/manual/autoconf.html#Files
---
configure.ac | 23 ++++++++++++++++++-----
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/configure.ac b/configure.ac
index ab8f5b3..e0daec4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -41,12 +41,25 @@ AC_ARG_WITH([dtb],
[KERN_DTB="$withval"])
# Ensure that the user has provided us with a sane kernel dir.
-m4_define([CHECKFILES], [KERN_DIR,
- KERN_DTB,
- KERN_IMAGE])
+if ! test -d $KERN_DIR; then
+ AC_MSG_ERROR([Could not find Linux kernel dir $KERN_DIR.])
+fi
+
+AC_MSG_CHECKING([whether DTB file exists])
+if ! test -f $KERN_DTB; then
+ AC_MSG_RESULT([no])
+ AC_MSG_ERROR([You need to specify a valid DTB file, could not find: $KERN_DTB])
+else
+ AC_MSG_RESULT([yes])
+fi
-m4_foreach([checkfile], [CHECKFILES],
- [AC_CHECK_FILE([$checkfile], [], AC_MSG_ERROR([No such file or directory: $checkfile]))])
+AC_MSG_CHECKING([whether kernel image exists])
+if ! test -f $KERN_IMAGE; then
+ AC_MSG_RESULT([no])
+ AC_MSG_ERROR([You need to compile a kernel first, could not find: $KERN_IMAGE])
+else
+ AC_MSG_RESULT([yes])
+fi
AC_SUBST([KERNEL_IMAGE], [$KERN_IMAGE])
AC_SUBST([KERNEL_DTB], [$KERN_DTB])
--
2.9.0
^ permalink raw reply related
* [PATCH v3 2/5] Support for building in a Xen binary
From: Andre Przywara @ 2016-12-15 12:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161215122718.21422-1-andre.przywara@arm.com>
From: Christoffer Dall <christoffer.dall@linaro.org>
Add support for building a Xen binary which includes a Dom0 image and
the Dom0 command-line.
If the user specifies --with-xen=<Xen>, where Xen is an appropriate
AArch64 Xen binary, the build system will generate a xen-system.axf
instead of a linux-system.axf.
Original patch from Ian Campbell, but I modified most of it so all bugs
are probably mine.
[Andre: adapt to newest boot-wrapper branch, increase load address,
fixup Xen image file test]
Cc: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
---
.gitignore | 1 +
Makefile.am | 10 +++++++---
boot_common.c | 4 ++--
configure.ac | 17 +++++++++++++++++
model.lds.S | 14 ++++++++++++++
5 files changed, 41 insertions(+), 5 deletions(-)
diff --git a/.gitignore b/.gitignore
index 8653852..80770c0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -14,6 +14,7 @@ configure
dtc
fdt.dtb
Image
+Xen
install-sh
Makefile
Makefile.in
diff --git a/Makefile.am b/Makefile.am
index 692d2cc..f8b9ec9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -85,7 +85,6 @@ TEXT_LIMIT := 0x80080000
endif
LD_SCRIPT := model.lds.S
-IMAGE := linux-system.axf
FS_OFFSET := 0x10000000
FILESYSTEM_START:= $(shell echo $$(($(PHYS_OFFSET) + $(FS_OFFSET))))
@@ -94,6 +93,11 @@ FILESYSTEM_END := $(shell echo $$(($(FILESYSTEM_START) + $(FILESYSTEM_SIZE))))
FDT_OFFSET := 0x08000000
+if XEN
+XEN := -DXEN=$(XEN_IMAGE)
+XEN_OFFSET := 0x08200000
+endif
+
if INITRD
INITRD_FLAGS := -DUSE_INITRD
CHOSEN_NODE := chosen { \
@@ -121,7 +125,7 @@ all: $(IMAGE)
CLEANFILES = $(IMAGE) $(OFILES) model.lds fdt.dtb
-$(IMAGE): $(OFILES) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM)
+$(IMAGE): $(OFILES) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM) $(XEN_IMAGE)
$(LD) $(LDFLAGS) $(OFILES) -o $@ --script=model.lds
%.o: %.S Makefile
@@ -131,7 +135,7 @@ $(IMAGE): $(OFILES) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM)
$(CC) $(CPPFLAGS) $(CFLAGS) $(DEFINES) -c -o $@ $<
model.lds: $(LD_SCRIPT) Makefile
- $(CPP) $(CPPFLAGS) -ansi -DPHYS_OFFSET=$(PHYS_OFFSET) -DMBOX_OFFSET=$(MBOX_OFFSET) -DKERNEL_OFFSET=$(KERNEL_OFFSET) -DFDT_OFFSET=$(FDT_OFFSET) -DFS_OFFSET=$(FS_OFFSET) -DKERNEL=$(KERNEL_IMAGE) -DFILESYSTEM=$(FILESYSTEM) -DTEXT_LIMIT=$(TEXT_LIMIT) -P -C -o $@ $<
+ $(CPP) $(CPPFLAGS) -ansi -DPHYS_OFFSET=$(PHYS_OFFSET) -DMBOX_OFFSET=$(MBOX_OFFSET) -DKERNEL_OFFSET=$(KERNEL_OFFSET) -DFDT_OFFSET=$(FDT_OFFSET) -DFS_OFFSET=$(FS_OFFSET) $(XEN) -DXEN_OFFSET=$(XEN_OFFSET) -DKERNEL=$(KERNEL_IMAGE) -DFILESYSTEM=$(FILESYSTEM) -DTEXT_LIMIT=$(TEXT_LIMIT) -P -C -o $@ $<
fdt.dtb: $(KERNEL_DTB) Makefile gen-cpu-nodes.sh
( $(DTC) -O dts -I dtb $(KERNEL_DTB) ; echo "/ { $(CHOSEN_NODE) $(PSCI_NODE) $(CPUS_NODE) };" ) | $(DTC) -O dtb -o $@ -
diff --git a/boot_common.c b/boot_common.c
index 4947fe3..e7b8e1d 100644
--- a/boot_common.c
+++ b/boot_common.c
@@ -9,7 +9,7 @@
#include <cpu.h>
#include <spin.h>
-extern unsigned long kernel;
+extern unsigned long entrypoint;
extern unsigned long dtb;
void init_platform(void);
@@ -67,7 +67,7 @@ void __noreturn first_spin(unsigned int cpu, unsigned long *mbox,
if (cpu == 0) {
init_platform();
- *mbox = (unsigned long)&kernel;
+ *mbox = (unsigned long)&entrypoint;
sevl();
spin(mbox, invalid, 1);
} else {
diff --git a/configure.ac b/configure.ac
index e0daec4..1d7cf3d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -40,6 +40,18 @@ AC_ARG_WITH([dtb],
AS_HELP_STRING([--with-dtb], [Specify a particular DTB to use]),
[KERN_DTB="$withval"])
+AC_ARG_WITH([xen],
+ AS_HELP_STRING([--with-xen], [Compile for Xen, and specify a particular Xen to use]),
+ X_IMAGE=$withval)
+
+AS_IF([test "x$X_IMAGE" == "x"], [],
+ [AS_IF([test ! -f "$X_IMAGE"],
+ [AC_MSG_ERROR([Could not find Xen hypervisor binary: $X_IMAGE])]
+ )]
+)
+AC_SUBST([XEN_IMAGE], [$X_IMAGE])
+AM_CONDITIONAL([XEN], [test "x$X_IMAGE" != "x"])
+
# Ensure that the user has provided us with a sane kernel dir.
if ! test -d $KERN_DIR; then
AC_MSG_ERROR([Could not find Linux kernel dir $KERN_DIR.])
@@ -63,6 +75,10 @@ fi
AC_SUBST([KERNEL_IMAGE], [$KERN_IMAGE])
AC_SUBST([KERNEL_DTB], [$KERN_DTB])
+AS_IF([test "x$X_IMAGE" != "x"],
+ [AC_SUBST([IMAGE], ["xen-system.axf"])],
+ [AC_SUBST([IMAGE], ["linux-system.axf"])]
+)
# Allow a user to pass --enable-psci
AC_ARG_ENABLE([psci],
@@ -132,4 +148,5 @@ echo " CPU IDs: ${CPU_IDS}"
echo " Use GICv3? ${USE_GICV3}"
echo " Boot-wrapper execution state: AArch${BOOTWRAPPER_ES}"
echo " Kernel execution state: AArch${KERNEL_ES}"
+echo " Xen image ${XEN_IMAGE:-NONE}"
echo ""
diff --git a/model.lds.S b/model.lds.S
index 51c5684..511f552 100644
--- a/model.lds.S
+++ b/model.lds.S
@@ -16,6 +16,9 @@ OUTPUT_ARCH(aarch64)
#endif
TARGET(binary)
+#ifdef XEN
+INPUT(XEN)
+#endif
INPUT(KERNEL)
INPUT(./fdt.dtb)
@@ -36,6 +39,17 @@ SECTIONS
KERNEL
}
+#ifdef XEN
+ .xen (PHYS_OFFSET + XEN_OFFSET): {
+ xen = .;
+ XEN
+ }
+
+ entrypoint = xen;
+#else
+ entrypoint = kernel;
+#endif
+
.dtb (PHYS_OFFSET + FDT_OFFSET): {
dtb = .;
./fdt.dtb
--
2.9.0
^ permalink raw reply related
* [PATCH v3 3/5] Xen: Support adding DT nodes
From: Andre Przywara @ 2016-12-15 12:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161215122718.21422-1-andre.przywara@arm.com>
From: Christoffer Dall <christoffer.dall@linaro.org>
Support adding xen,xen-bootargs node via --with-xen-cmdline to the
configure script and automatically add the Dom0 node to the DT as well.
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
---
Makefile.am | 23 +++++++++++++++--------
configure.ac | 9 +++++++++
2 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index f8b9ec9..db97f9c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -96,21 +96,28 @@ FDT_OFFSET := 0x08000000
if XEN
XEN := -DXEN=$(XEN_IMAGE)
XEN_OFFSET := 0x08200000
+KERNEL_SIZE := $(shell stat -Lc %s $(KERNEL_IMAGE) 2>/dev/null || echo 0)
+DOM0_OFFSET := $(shell echo $$(($(PHYS_OFFSET) + $(KERNEL_OFFSET))))
+XEN_BOOTARGS := xen,xen-bootargs = \"$(XEN_CMDLINE)\"; \
+ \#address-cells = <2>; \
+ \#size-cells = <2>; \
+ module at 1 { \
+ compatible = \"xen,linux-zimage\", \"xen,multiboot-module\"; \
+ reg = <0x0 $(DOM0_OFFSET) 0x0 $(KERNEL_SIZE)>; \
+ };
endif
if INITRD
INITRD_FLAGS := -DUSE_INITRD
+INITRD_CHOSEN := linux,initrd-start = <$(FILESYSTEM_START)>; \
+ linux,initrd-end = <$(FILESYSTEM_END)>;
+endif
+
CHOSEN_NODE := chosen { \
bootargs = \"$(CMDLINE)\"; \
- linux,initrd-start = <$(FILESYSTEM_START)>; \
- linux,initrd-end = <$(FILESYSTEM_END)>; \
- };
-else
-INITRD_FLAGS :=
-CHOSEN_NODE := chosen { \
- bootargs = \"$(CMDLINE)\"; \
+ $(INITRD_CHOSEN) \
+ $(XEN_BOOTARGS) \
};
-endif
CPPFLAGS += $(INITRD_FLAGS)
CFLAGS += -Iinclude/ -I$(ARCH_SRC)/include/
diff --git a/configure.ac b/configure.ac
index 1d7cf3d..ea02dca 100644
--- a/configure.ac
+++ b/configure.ac
@@ -111,6 +111,12 @@ AC_ARG_WITH([cmdline],
[C_CMDLINE=$withval])
AC_SUBST([CMDLINE], [$C_CMDLINE])
+X_CMDLINE="console=dtuart dtuart=serial0 no-bootscrub"
+AC_ARG_WITH([xen-cmdline],
+ AS_HELP_STRING([--with-xen-cmdline], [set Xen command line]),
+ [X_CMDLINE=$withval])
+AC_SUBST([XEN_CMDLINE], [$X_CMDLINE])
+
# Allow a user to pass --enable-gicv3
AC_ARG_ENABLE([gicv3],
AS_HELP_STRING([--enable-gicv3], [enable GICv3 instead of GICv2]),
@@ -149,4 +155,7 @@ echo " Use GICv3? ${USE_GICV3}"
echo " Boot-wrapper execution state: AArch${BOOTWRAPPER_ES}"
echo " Kernel execution state: AArch${KERNEL_ES}"
echo " Xen image ${XEN_IMAGE:-NONE}"
+if test "x${XEN_IMAGE}" != "x"; then
+echo " Xen command line: ${XEN_CMDLINE}"
+fi
echo ""
--
2.9.0
^ permalink raw reply related
* [PATCH v3 4/5] Xen: Select correct dom0 console
From: Andre Przywara @ 2016-12-15 12:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161215122718.21422-1-andre.przywara@arm.com>
From: Ian Campbell <ian.campbell@citrix.com>
If Xen is enabled, tell Dom0 to use the 'hvc0' console, and fall back to
the usual ttyAMA0 otherwise.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
configure.ac | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index ea02dca..d23cced 100644
--- a/configure.ac
+++ b/configure.ac
@@ -105,7 +105,8 @@ AC_ARG_WITH([initrd],
AC_SUBST([FILESYSTEM], [$USE_INITRD])
AM_CONDITIONAL([INITRD], [test "x$USE_INITRD" != "x"])
-C_CMDLINE="console=ttyAMA0 earlyprintk=pl011,0x1c090000"
+AS_IF([test "x$X_IMAGE" = "x"],[C_CONSOLE="ttyAMA0"],[C_CONSOLE="hvc0"])
+C_CMDLINE="console=$C_CONSOLE earlyprintk=pl011,0x1c090000"
AC_ARG_WITH([cmdline],
AS_HELP_STRING([--with-cmdline], [set a command line for the kernel]),
[C_CMDLINE=$withval])
--
2.9.0
^ permalink raw reply related
* [PATCH v3 5/5] Explicitly clean linux-system.axf and xen-system.axf
From: Andre Przywara @ 2016-12-15 12:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161215122718.21422-1-andre.przywara@arm.com>
From: Christoffer Dall <christoffer.dall@linaro.org>
When doing a make clean, only the output image currently configured to
build is being removed. However, one would expect all build artifacts
to be removed when doing a 'make clean' and when switching between Xen
and Linux builds, it is easy to accidentally run an older build than
intended. Simply hardcode the axf image file names.
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
Makefile.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile.am b/Makefile.am
index db97f9c..506a1d9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -130,7 +130,7 @@ OFILES += $(addprefix $(ARCH_SRC),boot.o stack.o $(BOOTMETHOD) utils.o)
all: $(IMAGE)
-CLEANFILES = $(IMAGE) $(OFILES) model.lds fdt.dtb
+CLEANFILES = $(IMAGE) linux-system.axf xen-system.axf $(OFILES) model.lds fdt.dtb
$(IMAGE): $(OFILES) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM) $(XEN_IMAGE)
$(LD) $(LDFLAGS) $(OFILES) -o $@ --script=model.lds
--
2.9.0
^ permalink raw reply related
* [PATCH v2] i2c: designware: add reset interface
From: Andy Shevchenko @ 2016-12-15 12:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481792388-13781-1-git-send-email-zhangfei.gao@linaro.org>
On Thu, 2016-12-15 at 16:59 +0800, Zhangfei Gao wrote:
> Some platforms like hi3660 need do reset first to allow accessing
> registers
Patch itself looks good, but would be nice to have it tested.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
> ---
> ?drivers/i2c/busses/i2c-designware-core.h????|??1 +
> ?drivers/i2c/busses/i2c-designware-platdrv.c | 28
> ++++++++++++++++++++++++----
> ?2 files changed, 25 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-designware-core.h
> b/drivers/i2c/busses/i2c-designware-core.h
> index 0d44d2a..94b14fa 100644
> --- a/drivers/i2c/busses/i2c-designware-core.h
> +++ b/drivers/i2c/busses/i2c-designware-core.h
> @@ -80,6 +80,7 @@ struct dw_i2c_dev {
> ? void __iomem *base;
> ? struct completion cmd_complete;
> ? struct clk *clk;
> + struct reset_control *rst;
> ? u32 (*get_clk_rate_khz) (struct
> dw_i2c_dev *dev);
> ? struct dw_pci_controller *controller;
> ? int cmd_err;
> diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
> b/drivers/i2c/busses/i2c-designware-platdrv.c
> index 0b42a12..e9016ae 100644
> --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
> @@ -38,6 +38,7 @@
> ?#include <linux/pm_runtime.h>
> ?#include <linux/property.h>
> ?#include <linux/io.h>
> +#include <linux/reset.h>
> ?#include <linux/slab.h>
> ?#include <linux/acpi.h>
> ?#include <linux/platform_data/i2c-designware.h>
> @@ -176,6 +177,14 @@ static int dw_i2c_plat_probe(struct
> platform_device *pdev)
> ? dev->irq = irq;
> ? platform_set_drvdata(pdev, dev);
> ?
> + dev->rst = devm_reset_control_get_optional(&pdev->dev, NULL);
> + if (IS_ERR(dev->rst)) {
> + if (PTR_ERR(dev->rst) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + } else {
> + reset_control_deassert(dev->rst);
> + }
> +
> ? /* fast mode by default because of legacy reasons */
> ? dev->clk_freq = 400000;
> ?
> @@ -207,12 +216,13 @@ static int dw_i2c_plat_probe(struct
> platform_device *pdev)
> ? ????&& dev->clk_freq != 1000000 && dev->clk_freq != 3400000)
> {
> ? dev_err(&pdev->dev,
> ? "Only 100kHz, 400kHz, 1MHz and 3.4MHz
> supported");
> - return -EINVAL;
> + r = -EINVAL;
> + goto exit_reset;
> ? }
> ?
> ? r = i2c_dw_eval_lock_support(dev);
> ? if (r)
> - return r;
> + goto exit_reset;
> ?
> ? dev->functionality =
> ? I2C_FUNC_I2C |
> @@ -270,10 +280,18 @@ static int dw_i2c_plat_probe(struct
> platform_device *pdev)
> ? }
> ?
> ? r = i2c_dw_probe(dev);
> - if (r && !dev->pm_runtime_disabled)
> - pm_runtime_disable(&pdev->dev);
> + if (r)
> + goto exit_probe;
> ?
> ? return r;
> +
> +exit_probe:
> + if (!dev->pm_runtime_disabled)
> + pm_runtime_disable(&pdev->dev);
> +exit_reset:
> + if (!IS_ERR_OR_NULL(dev->rst))
> + reset_control_assert(dev->rst);
> + return r;
> ?}
> ?
> ?static int dw_i2c_plat_remove(struct platform_device *pdev)
> @@ -290,6 +308,8 @@ static int dw_i2c_plat_remove(struct
> platform_device *pdev)
> ? pm_runtime_put_sync(&pdev->dev);
> ? if (!dev->pm_runtime_disabled)
> ? pm_runtime_disable(&pdev->dev);
> + if (!IS_ERR_OR_NULL(dev->rst))
> + reset_control_assert(dev->rst);
> ?
> ? return 0;
> ?}
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* [PATCH] trace: extend trace_clock to support arch_arm clock counter
From: Srinivas Ramana @ 2016-12-15 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212104243.GA21248@arm.com>
On 12/12/2016 04:12 PM, Will Deacon wrote:
> On Mon, Dec 12, 2016 at 10:31:52AM +0530, Srinivas Ramana wrote:
>> On 12/06/2016 05:43 PM, Will Deacon wrote:
>>> On Sun, Dec 04, 2016 at 02:06:23PM +0530, Srinivas Ramana wrote:
>>>> On 12/02/2016 04:38 PM, Will Deacon wrote:
>>>>> On Fri, Dec 02, 2016 at 01:44:55PM +0530, Srinivas Ramana wrote:
>>>>>> Extend the trace_clock to support the arch timer cycle
>>>>>> counter so that we can get the monotonic cycle count
>>>>>> in the traces. This will help in correlating the traces with the
>>>>>> timestamps/events in other subsystems in the soc which share
>>>>>> this common counter for driving their timers.
>>>>>
>>>>> I'm not sure I follow this reasoning. What's wrong with nanoseconds? In
>>>>> particular, the "perf" trace_clock hangs off sched_clock, which should
>>>>> be backed by the architected counter anyway. What does the cycle counter in
>>>>> isolation tell you, given that the frequency isn't architected?
>>>>>
>>>>> I think I'm missing something here.
>>>>>
>>>>
>>>> Having cycle counter would help in the cases where we want to correlate the
>>>> time with other subsystems which are outside cpu subsystem.
>>>
>>> Do you have an example of these subsystems? Can they be used to generate
>>> trace data with mainline?
>>
>> Some of the subsystems i can list are Modem(on a mobilephone), GPU or video
>> subsystem, or a DSP among others.
>
> Oh, you're talking about hardware subsystems. That makes this slightly more
> compelling, but I don't think you want the virtual counter here, since
> I assume those other subsystems don't take into account CNTVOFF (and I
> don't really see how they could, it being a per-cpu thing). So, if you
> want to expose the *physical* counter as a trace clock, I think that's
> justifiable.
>
Yes, I meant HW subsystems. Sorry if I was not clear.
In ARM64, it seems the access to physical counter is removed with commit
"clocksource: arch_timer: Fix code to use physical timers when
requested". Only ARM (32) is allowed to used physical counter in the
current timer API. It seems only EL2 is supposed to access this. But
yes, if there is an offset, it seems it would be difficult to get the
exact value at EL0. However for systems where CNTVOFF is '0', this will
work seamless. This clock would not be the default anyways and is
optional. Local clock would continue to be the default for traces.
>>>> local_clock or even the perf track_clock uses sched_clock which gets
>>>> suspended during system suspend. Yes, they are backed up by the
>>>> architected counter but they ignore the cycles spent in suspend.i
>>>
>>> Does mono_raw solve this (also hangs off the architected counter and is
>>> supported in the vdso)?
>>
>> Doesn't seem like. Any of the existing clock sources are designed not show
>> the jump, when there is a suspend and resume. Even though they run out of
>> architected counter they just cane give exact correlation with the counter.
>> Furthermore, during the initial kernel boot, these just run out of jiffies
>> clock source. They also not account for the time spent in boot loaders.
>
> Hmm, there's a thing called CLOCK_BOOTTIME, but I don't think that helps
> you when CNTVOFF comes into play.
>
CLOCK_BOOTTIME includes the time spent in suspend. But this also doesn't
give exact counter value since power ON. So for the purpose of comparing
with global counter, this would not help.
>>>> so, when comparing with monotonically increasing cycle counter, other
>>>> clocks doesn't help. It seems X86 uses the TSC counter to help such cases.
>>>
>>> Does this mean we need a way to expose the frequency to userspace, too?
>>
>> Not really. The CNTFRQ_EL0 of timer subsystem holds the clock frequency of
>> system timer and is available to EL0.
>
> Experience shows that CNTFRQ_EL0 is often unreliable, and the frequency
> can be overridden by the device-tree. There are also systems where the
> counter stops ticking across suspend. Whilst both of these can be considered
> "broken", I suspect we want runtime buy-in from the arch-timer driver
> before registering this trace_clock.
Agree. It doesnt seem like architecture mandates initializing this.
For those systems where tick would stop, if not arch counter, i assume
there is some counter which falls in 'always ON' domain without which
they cant keep track of time.
Adding Mark Rutland and Marc Zyngier for help with this.
Thanks,
-- Srinivas R
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative
Project.
^ permalink raw reply
* [PATCH 33/37] ARM: dts: vf610m4-cosmic: Correct license text
From: Afzal Mohammed @ 2016-12-15 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214235746.7108-34-alexandre.belloni@free-electrons.com>
Hi,
On Thu, Dec 15, 2016 at 12:57:42AM +0100, Alexandre Belloni wrote:
> The license test has been mangled at some point then copy pasted across
The patch text has been mangled at this point ... ;)
> multiple files. Restore it to what it should be.
> Note that this is not intended as a license change.
Acked-by: Afzal Mohammed <afzal.mohd.ma@gmail.com>
Regards
afzal
^ permalink raw reply
* mmc: core: complete/wait_for_completion performance
From: Jörg Krause @ 2016-12-15 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <962480933.163666.1481741832090@email.1und1.de>
Hi Stefan,
On Wed, 2016-12-14 at 19:57 +0100, Stefan Wahren wrote:
> Hi J?rg,
>
[snip]
> > >
> > > did you try cyclictest [1]?
> >
> > Not yet. Not sure what to measure and which values to compare here.
>
> i tought you have the vendor kernel and the mainline kernel available
> for your platform.
>
> So you could compare the both kernels.
Yes, that's right. I will have a look at this tool.
> >
> > >
> > > Beside the time for a request the amount of requests for the
> > > complete
> > > iperf test
> > > would we interesting. Maybe there are retries.
> > >
> > > I'm still interested in your PIO mode patches for mxs-mmc even
> > > without clean up.
> >
> > Actually, the patch does not implement a PIO mode, but drops DMA
> > and
> > uses polling instead. I've attached the patch.
>
> Thanks. I applied it, but unfortunately this breaks SD card support
> for my Duckbill and the kernel isn't able to mount the rootfs:
>
> [????2.267073] mxs-mmc 80010000.ssp: initialized
> [????2.272624] mxs-mmc 80010000.ssp: AC command error 0xffffff92
Sorry, I messed up the branches. I attached the correct patch which is
working for me on Linux v4.9.
J?rg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0200-mmc-mxs-mmc-use-PIO-mode.patch
Type: text/x-patch
Size: 15450 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161215/b5c33807/attachment-0001.bin>
^ permalink raw reply
* [PATCH v2] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Markus Reichl @ 2016-12-15 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <10512254.nyUcL0zgTP@amdc3058>
Hi Bartlomiej,
Am 15.12.2016 um 12:55 schrieb Bartlomiej Zolnierkiewicz:
> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
> cooling maps to account for new OPPs.
>
> Since new OPPs are not available on all Exynos5422/5800 boards modify
> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
>
> Tested on Odroid-XU3 and XU3 Lite.
>
> Cc: Doug Anderson <dianders@chromium.org>
> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> Cc: Andreas Faerber <afaerber@suse.de>
> Cc: Thomas Abraham <thomas.ab@samsung.com>
> Cc: Ben Gamari <ben@smart-cactus.org>
> Cc: Arjun K V <arjun.kv@samsung.com>
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> ---
> v2:
> - added comments about limitations of SoC revisions used by Odroid-XU3 Lite and
> Peach Pi boards (suggested by Javier)
> - removed redundant opp_a7_14 label
> - added Arjun to Cc:
>
> Javier, could you test it on Peach Pi board?
>
> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 ++++++-------
> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 22 +++++++++++++++++++++
> arch/arm/boot/dts/exynos5800-peach-pi.dts | 9 ++++++++
> arch/arm/boot/dts/exynos5800.dtsi | 15 ++++++++++++++
> 4 files changed, 53 insertions(+), 7 deletions(-)
>
> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> ===================================================================
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-15 12:43:54.365955950 +0100
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-15 12:43:54.361955949 +0100
> @@ -118,7 +118,7 @@
> /*
> * When reaching cpu_alert3, reduce CPU
> * by 2 steps. On Exynos5422/5800 that would
> - * be: 1600 MHz and 1100 MHz.
> + * (usually) be: 1800 MHz and 1200 MHz.
> */
> map3 {
> trip = <&cpu_alert3>;
> @@ -131,16 +131,16 @@
>
> /*
> * When reaching cpu_alert4, reduce CPU
> - * further, down to 600 MHz (11 steps for big,
> - * 7 steps for LITTLE).
> + * further, down to 600 MHz (13 steps for big,
> + * 8 steps for LITTLE).
> */
> - map5 {
> + cooling_map5: map5 {
> trip = <&cpu_alert4>;
> - cooling-device = <&cpu0 3 7>;
> + cooling-device = <&cpu0 3 8>;
> };
> - map6 {
> + cooling_map6: map6 {
> trip = <&cpu_alert4>;
> - cooling-device = <&cpu4 3 11>;
> + cooling-device = <&cpu4 3 13>;
> };
> };
> };
> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> ===================================================================
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-15 12:43:54.365955950 +0100
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-15 12:43:54.361955949 +0100
> @@ -21,6 +21,28 @@
> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
> };
>
> +/*
> + * Odroid XU3-Lite board uses SoC revision with lower maximum frequencies
> + * than Odroid XU3/XU4 boards: 1.8 GHz for A15 cores & 1.3 GHz for A7 cores.
> + * Therefore we need to update OPPs tables and thermal maps accordingly.
> + */
> +&cluster_a15_opp_table {
> + /delete-node/opp at 2000000000;
> + /delete-node/opp at 1900000000;
> +};
> +
> +&cluster_a7_opp_table {
> + /delete-node/opp at 1400000000;
> +};
> +
> +&cooling_map5 {
> + cooling-device = <&cpu0 3 7>;
> +};
> +
> +&cooling_map6 {
> + cooling-device = <&cpu4 3 11>;
> +};
> +
> &pwm {
> /*
> * PWM 0 -- fan
> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> ===================================================================
> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-15 12:43:54.365955950 +0100
> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-15 12:43:54.361955949 +0100
> @@ -146,6 +146,15 @@
> vdd-supply = <&ldo9_reg>;
> };
>
> +/*
> + * Peach Pi board uses SoC revision with lower maximum frequency for A7 cores
> + * (1.3 GHz instead of 1.4 GHz) than Odroid XU3/XU4 boards. Thus we need to
> + * update A7 OPPs table accordingly.
> + */
> +&cluster_a7_opp_table {
> + /delete-property/opp at 1400000000;
> +};
> +
> &cpu0 {
> cpu-supply = <&buck2_reg>;
> };
> Index: b/arch/arm/boot/dts/exynos5800.dtsi
> ===================================================================
> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-15 12:43:54.365955950 +0100
> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-15 12:43:54.361955949 +0100
> @@ -24,6 +24,16 @@
> };
>
> &cluster_a15_opp_table {
> + opp at 2000000000 {
> + opp-hz = /bits/ 64 <2000000000>;
> + opp-microvolt = <1250000>;
> + clock-latency-ns = <140000>;
> + };
> + opp at 1900000000 {
> + opp-hz = /bits/ 64 <1900000000>;
> + opp-microvolt = <1250000>;
> + clock-latency-ns = <140000>;
> + };
> opp at 1700000000 {
> opp-microvolt = <1250000>;
> };
> @@ -85,6 +95,11 @@
> };
>
> &cluster_a7_opp_table {
> + opp at 1400000000 {
> + opp-hz = /bits/ 64 <1400000000>;
> + opp-microvolt = <1250000>;
> + clock-latency-ns = <140000>;
> + };
> opp at 1300000000 {
> opp-microvolt = <1250000>;
> };
>
On Odroid XU4, XU3 and XU3-lite:
Tested-by: Markus Reichl <m.reichl@fivetechno.de>
Thanks,
--
Markus Reichl
^ permalink raw reply
* [PATCH 2/2] xilinx_dma: Add reset support
From: Laurent Pinchart @ 2016-12-15 13:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <380d1b11-814d-0164-3d49-e976f2deb3f9@synopsys.com>
Hi Ramiro,
(CC'ing Philipp Zabel)
On Thursday 15 Dec 2016 11:26:54 Ramiro Oliveira wrote:
> On 12/14/2016 8:16 PM, Laurent Pinchart wrote:
> > Hi Ramiro,
> >
> > Thank you for the patch.
> >
> > On Wednesday 14 Dec 2016 17:18:24 Ramiro Oliveira wrote:
> >> Add a DT property to control an optional external reset line
> >>
> >> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
> >> ---
> >>
> >> drivers/dma/xilinx/xilinx_dma.c | 23 +++++++++++++++++++++++
> >> 1 file changed, 23 insertions(+)
> >>
> >> diff --git a/drivers/dma/xilinx/xilinx_dma.c
> >> b/drivers/dma/xilinx/xilinx_dma.c index 5c9f11b..b845224 100644
> >> --- a/drivers/dma/xilinx/xilinx_dma.c
> >> +++ b/drivers/dma/xilinx/xilinx_dma.c
> >> @@ -46,6 +46,7 @@
> >> #include <linux/slab.h>
> >> #include <linux/clk.h>
> >> #include <linux/io-64-nonatomic-lo-hi.h>
> >> +#include <linux/reset.h>
> >
> > I had neatly sorted the header alphabetically until someone added clk.h
> > and io-64-nonatomic-lo-hi.h :-( Could you please move reset.h just before
> > slab.h ?
>
> Sure. Actually I was tempted to reorder it, but I decided not to do it. I'll
> do it now
Yeah, I'll sleep better tonight :-D
> >> #include "../dmaengine.h"
> >>
> >> @@ -409,6 +410,7 @@ struct xilinx_dma_device {
> >> struct clk *rxs_clk;
> >> u32 nr_channels;
> >> u32 chan_id;
> >> + struct reset_control *rst;
> >> };
> >>
> >> /* Macros */
> >> @@ -2543,6 +2545,27 @@ static int xilinx_dma_probe(struct platform_device
> >> *pdev) if (IS_ERR(xdev->regs))
> >> return PTR_ERR(xdev->regs);
> >>
> >> + xdev->rst = devm_reset_control_get_optional(&pdev->dev, "reset");
> >
> > devm_reset_control_get_optional() is deprecated as explained in
> > linux/reset.h, you should use devm_reset_control_get_optional_exclusive()
> > or devm_reset_control_get_optional_shared() instead, as applicable.
> >
> > This being said, I'm wondering why the optional versions of those
> > functions exist, as they do exactly the same as the non-optional versions.
> > The API feels wrong, it should have been modelled like the GPIO API. Feel
> > free to fix it if you want :-) But that's out of scope for this patch.
>
> I missed the comment stating that devm_reset_control_get_optional() was
> deprecated.
>
> I could fix it. Your sugestion is modelling these functions like the GPIO
> API?
I think it would be better for driver if the _get_optional functions would
return an ERR_PTR() for errors and NULL when reset control is not available,
and then have the rest of the reset controller API accept NULL as a no-op.
Your implementation would then be
xdev->rst = devm_reset_control_get_optional_exclusive(&pdev->dev,
"reset");
if (IS_ERR(xdev->rst)) {
err = PTR_ERR(xdev->rst);
if (err != -EPROBE_DEFER)
dev_err(xdev->dev, "error getting reset %d\n", err);
return err;
}
err = reset_control_deassert(xdev->rst);
if (err) {
dev_err(xdev->dev, "failed to deassert reset: %d\n", err);
return err;
}
That requires modifying the reset controller API, so it's a bit out-of-scope,
but if you could give it a go, it would be great.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 1/2] media: s5p-cec: Remove unneeded linux/miscdevice.h include
From: Corentin Labbe @ 2016-12-15 14:03 UTC (permalink / raw)
To: linux-arm-kernel
s5p-cec: does not use any miscdevice so this patch remove this
unnecessary inclusion.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/staging/media/s5p-cec/exynos_hdmi_cec.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/media/s5p-cec/exynos_hdmi_cec.h b/drivers/staging/media/s5p-cec/exynos_hdmi_cec.h
index 3e4fc7b..7d94535 100644
--- a/drivers/staging/media/s5p-cec/exynos_hdmi_cec.h
+++ b/drivers/staging/media/s5p-cec/exynos_hdmi_cec.h
@@ -14,7 +14,6 @@
#define _EXYNOS_HDMI_CEC_H_ __FILE__
#include <linux/regmap.h>
-#include <linux/miscdevice.h>
#include "s5p_cec.h"
void s5p_cec_set_divider(struct s5p_cec_dev *cec);
--
2.10.2
^ permalink raw reply related
* [PATCH 2/2] media: s5p-cec: Remove references to non-existent PLAT_S5P symbol
From: Corentin Labbe @ 2016-12-15 14:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161215140324.28986-1-clabbe.montjoie@gmail.com>
Commit d78c16ccde96 ("ARM: SAMSUNG: Remove remaining legacy code")
removed the Kconfig symbol PLAT_S5P.
This patch remove the last occurrence of this symbol.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/staging/media/s5p-cec/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/s5p-cec/Kconfig b/drivers/staging/media/s5p-cec/Kconfig
index 0315fd7..cba4f8a 100644
--- a/drivers/staging/media/s5p-cec/Kconfig
+++ b/drivers/staging/media/s5p-cec/Kconfig
@@ -1,6 +1,6 @@
config VIDEO_SAMSUNG_S5P_CEC
tristate "Samsung S5P CEC driver"
- depends on VIDEO_DEV && MEDIA_CEC && (PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST)
+ depends on VIDEO_DEV && MEDIA_CEC && (ARCH_EXYNOS || COMPILE_TEST)
---help---
This is a driver for Samsung S5P HDMI CEC interface. It uses the
generic CEC framework interface.
--
2.10.2
^ permalink raw reply related
* [PATCH 1/3] dma: zx: rename zx296702_dma.c to zx_dma.c
From: Shawn Guo @ 2016-12-15 14:03 UTC (permalink / raw)
To: linux-arm-kernel
From: Shawn Guo <shawn.guo@linaro.org>
ZTE ZX dma driver is not ZX296702 specific. It works for not only
ZX296702 but also other ZTE ZX family platforms like ZX296718. Let's
rename the file to reflect that.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
drivers/dma/Kconfig | 4 ++--
drivers/dma/Makefile | 2 +-
drivers/dma/{zx296702_dma.c => zx_dma.c} | 0
3 files changed, 3 insertions(+), 3 deletions(-)
rename drivers/dma/{zx296702_dma.c => zx_dma.c} (100%)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 263495d0adbd..eab7e12ee4a6 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -571,12 +571,12 @@ config XILINX_ZYNQMP_DMA
Enable support for Xilinx ZynqMP DMA controller.
config ZX_DMA
- tristate "ZTE ZX296702 DMA support"
+ tristate "ZTE ZX DMA support"
depends on ARCH_ZX || COMPILE_TEST
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
help
- Support the DMA engine for ZTE ZX296702 platform devices.
+ Support the DMA engine for ZTE ZX family platform devices.
# driver files
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index a4fa3360e609..0b723e94d9e6 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -66,7 +66,7 @@ obj-$(CONFIG_TI_CPPI41) += cppi41.o
obj-$(CONFIG_TI_DMA_CROSSBAR) += ti-dma-crossbar.o
obj-$(CONFIG_TI_EDMA) += edma.o
obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
-obj-$(CONFIG_ZX_DMA) += zx296702_dma.o
+obj-$(CONFIG_ZX_DMA) += zx_dma.o
obj-$(CONFIG_ST_FDMA) += st_fdma.o
obj-y += qcom/
diff --git a/drivers/dma/zx296702_dma.c b/drivers/dma/zx_dma.c
similarity index 100%
rename from drivers/dma/zx296702_dma.c
rename to drivers/dma/zx_dma.c
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] dma: zx: set DMA_CYCLIC cap_mask bit
From: Shawn Guo @ 2016-12-15 14:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481810617-7650-1-git-send-email-shawnguo@kernel.org>
From: Shawn Guo <shawn.guo@linaro.org>
The zx_dma driver supports cyclic transfer mode. Let's set DMA_CYCLIC
cap_mask bit to make that clear, and avoid unnecessary failure when
clients request channel via dma_request_chan_by_mask() with DMA_CYCLIC
bit set in mask.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
drivers/dma/zx_dma.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma/zx_dma.c b/drivers/dma/zx_dma.c
index 380276d078b2..33155c6816cc 100644
--- a/drivers/dma/zx_dma.c
+++ b/drivers/dma/zx_dma.c
@@ -812,6 +812,7 @@ static int zx_dma_probe(struct platform_device *op)
INIT_LIST_HEAD(&d->slave.channels);
dma_cap_set(DMA_SLAVE, d->slave.cap_mask);
dma_cap_set(DMA_MEMCPY, d->slave.cap_mask);
+ dma_cap_set(DMA_CYCLIC, d->slave.cap_mask);
dma_cap_set(DMA_PRIVATE, d->slave.cap_mask);
d->slave.dev = &op->dev;
d->slave.device_free_chan_resources = zx_dma_free_chan_resources;
--
1.9.1
^ permalink raw reply related
* [PATCH 3/3] dma: zx: fix residue calculation
From: Shawn Guo @ 2016-12-15 14:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481810617-7650-1-git-send-email-shawnguo@kernel.org>
From: Shawn Guo <shawn.guo@linaro.org>
The dma residue is defined as the free space to end of transfer buffer,
which could be multiple segments chained together. So the residue
calculation in zx_dma_tx_status() works for both slave_sg and cyclic
case. But unfortunately, the 'index' is wrong. It should plus one,
because the current segment is already occupied and shouldn't be counted
into free space.
This fixes the HDMI audio noise issue we see on ZX296718 with SPDIF
interface.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
drivers/dma/zx_dma.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/zx_dma.c b/drivers/dma/zx_dma.c
index 33155c6816cc..42ff3e66c1e1 100644
--- a/drivers/dma/zx_dma.c
+++ b/drivers/dma/zx_dma.c
@@ -365,7 +365,8 @@ static enum dma_status zx_dma_tx_status(struct dma_chan *chan,
bytes = 0;
clli = zx_dma_get_curr_lli(p);
- index = (clli - ds->desc_hw_lli) / sizeof(struct zx_desc_hw);
+ index = (clli - ds->desc_hw_lli) /
+ sizeof(struct zx_desc_hw) + 1;
for (; index < ds->desc_num; index++) {
bytes += ds->desc_hw[index].src_x;
/* end of lli */
--
1.9.1
^ permalink raw reply related
* [PATCH V6 03/10] efi: parse ARM processor error
From: James Morse @ 2016-12-15 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481147303-7979-4-git-send-email-tbaicar@codeaurora.org>
Hi Tyler,
On 07/12/16 21:48, Tyler Baicar wrote:
> Add support for ARM Common Platform Error Record (CPER).
> UEFI 2.6 specification adds support for ARM specific
> processor error information to be reported as part of the
> CPER records. This provides more detail on for processor error logs.
Looks good to me, a few minor comments below.
Reviewed-by: James Morse <james.morse@arm.com>
> diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
> index 8fa4e23..1ac2572 100644
> --- a/drivers/firmware/efi/cper.c
> +++ b/drivers/firmware/efi/cper.c
> @@ -184,6 +199,110 @@ static void cper_print_proc_generic(const char *pfx,
> printk("%s""IP: 0x%016llx\n", pfx, proc->ip);
> }
>
> +static void cper_print_proc_arm(const char *pfx,
> + const struct cper_sec_proc_arm *proc)
> +{
> + int i, len, max_ctx_type;
> + struct cper_arm_err_info *err_info;
> + struct cper_arm_ctx_info *ctx_info;
> + char newpfx[64];
> +
> + printk("%ssection length: %d\n", pfx, proc->section_length);
Compared to the rest of the file, this:
> printk("%s""section length: %d\n", pfx, proc->section_length);
would be more in keeping. I guess its done this way to avoid some spurious
warning about %ssection not being recognised by printk().
> + printk("%sMIDR: 0x%016llx\n", pfx, proc->midr);
> +
> + len = proc->section_length - (sizeof(*proc) +
> + proc->err_info_num * (sizeof(*err_info)));
> + if (len < 0) {
> + printk("%ssection length is too small\n", pfx);
This calculation is all based on values in the 'struct cper_sec_proc_arm', is it
worth making more noise about how the firmware-generated record is incorrectly
formatted? If we see this message its not the kernel's fault!
> + printk("%sERR_INFO_NUM is %d\n", pfx, proc->err_info_num);
> + return;
> + }
> +
> + if (proc->validation_bits & CPER_ARM_VALID_MPIDR)
> + printk("%sMPIDR: 0x%016llx\n", pfx, proc->mpidr);
> + if (proc->validation_bits & CPER_ARM_VALID_AFFINITY_LEVEL)
> + printk("%serror affinity level: %d\n", pfx,
> + proc->affinity_level);
> + if (proc->validation_bits & CPER_ARM_VALID_RUNNING_STATE) {
> + printk("%srunning state: %d\n", pfx, proc->running_state);
This field is described as a bit field in table 260, can we print it as 0x%lx in
case additional bits are set?
> + printk("%sPSCI state: %d\n", pfx, proc->psci_state);
> + }
> +
> + snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP);
> +
> + err_info = (struct cper_arm_err_info *)(proc + 1);
> + for (i = 0; i < proc->err_info_num; i++) {
> + printk("%sError info structure %d:\n", pfx, i);
> + printk("%sversion:%d\n", newpfx, err_info->version);
> + printk("%slength:%d\n", newpfx, err_info->length);
> + if (err_info->validation_bits &
> + CPER_ARM_INFO_VALID_MULTI_ERR) {
> + if (err_info->multiple_error == 0)
> + printk("%ssingle error\n", newpfx);
> + else if (err_info->multiple_error == 1)
> + printk("%smultiple errors\n", newpfx);
> + else
> + printk("%smultiple errors count:%d\n",
> + newpfx, err_info->multiple_error);
This is described as unsigned in table 261.
> + }
> + if (err_info->validation_bits & CPER_ARM_INFO_VALID_FLAGS) {
> + if (err_info->flags & CPER_ARM_INFO_FLAGS_FIRST)
> + printk("%sfirst error captured\n", newpfx);
> + if (err_info->flags & CPER_ARM_INFO_FLAGS_LAST)
> + printk("%slast error captured\n", newpfx);
> + if (err_info->flags & CPER_ARM_INFO_FLAGS_PROPAGATED)
> + printk("%spropagated error captured\n",
> + newpfx);
Table 261 also has an 'overflow' bit in flags. It may be worth printing a
warning if this is set:
> Note: Overflow bit indicates that firmware/hardware error
> buffers had experience an overflow, and it is possible that
> some error information has been lost.
> + }
> + printk("%serror_type: %d, %s\n", newpfx, err_info->type,
> + err_info->type < ARRAY_SIZE(proc_error_type_strs) ?
> + proc_error_type_strs[err_info->type] : "unknown");
> + if (err_info->validation_bits & CPER_ARM_INFO_VALID_ERR_INFO)
> + printk("%serror_info: 0x%016llx\n", newpfx,
> + err_info->error_info);
> + if (err_info->validation_bits & CPER_ARM_INFO_VALID_VIRT_ADDR)
> + printk("%svirtual fault address: 0x%016llx\n",
> + newpfx, err_info->virt_fault_addr);
> + if (err_info->validation_bits &
> + CPER_ARM_INFO_VALID_PHYSICAL_ADDR)
> + printk("%sphysical fault address: 0x%016llx\n",
> + newpfx, err_info->physical_fault_addr);
> + err_info += 1;
> + }
> + ctx_info = (struct cper_arm_ctx_info *)err_info;
> + max_ctx_type = (sizeof(arm_reg_ctx_strs) /
> + sizeof(arm_reg_ctx_strs[0]) - 1);
ARRAY_SIZE() - 1?
> + for (i = 0; i < proc->context_info_num; i++) {
> + int size = sizeof(*ctx_info) + ctx_info->size;
> +
> + printk("%sContext info structure %d:\n", pfx, i);
> + if (len < size) {
> + printk("%ssection length is too small\n", newpfx);
> + return;
> + }
> + if (ctx_info->type > max_ctx_type) {
> + printk("%sInvalid context type: %d\n", newpfx,
> + ctx_info->type);
> + printk("%sMax context type: %d\n", newpfx,
> + max_ctx_type);
> + return;
> + }
> + printk("%sregister context type %d: %s\n", newpfx,
> + ctx_info->type, arm_reg_ctx_strs[ctx_info->type]);
> + print_hex_dump(newpfx, "", DUMP_PREFIX_OFFSET, 16, 4,
> + (ctx_info + 1), ctx_info->size, 0);
> + len -= size;
> + ctx_info = (struct cper_arm_ctx_info *)((long)ctx_info + size);
> + }
> +
> + if (len > 0) {
> + printk("%sVendor specific error info has %d bytes:\n", pfx,
> + len);
%u - just in case it is surprisingly large!
> + print_hex_dump(newpfx, "", DUMP_PREFIX_OFFSET, 16, 4, ctx_info,
> + len, 0);
> + }
> +}
> +
> static const char * const mem_err_type_strs[] = {
> "unknown",
> "no error",
> @@ -458,6 +577,15 @@ static void cper_estatus_print_section(
> cper_print_pcie(newpfx, pcie, gdata);
> else
> goto err_section_too_small;
> + } else if (!uuid_le_cmp(*sec_type, CPER_SEC_PROC_ARM)) {
> + struct cper_sec_proc_arm *arm_err;
> +
> + arm_err = acpi_hest_generic_data_payload(gdata);
> + printk("%ssection_type: ARM processor error\n", newpfx);
> + if (gdata->error_data_length >= sizeof(*arm_err))
> + cper_print_proc_arm(newpfx, arm_err);
> + else
> + goto err_section_too_small;
> } else
> printk("%s""section type: unknown, %pUl\n", newpfx, sec_type);
>
This is the only processor-specific entry in this function,
CPER_SEC_PROC_{IA,IPF} don't appear anywhere else in the tree.
Is it worth adding an (IS_ENABLED(CONFIG_ARM64) || IS_ENABLED(CONFIG_ARM)) in
the if()? This would let the compiler remove cper_print_proc_arm(() on x86/ia64
systems which won't ever see a record of this type.
Thanks!
James
^ 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