* [PATCH 1/4] ARM: davinci: da8xx: VPIF: enable DT init
From: Kevin Hilman @ 2016-11-22 19:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122194551.3420-1-khilman@baylibre.com>
Add basic support for DT initializaion of VPIF (capture) via DT. Clocks
and mux still need to happen in this file until there are real clock and
pinctrl drivers, but the video nodes and subdevs can all come from DT.
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
arch/arm/mach-davinci/da8xx-dt.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index c9f7e9274aa8..7b41611f2665 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -17,6 +17,7 @@
#include <mach/common.h>
#include "cp_intc.h"
#include <mach/da8xx.h>
+#include <mach/mux.h>
static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("ti,davinci-i2c", 0x01c22000, "i2c_davinci.1", NULL),
@@ -38,14 +39,30 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
NULL),
OF_DEV_AUXDATA("ti,da830-mcasp-audio", 0x01d00000, "davinci-mcasp.0", NULL),
OF_DEV_AUXDATA("ti,da850-aemif", 0x68000000, "ti-aemif", NULL),
+ OF_DEV_AUXDATA("ti,da850-vpif", 0x01e17000, "vpif", NULL),
{}
};
#ifdef CONFIG_ARCH_DAVINCI_DA850
+#if IS_ENABLED(CONFIG_VIDEO_DAVINCI_VPIF_CAPTURE)
+static __init void da850_vpif_capture_init(void)
+{
+ int ret;
+
+ ret = davinci_cfg_reg_list(da850_vpif_capture_pins);
+ if (ret)
+ pr_warn("da850_evm_init: VPIF capture mux setup failed: %d\n",
+ ret);
+}
+#else
+#define da850_vpif_capture_init()
+#endif
+
static void __init da850_init_machine(void)
{
of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
+ da850_vpif_capture_init();
}
static const char *const da850_boards_compat[] __initconst = {
--
2.9.3
^ permalink raw reply related
* [PATCH 0/4] ARM: davinci: add/enable video capture for da850-lcdk
From: Kevin Hilman @ 2016-11-22 19:45 UTC (permalink / raw)
To: linux-arm-kernel
Add DT description of da850 video capture (using VPIF) for the da850
SoC. and the LCDK board. This enables video capture using the
composite input on the LCDK board.
Series applies to Sekhar's v4.10/dt branch (and defconfig change will
have trivial add/add conflict when applied to Sekhar's defconfig branch.)
@Sekhar: I'm not sure if you want the first patch to go via your soc
branch or dt branch, but I kept it together with this series for now.
Feel free to break it up as needed. It will also have a trivial
add/add conflict with some existing changes to that file.
Depenencies:
- [PATCH v3 0/4] [media] davinci: VPIF: add DT support
https://marc.info/?l=devicetree&m=147982997317376&w=2
In video capture to work, this series depends on the above VPIF driver
update to enable DT support, however there are no build or boot-time
regressions if this series goes in independently of the driver
changes. There will simply be no video capture support until the
driver changes are done (which the same as how things work today.)
Kevin Hilman (4):
ARM: davinci: da8xx: VPIF: enable DT init
ARM: dts: davinci: da850: add VPIF
ARM: dts: davinci: da850-lcdk: enable VPIF capture via TVP5147
ARM: davinci_all_defconfig: enable video capture as modules
arch/arm/boot/dts/da850-lcdk.dts | 30 ++++++++++++++++++++++++++++++
arch/arm/boot/dts/da850.dtsi | 28 ++++++++++++++++++++++++++++
arch/arm/configs/davinci_all_defconfig | 6 ++++++
arch/arm/mach-davinci/da8xx-dt.c | 17 +++++++++++++++++
4 files changed, 81 insertions(+)
--
2.9.3
^ permalink raw reply
* Applied "ASoC: sunxi: Add bindings for A23/A33/H3 codec's analog path controls" to the asoc tree
From: Mark Brown @ 2016-11-22 19:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161112064648.26779-2-wens@csie.org>
The patch
ASoC: sunxi: Add bindings for A23/A33/H3 codec's analog path controls
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 837e71847aefd82c903ee0bb2ff2589e70b0808f Mon Sep 17 00:00:00 2001
From: Chen-Yu Tsai <wens@csie.org>
Date: Sat, 12 Nov 2016 14:46:39 +0800
Subject: [PATCH] ASoC: sunxi: Add bindings for A23/A33/H3 codec's analog path
controls
The internal codec on A23/A33/H3 is split into 2 parts. The
analog path controls are routed through an embedded custom register
bus accessed through the PRCM block.
The SoCs share a common set of inputs, outputs, and audio paths.
The following table lists the differences.
----------------------------------------
| Feature \ SoC | A23 | A33 | H3 |
----------------------------------------
| Headphone | v | v | |
----------------------------------------
| Line Out | | | v |
----------------------------------------
| Phone In/Out | v | v | |
----------------------------------------
Add a binding for this hardware.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
.../devicetree/bindings/sound/sun8i-codec-analog.txt | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
diff --git a/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt b/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
new file mode 100644
index 000000000000..779b735781ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
@@ -0,0 +1,16 @@
+* Allwinner Codec Analog Controls
+
+Required properties:
+- compatible: must be one of the following compatibles:
+ - "allwinner,sun8i-a23-codec-analog"
+ - "allwinner,sun8i-h3-codec-analog"
+
+Required properties if not a sub-node of the PRCM node:
+- reg: must contain the registers location and length
+
+Example:
+prcm: prcm at 01f01400 {
+ codec_analog: codec-analog {
+ compatible = "allwinner,sun8i-a23-codec-analog";
+ };
+};
--
2.10.2
^ permalink raw reply related
* Applied "ASoC: sunxi: Add support for A23/A33/H3 codec's analog path controls" to the asoc tree
From: Mark Brown @ 2016-11-22 19:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161112064648.26779-3-wens@csie.org>
The patch
ASoC: sunxi: Add support for A23/A33/H3 codec's analog path controls
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 ba2ff3027b5ab4a96b9d2832822311c3ccbf3011 Mon Sep 17 00:00:00 2001
From: Chen-Yu Tsai <wens@csie.org>
Date: Sat, 12 Nov 2016 14:46:40 +0800
Subject: [PATCH] ASoC: sunxi: Add support for A23/A33/H3 codec's analog path
controls
The internal codec on A23/A33/H3 is split into 2 parts. The
analog path controls are routed through an embedded custom register
bus accessed through the PRCM block.
The SoCs share a common set of inputs, outputs, and audio paths.
The following table lists the differences.
----------------------------------------
| Feature \ SoC | A23 | A33 | H3 |
----------------------------------------
| Headphone | v | v | |
----------------------------------------
| Line Out | | | v |
----------------------------------------
| Phone In/Out | v | v | |
----------------------------------------
Add an ASoC component driver for it. This should be tied to the codec
audio card as an auxiliary device. This patch adds the commont paths
and controls, and variant specific headphone out and line out.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/sunxi/Kconfig | 8 +
sound/soc/sunxi/Makefile | 1 +
sound/soc/sunxi/sun8i-codec-analog.c | 665 +++++++++++++++++++++++++++++++++++
3 files changed, 674 insertions(+)
create mode 100644 sound/soc/sunxi/sun8i-codec-analog.c
diff --git a/sound/soc/sunxi/Kconfig b/sound/soc/sunxi/Kconfig
index dd2368297fd3..6c344e16aca4 100644
--- a/sound/soc/sunxi/Kconfig
+++ b/sound/soc/sunxi/Kconfig
@@ -9,6 +9,14 @@ config SND_SUN4I_CODEC
Select Y or M to add support for the Codec embedded in the Allwinner
A10 and affiliated SoCs.
+config SND_SUN8I_CODEC_ANALOG
+ tristate "Allwinner sun8i Codec Analog Controls Support"
+ depends on MACH_SUN8I || COMPILE_TEST
+ select REGMAP
+ help
+ Say Y or M if you want to add support for the analog controls for
+ the codec embedded in newer Allwinner SoCs.
+
config SND_SUN4I_I2S
tristate "Allwinner A10 I2S Support"
select SND_SOC_GENERIC_DMAENGINE_PCM
diff --git a/sound/soc/sunxi/Makefile b/sound/soc/sunxi/Makefile
index 604c7b842837..241c0df9ca0c 100644
--- a/sound/soc/sunxi/Makefile
+++ b/sound/soc/sunxi/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_SND_SUN4I_CODEC) += sun4i-codec.o
obj-$(CONFIG_SND_SUN4I_I2S) += sun4i-i2s.o
obj-$(CONFIG_SND_SUN4I_SPDIF) += sun4i-spdif.o
+obj-$(CONFIG_SND_SUN8I_CODEC_ANALOG) += sun8i-codec-analog.o
diff --git a/sound/soc/sunxi/sun8i-codec-analog.c b/sound/soc/sunxi/sun8i-codec-analog.c
new file mode 100644
index 000000000000..222bbd440b1e
--- /dev/null
+++ b/sound/soc/sunxi/sun8i-codec-analog.c
@@ -0,0 +1,665 @@
+/*
+ * This driver supports the analog controls for the internal codec
+ * found in Allwinner's A31s, A23, A33 and H3 SoCs.
+ *
+ * Copyright 2016 Chen-Yu Tsai <wens@csie.org>
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+
+#include <sound/soc.h>
+#include <sound/soc-dapm.h>
+#include <sound/tlv.h>
+
+/* Codec analog control register offsets and bit fields */
+#define SUN8I_ADDA_HP_VOLC 0x00
+#define SUN8I_ADDA_HP_VOLC_PA_CLK_GATE 7
+#define SUN8I_ADDA_HP_VOLC_HP_VOL 0
+#define SUN8I_ADDA_LOMIXSC 0x01
+#define SUN8I_ADDA_LOMIXSC_MIC1 6
+#define SUN8I_ADDA_LOMIXSC_MIC2 5
+#define SUN8I_ADDA_LOMIXSC_PHONE 4
+#define SUN8I_ADDA_LOMIXSC_PHONEN 3
+#define SUN8I_ADDA_LOMIXSC_LINEINL 2
+#define SUN8I_ADDA_LOMIXSC_DACL 1
+#define SUN8I_ADDA_LOMIXSC_DACR 0
+#define SUN8I_ADDA_ROMIXSC 0x02
+#define SUN8I_ADDA_ROMIXSC_MIC1 6
+#define SUN8I_ADDA_ROMIXSC_MIC2 5
+#define SUN8I_ADDA_ROMIXSC_PHONE 4
+#define SUN8I_ADDA_ROMIXSC_PHONEP 3
+#define SUN8I_ADDA_ROMIXSC_LINEINR 2
+#define SUN8I_ADDA_ROMIXSC_DACR 1
+#define SUN8I_ADDA_ROMIXSC_DACL 0
+#define SUN8I_ADDA_DAC_PA_SRC 0x03
+#define SUN8I_ADDA_DAC_PA_SRC_DACAREN 7
+#define SUN8I_ADDA_DAC_PA_SRC_DACALEN 6
+#define SUN8I_ADDA_DAC_PA_SRC_RMIXEN 5
+#define SUN8I_ADDA_DAC_PA_SRC_LMIXEN 4
+#define SUN8I_ADDA_DAC_PA_SRC_RHPPAMUTE 3
+#define SUN8I_ADDA_DAC_PA_SRC_LHPPAMUTE 2
+#define SUN8I_ADDA_DAC_PA_SRC_RHPIS 1
+#define SUN8I_ADDA_DAC_PA_SRC_LHPIS 0
+#define SUN8I_ADDA_PHONEIN_GCTRL 0x04
+#define SUN8I_ADDA_PHONEIN_GCTRL_PHONEPG 4
+#define SUN8I_ADDA_PHONEIN_GCTRL_PHONENG 0
+#define SUN8I_ADDA_LINEIN_GCTRL 0x05
+#define SUN8I_ADDA_LINEIN_GCTRL_LINEING 4
+#define SUN8I_ADDA_LINEIN_GCTRL_PHONEG 0
+#define SUN8I_ADDA_MICIN_GCTRL 0x06
+#define SUN8I_ADDA_MICIN_GCTRL_MIC1G 4
+#define SUN8I_ADDA_MICIN_GCTRL_MIC2G 0
+#define SUN8I_ADDA_PAEN_HP_CTRL 0x07
+#define SUN8I_ADDA_PAEN_HP_CTRL_HPPAEN 7
+#define SUN8I_ADDA_PAEN_HP_CTRL_LINEOUTEN 7 /* H3 specific */
+#define SUN8I_ADDA_PAEN_HP_CTRL_HPCOM_FC 5
+#define SUN8I_ADDA_PAEN_HP_CTRL_COMPTEN 4
+#define SUN8I_ADDA_PAEN_HP_CTRL_PA_ANTI_POP_CTRL 2
+#define SUN8I_ADDA_PAEN_HP_CTRL_LTRNMUTE 1
+#define SUN8I_ADDA_PAEN_HP_CTRL_RTLNMUTE 0
+#define SUN8I_ADDA_PHONEOUT_CTRL 0x08
+#define SUN8I_ADDA_PHONEOUT_CTRL_PHONEOUTG 5
+#define SUN8I_ADDA_PHONEOUT_CTRL_PHONEOUTEN 4
+#define SUN8I_ADDA_PHONEOUT_CTRL_PHONEOUT_MIC1 3
+#define SUN8I_ADDA_PHONEOUT_CTRL_PHONEOUT_MIC2 2
+#define SUN8I_ADDA_PHONEOUT_CTRL_PHONEOUT_RMIX 1
+#define SUN8I_ADDA_PHONEOUT_CTRL_PHONEOUT_LMIX 0
+#define SUN8I_ADDA_PHONE_GAIN_CTRL 0x09
+#define SUN8I_ADDA_PHONE_GAIN_CTRL_LINEOUT_VOL 3
+#define SUN8I_ADDA_PHONE_GAIN_CTRL_PHONEPREG 0
+#define SUN8I_ADDA_MIC2G_CTRL 0x0a
+#define SUN8I_ADDA_MIC2G_CTRL_MIC2AMPEN 7
+#define SUN8I_ADDA_MIC2G_CTRL_MIC2BOOST 4
+#define SUN8I_ADDA_MIC2G_CTRL_LINEOUTLEN 3
+#define SUN8I_ADDA_MIC2G_CTRL_LINEOUTREN 2
+#define SUN8I_ADDA_MIC2G_CTRL_LINEOUTLSRC 1
+#define SUN8I_ADDA_MIC2G_CTRL_LINEOUTRSRC 0
+#define SUN8I_ADDA_MIC1G_MICBIAS_CTRL 0x0b
+#define SUN8I_ADDA_MIC1G_MICBIAS_CTRL_HMICBIASEN 7
+#define SUN8I_ADDA_MIC1G_MICBIAS_CTRL_MMICBIASEN 6
+#define SUN8I_ADDA_MIC1G_MICBIAS_CTRL_HMICBIAS_MODE 5
+#define SUN8I_ADDA_MIC1G_MICBIAS_CTRL_MIC1AMPEN 3
+#define SUN8I_ADDA_MIC1G_MICBIAS_CTRL_MIC1BOOST 0
+#define SUN8I_ADDA_LADCMIXSC 0x0c
+#define SUN8I_ADDA_LADCMIXSC_MIC1 6
+#define SUN8I_ADDA_LADCMIXSC_MIC2 5
+#define SUN8I_ADDA_LADCMIXSC_PHONE 4
+#define SUN8I_ADDA_LADCMIXSC_PHONEN 3
+#define SUN8I_ADDA_LADCMIXSC_LINEINL 2
+#define SUN8I_ADDA_LADCMIXSC_OMIXRL 1
+#define SUN8I_ADDA_LADCMIXSC_OMIXRR 0
+#define SUN8I_ADDA_RADCMIXSC 0x0d
+#define SUN8I_ADDA_RADCMIXSC_MIC1 6
+#define SUN8I_ADDA_RADCMIXSC_MIC2 5
+#define SUN8I_ADDA_RADCMIXSC_PHONE 4
+#define SUN8I_ADDA_RADCMIXSC_PHONEP 3
+#define SUN8I_ADDA_RADCMIXSC_LINEINR 2
+#define SUN8I_ADDA_RADCMIXSC_OMIXR 1
+#define SUN8I_ADDA_RADCMIXSC_OMIXL 0
+#define SUN8I_ADDA_RES 0x0e
+#define SUN8I_ADDA_RES_MMICBIAS_SEL 4
+#define SUN8I_ADDA_RES_PA_ANTI_POP_CTRL 0
+#define SUN8I_ADDA_ADC_AP_EN 0x0f
+#define SUN8I_ADDA_ADC_AP_EN_ADCREN 7
+#define SUN8I_ADDA_ADC_AP_EN_ADCLEN 6
+#define SUN8I_ADDA_ADC_AP_EN_ADCG 0
+
+/* Analog control register access bits */
+#define ADDA_PR 0x0 /* PRCM base + 0x1c0 */
+#define ADDA_PR_RESET BIT(28)
+#define ADDA_PR_WRITE BIT(24)
+#define ADDA_PR_ADDR_SHIFT 16
+#define ADDA_PR_ADDR_MASK GENMASK(4, 0)
+#define ADDA_PR_DATA_IN_SHIFT 8
+#define ADDA_PR_DATA_IN_MASK GENMASK(7, 0)
+#define ADDA_PR_DATA_OUT_SHIFT 0
+#define ADDA_PR_DATA_OUT_MASK GENMASK(7, 0)
+
+/* regmap access bits */
+static int adda_reg_read(void *context, unsigned int reg, unsigned int *val)
+{
+ void __iomem *base = (void __iomem *)context;
+ u32 tmp;
+
+ /* De-assert reset */
+ writel(readl(base) | ADDA_PR_RESET, base);
+
+ /* Clear write bit */
+ writel(readl(base) & ~ADDA_PR_WRITE, base);
+
+ /* Set register address */
+ tmp = readl(base);
+ tmp &= ~(ADDA_PR_ADDR_MASK << ADDA_PR_ADDR_SHIFT);
+ tmp |= (reg & ADDA_PR_ADDR_MASK) << ADDA_PR_ADDR_SHIFT;
+ writel(tmp, base);
+
+ /* Read back value */
+ *val = readl(base) & ADDA_PR_DATA_OUT_MASK;
+
+ return 0;
+}
+
+static int adda_reg_write(void *context, unsigned int reg, unsigned int val)
+{
+ void __iomem *base = (void __iomem *)context;
+ u32 tmp;
+
+ /* De-assert reset */
+ writel(readl(base) | ADDA_PR_RESET, base);
+
+ /* Set register address */
+ tmp = readl(base);
+ tmp &= ~(ADDA_PR_ADDR_MASK << ADDA_PR_ADDR_SHIFT);
+ tmp |= (reg & ADDA_PR_ADDR_MASK) << ADDA_PR_ADDR_SHIFT;
+ writel(tmp, base);
+
+ /* Set data to write */
+ tmp = readl(base);
+ tmp &= ~(ADDA_PR_DATA_IN_MASK << ADDA_PR_DATA_IN_SHIFT);
+ tmp |= (val & ADDA_PR_DATA_IN_MASK) << ADDA_PR_DATA_IN_SHIFT;
+ writel(tmp, base);
+
+ /* Set write bit to signal a write */
+ writel(readl(base) | ADDA_PR_WRITE, base);
+
+ /* Clear write bit */
+ writel(readl(base) & ~ADDA_PR_WRITE, base);
+
+ return 0;
+}
+
+static const struct regmap_config adda_pr_regmap_cfg = {
+ .name = "adda-pr",
+ .reg_bits = 5,
+ .reg_stride = 1,
+ .val_bits = 8,
+ .reg_read = adda_reg_read,
+ .reg_write = adda_reg_write,
+ .fast_io = true,
+ .max_register = 24,
+};
+
+/* mixer controls */
+static const struct snd_kcontrol_new sun8i_codec_mixer_controls[] = {
+ SOC_DAPM_DOUBLE_R("DAC Playback Switch",
+ SUN8I_ADDA_LOMIXSC,
+ SUN8I_ADDA_ROMIXSC,
+ SUN8I_ADDA_LOMIXSC_DACL, 1, 0),
+ SOC_DAPM_DOUBLE_R("DAC Reversed Playback Switch",
+ SUN8I_ADDA_LOMIXSC,
+ SUN8I_ADDA_ROMIXSC,
+ SUN8I_ADDA_LOMIXSC_DACR, 1, 0),
+ SOC_DAPM_DOUBLE_R("Line In Playback Switch",
+ SUN8I_ADDA_LOMIXSC,
+ SUN8I_ADDA_ROMIXSC,
+ SUN8I_ADDA_LOMIXSC_LINEINL, 1, 0),
+ SOC_DAPM_DOUBLE_R("Mic1 Playback Switch",
+ SUN8I_ADDA_LOMIXSC,
+ SUN8I_ADDA_ROMIXSC,
+ SUN8I_ADDA_LOMIXSC_MIC1, 1, 0),
+ SOC_DAPM_DOUBLE_R("Mic2 Playback Switch",
+ SUN8I_ADDA_LOMIXSC,
+ SUN8I_ADDA_ROMIXSC,
+ SUN8I_ADDA_LOMIXSC_MIC2, 1, 0),
+};
+
+/* ADC mixer controls */
+static const struct snd_kcontrol_new sun8i_codec_adc_mixer_controls[] = {
+ SOC_DAPM_DOUBLE_R("Mixer Capture Switch",
+ SUN8I_ADDA_LADCMIXSC,
+ SUN8I_ADDA_RADCMIXSC,
+ SUN8I_ADDA_LADCMIXSC_OMIXRL, 1, 0),
+ SOC_DAPM_DOUBLE_R("Mixer Reversed Capture Switch",
+ SUN8I_ADDA_LADCMIXSC,
+ SUN8I_ADDA_RADCMIXSC,
+ SUN8I_ADDA_LADCMIXSC_OMIXRR, 1, 0),
+ SOC_DAPM_DOUBLE_R("Line In Capture Switch",
+ SUN8I_ADDA_LADCMIXSC,
+ SUN8I_ADDA_RADCMIXSC,
+ SUN8I_ADDA_LADCMIXSC_LINEINL, 1, 0),
+ SOC_DAPM_DOUBLE_R("Mic1 Capture Switch",
+ SUN8I_ADDA_LADCMIXSC,
+ SUN8I_ADDA_RADCMIXSC,
+ SUN8I_ADDA_LADCMIXSC_MIC1, 1, 0),
+ SOC_DAPM_DOUBLE_R("Mic2 Capture Switch",
+ SUN8I_ADDA_LADCMIXSC,
+ SUN8I_ADDA_RADCMIXSC,
+ SUN8I_ADDA_LADCMIXSC_MIC2, 1, 0),
+};
+
+/* volume / mute controls */
+static const DECLARE_TLV_DB_SCALE(sun8i_codec_out_mixer_pregain_scale,
+ -450, 150, 0);
+static const DECLARE_TLV_DB_RANGE(sun8i_codec_mic_gain_scale,
+ 0, 0, TLV_DB_SCALE_ITEM(0, 0, 0),
+ 1, 7, TLV_DB_SCALE_ITEM(2400, 300, 0),
+);
+
+static const struct snd_kcontrol_new sun8i_codec_common_controls[] = {
+ /* Mixer pre-gains */
+ SOC_SINGLE_TLV("Line In Playback Volume", SUN8I_ADDA_LINEIN_GCTRL,
+ SUN8I_ADDA_LINEIN_GCTRL_LINEING,
+ 0x7, 0, sun8i_codec_out_mixer_pregain_scale),
+ SOC_SINGLE_TLV("Mic1 Playback Volume", SUN8I_ADDA_MICIN_GCTRL,
+ SUN8I_ADDA_MICIN_GCTRL_MIC1G,
+ 0x7, 0, sun8i_codec_out_mixer_pregain_scale),
+ SOC_SINGLE_TLV("Mic2 Playback Volume",
+ SUN8I_ADDA_MICIN_GCTRL, SUN8I_ADDA_MICIN_GCTRL_MIC2G,
+ 0x7, 0, sun8i_codec_out_mixer_pregain_scale),
+
+ /* Microphone Amp boost gains */
+ SOC_SINGLE_TLV("Mic1 Boost Volume", SUN8I_ADDA_MIC1G_MICBIAS_CTRL,
+ SUN8I_ADDA_MIC1G_MICBIAS_CTRL_MIC1BOOST, 0x7, 0,
+ sun8i_codec_mic_gain_scale),
+ SOC_SINGLE_TLV("Mic2 Boost Volume", SUN8I_ADDA_MIC2G_CTRL,
+ SUN8I_ADDA_MIC2G_CTRL_MIC2BOOST, 0x7, 0,
+ sun8i_codec_mic_gain_scale),
+
+ /* ADC */
+ SOC_SINGLE_TLV("ADC Gain Capture Volume", SUN8I_ADDA_ADC_AP_EN,
+ SUN8I_ADDA_ADC_AP_EN_ADCG, 0x7, 0,
+ sun8i_codec_out_mixer_pregain_scale),
+};
+
+static const struct snd_soc_dapm_widget sun8i_codec_common_widgets[] = {
+ /* ADC */
+ SND_SOC_DAPM_ADC("Left ADC", NULL, SUN8I_ADDA_ADC_AP_EN,
+ SUN8I_ADDA_ADC_AP_EN_ADCLEN, 0),
+ SND_SOC_DAPM_ADC("Right ADC", NULL, SUN8I_ADDA_ADC_AP_EN,
+ SUN8I_ADDA_ADC_AP_EN_ADCREN, 0),
+
+ /* DAC */
+ SND_SOC_DAPM_DAC("Left DAC", NULL, SUN8I_ADDA_DAC_PA_SRC,
+ SUN8I_ADDA_DAC_PA_SRC_DACALEN, 0),
+ SND_SOC_DAPM_DAC("Right DAC", NULL, SUN8I_ADDA_DAC_PA_SRC,
+ SUN8I_ADDA_DAC_PA_SRC_DACAREN, 0),
+ /*
+ * Due to this component and the codec belonging to separate DAPM
+ * contexts, we need to manually link the above widgets to their
+ * stream widgets@the card level.
+ */
+
+ /* Line In */
+ SND_SOC_DAPM_INPUT("LINEIN"),
+
+ /* Microphone inputs */
+ SND_SOC_DAPM_INPUT("MIC1"),
+ SND_SOC_DAPM_INPUT("MIC2"),
+
+ /* Microphone Bias */
+ SND_SOC_DAPM_SUPPLY("MBIAS", SUN8I_ADDA_MIC1G_MICBIAS_CTRL,
+ SUN8I_ADDA_MIC1G_MICBIAS_CTRL_MMICBIASEN,
+ 0, NULL, 0),
+
+ /* Mic input path */
+ SND_SOC_DAPM_PGA("Mic1 Amplifier", SUN8I_ADDA_MIC1G_MICBIAS_CTRL,
+ SUN8I_ADDA_MIC1G_MICBIAS_CTRL_MIC1AMPEN, 0, NULL, 0),
+ SND_SOC_DAPM_PGA("Mic2 Amplifier", SUN8I_ADDA_MIC2G_CTRL,
+ SUN8I_ADDA_MIC2G_CTRL_MIC2AMPEN, 0, NULL, 0),
+
+ /* Mixers */
+ SND_SOC_DAPM_MIXER("Left Mixer", SUN8I_ADDA_DAC_PA_SRC,
+ SUN8I_ADDA_DAC_PA_SRC_LMIXEN, 0,
+ sun8i_codec_mixer_controls,
+ ARRAY_SIZE(sun8i_codec_mixer_controls)),
+ SND_SOC_DAPM_MIXER("Right Mixer", SUN8I_ADDA_DAC_PA_SRC,
+ SUN8I_ADDA_DAC_PA_SRC_RMIXEN, 0,
+ sun8i_codec_mixer_controls,
+ ARRAY_SIZE(sun8i_codec_mixer_controls)),
+ SND_SOC_DAPM_MIXER("Left ADC Mixer", SUN8I_ADDA_ADC_AP_EN,
+ SUN8I_ADDA_ADC_AP_EN_ADCLEN, 0,
+ sun8i_codec_adc_mixer_controls,
+ ARRAY_SIZE(sun8i_codec_adc_mixer_controls)),
+ SND_SOC_DAPM_MIXER("Right ADC Mixer", SUN8I_ADDA_ADC_AP_EN,
+ SUN8I_ADDA_ADC_AP_EN_ADCREN, 0,
+ sun8i_codec_adc_mixer_controls,
+ ARRAY_SIZE(sun8i_codec_adc_mixer_controls)),
+};
+
+static const struct snd_soc_dapm_route sun8i_codec_common_routes[] = {
+ /* Microphone Routes */
+ { "Mic1 Amplifier", NULL, "MIC1"},
+ { "Mic2 Amplifier", NULL, "MIC2"},
+
+ /* Left Mixer Routes */
+ { "Left Mixer", "DAC Playback Switch", "Left DAC" },
+ { "Left Mixer", "DAC Reversed Playback Switch", "Right DAC" },
+ { "Left Mixer", "Line In Playback Switch", "LINEIN" },
+ { "Left Mixer", "Mic1 Playback Switch", "Mic1 Amplifier" },
+ { "Left Mixer", "Mic2 Playback Switch", "Mic2 Amplifier" },
+
+ /* Right Mixer Routes */
+ { "Right Mixer", "DAC Playback Switch", "Right DAC" },
+ { "Right Mixer", "DAC Reversed Playback Switch", "Left DAC" },
+ { "Right Mixer", "Line In Playback Switch", "LINEIN" },
+ { "Right Mixer", "Mic1 Playback Switch", "Mic1 Amplifier" },
+ { "Right Mixer", "Mic2 Playback Switch", "Mic2 Amplifier" },
+
+ /* Left ADC Mixer Routes */
+ { "Left ADC Mixer", "Mixer Capture Switch", "Left Mixer" },
+ { "Left ADC Mixer", "Mixer Reversed Capture Switch", "Right Mixer" },
+ { "Left ADC Mixer", "Line In Capture Switch", "LINEIN" },
+ { "Left ADC Mixer", "Mic1 Capture Switch", "Mic1 Amplifier" },
+ { "Left ADC Mixer", "Mic2 Capture Switch", "Mic2 Amplifier" },
+
+ /* Right ADC Mixer Routes */
+ { "Right ADC Mixer", "Mixer Capture Switch", "Right Mixer" },
+ { "Right ADC Mixer", "Mixer Reversed Capture Switch", "Left Mixer" },
+ { "Right ADC Mixer", "Line In Capture Switch", "LINEIN" },
+ { "Right ADC Mixer", "Mic1 Capture Switch", "Mic1 Amplifier" },
+ { "Right ADC Mixer", "Mic2 Capture Switch", "Mic2 Amplifier" },
+
+ /* ADC Routes */
+ { "Left ADC", NULL, "Left ADC Mixer" },
+ { "Right ADC", NULL, "Right ADC Mixer" },
+};
+
+/* headphone specific controls, widgets, and routes */
+static const DECLARE_TLV_DB_SCALE(sun8i_codec_hp_vol_scale, -6300, 100, 1);
+static const struct snd_kcontrol_new sun8i_codec_headphone_controls[] = {
+ SOC_SINGLE_TLV("Headphone Playback Volume",
+ SUN8I_ADDA_HP_VOLC,
+ SUN8I_ADDA_HP_VOLC_HP_VOL, 0x3f, 0,
+ sun8i_codec_hp_vol_scale),
+ SOC_DOUBLE("Headphone Playback Switch",
+ SUN8I_ADDA_DAC_PA_SRC,
+ SUN8I_ADDA_DAC_PA_SRC_LHPPAMUTE,
+ SUN8I_ADDA_DAC_PA_SRC_RHPPAMUTE, 1, 0),
+};
+
+static const char * const sun8i_codec_hp_src_enum_text[] = {
+ "DAC", "Mixer",
+};
+
+static SOC_ENUM_DOUBLE_DECL(sun8i_codec_hp_src_enum,
+ SUN8I_ADDA_DAC_PA_SRC,
+ SUN8I_ADDA_DAC_PA_SRC_LHPIS,
+ SUN8I_ADDA_DAC_PA_SRC_RHPIS,
+ sun8i_codec_hp_src_enum_text);
+
+static const struct snd_kcontrol_new sun8i_codec_hp_src[] = {
+ SOC_DAPM_ENUM("Headphone Source Playback Route",
+ sun8i_codec_hp_src_enum),
+};
+
+static const struct snd_soc_dapm_widget sun8i_codec_headphone_widgets[] = {
+ SND_SOC_DAPM_MUX("Headphone Source Playback Route",
+ SND_SOC_NOPM, 0, 0, sun8i_codec_hp_src),
+ SND_SOC_DAPM_OUT_DRV("Headphone Amp", SUN8I_ADDA_PAEN_HP_CTRL,
+ SUN8I_ADDA_PAEN_HP_CTRL_HPPAEN, 0, NULL, 0),
+ SND_SOC_DAPM_SUPPLY("HPCOM Protection", SUN8I_ADDA_PAEN_HP_CTRL,
+ SUN8I_ADDA_PAEN_HP_CTRL_COMPTEN, 0, NULL, 0),
+ SND_SOC_DAPM_REG(snd_soc_dapm_supply, "HPCOM", SUN8I_ADDA_PAEN_HP_CTRL,
+ SUN8I_ADDA_PAEN_HP_CTRL_HPCOM_FC, 0x3, 0x3, 0),
+ SND_SOC_DAPM_OUTPUT("HP"),
+};
+
+static const struct snd_soc_dapm_route sun8i_codec_headphone_routes[] = {
+ { "Headphone Source Playback Route", "DAC", "Left DAC" },
+ { "Headphone Source Playback Route", "DAC", "Right DAC" },
+ { "Headphone Source Playback Route", "Mixer", "Left Mixer" },
+ { "Headphone Source Playback Route", "Mixer", "Right Mixer" },
+ { "Headphone Amp", NULL, "Headphone Source Playback Route" },
+ { "HPCOM", NULL, "HPCOM Protection" },
+ { "HP", NULL, "Headphone Amp" },
+};
+
+static int sun8i_codec_add_headphone(struct snd_soc_component *cmpnt)
+{
+ struct snd_soc_dapm_context *dapm = snd_soc_component_get_dapm(cmpnt);
+ struct device *dev = cmpnt->dev;
+ int ret;
+
+ ret = snd_soc_add_component_controls(cmpnt,
+ sun8i_codec_headphone_controls,
+ ARRAY_SIZE(sun8i_codec_headphone_controls));
+ if (ret) {
+ dev_err(dev, "Failed to add Headphone controls: %d\n", ret);
+ return ret;
+ }
+
+ ret = snd_soc_dapm_new_controls(dapm, sun8i_codec_headphone_widgets,
+ ARRAY_SIZE(sun8i_codec_headphone_widgets));
+ if (ret) {
+ dev_err(dev, "Failed to add Headphone DAPM widgets: %d\n", ret);
+ return ret;
+ }
+
+ ret = snd_soc_dapm_add_routes(dapm, sun8i_codec_headphone_routes,
+ ARRAY_SIZE(sun8i_codec_headphone_routes));
+ if (ret) {
+ dev_err(dev, "Failed to add Headphone DAPM routes: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+/* hmic specific widget */
+static const struct snd_soc_dapm_widget sun8i_codec_hmic_widgets[] = {
+ SND_SOC_DAPM_SUPPLY("HBIAS", SUN8I_ADDA_MIC1G_MICBIAS_CTRL,
+ SUN8I_ADDA_MIC1G_MICBIAS_CTRL_HMICBIASEN,
+ 0, NULL, 0),
+};
+
+static int sun8i_codec_add_hmic(struct snd_soc_component *cmpnt)
+{
+ struct snd_soc_dapm_context *dapm = snd_soc_component_get_dapm(cmpnt);
+ struct device *dev = cmpnt->dev;
+ int ret;
+
+ ret = snd_soc_dapm_new_controls(dapm, sun8i_codec_hmic_widgets,
+ ARRAY_SIZE(sun8i_codec_hmic_widgets));
+ if (ret)
+ dev_err(dev, "Failed to add Mic3 DAPM widgets: %d\n", ret);
+
+ return ret;
+}
+
+/* line out specific controls, widgets and routes */
+static const DECLARE_TLV_DB_RANGE(sun8i_codec_lineout_vol_scale,
+ 0, 1, TLV_DB_SCALE_ITEM(TLV_DB_GAIN_MUTE, 0, 1),
+ 2, 31, TLV_DB_SCALE_ITEM(-4350, 150, 0),
+);
+static const struct snd_kcontrol_new sun8i_codec_lineout_controls[] = {
+ SOC_SINGLE_TLV("Line Out Playback Volume",
+ SUN8I_ADDA_PHONE_GAIN_CTRL,
+ SUN8I_ADDA_PHONE_GAIN_CTRL_LINEOUT_VOL, 0x1f, 0,
+ sun8i_codec_lineout_vol_scale),
+ SOC_DOUBLE("Line Out Playback Switch",
+ SUN8I_ADDA_MIC2G_CTRL,
+ SUN8I_ADDA_MIC2G_CTRL_LINEOUTLEN,
+ SUN8I_ADDA_MIC2G_CTRL_LINEOUTREN, 1, 0),
+};
+
+static const char * const sun8i_codec_lineout_src_enum_text[] = {
+ "Stereo", "Mono Differential",
+};
+
+static SOC_ENUM_DOUBLE_DECL(sun8i_codec_lineout_src_enum,
+ SUN8I_ADDA_MIC2G_CTRL,
+ SUN8I_ADDA_MIC2G_CTRL_LINEOUTLSRC,
+ SUN8I_ADDA_MIC2G_CTRL_LINEOUTRSRC,
+ sun8i_codec_lineout_src_enum_text);
+
+static const struct snd_kcontrol_new sun8i_codec_lineout_src[] = {
+ SOC_DAPM_ENUM("Line Out Source Playback Route",
+ sun8i_codec_lineout_src_enum),
+};
+
+static const struct snd_soc_dapm_widget sun8i_codec_lineout_widgets[] = {
+ SND_SOC_DAPM_MUX("Line Out Source Playback Route",
+ SND_SOC_NOPM, 0, 0, sun8i_codec_lineout_src),
+ /* It is unclear if this is a buffer or gate, model it as a supply */
+ SND_SOC_DAPM_SUPPLY("Line Out Enable", SUN8I_ADDA_PAEN_HP_CTRL,
+ SUN8I_ADDA_PAEN_HP_CTRL_LINEOUTEN, 0, NULL, 0),
+ SND_SOC_DAPM_OUTPUT("LINEOUT"),
+};
+
+static const struct snd_soc_dapm_route sun8i_codec_lineout_routes[] = {
+ { "Line Out Source Playback Route", "Stereo", "Left Mixer" },
+ { "Line Out Source Playback Route", "Stereo", "Right Mixer" },
+ { "Line Out Source Playback Route", "Mono Differential", "Left Mixer" },
+ { "Line Out Source Playback Route", "Mono Differential", "Right Mixer" },
+ { "LINEOUT", NULL, "Line Out Source Playback Route" },
+ { "LINEOUT", NULL, "Line Out Enable", },
+};
+
+static int sun8i_codec_add_lineout(struct snd_soc_component *cmpnt)
+{
+ struct snd_soc_dapm_context *dapm = snd_soc_component_get_dapm(cmpnt);
+ struct device *dev = cmpnt->dev;
+ int ret;
+
+ ret = snd_soc_add_component_controls(cmpnt,
+ sun8i_codec_lineout_controls,
+ ARRAY_SIZE(sun8i_codec_lineout_controls));
+ if (ret) {
+ dev_err(dev, "Failed to add Line Out controls: %d\n", ret);
+ return ret;
+ }
+
+ ret = snd_soc_dapm_new_controls(dapm, sun8i_codec_lineout_widgets,
+ ARRAY_SIZE(sun8i_codec_lineout_widgets));
+ if (ret) {
+ dev_err(dev, "Failed to add Line Out DAPM widgets: %d\n", ret);
+ return ret;
+ }
+
+ ret = snd_soc_dapm_add_routes(dapm, sun8i_codec_lineout_routes,
+ ARRAY_SIZE(sun8i_codec_lineout_routes));
+ if (ret) {
+ dev_err(dev, "Failed to add Line Out DAPM routes: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+struct sun8i_codec_analog_quirks {
+ bool has_headphone;
+ bool has_hmic;
+ bool has_lineout;
+};
+
+static const struct sun8i_codec_analog_quirks sun8i_a23_quirks = {
+ .has_headphone = true,
+ .has_hmic = true,
+};
+
+static const struct sun8i_codec_analog_quirks sun8i_h3_quirks = {
+ .has_lineout = true,
+};
+
+static int sun8i_codec_analog_cmpnt_probe(struct snd_soc_component *cmpnt)
+{
+ struct device *dev = cmpnt->dev;
+ const struct sun8i_codec_analog_quirks *quirks;
+ int ret;
+
+ /*
+ * This would never return NULL unless someone directly registers a
+ * platform device matching this driver's name, without specifying a
+ * device tree node.
+ */
+ quirks = of_device_get_match_data(dev);
+
+ /* Add controls, widgets, and routes for individual features */
+
+ if (quirks->has_headphone) {
+ ret = sun8i_codec_add_headphone(cmpnt);
+ if (ret)
+ return ret;
+ }
+
+ if (quirks->has_hmic) {
+ sun8i_codec_add_hmic(cmpnt);
+ if (ret)
+ return ret;
+ }
+
+ if (quirks->has_lineout) {
+ ret = sun8i_codec_add_lineout(cmpnt);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+static const struct snd_soc_component_driver sun8i_codec_analog_cmpnt_drv = {
+ .controls = sun8i_codec_common_controls,
+ .num_controls = ARRAY_SIZE(sun8i_codec_common_controls),
+ .dapm_widgets = sun8i_codec_common_widgets,
+ .num_dapm_widgets = ARRAY_SIZE(sun8i_codec_common_widgets),
+ .dapm_routes = sun8i_codec_common_routes,
+ .num_dapm_routes = ARRAY_SIZE(sun8i_codec_common_routes),
+ .probe = sun8i_codec_analog_cmpnt_probe,
+};
+
+static const struct of_device_id sun8i_codec_analog_of_match[] = {
+ {
+ .compatible = "allwinner,sun8i-a23-codec-analog",
+ .data = &sun8i_a23_quirks,
+ },
+ {
+ .compatible = "allwinner,sun8i-h3-codec-analog",
+ .data = &sun8i_h3_quirks,
+ },
+ {}
+};
+MODULE_DEVICE_TABLE(of, sun8i_codec_analog_of_match);
+
+static int sun8i_codec_analog_probe(struct platform_device *pdev)
+{
+ struct resource *res;
+ struct regmap *regmap;
+ void __iomem *base;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(base)) {
+ dev_err(&pdev->dev, "Failed to map the registers\n");
+ return PTR_ERR(base);
+ }
+
+ regmap = devm_regmap_init(&pdev->dev, NULL, base, &adda_pr_regmap_cfg);
+ if (IS_ERR(regmap)) {
+ dev_err(&pdev->dev, "Failed to create regmap\n");
+ return PTR_ERR(regmap);
+ }
+
+ return devm_snd_soc_register_component(&pdev->dev,
+ &sun8i_codec_analog_cmpnt_drv,
+ NULL, 0);
+}
+
+static struct platform_driver sun8i_codec_analog_driver = {
+ .driver = {
+ .name = "sun8i-codec-analog",
+ .of_match_table = sun8i_codec_analog_of_match,
+ },
+ .probe = sun8i_codec_analog_probe,
+};
+module_platform_driver(sun8i_codec_analog_driver);
+
+MODULE_DESCRIPTION("Allwinner internal codec analog controls driver");
+MODULE_AUTHOR("Chen-Yu Tsai <wens@csie.org>");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:sun8i-codec-analog");
--
2.10.2
^ permalink raw reply related
* [PATCH 0/2] serial: introduce DSR handling property
From: Uwe Kleine-König @ 2016-11-22 19:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479834851-32442-1-git-send-email-chf.fritz@googlemail.com>
On Tue, Nov 22, 2016 at 06:14:09PM +0100, Christoph Fritz wrote:
> This patchset introduces device-tree property "disable-dsr" including
> documentation and usage.
>
> Christoph Fritz (2):
> doc: DT: add generic serial property to disable DSR
I'd add the documentation for all handshaking lines, not only dsr. And
I'd call it disable-hw-dsr, otherwise
{
disable-dsr;
dsr-gpios = <&gpio1 2 GPIO_ACTIVE_LOW>;
}
looks strange. (Not 100% sure this would make sense, but I think it
does.)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH 2/2] arm64: Pass RAM boundary and enable-dcache flag to purgatory
From: Geoff Levand @ 2016-11-22 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b1b9e70db9d08364040436154cf0cf2f4600da49.1479788404.git.panand@redhat.com>
Hi Pratyush,
On 11/21/2016 08:32 PM, Pratyush Anand wrote:
> When "enable-dcache" is passed to the kexec() command line, kexec-tools
> passes this information to purgatory, which in turn enables cache during
> sha-256 verification.
What's the point of this enable-dcache option? Why not just
always enable the cache if we can?
-Geoff
^ permalink raw reply
* [PATCH 0/2] kexec-tools: arm64: Add dcache enabling facility
From: Geoff Levand @ 2016-11-22 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479788404.git.panand@redhat.com>
Hi Pratyush,
On 11/21/2016 08:32 PM, Pratyush Anand wrote:
> It takes more that 2 minutes to verify SHA in purgatory when vmlinuz image
> is around 13MB and initramfs is around 30MB. It takes more than 20 second
> even when we have -O2 optimization enabled. However, if dcache is enabled
> during purgatory execution then, it takes just a second in SHA verification.
As I had mentioned in another thread, I think -O2 optimization is
sufficient considering the complexity of the code needed to enable
the dcache. Integrity checking is only needed for crash dump
support. If the crash reboot takes an extra 20 seconds does it
matter?
For the re-boot of a stable system where the new kernel is loaded
then immediately kexec'ed into integrity checking is not needed.
For that arm64 support needs to be added to kexec-lite.
-Geoff
^ permalink raw reply
* [PATCH v2 1/5] ARM: memory: da8xx-ddrctl: new driver
From: Frank Rowand @ 2016-11-22 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <800171a8-2e2c-2afb-f96d-800a17eaa17a@ti.com>
On 11/21/16 22:25, Sekhar Nori wrote:
> Hi Frank,
>
> On Tuesday 22 November 2016 07:13 AM, Frank Rowand wrote:
>> On 11/21/16 08:33, Sekhar Nori wrote:
>>> On Monday 31 October 2016 08:15 PM, Bartosz Golaszewski wrote:
>>>> +static int da8xx_ddrctl_probe(struct platform_device *pdev)
>>>> +{
>>>> + const struct da8xx_ddrctl_config_knob *knob;
>>>> + const struct da8xx_ddrctl_setting *setting;
>>>> + struct device_node *node;
>>>> + struct resource *res;
>>>> + void __iomem *ddrctl;
>>>> + struct device *dev;
>>>> + u32 reg;
>>>> +
>>>> + dev = &pdev->dev;
>>>> + node = dev->of_node;
>>>> +
>>>> + setting = da8xx_ddrctl_get_board_settings();
>>>> + if (!setting) {
>>>> + dev_err(dev, "no settings for board '%s'\n",
>>>> + of_flat_dt_get_machine_name());
>>>> + return -EINVAL;
>>>> + }
>>>
>>> This causes a section mismatch because of_flat_dt_get_machine_name()
>>> has an __init annotation. I did not notice that before, sorry.
>>>
>>> It can be fixed with a patch like below:
>>>
>>> ---8<---
>>> diff --git a/drivers/memory/da8xx-ddrctl.c b/drivers/memory/da8xx-ddrctl.c
>>> index a20e7bbbcbe0..9ca5aab3ac54 100644
>>> --- a/drivers/memory/da8xx-ddrctl.c
>>> +++ b/drivers/memory/da8xx-ddrctl.c
>>> @@ -102,6 +102,18 @@ static const struct da8xx_ddrctl_setting *da8xx_ddrctl_get_board_settings(void)
>>> return NULL;
>>> }
>>>
>>> +static const char* da8xx_ddrctl_get_machine_name(void)
>>> +{
>>> + const char *str;
>>> + int ret;
>>> +
>>> + ret = of_property_read_string(of_root, "model", &str);
>>> + if (ret)
>>> + ret = of_property_read_string(of_root, "compatible", &str);
>>> +
>>> + return str;
>>> +}
>>> +
>>> static int da8xx_ddrctl_probe(struct platform_device *pdev)
>>> {
>>> const struct da8xx_ddrctl_config_knob *knob;
>>> @@ -118,7 +130,7 @@ static int da8xx_ddrctl_probe(struct platform_device *pdev)
>>> setting = da8xx_ddrctl_get_board_settings();
>>> if (!setting) {
>>> dev_err(dev, "no settings for board '%s'\n",
>>> - of_flat_dt_get_machine_name());
>>
>> da8xx_ddrctl_get_board_settings() tries to match based on the "compatible"
>> property in the root node. The "model" property in the root node has
>> nothing to do with the failure to match. So creating and then using
>> da8xx_ddrctl_get_machine_name() to potentially report model is not useful.
>>
>> It should be sufficient to simply report that no compatible matched.
>
> I agree with you on this. Even if model name is printed, you will have
> to go back and check the compatible anyway. But I think it will be
> useful to print the compatible instead of just reporting that nothing
> matched.
>
> Bartosz, if you agree too, could you send a fix patch just printing the
> compatible?
Please note that the compatible property might contain several strings, not just
a single string.
>
> Thanks,
> Sekhar
>
^ permalink raw reply
* [PATCH 0/9] AC97 device/driver model revamp
From: Mark Brown @ 2016-11-22 18:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477510907-23495-1-git-send-email-robert.jarzmik@free.fr>
On Wed, Oct 26, 2016 at 09:41:38PM +0200, Robert Jarzmik wrote:
> The driving ideas are still the same, and I put them in [1] for memory. This is
> the first post RFC submission. In order to make a full demonstration of the
> framework, wm97xx was converted to an MFD, see [2] for the "why".
This all looks nice to me, I did spot a few things but I don't think I
had anything that wasn't already raised by someone else so didn't repeat
them. Thanks for stepping up and doing this work!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161122/7e4a6ad6/attachment.sig>
^ permalink raw reply
* [alsa-devel] [PATCH 2/9] ALSA: ac97: add an ac97 bus
From: Mark Brown @ 2016-11-22 18:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6b97a129-bd10-b9be-616d-a3ea3b91b103@metafoo.de>
On Thu, Nov 10, 2016 at 12:38:40PM +0100, Lars-Peter Clausen wrote:
> On 11/09/2016 10:27 PM, Robert Jarzmik wrote:
> > here, ie. that the rescan is a bug, or if it's more an "Occam's razor"
> > discussion ?
> Maybe we can just leave the rescanning out for now and think about how to
> best handle it when the need arises.
Yes, I think that's best - I suspect it'd be something that'd need to be
triggered by a driver for an AC'97 CODEC doing power management but I
imagine that if we were going to have such a system we'd have run into
it already anyway.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161122/3891c7e3/attachment.sig>
^ permalink raw reply
* [PATCH 2/2] PCI: iproc: avoid maybe-uninitialized warning
From: Ray Jui @ 2016-11-22 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122141844.1655574-2-arnd@arndb.de>
Hi Arnd,
On 11/22/2016 6:17 AM, Arnd Bergmann wrote:
> gcc notices that calling iproc_pcie_setup_ib with ib->nr_regions==0
> would result in an uninitialized return value:
>
> drivers/pci/host/pcie-iproc.c: In function 'iproc_pcie_setup_ib':
> drivers/pci/host/pcie-iproc.c:894:6: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>
> This can't really happen, but the correct behavior of the function
> is probably to return -EINVAL if it ever did.
>
> Fixes: 4213e15c364e ("PCI: iproc: Make outbound mapping code more generic")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/pci/host/pcie-iproc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
> index 857ff5198317..0359569c8d78 100644
> --- a/drivers/pci/host/pcie-iproc.c
> +++ b/drivers/pci/host/pcie-iproc.c
> @@ -936,6 +936,7 @@ static int iproc_pcie_setup_ib(struct iproc_pcie *pcie,
>
> }
> }
> + ret = -EINVAL;
> err_ib:
> dev_err(dev, "unable to configure inbound mapping\n");
> dev_err(dev, "axi %pap, pci %pap, res size %pap\n",
>
This change is good, but in my opinion, a further improvement for
clarity would be to initialize 'ret' to -EINVAL in the beginning of this
function when 'ret' is declared. What do you think?
Thanks,
Ray
^ permalink raw reply
* [PATCH 1/2] PCI: iproc: fix 32-bit build
From: Ray Jui @ 2016-11-22 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122141844.1655574-1-arnd@arndb.de>
On 11/22/2016 6:17 AM, Arnd Bergmann wrote:
> The newly added code to setup the inbound ranges causes a link error
> on 32-bit machines from a 32-bit division:
>
> drivers/pci/host/pcie-iproc.o: In function `iproc_pcie_setup_ib':
> pcie-iproc.c:(.text.iproc_pcie_setup_ib+0x14c): undefined reference to `__aeabi_uldivmod'
>
> As both sides of the division are always power-of-two numbers and
> we already rely on that, we can use a shift instead.
>
> Fixes: 87c240b19bba ("PCI: iproc: Add inbound DMA mapping support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/pci/host/pcie-iproc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
> index d10e6aa32e0d..857ff5198317 100644
> --- a/drivers/pci/host/pcie-iproc.c
> +++ b/drivers/pci/host/pcie-iproc.c
> @@ -865,7 +865,7 @@ static int iproc_pcie_ib_write(struct iproc_pcie *pcie, int region_idx,
> * Now program the IMAP registers. Each IARR region may have one or
> * more IMAP windows.
> */
> - size /= nr_windows;
> + size >>= ilog2(nr_windows);
> for (window_idx = 0; window_idx < nr_windows; window_idx++) {
> val = readl(pcie->base + imap_offset);
> val |= lower_32_bits(axi_addr) | IMAP_VALID;
>
Hmmm, somehow we've never seen this link error for the ARM32 based
platforms that we build for. Does it behave differently between
different versions of compilers?
Nevertheless, this is a good change to take, thanks!
Acked-by: Ray Jui <ray.jui@broadcom.com>
^ permalink raw reply
* Applied "spi: spi-fsl-dspi: Fix incorrect freeing of DMA allocated buffers" to the spi tree
From: Mark Brown @ 2016-11-22 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fd3b1fa5d9fb2a0c2d1f6ded314acf20f5081a89.1479796821.git.maitysanchayan@gmail.com>
The patch
spi: spi-fsl-dspi: Fix incorrect freeing of DMA allocated buffers
has been applied to the spi tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.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 27d21e9f988e527982a7516fcf411994f498787d Mon Sep 17 00:00:00 2001
From: Sanchayan Maity <maitysanchayan@gmail.com>
Date: Tue, 22 Nov 2016 12:31:32 +0530
Subject: [PATCH] spi: spi-fsl-dspi: Fix incorrect freeing of DMA allocated
buffers
Buffers allocated with a call to dma_alloc_coherent should be
freed with dma_free_coherent instead of the currently used
devm_kfree.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/spi/spi-fsl-dspi.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index b1ee1f521ba0..22f7ce1279bd 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -427,9 +427,11 @@ static int dspi_request_dma(struct fsl_dspi *dspi, phys_addr_t phy_addr)
return 0;
err_slave_config:
- devm_kfree(dev, dma->rx_dma_buf);
+ dma_free_coherent(dev, DSPI_DMA_BUFSIZE,
+ dma->rx_dma_buf, dma->rx_dma_phys);
err_rx_dma_buf:
- devm_kfree(dev, dma->tx_dma_buf);
+ dma_free_coherent(dev, DSPI_DMA_BUFSIZE,
+ dma->tx_dma_buf, dma->tx_dma_phys);
err_tx_dma_buf:
dma_release_channel(dma->chan_tx);
err_tx_channel:
--
2.10.2
^ permalink raw reply related
* Applied "spi: spi-fsl-dspi: Fix incorrect DMA setup" to the spi tree
From: Mark Brown @ 2016-11-22 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a36bac5f2499d1002693a7dbf95982bab186e51f.1479706671.git.maitysanchayan@gmail.com>
The patch
spi: spi-fsl-dspi: Fix incorrect DMA setup
has been applied to the spi tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.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 1eaccf210c59e04eb6e9b5469a60d6609c95ac61 Mon Sep 17 00:00:00 2001
From: Sanchayan Maity <maitysanchayan@gmail.com>
Date: Tue, 22 Nov 2016 12:31:30 +0530
Subject: [PATCH] spi: spi-fsl-dspi: Fix incorrect DMA setup
Currently dmaengine_prep_slave_single was being called with length
set to the complete DMA buffer size. This resulted in unwanted bytes
being transferred to the SPI register leading to clock and MOSI lines
having unwanted data even after chip select got deasserted and the
required bytes having been transferred.
While at it also clean up the use of curr_xfer_len which is central
to the DMA setup, from bytes to DMA transfers for every use.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
Reviewed-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/spi/spi-fsl-dspi.c | 35 ++++++++++++++++++-----------------
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 22f7ce1279bd..cb41c327bd77 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -151,6 +151,7 @@ static const struct fsl_dspi_devtype_data ls2085a_data = {
};
struct fsl_dspi_dma {
+ /* Length of transfer in words of DSPI_FIFO_SIZE */
u32 curr_xfer_len;
u32 *tx_dma_buf;
@@ -217,15 +218,13 @@ static void dspi_rx_dma_callback(void *arg)
struct fsl_dspi *dspi = arg;
struct fsl_dspi_dma *dma = dspi->dma;
int rx_word;
- int i, len;
+ int i;
u16 d;
rx_word = is_double_byte_mode(dspi);
- len = rx_word ? (dma->curr_xfer_len / 2) : dma->curr_xfer_len;
-
if (!(dspi->dataflags & TRAN_STATE_RX_VOID)) {
- for (i = 0; i < len; i++) {
+ for (i = 0; i < dma->curr_xfer_len; i++) {
d = dspi->dma->rx_dma_buf[i];
rx_word ? (*(u16 *)dspi->rx = d) :
(*(u8 *)dspi->rx = d);
@@ -242,14 +241,12 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
struct device *dev = &dspi->pdev->dev;
int time_left;
int tx_word;
- int i, len;
+ int i;
u16 val;
tx_word = is_double_byte_mode(dspi);
- len = tx_word ? (dma->curr_xfer_len / 2) : dma->curr_xfer_len;
-
- for (i = 0; i < len - 1; i++) {
+ for (i = 0; i < dma->curr_xfer_len - 1; i++) {
val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
dspi->dma->tx_dma_buf[i] =
SPI_PUSHR_TXDATA(val) | SPI_PUSHR_PCS(dspi->cs) |
@@ -265,7 +262,9 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,
dma->tx_dma_phys,
- DSPI_DMA_BUFSIZE, DMA_MEM_TO_DEV,
+ dma->curr_xfer_len *
+ DMA_SLAVE_BUSWIDTH_4_BYTES,
+ DMA_MEM_TO_DEV,
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!dma->tx_desc) {
dev_err(dev, "Not able to get desc for DMA xfer\n");
@@ -281,7 +280,9 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
dma->rx_desc = dmaengine_prep_slave_single(dma->chan_rx,
dma->rx_dma_phys,
- DSPI_DMA_BUFSIZE, DMA_DEV_TO_MEM,
+ dma->curr_xfer_len *
+ DMA_SLAVE_BUSWIDTH_4_BYTES,
+ DMA_DEV_TO_MEM,
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!dma->rx_desc) {
dev_err(dev, "Not able to get desc for DMA xfer\n");
@@ -328,17 +329,17 @@ static int dspi_dma_xfer(struct fsl_dspi *dspi)
struct device *dev = &dspi->pdev->dev;
int curr_remaining_bytes;
int bytes_per_buffer;
- int tx_word;
+ int word = 1;
int ret = 0;
- tx_word = is_double_byte_mode(dspi);
+ if (is_double_byte_mode(dspi))
+ word = 2;
curr_remaining_bytes = dspi->len;
+ bytes_per_buffer = DSPI_DMA_BUFSIZE / DSPI_FIFO_SIZE;
while (curr_remaining_bytes) {
/* Check if current transfer fits the DMA buffer */
- dma->curr_xfer_len = curr_remaining_bytes;
- bytes_per_buffer = DSPI_DMA_BUFSIZE /
- (DSPI_FIFO_SIZE / (tx_word ? 2 : 1));
- if (curr_remaining_bytes > bytes_per_buffer)
+ dma->curr_xfer_len = curr_remaining_bytes / word;
+ if (dma->curr_xfer_len > bytes_per_buffer)
dma->curr_xfer_len = bytes_per_buffer;
ret = dspi_next_xfer_dma_submit(dspi);
@@ -347,7 +348,7 @@ static int dspi_dma_xfer(struct fsl_dspi *dspi)
goto exit;
} else {
- curr_remaining_bytes -= dma->curr_xfer_len;
+ curr_remaining_bytes -= dma->curr_xfer_len * word;
if (curr_remaining_bytes < 0)
curr_remaining_bytes = 0;
dspi->len = curr_remaining_bytes;
--
2.10.2
^ permalink raw reply related
* Applied "spi: spi-fsl-dspi: Fix continuous selection format" to the spi tree
From: Mark Brown @ 2016-11-22 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fd5dac77580ba02edb38319d04345e23a34b2d9d.1479796821.git.maitysanchayan@gmail.com>
The patch
spi: spi-fsl-dspi: Fix continuous selection format
has been applied to the spi tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.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 ccf7d8ee3d6eb600338a184e9a192ec1d5aee924 Mon Sep 17 00:00:00 2001
From: Sanchayan Maity <maitysanchayan@gmail.com>
Date: Tue, 22 Nov 2016 12:31:31 +0530
Subject: [PATCH] spi: spi-fsl-dspi: Fix continuous selection format
Current DMA implementation was not handling the continuous selection
format viz. SPI chip select would be deasserted even between sequential
serial transfers.
Use existing dspi_data_to_pushr function to restructure the transmit
code path and set or reset the CONT bit on same lines as code path
in EOQ mode does. This correctly implements continuous selection format
while also correcting and cleaning up the transmit code path.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/spi/spi-fsl-dspi.c | 20 ++++++--------------
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index cb41c327bd77..7ada112bfd85 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -196,6 +196,8 @@ struct fsl_dspi {
struct fsl_dspi_dma *dma;
};
+static u32 dspi_data_to_pushr(struct fsl_dspi *dspi, int tx_word);
+
static inline int is_double_byte_mode(struct fsl_dspi *dspi)
{
unsigned int val;
@@ -242,24 +244,15 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
int time_left;
int tx_word;
int i;
- u16 val;
tx_word = is_double_byte_mode(dspi);
- for (i = 0; i < dma->curr_xfer_len - 1; i++) {
- val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
- dspi->dma->tx_dma_buf[i] =
- SPI_PUSHR_TXDATA(val) | SPI_PUSHR_PCS(dspi->cs) |
- SPI_PUSHR_CTAS(0) | SPI_PUSHR_CONT;
- dspi->tx += tx_word + 1;
+ for (i = 0; i < dma->curr_xfer_len; i++) {
+ dspi->dma->tx_dma_buf[i] = dspi_data_to_pushr(dspi, tx_word);
+ if ((dspi->cs_change) && (!dspi->len))
+ dspi->dma->tx_dma_buf[i] &= ~SPI_PUSHR_CONT;
}
- val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
- dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
- SPI_PUSHR_PCS(dspi->cs) |
- SPI_PUSHR_CTAS(0);
- dspi->tx += tx_word + 1;
-
dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,
dma->tx_dma_phys,
dma->curr_xfer_len *
@@ -351,7 +344,6 @@ static int dspi_dma_xfer(struct fsl_dspi *dspi)
curr_remaining_bytes -= dma->curr_xfer_len * word;
if (curr_remaining_bytes < 0)
curr_remaining_bytes = 0;
- dspi->len = curr_remaining_bytes;
}
}
--
2.10.2
^ permalink raw reply related
* Applied "ASoC: samsung: Remove non-existing MACH dependencies" to the asoc tree
From: Mark Brown @ 2016-11-22 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479566911-5580-2-git-send-email-krzk@kernel.org>
The patch
ASoC: samsung: Remove non-existing MACH dependencies
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 f8cbab42d98298ab9c4878dc9105d350b0b902ff Mon Sep 17 00:00:00 2001
From: Krzysztof Kozlowski <krzk@kernel.org>
Date: Sun, 20 Nov 2016 21:24:51 +0200
Subject: [PATCH] ASoC: samsung: Remove non-existing MACH dependencies
MACH_SMDKC100 was removed in commit b8529ec1c1b0 ("ARM: S5PC100: no more
support S5PC100 SoC"). MACH_SMDKV210 and MACH_SMDKC110 in commit
28c8331d386 ("ARM: S5PV210: Remove support for board files").
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/samsung/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index 79ae6a7c93ff..ea0fa9971a0c 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -49,7 +49,7 @@ config SND_SOC_SAMSUNG_JIVE_WM8750
config SND_SOC_SAMSUNG_SMDK_WM8580
tristate "SoC I2S Audio support for WM8580 on SMDK"
- depends on MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110
+ depends on MACH_SMDK6410
depends on I2C
select SND_SOC_WM8580
select SND_SAMSUNG_I2S
--
2.10.2
^ permalink raw reply related
* Applied "ASoC: samsung: smdk_wm8580: Remove old platforms and drop mach-types usage" to the asoc tree
From: Mark Brown @ 2016-11-22 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479669895-19124-3-git-send-email-krzk@kernel.org>
The patch
ASoC: samsung: smdk_wm8580: Remove old platforms and drop mach-types usage
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 cd9e2b62768c21c051c585f9d4935b4fa6e9603e Mon Sep 17 00:00:00 2001
From: Krzysztof Kozlowski <krzk@kernel.org>
Date: Sun, 20 Nov 2016 21:24:52 +0200
Subject: [PATCH] ASoC: samsung: smdk_wm8580: Remove old platforms and drop
mach-types usage
MACH_SMDKC100, MACH_SMDKV210 and MACH_SMDKC110 are no longer supported
so we can drop the dead code. After this the driver no longer
differentiates between machines (S3C24xx machines are not supported by
it) so there is no need to override I2S device id in cpu_dai_name and
SEC_PLAYBACK dai_link can be removed as well.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/samsung/smdk_wm8580.c | 30 +++---------------------------
1 file changed, 3 insertions(+), 27 deletions(-)
diff --git a/sound/soc/samsung/smdk_wm8580.c b/sound/soc/samsung/smdk_wm8580.c
index 548bfd993788..de724ce7b955 100644
--- a/sound/soc/samsung/smdk_wm8580.c
+++ b/sound/soc/samsung/smdk_wm8580.c
@@ -14,8 +14,6 @@
#include <sound/soc.h>
#include <sound/pcm_params.h>
-#include <asm/mach-types.h>
-
#include "../codecs/wm8580.h"
#include "i2s.h"
@@ -147,7 +145,6 @@ static int smdk_wm8580_init_paiftx(struct snd_soc_pcm_runtime *rtd)
enum {
PRI_PLAYBACK = 0,
PRI_CAPTURE,
- SEC_PLAYBACK,
};
#define SMDK_DAI_FMT (SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | \
@@ -157,7 +154,7 @@ static struct snd_soc_dai_link smdk_dai[] = {
[PRI_PLAYBACK] = { /* Primary Playback i/f */
.name = "WM8580 PAIF RX",
.stream_name = "Playback",
- .cpu_dai_name = "samsung-i2s.0",
+ .cpu_dai_name = "samsung-i2s.2",
.codec_dai_name = "wm8580-hifi-playback",
.platform_name = "samsung-i2s.0",
.codec_name = "wm8580.0-001b",
@@ -167,7 +164,7 @@ static struct snd_soc_dai_link smdk_dai[] = {
[PRI_CAPTURE] = { /* Primary Capture i/f */
.name = "WM8580 PAIF TX",
.stream_name = "Capture",
- .cpu_dai_name = "samsung-i2s.0",
+ .cpu_dai_name = "samsung-i2s.2",
.codec_dai_name = "wm8580-hifi-capture",
.platform_name = "samsung-i2s.0",
.codec_name = "wm8580.0-001b",
@@ -175,23 +172,13 @@ static struct snd_soc_dai_link smdk_dai[] = {
.init = smdk_wm8580_init_paiftx,
.ops = &smdk_ops,
},
- [SEC_PLAYBACK] = { /* Sec_Fifo Playback i/f */
- .name = "Sec_FIFO TX",
- .stream_name = "Playback",
- .cpu_dai_name = "samsung-i2s-sec",
- .codec_dai_name = "wm8580-hifi-playback",
- .platform_name = "samsung-i2s-sec",
- .codec_name = "wm8580.0-001b",
- .dai_fmt = SMDK_DAI_FMT,
- .ops = &smdk_ops,
- },
};
static struct snd_soc_card smdk = {
.name = "SMDK-I2S",
.owner = THIS_MODULE,
.dai_link = smdk_dai,
- .num_links = 2,
+ .num_links = ARRAY_SIZE(smdk_dai),
.dapm_widgets = smdk_wm8580_dapm_widgets,
.num_dapm_widgets = ARRAY_SIZE(smdk_wm8580_dapm_widgets),
@@ -204,17 +191,6 @@ static struct platform_device *smdk_snd_device;
static int __init smdk_audio_init(void)
{
int ret;
- char *str;
-
- if (machine_is_smdkc100()
- || machine_is_smdkv210() || machine_is_smdkc110()) {
- smdk.num_links = 3;
- } else if (machine_is_smdk6410()) {
- str = (char *)smdk_dai[PRI_PLAYBACK].cpu_dai_name;
- str[strlen(str) - 1] = '2';
- str = (char *)smdk_dai[PRI_CAPTURE].cpu_dai_name;
- str[strlen(str) - 1] = '2';
- }
smdk_snd_device = platform_device_alloc("soc-audio", -1);
if (!smdk_snd_device)
--
2.10.2
^ permalink raw reply related
* Applied "ASoC: samsung: Enable COMPILE_TEST for entire Samsung ASoc" to the asoc tree
From: Mark Brown @ 2016-11-22 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479566911-5580-6-git-send-email-krzk@kernel.org>
The patch
ASoC: samsung: Enable COMPILE_TEST for entire Samsung ASoc
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 a41dcdeee5d87cf3852b857cc3a8507832ec8b42 Mon Sep 17 00:00:00 2001
From: Krzysztof Kozlowski <krzk@kernel.org>
Date: Sun, 20 Nov 2016 21:24:54 +0200
Subject: [PATCH] ASoC: samsung: Enable COMPILE_TEST for entire Samsung ASoc
Instead of build time, Samsung ASoC drivers have rather runtime
dependency on Exynos or other Samsung platforms. For building they
require Common Clock Framework. If it is provided they could be compile
tested to increase build coverage.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/samsung/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index ea0fa9971a0c..48dcd3dd9ec7 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -1,6 +1,7 @@
menuconfig SND_SOC_SAMSUNG
tristate "ASoC support for Samsung"
- depends on (PLAT_SAMSUNG || ARCH_EXYNOS)
+ depends on PLAT_SAMSUNG || ARCH_EXYNOS || COMPILE_TEST
+ depends on COMMON_CLK
select SND_SOC_GENERIC_DMAENGINE_PCM
---help---
Say Y or M if you want to add support for codecs attached to
--
2.10.2
^ permalink raw reply related
* Applied "ASoC: samsung: Enable COMPILE_TEST for SmartQ and WM8580" to the asoc tree
From: Mark Brown @ 2016-11-22 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479566911-5580-5-git-send-email-krzk@kernel.org>
The patch
ASoC: samsung: Enable COMPILE_TEST for SmartQ and WM8580
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 95f5609d223d661419061bd6231da01a317c30d9 Mon Sep 17 00:00:00 2001
From: Krzysztof Kozlowski <krzk@kernel.org>
Date: Sun, 20 Nov 2016 21:24:53 +0200
Subject: [PATCH] ASoC: samsung: Enable COMPILE_TEST for SmartQ and WM8580
The I2S sound drivers for SmartQ board and WM8580 codec can be compile
tested to increase build coverage.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/samsung/Kconfig | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index 48dcd3dd9ec7..a6cc6ca93fa7 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -50,7 +50,7 @@ config SND_SOC_SAMSUNG_JIVE_WM8750
config SND_SOC_SAMSUNG_SMDK_WM8580
tristate "SoC I2S Audio support for WM8580 on SMDK"
- depends on MACH_SMDK6410
+ depends on MACH_SMDK6410 || COMPILE_TEST
depends on I2C
select SND_SOC_WM8580
select SND_SAMSUNG_I2S
@@ -110,7 +110,8 @@ config SND_SOC_SAMSUNG_RX1950_UDA1380
config SND_SOC_SMARTQ
tristate "SoC I2S Audio support for SmartQ board"
- depends on MACH_SMARTQ && I2C
+ depends on MACH_SMARTQ || COMPILE_TEST
+ depends on I2C
select SND_SAMSUNG_I2S
select SND_SOC_WM8750
--
2.10.2
^ permalink raw reply related
* [PATCH 5/10] dt: bindings: Add bindings for Marvell Xenon SD Host Controller
From: Gregory CLEMENT @ 2016-11-22 17:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <15b06a12-ed69-03a7-ccc7-0c133ce1ac1e@marvell.com>
Hi Rob,
On jeu., nov. 10 2016, Ziji Hu <huziji@marvell.com> wrote:
[...]
>>> +
>>> +- reg:
>>> + * For "marvell,xenon-sdhci", one register area for Xenon IP.
>>> +
>>> + * For "marvell,armada-3700-sdhci", two register areas.
>>> + The first one for Xenon IP register. The second one for the Armada 3700 SOC
>>> + PHY PAD Voltage Control register.
>>> + Please follow the examples with compatible "marvell,armada-3700-sdhci"
>>> + in below.
>>> + Please also check property marvell,pad-type in below.
>>> +
>>> +Optional Properties:
>>> +- marvell,xenon-slotno:
>>
>> Multiple slots should be represented as child nodes IMO. I think some
>> other bindings already do this.
>>
>
> All the slots are entirely independent.
> I prefer to consider it as multiple independent SDHCs placed in
> a single IP, instead of that a IP contains multiple child slots.
It was indeed what I tried to show in my answer for the 1st version:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/461860.html
Maybe you missed it.
You also mentioned other bindings using child nodes, but for this one
we have one controller with only one set of register with multiple slots
(Atmel is an example). Here each slot have it own set of register.
Actually giving the fact that each slot is controlled by a different set
of register I wonder why the hardware can't also deduce the slot number
from the address register. For me it looks like an hardware bug but we
have to deal with it.
Do you still think we needchild node here?
>
> It is unlike the implementation which put multiple slots behind PCIe EP interface. sdhci-pci.c will handle each slot init one by one.
> If Xenon SDHC slots are represented as child nodes, there should also be a main entry in Xenon driver to init each child node one by one.
> In my very own opinion, it is inconvenient and unnecessary.
Gregory
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 5/7] add bindings for stm32 IIO timer drivers
From: Lee Jones @ 2016-11-22 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+M3ks6ZoOND4VobU65OntEYU-f_XoNCV4wNZZ0_dYoOxy73+w@mail.gmail.com>
On Tue, 22 Nov 2016, Benjamin Gaignard wrote:
> [snip]
> >> + "st,stm32-iio-timer5"
> >> + "st,stm32-iio-timer6"
> >> + "st,stm32-iio-timer7"
> >> + "st,stm32-iio-timer8"
> >> + "st,stm32-iio-timer9"
> >> + "st,stm32-iio-timer10"
> >> + "st,stm32-iio-timer11"
> >> + "st,stm32-iio-timer12"
> >> + "st,stm32-iio-timer13"
> >> + "st,stm32-iio-timer14"
> >
> > We can't do this. This is a binding for a driver, not for the hardware.
> >
>
> Unfortunately each instance for the hardware IP have little
> differences like which triggers they could accept or size of the
> counter register,
> and I doesn't have value inside the hardware to distinguish them so
> the only way I found is to use compatible.
Can't you represent these as properties?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 2/2] serial: imx: make DSR irq handling conditional
From: Christoph Fritz @ 2016-11-22 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479834851-32442-1-git-send-email-chf.fritz@googlemail.com>
This patch makes use of device-tree property disable-dsr. Disabling
DSR can be necessary on i.MX6SX to quirk buggy hardware, for more
info see commit 276b891e3879 ("ARM: dts: imx6sx: document SION
necessity of ENET1_REF_CLK1").
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
---
drivers/tty/serial/imx.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 0df2b1c..bd85a69a4 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -207,6 +207,7 @@ struct imx_port {
unsigned int dte_mode:1;
unsigned int irda_inv_rx:1;
unsigned int irda_inv_tx:1;
+ unsigned int dsr:1;
unsigned short trcv_delay; /* transceiver delay */
struct clk *clk_ipg;
struct clk *clk_per;
@@ -1219,7 +1220,8 @@ static int imx_startup(struct uart_port *port)
/*
* Finally, clear and enable interrupts
*/
- writel(USR1_RTSD | USR1_DTRD, sport->port.membase + USR1);
+ temp = USR1_RTSD | (sport->dsr ? USR1_DTRD : 0);
+ writel(temp, sport->port.membase + USR1);
writel(USR2_ORE, sport->port.membase + USR2);
if (sport->dma_is_inited && !sport->dma_is_enabled)
@@ -1259,7 +1261,7 @@ static int imx_startup(struct uart_port *port)
* now, too.
*/
temp |= IMX21_UCR3_RXDMUXSEL | UCR3_ADNIMP |
- UCR3_DTRDEN | UCR3_RI | UCR3_DCD;
+ (sport->dsr ? UCR3_DTRDEN : 0) | UCR3_RI | UCR3_DCD;
if (sport->dte_mode)
temp &= ~(UCR3_RI | UCR3_DCD);
@@ -1987,6 +1989,9 @@ static int serial_imx_probe_dt(struct imx_port *sport,
if (of_get_property(np, "fsl,dte-mode", NULL))
sport->dte_mode = 1;
+ if (!of_property_read_bool(np, "disable-dsr"))
+ sport->dsr = 1;
+
return 0;
}
#else
--
2.1.4
^ permalink raw reply related
* [PATCH 1/2] doc: DT: add generic serial property to disable DSR
From: Christoph Fritz @ 2016-11-22 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479834851-32442-1-git-send-email-chf.fritz@googlemail.com>
Introduce a generic serial property to disable DSR events which
can be necessary for buggy hardware.
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
---
Documentation/devicetree/bindings/serial/serial.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/serial.txt b/Documentation/devicetree/bindings/serial/serial.txt
index fd970f7..26e274e 100644
--- a/Documentation/devicetree/bindings/serial/serial.txt
+++ b/Documentation/devicetree/bindings/serial/serial.txt
@@ -25,6 +25,8 @@ Optional properties:
Note that this property is mutually-exclusive with "cts-gpios" and
"rts-gpios" above.
+ - disable-dsr: The presence of this property disables DSR events reporting.
+
Examples:
--
2.1.4
^ permalink raw reply related
* [PATCH 0/2] serial: introduce DSR handling property
From: Christoph Fritz @ 2016-11-22 17:14 UTC (permalink / raw)
To: linux-arm-kernel
This patchset introduces device-tree property "disable-dsr" including
documentation and usage.
Christoph Fritz (2):
doc: DT: add generic serial property to disable DSR
serial: imx: make DSR irq handling conditional
Documentation/devicetree/bindings/serial/serial.txt | 2 ++
drivers/tty/serial/imx.c | 9 +++++++--
2 files changed, 9 insertions(+), 2 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH V5 00/10] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64
From: Baicar, Tyler @ 2016-11-22 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d5e199f2-c23e-9599-7ed7-e54475311a39@huawei.com>
Thank you John! Let me know how it goes and if you have any questions :)
Tyler
On 11/22/2016 4:11 AM, John Garry wrote:
> +
>
> We'll try and test this on our platform.
>
> Cheers,
> John
>
> On 21/11/2016 22:35, Tyler Baicar wrote:
>> When a memory error, CPU error, PCIe error, or other type of hardware
>> error
>> that's covered by RAS occurs, firmware should populate the shared
>> GHES memory
>> location with the proper GHES structures to notify the OS of the error.
>> For example, platforms that implement firmware first handling may
>> implement
>> separate GHES sources for corrected errors and uncorrected errors. If
>> the
>> error is an uncorrectable error, then the firmware will notify the OS
>> immediately since the error needs to be handled ASAP. The OS will
>> then be able
>> to take the appropriate action needed such as offlining a page. If
>> the error
>> is a corrected error, then the firmware will not interrupt the OS
>> immediately.
>> Instead, the OS will see and report the error the next time it's GHES
>> timer
>> expires. The kernel will first parse the GHES structures and report
>> the errors
>> through the kernel logs and then notify the user space through RAS trace
>> events. This allows user space applications such as RAS Daemon to see
>> the
>> errors and report them however the user desires. This patchset
>> extends the
>> kernel functionality for RAS errors based on updates in the UEFI 2.6 and
>> ACPI 6.1 specifications.
>>
>> An example flow from firmware to user space could be:
>>
>> +---------------+
>> +-------->| |
>> | | GHES polling |--+
>> +-------------+ | source | | +---------------+ +------------+
>> | | +---------------+ | | Kernel GHES | | |
>> | Firmware | +-->| CPER AER and |-->| RAS
>> trace |
>> | | +---------------+ | | EDAC drivers | | event |
>> +-------------+ | | | +---------------+ +------------+
>> | | GHES sci |--+
>> +-------->| source |
>> +---------------+
>>
>> Add support for Generic Hardware Error Source (GHES) v2, which
>> introduces the
>> capability for the OS to acknowledge the consumption of the error record
>> generated by the Reliability, Availability and Serviceability (RAS)
>> controller.
>> This eliminates potential race conditions between the OS and the RAS
>> controller.
>>
>> Add support for the timestamp field added to the Generic Error Data
>> Entry v3,
>> allowing the OS to log the time that the error is generated by the
>> firmware,
>> rather than the time the error is consumed. This improves the
>> correctness of
>> event sequences when analyzing error logs. The timestamp is added in
>> ACPI 6.1, reference Table 18-343 Generic Error Data Entry.
>>
>> Add support for ARMv8 Common Platform Error Record (CPER) per UEFI 2.6
>> specification. ARMv8 specific processor error information is reported
>> as part of
>> the CPER records. This provides more detail on for processor error
>> logs. This
>> can help describe ARMv8 cache, tlb, and bus errors.
>>
>> Synchronous External Abort (SEA) represents a specific processor
>> error condition
>> in ARM systems. A handler is added to recognize SEA errors, and a
>> notifier is
>> added to parse and report the errors before the process is killed.
>> Refer to
>> section N.2.1.1 in the Common Platform Error Record appendix of the
>> UEFI 2.6
>> specification.
>>
>> Currently the kernel ignores CPER records that are unrecognized.
>> On the other hand, UEFI spec allows for non-standard (eg. vendor
>> proprietary) error section type in CPER (Common Platform Error Record),
>> as defined in section N2.3 of UEFI version 2.5. Therefore, user
>> is not able to see hardware error data of non-standard section.
>>
>> If section Type field of Generic Error Data Entry is unrecognized,
>> prints out the raw data in dmesg buffer, and also adds a tracepoint
>> for reporting such hardware errors.
>>
>> Currently even if an error status block's severity is fatal, the kernel
>> does not honor the severity level and panic. With the firmware first
>> model, the platform could inform the OS about a fatal hardware error
>> through the non-NMI GHES notification type. The OS should panic when a
>> hardware error record is received with this severity.
>>
>> Add support to handle SEAs that occur while a KVM guest kernel is
>> running. Currently these are unsupported by the guest abort handling.
>>
>> Depends on: [PATCH v14] acpi, apei, arm64: APEI initial support for
>> aarch64.
>> https://lkml.org/lkml/2016/8/10/231
>>
>> V5: Fix GHES goto logic for error conditions
>> Change ghes_do_read_ack to ghes_ack_error
>> Make sure data version check is >= 3
>> Use CPER helper functions in print functions
>> Make handle_guest_sea() dummy function static for arm
>> Add arm to subject line for KVM patch
>>
>> V4: Add bit offset left shift to read_ack_write value
>> Make HEST generic and generic_v2 structures a union in the ghes
>> structure
>> Move gdata v3 helper functions into ghes.h to avoid duplication
>> Reorder the timestamp print and avoid memcpy
>> Add helper functions for gdata size checking
>> Rename the SEA functions
>> Add helper function for GHES panics
>> Set fru_id to NULL UUID at variable declaration
>> Limit ARM trace event parameters to the needed structures
>> Reorder the ARM trace event variables to save space
>> Add comment for why we don't pass SEAs to the guest when it aborts
>> Move ARM trace event call into GHES driver instead of CPER
>>
>> V3: Fix unmapped address to the read_ack_register in ghes.c
>> Add helper function to get the proper payload based on generic
>> data entry
>> version
>> Move timestamp print to avoid changing function calls in cper.c
>> Remove patch "arm64: exception: handle instruction abort at
>> current EL"
>> since the el1_ia handler is already added in 4.8
>> Add EFI and ARM64 dependencies for HAVE_ACPI_APEI_SEA
>> Add a new trace event for ARM type errors
>> Add support to handle KVM guest SEAs
>>
>> V2: Add PSCI state print for the ARMv8 error type.
>> Separate timestamp year into year and century using BCD format.
>> Rebase on top of ACPICA 20160318 release and remove header file
>> changes
>> in include/acpi/actbl1.h.
>> Add panic OS with fatal error status block patch.
>> Add processing of unrecognized CPER error section patches with
>> updates
>> from previous comments. Original patches:
>> https://lkml.org/lkml/2015/9/8/646
>>
>> V1: https://lkml.org/lkml/2016/2/5/544
>>
>> Jonathan (Zhixiong) Zhang (1):
>> acpi: apei: panic OS with fatal error status block
>>
>> Tyler Baicar (9):
>> acpi: apei: read ack upon ghes record consumption
>> ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1
>> efi: parse ARMv8 processor error
>> arm64: exception: handle Synchronous External Abort
>> acpi: apei: handle SEA notification type for ARMv8
>> efi: print unrecognized CPER section
>> ras: acpi / apei: generate trace event for unrecognized CPER section
>> trace, ras: add ARM processor error trace event
>> arm/arm64: KVM: add guest SEA support
>>
>> arch/arm/include/asm/kvm_arm.h | 1 +
>> arch/arm/include/asm/system_misc.h | 5 +
>> arch/arm/kvm/mmu.c | 18 ++-
>> arch/arm64/Kconfig | 1 +
>> arch/arm64/include/asm/kvm_arm.h | 1 +
>> arch/arm64/include/asm/system_misc.h | 15 +++
>> arch/arm64/mm/fault.c | 71 ++++++++++--
>> drivers/acpi/apei/Kconfig | 14 +++
>> drivers/acpi/apei/ghes.c | 188
>> ++++++++++++++++++++++++++++---
>> drivers/acpi/apei/hest.c | 7 +-
>> drivers/firmware/efi/cper.c | 210
>> ++++++++++++++++++++++++++++++++---
>> drivers/ras/ras.c | 2 +
>> include/acpi/ghes.h | 15 ++-
>> include/linux/cper.h | 84 ++++++++++++++
>> include/ras/ras_event.h | 100 +++++++++++++++++
>> 15 files changed, 688 insertions(+), 44 deletions(-)
>>
>
>
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ 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