* [RFC PATCH 4/6] serial: 8250_omap: Make 8250_omap driver driver depend on ARCH_K3
From: Nishanth Menon @ 2018-06-05 6:01 UTC (permalink / raw)
To: Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, Rob Herring
Cc: Nishanth Menon, devicetree, Vignesh R, Tony Lindgren,
linux-kernel, Russell King, Tero Kristo, Lokesh Vutla,
linux-serial, Sudeep Holla, linux-arm-kernel
In-Reply-To: <20180605060125.9518-1-nm@ti.com>
From: Lokesh Vutla <lokeshvutla@ti.com>
Allow 8250 omap serial driver to be used for K3 platforms.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
drivers/tty/serial/8250/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
index f005eaf8bc57..15c2c5463835 100644
--- a/drivers/tty/serial/8250/Kconfig
+++ b/drivers/tty/serial/8250/Kconfig
@@ -375,7 +375,7 @@ config SERIAL_8250_RT288X
config SERIAL_8250_OMAP
tristate "Support for OMAP internal UART (8250 based driver)"
- depends on SERIAL_8250 && ARCH_OMAP2PLUS
+ depends on SERIAL_8250 && (ARCH_OMAP2PLUS || ARCH_K3)
help
If you have a machine based on an Texas Instruments OMAP CPU you
can enable its onboard serial ports by enabling this option.
--
2.15.1
^ permalink raw reply related
* [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
From: Nishanth Menon @ 2018-06-05 6:05 UTC (permalink / raw)
To: Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, Rob Herring
Cc: linux-serial, linux-kernel, devicetree, linux-arm-kernel,
Tony Lindgren, Vignesh R, Tero Kristo, Russell King, Sudeep Holla,
nm
In-Reply-To: <=<20180605060125.9518-1-nm@ti.com>
The AM654 SoC is a lead device of the K3 Multicore SoC architecture
platform, targeted for broad market and industrial control with aim to
meet the complex processing needs of modern embedded products.
Some highlights of this SoC are:
* Quad ARMv8 A53 cores split over two clusters
* GICv3 compliant GIC500
* Configurable L3 Cache and IO-coherent architecture
* Dual lock-step capable R5F uC for safety-critical applications
* High data throughput capable distributed DMA architecture under NAVSS
* Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual
PRUs and dual RTUs
* Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
* Centralized System Controller for Security, Power, and Resource
management.
* Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD
* Flash subystem with OSPI and Hyperbus interfaces
* Multimedia capability with CAL, DSS7-UL, SGX544, McASP
* Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI,
GPIO
See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7
We introduce the Kconfig symbol for the SoC along with this patch since
it is logically relevant point, however the usage is in subsequent
patches.
NOTE: AM654 is the first of the device variants, hence we introduce a
generic am6.dtsi.
Signed-off-by: Benjamin Fair <b-fair@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
MAINTAINERS | 1 +
arch/arm64/boot/dts/ti/k3-am6.dtsi | 144 +++++++++++++++++++++++++++++++++++
arch/arm64/boot/dts/ti/k3-am654.dtsi | 117 ++++++++++++++++++++++++++++
drivers/soc/ti/Kconfig | 14 ++++
4 files changed, 276 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am6.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am654.dtsi
diff --git a/MAINTAINERS b/MAINTAINERS
index cfb35b252ac7..5f5c4eddec7a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2092,6 +2092,7 @@ M: Nishanth Menon <nm@ti.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Supported
F: Documentation/devicetree/bindings/arm/ti/k3.txt
+F: arch/arm64/boot/dts/ti/k3-*
ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE
M: Santosh Shilimkar <ssantosh@kernel.org>
diff --git a/arch/arm64/boot/dts/ti/k3-am6.dtsi b/arch/arm64/boot/dts/ti/k3-am6.dtsi
new file mode 100644
index 000000000000..cdfa12173aac
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am6.dtsi
@@ -0,0 +1,144 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for AM6 SoC Family
+ *
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+ model = "Texas Instruments K3 AM654 SoC";
+ compatible = "ti,am654";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ serial0 = &wkup_uart0;
+ serial1 = &mcu_uart0;
+ serial2 = &main_uart0;
+ serial3 = &main_uart1;
+ serial4 = &main_uart2;
+ };
+
+ chosen { };
+
+ firmware {
+ optee {
+ compatible = "linaro,optee-tz";
+ method = "smc";
+ };
+
+ psci: psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+ };
+
+ soc0: soc0 {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ a53_timer0: timer-cl0-cpu0 {
+ compatible = "arm,armv8-timer";
+ interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, /* cntpsirq */
+ <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, /* cntpnsirq */
+ <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, /* cntvirq */
+ <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; /* cnthpirq */
+ };
+
+ pmu: pmu {
+ compatible = "arm,armv8-pmuv3";
+ /* Recommendation from GIC500 TRM Table A.3 */
+ interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ gic: interrupt-controller@1800000 {
+ compatible = "arm,gic-v3";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ /*
+ * NOTE: we are NOT gicv2 backward compat, so no GICC,
+ * GICH or GICV
+ */
+ reg = <0x0 0x01800000 0x0 0x10000>, /* GICD */
+ <0x0 0x01880000 0x0 0x90000>; /* GICR */
+
+ /*
+ * vcpumntirq:
+ * virtual CPU interface maintenance interrupt
+ */
+ interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+
+ gic_its: gic-its@1000000 {
+ compatible = "arm,gic-v3-its";
+ reg = <0x0 0x1820000 0x0 0x10000>;
+ msi-controller;
+ #msi-cells = <1>;
+ };
+ };
+
+ wkup_uart0: serial@42300000 {
+ compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
+ reg = <0x0 0x42300000 0x0 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 697 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <48000000>;
+ current-speed = <115200>;
+ status = "disabled";
+ };
+
+ mcu_uart0: serial@40a00000 {
+ compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
+ reg = <0x0 0x40a00000 0x0 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 565 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <96000000>;
+ current-speed = <115200>;
+ status = "disabled";
+ };
+
+ main_uart0: serial@2800000 {
+ compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
+ reg = <0x0 0x02800000 0x0 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <48000000>;
+ current-speed = <115200>;
+ status = "disabled";
+ };
+
+ main_uart1: serial@2810000 {
+ compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
+ reg = <0x0 0x02810000 0x0 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <48000000>;
+ current-speed = <115200>;
+ status = "disabled";
+ };
+
+ main_uart2: serial@2820000 {
+ compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
+ reg = <0x0 0x02820000 0x0 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <48000000>;
+ current-speed = <115200>;
+ status = "disabled";
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am654.dtsi b/arch/arm64/boot/dts/ti/k3-am654.dtsi
new file mode 100644
index 000000000000..d9b70081daba
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am654.dtsi
@@ -0,0 +1,117 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for AM6 SoC family in Quad core configuration
+ *
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#include "k3-am6.dtsi"
+
+/ {
+ cpus: cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu-map {
+ cluster0: cluster0 {
+ core0 {
+ cpu = <&cpu0>;
+ };
+
+ core1 {
+ cpu = <&cpu1>;
+ };
+ };
+
+ cluster1: cluster1 {
+ core0 {
+ cpu = <&cpu2>;
+ };
+
+ core1 {
+ cpu = <&cpu3>;
+ };
+ };
+ };
+
+ cpu0: cpu@0 {
+ compatible = "arm,cortex-a53","arm,armv8";
+ reg = <0x000>;
+ device_type = "cpu";
+ enable-method = "psci";
+ i-cache-size = <0x8000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <256>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ next-level-cache = <&L2_0>;
+ };
+
+ cpu1: cpu@1 {
+ compatible = "arm,cortex-a53","arm,armv8";
+ reg = <0x001>;
+ device_type = "cpu";
+ enable-method = "psci";
+ i-cache-size = <0x8000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <256>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ next-level-cache = <&L2_0>;
+ };
+
+ cpu2: cpu@100 {
+ compatible = "arm,cortex-a53","arm,armv8";
+ reg = <0x100>;
+ device_type = "cpu";
+ enable-method = "psci";
+ i-cache-size = <0x8000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <256>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ next-level-cache = <&L2_1>;
+ };
+
+ cpu3: cpu@101 {
+ compatible = "arm,cortex-a53","arm,armv8";
+ reg = <0x101>;
+ device_type = "cpu";
+ enable-method = "psci";
+ i-cache-size = <0x8000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <256>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ next-level-cache = <&L2_1>;
+ };
+ };
+};
+
+&soc0 {
+ L2_0: l2-cache0 {
+ compatible = "cache";
+ cache-level = <2>;
+ cache-size = <0x80000>;
+ cache-line-size = <64>;
+ cache-sets = <512>;
+ next-level-cache = <&msmc_l3>;
+ };
+
+ L2_1: l2-cache1 {
+ compatible = "cache";
+ cache-level = <2>;
+ cache-size = <0x80000>;
+ cache-line-size = <64>;
+ cache-sets = <512>;
+ next-level-cache = <&msmc_l3>;
+ };
+
+ msmc_l3: l3-cache0 {
+ compatible = "cache";
+ cache-level = <3>;
+ };
+};
diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
index 92770d84a288..be4570baad96 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -1,3 +1,17 @@
+# 64-bit ARM SoCs from TI
+if ARM64
+
+if ARCH_K3
+
+config ARCH_K3_AM6_SOC
+ bool "K3 AM6 SoC"
+ help
+ Enable support for TI's AM6 SoC Family support
+
+endif
+
+endif
+
#
# TI SOC drivers
#
--
2.15.1
^ permalink raw reply related
* [RFC PATCH 6/6] arm64: dts: ti: Add support for AM654 EVM base board
From: Nishanth Menon @ 2018-06-05 6:05 UTC (permalink / raw)
To: Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, Rob Herring
Cc: linux-serial, linux-kernel, devicetree, linux-arm-kernel,
Tony Lindgren, Vignesh R, Tero Kristo, Russell King, Sudeep Holla,
nm
In-Reply-To: <20180605060510.32473-1-nm@ti.com>
The EValuation Module(EVM) platform for AM654 consists of a
common Base board + one or more of daughter cards, which include:
a) "Personality Modules", which can be specific to a profile, such as
ICSSG enabled or Multi-media (including audio).
b) SERDES modules, which may be 2 lane PCIe or two port PCIe + USB2
c) Camera daughter card
d) various display panels
Among other options. There are two basic configurations defined which
include an "EVM" configuration and "IDK" (Industrial development kit)
which differ in the specific combination of daughter cards that are
used.
To simplify support, we choose to support just the base board as the
core device tree file and all daughter cards would be expected to be
device tree overlays.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
MAINTAINERS | 1 +
arch/arm64/boot/dts/Makefile | 1 +
arch/arm64/boot/dts/ti/Makefile | 9 ++++++
arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 40 ++++++++++++++++++++++++++
4 files changed, 51 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/Makefile
create mode 100644 arch/arm64/boot/dts/ti/k3-am654-base-board.dts
diff --git a/MAINTAINERS b/MAINTAINERS
index 5f5c4eddec7a..4491a0f0625f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2092,6 +2092,7 @@ M: Nishanth Menon <nm@ti.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Supported
F: Documentation/devicetree/bindings/arm/ti/k3.txt
+F: arch/arm64/boot/dts/ti/Makefile
F: arch/arm64/boot/dts/ti/k3-*
ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index 3543bc324553..4690364d584b 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -23,5 +23,6 @@ subdir-y += rockchip
subdir-y += socionext
subdir-y += sprd
subdir-y += synaptics
+subdir-y += ti
subdir-y += xilinx
subdir-y += zte
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
new file mode 100644
index 000000000000..63e619d0b5b8
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -0,0 +1,9 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Make file to build device tree binaries for boards based on
+# Texas Instruments Inc processors
+#
+# Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+#
+
+dtb-$(CONFIG_ARCH_K3_AM6_SOC) += k3-am654-base-board.dtb
diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
new file mode 100644
index 000000000000..d227d792de60
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+/dts-v1/;
+
+#include "k3-am654.dtsi"
+
+/ {
+ compatible = "ti,am654-evm", "ti,am654";
+ model = "Texas Instruments AM654 Base Board";
+
+ chosen {
+ stdout-path = "serial2:115200n8";
+ bootargs = "earlycon=ns16550a,mmio32,0x02800000";
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ /* 4G RAM */
+ reg = <0x00000000 0x80000000 0x00000000 0x80000000>,
+ <0x00000008 0x80000000 0x00000000 0x80000000>;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ secure_ddr: secure_ddr@9e800000 {
+ reg = <0 0x9e800000 0 0x01800000>; /* for OP-TEE */
+ alignment = <0x1000>;
+ no-map;
+ };
+ };
+};
+
+&main_uart0 {
+ status = "okay";
+};
--
2.15.1
^ permalink raw reply related
* [RFC PATCH 0/8] mailbox: ti-msgmgr: Add support for AM654 Secure Proxy
From: Nishanth Menon @ 2018-06-05 6:16 UTC (permalink / raw)
To: Jassi Brar, Rob Herring
Cc: linux-arm-kernel, linux-kernel, devicetree, Nishanth Menon,
Tero Kristo, Suman Anna
Hi,
The following series enables support for Secure Proxy in newest addition in TI's SoC
portfolio - AM654 SoC.
The series is an RFC based off next-20180604 and will post formally once
v4.18-rc1 is available.
The DT and ARCH part of the series is based on https://marc.info/?l=linux-arm-kernel&m=152817866312732&w=2
The series (part 2 of 4) is available here:
https://github.com/nmenon/linux-2.6-playground/commits/upstream/next-20180604/k3-2-am6-sproxy
Full Boot log is available here: https://pastebin.ubuntu.com/p/vWCzMKtBCW/
See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7
Nishanth Menon (8):
mailbox: ti-msgmgr: Get rid of unused structure members
mailbox: ti-msgmgr: Allocate Rx channel resources only on request
mailbox: ti-msgmgr: Change message count mask to be descriptor based
mailbox: ti-msgmgr: Move the memory region name to descriptor
dt-bindings: mailbox: ti,message-manager: Add support for secure proxy
threads
mailbox: ti-msgmgr: Add support for Secure Proxy
drivers: mailbox: Make ti-msgmr driver depend on ARCH_K3
arm64: dts: ti: k3-am6: Add Secure Proxy instance
.../bindings/mailbox/ti,message-manager.txt | 58 +++-
arch/arm64/boot/dts/ti/k3-am6.dtsi | 11 +
drivers/mailbox/Kconfig | 8 +-
drivers/mailbox/ti-msgmgr.c | 353 +++++++++++++++++----
4 files changed, 351 insertions(+), 79 deletions(-)
--
2.15.1
^ permalink raw reply
* [RFC PATCH 1/8] mailbox: ti-msgmgr: Get rid of unused structure members
From: Nishanth Menon @ 2018-06-05 6:16 UTC (permalink / raw)
To: Jassi Brar, Rob Herring
Cc: linux-arm-kernel, linux-kernel, devicetree, Nishanth Menon,
Tero Kristo, Suman Anna
In-Reply-To: <20180605061629.4759-1-nm@ti.com>
Though q_proxies and q_slices do describe the hardware configuration,
they are not necessary for operation given that the values are
always default. Hence drop the same.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
drivers/mailbox/ti-msgmgr.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/mailbox/ti-msgmgr.c b/drivers/mailbox/ti-msgmgr.c
index 78753a87ba4d..7cd5f9c9c97f 100644
--- a/drivers/mailbox/ti-msgmgr.c
+++ b/drivers/mailbox/ti-msgmgr.c
@@ -42,8 +42,6 @@ struct ti_msgmgr_valid_queue_desc {
* @queue_count: Number of Queues
* @max_message_size: Message size in bytes
* @max_messages: Number of messages
- * @q_slices: Number of queue engines
- * @q_proxies: Number of queue proxies per page
* @data_first_reg: First data register for proxy data region
* @data_last_reg: Last data register for proxy data region
* @tx_polled: Do I need to use polled mechanism for tx
@@ -58,8 +56,6 @@ struct ti_msgmgr_desc {
u8 queue_count;
u8 max_message_size;
u8 max_messages;
- u8 q_slices;
- u8 q_proxies;
u8 data_first_reg;
u8 data_last_reg;
bool tx_polled;
@@ -494,8 +490,6 @@ static const struct ti_msgmgr_desc k2g_desc = {
.queue_count = 64,
.max_message_size = 64,
.max_messages = 128,
- .q_slices = 1,
- .q_proxies = 1,
.data_first_reg = 16,
.data_last_reg = 31,
.tx_polled = false,
--
2.15.1
^ permalink raw reply related
* [RFC PATCH 2/8] mailbox: ti-msgmgr: Allocate Rx channel resources only on request
From: Nishanth Menon @ 2018-06-05 6:16 UTC (permalink / raw)
To: Jassi Brar, Rob Herring
Cc: linux-arm-kernel, linux-kernel, devicetree, Nishanth Menon,
Tero Kristo, Suman Anna
In-Reply-To: <20180605061629.4759-1-nm@ti.com>
In a much bigger system SoCs, the number of Rx channels can be
many and mostly unused based on the system of choice, and not all
Rx channels need IRQs and allocating all memory at probe will be
inefficient. Some SoCs could have total threads in the 100s and usage
would be just 1 Rx thread.
Thus, request and map the IRQs and allocate memory only when needed.
Since these channels are requested by client drivers on need, our
utilization will be optimal.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
drivers/mailbox/ti-msgmgr.c | 91 ++++++++++++++++++++++++++++++---------------
1 file changed, 61 insertions(+), 30 deletions(-)
diff --git a/drivers/mailbox/ti-msgmgr.c b/drivers/mailbox/ti-msgmgr.c
index 7cd5f9c9c97f..7221590c409c 100644
--- a/drivers/mailbox/ti-msgmgr.c
+++ b/drivers/mailbox/ti-msgmgr.c
@@ -310,6 +310,51 @@ static int ti_msgmgr_send_data(struct mbox_chan *chan, void *data)
return 0;
}
+/**
+ * ti_msgmgr_queue_rx_irq_req() - RX IRQ request
+ * @dev: device pointer
+ * @qinst: Queue instance
+ * @chan: Channel pointer
+ */
+static int ti_msgmgr_queue_rx_irq_req(struct device *dev,
+ struct ti_queue_inst *qinst,
+ struct mbox_chan *chan)
+{
+ int ret = 0;
+ char of_rx_irq_name[7];
+ struct device_node *np;
+
+ snprintf(of_rx_irq_name, sizeof(of_rx_irq_name),
+ "rx_%03d", qinst->queue_id);
+
+ /* Get the IRQ if not found */
+ if (qinst->irq < 0) {
+ np = of_node_get(dev->of_node);
+ if (!np)
+ return -ENODATA;
+ qinst->irq = of_irq_get_byname(np, of_rx_irq_name);
+ of_node_put(np);
+
+ if (qinst->irq < 0) {
+ dev_err(dev,
+ "QID %d PID %d:No IRQ[%s]: %d\n",
+ qinst->queue_id, qinst->proxy_id,
+ of_rx_irq_name, qinst->irq);
+ return qinst->irq;
+ }
+ }
+
+ /* With the expectation that the IRQ might be shared in SoC */
+ ret = request_irq(qinst->irq, ti_msgmgr_queue_rx_interrupt,
+ IRQF_SHARED, qinst->name, chan);
+ if (ret) {
+ dev_err(dev, "Unable to get IRQ %d on %s(res=%d)\n",
+ qinst->irq, qinst->name, ret);
+ }
+
+ return ret;
+}
+
/**
* ti_msgmgr_queue_startup() - Startup queue
* @chan: Channel pointer
@@ -318,19 +363,21 @@ static int ti_msgmgr_send_data(struct mbox_chan *chan, void *data)
*/
static int ti_msgmgr_queue_startup(struct mbox_chan *chan)
{
- struct ti_queue_inst *qinst = chan->con_priv;
struct device *dev = chan->mbox->dev;
+ struct ti_msgmgr_inst *inst = dev_get_drvdata(dev);
+ struct ti_queue_inst *qinst = chan->con_priv;
+ const struct ti_msgmgr_desc *d = inst->desc;
int ret;
if (!qinst->is_tx) {
- /*
- * With the expectation that the IRQ might be shared in SoC
- */
- ret = request_irq(qinst->irq, ti_msgmgr_queue_rx_interrupt,
- IRQF_SHARED, qinst->name, chan);
+ /* Allocate usage buffer for rx */
+ qinst->rx_buff = kzalloc(d->max_message_size, GFP_KERNEL);
+ if (!qinst->rx_buff)
+ return -ENOMEM;
+ /* Request IRQ */
+ ret = ti_msgmgr_queue_rx_irq_req(dev, qinst, chan);
if (ret) {
- dev_err(dev, "Unable to get IRQ %d on %s(res=%d)\n",
- qinst->irq, qinst->name, ret);
+ kfree(qinst->rx_buff);
return ret;
}
}
@@ -346,8 +393,10 @@ static void ti_msgmgr_queue_shutdown(struct mbox_chan *chan)
{
struct ti_queue_inst *qinst = chan->con_priv;
- if (!qinst->is_tx)
+ if (!qinst->is_tx) {
free_irq(qinst->irq, chan);
+ kfree(qinst->rx_buff);
+ }
}
/**
@@ -425,27 +474,6 @@ static int ti_msgmgr_queue_setup(int idx, struct device *dev,
dev_name(dev), qinst->is_tx ? "tx" : "rx", qinst->queue_id,
qinst->proxy_id);
- if (!qinst->is_tx) {
- char of_rx_irq_name[7];
-
- snprintf(of_rx_irq_name, sizeof(of_rx_irq_name),
- "rx_%03d", qinst->queue_id);
-
- qinst->irq = of_irq_get_byname(np, of_rx_irq_name);
- if (qinst->irq < 0) {
- dev_crit(dev,
- "[%d]QID %d PID %d:No IRQ[%s]: %d\n",
- idx, qinst->queue_id, qinst->proxy_id,
- of_rx_irq_name, qinst->irq);
- return qinst->irq;
- }
- /* Allocate usage buffer for rx */
- qinst->rx_buff = devm_kzalloc(dev,
- d->max_message_size, GFP_KERNEL);
- if (!qinst->rx_buff)
- return -ENOMEM;
- }
-
qinst->queue_buff_start = inst->queue_proxy_region +
Q_DATA_OFFSET(qinst->proxy_id, qinst->queue_id, d->data_first_reg);
qinst->queue_buff_end = inst->queue_proxy_region +
@@ -454,6 +482,9 @@ static int ti_msgmgr_queue_setup(int idx, struct device *dev,
Q_STATE_OFFSET(qinst->queue_id);
qinst->chan = chan;
+ /* Setup an error value for IRQ - Lazy allocation */
+ qinst->irq = -EINVAL;
+
chan->con_priv = qinst;
dev_dbg(dev, "[%d] qidx=%d pidx=%d irq=%d q_s=%p q_e = %p\n",
--
2.15.1
^ permalink raw reply related
* [RFC PATCH 3/8] mailbox: ti-msgmgr: Change message count mask to be descriptor based
From: Nishanth Menon @ 2018-06-05 6:16 UTC (permalink / raw)
To: Jassi Brar, Rob Herring
Cc: linux-arm-kernel, linux-kernel, devicetree, Nishanth Menon,
Tero Kristo, Suman Anna
In-Reply-To: <20180605061629.4759-1-nm@ti.com>
Change mask used to extract the message count to be descriptor based.
This is to support changes for count location for various SoC
solutions.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
drivers/mailbox/ti-msgmgr.c | 25 ++++++++++++++++++-------
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/mailbox/ti-msgmgr.c b/drivers/mailbox/ti-msgmgr.c
index 7221590c409c..2952339a8446 100644
--- a/drivers/mailbox/ti-msgmgr.c
+++ b/drivers/mailbox/ti-msgmgr.c
@@ -44,6 +44,7 @@ struct ti_msgmgr_valid_queue_desc {
* @max_messages: Number of messages
* @data_first_reg: First data register for proxy data region
* @data_last_reg: Last data register for proxy data region
+ * @status_cnt_mask: Mask for getting the status value
* @tx_polled: Do I need to use polled mechanism for tx
* @tx_poll_timeout_ms: Timeout in ms if polled
* @valid_queues: List of Valid queues that the processor can access
@@ -58,6 +59,7 @@ struct ti_msgmgr_desc {
u8 max_messages;
u8 data_first_reg;
u8 data_last_reg;
+ u32 status_cnt_mask;
bool tx_polled;
int tx_poll_timeout_ms;
const struct ti_msgmgr_valid_queue_desc *valid_queues;
@@ -116,20 +118,24 @@ struct ti_msgmgr_inst {
/**
* ti_msgmgr_queue_get_num_messages() - Get the number of pending messages
+ * @d: Description of message manager
* @qinst: Queue instance for which we check the number of pending messages
*
* Return: number of messages pending in the queue (0 == no pending messages)
*/
-static inline int ti_msgmgr_queue_get_num_messages(struct ti_queue_inst *qinst)
+static inline int
+ti_msgmgr_queue_get_num_messages(const struct ti_msgmgr_desc *d,
+ struct ti_queue_inst *qinst)
{
u32 val;
+ u32 status_cnt_mask = d->status_cnt_mask;
/*
* We cannot use relaxed operation here - update may happen
* real-time.
*/
- val = readl(qinst->queue_state) & Q_STATE_ENTRY_COUNT_MASK;
- val >>= __ffs(Q_STATE_ENTRY_COUNT_MASK);
+ val = readl(qinst->queue_state) & status_cnt_mask;
+ val >>= __ffs(status_cnt_mask);
return val;
}
@@ -167,8 +173,9 @@ static irqreturn_t ti_msgmgr_queue_rx_interrupt(int irq, void *p)
return IRQ_NONE;
}
+ desc = inst->desc;
/* Do I actually have messages to read? */
- msg_count = ti_msgmgr_queue_get_num_messages(qinst);
+ msg_count = ti_msgmgr_queue_get_num_messages(desc, qinst);
if (!msg_count) {
/* Shared IRQ? */
dev_dbg(dev, "Spurious event - 0 pending data!\n");
@@ -181,7 +188,6 @@ static irqreturn_t ti_msgmgr_queue_rx_interrupt(int irq, void *p)
* of how many bytes I should be reading. Let the client figure this
* out.. I just read the full message and pass it on..
*/
- desc = inst->desc;
message.len = desc->max_message_size;
message.buf = (u8 *)qinst->rx_buff;
@@ -224,12 +230,14 @@ static irqreturn_t ti_msgmgr_queue_rx_interrupt(int irq, void *p)
static bool ti_msgmgr_queue_peek_data(struct mbox_chan *chan)
{
struct ti_queue_inst *qinst = chan->con_priv;
+ struct device *dev = chan->mbox->dev;
+ struct ti_msgmgr_inst *inst = dev_get_drvdata(dev);
int msg_count;
if (qinst->is_tx)
return false;
- msg_count = ti_msgmgr_queue_get_num_messages(qinst);
+ msg_count = ti_msgmgr_queue_get_num_messages(inst->desc, qinst);
return msg_count ? true : false;
}
@@ -243,12 +251,14 @@ static bool ti_msgmgr_queue_peek_data(struct mbox_chan *chan)
static bool ti_msgmgr_last_tx_done(struct mbox_chan *chan)
{
struct ti_queue_inst *qinst = chan->con_priv;
+ struct device *dev = chan->mbox->dev;
+ struct ti_msgmgr_inst *inst = dev_get_drvdata(dev);
int msg_count;
if (!qinst->is_tx)
return false;
- msg_count = ti_msgmgr_queue_get_num_messages(qinst);
+ msg_count = ti_msgmgr_queue_get_num_messages(inst->desc, qinst);
/* if we have any messages pending.. */
return msg_count ? false : true;
@@ -523,6 +533,7 @@ static const struct ti_msgmgr_desc k2g_desc = {
.max_messages = 128,
.data_first_reg = 16,
.data_last_reg = 31,
+ .status_cnt_mask = Q_STATE_ENTRY_COUNT_MASK,
.tx_polled = false,
.valid_queues = k2g_valid_queues,
.num_valid_queues = ARRAY_SIZE(k2g_valid_queues),
--
2.15.1
^ permalink raw reply related
* [RFC PATCH 4/8] mailbox: ti-msgmgr: Move the memory region name to descriptor
From: Nishanth Menon @ 2018-06-05 6:16 UTC (permalink / raw)
To: Jassi Brar, Rob Herring
Cc: Nishanth Menon, devicetree, linux-kernel, Tero Kristo,
linux-arm-kernel
In-Reply-To: <20180605061629.4759-1-nm@ti.com>
For newer generation of the hardware, the naming of the region is
decided at integration level and there could be additional regions
as well. Hence move the region naming to be described from compatible
descriptor.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
drivers/mailbox/ti-msgmgr.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/mailbox/ti-msgmgr.c b/drivers/mailbox/ti-msgmgr.c
index 2952339a8446..a37d6a4b392f 100644
--- a/drivers/mailbox/ti-msgmgr.c
+++ b/drivers/mailbox/ti-msgmgr.c
@@ -48,6 +48,8 @@ struct ti_msgmgr_valid_queue_desc {
* @tx_polled: Do I need to use polled mechanism for tx
* @tx_poll_timeout_ms: Timeout in ms if polled
* @valid_queues: List of Valid queues that the processor can access
+ * @data_region_name: Name of the proxy data region
+ * @status_region_name: Name of the proxy status region
* @num_valid_queues: Number of valid queues
*
* This structure is used in of match data to describe how integration
@@ -63,6 +65,8 @@ struct ti_msgmgr_desc {
bool tx_polled;
int tx_poll_timeout_ms;
const struct ti_msgmgr_valid_queue_desc *valid_queues;
+ const char *data_region_name;
+ const char *status_region_name;
int num_valid_queues;
};
@@ -531,6 +535,8 @@ static const struct ti_msgmgr_desc k2g_desc = {
.queue_count = 64,
.max_message_size = 64,
.max_messages = 128,
+ .data_region_name = "queue_proxy_region",
+ .status_region_name = "queue_state_debug_region",
.data_first_reg = 16,
.data_last_reg = 31,
.status_cnt_mask = Q_STATE_ENTRY_COUNT_MASK,
@@ -582,13 +588,13 @@ static int ti_msgmgr_probe(struct platform_device *pdev)
inst->desc = desc;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
- "queue_proxy_region");
+ desc->data_region_name);
inst->queue_proxy_region = devm_ioremap_resource(dev, res);
if (IS_ERR(inst->queue_proxy_region))
return PTR_ERR(inst->queue_proxy_region);
res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
- "queue_state_debug_region");
+ desc->status_region_name);
inst->queue_state_debug_region = devm_ioremap_resource(dev, res);
if (IS_ERR(inst->queue_state_debug_region))
return PTR_ERR(inst->queue_state_debug_region);
--
2.15.1
^ permalink raw reply related
* [RFC PATCH 5/8] dt-bindings: mailbox: ti,message-manager: Add support for secure proxy threads
From: Nishanth Menon @ 2018-06-05 6:16 UTC (permalink / raw)
To: Jassi Brar, Rob Herring
Cc: linux-arm-kernel, linux-kernel, devicetree, Nishanth Menon,
Tero Kristo, Suman Anna
In-Reply-To: <20180605061629.4759-1-nm@ti.com>
Secure Proxy is another communication scheme in Texas Instrument's
devices intended to provide an unique communication path from various
processors in the System on Chip(SoC) to a central System Controller.
Secure proxy is, in effect, an evolution of current generation Message
Manager hardware block found in K2G devices. However the following
changes have taken place:
Secure Proxy instance exposes "threads" or "proxies" which is
primary representation of "a" communication channel. Each thread is
preconfigured by System controller configuration based on SoC usage
requirements. Secure proxy by itself represents a single "queue" of
communication but allows the proxies to be independently operated.
Each Secure proxy thread can uniquely have their own error and threshold
interrupts allowing for more fine control of IRQ handling.
Provide an hardware description of the same for device tree
representation.
See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7
Signed-off-by: Nishanth Menon <nm@ti.com>
---
.../bindings/mailbox/ti,message-manager.txt | 58 +++++++++++++++++++---
1 file changed, 50 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
index ebf0e3710cee..de796e90cac6 100644
--- a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
+++ b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
@@ -7,22 +7,40 @@ manager is broken up into queues in different address regions that are called
"proxies" - each instance is unidirectional and is instantiated at SoC
integration level to indicate receive or transmit path.
+This can also be used to describe Texas Instrument's Secure Proxy
+controller that allows for individually configurable "threads" or
+"proxies" which allow for independent communication scheme.
+
Message Manager Device Node:
===========================
Required properties:
--------------------
-- compatible: Shall be: "ti,k2g-message-manager"
-- reg-names queue_proxy_region - Map the queue proxy region.
- queue_state_debug_region - Map the queue state debug
- region.
+- compatible: Shall be one of: "ti,k2g-message-manager",
+ "ti,am654-secure-proxy"
+- reg-names for ti,k2g-message-manager, the following shall exist:
+ queue_proxy_region - Map the queue proxy region.
+ queue_state_debug_region - Map the queue state
+ debug region.
+ for ti,am654-secure-proxy, the following shall exist:
+ target_data - Map the proxy data region
+ rt - Map the realtime status region
+ scfg - Map the configuration region
- reg: Contains the register map per reg-names.
-- #mbox-cells Shall be 2. Contains the queue ID and proxy ID in that
- order referring to the transfer path.
+- #mbox-cells for ti,k2g-message-manager, Shall be 2. Contains the
+ queue ID and proxy ID in the following order referring
+ to the transfer path:
+ queue_proxy_region - Map the queue proxy region.
+ queue_state_debug_region - Map the queue state
+ debug region.
+ for ti,am654-secure-proxy, Shall be 1 and shall refer
+ to the transfer path called thread.
- interrupt-names: Contains interrupt names matching the rx transfer path
for a given SoC. Receive interrupts shall be of the
- format: "rx_<QID>".
- For ti,k2g-message-manager, this shall contain:
+ format:
+ For ti,k2g-message-manager, this shall be: "rx_<QID>"
+ and shall contain:
"rx_005", "rx_057"
+ for ti,am654-secure-proxy, this shall be: "rx_<PID>".
- interrupts: Contains the interrupt information corresponding to
interrupt-names property.
@@ -48,3 +66,27 @@ Example(K2G):
<&msgmgr 0 0>;
[...]
};
+
+Example(AM654):
+------------
+
+ secure_proxy: secure_proxy@32c00000 {
+ compatible = "ti,am654-secure-proxy";
+ #mbox-cells = <1>;
+ reg-names = "target_data", "rt", "scfg";
+ reg = <0x0 0x32c00000 0x0 0x100000>,
+ <0x0 0x32400000 0x0 0x100000>,
+ <0x0 0x32800000 0x0 0x100000>;
+ interrupt-names = "rx_011";
+ interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ dmsc: dmsc {
+ [...]
+ mbox-names = "rx", "tx";
+ # RX Thread ID is 11
+ # TX Thread ID is 13
+ mboxes= <&secure_proxy 11>,
+ <&secure_proxy 13>;
+ [...]
+ };
--
2.15.1
^ permalink raw reply related
* [RFC PATCH 6/8] mailbox: ti-msgmgr: Add support for Secure Proxy
From: Nishanth Menon @ 2018-06-05 6:16 UTC (permalink / raw)
To: Jassi Brar, Rob Herring
Cc: linux-arm-kernel, linux-kernel, devicetree, Nishanth Menon,
Tero Kristo, Suman Anna
In-Reply-To: <20180605061629.4759-1-nm@ti.com>
Secure Proxy is another communication scheme in Texas Instrument's
devices intended to provide an unique communication path from various
processors in the System on Chip(SoC) to a central System Controller.
Secure proxy is, in effect, an evolution of current generation Message
Manager hardware block found in K2G devices. However the following
changes have taken place:
Secure Proxy instance exposes "threads" or "proxies" which is
primary representation of "a" communication channel. Each thread is
preconfigured by System controller configuration based on SoC usage
requirements. Secure proxy by itself represents a single "queue" of
communication but allows the proxies to be independently operated.
Each Secure proxy thread can uniquely have their own error and threshold
interrupts allowing for more fine control of IRQ handling.
Provide the driver support for Secure Proxy and thread instances.
NOTE: Secure proxy configuration is only done by System Controller,
hence these are assumed to be pre-configured instances.
See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7
Signed-off-by: Nishanth Menon <nm@ti.com>
---
drivers/mailbox/ti-msgmgr.c | 233 ++++++++++++++++++++++++++++++++++++++------
1 file changed, 205 insertions(+), 28 deletions(-)
diff --git a/drivers/mailbox/ti-msgmgr.c b/drivers/mailbox/ti-msgmgr.c
index a37d6a4b392f..3e30b80c6401 100644
--- a/drivers/mailbox/ti-msgmgr.c
+++ b/drivers/mailbox/ti-msgmgr.c
@@ -25,6 +25,17 @@
#define Q_STATE_OFFSET(queue) ((queue) * 0x4)
#define Q_STATE_ENTRY_COUNT_MASK (0xFFF000)
+#define SPROXY_THREAD_OFFSET(tid) (0x1000 * (tid))
+#define SPROXY_THREAD_DATA_OFFSET(tid, reg) \
+ (SPROXY_THREAD_OFFSET(tid) + ((reg) * 0x4) + 0x4)
+
+#define SPROXY_THREAD_STATUS_OFFSET(tid) (SPROXY_THREAD_OFFSET(tid))
+
+#define SPROXY_THREAD_STATUS_COUNT_MASK (0xFF)
+
+#define SPROXY_THREAD_CTRL_OFFSET(tid) (0x1000 + SPROXY_THREAD_OFFSET(tid))
+#define SPROXY_THREAD_CTRL_DIR_MASK (0x1 << 31)
+
/**
* struct ti_msgmgr_valid_queue_desc - SoC valid queues meant for this processor
* @queue_id: Queue Number for this path
@@ -45,12 +56,15 @@ struct ti_msgmgr_valid_queue_desc {
* @data_first_reg: First data register for proxy data region
* @data_last_reg: Last data register for proxy data region
* @status_cnt_mask: Mask for getting the status value
+ * @status_err_mask: Mask for getting the error value, if applicable
* @tx_polled: Do I need to use polled mechanism for tx
* @tx_poll_timeout_ms: Timeout in ms if polled
* @valid_queues: List of Valid queues that the processor can access
* @data_region_name: Name of the proxy data region
* @status_region_name: Name of the proxy status region
+ * @ctrl_region_name: Name of the proxy control region
* @num_valid_queues: Number of valid queues
+ * @is_sproxy: Is this an Secure Proxy instance?
*
* This structure is used in of match data to describe how integration
* for a specific compatible SoC is done.
@@ -62,12 +76,15 @@ struct ti_msgmgr_desc {
u8 data_first_reg;
u8 data_last_reg;
u32 status_cnt_mask;
+ u32 status_err_mask;
bool tx_polled;
int tx_poll_timeout_ms;
const struct ti_msgmgr_valid_queue_desc *valid_queues;
const char *data_region_name;
const char *status_region_name;
+ const char *ctrl_region_name;
int num_valid_queues;
+ bool is_sproxy;
};
/**
@@ -80,6 +97,7 @@ struct ti_msgmgr_desc {
* @queue_buff_start: First register of Data Buffer
* @queue_buff_end: Last (or confirmation) register of Data buffer
* @queue_state: Queue status register
+ * @queue_ctrl: Queue Control register
* @chan: Mailbox channel
* @rx_buff: Receive buffer pointer allocated at probe, max_message_size
*/
@@ -92,6 +110,7 @@ struct ti_queue_inst {
void __iomem *queue_buff_start;
void __iomem *queue_buff_end;
void __iomem *queue_state;
+ void __iomem *queue_ctrl;
struct mbox_chan *chan;
u32 *rx_buff;
};
@@ -102,6 +121,7 @@ struct ti_queue_inst {
* @desc: Description of the SoC integration
* @queue_proxy_region: Queue proxy region where queue buffers are located
* @queue_state_debug_region: Queue status register regions
+ * @queue_ctrl_region: Queue Control register regions
* @num_valid_queues: Number of valid queues defined for the processor
* Note: other queues are probably reserved for other processors
* in the SoC.
@@ -114,6 +134,7 @@ struct ti_msgmgr_inst {
const struct ti_msgmgr_desc *desc;
void __iomem *queue_proxy_region;
void __iomem *queue_state_debug_region;
+ void __iomem *queue_ctrl_region;
u8 num_valid_queues;
struct ti_queue_inst *qinsts;
struct mbox_controller mbox;
@@ -144,6 +165,31 @@ ti_msgmgr_queue_get_num_messages(const struct ti_msgmgr_desc *d,
return val;
}
+/**
+ * ti_msgmgr_queue_is_error() - Check to see if there is queue error
+ * @d: Description of message manager
+ * @qinst: Queue instance for which we check the number of pending messages
+ *
+ * Return: true if error, else false
+ */
+static inline bool ti_msgmgr_queue_is_error(const struct ti_msgmgr_desc *d,
+ struct ti_queue_inst *qinst)
+{
+ u32 val;
+
+ /* Msgmgr has no error detection */
+ if (!d->is_sproxy)
+ return false;
+
+ /*
+ * We cannot use relaxed operation here - update may happen
+ * real-time.
+ */
+ val = readl(qinst->queue_state) & d->status_err_mask;
+
+ return val ? true : false;
+}
+
/**
* ti_msgmgr_queue_rx_interrupt() - Interrupt handler for receive Queue
* @irq: Interrupt number
@@ -178,6 +224,11 @@ static irqreturn_t ti_msgmgr_queue_rx_interrupt(int irq, void *p)
}
desc = inst->desc;
+ if (ti_msgmgr_queue_is_error(desc, qinst)) {
+ dev_err(dev, "Error on Rx channel %s\n", qinst->name);
+ return IRQ_NONE;
+ }
+
/* Do I actually have messages to read? */
msg_count = ti_msgmgr_queue_get_num_messages(desc, qinst);
if (!msg_count) {
@@ -236,12 +287,18 @@ static bool ti_msgmgr_queue_peek_data(struct mbox_chan *chan)
struct ti_queue_inst *qinst = chan->con_priv;
struct device *dev = chan->mbox->dev;
struct ti_msgmgr_inst *inst = dev_get_drvdata(dev);
+ const struct ti_msgmgr_desc *desc = inst->desc;
int msg_count;
if (qinst->is_tx)
return false;
- msg_count = ti_msgmgr_queue_get_num_messages(inst->desc, qinst);
+ if (ti_msgmgr_queue_is_error(desc, qinst)) {
+ dev_err(dev, "Error on channel %s\n", qinst->name);
+ return false;
+ }
+
+ msg_count = ti_msgmgr_queue_get_num_messages(desc, qinst);
return msg_count ? true : false;
}
@@ -257,12 +314,23 @@ static bool ti_msgmgr_last_tx_done(struct mbox_chan *chan)
struct ti_queue_inst *qinst = chan->con_priv;
struct device *dev = chan->mbox->dev;
struct ti_msgmgr_inst *inst = dev_get_drvdata(dev);
+ const struct ti_msgmgr_desc *desc = inst->desc;
int msg_count;
if (!qinst->is_tx)
return false;
- msg_count = ti_msgmgr_queue_get_num_messages(inst->desc, qinst);
+ if (ti_msgmgr_queue_is_error(desc, qinst)) {
+ dev_err(dev, "Error on channel %s\n", qinst->name);
+ return false;
+ }
+
+ msg_count = ti_msgmgr_queue_get_num_messages(desc, qinst);
+
+ if (desc->is_sproxy) {
+ /* In secure proxy, msg_count indicates how many we can send */
+ return msg_count ? true : false;
+ }
/* if we have any messages pending.. */
return msg_count ? false : true;
@@ -292,6 +360,11 @@ static int ti_msgmgr_send_data(struct mbox_chan *chan, void *data)
}
desc = inst->desc;
+ if (ti_msgmgr_queue_is_error(desc, qinst)) {
+ dev_err(dev, "Error on channel %s\n", qinst->name);
+ return false;
+ }
+
if (desc->max_message_size < message->len) {
dev_err(dev, "Queue %s message length %zu > max %d\n",
qinst->name, message->len, desc->max_message_size);
@@ -327,10 +400,12 @@ static int ti_msgmgr_send_data(struct mbox_chan *chan, void *data)
/**
* ti_msgmgr_queue_rx_irq_req() - RX IRQ request
* @dev: device pointer
+ * @d: descriptor for ti_msgmgr
* @qinst: Queue instance
* @chan: Channel pointer
*/
static int ti_msgmgr_queue_rx_irq_req(struct device *dev,
+ const struct ti_msgmgr_desc *d,
struct ti_queue_inst *qinst,
struct mbox_chan *chan)
{
@@ -339,7 +414,7 @@ static int ti_msgmgr_queue_rx_irq_req(struct device *dev,
struct device_node *np;
snprintf(of_rx_irq_name, sizeof(of_rx_irq_name),
- "rx_%03d", qinst->queue_id);
+ "rx_%03d", d->is_sproxy ? qinst->proxy_id : qinst->queue_id);
/* Get the IRQ if not found */
if (qinst->irq < 0) {
@@ -382,6 +457,24 @@ static int ti_msgmgr_queue_startup(struct mbox_chan *chan)
struct ti_queue_inst *qinst = chan->con_priv;
const struct ti_msgmgr_desc *d = inst->desc;
int ret;
+ int msg_count;
+
+ /*
+ * If sproxy is starting and can send messages, we are a Tx thread,
+ * else Rx
+ */
+ if (d->is_sproxy) {
+ qinst->is_tx = (readl(qinst->queue_ctrl) &
+ SPROXY_THREAD_CTRL_DIR_MASK) ? false : true;
+
+ msg_count = ti_msgmgr_queue_get_num_messages(d, qinst);
+
+ if (!msg_count && qinst->is_tx) {
+ dev_err(dev, "%s: Cannot transmit with 0 credits!\n",
+ qinst->name);
+ return -EINVAL;
+ }
+ }
if (!qinst->is_tx) {
/* Allocate usage buffer for rx */
@@ -389,7 +482,7 @@ static int ti_msgmgr_queue_startup(struct mbox_chan *chan)
if (!qinst->rx_buff)
return -ENOMEM;
/* Request IRQ */
- ret = ti_msgmgr_queue_rx_irq_req(dev, qinst, chan);
+ ret = ti_msgmgr_queue_rx_irq_req(dev, d, qinst, chan);
if (ret) {
kfree(qinst->rx_buff);
return ret;
@@ -427,20 +520,38 @@ static struct mbox_chan *ti_msgmgr_of_xlate(struct mbox_controller *mbox,
struct ti_msgmgr_inst *inst;
int req_qid, req_pid;
struct ti_queue_inst *qinst;
- int i;
+ const struct ti_msgmgr_desc *d;
+ int i, ncells;
inst = container_of(mbox, struct ti_msgmgr_inst, mbox);
if (WARN_ON(!inst))
return ERR_PTR(-EINVAL);
- /* #mbox-cells is 2 */
- if (p->args_count != 2) {
- dev_err(inst->dev, "Invalid arguments in dt[%d] instead of 2\n",
- p->args_count);
+ d = inst->desc;
+
+ if (d->is_sproxy)
+ ncells = 1;
+ else
+ ncells = 2;
+ if (p->args_count != ncells) {
+ dev_err(inst->dev, "Invalid arguments in dt[%d]. Must be %d\n",
+ p->args_count, ncells);
return ERR_PTR(-EINVAL);
}
- req_qid = p->args[0];
- req_pid = p->args[1];
+ if (ncells == 1) {
+ req_qid = 0;
+ req_pid = p->args[0];
+ } else {
+ req_qid = p->args[0];
+ req_pid = p->args[1];
+ }
+
+ if (d->is_sproxy) {
+ if (req_pid > d->num_valid_queues)
+ goto err;
+ qinst = &inst->qinsts[req_pid];
+ return qinst->chan;
+ }
for (qinst = inst->qinsts, i = 0; i < inst->num_valid_queues;
i++, qinst++) {
@@ -448,6 +559,7 @@ static struct mbox_chan *ti_msgmgr_of_xlate(struct mbox_controller *mbox,
return qinst->chan;
}
+err:
dev_err(inst->dev, "Queue ID %d, Proxy ID %d is wrong on %s\n",
req_qid, req_pid, p->np->name);
return ERR_PTR(-ENOENT);
@@ -474,6 +586,8 @@ static int ti_msgmgr_queue_setup(int idx, struct device *dev,
struct ti_queue_inst *qinst,
struct mbox_chan *chan)
{
+ char *dir;
+
qinst->proxy_id = qd->proxy_id;
qinst->queue_id = qd->queue_id;
@@ -483,17 +597,38 @@ static int ti_msgmgr_queue_setup(int idx, struct device *dev,
return -ERANGE;
}
- qinst->is_tx = qd->is_tx;
- snprintf(qinst->name, sizeof(qinst->name), "%s %s_%03d_%03d",
- dev_name(dev), qinst->is_tx ? "tx" : "rx", qinst->queue_id,
- qinst->proxy_id);
-
- qinst->queue_buff_start = inst->queue_proxy_region +
- Q_DATA_OFFSET(qinst->proxy_id, qinst->queue_id, d->data_first_reg);
- qinst->queue_buff_end = inst->queue_proxy_region +
- Q_DATA_OFFSET(qinst->proxy_id, qinst->queue_id, d->data_last_reg);
- qinst->queue_state = inst->queue_state_debug_region +
- Q_STATE_OFFSET(qinst->queue_id);
+ if (d->is_sproxy) {
+ qinst->queue_buff_start = inst->queue_proxy_region +
+ SPROXY_THREAD_DATA_OFFSET(qinst->proxy_id,
+ d->data_first_reg);
+ qinst->queue_buff_end = inst->queue_proxy_region +
+ SPROXY_THREAD_DATA_OFFSET(qinst->proxy_id,
+ d->data_last_reg);
+ qinst->queue_state = inst->queue_state_debug_region +
+ SPROXY_THREAD_STATUS_OFFSET(qinst->proxy_id);
+ qinst->queue_ctrl = inst->queue_ctrl_region +
+ SPROXY_THREAD_CTRL_OFFSET(qinst->proxy_id);
+
+ /* XXX: DONOT read registers here!.. Some may be unusable */
+ dir = "thr";
+ snprintf(qinst->name, sizeof(qinst->name), "%s %s_%03d",
+ dev_name(dev), dir, qinst->proxy_id);
+ } else {
+ qinst->queue_buff_start = inst->queue_proxy_region +
+ Q_DATA_OFFSET(qinst->proxy_id, qinst->queue_id,
+ d->data_first_reg);
+ qinst->queue_buff_end = inst->queue_proxy_region +
+ Q_DATA_OFFSET(qinst->proxy_id, qinst->queue_id,
+ d->data_last_reg);
+ qinst->queue_state =
+ inst->queue_state_debug_region +
+ Q_STATE_OFFSET(qinst->queue_id);
+ qinst->is_tx = qd->is_tx;
+ dir = qinst->is_tx ? "tx" : "rx";
+ snprintf(qinst->name, sizeof(qinst->name), "%s %s_%03d_%03d",
+ dev_name(dev), dir, qinst->queue_id, qinst->proxy_id);
+ }
+
qinst->chan = chan;
/* Setup an error value for IRQ - Lazy allocation */
@@ -543,12 +678,29 @@ static const struct ti_msgmgr_desc k2g_desc = {
.tx_polled = false,
.valid_queues = k2g_valid_queues,
.num_valid_queues = ARRAY_SIZE(k2g_valid_queues),
+ .is_sproxy = false,
+};
+
+static const struct ti_msgmgr_desc am654_desc = {
+ .queue_count = 190,
+ .num_valid_queues = 190,
+ .max_message_size = 60,
+ .data_region_name = "target_data",
+ .status_region_name = "rt",
+ .ctrl_region_name = "scfg",
+ .data_first_reg = 0,
+ .data_last_reg = 14,
+ .status_cnt_mask = SPROXY_THREAD_STATUS_COUNT_MASK,
+ .tx_polled = false,
+ .is_sproxy = true,
};
static const struct of_device_id ti_msgmgr_of_match[] = {
{.compatible = "ti,k2g-message-manager", .data = &k2g_desc},
+ {.compatible = "ti,am654-secure-proxy", .data = &am654_desc},
{ /* Sentinel */ }
};
+
MODULE_DEVICE_TABLE(of, ti_msgmgr_of_match);
static int ti_msgmgr_probe(struct platform_device *pdev)
@@ -599,6 +751,14 @@ static int ti_msgmgr_probe(struct platform_device *pdev)
if (IS_ERR(inst->queue_state_debug_region))
return PTR_ERR(inst->queue_state_debug_region);
+ if (desc->is_sproxy) {
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+ desc->ctrl_region_name);
+ inst->queue_ctrl_region = devm_ioremap_resource(dev, res);
+ if (IS_ERR(inst->queue_ctrl_region))
+ return PTR_ERR(inst->queue_ctrl_region);
+ }
+
dev_dbg(dev, "proxy region=%p, queue_state=%p\n",
inst->queue_proxy_region, inst->queue_state_debug_region);
@@ -620,12 +780,29 @@ static int ti_msgmgr_probe(struct platform_device *pdev)
return -ENOMEM;
inst->chans = chans;
- for (i = 0, queue_desc = desc->valid_queues;
- i < queue_count; i++, qinst++, chans++, queue_desc++) {
- ret = ti_msgmgr_queue_setup(i, dev, np, inst,
- desc, queue_desc, qinst, chans);
- if (ret)
- return ret;
+ if (desc->is_sproxy) {
+ struct ti_msgmgr_valid_queue_desc sproxy_desc;
+
+ /* All proxies may be valid in Secure Proxy instance */
+ for (i = 0; i < queue_count; i++, qinst++, chans++) {
+ sproxy_desc.queue_id = 0;
+ sproxy_desc.proxy_id = i;
+ ret = ti_msgmgr_queue_setup(i, dev, np, inst,
+ desc, &sproxy_desc, qinst,
+ chans);
+ if (ret)
+ return ret;
+ }
+ } else {
+ /* Only Some proxies are valid in Message Manager */
+ for (i = 0, queue_desc = desc->valid_queues;
+ i < queue_count; i++, qinst++, chans++, queue_desc++) {
+ ret = ti_msgmgr_queue_setup(i, dev, np, inst,
+ desc, queue_desc, qinst,
+ chans);
+ if (ret)
+ return ret;
+ }
}
mbox = &inst->mbox;
--
2.15.1
^ permalink raw reply related
* [RFC PATCH 7/8] drivers: mailbox: Make ti-msgmr driver depend on ARCH_K3
From: Nishanth Menon @ 2018-06-05 6:16 UTC (permalink / raw)
To: Jassi Brar, Rob Herring
Cc: linux-arm-kernel, linux-kernel, devicetree, Nishanth Menon,
Tero Kristo, Suman Anna
In-Reply-To: <20180605061629.4759-1-nm@ti.com>
ti-msgmr driver can support K3 platforms as well.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
drivers/mailbox/Kconfig | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 725dce5ba62d..f87a857d21a5 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -99,12 +99,12 @@ config STI_MBOX
config TI_MESSAGE_MANAGER
tristate "Texas Instruments Message Manager Driver"
- depends on ARCH_KEYSTONE
+ depends on ARCH_KEYSTONE || ARCH_K3
help
An implementation of Message Manager slave driver for Keystone
- architecture SoCs from Texas Instruments. Message Manager is a
- communication entity found on few of Texas Instrument's keystone
- architecture SoCs. These may be used for communication between
+ and K3 architecture SoCs from Texas Instruments. Message Manager
+ is a communication entity found on few of Texas Instrument's keystone
+ and K3 architecture SoCs. These may be used for communication between
multiple processors within the SoC. Select this driver if your
platform has support for the hardware block.
--
2.15.1
^ permalink raw reply related
* [RFC PATCH 8/8] arm64: dts: ti: k3-am6: Add Secure Proxy instance
From: Nishanth Menon @ 2018-06-05 6:16 UTC (permalink / raw)
To: Jassi Brar, Rob Herring
Cc: Nishanth Menon, devicetree, linux-kernel, Tero Kristo,
linux-arm-kernel
In-Reply-To: <20180605061629.4759-1-nm@ti.com>
Add support for Secure Proxy instances in AM6 family of SoCs.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm64/boot/dts/ti/k3-am6.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am6.dtsi b/arch/arm64/boot/dts/ti/k3-am6.dtsi
index cdfa12173aac..07e9cc05519c 100644
--- a/arch/arm64/boot/dts/ti/k3-am6.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am6.dtsi
@@ -86,6 +86,17 @@
};
};
+ secure_proxy: secure_proxy@32c00000 {
+ compatible = "ti,am654-secure-proxy";
+ #mbox-cells = <1>;
+ reg-names = "target_data", "rt", "scfg";
+ reg = <0x0 0x32c00000 0x0 0x100000>,
+ <0x0 0x32400000 0x0 0x100000>,
+ <0x0 0x32800000 0x0 0x100000>;
+ interrupt-names = "rx_011";
+ interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
wkup_uart0: serial@42300000 {
compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
reg = <0x0 0x42300000 0x0 0x100>;
--
2.15.1
^ permalink raw reply related
* Re: [PATCH] remoteproc: qcom: Introduce Hexagon V5 based WCSS driver
From: Vinod @ 2018-06-05 6:19 UTC (permalink / raw)
To: Sricharan R
Cc: bjorn.andersson, ohad, robh+dt, mark.rutland, andy.gross,
david.brown, linux-remoteproc, devicetree, linux-kernel,
linux-arm-msm, linux-soc, sibis
In-Reply-To: <1528177361-8883-1-git-send-email-sricharan@codeaurora.org>
On 05-06-18, 11:12, Sricharan R wrote:
> +config QCOM_Q6V5_WCSS
> + tristate "Qualcomm Hexagon based WCSS Peripheral Image Loader"
> + depends on OF && ARCH_QCOM
> + depends on QCOM_SMEM
> + depends on RPMSG_QCOM_SMD || (COMPILE_TEST && RPMSG_QCOM_SMD=n)
> + depends on RPMSG_QCOM_GLINK_SMEM || RPMSG_QCOM_GLINK_SMEM=n
Is there a reason why it depends on RPMSG_QCOM_GLINK_SMEM=n? What would
happen if distro wants both this and RPMSG_QCOM_GLINK_SMEM
> +/* QDSP6SS Register Offsets */
> +#define QDSP6SS_RESET_REG 0x014
> +#define QDSP6SS_GFMUX_CTL_REG 0x020
> +#define QDSP6SS_PWR_CTL_REG 0x030
> +#define QDSP6SS_MEM_PWR_CTL 0x0B0
> +
> +/* AXI Halt Register Offsets */
> +#define AXI_HALTREQ_REG 0x0
> +#define AXI_HALTACK_REG 0x4
> +#define AXI_IDLE_REG 0x8
> +
> +#define HALT_ACK_TIMEOUT_MS 100
> +
> +/* QDSP6SS_RESET */
> +#define Q6SS_STOP_CORE BIT(0)
> +#define Q6SS_CORE_ARES BIT(1)
> +#define Q6SS_BUS_ARES_ENABLE BIT(2)
Wouldn't it be nice if the defines are all consistent, some of them are
QDSP6SS_xxx, some Q6SS_ some are not
Please do pick one and make it consistent :)
> +/* QDSP6v56 parameters */
> +#define QDSP6v56_LDO_BYP BIT(25)
> +#define QDSP6v56_BHS_ON BIT(24)
> +#define QDSP6v56_CLAMP_WL BIT(21)
> +#define QDSP6v56_CLAMP_QMC_MEM BIT(22)
> +#define HALT_CHECK_MAX_LOOPS 200
> +#define QDSP6SS_XO_CBCR 0x0038
GENMASK() perhaps?
> +static int q6v5_wcss_reset(struct q6v5_wcss *wcss)
> +{
> + int ret;
> + u32 val;
> + int i;
int ret, i;
> +static int q6v5_wcss_start(struct rproc *rproc)
> +{
> + struct q6v5_wcss *wcss = rproc->priv;
> + int ret;
> +
> + qcom_q6v5_prepare(&wcss->q6v5);
> +
> + /* Release Q6 and WCSS reset */
> + ret = reset_control_deassert(wcss->wcss_reset);
> + if (ret) {
> + dev_err(wcss->dev, "wcss_reset failed\n");
> + return ret;
> + }
> +
> + ret = reset_control_deassert(wcss->wcss_q6_reset);
> + if (ret) {
> + dev_err(wcss->dev, "wcss_q6_reset failed\n");
> + goto wcss_reset;
> + }
> +
> + /* Lithium configuration - clock gating and bus arbitration */
> + ret = regmap_update_bits(wcss->halt_map,
> + wcss->halt_nc + TCSR_GLOBAL_CFG0,
> + 0x1F, 0x14);
magic numbers??
> +static int q6v5_wcss_powerdown(struct q6v5_wcss *wcss)
> +{
> + int ret;
> + u32 val;
> +
> + /* 1 - Assert WCSS/Q6 HALTREQ */
> + q6v5_wcss_halt_axi_port(wcss, wcss->halt_map, wcss->halt_wcss);
> +
> + /* 2 - Enable WCSSAON_CONFIG */
> + val = readl(wcss->rmb_base + SSCAON_CONFIG);
> + val |= SSCAON_ENABLE;
> + writel(val, wcss->rmb_base + SSCAON_CONFIG);
> +
> + /* 3 - Set SSCAON_CONFIG */
> + val |= BIT(15);
> + val &= ~BIT(16);
> + val &= ~BIT(17);
> + val &= ~BIT(18);
wouldn't it be nice to define these bits?
> +static int q6v5_q6_powerdown(struct q6v5_wcss *wcss)
> +{
> + int ret;
> + u32 val;
> + int i;
int ret, i;
--
~Vinod
^ permalink raw reply
* [RFC PATCH 0/3] firmware: Add K3 Support for TISCI driver
From: Nishanth Menon @ 2018-06-05 6:26 UTC (permalink / raw)
To: Rob Herring, Santosh Shilimkar, Tero Kristo, Nishanth Menon
Cc: linux-kernel, devicetree, linux-arm-kernel
Hi,
The following series enables TI System Control Interface(TISCI) support for
the newest addition in TI's SoC portfolio - AM654 SoC.
The series is an RFC based off next-20180604 and will post formally once
v4.18-rc1 is available.
The series (part 4 of 4) is available here:
https://github.com/nmenon/linux-2.6-playground/commits/upstream/next-20180604/k3-4-am6-tisci
Full Boot log is available here: https://pastebin.ubuntu.com/p/vWCzMKtBCW/
The Linux development follows closely the 66AK2G SoC model in aarch64 with a
few additions to handle the flexibility of firmware.
The architecture and dts support depends on part 1 of the series:
https://marc.info/?l=linux-arm-kernel&m=152817866312732&w=2
See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7
Nishanth Menon (3):
Documentation: dt: keystone: ti-sci: Add optional host-id parameter
firmware: ti_sci: Provide host-id as an optional dt parameter
arm64: dts: ti: k3-am6: Add Device Management Security Controller
support
.../devicetree/bindings/arm/keystone/ti,sci.txt | 4 +++
arch/arm64/boot/dts/ti/k3-am6.dtsi | 32 ++++++++++++++++++++++
drivers/firmware/ti_sci.c | 24 +++++++++++++---
3 files changed, 56 insertions(+), 4 deletions(-)
--
2.15.1
^ permalink raw reply
* [RFC PATCH 1/3] Documentation: dt: keystone: ti-sci: Add optional host-id parameter
From: Nishanth Menon @ 2018-06-05 6:26 UTC (permalink / raw)
To: Rob Herring, Santosh Shilimkar, Tero Kristo, Nishanth Menon
Cc: linux-kernel, devicetree, linux-arm-kernel
In-Reply-To: <20180605062640.3356-1-nm@ti.com>
Texas Instrument's System Control Interface (TISCI) permits the
ability for Operating Systems to running in virtual machines to be
able to independently communicate with the firmware without the need
going through an hypervisor.
The "host-id" in effect is the hardware representation of the
host (example: VMs locked to a core) as identified to the System
Controller.
This is introduced as an optional parameter to maintain consistency
with legacy device tree blobs.
We call this with a vendor prefix to prevent any possible confusion
with SCSI ID (m68k) kernel option.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Documentation/devicetree/bindings/arm/keystone/ti,sci.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
index 31f5f9a104cc..b56a02c10ae6 100644
--- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
+++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
@@ -45,11 +45,15 @@ Optional Properties:
debug_messages - Map the Debug message region
- reg: register space corresponding to the debug_messages
- ti,system-reboot-controller: If system reboot can be triggered by SoC reboot
+- ti,host-id: Integer value corresponding to the host ID assigned by Firmware
+ for identification of host processing entities such as virtual
+ machines
Example (K2G):
-------------
pmmc: pmmc {
compatible = "ti,k2g-sci";
+ ti,host-id = <2>;
mbox-names = "rx", "tx";
mboxes= <&msgmgr &msgmgr_proxy_pmmc_rx>,
<&msgmgr &msgmgr_proxy_pmmc_tx>;
--
2.15.1
^ permalink raw reply related
* [RFC PATCH 2/3] firmware: ti_sci: Provide host-id as an optional dt parameter
From: Nishanth Menon @ 2018-06-05 6:26 UTC (permalink / raw)
To: Rob Herring, Santosh Shilimkar, Tero Kristo, Nishanth Menon
Cc: linux-kernel, devicetree, linux-arm-kernel
In-Reply-To: <20180605062640.3356-1-nm@ti.com>
Texas Instrument's System Control Interface (TISCI) permits the
ability for Operating Systems to running in virtual machines to be
able to independently communicate with the firmware without the need
going through an hypervisor.
The "host-id" in effect is the hardware representation of the
host (example: VMs locked to a core) as identified to the System
Controller.
Provide support as an optional parameter implementation and use the compatible
data as default if one is not provided by device tree.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
drivers/firmware/ti_sci.c | 24 ++++++++++++++++++++----
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index b74a533ef35b..6b08ee815b24 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -66,14 +66,14 @@ struct ti_sci_xfers_info {
/**
* struct ti_sci_desc - Description of SoC integration
- * @host_id: Host identifier representing the compute entity
+ * @default_host_id: Host identifier representing the compute entity
* @max_rx_timeout_ms: Timeout for communication with SoC (in Milliseconds)
* @max_msgs: Maximum number of messages that can be pending
* simultaneously in the system
* @max_msg_size: Maximum size of data per message that can be handled.
*/
struct ti_sci_desc {
- u8 host_id;
+ u8 default_host_id;
int max_rx_timeout_ms;
int max_msgs;
int max_msg_size;
@@ -94,6 +94,7 @@ struct ti_sci_desc {
* @chan_rx: Receive mailbox channel
* @minfo: Message info
* @node: list head
+ * @host_id: Host ID
* @users: Number of users of this instance
*/
struct ti_sci_info {
@@ -110,6 +111,7 @@ struct ti_sci_info {
struct mbox_chan *chan_rx;
struct ti_sci_xfers_info minfo;
struct list_head node;
+ u8 host_id;
/* protected by ti_sci_list_mutex */
int users;
@@ -370,7 +372,7 @@ static struct ti_sci_xfer *ti_sci_get_one_xfer(struct ti_sci_info *info,
hdr->seq = xfer_id;
hdr->type = msg_type;
- hdr->host = info->desc->host_id;
+ hdr->host = info->host_id;
hdr->flags = msg_flags;
return xfer;
@@ -1793,7 +1795,7 @@ static int tisci_reboot_handler(struct notifier_block *nb, unsigned long mode,
/* Description for K2G */
static const struct ti_sci_desc ti_sci_pmmc_k2g_desc = {
- .host_id = 2,
+ .default_host_id = 2,
/* Conservative duration */
.max_rx_timeout_ms = 1000,
/* Limited by MBOX_TX_QUEUE_LEN. K2G can handle upto 128 messages! */
@@ -1819,6 +1821,7 @@ static int ti_sci_probe(struct platform_device *pdev)
int ret = -EINVAL;
int i;
int reboot = 0;
+ u32 h_id;
of_id = of_match_device(ti_sci_of_match, dev);
if (!of_id) {
@@ -1833,6 +1836,19 @@ static int ti_sci_probe(struct platform_device *pdev)
info->dev = dev;
info->desc = desc;
+ ret = of_property_read_u32(dev->of_node, "ti,host-id", &h_id);
+ /* if the property is not present in DT, use a default from desc */
+ if (ret < 0) {
+ info->host_id = info->desc->default_host_id;
+ } else {
+ if (!h_id) {
+ dev_warn(dev, "Host ID 0 is reserved for firmware\n");
+ info->host_id = info->desc->default_host_id;
+ } else {
+ info->host_id = h_id;
+ }
+ }
+
reboot = of_property_read_bool(dev->of_node,
"ti,system-reboot-controller");
INIT_LIST_HEAD(&info->node);
--
2.15.1
^ permalink raw reply related
* [RFC PATCH 3/3] arm64: dts: ti: k3-am6: Add Device Management Security Controller support
From: Nishanth Menon @ 2018-06-05 6:26 UTC (permalink / raw)
To: Rob Herring, Santosh Shilimkar, Tero Kristo, Nishanth Menon
Cc: linux-kernel, devicetree, linux-arm-kernel
In-Reply-To: <20180605062640.3356-1-nm@ti.com>
Add TISCI compatible System controller for AM6 SoCs.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm64/boot/dts/ti/k3-am6.dtsi | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am6.dtsi b/arch/arm64/boot/dts/ti/k3-am6.dtsi
index 07e9cc05519c..898422e24b27 100644
--- a/arch/arm64/boot/dts/ti/k3-am6.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am6.dtsi
@@ -97,6 +97,38 @@
interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
};
+ dmsc: dmsc {
+ compatible = "ti,k2g-sci";
+ ti,host-id = <12>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ /*
+ * In case of rare platforms that does not use am6 as
+ * system master, use /delete-property/
+ */
+ ti,system-reboot-controller;
+ mbox-names = "rx", "tx";
+
+ mboxes= <&secure_proxy 11>,
+ <&secure_proxy 13>;
+
+ k3_pds: power-controller {
+ compatible = "ti,sci-pm-domain";
+ #power-domain-cells = <1>;
+ };
+
+ k3_clks: clocks {
+ compatible = "ti,k2g-sci-clk";
+ #clock-cells = <2>;
+ };
+
+ k3_reset: reset-controller {
+ compatible = "ti,sci-reset";
+ #reset-cells = <2>;
+ };
+ };
+
wkup_uart0: serial@42300000 {
compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
reg = <0x0 0x42300000 0x0 0x100>;
--
2.15.1
^ permalink raw reply related
* Re: [PATCH] regulator: tps65911: fix regulator-compatible documentation
From: Lee Jones @ 2018-06-05 7:04 UTC (permalink / raw)
To: Christoph Fritz; +Cc: Rob Herring, Tony Lindgren, devicetree, linux-omap
In-Reply-To: <1528146863.2818.23.camel@googlemail.com>
On Mon, 04 Jun 2018, Christoph Fritz wrote:
>
> Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
> ---
> Documentation/devicetree/bindings/mfd/tps65910.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/tps65910.txt b/Documentation/devicetree/bindings/mfd/tps65910.txt
> index 8af1202..4f62143 100644
> --- a/Documentation/devicetree/bindings/mfd/tps65910.txt
> +++ b/Documentation/devicetree/bindings/mfd/tps65910.txt
> @@ -22,7 +22,7 @@ Required properties:
> The valid regulator-compatible values are:
> tps65910: vrtc, vio, vdd1, vdd2, vdd3, vdig1, vdig2, vpll, vdac, vaux1,
> vaux2, vaux33, vmmc, vbb
> - tps65911: vrtc, vio, vdd1, vdd3, vddctrl, ldo1, ldo2, ldo3, ldo4, ldo5,
> + tps65911: vrtc, vio, vdd1, vdd2, vddctrl, ldo1, ldo2, ldo3, ldo4, ldo5,
> ldo6, ldo7, ldo8
>
> - xxx-supply: Input voltage supply regulator.
<playing_dumb>
I have no idea what I'm meant to be looking for.
Please add a suitable commit log.
</playing_dumb>
Also, this is not a "regulator" patch, as your $SUBJECT suggests.
Please change the pre-fix to "dt-bindings: mfd: "
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v3 1/3] cpufreq: imx6q: check speed grades for i.MX6ULL
From: Sébastien Szymanski @ 2018-06-05 7:07 UTC (permalink / raw)
To: Shawn Guo
Cc: Mark Rutland, devicetree, linux-pm, Viresh Kumar,
Rafael J . Wysocki, linux-kernel, Stefan Agner, Rob Herring,
Sascha Hauer, Fabio Estevam, linux-arm-kernel
In-Reply-To: <20180523042953.kcp2h5xtwjrjponn@vireshk-i7>
On 05/23/2018 06:29 AM, Viresh Kumar wrote:
> On 22-05-18, 08:28, Sébastien Szymanski wrote:
>> Check the max speed supported from the fuses for i.MX6ULL and update the
>> operating points table accordingly.
>>
>> Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
>> ---
>>
>> Changes for v3:
>> - none
>
> @Sascha and Shawn: Can you guys please Ack this series if there is
> nothing wrong with it ?
>
ping...
--
Sébastien Szymanski
Software engineer, Armadeus Systems
Tel: +33 (0)9 72 29 41 44
Fax: +33 (0)9 72 28 79 26
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V2 2/2] arm: dts: sunxi: Add missing cooling device properties for CPUs
From: Maxime Ripard @ 2018-06-05 7:11 UTC (permalink / raw)
To: Viresh Kumar
Cc: arm, Rob Herring, Mark Rutland, Chen-Yu Tsai, Vincent Guittot,
ionela.voinescu, Daniel Lezcano, chris.redpath, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <a313ec0be4104494de319e8318e05614fb97b2fd.1528173943.git.viresh.kumar@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 905 bytes --]
On Tue, Jun 05, 2018 at 10:17:49AM +0530, Viresh Kumar wrote:
> The cooling device properties, like "#cooling-cells" and
> "dynamic-power-coefficient", should either be present for all the CPUs
> of a cluster or none. If these are present only for a subset of CPUs of
> a cluster then things will start falling apart as soon as the CPUs are
> brought online in a different order. For example, this will happen
> because the operating system looks for such properties in the CPU node
> it is trying to bring up, so that it can register a cooling device.
>
> Add such missing properties.
>
> Fix other missing properties (clocks, OPP, clock latency) as well to
> make it all work.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Applied both, thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 8/8] ARM: dts: rcar-gen2: Remove unused VIN properties
From: Simon Horman @ 2018-06-05 7:49 UTC (permalink / raw)
To: Niklas Söderlund
Cc: devicetree, robh+dt, linux-renesas-soc, hans.verkuil, geert,
laurent.pinchart, sakari.ailus, Jacopo Mondi, mchehab,
linux-arm-kernel, linux-media
In-Reply-To: <20180604122325.GH19674@bigcity.dyn.berto.se>
On Mon, Jun 04, 2018 at 02:23:25PM +0200, Niklas Söderlund wrote:
> Hi Jacopo,
>
> Thanks for your work.
>
> On 2018-05-29 17:05:59 +0200, Jacopo Mondi wrote:
> > The 'bus-width' and 'pclk-sample' properties are not parsed by the VIN
> > driver and only confuse users. Remove them in all Gen2 SoC that use
> > them.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>
> The more I think about this the more I lean towards that this patch
> should be dropped. The properties accurately describes the hardware and
> I think there is value in that. That the driver currently don't parse or
> make use of them don't in my view reduce there value. Maybe you should
> break out this patch to a separate series?
I also think there is value in describing the hardware not the state of the
driver at this time. Is there any missmatch between these properties and
the bindings?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 1/4] mfd: bd71837: mfd driver for ROHM BD71837 PMIC
From: Matti Vaittinen @ 2018-06-05 7:57 UTC (permalink / raw)
To: Matti Vaittinen
Cc: mturquette, sboyd, robh+dt, mark.rutland, lee.jones, lgirdwood,
broonie, mazziesaccount, linux-clk, devicetree, linux-kernel,
mikko.mutanen, heikki.haikola
In-Reply-To: <985ac760de3be503f9196eb6353a57eeb92c6dc0.1528117485.git.matti.vaittinen@fi.rohmeurope.com>
On Mon, Jun 04, 2018 at 04:18:07PM +0300, Matti Vaittinen wrote:
> +static struct regmap_irq_chip bd71837_irq_chip = {
> + .name = "bd71837-irq",
> + .irqs = bd71837_irqs,
> + .num_irqs = ARRAY_SIZE(bd71837_irqs),
> + .num_regs = 1,
> + .irq_reg_stride = 1,
> + .status_base = BD71837_REG_IRQ,
> + .mask_base = BD71837_REG_MIRQ,
> + .init_ack_masked = true,
> + .mask_invert = false,
> +};
.ack_base = BD71837_REG_IRQ, is missing. I'll send yet another version
with this fixed - unless Rob tells me to drop the whole irq handling
from the patch series.
Br,
Matti Vaittinen
^ permalink raw reply
* Re: [PATCH] dt-bindings: display: renesas: du: document R8A77980 bindings
From: Simon Horman @ 2018-06-05 8:09 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Mark Rutland, devicetree, David Airlie, dri-devel,
linux-renesas-soc, Rob Herring, Laurent Pinchart
In-Reply-To: <2a775652-604c-6379-b807-19979f164f84@cogentembedded.com>
On Mon, Jun 04, 2018 at 10:04:59PM +0300, Sergei Shtylyov wrote:
> Document the R-Car V3H (R8A77980) SoC in the R-Car DU bindings; the DU
> hardware seems the same as in the R-Car V3M (R8A77970).
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
>
> ---
> The patch is against the 'drm-next' branch of David Airlie's 'linux.git' repo.
>
> Documentation/devicetree/bindings/display/renesas,du.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> Index: linux/Documentation/devicetree/bindings/display/renesas,du.txt
> ===================================================================
> --- linux.orig/Documentation/devicetree/bindings/display/renesas,du.txt
> +++ linux/Documentation/devicetree/bindings/display/renesas,du.txt
> @@ -14,6 +14,7 @@ Required Properties:
> - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU
> - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU
> - "renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU
> + - "renesas,du-r8a77980" for R8A77980 (R-Car V3H) compatible DU
> - "renesas,du-r8a77995" for R8A77995 (R-Car D3) compatible DU
>
> - reg: the memory-mapped I/O registers base address and length
> @@ -60,6 +61,7 @@ corresponding to each DU output.
> R8A7795 (R-Car H3) DPAD 0 HDMI 0 HDMI 1 LVDS 0
> R8A7796 (R-Car M3-W) DPAD 0 HDMI 0 LVDS 0 -
> R8A77970 (R-Car V3M) DPAD 0 LVDS 0 - -
> + R8A77980 (R-Car V3H) DPAD 0 LVDS 0 - -
> R8A77995 (R-Car D3) DPAD 0 LVDS 0 LVDS 1 -
>
>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v3 8/8] ARM: dts: rcar-gen2: Remove unused VIN properties
From: jacopo mondi @ 2018-06-05 8:12 UTC (permalink / raw)
To: Simon Horman
Cc: devicetree, robh+dt, linux-renesas-soc, hans.verkuil, geert,
laurent.pinchart, sakari.ailus, Niklas Söderlund,
Jacopo Mondi, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <20180605074938.mljwmgpjlplvkp2v@verge.net.au>
[-- Attachment #1.1: Type: text/plain, Size: 3114 bytes --]
Hi Simon,
On Tue, Jun 05, 2018 at 09:49:38AM +0200, Simon Horman wrote:
> On Mon, Jun 04, 2018 at 02:23:25PM +0200, Niklas Söderlund wrote:
> > Hi Jacopo,
> >
> > Thanks for your work.
> >
> > On 2018-05-29 17:05:59 +0200, Jacopo Mondi wrote:
> > > The 'bus-width' and 'pclk-sample' properties are not parsed by the VIN
> > > driver and only confuse users. Remove them in all Gen2 SoC that use
> > > them.
> > >
> > > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> >
> > The more I think about this the more I lean towards that this patch
> > should be dropped. The properties accurately describes the hardware and
> > I think there is value in that. That the driver currently don't parse or
> > make use of them don't in my view reduce there value. Maybe you should
> > break out this patch to a separate series?
>
> I also think there is value in describing the hardware not the state of the
> driver at this time. Is there any missmatch between these properties and
> the bindings?
Niklas and I discussed a bit offline on this yesterday. My main
concern, and sorry for being pedant on this, is that changing those
properties value does not change the interface behaviour, and this
could cause troubles when integrating image sensor not known to be
working on the VIN interface.
This said, the documentation of those (and all other) properties is in the
generic "video-interfaces.txt" file and it is my understanding, but I think
Laurent and Rob agree on this as well from their replies to my previous series,
that each driver should list which properties it actually supports, as
some aspects are very implementation specific, like default values and
what happens if the property is not specified [1]. Nonetheless, all
properties describing hardware features and documented in the generic
file should be accepted in DTS, as those aims to be OS-independent and
even independent from the single driver implementation.
A possible middle-ground would be documenting in the VIN device tree
bindings description properties whose values actually affect the VIN
interface configuration and state in bindings that all generic properties
described in 'video-interfaces.txt' are valid ones but if not
explicitly listed there their value won't affect the interface
configuration. Niklas suggested this, and I quite like the fact it
makes clear that, say, changing the 'pclk-sample' property won't
change how the VIN interface would sample data but at the same time
allows for extensive description of the hardware.
Would something like this work in your opinion?
As a consequence, this patch should be dropped as Niklas and you
suggested.
Thanks
j
[1] Ie. An interface that supports BT.656 encoding will use it if
'hsync-active' and 'vsync-active' are not specified. One that does not
support embedded synchronization would instead use defaults for those
two properties. This is specific to the single interface (or even the
single driver implementation actually) and should be listed in the single
driver's bindings description imo.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 8/8] ARM: dts: rcar-gen2: Remove unused VIN properties
From: Geert Uytterhoeven @ 2018-06-05 8:23 UTC (permalink / raw)
To: jacopo mondi
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rob Herring, Linux-Renesas, Simon Horman, Jacopo Mondi,
Laurent Pinchart, Sakari Ailus, Niklas Söderlund,
Hans Verkuil, Mauro Carvalho Chehab, Linux ARM,
Linux Media Mailing List
In-Reply-To: <20180605081222.GL10472@w540>
Hi Jacopo,
On Tue, Jun 5, 2018 at 10:12 AM, jacopo mondi <jacopo@jmondi.org> wrote:
> On Tue, Jun 05, 2018 at 09:49:38AM +0200, Simon Horman wrote:
>> On Mon, Jun 04, 2018 at 02:23:25PM +0200, Niklas Söderlund wrote:
>> > On 2018-05-29 17:05:59 +0200, Jacopo Mondi wrote:
>> > > The 'bus-width' and 'pclk-sample' properties are not parsed by the VIN
>> > > driver and only confuse users. Remove them in all Gen2 SoC that use
>> > > them.
>> > >
>> > > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>> >
>> > The more I think about this the more I lean towards that this patch
>> > should be dropped. The properties accurately describes the hardware and
>> > I think there is value in that. That the driver currently don't parse or
>> > make use of them don't in my view reduce there value. Maybe you should
>> > break out this patch to a separate series?
>>
>> I also think there is value in describing the hardware not the state of the
>> driver at this time. Is there any missmatch between these properties and
>> the bindings?
>
> Niklas and I discussed a bit offline on this yesterday. My main
> concern, and sorry for being pedant on this, is that changing those
> properties value does not change the interface behaviour, and this
> could cause troubles when integrating image sensor not known to be
> working on the VIN interface.
>
> This said, the documentation of those (and all other) properties is in the
> generic "video-interfaces.txt" file and it is my understanding, but I think
> Laurent and Rob agree on this as well from their replies to my previous series,
> that each driver should list which properties it actually supports, as
s/driver/device-specific binding/
> some aspects are very implementation specific, like default values and
> what happens if the property is not specified [1]. Nonetheless, all
In se defaults are not (Linux) implementation-specific, but fixed in the
DT bindings.
> properties describing hardware features and documented in the generic
> file should be accepted in DTS, as those aims to be OS-independent and
> even independent from the single driver implementation.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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