* [PATCH v2 5/6] ARM: davinci: da8xx: add pdata-quirks, use for VPIF capture
From: Kevin Hilman @ 2017-01-09 20:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109205531.3435-1-khilman@baylibre.com>
For da8xx DT platforms, use pdata-quirks to add legacy platform data for
vpif_capture driver.
Passing legacy platform_data is required until the V4L2 framework, and
subdevice drivers (such as the tvp514x) grow a way of selecting input
and output routing (c.f. V4L2 s_routing API)
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
arch/arm/mach-davinci/Makefile | 2 +-
arch/arm/mach-davinci/da8xx-dt.c | 2 +
arch/arm/mach-davinci/pdata-quirks.c | 115 +++++++++++++++++++++++++++++++++++
3 files changed, 118 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index 0a2e6da45f28..df96ca9eab6d 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -21,7 +21,7 @@ obj-$(CONFIG_AINTC) += irq.o
obj-$(CONFIG_CP_INTC) += cp_intc.o
# Board specific
-obj-$(CONFIG_MACH_DA8XX_DT) += da8xx-dt.o
+obj-$(CONFIG_MACH_DA8XX_DT) += da8xx-dt.o pdata-quirks.o
obj-$(CONFIG_MACH_DAVINCI_EVM) += board-dm644x-evm.o
obj-$(CONFIG_MACH_SFFSDR) += board-sffsdr.o
obj-$(CONFIG_MACH_NEUROS_OSD2) += board-neuros-osd2.o
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 9ee44da6eb7b..fe4a9e30d937 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -42,6 +42,7 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("ti,da830-ohci", 0x01e25000, "ohci-da8xx", NULL),
OF_DEV_AUXDATA("ti,da830-musb", 0x01e00000, "musb-da8xx", NULL),
OF_DEV_AUXDATA("ti,da830-usb-phy", 0x01c1417c, "da8xx-usb-phy", NULL),
+ OF_DEV_AUXDATA("ti,da850-vpif", 0x01e17000, "vpif", NULL),
{}
};
@@ -62,6 +63,7 @@ static void __init da850_init_machine(void)
of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
davinci_pm_init();
+ pdata_quirks_init();
}
static const char *const da850_boards_compat[] __initconst = {
diff --git a/arch/arm/mach-davinci/pdata-quirks.c b/arch/arm/mach-davinci/pdata-quirks.c
index 5b57da475065..142a2684c445 100644
--- a/arch/arm/mach-davinci/pdata-quirks.c
+++ b/arch/arm/mach-davinci/pdata-quirks.c
@@ -10,13 +10,122 @@
#include <linux/kernel.h>
#include <linux/of_platform.h>
+#include <media/i2c/tvp514x.h>
+
#include <mach/common.h>
+#include <mach/da8xx.h>
struct pdata_init {
const char *compatible;
void (*fn)(void);
};
+#if IS_ENABLED(CONFIG_VIDEO_DAVINCI_VPIF_CAPTURE)
+
+#define TVP5147_CH0 "tvp514x-0"
+#define TVP5147_CH1 "tvp514x-1"
+
+/* VPIF capture configuration */
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity = 1,
+ .vs_polarity = 1,
+};
+
+#define TVP514X_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL)
+
+static const struct vpif_input da850_ch0_inputs[] = {
+ {
+ .input = {
+ .index = 0,
+ .name = "Composite",
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .capabilities = V4L2_IN_CAP_STD,
+ .std = TVP514X_STD_ALL,
+ },
+ .input_route = INPUT_CVBS_VI2B,
+ .output_route = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ .subdev_name = TVP5147_CH0,
+ },
+};
+
+static const struct vpif_input da850_ch1_inputs[] = {
+ {
+ .input = {
+ .index = 0,
+ .name = "S-Video",
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .capabilities = V4L2_IN_CAP_STD,
+ .std = TVP514X_STD_ALL,
+ },
+ .input_route = INPUT_SVIDEO_VI2C_VI1C,
+ .output_route = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ .subdev_name = TVP5147_CH1,
+ },
+};
+
+static struct vpif_subdev_info da850_vpif_capture_sdev_info[] = {
+ {
+ .name = TVP5147_CH0,
+ .board_info = {
+ I2C_BOARD_INFO("tvp5146", 0x5d),
+ .platform_data = &tvp5146_pdata,
+ },
+ },
+ {
+ .name = TVP5147_CH1,
+ .board_info = {
+ I2C_BOARD_INFO("tvp5146", 0x5c),
+ .platform_data = &tvp5146_pdata,
+ },
+ },
+};
+
+static struct vpif_capture_config da850_vpif_capture_config = {
+ .subdev_info = da850_vpif_capture_sdev_info,
+ .subdev_count = ARRAY_SIZE(da850_vpif_capture_sdev_info),
+ .chan_config[0] = {
+ .inputs = da850_ch0_inputs,
+ .input_count = ARRAY_SIZE(da850_ch0_inputs),
+ .vpif_if = {
+ .if_type = VPIF_IF_BT656,
+ .hd_pol = 1,
+ .vd_pol = 1,
+ .fid_pol = 0,
+ },
+ },
+ .chan_config[1] = {
+ .inputs = da850_ch1_inputs,
+ .input_count = ARRAY_SIZE(da850_ch1_inputs),
+ .vpif_if = {
+ .if_type = VPIF_IF_BT656,
+ .hd_pol = 1,
+ .vd_pol = 1,
+ .fid_pol = 0,
+ },
+ },
+ .card_name = "DA850/OMAP-L138 Video Capture",
+};
+
+static void __init da850_vpif_legacy_init(void)
+{
+ int ret;
+
+ /* LCDK doesn't have the 2nd TVP514x on CH1 */
+ if (of_machine_is_compatible("ti,da850-lcdk"))
+ da850_vpif_capture_config.subdev_count = 1;
+
+ /* EVM (UI card) uses i2c adapter 1 (not default: zero) */
+ if (of_machine_is_compatible("ti,da850-evm"))
+ da850_vpif_capture_config.i2c_adapter_id = 1;
+
+ ret = da850_register_vpif_capture(&da850_vpif_capture_config);
+ if (ret)
+ pr_warn("%s: VPIF capture setup failed: %d\n",
+ __func__, ret);
+}
+#endif
+
static void pdata_quirks_check(struct pdata_init *quirks)
{
while (quirks->compatible) {
@@ -30,6 +139,12 @@ static void pdata_quirks_check(struct pdata_init *quirks)
}
static struct pdata_init pdata_quirks[] __initdata = {
+#if IS_ENABLED(CONFIG_VIDEO_DAVINCI_VPIF_CAPTURE)
+ { "ti,da850-lcdk", da850_vpif_legacy_init, },
+#if defined(CONFIG_DA850_UI_SD_VIDEO_PORT)
+ { "ti,da850-evm", da850_vpif_legacy_init, },
+#endif
+#endif
{ /* sentinel */ },
};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 4/6] ARM: davinci: add skeleton for pdata-quirks
From: Kevin Hilman @ 2017-01-09 20:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109205531.3435-1-khilman@baylibre.com>
Add skeleton pdata-quirks for for davinci.
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
arch/arm/mach-davinci/include/mach/common.h | 2 ++
arch/arm/mach-davinci/pdata-quirks.c | 39 +++++++++++++++++++++++++++++
2 files changed, 41 insertions(+)
create mode 100644 arch/arm/mach-davinci/pdata-quirks.c
diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index 0b3c169758ed..037aa66bcac1 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -102,6 +102,8 @@ int davinci_pm_init(void);
static inline int davinci_pm_init(void) { return 0; }
#endif
+void __init pdata_quirks_init(void);
+
#define SRAM_SIZE SZ_128K
#endif /* __ARCH_ARM_MACH_DAVINCI_COMMON_H */
diff --git a/arch/arm/mach-davinci/pdata-quirks.c b/arch/arm/mach-davinci/pdata-quirks.c
new file mode 100644
index 000000000000..5b57da475065
--- /dev/null
+++ b/arch/arm/mach-davinci/pdata-quirks.c
@@ -0,0 +1,39 @@
+/*
+ * Legacy platform_data quirks
+ *
+ * Copyright (C) 2016 BayLibre, Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <linux/kernel.h>
+#include <linux/of_platform.h>
+
+#include <mach/common.h>
+
+struct pdata_init {
+ const char *compatible;
+ void (*fn)(void);
+};
+
+static void pdata_quirks_check(struct pdata_init *quirks)
+{
+ while (quirks->compatible) {
+ if (of_machine_is_compatible(quirks->compatible)) {
+ if (quirks->fn)
+ quirks->fn();
+ break;
+ }
+ quirks++;
+ }
+}
+
+static struct pdata_init pdata_quirks[] __initdata = {
+ { /* sentinel */ },
+};
+
+void __init pdata_quirks_init(void)
+{
+ pdata_quirks_check(pdata_quirks);
+}
--
2.9.3
^ permalink raw reply related
* [PATCH v2 3/6] ARM: dts: davinci: da850-lcdk: enable VPIF
From: Kevin Hilman @ 2017-01-09 20:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109205531.3435-1-khilman@baylibre.com>
Enable VPIF for video captpure and configure input channel 0, used for
composite input.
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
arch/arm/boot/dts/da850-lcdk.dts | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index afcb4821deb1..9b1f3695607c 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -236,3 +236,16 @@
&memctrl {
status = "okay";
};
+
+&vpif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&vpif_capture_pins>;
+ status = "okay";
+
+ /* VPIF capture port */
+ port {
+ vpif_ch0: endpoint {
+ bus-width = <8>;
+ };
+ };
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 2/6] ARM: dts: davinci: da850-evm: enable VPIF
From: Kevin Hilman @ 2017-01-09 20:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109205531.3435-1-khilman@baylibre.com>
Enable VPIF node for video capture, and configure ports. EVM board
uses channel 0 for composite input and channel 1 S-Video input.
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
arch/arm/boot/dts/da850-evm.dts | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 41de15fe15a2..cea36ee6fd07 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -289,3 +289,23 @@
};
};
};
+
+&vpif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&vpif_capture_pins>;
+ status = "okay";
+
+ /* VPIF capture port */
+ port {
+ vpif_ch0: endpoint at 0 {
+ reg = <0>;
+ bus-width = <8>;
+ };
+
+ vpif_ch1: endpoint at 1 {
+ reg = <1>;
+ bus-width = <8>;
+ data-shift = <8>;
+ };
+ };
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 1/6] ARM: dts: davinci: da850: VPIF: add node and muxing
From: Kevin Hilman @ 2017-01-09 20:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109205531.3435-1-khilman@baylibre.com>
Add VPIF node an pins to da850 SoC. VPIF has two input channels which
can be described using the standard DT ports and enpoints.
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
arch/arm/boot/dts/da850.dtsi | 26 +++++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 104155d12c2f..edab8bb92ec5 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -208,7 +208,18 @@
0x4c 0x02000022 0x0f0000ff
>;
};
-
+ vpif_capture_pins: vpif_capture_pins {
+ pinctrl-single,bits = <
+ /* VP_DIN[2..7], VP_CLKIN1, VP_CLKIN0 */
+ 0x38 0x11111111 0xffffffff
+ /* VP_DIN[10..15,0..1] */
+ 0x3c 0x11111111 0xffffffff
+ /* VP_DIN[8..9] */
+ 0x40 0x00000011 0x000000ff
+ /* VP_CLKIN3, VP_CLKIN2 */
+ 0x4c 0x00010100 0x000f0f00
+ >;
+ };
};
prictrl: priority-controller at 14110 {
compatible = "ti,da850-mstpri";
@@ -324,6 +335,18 @@
dma-names = "rx", "tx";
status = "disabled";
};
+ vpif: video at 217000 {
+ compatible = "ti,da850-vpif";
+ reg = <0x217000 0x1000>;
+ interrupts = <92>;
+ status = "disabled";
+
+ /* VPIF capture port */
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
mmc1: mmc at 21b000 {
compatible = "ti,da830-mmc";
reg = <0x21b000 0x1000>;
@@ -465,6 +488,7 @@
status = "disabled";
};
};
+
aemif: aemif at 68000000 {
compatible = "ti,da850-aemif";
#address-cells = <2>;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 0/6] ARM: davinci: da850: add/enable video capture
From: Kevin Hilman @ 2017-01-09 20:55 UTC (permalink / raw)
To: linux-arm-kernel
Add support for VPIF video capture using DT (partially.)
The main VPIF device, and its pin muxing are using DT, but legacy
platform_data is still required for the vpif_capture driver. Passing
legacy platform_data is required until the V4L2 framework, and
subdevice drivers (such as the tvp514x) grow a way of selecting input
and output routing (c.f. V4L2 s_routing API)
Dependencies:
- VPIF driver changes:
[PATCH v6 0/5] davinci: VPIF: add DT support
https://marc.info/?l=linux-arm-kernel&m=148113556200610
Changes since v1:
- split DT patches into separate SoC and board patches
- split pdata-quirks into base/skeleton driver and da8xx
Kevin Hilman (6):
ARM: dts: davinci: da850: VPIF: add node and muxing
ARM: dts: davinci: da850-evm: enable VPIF
ARM: dts: davinci: da850-lcdk: enable VPIF
ARM: davinci: add skeleton for pdata-quirks
ARM: davinci: da8xx: add pdata-quirks, use for VPIF capture
ARM: davinci: board-da850-evm: add I2C ID for VPIF
arch/arm/boot/dts/da850-evm.dts | 20 ++++
arch/arm/boot/dts/da850-lcdk.dts | 13 +++
arch/arm/boot/dts/da850.dtsi | 26 ++++-
arch/arm/mach-davinci/Makefile | 2 +-
arch/arm/mach-davinci/board-da850-evm.c | 1 +
arch/arm/mach-davinci/da8xx-dt.c | 2 +
arch/arm/mach-davinci/include/mach/common.h | 2 +
arch/arm/mach-davinci/pdata-quirks.c | 154 ++++++++++++++++++++++++++++
8 files changed, 218 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mach-davinci/pdata-quirks.c
--
2.9.3
^ permalink raw reply
* [RESEND] spi: davinci: Allow device tree devices to use DMA
From: David Lechner @ 2017-01-09 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109194811.p3if5pzvjjaez2g3@sirena.org.uk>
On 01/09/2017 01:48 PM, Mark Brown wrote:
> On Thu, Jan 05, 2017 at 09:26:17PM -0600, David Lechner wrote:
>
>> This allows SPI devices specified in a device tree to use DMA when the
>> master controller.
>
>> Since device tree is supposed to only describe the hardware, adding such
>> a configuration option to device tree would not be acceptable. So, this
>> is the best we can do for now to get SPI devices working with DMA.
>
>> Unfortunately, this excludes the possibility of using one SPI device with
>> DMA and one without on the same master.
>
> Why would you ever want to do that? What would ever make sense about
> not using DMA if it's available and the transfer is suitably large, or
> conversely why would one want to force DMA even if PIO would be more
> performant?
I don't particularly want to do that, but that is the way the
spi-davinci driver currently works. The choice between DMA or PIO is
specified in the platform data on a per-device basis.
What I get from your remarks is that this is wrong and it needs to be
fixed. If that is so, could someone please point out a driver that does
it the right way and I will try to fix it.
>
>> When I originally submitted this patch, there was some discussion as to whether
>> dspi->dma_rx should be changed to return an error rather than being null.
>
>> However, I prefer it the way it is and don't see a compelling reason to change
>> it.
>
> I don't know what the above comment means, sorry (and don't recall
> having seen any earlier versions of this).
>
FWIW, you can find the previous conversation at
https://patchwork.kernel.org/patch/9437901/
^ permalink raw reply
* [PATCH 04/10] arm: migrate exception table users off module.h and onto extable.h
From: Paul Gortmaker @ 2017-01-09 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109204010.5047-1-paul.gortmaker@windriver.com>
These files were only including module.h for exception table
related functions. We've now separated that content out into its
own file "extable.h" so now move over to that and avoid all the
extra header content in module.h that we don't really need to compile
these files.
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/arm/mm/extable.c | 2 +-
arch/arm/mm/fault.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/extable.c b/arch/arm/mm/extable.c
index 312e15e6d00b..f436f7439e46 100644
--- a/arch/arm/mm/extable.c
+++ b/arch/arm/mm/extable.c
@@ -1,7 +1,7 @@
/*
* linux/arch/arm/mm/extable.c
*/
-#include <linux/module.h>
+#include <linux/extable.h>
#include <linux/uaccess.h>
int fixup_exception(struct pt_regs *regs)
diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index 3a2e678b8d30..94de590db99e 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -8,7 +8,7 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
-#include <linux/module.h>
+#include <linux/extable.h>
#include <linux/signal.h>
#include <linux/mm.h>
#include <linux/hardirq.h>
--
2.11.0
^ permalink raw reply related
* [PATCH v2 00/10] Finalize separation of extable.h from module.h
From: Paul Gortmaker @ 2017-01-09 20:40 UTC (permalink / raw)
To: linux-arm-kernel
Some of the arch specific changes have already been picked up by the
arch maintainers in v1, so I'm assuming the other folks just figured I'd
ask Linus to pull the remainder. Which is the current plan ; soak this
in linux-next on 4.10-rc3 and request a pull in the next merge window.
So please shout if you are an arch maintainer and see something here you
have questions or comments on. Otherwise, you don't have to do anything.
Once all the old users who expected extable content via module.h are
gone, then and only then can we remove the back compat line as done in
the final patch in this series.
I've been build testing this locally on a regular basis in with my other
pending work, on a bunch of different architectures, so hopefully we
don't see anything go pear shaped when it goes into sfr's linux-next.
The only real change in the v1 ---> v2 aside from dropping merged
content was the restructuring in the ia64 based on comments from Al
Viro to improve some header separation at the same time. I'd resent
just those two for follow up comments and nobody seemed to have further
suggestions. Note that I'm not able to run test ia64; just compile.
There was also a minor context refresh required due to the recent
treewide asm/uaccess --> linux/uaccess change, which gave me the
motivation to get this out of my queue and finalized.
RFC/V1: https://lkml.kernel.org/r/CA+55aFyDw_jK609LcjpWvVMTzCWuH6nLUXiZDeYC2tpSaZqhXA at mail.gmail.com
ia64: https://lkml.kernel.org/r/20160920022924.9537-1-paul.gortmaker at windriver.com
---
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Chris Zankel <chris@zankel.net>
Cc: David Howells <dhowells@redhat.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-alpha at vger.kernel.org
Cc: linux-am33-list at redhat.com
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-ia64 at vger.kernel.org
Cc: linux-sh at vger.kernel.org
Cc: linux-xtensa at linux-xtensa.org
Cc: Matt Turner <mattst88@gmail.com>
Cc: Max Filippov <jcmvbkbc@gmail.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Rich Felker <dalias@libc.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Paul Gortmaker (10):
ia64: move ia64_done_with_exception out of asm/uaccess.h
ia64: ensure exception table search users include extable.h
m32r: migrate exception table users off module.h and onto extable.h
arm: migrate exception table users off module.h and onto extable.h
alpha: migrate exception table users off module.h and onto extable.h
mn10300: migrate exception table users off module.h and onto extable.h
xtensa: migrate exception table users off module.h and onto extable.h
sh: migrate exception table users off module.h and onto extable.h
core: migrate exception table users off module.h and onto extable.h
module.h: remove extable.h include now users have migrated
arch/alpha/kernel/traps.c | 2 +-
arch/alpha/mm/fault.c | 2 +-
arch/arm/mm/extable.c | 2 +-
arch/arm/mm/fault.c | 2 +-
arch/ia64/include/asm/exception.h | 35 +++++++++++++++++++++++++++++++++++
arch/ia64/include/asm/uaccess.h | 15 ---------------
arch/ia64/kernel/kprobes.c | 4 ++--
arch/ia64/kernel/traps.c | 6 ++++--
arch/ia64/kernel/unaligned.c | 4 +++-
arch/ia64/mm/fault.c | 2 ++
arch/m32r/mm/extable.c | 2 +-
arch/m32r/mm/fault.c | 2 +-
arch/mn10300/mm/extable.c | 2 +-
arch/mn10300/mm/misalignment.c | 2 +-
arch/sh/include/asm/uaccess.h | 1 -
arch/sh/kernel/kprobes.c | 2 +-
arch/sh/kernel/traps.c | 3 ++-
arch/sh/mm/extable_32.c | 2 +-
arch/sh/mm/extable_64.c | 2 +-
arch/xtensa/mm/fault.c | 2 +-
include/linux/module.h | 1 -
init/main.c | 1 +
kernel/extable.c | 1 +
kernel/module.c | 1 +
24 files changed, 63 insertions(+), 35 deletions(-)
create mode 100644 arch/ia64/include/asm/exception.h
--
2.11.0
^ permalink raw reply
* [PATCH v3] ARM: dts: sun7i: Add wifi dt node on Banana Pro
From: Jörg Krause @ 2017-01-09 20:36 UTC (permalink / raw)
To: linux-arm-kernel
The Banana Pro has an AMPAK AP6181 WiFi+Bluetooth module. The WiFi part
is a BCM43362 IC connected to MMC3 of the A20 SoC via SDIO. The IC also
takes a power enable signal via GPIO.
This commit adds a device-tree node to power it up, so the mmc subsys
can scan it, and enables the mmc controller which is connected to it.
As the wifi enable pin of the AP6181 module is not really a regulator,
switch the mmc3 node to the mmc-pwrseq framework for controlling it.
This more accurately reflectes how the hardware actually works.
Signed-off-by: J?rg Krause <joerg.krause@embedded.rocks>
---
Changes v3 suggested by Maxime Ripard):
- do not set the wakeup-source property for the mmc3 node as it is
suspicious and propably does not work
Changes v2 (suggested by Maxime Ripard):
- rename pwrseq node to clarify the function rather what it's
connected to
- use dash instead of underscore for the pwrseq node name
- remove setting pull-ups for mmc3 (default since commit 37bc56128d92)
---
arch/arm/boot/dts/sun7i-a20-bananapro.dts | 29 +++++++++++++++++------------
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapro.dts b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
index f1a33560710f..c17e6407fee0 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapro.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
@@ -76,6 +76,13 @@
};
};
+ wifi_pwrseq: wifi-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ pinctrl-names = "default";
+ pinctrl-0 = <&vmmc3_pin_bananapro>;
+ reset-gpios = <&pio 7 22 GPIO_ACTIVE_LOW>;
+ };
+
reg_gmac_3v3: gmac-3v3 {
compatible = "regulator-fixed";
pinctrl-names = "default";
@@ -87,17 +94,6 @@
enable-active-high;
gpio = <&pio 7 23 GPIO_ACTIVE_HIGH>;
};
-
- reg_vmmc3: vmmc3 {
- compatible = "regulator-fixed";
- pinctrl-names = "default";
- pinctrl-0 = <&vmmc3_pin_bananapro>;
- regulator-name = "vmmc3";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- enable-active-high;
- gpio = <&pio 7 22 GPIO_ACTIVE_HIGH>;
- };
};
&ahci {
@@ -170,10 +166,19 @@
&mmc3 {
pinctrl-names = "default";
pinctrl-0 = <&mmc3_pins_a>;
- vmmc-supply = <®_vmmc3>;
+ vmmc-supply = <®_vcc3v3>;
+ mmc-pwrseq = <&wifi_pwrseq>;
bus-width = <4>;
non-removable;
status = "okay";
+
+ brcmf: bcrmf at 1 {
+ reg = <1>;
+ compatible = "brcm,bcm4329-fmac";
+ interrupt-parent = <&pio>;
+ interrupts = <7 15 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "host-wake";
+ };
};
&ohci0 {
--
2.11.0
^ permalink raw reply related
* [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask
From: Nikita Yushchenko @ 2017-01-09 20:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6374144.HVL0QxNJiT@wuerfel>
[CCing NVMe maintainers since we are discussion issues in that driver]
>> With my patch applied and thus 32bit dma_mask set for NVMe device, I do
>> see high addresses passed to dma_map_*() routines and handled by
>> swiotlb. Thus your statement that behavior "succeed 64bit dma_set_mask()
>> operation but silently replace mask behind the scene" is required for
>> swiotlb to be used, does not match reality.
>
> See my point about drivers that don't implement bounce buffering.
> Apparently NVMe is one of them, unlike the SATA/SCSI/MMC storage
> drivers that do their own thing.
I believe the bounce buffering code you refer to is not in SATA/SCSI/MMC
but in block layer, in particular it should be controlled by
blk_queue_bounce_limit(). [Yes there is CONFIG_MMC_BLOCK_BOUNCE but it
is something completely different, namely it is for request merging for
hw not supporting scatter-gather]. And NVMe also uses block layer and
thus should get same support.
But blk_queue_bounce_limit() is somewhat broken, it has very strange
code under #if BITS_PER_LONG == 64 that makes setting max_addr to
0xffffffff not working if max_low_pfn is above 4G.
Maybe fixing that, together with making NVMe use this API, could stop it
from issuing dma_map()s of addresses beyond mask.
> What I think happened here in chronological order is:
>
> - In the old days, 64-bit architectures tended to use an IOMMU
> all the time to work around 32-bit limitations on DMA masters
> - Some architectures had no IOMMU that fully solved this and the
> dma-mapping API required drivers to set the right mask and check
> the return code. If this failed, the driver needed to use its
> own bounce buffers as network and scsi do. See also the
> grossly misnamed "PCI_DMA_BUS_IS_PHYS" macro.
> - As we never had support for bounce buffers in all drivers, and
> early 64-bit Intel machines had no IOMMU, the swiotlb code was
> introduced as a workaround, so we can use the IOMMU case without
> driver specific bounce buffers everywhere
> - As most of the important 64-bit architectures (x86, arm64, powerpc)
> now always have either IOMMU or swiotlb enabled, drivers like
> NVMe started relying on it, and no longer handle a dma_set_mask
> failure properly.
... and architectures started to add to this breakage, not handling
dma_set_mask() as documented.
As for PCI_DMA_BUS_IS_PHYS - ironically, what all current usages of this
macro in the kernel do is - *disable* bounce buffers in block layer if
PCI_DMA_BUS_IS_PHYS is zero. Defining it to zero (as arm64 currently
does) on system with memory above 4G makes all block drivers to depend
on swiotlb (or iommu). Affected drivers are SCSI and IDE.
> We may need to audit how drivers typically handle dma_set_mask()
> failure. The NVMe driver in its current state will probably cause
> silent data corruption when used on a 64-bit architecture that has
> a 32-bit bus but neither swiotlb nor iommu enabled at runtime.
With current code NVME causes system memory breakage even if swiotlb is
there - because it's dma_set_mask_and_coherent(DMA_BIT_MASK(64)) call
has effect of silent disable of swiotlb.
> I would argue that the driver should be fixed to either refuse
> working in that configuration to avoid data corruption, or that
> it should implement bounce buffering like SCSI does.
Difference from "SCSI" (actually - from block drivers that work) is in
that dma_set_mask_and_coherent(DMA_BIT_MASK(64)) call: driver that does
not do it works, driver that does it fails.
Per documentation, driver *should* do it if it's hardware supports
64-bit dma, and platform *should* either fail this call, or ensure that
64-bit addresses can be dma_map()ed successfully.
So what we have on arm64 is - drivers that follow documented procedure
fail, drivers that don't follow it work, That's nonsense.
> If we make it
> simply not work, then your suggestion of making dma_set_mask()
> fail will break your system in a different way.
Proper fix should fix *both* architecture and NVMe.
- architecture should stop breaking 64-bit DMA when driver attempts to
set 64-bit dma mask,
- NVMe should issue proper blk_queue_bounce_limit() call based on what
is actually set mask,
- and blk_queue_bounce_limit() should also be fixed to actually set
0xffffffff limit, instead of replacing it with (max_low_pfn <<
PAGE_SHIFT) as it does now.
>> Still current code does not work, thus fix is needed.
>>
>> Perhaps need to introduce some generic API to "allocate memory best
>> suited for DMA to particular device", and fix allocation points (in
>> drivers, filesystems, etc) to use it. Such an API could try to allocate
>> area that can be DMAed by hardware, and fallback to other memory that
>> can be used via swiotlb or other bounce buffer implementation.
>
> The DMA mapping API is meant to do this, but we can definitely improve
> it or clarify some of the rules.
DMA mapping API can't help here, it's about mapping, not about allocation.
What I mean is some API to allocate memory for use with streaming DMA in
such way that bounce buffers won't be needed. There are many cases when
at buffer allocation time, it is already known that buffer will be used
for DMA with particular device. Bounce buffers will still be needed
cases when no such information is available at allocation time, or when
there is no directly-DMAable memory available at allocation time.
>> But for now, have to stay with dma masks. Will follow-up with a patch
>> based on your but with coherent mask handling added.
>
> Ok.
Already posted. Can we have that merged? At least it will make things to
stop breaking memory and start working.
Nikita
^ permalink raw reply
* [PATCH 1/4] watchdog: coh901327_wdt: Simplify error handling in probe function
From: Guenter Roeck @ 2017-01-09 20:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbb9O=zRNox9RO9bNkAJ0grZ7vHy+8=9udJj0_Gw+k5hA@mail.gmail.com>
On Mon, Jan 09, 2017 at 08:38:03PM +0100, Linus Walleij wrote:
> On Wed, Jan 4, 2017 at 4:25 AM, Guenter Roeck <linux@roeck-us.net> wrote:
>
> > Checking if there is no error followed by a goto if there is one is
> > confusing. Reverse the logic.
> >
> > Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>
Thanks!
Guenter
^ permalink raw reply
* [PATCH 0/5] Reset Controller Nodes for TI Keystone platforms
From: Santosh Shilimkar @ 2017-01-09 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109194358.27271-1-s-anna@ti.com>
On 1/9/2017 11:43 AM, Suman Anna wrote:
> Hi Santosh,
>
> This patch adds the reset controller nodes and the corresponding
> reset data for TI Keystone 66AK2H, 66AK2L and 66AK2E SoCs. These
> resets are for the DSPs on these SoCs, and are the last dependencies
> before the keystone remoteproc driver can be added.
>
> All these SoCs will use the ti-syscon-reset driver which is already
> part of mainline kernel. The bindings for the same can be found in
> Documentation/devicetree/bindings/reset/ti-syscon-reset.txt file.
> Note that the other Keystone 66AK2G SoC will use a different TI-SCI
> based reset driver, so will be submitted separately once the TI-SCI
> dependencies make it into mainline.
>
> Patches are based on top of 4.10-rc1 plus the MSM-RAM DT node series
> that you have already picked up. Patch 1 enable the Reset Framework
> for Keystone platforms, and remaining patches add the required DT
> nodes.
>
Ok. I will let this series be on list for a week or so for any
comments. After that will pick this up and push it out to next.
Regards,
Santosh
^ permalink raw reply
* [PATCH 0/3] watchdog: imx2: handle WMCR only being available on i.MX35 and later
From: Uwe Kleine-König @ 2017-01-09 20:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109171959.GA7274@roeck-us.net>
On Mon, Jan 09, 2017 at 09:19:59AM -0800, Guenter Roeck wrote:
> On Mon, Jan 09, 2017 at 10:50:36AM +0100, Uwe Kleine-K?nig wrote:
> > this is my approach to fix the issue reported by Vladimir Zapolskiy.
> >
> So ...
>
> Unfortunately, I don't see any convergence on this issue. My take is that,
> given the lack of convergence, it can't be that severe since no one feels
> that it is important enough to get it fixed one way or the other to budge
> from your positions.
I didn't get any critic for my patch set yet apart from being a second
one to address the same problem. So until proven differently I assume
that mine is fine.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Applied "ASoC: sun4i-codec: Add "Right Mixer" to "Line Out Mono Diff." route" to the asoc tree
From: Mark Brown @ 2017-01-09 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107100703.5586-4-wens@csie.org>
The patch
ASoC: sun4i-codec: Add "Right Mixer" to "Line Out Mono Diff." route
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 19426bdedb72b965db0ebf2106e95e9eeb3b5935 Mon Sep 17 00:00:00 2001
From: Chen-Yu Tsai <wens@csie.org>
Date: Sun, 8 Jan 2017 02:57:06 +0800
Subject: [PATCH] ASoC: sun4i-codec: Add "Right Mixer" to "Line Out Mono Diff."
route
The mono differential output for "Line Out" downmixes the stereo audio
from the mixer, instead of just taking the left channel.
Add a route from the "Right Mixer" to "Line Out Source Playback Route"
through the "Mono Differential" path, so DAPM doesn't shut down
everything if the left channel is muted.
Fixes: 0f909f98d7cb ("ASoC: sun4i-codec: Add support for A31 Line Out
playback")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/sunxi/sun4i-codec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 848af01692a0..c3aab10fa085 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -1058,6 +1058,7 @@ static const struct snd_soc_dapm_route sun6i_codec_codec_dapm_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" },
/* ADC Routes */
--
2.11.0
^ permalink raw reply related
* [RFC PATCH 2/2] crypto: arm/aes - add CCM driver using ARMv8 Crypto Extensions
From: Ard Biesheuvel @ 2017-01-09 19:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483991849-32448-1-git-send-email-ard.biesheuvel@linaro.org>
This is a straight port of the arm64 driver that implements AES
in CCM mode using the ARMv8 Crypto Extensions instructions. It
is ~13x faster than the generic CCM code using scalar AES.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/crypto/Kconfig | 8 +
arch/arm/crypto/Makefile | 2 +
arch/arm/crypto/aes-ce-ccm-core.S | 234 +++++++++++++
arch/arm/crypto/aes-ce-ccm-glue.c | 360 ++++++++++++++++++++
4 files changed, 604 insertions(+)
diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig
index f1de658c3c8f..f933cae8d76b 100644
--- a/arch/arm/crypto/Kconfig
+++ b/arch/arm/crypto/Kconfig
@@ -92,6 +92,14 @@ config CRYPTO_AES_ARM_CE
Use an implementation of AES in CBC, CTR and XTS modes that uses
ARMv8 Crypto Extensions
+config CRYPTO_AES_ARM_CE_CCM
+ tristate "AES in CCM mode using ARMv8 Crypto Extensions"
+ depends on KERNEL_MODE_NEON && m
+ select CRYPTO_ALGAPI
+ select CRYPTO_AES
+ select CRYPTO_AEAD
+ select CRYPTO_CCM
+
config CRYPTO_GHASH_ARM_CE
tristate "PMULL-accelerated GHASH using ARMv8 Crypto Extensions"
depends on KERNEL_MODE_NEON
diff --git a/arch/arm/crypto/Makefile b/arch/arm/crypto/Makefile
index 6eda6ffafea9..1b4f3a5f918c 100644
--- a/arch/arm/crypto/Makefile
+++ b/arch/arm/crypto/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_CRYPTO_SHA512_ARM) += sha512-arm.o
obj-$(CONFIG_CRYPTO_CHACHA20_NEON) += chacha20-neon.o
ce-obj-$(CONFIG_CRYPTO_AES_ARM_CE) += aes-arm-ce.o
+ce-obj-$(CONFIG_CRYPTO_AES_ARM_CE_CCM) += aes-ce-ccm.o
ce-obj-$(CONFIG_CRYPTO_SHA1_ARM_CE) += sha1-arm-ce.o
ce-obj-$(CONFIG_CRYPTO_SHA2_ARM_CE) += sha2-arm-ce.o
ce-obj-$(CONFIG_CRYPTO_GHASH_ARM_CE) += ghash-arm-ce.o
@@ -38,6 +39,7 @@ sha512-arm-y := sha512-core.o sha512-glue.o $(sha512-arm-neon-y)
sha1-arm-ce-y := sha1-ce-core.o sha1-ce-glue.o
sha2-arm-ce-y := sha2-ce-core.o sha2-ce-glue.o
aes-arm-ce-y := aes-ce-core.o aes-ce-glue.o
+aes-ce-ccm-y := aes-ce-ccm-core.o aes-ce-ccm-glue.o
ghash-arm-ce-y := ghash-ce-core.o ghash-ce-glue.o
crct10dif-arm-ce-y := crct10dif-ce-core.o crct10dif-ce-glue.o
crc32-arm-ce-y:= crc32-ce-core.o crc32-ce-glue.o
diff --git a/arch/arm/crypto/aes-ce-ccm-core.S b/arch/arm/crypto/aes-ce-ccm-core.S
new file mode 100644
index 000000000000..6eefb7dea77e
--- /dev/null
+++ b/arch/arm/crypto/aes-ce-ccm-core.S
@@ -0,0 +1,234 @@
+/*
+ * aesce-ccm-core.S - AES-CCM transform for ARMv8 with Crypto Extensions
+ *
+ * Copyright (C) 2013 - 2017 Linaro Ltd <ard.biesheuvel@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/linkage.h>
+#include <asm/assembler.h>
+
+ .text
+ .arch armv7-a
+ .fpu crypto-neon-fp-armv8
+
+ /*
+ * void ce_aes_ccm_auth_data(u8 mac[], u8 const in[], u32 abytes,
+ * u32 *macp, u8 const rk[], u32 rounds);
+ */
+ENTRY(ce_aes_ccm_auth_data)
+ push {r4-r8, lr}
+ ldrd r4, r5, [sp, #24]
+ ldr r8, [r3] /* leftover from prev round? */
+ vld1.8 {q0}, [r0] /* load mac */
+ teq r8, #0
+ beq 1f
+ sub r8, r8, #16
+ veor q1, q1, q1
+0: ldrb r7, [r1], #1 /* get 1 byte of input */
+ subs r2, r2, #1
+ add r8, r8, #1
+ vmov.8 d2[0], r7
+ vext.8 q1, q1, q1, #1 /* rotate in the input bytes */
+ beq 8f /* out of input? */
+ teq r8, #0
+ bne 0b
+ veor q0, q0, q1
+1: vld1.32 {q3}, [r4] /* load first round key */
+ cmp r5, #12 /* which key size? */
+ add r6, r4, #16
+ sub r7, r5, #2 /* modified # of rounds */
+ bmi 2f
+ bne 5f
+ vmov q5, q3
+ b 4f
+2: vmov q4, q3
+ vld1.32 {q5}, [r6]! /* load 2nd round key */
+3: aese.8 q0, q4
+ aesmc.8 q0, q0
+4: vld1.32 {q3}, [r6]! /* load next round key */
+ aese.8 q0, q5
+ aesmc.8 q0, q0
+5: vld1.32 {q4}, [r6]! /* load next round key */
+ subs r7, r7, #3
+ aese.8 q0, q3
+ aesmc.8 q0, q0
+ vld1.32 {q5}, [r6]! /* load next round key */
+ bpl 3b
+ aese.8 q0, q4
+ subs r2, r2, #16 /* last data? */
+ veor q0, q0, q5 /* final round */
+ bmi 6f
+ vld1.8 {q1}, [r1]! /* load next input block */
+ veor q0, q0, q1 /* xor with mac */
+ bne 1b
+6: vst1.8 {q0}, [r0] /* store mac */
+ beq 10f
+ adds r2, r2, #16
+ beq 10f
+ mov r8, r2
+7: ldrb r7, [r1], #1
+ vmov r6, d0[0]
+ eor r6, r6, r7
+ strb r6, [r0], #1
+ subs r2, r2, #1
+ beq 10f
+ vext.8 q0, q0, q0, #1 /* rotate out the mac bytes */
+ b 7b
+8: mov r7, r8
+ add r8, r8, #16
+9: vext.8 q1, q1, q1, #1
+ adds r7, r7, #1
+ bne 9b
+ veor q0, q0, q1
+ vst1.8 {q0}, [r0]
+10: str r8, [r3]
+ pop {r4-r8, pc}
+ENDPROC(ce_aes_ccm_auth_data)
+
+ /*
+ * void ce_aes_ccm_final(u8 mac[], u8 const ctr[], u8 const rk[],
+ * u32 rounds);
+ */
+ENTRY(ce_aes_ccm_final)
+ vld1.32 {q3}, [r2]! /* load first round key */
+ vld1.8 {q0}, [r0] /* load mac */
+ cmp r3, #12 /* which key size? */
+ sub r3, r3, #2 /* modified # of rounds */
+ vld1.8 {q1}, [r1] /* load 1st ctriv */
+ bmi 0f
+ bne 3f
+ vmov q5, q3
+ b 2f
+0: vmov q4, q3
+1: vld1.32 {q5}, [r2]! /* load next round key */
+ aese.8 q0, q4
+ aesmc.8 q0, q0
+ aese.8 q1, q4
+ aesmc.8 q1, q1
+2: vld1.32 {q3}, [r2]! /* load next round key */
+ aese.8 q0, q5
+ aesmc.8 q0, q0
+ aese.8 q1, q5
+ aesmc.8 q1, q1
+3: vld1.32 {q4}, [r2]! /* load next round key */
+ subs r3, r3, #3
+ aese.8 q0, q3
+ aesmc.8 q0, q0
+ aese.8 q1, q3
+ aesmc.8 q1, q1
+ bpl 1b
+ aese.8 q0, q4
+ aese.8 q1, q4
+ /* final round key cancels out */
+ veor q0, q0, q1 /* en-/decrypt the mac */
+ vst1.8 {q0}, [r0] /* store result */
+ bx lr
+ENDPROC(ce_aes_ccm_final)
+
+ .macro aes_ccm_do_crypt, enc
+ push {r4-r10, lr}
+ ldrd r4, r5, [sp, #32]
+ ldr r6, [sp, #40]
+
+ ldr r8, [r6, #12] /* load lower ctr */
+ vld1.8 {q0}, [r5] /* load mac */
+#ifndef CONFIG_CPU_BIG_ENDIAN
+ rev r8, r8 /* keep swabbed ctr in reg */
+#endif
+0: /* outer loop */
+ vld1.8 {q1}, [r6] /* load upper ctr */
+ add r8, r8, #1
+ rev r9, r8
+ cmp r4, #12 /* which key size? */
+ sub r7, r4, #2 /* get modified # of rounds */
+ vmov.32 d3[1], r9 /* no carry in lower ctr */
+ vld1.8 {q3}, [r3] /* load first round key */
+ add r10, r3, #16
+ bmi 1f
+ bne 4f
+ vmov q5, q3
+ b 3f
+1: vmov q4, q3
+ vld1.32 {q5}, [r10]! /* load 2nd round key */
+2: /* inner loop: 3 rounds, 2x interleaved */
+ aese.8 q0, q4
+ aesmc.8 q0, q0
+ aese.8 q1, q4
+ aesmc.8 q1, q1
+3: vld1.32 {q3}, [r10]! /* load next round key */
+ aese.8 q0, q5
+ aesmc.8 q0, q0
+ aese.8 q1, q5
+ aesmc.8 q1, q1
+4: vld1.32 {q4}, [r10]! /* load next round key */
+ subs r7, r7, #3
+ aese.8 q0, q3
+ aesmc.8 q0, q0
+ aese.8 q1, q3
+ aesmc.8 q1, q1
+ vld1.32 {q5}, [r10]! /* load next round key */
+ bpl 2b
+ aese.8 q0, q4
+ aese.8 q1, q4
+ subs r2, r2, #16
+ bmi 6f /* partial block? */
+ vld1.8 {q2}, [r1]! /* load next input block */
+ .if \enc == 1
+ veor q2, q2, q5 /* final round enc+mac */
+ veor q1, q1, q2 /* xor with crypted ctr */
+ .else
+ veor q2, q2, q1 /* xor with crypted ctr */
+ veor q1, q2, q5 /* final round enc */
+ .endif
+ veor q0, q0, q2 /* xor mac with pt ^ rk[last] */
+ vst1.8 {q1}, [r0]! /* write output block */
+ bne 0b
+#ifndef CONFIG_CPU_BIG_ENDIAN
+ rev r8, r8
+#endif
+ vst1.8 {q0}, [r5] /* store mac */
+ str r8, [r6, #12] /* store lsb end of ctr (BE) */
+5: pop {r4-r10, pc}
+
+6: veor q0, q0, q5 /* final round mac */
+ veor q1, q1, q5 /* final round enc */
+ vst1.8 {q0}, [r5] /* store mac */
+ add r2, r2, #16 /* process partial tail block */
+7: ldrb r9, [r1], #1 /* get 1 byte of input */
+ vmov.u8 r6, d2[0] /* get top crypted ctr byte */
+ vmov.u8 r7, d0[0] /* get top mac byte */
+ .if \enc == 1
+ eor r7, r7, r9
+ eor r9, r9, r6
+ .else
+ eor r9, r9, r6
+ eor r7, r7, r9
+ .endif
+ strb r9, [r0], #1 /* store out byte */
+ strb r7, [r5], #1 /* store mac byte */
+ subs r2, r2, #1
+ beq 5b
+ vext.8 q0, q0, q0, #1 /* shift out mac byte */
+ vext.8 q1, q1, q1, #1 /* shift out ctr byte */
+ b 7b
+ .endm
+
+ /*
+ * void ce_aes_ccm_encrypt(u8 out[], u8 const in[], u32 cbytes,
+ * u8 const rk[], u32 rounds, u8 mac[],
+ * u8 ctr[]);
+ * void ce_aes_ccm_decrypt(u8 out[], u8 const in[], u32 cbytes,
+ * u8 const rk[], u32 rounds, u8 mac[],
+ * u8 ctr[]);
+ */
+ENTRY(ce_aes_ccm_encrypt)
+ aes_ccm_do_crypt 1
+ENDPROC(ce_aes_ccm_encrypt)
+
+ENTRY(ce_aes_ccm_decrypt)
+ aes_ccm_do_crypt 0
+ENDPROC(ce_aes_ccm_decrypt)
diff --git a/arch/arm/crypto/aes-ce-ccm-glue.c b/arch/arm/crypto/aes-ce-ccm-glue.c
new file mode 100644
index 000000000000..137ff7dded6b
--- /dev/null
+++ b/arch/arm/crypto/aes-ce-ccm-glue.c
@@ -0,0 +1,360 @@
+/*
+ * aes-ccm-glue.c - AES-CCM transform for ARMv8 with Crypto Extensions
+ *
+ * Copyright (C) 2013 - 2017 Linaro Ltd <ard.biesheuvel@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <asm/neon.h>
+#include <asm/unaligned.h>
+#include <crypto/aes.h>
+#include <crypto/scatterwalk.h>
+#include <crypto/internal/aead.h>
+#include <crypto/internal/skcipher.h>
+#include <linux/module.h>
+
+struct crypto_aes_ccm_ctx {
+ struct crypto_aes_ctx key;
+ struct crypto_aead *fallback;
+};
+
+asmlinkage void ce_aes_ccm_auth_data(u8 mac[], u8 const in[], u32 abytes,
+ u32 *macp, u32 const rk[], u32 rounds);
+
+asmlinkage void ce_aes_ccm_encrypt(u8 out[], u8 const in[], u32 cbytes,
+ u32 const rk[], u32 rounds, u8 mac[],
+ u8 ctr[]);
+
+asmlinkage void ce_aes_ccm_decrypt(u8 out[], u8 const in[], u32 cbytes,
+ u32 const rk[], u32 rounds, u8 mac[],
+ u8 ctr[]);
+
+asmlinkage void ce_aes_ccm_final(u8 mac[], u8 const ctr[], u32 const rk[],
+ u32 rounds);
+
+static int num_rounds(struct crypto_aes_ccm_ctx *ctx)
+{
+ /*
+ * # of rounds specified by AES:
+ * 128 bit key 10 rounds
+ * 192 bit key 12 rounds
+ * 256 bit key 14 rounds
+ * => n byte key => 6 + (n/4) rounds
+ */
+ return 6 + ctx->key.key_length / 4;
+}
+
+static int ccm_setkey(struct crypto_aead *tfm, const u8 *in_key,
+ unsigned int key_len)
+{
+ struct crypto_aes_ccm_ctx *ctx = crypto_aead_ctx(tfm);
+ int ret;
+
+ ret = crypto_aes_expand_key(&ctx->key, in_key, key_len);
+ if (ret) {
+ tfm->base.crt_flags |= CRYPTO_TFM_RES_BAD_KEY_LEN;
+ return ret;
+ }
+
+ ret = crypto_aead_setkey(ctx->fallback, in_key, key_len);
+ if (ret) {
+ tfm->base.crt_flags |= (ctx->fallback->base.crt_flags &
+ CRYPTO_TFM_RES_BAD_KEY_LEN);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int ccm_setauthsize(struct crypto_aead *tfm, unsigned int authsize)
+{
+ struct crypto_aes_ccm_ctx *ctx = crypto_aead_ctx(tfm);
+
+ if ((authsize & 1) || authsize < 4)
+ return -EINVAL;
+
+ return crypto_aead_setauthsize(ctx->fallback, authsize);
+}
+
+static int ccm_init_mac(struct aead_request *req, u8 maciv[], u32 msglen)
+{
+ struct crypto_aead *aead = crypto_aead_reqtfm(req);
+ __be32 *n = (__be32 *)&maciv[AES_BLOCK_SIZE - 8];
+ u32 l = req->iv[0] + 1;
+
+ /* verify that CCM dimension 'L' is set correctly in the IV */
+ if (l < 2 || l > 8)
+ return -EINVAL;
+
+ /* verify that msglen can in fact be represented in L bytes */
+ if (l < 4 && msglen >> (8 * l))
+ return -EOVERFLOW;
+
+ /*
+ * Even if the CCM spec allows L values of up to 8, the Linux cryptoapi
+ * uses a u32 type to represent msglen so the top 4 bytes are always 0.
+ */
+ n[0] = 0;
+ n[1] = cpu_to_be32(msglen);
+
+ memcpy(maciv, req->iv, AES_BLOCK_SIZE - l);
+
+ /*
+ * Meaning of byte 0 according to CCM spec (RFC 3610/NIST 800-38C)
+ * - bits 0..2 : max # of bytes required to represent msglen, minus 1
+ * (already set by caller)
+ * - bits 3..5 : size of auth tag (1 => 4 bytes, 2 => 6 bytes, etc)
+ * - bit 6 : indicates presence of authenticate-only data
+ */
+ maciv[0] |= (crypto_aead_authsize(aead) - 2) << 2;
+ if (req->assoclen)
+ maciv[0] |= 0x40;
+
+ memset(&req->iv[AES_BLOCK_SIZE - l], 0, l);
+ return 0;
+}
+
+static void ccm_calculate_auth_mac(struct aead_request *req, u8 mac[])
+{
+ struct crypto_aead *aead = crypto_aead_reqtfm(req);
+ struct crypto_aes_ccm_ctx *ctx = crypto_aead_ctx(aead);
+ struct __packed { __be16 l; __be32 h; u16 len; } ltag;
+ struct scatter_walk walk;
+ u32 len = req->assoclen;
+ u32 macp = 0;
+
+ /* prepend the AAD with a length tag */
+ if (len < 0xff00) {
+ ltag.l = cpu_to_be16(len);
+ ltag.len = 2;
+ } else {
+ ltag.l = cpu_to_be16(0xfffe);
+ put_unaligned_be32(len, <ag.h);
+ ltag.len = 6;
+ }
+
+ ce_aes_ccm_auth_data(mac, (u8 *)<ag, ltag.len, &macp,
+ ctx->key.key_enc, num_rounds(ctx));
+ scatterwalk_start(&walk, req->src);
+
+ do {
+ u32 n = scatterwalk_clamp(&walk, len);
+ u8 *p;
+
+ if (!n) {
+ scatterwalk_start(&walk, sg_next(walk.sg));
+ n = scatterwalk_clamp(&walk, len);
+ }
+ p = scatterwalk_map(&walk);
+ ce_aes_ccm_auth_data(mac, p, n, &macp, ctx->key.key_enc,
+ num_rounds(ctx));
+ len -= n;
+
+ scatterwalk_unmap(p);
+ scatterwalk_advance(&walk, n);
+ scatterwalk_done(&walk, 0, len);
+ } while (len);
+}
+
+static int ccm_encrypt(struct aead_request *req)
+{
+ struct crypto_aead *aead = crypto_aead_reqtfm(req);
+ struct crypto_aes_ccm_ctx *ctx = crypto_aead_ctx(aead);
+ struct skcipher_walk walk;
+ u8 __aligned(8) mac[AES_BLOCK_SIZE];
+ u8 buf[AES_BLOCK_SIZE];
+ u32 len = req->cryptlen;
+ int err;
+
+ if (in_irq()) {
+ struct aead_request *fallback_req;
+
+ fallback_req = aead_request_alloc(ctx->fallback, GFP_ATOMIC);
+ if (!fallback_req)
+ return -ENOMEM;
+
+ aead_request_set_ad(fallback_req, req->assoclen);
+ aead_request_set_crypt(fallback_req, req->src, req->dst,
+ req->cryptlen, req->iv);
+
+ err = crypto_aead_encrypt(fallback_req);
+ aead_request_free(fallback_req);
+ return err;
+ }
+
+ err = ccm_init_mac(req, mac, len);
+ if (err)
+ return err;
+
+ kernel_neon_begin();
+
+ if (req->assoclen)
+ ccm_calculate_auth_mac(req, mac);
+
+ /* preserve the original iv for the final round */
+ memcpy(buf, req->iv, AES_BLOCK_SIZE);
+
+ err = skcipher_walk_aead_encrypt(&walk, req, true);
+
+ while (walk.nbytes) {
+ u32 tail = walk.nbytes % AES_BLOCK_SIZE;
+
+ if (walk.nbytes == walk.total)
+ tail = 0;
+
+ ce_aes_ccm_encrypt(walk.dst.virt.addr, walk.src.virt.addr,
+ walk.nbytes - tail, ctx->key.key_enc,
+ num_rounds(ctx), mac, walk.iv);
+
+ err = skcipher_walk_done(&walk, tail);
+ }
+ if (!err)
+ ce_aes_ccm_final(mac, buf, ctx->key.key_enc, num_rounds(ctx));
+
+ kernel_neon_end();
+
+ if (err)
+ return err;
+
+ /* copy authtag to end of dst */
+ scatterwalk_map_and_copy(mac, req->dst, req->assoclen + req->cryptlen,
+ crypto_aead_authsize(aead), 1);
+
+ return 0;
+}
+
+static int ccm_decrypt(struct aead_request *req)
+{
+ struct crypto_aead *aead = crypto_aead_reqtfm(req);
+ struct crypto_aes_ccm_ctx *ctx = crypto_aead_ctx(aead);
+ unsigned int authsize = crypto_aead_authsize(aead);
+ struct skcipher_walk walk;
+ u8 __aligned(8) mac[AES_BLOCK_SIZE];
+ u8 buf[AES_BLOCK_SIZE];
+ u32 len = req->cryptlen - authsize;
+ int err;
+
+ if (in_irq()) {
+ struct aead_request *fallback_req;
+
+ fallback_req = aead_request_alloc(ctx->fallback, GFP_ATOMIC);
+ if (!fallback_req)
+ return -ENOMEM;
+
+ aead_request_set_ad(fallback_req, req->assoclen);
+ aead_request_set_crypt(fallback_req, req->src, req->dst,
+ req->cryptlen, req->iv);
+
+ err = crypto_aead_decrypt(fallback_req);
+ aead_request_free(fallback_req);
+ return err;
+ }
+
+ err = ccm_init_mac(req, mac, len);
+ if (err)
+ return err;
+
+ kernel_neon_begin();
+
+ if (req->assoclen)
+ ccm_calculate_auth_mac(req, mac);
+
+ /* preserve the original iv for the final round */
+ memcpy(buf, req->iv, AES_BLOCK_SIZE);
+
+ err = skcipher_walk_aead_decrypt(&walk, req, true);
+
+ while (walk.nbytes) {
+ u32 tail = walk.nbytes % AES_BLOCK_SIZE;
+
+ if (walk.nbytes == walk.total)
+ tail = 0;
+
+ ce_aes_ccm_decrypt(walk.dst.virt.addr, walk.src.virt.addr,
+ walk.nbytes - tail, ctx->key.key_enc,
+ num_rounds(ctx), mac, walk.iv);
+
+ err = skcipher_walk_done(&walk, tail);
+ }
+ if (!err)
+ ce_aes_ccm_final(mac, buf, ctx->key.key_enc, num_rounds(ctx));
+
+ kernel_neon_end();
+
+ if (err)
+ return err;
+
+ /* compare calculated auth tag with the stored one */
+ scatterwalk_map_and_copy(buf, req->src,
+ req->assoclen + req->cryptlen - authsize,
+ authsize, 0);
+
+ if (crypto_memneq(mac, buf, authsize))
+ return -EBADMSG;
+ return 0;
+}
+
+static int ccm_init(struct crypto_aead *aead)
+{
+ struct crypto_aes_ccm_ctx *ctx = crypto_aead_ctx(aead);
+ struct crypto_aead *tfm;
+
+ tfm = crypto_alloc_aead("ccm(aes)", 0,
+ CRYPTO_ALG_ASYNC | CRYPTO_ALG_NEED_FALLBACK);
+
+ if (IS_ERR(tfm))
+ return PTR_ERR(tfm);
+
+ ctx->fallback = tfm;
+ return 0;
+}
+
+static void ccm_exit(struct crypto_aead *aead)
+{
+ struct crypto_aes_ccm_ctx *ctx = crypto_aead_ctx(aead);
+
+ crypto_free_aead(ctx->fallback);
+}
+
+static struct aead_alg ccm_aes_alg = {
+ .base.cra_name = "ccm(aes)",
+ .base.cra_driver_name = "ccm-aes-ce",
+ .base.cra_priority = 300,
+ .base.cra_blocksize = 1,
+ .base.cra_ctxsize = sizeof(struct crypto_aes_ccm_ctx),
+ .base.cra_module = THIS_MODULE,
+ .base.cra_flags = CRYPTO_ALG_NEED_FALLBACK,
+
+ .ivsize = AES_BLOCK_SIZE,
+ .chunksize = AES_BLOCK_SIZE,
+ .maxauthsize = AES_BLOCK_SIZE,
+ .setkey = ccm_setkey,
+ .setauthsize = ccm_setauthsize,
+ .encrypt = ccm_encrypt,
+ .decrypt = ccm_decrypt,
+ .init = ccm_init,
+ .exit = ccm_exit,
+};
+
+static int __init aes_mod_init(void)
+{
+ if (!(elf_hwcap2 & HWCAP2_AES))
+ return -ENODEV;
+ return crypto_register_aead(&ccm_aes_alg);
+}
+
+static void __exit aes_mod_exit(void)
+{
+ crypto_unregister_aead(&ccm_aes_alg);
+}
+
+module_init(aes_mod_init);
+module_exit(aes_mod_exit);
+
+MODULE_DESCRIPTION("Synchronous AES in CCM mode using ARMv8 Crypto Extensions");
+MODULE_AUTHOR("Ard Biesheuvel <ard.biesheuvel@linaro.org>");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS_CRYPTO("ccm(aes)");
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 1/2] ARM: vfp - allow kernel mode NEON in softirq context
From: Ard Biesheuvel @ 2017-01-09 19:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483991849-32448-1-git-send-email-ard.biesheuvel@linaro.org>
This updates the kernel mode NEON handling to allow the NEON to be used
in softirq context as well as process context. This involves disabling
softirq processing when the NEON is used in kernel mode in process context,
and dealing with the situation where 'current' is not the owner of the
userland context that is present in the NEON register file when the NEON
is enabled in kernel mode.
The rationale for this change is that the NEON is shared with the ARMv8
Crypto Extensions (which are also defined for the AArch32 execution state),
which can give a huge performance boost (15x) to use cases like mac80211
CCMP processing, which executes in softirq context.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/vfp/vfpmodule.c | 22 ++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index 569d5a650a4a..814752811537 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -690,26 +690,33 @@ void kernel_neon_begin(void)
u32 fpexc;
/*
- * Kernel mode NEON is only allowed outside of interrupt context
+ * Kernel mode NEON is only allowed outside of hardirq context
* with preemption disabled. This will make sure that the kernel
* mode NEON register contents never need to be preserved.
*/
- BUG_ON(in_interrupt());
+ BUG_ON(in_irq());
cpu = get_cpu();
+ /*
+ * Disable softirq processing while the NEON is used by the kernel in
+ * process context. This ensures that only a single kernel mode NEON
+ * state is live at any given time.
+ */
+ if (!in_serving_softirq())
+ local_bh_disable();
+
fpexc = fmrx(FPEXC) | FPEXC_EN;
fmxr(FPEXC, fpexc);
/*
- * Save the userland NEON/VFP state. Under UP,
- * the owner could be a task other than 'current'
+ * Save the userland NEON/VFP state. Under UP, or when executing in
+ * softirq context, the owner could be a task other than 'current'
*/
if (vfp_state_in_hw(cpu, thread))
vfp_save_state(&thread->vfpstate, fpexc);
-#ifndef CONFIG_SMP
else if (vfp_current_hw_state[cpu] != NULL)
vfp_save_state(vfp_current_hw_state[cpu], fpexc);
-#endif
+
vfp_current_hw_state[cpu] = NULL;
}
EXPORT_SYMBOL(kernel_neon_begin);
@@ -718,7 +725,10 @@ void kernel_neon_end(void)
{
/* Disable the NEON/VFP unit. */
fmxr(FPEXC, fmrx(FPEXC) & ~FPEXC_EN);
+ if (!in_serving_softirq())
+ local_bh_enable();
put_cpu();
+
}
EXPORT_SYMBOL(kernel_neon_end);
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 0/2] ARM: kernel mode NEON in softirq context
From: Ard Biesheuvel @ 2017-01-09 19:57 UTC (permalink / raw)
To: linux-arm-kernel
Patch #1 in this series adds support for using the NEON in kernel mode
while executing in softirq context. By allowing this, subsystems that
perform non-trivial crypto in softirq context (such as CCMP in the
mac80211 layer) can use algorithms such as the AES-CCM driver in
patch #2, which is 13x faster than the generic CCM driver.
Ard Biesheuvel (2):
ARM: vfp - allow kernel mode NEON in softirq context
crypto: arm/aes - add CCM driver using ARMv8 Crypto Extensions
arch/arm/crypto/Kconfig | 8 +
arch/arm/crypto/Makefile | 2 +
arch/arm/crypto/aes-ce-ccm-core.S | 234 +++++++++++++
arch/arm/crypto/aes-ce-ccm-glue.c | 360 ++++++++++++++++++++
arch/arm/vfp/vfpmodule.c | 22 +-
5 files changed, 620 insertions(+), 6 deletions(-)
create mode 100644 arch/arm/crypto/aes-ce-ccm-core.S
create mode 100644 arch/arm/crypto/aes-ce-ccm-glue.c
--
2.7.4
^ permalink raw reply
* [RESEND] spi: davinci: Allow device tree devices to use DMA
From: Mark Brown @ 2017-01-09 19:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483673177-31516-1-git-send-email-david@lechnology.com>
On Thu, Jan 05, 2017 at 09:26:17PM -0600, David Lechner wrote:
> This allows SPI devices specified in a device tree to use DMA when the
> master controller.
> Since device tree is supposed to only describe the hardware, adding such
> a configuration option to device tree would not be acceptable. So, this
> is the best we can do for now to get SPI devices working with DMA.
> Unfortunately, this excludes the possibility of using one SPI device with
> DMA and one without on the same master.
Why would you ever want to do that? What would ever make sense about
not using DMA if it's available and the transfer is suitably large, or
conversely why would one want to force DMA even if PIO would be more
performant?
> When I originally submitted this patch, there was some discussion as to whether
> dspi->dma_rx should be changed to return an error rather than being null.
> However, I prefer it the way it is and don't see a compelling reason to change
> it.
I don't know what the above comment means, sorry (and don't recall
having seen any earlier versions of this).
-------------- 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/20170109/ce442c16/attachment.sig>
^ permalink raw reply
* [PATCH 5/5] ARM: dts: keystone-k2e: Add PSC reset controller node
From: Suman Anna @ 2017-01-09 19:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109194358.27271-1-s-anna@ti.com>
The Power Sleep Controller (PSC) module contains specific
memory-mapped registers that can be used to perform reset
management using specific bits for the DSPs available on the
SoC. The PSC is defined using a syscon node, and the reset
functionality is defined using a child syscon reset controller
node.
Add this syscon reset controller node as well as the reset
control data for the resets it supports for the 66AK2E SoCs.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
arch/arm/boot/dts/keystone-k2e.dtsi | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2e.dtsi b/arch/arm/boot/dts/keystone-k2e.dtsi
index 9d1d8a64d10e..c5983418c42c 100644
--- a/arch/arm/boot/dts/keystone-k2e.dtsi
+++ b/arch/arm/boot/dts/keystone-k2e.dtsi
@@ -8,6 +8,8 @@
* published by the Free Software Foundation.
*/
+#include <dt-bindings/reset/ti-syscon.h>
+
/ {
compatible = "ti,k2e", "ti,keystone";
model = "Texas Instruments Keystone 2 Edison SoC";
@@ -94,6 +96,17 @@
};
};
+ psc: power-sleep-controller at 02350000 {
+ pscrst: psc-reset-controller {
+ compatible = "ti,k2e-pscrst", "ti,syscon-reset";
+ #reset-cells = <1>;
+
+ ti,reset-bits = <
+ 0xa3c 8 0xa3c 8 0x83c 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 0: dsp0 */
+ >;
+ };
+ };
+
dspgpio0: keystone_dsp_gpio at 02620240 {
compatible = "ti,keystone-dsp-gpio";
gpio-controller;
--
2.10.2
^ permalink raw reply related
* [PATCH 4/5] ARM: dts: keystone-k2l: Add PSC reset controller node
From: Suman Anna @ 2017-01-09 19:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109194358.27271-1-s-anna@ti.com>
The Power Sleep Controller (PSC) module contains specific
memory-mapped registers that can be used to perform reset
management using specific bits for the DSPs available on the
SoC. The PSC is defined using a syscon node, and the reset
functionality is defined using a child syscon reset controller
node.
Add this syscon reset controller node as well as the reset
control data for the resets it supports for the 66AK2L SoCs.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
arch/arm/boot/dts/keystone-k2l.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2l.dtsi b/arch/arm/boot/dts/keystone-k2l.dtsi
index b58015737a35..4fa368f9ba52 100644
--- a/arch/arm/boot/dts/keystone-k2l.dtsi
+++ b/arch/arm/boot/dts/keystone-k2l.dtsi
@@ -8,6 +8,8 @@
* published by the Free Software Foundation.
*/
+#include <dt-bindings/reset/ti-syscon.h>
+
/ {
compatible = "ti,k2l", "ti,keystone";
model = "Texas Instruments Keystone 2 Lamarr SoC";
@@ -216,6 +218,20 @@
};
};
+ psc: power-sleep-controller at 02350000 {
+ pscrst: psc-reset-controller {
+ compatible = "ti,k2l-pscrst", "ti,syscon-reset";
+ #reset-cells = <1>;
+
+ ti,reset-bits = <
+ 0xa3c 8 0xa3c 8 0x83c 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 0: dsp0 */
+ 0xa40 8 0xa40 8 0x840 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 1: dsp1 */
+ 0xa44 8 0xa44 8 0x844 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 2: dsp2 */
+ 0xa48 8 0xa48 8 0x848 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 3: dsp3 */
+ >;
+ };
+ };
+
dspgpio0: keystone_dsp_gpio at 02620240 {
compatible = "ti,keystone-dsp-gpio";
gpio-controller;
--
2.10.2
^ permalink raw reply related
* [PATCH 3/5] ARM: dts: keystone-k2hk: Add PSC reset controller node
From: Suman Anna @ 2017-01-09 19:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109194358.27271-1-s-anna@ti.com>
The Power Sleep Controller (PSC) module contains specific
memory-mapped registers that can be used to perform reset
management using specific bits for the DSPs available on the
SoC. The PSC is defined using a syscon node, and the reset
functionality is defined using a child syscon reset controller
node.
Add this syscon reset controller node as well as the reset
control data for the resets it supports for the 66AK2H SoCs.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
arch/arm/boot/dts/keystone-k2hk.dtsi | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2hk.dtsi b/arch/arm/boot/dts/keystone-k2hk.dtsi
index e0780f111537..a833db72fc61 100644
--- a/arch/arm/boot/dts/keystone-k2hk.dtsi
+++ b/arch/arm/boot/dts/keystone-k2hk.dtsi
@@ -8,6 +8,8 @@
* published by the Free Software Foundation.
*/
+#include <dt-bindings/reset/ti-syscon.h>
+
/ {
compatible = "ti,k2hk", "ti,keystone";
model = "Texas Instruments Keystone 2 Kepler/Hawking SoC";
@@ -58,6 +60,24 @@
};
};
+ psc: power-sleep-controller at 02350000 {
+ pscrst: psc-reset-controller {
+ compatible = "ti,k2hk-pscrst", "ti,syscon-reset";
+ #reset-cells = <1>;
+
+ ti,reset-bits = <
+ 0xa3c 8 0xa3c 8 0x83c 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 0: dsp0 */
+ 0xa40 8 0xa40 8 0x840 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 1: dsp1 */
+ 0xa44 8 0xa44 8 0x844 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 2: dsp2 */
+ 0xa48 8 0xa48 8 0x848 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 3: dsp3 */
+ 0xa4c 8 0xa4c 8 0x84c 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 4: dsp4 */
+ 0xa50 8 0xa50 8 0x850 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 5: dsp5 */
+ 0xa54 8 0xa54 8 0x854 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 6: dsp6 */
+ 0xa58 8 0xa58 8 0x858 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 7: dsp7 */
+ >;
+ };
+ };
+
dspgpio0: keystone_dsp_gpio at 02620240 {
compatible = "ti,keystone-dsp-gpio";
gpio-controller;
--
2.10.2
^ permalink raw reply related
* [PATCH 2/5] ARM: dts: keystone: Add PSC node
From: Suman Anna @ 2017-01-09 19:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109194358.27271-1-s-anna@ti.com>
The Power Sleep Controller (PSC) module is responsible
for the power and clock management for each of the peripherals
present on the SoC. Represent this as a syscon node so that
multiple users can leverage it for various functionalities.
Signed-off-by: Suman Anna <s-anna@ti.com>
[afd at ti.com: add simple-mfd compatible]
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
arch/arm/boot/dts/keystone.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index 02708ba2d4f4..ec203d0a673d 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -83,6 +83,11 @@
reg = <0x02310000 0x200>;
};
+ psc: power-sleep-controller at 02350000 {
+ compatible = "syscon", "simple-mfd";
+ reg = <0x02350000 0x1000>;
+ };
+
devctrl: device-state-control at 02620000 {
compatible = "ti,keystone-devctrl", "syscon";
reg = <0x02620000 0x1000>;
--
2.10.2
^ permalink raw reply related
* [PATCH 1/5] ARM: Keystone: Enable ARCH_HAS_RESET_CONTROLLER
From: Suman Anna @ 2017-01-09 19:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109194358.27271-1-s-anna@ti.com>
The Keystone 2 family of SoCs will use various Reset Controller
drivers for managing the resets of remote processor devices like
DSPs on the SoC, so select the ARCH_HAS_RESET_CONTROLLER option
by default to enable the Reset framework.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/mach-keystone/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-keystone/Kconfig b/arch/arm/mach-keystone/Kconfig
index 24bd64dabdfc..554357035f30 100644
--- a/arch/arm/mach-keystone/Kconfig
+++ b/arch/arm/mach-keystone/Kconfig
@@ -4,6 +4,7 @@ config ARCH_KEYSTONE
select ARM_GIC
select HAVE_ARM_ARCH_TIMER
select KEYSTONE_TIMER
+ select ARCH_HAS_RESET_CONTROLLER
select ARM_ERRATA_798181 if SMP
select COMMON_CLK_KEYSTONE
select ARCH_SUPPORTS_BIG_ENDIAN
--
2.10.2
^ permalink raw reply related
* [PATCH 0/5] Reset Controller Nodes for TI Keystone platforms
From: Suman Anna @ 2017-01-09 19:43 UTC (permalink / raw)
To: linux-arm-kernel
Hi Santosh,
This patch adds the reset controller nodes and the corresponding
reset data for TI Keystone 66AK2H, 66AK2L and 66AK2E SoCs. These
resets are for the DSPs on these SoCs, and are the last dependencies
before the keystone remoteproc driver can be added.
All these SoCs will use the ti-syscon-reset driver which is already
part of mainline kernel. The bindings for the same can be found in
Documentation/devicetree/bindings/reset/ti-syscon-reset.txt file.
Note that the other Keystone 66AK2G SoC will use a different TI-SCI
based reset driver, so will be submitted separately once the TI-SCI
dependencies make it into mainline.
Patches are based on top of 4.10-rc1 plus the MSM-RAM DT node series
that you have already picked up. Patch 1 enable the Reset Framework
for Keystone platforms, and remaining patches add the required DT
nodes.
regards
Suman
Suman Anna (5):
ARM: Keystone: Enable ARCH_HAS_RESET_CONTROLLER
ARM: dts: keystone: Add PSC node
ARM: dts: keystone-k2hk: Add PSC reset controller node
ARM: dts: keystone-k2l: Add PSC reset controller node
ARM: dts: keystone-k2e: Add PSC reset controller node
arch/arm/boot/dts/keystone-k2e.dtsi | 13 +++++++++++++
arch/arm/boot/dts/keystone-k2hk.dtsi | 20 ++++++++++++++++++++
arch/arm/boot/dts/keystone-k2l.dtsi | 16 ++++++++++++++++
arch/arm/boot/dts/keystone.dtsi | 5 +++++
arch/arm/mach-keystone/Kconfig | 1 +
5 files changed, 55 insertions(+)
--
2.10.2
^ 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