* [PATCH 2/5] arm64: Add support for TI's K3 Multicore SoC architecture
From: Nishanth Menon @ 2018-06-19 19:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619194253.27288-1-nm@ti.com>
Add support for Texas Instrument's K3 Multicore SoC architecture
processors.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Changes since RFC:
* None
RFC: https://patchwork.kernel.org/patch/10447633/
arch/arm64/Kconfig.platforms | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index d5aeac351fc3..52df25bf4f8c 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -71,6 +71,13 @@ config ARCH_EXYNOS
help
This enables support for ARMv8 based Samsung Exynos SoC family.
+config ARCH_K3
+ bool "Texas Instruments Inc. K3 multicore SoC architecture"
+ select PM_GENERIC_DOMAINS if PM
+ help
+ This enables support for Texas Instruments' K3 multicore SoC
+ architecture.
+
config ARCH_LAYERSCAPE
bool "ARMv8 based Freescale Layerscape SoC family"
select EDAC_SUPPORT
--
2.15.1
^ permalink raw reply related
* [PATCH 3/5] arm64: dts: ti: Add Support for AM654 SoC
From: Nishanth Menon @ 2018-06-19 19:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619194253.27288-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 subsystem 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
NOTE:
1. AM654 is the first of the device variants, hence we introduce a
generic am65.dtsi.
2. We indicate the proper bus topology, the ranges are elaborated in
each bus segment instead of using the top level ranges to make sure
that peripherals in each segment use the address space accurately.
3. Peripherals in each bus segment is maintained in a separate dtsi
allowing for reuse in different bus segment representation from a
different core such as R5. This is also the reason for maintaining a
1-1 address map in the ranges.
4. Cache descriptions follow the ARM64 standard description.
Further tweaks may be necessary as we introduce more complex devices,
but can be introduced in context of the device introduction.
Signed-off-by: Benjamin Fair <b-fair@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Changes since RFC:
* Bus topology representation
* Device nodes underneath a bus segment moved to seperate dtsi (allowing reuse
where applicable)
* Ranges used in the bus segments
* Processor level nodes moved to the root node
* SoC node dropped.
* Default for device nodes is "enabled" instead of explicitly enabling them in
board dts.
* UART patches are spun off into a different series to prevent maintainer
tree level conflicts. (wakeup and mcu domain peripherals to be introduced
there)
* Few addresses had uppercase hexadecimal values, replaced with standard
lowercase hex values
* Commit message updates
* Kconfig was spun out as seperate patch
RFC: https://patchwork.kernel.org/patch/10447719/ , https://patchwork.kernel.org/patch/10453659/
MAINTAINERS | 1 +
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 31 +++++++++
arch/arm64/boot/dts/ti/k3-am65.dtsi | 87 +++++++++++++++++++++++
arch/arm64/boot/dts/ti/k3-am654.dtsi | 115 +++++++++++++++++++++++++++++++
4 files changed, 234 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am65-main.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am65.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am654.dtsi
diff --git a/MAINTAINERS b/MAINTAINERS
index fbd93eee41ae..6785ceaf5b0b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2093,6 +2093,7 @@ M: Nishanth Menon <nm@ti.com>
L: linux-arm-kernel at 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-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
new file mode 100644
index 000000000000..2409344df4fa
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for AM6 SoC Family Main Domain peripherals
+ *
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+&cbass_main {
+ gic500: interrupt-controller at 1800000 {
+ compatible = "arm,gic-v3";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ reg = <0x01800000 0x10000>, /* GICD */
+ <0x01880000 0x90000>; /* GICR */
+ /*
+ * vcpumntirq:
+ * virtual CPU interface maintenance interrupt
+ */
+ interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+
+ gic_its: gic-its at 18200000 {
+ compatible = "arm,gic-v3-its";
+ reg = <0x01820000 0x10000>;
+ msi-controller;
+ #msi-cells = <1>;
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am65.dtsi b/arch/arm64/boot/dts/ti/k3-am65.dtsi
new file mode 100644
index 000000000000..8c0f78332157
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am65.dtsi
@@ -0,0 +1,87 @@
+// 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 = <&gic500>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ chosen { };
+
+ firmware {
+ optee {
+ compatible = "linaro,optee-tz";
+ method = "smc";
+ };
+
+ psci: psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+ };
+
+ 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>;
+ };
+
+ cbass_main: cbass at 100000 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x00100000 0x00 0x00100000 0x00020000>, /* ctrl mmr */
+ <0x00600000 0x00 0x00600000 0x00001100>, /* GPIO */
+ <0x00900000 0x00 0x00900000 0x00012000>, /* serdes */
+ <0x01000000 0x00 0x01000000 0x0af02400>, /* Most peripherals */
+ <0x30800000 0x00 0x30800000 0x0bc00000>, /* MAIN NAVSS */
+ /* MCUSS Range */
+ <0x28380000 0x00 0x28380000 0x03880000>,
+ <0x40200000 0x00 0x40200000 0x00900100>,
+ <0x42040000 0x00 0x42040000 0x03ac2400>,
+ <0x45100000 0x00 0x45100000 0x00c24000>,
+ <0x46000000 0x00 0x46000000 0x00200000>,
+ <0x47000000 0x00 0x47000000 0x00068400>;
+
+ cbass_mcu: cbass at 28380000 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x28380000 0x28380000 0x03880000>, /* MCU NAVSS*/
+ <0x40200000 0x40200000 0x00900100>, /* First peripheral window */
+ <0x42040000 0x42040000 0x03ac2400>, /* WKUP */
+ <0x45100000 0x45100000 0x00c24000>, /* MMRs, remaining NAVSS */
+ <0x46000000 0x46000000 0x00200000>, /* CPSW */
+ <0x47000000 0x47000000 0x00068400>; /* OSPI space 1 */
+
+ cbass_wakeup: cbass at 42040000 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ /* WKUP Basic peripherals */
+ ranges = <0x42040000 0x42040000 0x03ac2400>;
+ };
+ };
+ };
+};
+
+/* Now include the peripherals for each bus segments */
+#include "k3-am65-main.dtsi"
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..2affa6f6617e
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am654.dtsi
@@ -0,0 +1,115 @@
+// 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-am65.dtsi"
+
+/ {
+ 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 at 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 at 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 at 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 at 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>;
+ };
+ };
+
+ 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>;
+ };
+};
--
2.15.1
^ permalink raw reply related
* [PATCH 4/5] soc: ti: Add Support for AM654 SoC config option
From: Nishanth Menon @ 2018-06-19 19:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619194253.27288-1-nm@ti.com>
Add option to build AM6 SoC specific components
Signed-off-by: Benjamin Fair <b-fair@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
(new patch broken out from: https://patchwork.kernel.org/patch/10447719/)
drivers/soc/ti/Kconfig | 14 ++++++++++++++
1 file changed, 14 insertions(+)
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
* [PATCH 5/5] arm64: dts: ti: Add support for AM654 EVM base board
From: Nishanth Menon @ 2018-06-19 19:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619194253.27288-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>
---
Changes since RFC:
* Since defaults are enabled, and uart has been spun off, dropped the
redundant nodes from baseboard dts
RFC: https://patchwork.kernel.org/patch/10447741/
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 | 36 ++++++++++++++++++++++++++
4 files changed, 47 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 6785ceaf5b0b..e9e916d1fb52 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2093,6 +2093,7 @@ M: Nishanth Menon <nm@ti.com>
L: linux-arm-kernel at 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..af6956fdc13f
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
@@ -0,0 +1,36 @@
+// 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 at 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 at 9e800000 {
+ reg = <0 0x9e800000 0 0x01800000>; /* for OP-TEE */
+ alignment = <0x1000>;
+ no-map;
+ };
+ };
+};
--
2.15.1
^ permalink raw reply related
* [PATCH 0/2] firmware: ti_sci: Add host-id as an optional parameter
From: Nishanth Menon @ 2018-06-19 19:44 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Please find attached series to enable host-id as an optional dt property.
Changes Since RFC:
* Updated commit message based on feedback from Rob.
The series is based on v4.18-rc1 and is available here:
https://github.com/nmenon/linux-2.6-playground/commits/upstream/v4.18-rc1/k3-1-am6-tisci
Consolidated all patches (including all series) are available here:
https://github.com/nmenon/linux-2.6-playground/commits/upstream/v4.18-rc1/k3-am6-integ
Full Boot log (integrated of all series for AM654) is available here:
https://pastebin.ubuntu.com/p/bBFmnzYtCd/
Nishanth Menon (2):
Documentation: dt: keystone: ti-sci: Add optional host-id parameter
firmware: ti_sci: Provide host-id as an optional dt parameter
.../devicetree/bindings/arm/keystone/ti,sci.txt | 4 ++++
drivers/firmware/ti_sci.c | 24 ++++++++++++++++++----
2 files changed, 24 insertions(+), 4 deletions(-)
--
2.15.1
^ permalink raw reply
* [PATCH 1/2] Documentation: dt: keystone: ti-sci: Add optional host-id parameter
From: Nishanth Menon @ 2018-06-19 19:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619194421.3432-1-nm@ti.com>
Texas Instrument's System Control Interface (TISCI) permits
the ability for OSs 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. Hypervisors can either fill in appropriate host-ids in dt
used for each VM instance OR may use prebuilt blobs where the host-ids
are pre-populated, as appropriate for the OS running in the VMs.
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>
---
Changes since RFC:
* Commit message update to elaborate usage in VM
RFC: https://patchwork.kernel.org/patch/10447753/
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
* [PATCH 2/2] firmware: ti_sci: Provide host-id as an optional dt parameter
From: Nishanth Menon @ 2018-06-19 19:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619194421.3432-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>
---
Changes since RFC: None
RFC: https://patchwork.kernel.org/patch/10447715/
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 7fa744793bc5..69ed1464175c 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
* [PATCH] dt-bindings: Fix unbalanced quotation marks
From: Florian Fainelli @ 2018-06-19 19:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180617143127.11421-1-j.neuschaefer@gmx.net>
On 06/17/2018 07:31 AM, Jonathan Neusch?fer wrote:
> Multiple binding documents have various forms of unbalanced quotation
> marks. Fix them.
>
> Signed-off-by: Jonathan Neusch?fer <j.neuschaefer@gmx.net>
> ---
[snip]
> Documentation/devicetree/bindings/mips/brcm/soc.txt | 2 +-
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* [RFC PATCH v2] driver core: add a debugfs entry to show deferred devices
From: Andy Shevchenko @ 2018-06-19 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619183356.32106-1-javierm@redhat.com>
On Tue, Jun 19, 2018 at 9:33 PM, Javier Martinez Canillas
<javierm@redhat.com> wrote:
> For debugging purposes it may be useful to know what are the devices whose
> probe function was deferred. Add a debugfs entry showing that information.
>
> $ cat /sys/kernel/debug/deferred_devices
> 48070000.i2c:twl at 48:bci
> musb-hdrc.0.auto
> omapdrm.0
> +#if IS_ENABLED(CONFIG_DEBUG_FS)
> +#include <linux/debugfs.h>
> +
> +static struct dentry *deferred_devices;
> +
> +/*
> + * deferred_devs_show() - Show the devices in the deferred probe pending list.
> + */
> +static int deferred_devs_show(struct seq_file *s, void *data)
> +{
> + struct device_private *curr;
> +
> + mutex_lock(&deferred_probe_mutex);
> +
> + list_for_each_entry(curr, &deferred_probe_pending_list, deferred_probe)
> + seq_printf(s, "%s\n", dev_name(curr->device));
> +
> + mutex_unlock(&deferred_probe_mutex);
> +
> + return 0;
> +}
> +
> +static int deferred_devs_open(struct inode *inode, struct file *file)
> +{
> + return single_open(file, deferred_devs_show, inode->i_private);
> +}
> +
> +static const struct file_operations deferred_devs_fops = {
> + .owner = THIS_MODULE,
> + .open = deferred_devs_open,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release = single_release,
> +};
Isn't this DEFINE_SHOW_ATTRIBUTE() ?
> +#endif /* IS_ENABLED(CONFIG_DEBUG_FS) */
> +
> /**
> * deferred_probe_initcall() - Enable probing of deferred devices
> *
> @@ -233,6 +269,14 @@ void device_unblock_probing(void)
> */
> static int deferred_probe_initcall(void)
> {
> + if (IS_ENABLED(CONFIG_DEBUG_FS)) {
> + deferred_devices = debugfs_create_file("deferred_devices",
> + 0444, NULL, NULL,
> + &deferred_devs_fops);
> + if (!deferred_devices)
> + return -ENOMEM;
> + }
> +
> driver_deferred_probe_enable = true;
> driver_deferred_probe_trigger();
> /* Sort as many dependencies as possible before exiting initcalls */
> --
> 2.17.1
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [RFC PATCH v2] driver core: add a debugfs entry to show deferred devices
From: Andy Shevchenko @ 2018-06-19 19:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75Vcn39N9rZ0UO3szGrODVLxek4X746uWs+RPXwy4i0s1Ug@mail.gmail.com>
On Tue, Jun 19, 2018 at 10:53 PM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Tue, Jun 19, 2018 at 9:33 PM, Javier Martinez Canillas
> <javierm@redhat.com> wrote:
>> For debugging purposes it may be useful to know what are the devices whose
>> probe function was deferred. Add a debugfs entry showing that information.
>> +static int deferred_devs_open(struct inode *inode, struct file *file)
>> +{
>> + return single_open(file, deferred_devs_show, inode->i_private);
>> +}
>> +
>> +static const struct file_operations deferred_devs_fops = {
>> + .owner = THIS_MODULE,
>> + .open = deferred_devs_open,
>> + .read = seq_read,
>> + .llseek = seq_lseek,
>> + .release = single_release,
>> +};
>
> Isn't this DEFINE_SHOW_ATTRIBUTE() ?
Besides that, you are summoning Greg's dark side :-)
See below.
>> + if (IS_ENABLED(CONFIG_DEBUG_FS)) {
>> + deferred_devices = debugfs_create_file("deferred_devices",
>> + 0444, NULL, NULL,
>> + &deferred_devs_fops);
>> + if (!deferred_devices)
>> + return -ENOMEM;
This must not prevent the execution. So, the check introduces actually
a regression.
>> + }
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v2] arm: msm: Add MSM IOMMU support.
From: Stepan Moskovchenko @ 2018-06-19 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20100807135644.GA7318@n2100.arm.linux.org.uk>
Russell,
Tomorrow I will fix the style / iomem / other issues tomorrow and clean up
the failure paths. I have some questions for you, inline.
>> + iommu_drvdata = dev_get_drvdata(ctx_drvdata->pdev->dev.parent);
>
> Please explain what's going on here with parent devices. What device is
> pdev referring to, and what is pdev->dev.parent ? It seems quite dodgy
> to just expect a certain device relationship without checking that the
> device is what is expected (eg, it's non-NULL, it's of the right bus type,
> and it appears to be suitably named) before dereferencing its driver data.
I could see why this seems confusing. pdev->dev.parent is the IOMMU
context's parent device. There is a device hierarchy here. Each IOMMU
device has multiple IOMMU *context* devices as children. These are
physical, actual translation contexts, with their own distinct sets of
registers. The parent device (the IOMMU) also has a number of "global"
registers that are shared among the translation contexts. It is
impractical to lump the global register space and the context bank
registers into one device because the translation contexts are effectively
their own IOMMUs that can be separately managed. Additionally, the number
of translation contexts varies among IOMMUs in the system. So, in this
particular case, the driver needs to know the ioremapped address of the
IOMMU, so it references the driverdata of the parent device (the IOMMU
itself) to get it. There will never be a context "by itself", ie, a
context's parent will always be an IOMMU device, so the operation of
referencing the parent's data will always be safe. But I can put in some
sanity checks for the pointers if you wish.
>> +static void msm_iommu_domain_destroy(struct iommu_domain *domain)
>> +{
>> + struct msm_priv *priv = (struct msm_priv *) domain->priv;
>
> struct msm_priv *priv = domain->priv;
>
> Should this be outside msm_iommu_lock?
domain->priv should always be unchanged if the domain is still "valid".
The contents of domain->priv may change, but domain->priv does not get
reassigned (until being set to null right as domain is being freed), so I
put this outside the spinlock. Arguably, you could have a problem if a
function is trying to use the domain *as it's being freed*, but then
bigger problems will arise. I will make the change, though.
>> + spin_unlock_irqrestore(&msm_iommu_lock, flags);
>> + return;
>> +fail_inval:
>> + spin_unlock_irqrestore(&msm_iommu_lock, flags);
>> + return;
>
> Does this need to be repeated?
I had initially operated under the assumption that unmap() could return a
failure code. I will clean this up.
>> +#ifndef CONFIG_IOMMU_PGTABLES_L2
>
> I think you mean:
> #ifndef CONFIG_IOMMU_PGTABLES_L1
>
> because as I've said to you several times now, flush_cache_all() is about
> flushing data out of the L1 cache only. It does NOT affect L2 cache.
I do mean to flush the L2 cache here (ie, flush the data from whatever
cache it may be in, all the way to RAM). I believed that
v7_flush_cache_all() (and hence, flush_cache_all() as was suggested by you
as a replacement) would flush the L1 and L2. The comment in cache-v7.S
suggests that the function will "Flush the entire cache system." (line 81)
which sounds like L2 ought to be included (and the observed behavior seems
to agree). I just need the pagetable in RAM to reflect the latest changes
made by the driver, so that the IOMMU can get to it if it hasn't been
configured to access the L2 cache on its own. Could you please suggest a
correct way to flush the L2 cache?
>> +static int msm_iommu_unmap(struct iommu_domain *domain, unsigned long
>> va,
>> + int gfp_order)
>
> What does 'gfp_order' have to do with get_free_pages in this function?
> Wouldn't just 'order' be more appropriate?
I called it 'gfp_order' because that is how linux/iommu.h names that
parameter in the IOMMU API. I guess 'order' *is* more appropriate... I'll
fix it.
>> + /* Upper 20 bits from PAR, lower 12 from VA */
>> + spin_unlock_irqrestore(&msm_iommu_lock, flags);
>> + return (par & 0xFFFFF000) | (va & 0x00000FFF);
>> +fail_nodev:
>> + spin_unlock_irqrestore(&msm_iommu_lock, flags);
>> + return -ENODEV;
>
> Hmm, returning -ve numbers and addresses... how do you tell the difference
> between the two in the calling function?
That is a good question. I am not sure how to handle the error conditions
in this case. My first idea was to just return 0 for all iova-to-phys
faults, but 0 too is a legitimate address (although kind of a dodgy one).
But it may be better to return 0 for the error case. Also, the translation
hardware will not generate a fault interrupt if it's doing a translation
at the request of the CPU (as opposed to when it's being addressed by a
client) but I can manually ask the IOMMU to generate a translation fault
interrupt if iova_to_phys results in a fault (at least we'll know
something is wrong). I am not sure which approach is the best, but am
leaning towards just returning 0 on errors. What do you think is best?
> I'm also sure you can do better with these exit paths in a similar way to
> what I've illustrated above.
Yup, I'll fix it. I will try to post a revised patch tomorrow, after I get
some sleep in me (I guess it will be the evening where you are).
Thanks
Steve
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Query: Patches break with Microsoft exchange server.
From: viresh kumar @ 2018-06-19 20:23 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
Mail server in ST has recently changed and now we have Microsoft
exchange server. We are using thunderbird as mail client.
What we observed with this server is that patch are broken now while
sending as well as receiving. Tabs are replaced by spaces and may
be some other too which we haven't observed.
Has anybody found a solution to this kind of issues? Are there any
workarounds possible?
viresh
ST Microelectronics.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Query: Patches break with Microsoft exchange server.
From: Justin P. Mattock @ 2018-06-19 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4C5F9B25.8080401@st.com>
On 08/08/2010 11:07 PM, viresh kumar wrote:
> Hello,
>
> Mail server in ST has recently changed and now we have Microsoft
> exchange server. We are using thunderbird as mail client.
> What we observed with this server is that patch are broken now while
> sending as well as receiving. Tabs are replaced by spaces and may
> be some other too which we haven't observed.
>
> Has anybody found a solution to this kind of issues? Are there any
> workarounds possible?
>
> viresh
> ST Microelectronics.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
still trying to figure this out with thunderbird.. but did notice in
Documentation/email-clients.txt and SubmittingPatches
there's info about that(just haven't gotten around to reading use git
send-email for patches)
hope this helps.
Justin P. Mattock
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Query: Patches break with Microsoft exchange server.
From: Uwe Kleine-König @ 2018-06-19 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4C5F9B25.8080401@st.com>
Hello,
On Mon, Aug 09, 2010 at 11:37:33AM +0530, viresh kumar wrote:
> Hello,
>
> Mail server in ST has recently changed and now we have Microsoft
> exchange server. We are using thunderbird as mail client.
> What we observed with this server is that patch are broken now while
> sending as well as receiving. Tabs are replaced by spaces and may
> be some other too which we haven't observed.
unlucky you.
> Has anybody found a solution to this kind of issues? Are there any
> workarounds possible?
git.git has some tips for thunderbird, see
http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/SubmittingPatches;hb=HEAD
and look for the section titled "Thunderbird" (small surprise).
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Query: Patches break with Microsoft exchange server.
From: viresh kumar @ 2018-06-19 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4C5FA35E.50309@gmail.com>
On 8/9/2010 12:12 PM, Justin P. Mattock wrote:
> On 08/08/2010 11:07 PM, viresh kumar wrote:
>> > Hello,
>> >
>> > Mail server in ST has recently changed and now we have Microsoft
>> > exchange server. We are using thunderbird as mail client.
>> > What we observed with this server is that patch are broken now while
>> > sending as well as receiving. Tabs are replaced by spaces and may
>> > be some other too which we haven't observed.
>> >
>> > Has anybody found a solution to this kind of issues? Are there any
>> > workarounds possible?
>> >
>
> still trying to figure this out with thunderbird.. but did notice in
> Documentation/email-clients.txt and SubmittingPatches
> there's info about that(just haven't gotten around to reading use git
> send-email for patches)
>
> hope this helps.
I missed this information in my last mail. We are using git send-email for
sending patches. As patches will go through Microsoft exchange server only,
so they are broken.
viresh.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Query: Patches break with Microsoft exchange server.
From: viresh kumar @ 2018-06-19 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20100809064957.GB16661@pengutronix.de>
On 8/9/2010 12:19 PM, Uwe Kleine-K?nig wrote:
> Hello,
>
> On Mon, Aug 09, 2010 at 11:37:33AM +0530, viresh kumar wrote:
>> > Hello,
>> >
>> > Mail server in ST has recently changed and now we have Microsoft
>> > exchange server. We are using thunderbird as mail client.
>> > What we observed with this server is that patch are broken now while
>> > sending as well as receiving. Tabs are replaced by spaces and may
>> > be some other too which we haven't observed.
> unlucky you.
>
>> > Has anybody found a solution to this kind of issues? Are there any
>> > workarounds possible?
> git.git has some tips for thunderbird, see
>
> http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/SubmittingPatches;hb=HEAD
>
> and look for the section titled "Thunderbird" (small surprise).
I missed this information in my last mail. We are using git send-email for
sending patches. As patches will go through Microsoft exchange server only,
so they are broken.
With previous server everything was working fine.
viresh.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Query: Patches break with Microsoft exchange server.
From: Justin P. Mattock @ 2018-06-19 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4C5FA66D.7060404@st.com>
On 08/08/2010 11:55 PM, viresh kumar wrote:
> On 8/9/2010 12:12 PM, Justin P. Mattock wrote:
>> On 08/08/2010 11:07 PM, viresh kumar wrote:
>>>> Hello,
>>>>
>>>> Mail server in ST has recently changed and now we have Microsoft
>>>> exchange server. We are using thunderbird as mail client.
>>>> What we observed with this server is that patch are broken now while
>>>> sending as well as receiving. Tabs are replaced by spaces and may
>>>> be some other too which we haven't observed.
>>>>
>>>> Has anybody found a solution to this kind of issues? Are there any
>>>> workarounds possible?
>>>>
>>
>> still trying to figure this out with thunderbird.. but did notice in
>> Documentation/email-clients.txt and SubmittingPatches
>> there's info about that(just haven't gotten around to reading use git
>> send-email for patches)
>>
>> hope this helps.
>
> I missed this information in my last mail. We are using git send-email for
> sending patches. As patches will go through Microsoft exchange server only,
> so they are broken.
>
> viresh.
>
hmm.. then I don't know the answer to that.. always send through git
send-email(patches)and things are good(knock-on-wood)always ran into
issues with copy/pasting onto thunderbird. Hopefully somebody else with
more knowledge of using git send-email patches through microsoft
exchange answers this..
side note: maybe postfix or some type of wrapper around the wording
message(utf-8) to keep microsoft from mangling things or
something.(tough to say though)
Justin P. Mattock
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* [PATCH 4/5] [omap1] Bluetooth device code common to HTC smartphones
From: Tony Lindgren @ 2018-06-19 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTikGA9-TCM7v+_yivBYtxiX3ByJ7_ub1FOP0LgBO@mail.gmail.com>
* Cory Maccarrone <darkstar6262@gmail.com> [100808 20:22]:
> On Wed, Aug 4, 2010 at 3:15 AM, Tony Lindgren <tony@atomide.com> wrote:
> > * Cory Maccarrone <darkstar6262@gmail.com> [100802 18:23]:
> >> This change adds in a bluetooth controld driver/rfkill
> >> interface to the serial bluetooth controller found on many
> >> HTC smartphones such as the HTC Herald and HTC Wizard.
> >
> > To me it looks like most of this should be in drivers/bluetooth/omap7xx.c
> > or something like that. Then you can just pass it the gpio numbers in
> > the platform_data.
> >
>
> Not sure I agree that it fits there. The driver isn't really a
> bluetooth driver -- it's really just an RFKILL interface, and some
> code to toggle UART clocks on and off, plus GPIO work on a
> board-specific level. In principle, the gpios could be set and the
> clocks enabled in the board files, and this driver wouldn't be
> necessary to get working bluetooth (as we'd use hciattach on
> /dev/ttyS*). But then, we can't toggle it off for power saving.
> Maybe a better place would be plat-omap/? But it really is more
> specific to these HTC boards, not the architecture itself.
Hmm well what we've used earlier is to set something like set_power
function pointer in the platform data, then call that in the driver
if set. But in this case the driver is 8250.c, so let's not mess
with that..
This issue should get properly solved with the omap specific serial
driver once we get that merged as then we can have hooks for set_power
in addition to cutting serial clocks when idle.
> So really, the only point of this driver is to be able to power on and
> off the external bluetooth chip, which is why I submitted it as helper
> code to the board files.
Yeah. Can you take a look at the omap specific serial driver to get
it working on omap1?
Then you can have your GPIO functions set in the board-*.c file
as set_power or similar, and the UART driver can idle properly.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Query: Patches break with Microsoft exchange server.
From: Matti Aarnio @ 2018-06-19 20:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4C5FA698.90904@st.com>
On Mon, Aug 09, 2010 at 12:26:24PM +0530, viresh kumar wrote:
>
> I missed this information in my last mail. We are using git send-email for
> sending patches. As patches will go through Microsoft exchange server only,
> so they are broken.
>
Let your boss complain to your IT keepers.
"These are Machine-to-Machine messages, they must not be modified!"
It would probably be "against corporate policy" to use gmail for these emails...
> With previous server everything was working fine.
> viresh.
Best Regards, Matti Aarnio, one of <postmaster@vger.kernel.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* [PATCH 1/3] ARM: mmu: Setup MT_MEMORY and MT_MEMORY_NONACHED L1 entries
From: Shilimkar, Santosh @ 2018-06-19 20:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EAF47CD23C76F840A9E7FCE10091EFAB02C64A2363@dbde02.ent.ti.com>
> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> owner at vger.kernel.org] On Behalf Of Shilimkar, Santosh
> Sent: Sunday, August 08, 2010 5:16 PM
> To: Russell King - ARM Linux
> Cc: linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> Subject: RE: [PATCH 1/3] ARM: mmu: Setup MT_MEMORY and MT_MEMORY_NONACHED
> L1 entries
>
> > -----Original Message-----
> > From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> > Sent: Sunday, August 08, 2010 5:04 PM
> > To: Shilimkar, Santosh
> > Cc: linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> > Subject: Re: [PATCH 1/3] ARM: mmu: Setup MT_MEMORY and
> MT_MEMORY_NONACHED
> > L1 entries
> >
> > On Sun, Aug 08, 2010 at 03:47:52PM +0530, Santosh Shilimkar wrote:
> > > @@ -475,6 +486,9 @@ static void __init build_mem_type_table(void)
> > > mem_types[MT_LOW_VECTORS].prot_l1 |= ecc_mask;
> > > mem_types[MT_HIGH_VECTORS].prot_l1 |= ecc_mask;
> > > mem_types[MT_MEMORY].prot_sect |= ecc_mask | cp->pmd;
> > > + mem_types[MT_MEMORY].prot_pte |= kern_pgprot;
> > > + mem_types[MT_MEMORY_NONCACHED].prot_sect |= ecc_mask | cp->pmd;
> > > + mem_types[MT_MEMORY_NONCACHED].prot_pte |= kern_pgprot;
> >
> > This is wrong - it will result in the non-cached memory mapped in as
> > sections having the same cache settings as MT_MEMORY - in other
> > words, probably write back.
> You are right. Will fix this in next version.
>
Updated version with Russell's comments incorporated.
--------------------------------------------------------------------
>From 23d712c1846d78bdb09979087261911e5d80f014 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Sun, 8 Aug 2010 12:05:25 +0530
Subject: [PATCH 1/3 v2] ARM: mmu: Setup MT_MEMORY and MT_MEMORY_NONCACHED L1 entries
This patch populates the L1 entries for MT_MEMORY and MT_MEMORY_NONCACHED
types so that at boot-up, we can map memories outside system memory
at page level granularity
Previously the mapping was limiting to section level, which creates
unnecessary additional mapping for which physical memory may not
present. On the newer ARM with speculation, this is dangerous and can
result in untraceable aborts.
The patch is based on inputs from Russell King
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Russell King <linux@arm.linux.org.uk>
---
arch/arm/mm/mmu.c | 17 +++++++++++++++--
1 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 6e1c4f6..3e986a6 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -246,6 +246,9 @@ static struct mem_type mem_types[] = {
.domain = DOMAIN_USER,
},
[MT_MEMORY] = {
+ .prot_pte = L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |
+ L_PTE_USER | L_PTE_EXEC,
+ .prot_l1 = PMD_TYPE_TABLE,
.prot_sect = PMD_TYPE_SECT | PMD_SECT_AP_WRITE,
.domain = DOMAIN_KERNEL,
},
@@ -254,6 +257,9 @@ static struct mem_type mem_types[] = {
.domain = DOMAIN_KERNEL,
},
[MT_MEMORY_NONCACHED] = {
+ .prot_pte = L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |
+ L_PTE_USER | L_PTE_EXEC | L_PTE_MT_BUFFERABLE,
+ .prot_l1 = PMD_TYPE_TABLE,
.prot_sect = PMD_TYPE_SECT | PMD_SECT_AP_WRITE,
.domain = DOMAIN_KERNEL,
},
@@ -411,9 +417,12 @@ static void __init build_mem_type_table(void)
* Enable CPU-specific coherency if supported.
* (Only available on XSC3 at the moment.)
*/
- if (arch_is_coherent() && cpu_is_xsc3())
+ if (arch_is_coherent() && cpu_is_xsc3()) {
mem_types[MT_MEMORY].prot_sect |= PMD_SECT_S;
-
+ mem_types[MT_MEMORY].prot_pte |= L_PTE_SHARED;
+ mem_types[MT_MEMORY_NONCACHED].prot_sect |= PMD_SECT_S;
+ mem_types[MT_MEMORY_NONCACHED].prot_pte |= L_PTE_SHARED;
+ }
/*
* ARMv6 and above have extended page tables.
*/
@@ -438,7 +447,9 @@ static void __init build_mem_type_table(void)
mem_types[MT_DEVICE_CACHED].prot_sect |= PMD_SECT_S;
mem_types[MT_DEVICE_CACHED].prot_pte |= L_PTE_SHARED;
mem_types[MT_MEMORY].prot_sect |= PMD_SECT_S;
+ mem_types[MT_MEMORY].prot_pte |= L_PTE_SHARED;
mem_types[MT_MEMORY_NONCACHED].prot_sect |= PMD_SECT_S;
+ mem_types[MT_MEMORY_NONCACHED].prot_pte |= L_PTE_SHARED;
#endif
}
@@ -475,6 +486,8 @@ static void __init build_mem_type_table(void)
mem_types[MT_LOW_VECTORS].prot_l1 |= ecc_mask;
mem_types[MT_HIGH_VECTORS].prot_l1 |= ecc_mask;
mem_types[MT_MEMORY].prot_sect |= ecc_mask | cp->pmd;
+ mem_types[MT_MEMORY].prot_pte |= kern_pgprot;
+ mem_types[MT_MEMORY_NONCACHED].prot_sect |= ecc_mask;
mem_types[MT_ROM].prot_sect |= cp->pmd;
switch (cp->pmd) {
--
1.6.0.4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ARM-mmu-Setup-MT_MEMORY-and-MT_MEMORY_NONCACHED-L1.patch
Type: application/octet-stream
Size: 3089 bytes
Desc: 0001-ARM-mmu-Setup-MT_MEMORY-and-MT_MEMORY_NONCACHED-L1.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180619/542cd699/attachment.obj>
^ permalink raw reply related
* Query: Patches break with Microsoft exchange server.
From: viresh kumar @ 2018-06-19 20:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20100809090137.GP13165@mea-ext.zmailer.org>
On 8/9/2010 2:31 PM, Matti Aarnio wrote:
> On Mon, Aug 09, 2010 at 12:26:24PM +0530, viresh kumar wrote:
>> >
>> > I missed this information in my last mail. We are using git send-email for
>> > sending patches. As patches will go through Microsoft exchange server only,
>> > so they are broken.
>> >
> Let your boss complain to your IT keepers.
> "These are Machine-to-Machine messages, they must not be modified!"
>
>
> It would probably be "against corporate policy" to use gmail for these emails...
>
We got one solution: Upgrade Exchange server to SP2.
Lets see if our IT department does this upgradation.
viresh.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Query: Patches break with Microsoft exchange server.
From: Justin P. Mattock @ 2018-06-19 20:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4C5FCBE1.2080303@st.com>
On 08/09/2010 02:35 AM, viresh kumar wrote:
> On 8/9/2010 2:31 PM, Matti Aarnio wrote:
>> On Mon, Aug 09, 2010 at 12:26:24PM +0530, viresh kumar wrote:
>>>>
>>>> I missed this information in my last mail. We are using git send-email for
>>>> sending patches. As patches will go through Microsoft exchange server only,
>>>> so they are broken.
>>>>
>> Let your boss complain to your IT keepers.
>> "These are Machine-to-Machine messages, they must not be modified!"
>>
>>
>> It would probably be "against corporate policy" to use gmail for these emails...
>>
>
> We got one solution: Upgrade Exchange server to SP2.
> Lets see if our IT department does this upgradation.
>
> viresh.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
that or just blast them with some cryptology..i.e. pretty sure if your
message was encapsulated(AH/ESP) they couldn't tweak it.. but then
sending such encryption to a public list would require a _key_ on the
other side.. wishful thinking...
(just a thought)...
:-)
Justin P. Mattock
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Query: Patches break with Microsoft exchange server.
From: David Woodhouse @ 2018-06-19 20:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20100809090137.GP13165@mea-ext.zmailer.org>
On Mon, 2010-08-09 at 12:01 +0300, Matti Aarnio wrote:
> It would probably be "against corporate policy" to use gmail for these
> emails...
If that's the case, then you really *do* need to get your boss to fix
it.
If the company provides a working email account, it makes a certain
amount of sense for them to ask you to use it.
But if all they provide is Microsoft Exchange, that's insane -- what
Exchange provides is *like* email, but it is *not* email. Once you start
trying to use it for real email, you find it's broken by design in a
large number of ways. It makes no sense for them to require that you use
Exchange for Internet email, because that's not what Exchange does.
If my corporate overloads told me I had to use my Exchange "messaging"
account for external email communication, they would get a quite clear
'no' in response. My response may also contain suggestions that they use
certain other objects for purposes for which they were not designed.
Seriously, just use an external email account and ignore the broken
corporate policy. 'Policy' is just a euphemism for not having to think
for yourself.
--
dwmw2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* [RFC PATCH v2] driver core: add a debugfs entry to show deferred devices
From: Greg Kroah-Hartman @ 2018-06-19 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75VdpHdanWJmcwLBRTSDoDkbpPxuAGwwVO0hosXSRn4PUoA@mail.gmail.com>
On Tue, Jun 19, 2018 at 10:55:20PM +0300, Andy Shevchenko wrote:
> On Tue, Jun 19, 2018 at 10:53 PM, Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Tue, Jun 19, 2018 at 9:33 PM, Javier Martinez Canillas
> > <javierm@redhat.com> wrote:
> >> For debugging purposes it may be useful to know what are the devices whose
> >> probe function was deferred. Add a debugfs entry showing that information.
>
> >> +static int deferred_devs_open(struct inode *inode, struct file *file)
> >> +{
> >> + return single_open(file, deferred_devs_show, inode->i_private);
> >> +}
> >> +
> >> +static const struct file_operations deferred_devs_fops = {
> >> + .owner = THIS_MODULE,
> >> + .open = deferred_devs_open,
> >> + .read = seq_read,
> >> + .llseek = seq_lseek,
> >> + .release = single_release,
> >> +};
> >
> > Isn't this DEFINE_SHOW_ATTRIBUTE() ?
>
> Besides that, you are summoning Greg's dark side :-)
> See below.
>
> >> + if (IS_ENABLED(CONFIG_DEBUG_FS)) {
> >> + deferred_devices = debugfs_create_file("deferred_devices",
> >> + 0444, NULL, NULL,
> >> + &deferred_devs_fops);
>
> >> + if (!deferred_devices)
> >> + return -ENOMEM;
>
> This must not prevent the execution. So, the check introduces actually
> a regression.
Awe, you beat me to it :)
Also, I don't usually comment on RFC patches, as that shows the author
really doesn't think that the code is ready to be reviewed/merged...
thanks,
greg k-h
^ permalink raw reply
* [PATCH 0/2] Make badr macro compatible with newer GAS versions
From: Guenter Roeck @ 2018-06-19 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619192633.21846-1-ard.biesheuvel@linaro.org>
On Tue, Jun 19, 2018 at 09:26:31PM +0200, Ard Biesheuvel wrote:
> Work around the mindless and backward incompatible change in GAS that
> prevents us from using a simple addition to set the Thumb bit in local
> symbol references taken using 'adr' instructions (#2)
>
> As a preparatory step, remove badr occurrences in ARM code sequences
> contained in Thumb2 kernels.
>
> Ard Biesheuvel (2):
> ARM: avoid badr macro for switching to Thumb-2 mode
> ARM: assembler: prevent ADR from setting the Thumb bit twice
>
This doesn't work for images built with a toolchain based on gcc 7.3.0
and binutils 2.28.1. It _does_ work for images built with gcc 7.3.0/
binutils 2.30.
Guenter
^ 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