* [PATCH v11 24/27] dt-bindings: timer: new bindings for TI DaVinci timer
From: David Lechner @ 2018-05-18 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518164829.27052-1-david@lechnology.com>
This adds new device tree bindings for the timer IP block of TI
DaVinci-like SoCs.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Lechner <david@lechnology.com>
---
v11 changes:
- remove trailing whitespace
v10 changes:
- changed compatible to "ti,da830-timer"
- added interrupts and interrupt-names properties
- fixed grammatical error
v9 changes:
- new patch in v9
.../bindings/timer/ti,davinci-timer.txt | 37 +++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/timer/ti,davinci-timer.txt
diff --git a/Documentation/devicetree/bindings/timer/ti,davinci-timer.txt b/Documentation/devicetree/bindings/timer/ti,davinci-timer.txt
new file mode 100644
index 000000000000..29bf91ccf5b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/ti,davinci-timer.txt
@@ -0,0 +1,37 @@
+* Device tree bindings for Texas Instruments DaVinci timer
+
+This document provides bindings for the 64-bit timer in the DaVinci
+architecture devices. The timer can be configured as a general-purpose 64-bit
+timer, dual general-purpose 32-bit timers. When configured as dual 32-bit
+timers, each half can operate in conjunction (chain mode) or independently
+(unchained mode) of each other.
+
+The timer is a free running up-counter and can generate interrupts when the
+counter reaches preset counter values.
+
+Also see ../watchdog/davinci-wdt.txt for timers that are configurable as
+watchdog timers.
+
+Required properties:
+
+- compatible : should be "ti,da830-timer".
+- reg : specifies base physical address and count of the registers.
+- interrupts : interrupts generated by the timer.
+- interrupt-names: should be "tint12", "tint34", "cmpint0", "cmpint1",
+ "cmpint2", "cmpint3", "cmpint4", "cmpint5", "cmpint6",
+ "cmpint7" ("cmpintX" may be omitted if not present in the
+ hardware).
+- clocks : the clock feeding the timer clock.
+
+Example:
+
+ clocksource: timer at 20000 {
+ compatible = "ti,da830-timer";
+ reg = <0x20000 0x1000>;
+ interrupts = <21>, <22>, <74>, <75>, <76>, <77>, <78>, <79>,
+ <80>, <81>;
+ interrupt-names = "tint12", "tint34", "cmpint0", "cmpint1",
+ "cmpint2", "cmpint3", "cmpint4", "cmpint5",
+ "cmpint6", "cmpint7";
+ clocks = <&pll0_auxclk>;
+ };
--
2.17.0
^ permalink raw reply related
* [PATCH v11 25/27] ARM: davinci: add device tree support to timer
From: David Lechner @ 2018-05-18 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518164829.27052-1-david@lechnology.com>
This adds device tree support to the davinci timer so that when clocks
are moved to device tree, the timer will still work.
Signed-off-by: David Lechner <david@lechnology.com>
---
v11 changes:
- drop fallback to ref_clk
v10 changes:
- change compatible to "ti,da830-timer"
- remove comment clocks as platform devices
v9 changes:
- none (there were supposed to be changed, but apparently they got squashed
into the next commit - will fix on the next round)
v8 changes:
- none
v7 changes:
- rebased
- add davinci prefix to commit message
v6 changes:
- rebased
arch/arm/mach-davinci/Kconfig | 1 +
arch/arm/mach-davinci/time.c | 15 +++++++++++++++
2 files changed, 16 insertions(+)
diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index ba9912b4dfab..da8a039d65f9 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -59,6 +59,7 @@ config MACH_DA8XX_DT
default y
depends on ARCH_DAVINCI_DA850
select PINCTRL
+ select TIMER_OF
help
Say y here to include support for TI DaVinci DA850 based using
Flattened Device Tree. More information at Documentation/devicetree
diff --git a/arch/arm/mach-davinci/time.c b/arch/arm/mach-davinci/time.c
index 7ea3db0ff062..5a6de5368ab0 100644
--- a/arch/arm/mach-davinci/time.c
+++ b/arch/arm/mach-davinci/time.c
@@ -17,6 +17,7 @@
#include <linux/io.h>
#include <linux/clk.h>
#include <linux/err.h>
+#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/sched_clock.h>
@@ -397,3 +398,17 @@ void __init davinci_timer_init(struct clk *timer_clk)
for (i=0; i< ARRAY_SIZE(timers); i++)
timer32_config(&timers[i]);
}
+
+static int __init of_davinci_timer_init(struct device_node *np)
+{
+ struct clk *clk;
+
+ clk = of_clk_get(np, 0);
+ if (IS_ERR(clk))
+ return PTR_ERR(clk);
+
+ davinci_timer_init(clk);
+
+ return 0;
+}
+TIMER_OF_DECLARE(davinci_timer, "ti,da830-timer", of_davinci_timer_init);
--
2.17.0
^ permalink raw reply related
* [PATCH v11 26/27] ARM: davinci: da8xx-dt: switch to device tree clocks
From: David Lechner @ 2018-05-18 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518164829.27052-1-david@lechnology.com>
This removes all of the clock init code from da8xx-dt.c. This includes
all of the OF_DEV_AUXDATA that was just used for looking up clocks.
Signed-off-by: David Lechner <david@lechnology.com>
---
v11 changes:
- none
v10 changes:
- removed unused header files
- removed arch/arm/mach-davinci/time.c changes accidentally introduced in v9
v9 changes:
- changes to arch/arm/mach-davinci/time.c accidentally got squashed into this
commit. will drop this later.
v8 changes:
- none
v7 changes:
- rebased
- drop of_platform_default_populate(NULL, NULL, NULL)
- add change in pm_domain.c
v6 changes:
- removed misleading statement from commit message
arch/arm/mach-davinci/da8xx-dt.c | 64 -------------------------------
arch/arm/mach-davinci/pm_domain.c | 5 +++
2 files changed, 5 insertions(+), 64 deletions(-)
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 088bc5c0318b..beac80ec4037 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -7,79 +7,16 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
-#include <linux/io.h>
-#include <linux/of_irq.h>
-#include <linux/of_platform.h>
-#include <linux/irqdomain.h>
-#include <linux/platform_data/ti-aemif.h>
#include <asm/mach/arch.h>
#include <mach/common.h>
-#include "cp_intc.h"
#include <mach/da8xx.h>
-static struct of_dev_auxdata da850_aemif_auxdata_lookup[] = {
- OF_DEV_AUXDATA("ti,davinci-nand", 0x62000000, "davinci-nand.0", NULL),
- {}
-};
-
-static struct aemif_platform_data aemif_data = {
- .dev_lookup = da850_aemif_auxdata_lookup,
-};
-
-static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
- OF_DEV_AUXDATA("ti,davinci-i2c", 0x01c22000, "i2c_davinci.1", NULL),
- OF_DEV_AUXDATA("ti,davinci-i2c", 0x01e28000, "i2c_davinci.2", NULL),
- OF_DEV_AUXDATA("ti,davinci-wdt", 0x01c21000, "davinci-wdt", NULL),
- OF_DEV_AUXDATA("ti,da830-mmc", 0x01c40000, "da830-mmc.0", NULL),
- OF_DEV_AUXDATA("ti,da850-ehrpwm", 0x01f00000, "ehrpwm.0", NULL),
- OF_DEV_AUXDATA("ti,da850-ehrpwm", 0x01f02000, "ehrpwm.1", NULL),
- OF_DEV_AUXDATA("ti,da850-ecap", 0x01f06000, "ecap.0", NULL),
- OF_DEV_AUXDATA("ti,da850-ecap", 0x01f07000, "ecap.1", NULL),
- OF_DEV_AUXDATA("ti,da850-ecap", 0x01f08000, "ecap.2", NULL),
- OF_DEV_AUXDATA("ti,da830-spi", 0x01c41000, "spi_davinci.0", NULL),
- OF_DEV_AUXDATA("ti,da830-spi", 0x01f0e000, "spi_davinci.1", NULL),
- OF_DEV_AUXDATA("ns16550a", 0x01c42000, "serial8250.0", NULL),
- OF_DEV_AUXDATA("ns16550a", 0x01d0c000, "serial8250.1", NULL),
- OF_DEV_AUXDATA("ns16550a", 0x01d0d000, "serial8250.2", NULL),
- OF_DEV_AUXDATA("ti,davinci_mdio", 0x01e24000, "davinci_mdio.0", NULL),
- OF_DEV_AUXDATA("ti,davinci-dm6467-emac", 0x01e20000, "davinci_emac.1",
- NULL),
- OF_DEV_AUXDATA("ti,da830-mcasp-audio", 0x01d00000, "davinci-mcasp.0", NULL),
- OF_DEV_AUXDATA("ti,da850-aemif", 0x68000000, "ti-aemif", &aemif_data),
- OF_DEV_AUXDATA("ti,da850-tilcdc", 0x01e13000, "da8xx_lcdc.0", NULL),
- OF_DEV_AUXDATA("ti,da830-ohci", 0x01e25000, "ohci-da8xx", NULL),
- OF_DEV_AUXDATA("ti,da830-musb", 0x01e00000, "musb-da8xx", NULL),
- OF_DEV_AUXDATA("ti,da830-usb-phy", 0x01c1417c, "da8xx-usb-phy", NULL),
- OF_DEV_AUXDATA("ti,da850-ahci", 0x01e18000, "ahci_da850", NULL),
- OF_DEV_AUXDATA("ti,da850-vpif", 0x01e17000, "vpif", NULL),
- OF_DEV_AUXDATA("ti,da850-dsp", 0x11800000, "davinci-rproc.0", NULL),
- {}
-};
-
#ifdef CONFIG_ARCH_DAVINCI_DA850
static void __init da850_init_machine(void)
{
- /* All existing boards use 100MHz SATA refclkpn */
- static const unsigned long sata_refclkpn = 100 * 1000 * 1000;
-
- int ret;
-
- da850_register_clocks();
-
- ret = da8xx_register_usb_phy_clocks();
- if (ret)
- pr_warn("%s: USB PHY CLK registration failed: %d\n",
- __func__, ret);
-
- ret = da850_register_sata_refclk(sata_refclkpn);
- if (ret)
- pr_warn("%s: registering SATA REFCLK failed: %d",
- __func__, ret);
-
- of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
davinci_pm_init();
pdata_quirks_init();
}
@@ -94,7 +31,6 @@ static const char *const da850_boards_compat[] __initconst = {
DT_MACHINE_START(DA850_DT, "Generic DA850/OMAP-L138/AM18x")
.map_io = da850_init,
- .init_time = da850_init_time,
.init_machine = da850_init_machine,
.dt_compat = da850_boards_compat,
.init_late = davinci_init_late,
diff --git a/arch/arm/mach-davinci/pm_domain.c b/arch/arm/mach-davinci/pm_domain.c
index 78eac2c0c146..e251fd593bfd 100644
--- a/arch/arm/mach-davinci/pm_domain.c
+++ b/arch/arm/mach-davinci/pm_domain.c
@@ -13,6 +13,7 @@
#include <linux/pm_runtime.h>
#include <linux/pm_clock.h>
#include <linux/platform_device.h>
+#include <linux/of.h>
static struct dev_pm_domain davinci_pm_domain = {
.ops = {
@@ -28,6 +29,10 @@ static struct pm_clk_notifier_block platform_bus_notifier = {
static int __init davinci_pm_runtime_init(void)
{
+ if (of_have_populated_dt())
+ return 0;
+
+ /* Use pm_clk as fallback if we're not using genpd. */
pm_clk_add_notifier(&platform_bus_type, &platform_bus_notifier);
return 0;
--
2.17.0
^ permalink raw reply related
* [PATCH v11 27/27] ARM: dts: da850: Add clocks
From: David Lechner @ 2018-05-18 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518164829.27052-1-david@lechnology.com>
This adds clock provider nodes for da850 and wires them up to all of the
devices.
Signed-off-by: David Lechner <david@lechnology.com>
---
v11 changes:
- rebased
v10 changes:
- change compatible to "ti,da830-timer" and add interrupt and interrupt-names
properties to new clocksource timer node
v9 changes:
- change mcasp and vpif nodes from clocks to power-domains
v8 changes:
- fix typo in clock-names property of psc0
- added power-domains properties to nodes that define that property in their
device tree bindings
v7 changes:
- move ref_clk frequency to board-specific DT files
- enable sata_refclk in da850-lcdk.dts
- drop async2 fixed factor clock
- add power-domains for devices that use them
- fix USB PHY clock-names property
- move assigned-clocks to PSC device node
- drop clocks property from devices that don't use it (e.g. EDMA)
- add clock to RTC node
- add clock-ranges to usb0 and aemif nodes
- add clock-names property to aemif node
- fix typo in psc1 clock-names
v6 changes:
- updated for device tree bindings changes earlier in this series
- use single async2 clock instead of duplicate fixed factor clocks
- add clock-names property to mdio node
arch/arm/boot/dts/da850-enbw-cmc.dts | 4 +
arch/arm/boot/dts/da850-evm.dts | 4 +
arch/arm/boot/dts/da850-lcdk.dts | 9 ++
arch/arm/boot/dts/da850-lego-ev3.dts | 4 +
arch/arm/boot/dts/da850.dtsi | 168 +++++++++++++++++++++++++++
5 files changed, 189 insertions(+)
diff --git a/arch/arm/boot/dts/da850-enbw-cmc.dts b/arch/arm/boot/dts/da850-enbw-cmc.dts
index 14dff3e188ed..0102ffc5aa53 100644
--- a/arch/arm/boot/dts/da850-enbw-cmc.dts
+++ b/arch/arm/boot/dts/da850-enbw-cmc.dts
@@ -35,6 +35,10 @@
};
};
+&ref_clk {
+ clock-frequency = <24000000>;
+};
+
&edma0 {
ti,edma-reserved-slot-ranges = <32 50>;
};
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 2e817da37fdb..6e0d84fda034 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -63,6 +63,10 @@
};
};
+&ref_clk {
+ clock-frequency = <24000000>;
+};
+
&pmx_core {
status = "okay";
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index 0edf769ea95c..0177e3ed20fe 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -123,6 +123,10 @@
};
};
+&ref_clk {
+ clock-frequency = <24000000>;
+};
+
&pmx_core {
status = "okay";
@@ -175,6 +179,11 @@
status = "okay";
};
+&sata_refclk {
+ status = "okay";
+ clock-frequency = <100000000>;
+};
+
&sata {
status = "okay";
};
diff --git a/arch/arm/boot/dts/da850-lego-ev3.dts b/arch/arm/boot/dts/da850-lego-ev3.dts
index ee3932475ce7..331362a6f01e 100644
--- a/arch/arm/boot/dts/da850-lego-ev3.dts
+++ b/arch/arm/boot/dts/da850-lego-ev3.dts
@@ -191,6 +191,10 @@
};
};
+&ref_clk {
+ clock-frequency = <24000000>;
+};
+
&pmx_core {
status = "okay";
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index f6f1597b03df..de9a8bea100e 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -32,6 +32,25 @@
reg = <0xfffee000 0x2000>;
};
};
+ clocks: clocks {
+ ref_clk: ref_clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-output-names = "ref_clk";
+ };
+ sata_refclk: sata_refclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-output-names = "sata_refclk";
+ status = "disabled";
+ };
+ usb_refclkin: usb_refclkin {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-output-names = "usb_refclkin";
+ status = "disabled";
+ };
+ };
dsp: dsp at 11800000 {
compatible = "ti,da850-dsp";
reg = <0x11800000 0x40000>,
@@ -42,6 +61,7 @@
reg-names = "l2sram", "l1pram", "l1dram", "host1cfg", "chipsig";
interrupt-parent = <&intc>;
interrupts = <28>;
+ clocks = <&psc0 15>;
status = "disabled";
};
soc at 1c00000 {
@@ -52,6 +72,37 @@
ranges = <0x0 0x01c00000 0x400000>;
interrupt-parent = <&intc>;
+ psc0: clock-controller at 10000 {
+ compatible = "ti,da850-psc0";
+ reg = <0x10000 0x1000>;
+ #clock-cells = <1>;
+ #power-domain-cells = <1>;
+ clocks = <&pll0_sysclk 1>, <&pll0_sysclk 2>,
+ <&pll0_sysclk 4>, <&pll0_sysclk 6>,
+ <&async1_clk>;
+ clock-names = "pll0_sysclk1", "pll0_sysclk2",
+ "pll0_sysclk4", "pll0_sysclk6",
+ "async1";
+ };
+ pll0: clock-controller at 11000 {
+ compatible = "ti,da850-pll0";
+ reg = <0x11000 0x1000>;
+ clocks = <&ref_clk>, <&pll1_sysclk 3>;
+ clock-names = "clksrc", "extclksrc";
+
+ pll0_pllout: pllout {
+ #clock-cells = <0>;
+ };
+ pll0_sysclk: sysclk {
+ #clock-cells = <1>;
+ };
+ pll0_auxclk: auxclk {
+ #clock-cells = <0>;
+ };
+ pll0_obsclk: obsclk {
+ #clock-cells = <0>;
+ };
+ };
pmx_core: pinmux at 14120 {
compatible = "pinctrl-single";
reg = <0x14120 0x50>;
@@ -281,8 +332,41 @@
usb_phy: usb-phy {
compatible = "ti,da830-usb-phy";
#phy-cells = <1>;
+ clocks = <&usb_phy_clk 0>, <&usb_phy_clk 1>;
+ clock-names = "usb0_clk48", "usb1_clk48";
status = "disabled";
};
+ usb_phy_clk: usb-phy-clocks {
+ compatible = "ti,da830-usb-phy-clocks";
+ #clock-cells = <1>;
+ clocks = <&psc1 1>, <&usb_refclkin>,
+ <&pll0_auxclk>;
+ clock-names = "fck", "usb_refclkin", "auxclk";
+ };
+ ehrpwm_tbclk: ehrpwm_tbclk {
+ compatible = "ti,da830-tbclksync";
+ #clock-cells = <0>;
+ clocks = <&psc1 17>;
+ clock-names = "fck";
+ };
+ div4p5_clk: div4.5 {
+ compatible = "ti,da830-div4p5ena";
+ #clock-cells = <0>;
+ clocks = <&pll0_pllout>;
+ clock-names = "pll0_pllout";
+ };
+ async1_clk: async1 {
+ compatible = "ti,da850-async1-clksrc";
+ #clock-cells = <0>;
+ clocks = <&pll0_sysclk 3>, <&div4p5_clk>;
+ clock-names = "pll0_sysclk3", "div4.5";
+ };
+ async3_clk: async3 {
+ compatible = "ti,da850-async3-clksrc";
+ #clock-cells = <0>;
+ clocks = <&pll0_sysclk 2>, <&pll1_sysclk 2>;
+ clock-names = "pll0_sysclk2", "pll1_sysclk2";
+ };
};
edma0: edma at 0 {
compatible = "ti,edma3-tpcc";
@@ -294,18 +378,21 @@
#dma-cells = <2>;
ti,tptcs = <&edma0_tptc0 7>, <&edma0_tptc1 0>;
+ power-domains = <&psc0 0>;
};
edma0_tptc0: tptc at 8000 {
compatible = "ti,edma3-tptc";
reg = <0x8000 0x400>;
interrupts = <13>;
interrupt-names = "edm3_tcerrint";
+ power-domains = <&psc0 1>;
};
edma0_tptc1: tptc at 8400 {
compatible = "ti,edma3-tptc";
reg = <0x8400 0x400>;
interrupts = <32>;
interrupt-names = "edm3_tcerrint";
+ power-domains = <&psc0 2>;
};
edma1: edma at 230000 {
compatible = "ti,edma3-tpcc";
@@ -317,12 +404,14 @@
#dma-cells = <2>;
ti,tptcs = <&edma1_tptc0 7>;
+ power-domains = <&psc1 0>;
};
edma1_tptc0: tptc at 238000 {
compatible = "ti,edma3-tptc";
reg = <0x238000 0x400>;
interrupts = <95>;
interrupt-names = "edm3_tcerrint";
+ power-domains = <&psc1 21>;
};
serial0: serial at 42000 {
compatible = "ti,da830-uart", "ns16550a";
@@ -330,6 +419,8 @@
reg-io-width = <4>;
reg-shift = <2>;
interrupts = <25>;
+ clocks = <&psc0 9>;
+ power-domains = <&psc0 9>;
status = "disabled";
};
serial1: serial at 10c000 {
@@ -338,6 +429,8 @@
reg-io-width = <4>;
reg-shift = <2>;
interrupts = <53>;
+ clocks = <&psc1 12>;
+ power-domains = <&psc1 12>;
status = "disabled";
};
serial2: serial at 10d000 {
@@ -346,6 +439,8 @@
reg-io-width = <4>;
reg-shift = <2>;
interrupts = <61>;
+ clocks = <&psc1 13>;
+ power-domains = <&psc1 13>;
status = "disabled";
};
rtc0: rtc at 23000 {
@@ -353,6 +448,8 @@
reg = <0x23000 0x1000>;
interrupts = <19
19>;
+ clocks = <&pll0_auxclk>;
+ clock-names = "int-clk";
status = "disabled";
};
i2c0: i2c at 22000 {
@@ -361,6 +458,7 @@
interrupts = <15>;
#address-cells = <1>;
#size-cells = <0>;
+ clocks = <&pll0_auxclk>;
status = "disabled";
};
i2c1: i2c at 228000 {
@@ -369,11 +467,21 @@
interrupts = <51>;
#address-cells = <1>;
#size-cells = <0>;
+ clocks = <&psc1 11>;
+ power-domains = <&psc1 11>;
status = "disabled";
};
+ clocksource: timer at 20000 {
+ compatible = "ti,da830-timer";
+ reg = <0x20000 0x1000>;
+ interrupts = <12>, <13>;
+ interrupt-names = "tint12", "tint34";
+ clocks = <&pll0_auxclk>;
+ };
wdt: wdt at 21000 {
compatible = "ti,davinci-wdt";
reg = <0x21000 0x1000>;
+ clocks = <&pll0_auxclk>;
status = "disabled";
};
mmc0: mmc at 40000 {
@@ -384,12 +492,14 @@
interrupts = <16>;
dmas = <&edma0 16 0>, <&edma0 17 0>;
dma-names = "rx", "tx";
+ clocks = <&psc0 5>;
status = "disabled";
};
vpif: video at 217000 {
compatible = "ti,da850-vpif";
reg = <0x217000 0x1000>;
interrupts = <92>;
+ power-domains = <&psc1 9>;
status = "disabled";
/* VPIF capture port */
@@ -412,6 +522,7 @@
interrupts = <72>;
dmas = <&edma1 28 0>, <&edma1 29 0>;
dma-names = "rx", "tx";
+ clocks = <&psc1 18>;
status = "disabled";
};
ehrpwm0: pwm at 300000 {
@@ -419,6 +530,8 @@
"ti,am33xx-ehrpwm";
#pwm-cells = <3>;
reg = <0x300000 0x2000>;
+ clocks = <&psc1 17>, <&ehrpwm_tbclk>;
+ clock-names = "fck", "tbclk";
status = "disabled";
};
ehrpwm1: pwm at 302000 {
@@ -426,6 +539,8 @@
"ti,am33xx-ehrpwm";
#pwm-cells = <3>;
reg = <0x302000 0x2000>;
+ clocks = <&psc1 17>, <&ehrpwm_tbclk>;
+ clock-names = "fck", "tbclk";
status = "disabled";
};
ecap0: ecap at 306000 {
@@ -433,6 +548,8 @@
"ti,am33xx-ecap";
#pwm-cells = <3>;
reg = <0x306000 0x80>;
+ clocks = <&psc1 20>;
+ clock-names = "fck";
status = "disabled";
};
ecap1: ecap at 307000 {
@@ -440,6 +557,8 @@
"ti,am33xx-ecap";
#pwm-cells = <3>;
reg = <0x307000 0x80>;
+ clocks = <&psc1 20>;
+ clock-names = "fck";
status = "disabled";
};
ecap2: ecap at 308000 {
@@ -447,6 +566,8 @@
"ti,am33xx-ecap";
#pwm-cells = <3>;
reg = <0x308000 0x80>;
+ clocks = <&psc1 20>;
+ clock-names = "fck";
status = "disabled";
};
spi0: spi at 41000 {
@@ -459,6 +580,8 @@
interrupts = <20>;
dmas = <&edma0 14 0>, <&edma0 15 0>;
dma-names = "rx", "tx";
+ clocks = <&psc0 4>;
+ power-domains = <&psc0 4>;
status = "disabled";
};
spi1: spi at 30e000 {
@@ -471,6 +594,8 @@
interrupts = <56>;
dmas = <&edma0 18 0>, <&edma0 19 0>;
dma-names = "rx", "tx";
+ clocks = <&psc1 10>;
+ power-domains = <&psc1 10>;
status = "disabled";
};
usb0: usb at 200000 {
@@ -482,6 +607,8 @@
dr_mode = "otg";
phys = <&usb_phy 0>;
phy-names = "usb-phy";
+ clocks = <&psc1 1>;
+ clock-ranges;
status = "disabled";
#address-cells = <1>;
@@ -512,13 +639,31 @@
compatible = "ti,da850-ahci";
reg = <0x218000 0x2000>, <0x22c018 0x4>;
interrupts = <67>;
+ clocks = <&psc1 8>, <&sata_refclk>;
+ clock-names = "fck", "refclk";
status = "disabled";
};
+ pll1: clock-controller at 21a000 {
+ compatible = "ti,da850-pll1";
+ reg = <0x21a000 0x1000>;
+ clocks = <&ref_clk>;
+ clock-names = "clksrc";
+
+ pll1_sysclk: sysclk {
+ #clock-cells = <1>;
+ };
+ pll1_obsclk: obsclk {
+ #clock-cells = <0>;
+ };
+ };
mdio: mdio at 224000 {
compatible = "ti,davinci_mdio";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x224000 0x1000>;
+ clocks = <&psc1 5>;
+ clock-names = "fck";
+ power-domains = <&psc1 5>;
status = "disabled";
};
eth0: ethernet at 220000 {
@@ -534,6 +679,8 @@
35
36
>;
+ clocks = <&psc1 5>;
+ power-domains = <&psc1 5>;
status = "disabled";
};
usb1: usb at 225000 {
@@ -542,6 +689,7 @@
interrupts = <59>;
phys = <&usb_phy 1>;
phy-names = "usb-phy";
+ clocks = <&psc1 2>;
status = "disabled";
};
gpio: gpio at 226000 {
@@ -556,6 +704,8 @@
49 IRQ_TYPE_EDGE_BOTH 50 IRQ_TYPE_EDGE_BOTH>;
ti,ngpio = <144>;
ti,davinci-gpio-unbanked = <0>;
+ clocks = <&psc1 3>;
+ clock-names = "gpio";
status = "disabled";
interrupt-controller;
#interrupt-cells = <2>;
@@ -704,6 +854,17 @@
<&pmx_core 142 147 1>,
<&pmx_core 143 146 1>;
};
+ psc1: clock-controller at 227000 {
+ compatible = "ti,da850-psc1";
+ reg = <0x227000 0x1000>;
+ #clock-cells = <1>;
+ #power-domain-cells = <1>;
+ clocks = <&pll0_sysclk 2>, <&pll0_sysclk 4>,
+ <&async3_clk>;
+ clock-names = "pll0_sysclk2", "pll0_sysclk4", "async3";
+ assigned-clocks = <&async3_clk>;
+ assigned-clock-parents = <&pll1_sysclk 2>;
+ };
pinconf: pin-controller at 22c00c {
compatible = "ti,da850-pupd";
reg = <0x22c00c 0x8>;
@@ -717,6 +878,7 @@
reg-names = "mpu", "dat";
interrupts = <54>;
interrupt-names = "common";
+ power-domains = <&psc1 7>;
status = "disabled";
dmas = <&edma0 1 1>,
<&edma0 0 1>;
@@ -728,6 +890,9 @@
reg = <0x213000 0x1000>;
interrupts = <52>;
max-pixelclock = <37500>;
+ clocks = <&psc1 16>;
+ clock-names = "fck";
+ power-domains = <&psc1 16>;
status = "disabled";
};
};
@@ -739,6 +904,9 @@
reg = <0x68000000 0x00008000>;
ranges = <0 0 0x60000000 0x08000000
1 0 0x68000000 0x00008000>;
+ clocks = <&psc0 3>;
+ clock-names = "aemif";
+ clock-ranges;
status = "disabled";
};
memctrl: memory-controller at b0000000 {
--
2.17.0
^ permalink raw reply related
* [GIT PULL] ARM: mvebu: arm64 for v4.18 (#1)
From: Gregory CLEMENT @ 2018-05-18 16:49 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Here is the first pull request for arm64 for mvebu for v4.18.
Gregory
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the Git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-arm64-4.18-1
for you to fetch changes up to 3eb0a48af488b5e83d2986943a1b6905ca753571:
arm64: defconfig: enable the Armada thermal driver (2018-05-16 20:08:31 +0200)
----------------------------------------------------------------
mvebu arm64 for 4.18 (part 1)
Adding thermal for Armada 7K/8K and SPI for Armada 3700
----------------------------------------------------------------
Antoine Tenart (1):
arm64: defconfig: enable the Armada thermal driver
Gregory CLEMENT (1):
arm64: defconfig: enable CONFIG_SPI_ARMADA_3700
arch/arm64/configs/defconfig | 2 ++
1 file changed, 2 insertions(+)
^ permalink raw reply
* [GIT PULL] ARM: mvebu: dt for v4.18 (#1)
From: Gregory CLEMENT @ 2018-05-18 16:50 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Here is the first pull request for dt for mvebu for v4.18.
Gregory
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the Git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-dt-4.18-1
for you to fetch changes up to 163043ab55210dbb92e36c1220a721f404df6834:
ARM: dts: armada-xp-98dx: Add NAND pinctrl information (2018-05-18 18:36:57 +0200)
----------------------------------------------------------------
mvebu dt for 4.18 (part 1)
- Update 32-bit Marvell EBU NAND DT nodes with new bindings
- Add NAND pinctrl information for the Armada 98DX3236 and variants
----------------------------------------------------------------
Chris Packham (1):
ARM: dts: armada-xp-98dx: Add NAND pinctrl information
Miquel Raynal (4):
ARM: dts: armada-370-xp: update NAND node with new bindings
ARM: dts: armada-375: update NAND node with new bindings
ARM: dts: armada-38x: update NAND node with new bindings
ARM: dts: armada-39x: update NAND node with new bindings
arch/arm/boot/dts/armada-370-db.dts | 57 ++++----
arch/arm/boot/dts/armada-370-dlink-dns327l.dts | 120 ++++++++--------
arch/arm/boot/dts/armada-370-mirabox.dts | 51 ++++---
arch/arm/boot/dts/armada-370-netgear-rn102.dts | 90 ++++++------
arch/arm/boot/dts/armada-370-netgear-rn104.dts | 90 ++++++------
arch/arm/boot/dts/armada-370-rd.dts | 52 ++++---
arch/arm/boot/dts/armada-370-seagate-nas-xbay.dtsi | 64 +++++----
arch/arm/boot/dts/armada-370-xp.dtsi | 6 +-
arch/arm/boot/dts/armada-375-db.dts | 50 ++++---
arch/arm/boot/dts/armada-375.dtsi | 6 +-
arch/arm/boot/dts/armada-385-db-ap.dts | 69 ++++-----
arch/arm/boot/dts/armada-385-linksys-caiman.dts | 129 +++++++++--------
arch/arm/boot/dts/armada-385-linksys-cobra.dts | 129 +++++++++--------
arch/arm/boot/dts/armada-385-linksys-rango.dts | 141 ++++++++++---------
arch/arm/boot/dts/armada-385-linksys-shelby.dts | 129 +++++++++--------
arch/arm/boot/dts/armada-385-linksys.dtsi | 16 ++-
arch/arm/boot/dts/armada-388-db.dts | 55 +++++---
arch/arm/boot/dts/armada-38x.dtsi | 6 +-
arch/arm/boot/dts/armada-390-db.dts | 66 +++++----
arch/arm/boot/dts/armada-395-gp.dts | 74 +++++-----
arch/arm/boot/dts/armada-398-db.dts | 60 ++++----
arch/arm/boot/dts/armada-39x.dtsi | 6 +-
arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 13 ++
arch/arm/boot/dts/armada-xp-db-dxbc2.dts | 2 +-
arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts | 2 +-
arch/arm/boot/dts/armada-xp-db.dts | 2 +-
arch/arm/boot/dts/armada-xp-gp.dts | 2 +-
arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 2 +-
arch/arm/boot/dts/armada-xp-linksys-mamba.dts | 156 +++++++++++----------
arch/arm/boot/dts/armada-xp-netgear-rn2120.dts | 90 ++++++------
30 files changed, 948 insertions(+), 787 deletions(-)
^ permalink raw reply
* [GIT PULL] ARM: mvebu: dt64 for v4.18 (#1)
From: Gregory CLEMENT @ 2018-05-18 16:50 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Here is the first pull request for dt64 for mvebu for v4.18.
Gregory
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the Git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-dt64-4.18-1
for you to fetch changes up to bd473ecda24c6214868d58500c4d7569f6597946:
arm64: dts: marvell: armada-37xx: mark the gpio controllers as irq controller (2018-05-18 18:35:16 +0200)
----------------------------------------------------------------
mvebu dt64 for 4.18 (part 1)
- Allow using Armada 3700 gpio controller as interrupt one too
- Describe SPI flash on the EspressoBin
- Mark ahci as dma-coherent for Armada 7K/8K
- Add 10G interface support Armada 7K/8K based boards (including MacBin)
----------------------------------------------------------------
Antoine Tenart (3):
arm64: dts: marvell: mcbin: enable the fourth network interface
arm64: dts: marvell: 8040-db: describe the 10G interfaces as fixed-link
arm64: dts: marvell: 7040-db: describe the 10G interface as fixed-link
Ellie Reeves (1):
arm64: dts: armada-3720-espressobin: wire up spi flash
Mark Kettenis (1):
arm64: dts: marvell: mark CP110 ahci as dma-coherent
Russell King (1):
arm64: dts: marvell: mcbin: add 10G SFP support
Uwe Kleine-K?nig (1):
arm64: dts: marvell: armada-37xx: mark the gpio controllers as irq controller
.../boot/dts/marvell/armada-3720-espressobin.dts | 27 +++++++++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 6 ++
arch/arm64/boot/dts/marvell/armada-7040-db.dts | 5 ++
arch/arm64/boot/dts/marvell/armada-8040-db.dts | 10 ++++
arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 70 ++++++++++++++++++++++
arch/arm64/boot/dts/marvell/armada-cp110.dtsi | 1 +
6 files changed, 119 insertions(+)
^ permalink raw reply
* [PATCH 2/2] pwm: stm32: initialize raw local variables
From: Randy Dunlap @ 2018-05-18 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526657044-14879-3-git-send-email-fabrice.gasnier@st.com>
On 05/18/2018 08:24 AM, Fabrice Gasnier wrote:
> This removes build warning when COMPILE_TEST=y and MFD_STM32_TIMERS=n
> in drivers/pwm/pwm-stm32.c. In function 'stm32_pwm_capture' 'raw_prd' and
> 'raw_dty' may be used uninitialized in this function
> [-Wmaybe-uninitialized]
>
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.
> ---
> drivers/pwm/pwm-stm32.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
> index 60bfc07..09383c6 100644
> --- a/drivers/pwm/pwm-stm32.c
> +++ b/drivers/pwm/pwm-stm32.c
> @@ -170,7 +170,7 @@ static int stm32_pwm_capture(struct pwm_chip *chip, struct pwm_device *pwm,
> unsigned long long prd, div, dty;
> unsigned long rate;
> unsigned int psc = 0, icpsc, scale;
> - u32 raw_prd, raw_dty;
> + u32 raw_prd = 0, raw_dty = 0;
> int ret = 0;
>
> mutex_lock(&priv->lock);
>
--
~Randy
^ permalink raw reply
* [PATCH 1/2] mfd: stm32-timers: fix pwm-stm32 linker issue with COMPILE_TEST
From: Randy Dunlap @ 2018-05-18 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526657044-14879-2-git-send-email-fabrice.gasnier@st.com>
On 05/18/2018 08:24 AM, Fabrice Gasnier wrote:
> This is seen when COMPILE_TEST=y and MFD_STM32_TIMERS=n.
> drivers/pwm/pwm-stm32.o: In function 'stm32_pwm_raw_capture':
> pwm-stm32.c:... undefined reference to 'stm32_timers_dma_burst_read'
> Fixes: 0c6609805b63 ("mfd: stm32-timers: Add support for DMAs")
>
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.
> ---
> include/linux/mfd/stm32-timers.h | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/include/linux/mfd/stm32-timers.h b/include/linux/mfd/stm32-timers.h
> index 9da1d7e..067d146 100644
> --- a/include/linux/mfd/stm32-timers.h
> +++ b/include/linux/mfd/stm32-timers.h
> @@ -124,8 +124,20 @@ struct stm32_timers {
> struct stm32_timers_dma dma; /* Only to be used by the parent */
> };
>
> +#if IS_REACHABLE(CONFIG_MFD_STM32_TIMERS)
> int stm32_timers_dma_burst_read(struct device *dev, u32 *buf,
> enum stm32_timers_dmas id, u32 reg,
> unsigned int num_reg, unsigned int bursts,
> unsigned long tmo_ms);
> +#else
> +static inline int stm32_timers_dma_burst_read(struct device *dev, u32 *buf,
> + enum stm32_timers_dmas id,
> + u32 reg,
> + unsigned int num_reg,
> + unsigned int bursts,
> + unsigned long tmo_ms)
> +{
> + return -ENODEV;
> +}
> +#endif
> #endif
>
--
~Randy
^ permalink raw reply
* [PATCH] arm64: kvm: use -fno-jump-tables with clang
From: Sami Tolvanen @ 2018-05-18 17:02 UTC (permalink / raw)
To: linux-arm-kernel
Starting with LLVM r308050, clang generates a jump table with EL1
virtual addresses in __init_stage2_translation, which results in a
kernel panic when booting at EL2:
Kernel panic - not syncing: HYP panic:
PS:800003c9 PC:ffff0000089e6fd8 ESR:86000004
FAR:ffff0000089e6fd8 HPFAR:0000000009825000 PAR:0000000000000000
VCPU:000804fc20001221
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc7-dirty #3
Hardware name: ARM Juno development board (r1) (DT)
Call trace:
[<ffff000008088ea4>] dump_backtrace+0x0/0x34c
[<ffff000008089208>] show_stack+0x18/0x20
[<ffff0000089c73ec>] dump_stack+0xc4/0xfc
[<ffff0000080c8e1c>] panic+0x138/0x2b4
[<ffff0000080c8ce4>] panic+0x0/0x2b4
SMP: stopping secondary CPUs
SMP: failed to stop secondary CPUs 0-3,5
Kernel Offset: disabled
CPU features: 0x002086
Memory Limit: none
---[ end Kernel panic - not syncing: HYP panic:
PS:800003c9 PC:ffff0000089e6fd8 ESR:86000004
FAR:ffff0000089e6fd8 HPFAR:0000000009825000 PAR:0000000000000000
VCPU:000804fc20001221
This change adds -fno-jump-tables to arm64/hyp to work around the
bug.
Suggested-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
arch/arm64/kvm/hyp/Makefile | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/kvm/hyp/Makefile b/arch/arm64/kvm/hyp/Makefile
index 4313f74753332..745b3255e7832 100644
--- a/arch/arm64/kvm/hyp/Makefile
+++ b/arch/arm64/kvm/hyp/Makefile
@@ -5,6 +5,10 @@
ccflags-y += -fno-stack-protector -DDISABLE_BRANCH_PROFILING
+ifeq ($(cc-name),clang)
+ccflags-y += -fno-jump-tables
+endif
+
KVM=../../../../virt/kvm
obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/vgic-v3-sr.o
--
2.17.0.441.gb46fe60e1d-goog
^ permalink raw reply related
* [PATCH] arm64: dts: specify 1.8V EMMC capabilities for bcm958742k
From: Florian Fainelli @ 2018-05-18 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526656880-8795-1-git-send-email-scott.branden@broadcom.com>
On Fri, 18 May 2018 08:21:20 -0700, Scott Branden <scott.branden@broadcom.com> wrote:
> Specify 1.8V EMMC capabilities for bcm958742k board to indicate support
> for UHS mode.
>
> Fixes: d4b4aba6be8a ("arm64: dts: Initial DTS files for Broadcom Stingray SOC")
> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
> ---
Applied to devicetree-arm64/fixes, thanks!
--
Florian
^ permalink raw reply
* dma_sync_*_for_cpu and direction=TO_DEVICE (was Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation)
From: Vineet Gupta @ 2018-05-18 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bad125dff49f6e49c895e818c9d1abb346a46e8e.camel@synopsys.com>
On 05/18/2018 06:11 AM, Alexey Brodkin wrote:
> void arch_sync_dma_for_device(struct device *dev, phys_addr_t paddr,
> size_t size, enum dma_data_direction dir)
> {
> + if (dir != DMA_TO_DEVICE){
> + dump_stack();
> + printk(" *** %s@%d: DMA direction is %s instead of %s\n",
> + __func__, __LINE__, dir_to_str(dir), dir_to_str(DMA_TO_DEVICE));
> + }
> +
> return _dma_cache_sync(dev, paddr, size, dir);
> }
>
> void arch_sync_dma_for_cpu(struct device *dev, phys_addr_t paddr,
> size_t size, enum dma_data_direction dir)
> {
> + if (dir != DMA_FROM_DEVICE) {
> + dump_stack();
> + printk(" *** %s@%d: DMA direction is %s instead of %s\n",
> + __func__, __LINE__, dir_to_str(dir), dir_to_str(DMA_FROM_DEVICE));
> + }
> +
> return _dma_cache_sync(dev, paddr, size, dir);
> }
...
> In case of MMC/DW_MCI (AKA DesignWare MobileStorage controller) that's an execution flow:
> 1) __dw_mci_start_request()
> 2) dw_mci_pre_dma_transfer()
> 3) dma_map_sg(..., mmc_get_dma_dir(data))
>
> Note mmc_get_dma_dir() is just "data->flags & MMC_DATA_WRITE ? DMA_TO_DEVICE : DMA_FROM_DEVICE".
> I.e. if we're preparing for sending data dma_noncoherent_map_sg() will have DMA_TO_DEVICE which
> is quite OK for passing to dma_noncoherent_sync_sg_for_device() but in case of reading we'll have
> DMA_FROM_DEVICE which we'll pass to dma_noncoherent_sync_sg_for_device() in dma_noncoherent_map_sg().
>
> I'd say this is not entirely correct because IMHO arch_sync_dma_for_cpu() is supposed to only be used
> in case of DMA_FROM_DEVICE and arch_sync_dma_for_device() only in case of DMA_TO_DEVICE.
So roughly 10 years ago, some kernel rookie name Vineet Gupta, asked the exact
same question :-)
http://kernelnewbies.kernelnewbies.narkive.com/aGW1QcDv/query-about-dma-sync-for-cpu-and-direction-to-device
I never understood the need for this direction. And if memory serves me right, at
that time I was seeing twice the amount of cache flushing !
> But the real fix of my problem is:
> ---------------------------------------->8------------------------------------
> --- a/lib/dma-noncoherent.c
> +++ b/lib/dma-noncoherent.c
> @@ -35,7 +35,7 @@ static dma_addr_t dma_noncoherent_map_page(struct device *dev, struct page *page
>
> addr = dma_direct_map_page(dev, page, offset, size, dir, attrs);
> if (!dma_mapping_error(dev, addr) && !(attrs & DMA_ATTR_SKIP_CPU_SYNC))
> - arch_sync_dma_for_device(dev, page_to_phys(page), size, dir);
> + arch_sync_dma_for_device(dev, page_to_phys(page) + offset, size, dir);
> return addr;
> }
> ---------------------------------------->8------------------------------------
>
> You seem to lost an offset in the page so if we happen to have a buffer not aligned to
> a page boundary then we were obviously corrupting data outside our data :)
Neat !
^ permalink raw reply
* [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation
From: Vineet Gupta @ 2018-05-18 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518132731.GA31125@lst.de>
On 05/18/2018 06:23 AM, hch at lst.de wrote:
> Fri, May 18, 2018 at 01:03:46PM +0000, Alexey Brodkin wrote:
>> Note mmc_get_dma_dir() is just "data->flags & MMC_DATA_WRITE ? DMA_TO_DEVICE : DMA_FROM_DEVICE".
>> I.e. if we're preparing for sending data dma_noncoherent_map_sg() will have DMA_TO_DEVICE which
>> is quite OK for passing to dma_noncoherent_sync_sg_for_device() but in case of reading we'll have
>> DMA_FROM_DEVICE which we'll pass to dma_noncoherent_sync_sg_for_device() in dma_noncoherent_map_sg().
>>
>> I'd say this is not entirely correct because IMHO arch_sync_dma_for_cpu() is supposed to only be used
>> in case of DMA_FROM_DEVICE and arch_sync_dma_for_device() only in case of DMA_TO_DEVICE.
> arc overrides the dir paramter of the dma_sync_single_for_device/
> dma_sync_single_for_cpu calls. My patches dropped that, and I have
> restored that, and audit for the other architectures is pending.
Right, for now lets retain that and do a sweeping audit of @direction - to me it
seems extraneous (as it did 10 years ago), but I'm not an expert in this are so
perhaps it is needed for some device / arches and it would be good to understand
that finally.
> That being said the existing arc code still looks rather odd as it
> didn't do the same thing for the scatterlist versions of the calls.
> I've thrown in a few patches into my new tree to make the sg versions
> make the normal calls, and to clean up the area a bit.
Not calling names or anything here, but it doesn't exist for sg variants, because
I didn't write that code :-)
It was introduced by your commi:
2016-01-20 052c96dbe33b arc: convert to dma_map_ops
^ permalink raw reply
* [PATCH] arm64: kvm: use -fno-jump-tables with clang
From: Marc Zyngier @ 2018-05-18 17:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518170202.11458-1-samitolvanen@google.com>
On 18/05/18 18:02, Sami Tolvanen wrote:
> Starting with LLVM r308050, clang generates a jump table with EL1
> virtual addresses in __init_stage2_translation, which results in a
> kernel panic when booting at EL2:
>
> Kernel panic - not syncing: HYP panic:
> PS:800003c9 PC:ffff0000089e6fd8 ESR:86000004
> FAR:ffff0000089e6fd8 HPFAR:0000000009825000 PAR:0000000000000000
> VCPU:000804fc20001221
>
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc7-dirty #3
> Hardware name: ARM Juno development board (r1) (DT)
> Call trace:
> [<ffff000008088ea4>] dump_backtrace+0x0/0x34c
> [<ffff000008089208>] show_stack+0x18/0x20
> [<ffff0000089c73ec>] dump_stack+0xc4/0xfc
> [<ffff0000080c8e1c>] panic+0x138/0x2b4
> [<ffff0000080c8ce4>] panic+0x0/0x2b4
> SMP: stopping secondary CPUs
> SMP: failed to stop secondary CPUs 0-3,5
> Kernel Offset: disabled
> CPU features: 0x002086
> Memory Limit: none
> ---[ end Kernel panic - not syncing: HYP panic:
> PS:800003c9 PC:ffff0000089e6fd8 ESR:86000004
> FAR:ffff0000089e6fd8 HPFAR:0000000009825000 PAR:0000000000000000
> VCPU:000804fc20001221
>
> This change adds -fno-jump-tables to arm64/hyp to work around the
> bug.
>
> Suggested-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> ---
> arch/arm64/kvm/hyp/Makefile | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/kvm/hyp/Makefile b/arch/arm64/kvm/hyp/Makefile
> index 4313f74753332..745b3255e7832 100644
> --- a/arch/arm64/kvm/hyp/Makefile
> +++ b/arch/arm64/kvm/hyp/Makefile
> @@ -5,6 +5,10 @@
>
> ccflags-y += -fno-stack-protector -DDISABLE_BRANCH_PROFILING
>
> +ifeq ($(cc-name),clang)
> +ccflags-y += -fno-jump-tables
> +endif
> +
> KVM=../../../../virt/kvm
>
> obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/vgic-v3-sr.o
>
I'm going to ask the question I've asked before when this patch cropped
up (must be the 4th time now):
Is it guaranteed that this is the only case where LLVM/clang is going to
generate absolute addresses instead of using relative addressing?
So far, nobody has answered that question. If you assure me that this is
the case, I'll take that patch. Otherwise, we're just playing
whack-a-mole, as with the profiling stuff.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v3 0/5]
From: Stefan Wahren @ 2018-05-18 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <278cb8b1-d567-2067-2dde-980596821c9c@arm.com>
> Marc Zyngier <marc.zyngier@arm.com> hat am 18. Mai 2018 um 18:41 geschrieben:
>
>
> [/me beats himself for not writing a subject line...]
>
> On 18/05/18 17:29, Vince Weaver wrote:
> > On Fri, 18 May 2018, Marc Zyngier wrote:
> >
> >> There is also the case of people natively running 32bit kernels on
> >> 64bit HW and trying to upstream unspeakable hacks, hoping that the
> >> stars will align and that they'll win the lottery (see [1]).
> >
> > I've tested these patches on a Raspberry Pi 3B running a 32-bit upstream
> > (4.17-rc5-git) kernel and they work.
> >
> > [ 0.472906] hw perfevents: enabled with armv8_cortex_a53 PMU driver, 7 counters available
> >
> > I only needed to add this to the devicetree
> >
> > arm-pmu {
> > compatible = "arm,cortex-a53-pmu";
> > interrupt-parent = <&local_intc>;
> > interrupts = <9 IRQ_TYPE_LEVEL_HIGH>;
> > };
>
> That's definitely the sensible thing to have on such hardware. Why isn't
> it in the upstream DT already, irrespective of the state of the kernel
> support?
I remember that Vince point out the absence. He asked about how to implement it and i wasn't sure about it. At this time we hadn't IRQ polarity support. So we wanted to get this puzzle piece before. In march i put it on my TODO list, but then RPI 3 B+ support had higher prio to get into 4.18.
In general we have the problem that most of the users take the downstream kernel and don't know about the differences. Luckily more distributions switch to the upstream kernel, which increases the feedback.
>
> > Tested-by: Vince Weaver <vincent.weaver@maine.edu>
Thanks again
Stefan
>
> Thanks a lot for testing.
>
> M.
> --
> Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] arm64: kvm: use -fno-jump-tables with clang
From: Nick Desaulniers @ 2018-05-18 17:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <05d14ac7-0feb-63a3-e7ef-b8ca1ae2fd1d@arm.com>
On Fri, May 18, 2018 at 10:30 AM Marc Zyngier <marc.zyngier@arm.com> wrote:
> I'm going to ask the question I've asked before when this patch cropped
> up (must be the 4th time now):
> Is it guaranteed that this is the only case where LLVM/clang is going to
> generate absolute addresses instead of using relative addressing?
It seems like if there's requirements that only relative addressing be
used, then the compiler should be told explicitly about this restriction,
no?
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* [PATCH] arm64: kvm: use -fno-jump-tables with clang
From: Nick Desaulniers @ 2018-05-18 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKwvOdm1kYedukCq=g74AvqJHp6KC03oNoouQy2nkvfo4idoEw@mail.gmail.com>
+ Andrey (who reported testing this patch in
https://github.com/ClangBuiltLinux/linux/issues/11)
On Fri, May 18, 2018 at 10:40 AM Nick Desaulniers <ndesaulniers@google.com>
wrote:
> On Fri, May 18, 2018 at 10:30 AM Marc Zyngier <marc.zyngier@arm.com>
wrote:
> > I'm going to ask the question I've asked before when this patch cropped
> > up (must be the 4th time now):
> > Is it guaranteed that this is the only case where LLVM/clang is going to
> > generate absolute addresses instead of using relative addressing?
> It seems like if there's requirements that only relative addressing be
> used, then the compiler should be told explicitly about this restriction,
> no?
> --
> Thanks,
> ~Nick Desaulniers
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* [PATCH] arm64: kvm: use -fno-jump-tables with clang
From: Marc Zyngier @ 2018-05-18 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKwvOdm1kYedukCq=g74AvqJHp6KC03oNoouQy2nkvfo4idoEw@mail.gmail.com>
On 18/05/18 18:40, Nick Desaulniers wrote:
> On Fri, May 18, 2018 at 10:30 AM Marc Zyngier <marc.zyngier@arm.com> wrote:
>> I'm going to ask the question I've asked before when this patch cropped
>> up (must be the 4th time now):
>
>> Is it guaranteed that this is the only case where LLVM/clang is going to
>> generate absolute addresses instead of using relative addressing?
>
> It seems like if there's requirements that only relative addressing be
> used, then the compiler should be told explicitly about this restriction,
> no?
Certainly. What's the rune?
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* dma_sync_*_for_cpu and direction=TO_DEVICE (was Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation)
From: Russell King - ARM Linux @ 2018-05-18 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5ac5b1e3-9b96-9c7c-4dfe-f65be45ec179@synopsys.com>
On Fri, May 18, 2018 at 10:20:02AM -0700, Vineet Gupta wrote:
> I never understood the need for this direction. And if memory serves me
> right, at that time I was seeing twice the amount of cache flushing !
It's necessary. Take a moment to think carefully about this:
dma_map_single(, dir)
dma_sync_single_for_cpu(, dir)
dma_sync_single_for_device(, dir)
dma_unmap_single(, dir)
In the case of a DMA-incoherent architecture, the operations done at each
stage depend on the direction argument:
map for_cpu for_device unmap
TO_DEV writeback none writeback none
TO_CPU invalidate invalidate* invalidate invalidate*
BIDIR writeback invalidate writeback invalidate
* - only necessary if the CPU speculatively prefetches.
The multiple invalidations for the TO_CPU case handles different
conditions that can result in data corruption, and for some CPUs, all
four are necessary.
This is what is implemented for 32-bit ARM, depending on the CPU
capabilities, as we have DMA incoherent devices and we have CPUs that
speculatively prefetch data, and so may load data into the caches while
DMA is in operation.
Things get more interesting if the implementation behind the DMA API has
to copy data between the buffer supplied to the mapping and some DMA
accessible buffer:
map for_cpu for_device unmap
TO_DEV copy to dma none copy to dma none
TO_CPU none copy to cpu none copy to cpu
BIDIR copy to dma copy to cpu copy to dma copy to cpu
So, in both cases, the value of the direction argument defines what you
need to do in each call.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH] arm64: kvm: use -fno-jump-tables with clang
From: Nick Desaulniers @ 2018-05-18 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8c7be44f-086d-65e3-9969-8182261ce82f@arm.com>
+ Andrey
On Fri, May 18, 2018 at 10:45 AM Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 18/05/18 18:40, Nick Desaulniers wrote:
> > On Fri, May 18, 2018 at 10:30 AM Marc Zyngier <marc.zyngier@arm.com>
wrote:
> >> I'm going to ask the question I've asked before when this patch cropped
> >> up (must be the 4th time now):
The previous threads for context:
https://patchwork.kernel.org/patch/10060381/
https://lkml.org/lkml/2018/3/16/434
> >> Is it guaranteed that this is the only case where LLVM/clang is going
to
> >> generate absolute addresses instead of using relative addressing?
> >
> > It seems like if there's requirements that only relative addressing be
> > used, then the compiler should be told explicitly about this
restriction,
> > no?
> Certainly. What's the rune?
It seems like -fno-jump-tables covers all known issues and unblocks people
from doing further work. It sounds like you'd like some kind of stronger
guarantee? Wont those cases still "crop up" as far as needing to annotate
either the code, or build scripts?
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* [PATCH V6] ARM: dts: da850-evm: Enable LCD and Backlight
From: Adam Ford @ 2018-05-18 18:02 UTC (permalink / raw)
To: linux-arm-kernel
When using the board files the LCD works, but not with the DT.
This adds enables the original da850-evm to work with the same
LCD in device tree mode.
The EVM has a gpio for the regulator and a PWM for dimming the
backlight. The LCD and the vpif display pins are mutually
exclusive, so if using the LCD, do not load the vpif driver.
Signed-off-by: Adam Ford <aford173@gmail.com>
---
V6: Fix some whitespace and comment formatting. Rename backlight_reg to
backlight_lcd
V5: Resync against v4.18/dt
V4: Move the backlight to PWM, so the driver can control the regulator allowing the
regulator to power down and enabling the ability to change the brightness of the
backlight
V3: Fix errant GPIO, label GPIO pins, and rename the regulator to be more explict to
backlight which better matches the schematic. Updated the description to explain
that it cannot be used at the same time as the vpif driver.
V2: Add regulator and GPIO enable pins. Remove PWM backlight and replace with GPIO
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 0e82bb988fde..3e760e23d88c 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -27,6 +27,60 @@
spi0 = &spi1;
};
+ backlight: backlight-pwm {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ecap2_pins>;
+ power-supply = <&backlight_reg>;
+ compatible = "pwm-backlight";
+ pwms = <&ecap2 0 50000 0>;
+ brightness-levels = <0 10 20 30 40 50 60 70 80 90 99>;
+ default-brightness-level = <7>;
+ };
+
+ panel {
+ compatible = "ti,tilcdc,panel";
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_pins>;
+ /*
+ * The vpif and the LCD are mutually exclusive.
+ * To enable VPIF, change the status below to 'disabled' then
+ * then change the status of the vpif below to 'okay'
+ */
+ status = "okay";
+ enable-gpios = <&gpio 40 GPIO_ACTIVE_HIGH>; /* lcd_panel_pwr */
+
+ panel-info {
+ ac-bias = <255>;
+ ac-bias-intrpt = <0>;
+ dma-burst-sz = <16>;
+ bpp = <16>;
+ fdd = <0x80>;
+ sync-edge = <0>;
+ sync-ctrl = <1>;
+ raster-order = <0>;
+ fifo-th = <0>;
+ };
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: 480x272 {
+ clock-frequency = <9000000>;
+ hactive = <480>;
+ vactive = <272>;
+ hfront-porch = <3>;
+ hback-porch = <2>;
+ hsync-len = <42>;
+ vback-porch = <3>;
+ vfront-porch = <4>;
+ vsync-len = <11>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <1>;
+ };
+ };
+ };
+
vbat: fixedregulator0 {
compatible = "regulator-fixed";
regulator-name = "vbat";
@@ -35,6 +89,15 @@
regulator-boot-on;
};
+ backlight_lcd: backlight-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "lcd_backlight_pwr";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio 47 GPIO_ACTIVE_HIGH>; /* lcd_backlight_pwr */
+ enable-active-high;
+ };
+
sound {
compatible = "simple-audio-card";
simple-audio-card,name = "DA850/OMAP-L138 EVM";
@@ -63,6 +126,10 @@
};
};
+&ecap2 {
+ status = "okay";
+};
+
&pmx_core {
status = "okay";
@@ -109,6 +176,10 @@
status = "okay";
};
+&lcdc {
+ status = "okay";
+};
+
&i2c0 {
status = "okay";
clock-frequency = <100000>;
@@ -336,5 +407,10 @@
&vpif {
pinctrl-names = "default";
pinctrl-0 = <&vpif_capture_pins>, <&vpif_display_pins>;
- status = "okay";
+ /*
+ * The vpif and the LCD are mutually exclusive.
+ * To enable VPIF, disable the ti,tilcdc,panel then
+ * changed the status below to 'okay'
+ */
+ status = "disabled";
};
--
2.17.0
^ permalink raw reply related
* [PATCH v2 07/40] iommu: Add a page fault handler
From: Jacob Pan @ 2018-05-18 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511190641.23008-8-jean-philippe.brucker@arm.com>
On Fri, 11 May 2018 20:06:08 +0100
Jean-Philippe Brucker <jean-philippe.brucker@arm.com> wrote:
> Some systems allow devices to handle I/O Page Faults in the core mm.
> For example systems implementing the PCI PRI extension or Arm SMMU
> stall model. Infrastructure for reporting these recoverable page
> faults was recently added to the IOMMU core for SVA virtualisation.
> Add a page fault handler for host SVA.
>
> IOMMU driver can now instantiate several fault workqueues and link
> them to IOPF-capable devices. Drivers can choose between a single
> global workqueue, one per IOMMU device, one per low-level fault
> queue, one per domain, etc.
>
> When it receives a fault event, supposedly in an IRQ handler, the
> IOMMU driver reports the fault using iommu_report_device_fault(),
> which calls the registered handler. The page fault handler then calls
> the mm fault handler, and reports either success or failure with
> iommu_page_response(). When the handler succeeded, the IOMMU retries
> the access.
>
> The iopf_param pointer could be embedded into iommu_fault_param. But
> putting iopf_param into the iommu_param structure allows us not to
> care about ordering between calls to iopf_queue_add_device() and
> iommu_register_device_fault_handler().
>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
>
> ---
> v1->v2: multiple queues registered by IOMMU driver
> ---
> drivers/iommu/Kconfig | 4 +
> drivers/iommu/Makefile | 1 +
> drivers/iommu/io-pgfault.c | 363
> +++++++++++++++++++++++++++++++++++++ include/linux/iommu.h |
> 58 ++++++ 4 files changed, 426 insertions(+)
> create mode 100644 drivers/iommu/io-pgfault.c
>
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 38434899e283..09f13a7c4b60 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -79,6 +79,10 @@ config IOMMU_SVA
> select IOMMU_API
> select MMU_NOTIFIER
>
> +config IOMMU_PAGE_FAULT
> + bool
> + select IOMMU_API
> +
> config FSL_PAMU
> bool "Freescale IOMMU support"
> depends on PCI
> diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
> index 1dbcc89ebe4c..4b744e399a1b 100644
> --- a/drivers/iommu/Makefile
> +++ b/drivers/iommu/Makefile
> @@ -4,6 +4,7 @@ obj-$(CONFIG_IOMMU_API) += iommu-traces.o
> obj-$(CONFIG_IOMMU_API) += iommu-sysfs.o
> obj-$(CONFIG_IOMMU_DMA) += dma-iommu.o
> obj-$(CONFIG_IOMMU_SVA) += iommu-sva.o
> +obj-$(CONFIG_IOMMU_PAGE_FAULT) += io-pgfault.o
> obj-$(CONFIG_IOMMU_IO_PGTABLE) += io-pgtable.o
> obj-$(CONFIG_IOMMU_IO_PGTABLE_ARMV7S) += io-pgtable-arm-v7s.o
> obj-$(CONFIG_IOMMU_IO_PGTABLE_LPAE) += io-pgtable-arm.o
> diff --git a/drivers/iommu/io-pgfault.c b/drivers/iommu/io-pgfault.c
> new file mode 100644
> index 000000000000..321c00dd3a3d
> --- /dev/null
> +++ b/drivers/iommu/io-pgfault.c
> @@ -0,0 +1,363 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Handle device page faults
> + *
> + * Copyright (C) 2018 ARM Ltd.
> + */
> +
> +#include <linux/iommu.h>
> +#include <linux/list.h>
> +#include <linux/slab.h>
> +#include <linux/workqueue.h>
> +
> +/**
> + * struct iopf_queue - IO Page Fault queue
> + * @wq: the fault workqueue
> + * @flush: low-level flush callback
> + * @flush_arg: flush() argument
> + * @refs: references to this structure taken by producers
> + */
> +struct iopf_queue {
> + struct workqueue_struct *wq;
> + iopf_queue_flush_t flush;
> + void *flush_arg;
> + refcount_t refs;
> +};
> +
> +/**
> + * struct iopf_device_param - IO Page Fault data attached to a device
> + * @queue: IOPF queue
> + * @partial: faults that are part of a Page Request Group for which
> the last
> + * request hasn't been submitted yet.
> + */
> +struct iopf_device_param {
> + struct iopf_queue *queue;
> + struct list_head partial;
> +};
> +
> +struct iopf_context {
> + struct device *dev;
> + struct iommu_fault_event evt;
> + struct list_head head;
> +};
> +
> +struct iopf_group {
> + struct iopf_context last_fault;
> + struct list_head faults;
> + struct work_struct work;
> +};
> +
All the page requests in the group should belong to the same device,
perhaps struct device tracking should be in iopf_group instead of
iopf_context?
> +static int iopf_complete(struct device *dev, struct
> iommu_fault_event *evt,
> + enum page_response_code status)
> +{
> + struct page_response_msg resp = {
> + .addr = evt->addr,
> + .pasid = evt->pasid,
> + .pasid_present = evt->pasid_valid,
> + .page_req_group_id = evt->page_req_group_id,
> + .private_data = evt->iommu_private,
> + .resp_code = status,
> + };
> +
> + return iommu_page_response(dev, &resp);
> +}
> +
> +static enum page_response_code
> +iopf_handle_single(struct iopf_context *fault)
> +{
> + /* TODO */
> + return -ENODEV;
> +}
> +
> +static void iopf_handle_group(struct work_struct *work)
> +{
> + struct iopf_group *group;
> + struct iopf_context *fault, *next;
> + enum page_response_code status = IOMMU_PAGE_RESP_SUCCESS;
> +
> + group = container_of(work, struct iopf_group, work);
> +
> + list_for_each_entry_safe(fault, next, &group->faults, head) {
> + struct iommu_fault_event *evt = &fault->evt;
> + /*
> + * Errors are sticky: don't handle subsequent faults
> in the
> + * group if there is an error.
> + */
There might be performance benefit for certain device to continue in
spite of error in that the ATS retry may have less fault. Perhaps a
policy decision for later enhancement.
> + if (status == IOMMU_PAGE_RESP_SUCCESS)
> + status = iopf_handle_single(fault);
> +
> + if (!evt->last_req)
> + kfree(fault);
> + }
> +
> + iopf_complete(group->last_fault.dev, &group->last_fault.evt,
> status);
> + kfree(group);
> +}
> +
> +/**
> + * iommu_queue_iopf - IO Page Fault handler
> + * @evt: fault event
> + * @cookie: struct device, passed to
> iommu_register_device_fault_handler.
> + *
> + * Add a fault to the device workqueue, to be handled by mm.
> + */
> +int iommu_queue_iopf(struct iommu_fault_event *evt, void *cookie)
> +{
> + struct iopf_group *group;
> + struct iopf_context *fault, *next;
> + struct iopf_device_param *iopf_param;
> +
> + struct device *dev = cookie;
> + struct iommu_param *param = dev->iommu_param;
> +
> + if (WARN_ON(!mutex_is_locked(¶m->lock)))
> + return -EINVAL;
> +
> + if (evt->type != IOMMU_FAULT_PAGE_REQ)
> + /* Not a recoverable page fault */
> + return IOMMU_PAGE_RESP_CONTINUE;
> +
> + /*
> + * As long as we're holding param->lock, the queue can't be
> unlinked
> + * from the device and therefore cannot disappear.
> + */
> + iopf_param = param->iopf_param;
> + if (!iopf_param)
> + return -ENODEV;
> +
> + if (!evt->last_req) {
> + fault = kzalloc(sizeof(*fault), GFP_KERNEL);
> + if (!fault)
> + return -ENOMEM;
> +
> + fault->evt = *evt;
> + fault->dev = dev;
> +
> + /* Non-last request of a group. Postpone until the
> last one */
> + list_add(&fault->head, &iopf_param->partial);
> +
> + return IOMMU_PAGE_RESP_HANDLED;
> + }
> +
> + group = kzalloc(sizeof(*group), GFP_KERNEL);
> + if (!group)
> + return -ENOMEM;
> +
> + group->last_fault.evt = *evt;
> + group->last_fault.dev = dev;
> + INIT_LIST_HEAD(&group->faults);
> + list_add(&group->last_fault.head, &group->faults);
> + INIT_WORK(&group->work, iopf_handle_group);
> +
> + /* See if we have partial faults for this group */
> + list_for_each_entry_safe(fault, next, &iopf_param->partial,
> head) {
> + if (fault->evt.page_req_group_id ==
> evt->page_req_group_id)
If all 9 bit group index are used, there can be lots of PRGs. For
future enhancement, maybe we can have per group partial list ready to
go when LPIG comes in? I will be less searching.
> + /* Insert *before* the last fault */
> + list_move(&fault->head, &group->faults);
> + }
> +
If you already sorted the group list with last fault at the end, why do
you need a separate entry to track the last fault?
> + queue_work(iopf_param->queue->wq, &group->work);
> +
> + /* Postpone the fault completion */
> + return IOMMU_PAGE_RESP_HANDLED;
> +}
> +EXPORT_SYMBOL_GPL(iommu_queue_iopf);
> +
> +/**
> + * iopf_queue_flush_dev - Ensure that all queued faults have been
> processed
> + * @dev: the endpoint whose faults need to be flushed.
> + *
> + * Users must call this function when releasing a PASID, to ensure
> that all
> + * pending faults for this PASID have been handled, and won't hit
> the address
> + * space of the next process that uses this PASID.
> + *
> + * Return 0 on success.
> + */
> +int iopf_queue_flush_dev(struct device *dev)
> +{
> + int ret = 0;
> + struct iopf_queue *queue;
> + struct iommu_param *param = dev->iommu_param;
> +
> + if (!param)
> + return -ENODEV;
> +
> + /*
> + * It is incredibly easy to find ourselves in a deadlock
> situation if
> + * we're not careful, because we're taking the opposite path
> as
> + * iommu_queue_iopf:
> + *
> + * iopf_queue_flush_dev() | PRI queue handler
> + * lock(mutex) | iommu_queue_iopf()
> + * queue->flush() | lock(mutex)
> + * wait PRI queue empty |
> + *
> + * So we can't hold the device param lock while flushing. We
> don't have
> + * to, because the queue or the device won't disappear until
> all flush
> + * are finished.
> + */
> + mutex_lock(¶m->lock);
> + if (param->iopf_param) {
> + queue = param->iopf_param->queue;
> + } else {
> + ret = -ENODEV;
> + }
> + mutex_unlock(¶m->lock);
> + if (ret)
> + return ret;
> +
> + queue->flush(queue->flush_arg, dev);
> +
> + /*
> + * No need to clear the partial list. All PRGs containing
> the PASID that
> + * needs to be decommissioned are whole (the device driver
> made sure of
> + * it before this function was called). They have been
> submitted to the
> + * queue by the above flush().
> + */
So you are saying device driver need to make sure LPIG PRQ is submitted
in the flush call above such that partial list is cleared? what if
there are device failures where device needs to reset (either whole
function level or PASID level), should there still be a need to clear
the partial list for all associated PASID/group?
> + flush_workqueue(queue->wq);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(iopf_queue_flush_dev);
> +
> +/**
> + * iopf_queue_add_device - Add producer to the fault queue
> + * @queue: IOPF queue
> + * @dev: device to add
> + */
> +int iopf_queue_add_device(struct iopf_queue *queue, struct device
> *dev) +{
> + int ret = -EINVAL;
> + struct iopf_device_param *iopf_param;
> + struct iommu_param *param = dev->iommu_param;
> +
> + if (!param)
> + return -ENODEV;
> +
> + iopf_param = kzalloc(sizeof(*iopf_param), GFP_KERNEL);
> + if (!iopf_param)
> + return -ENOMEM;
> +
> + INIT_LIST_HEAD(&iopf_param->partial);
> + iopf_param->queue = queue;
> +
> + mutex_lock(¶m->lock);
> + if (!param->iopf_param) {
> + refcount_inc(&queue->refs);
> + param->iopf_param = iopf_param;
> + ret = 0;
> + }
> + mutex_unlock(¶m->lock);
> +
> + if (ret)
> + kfree(iopf_param);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(iopf_queue_add_device);
> +
> +/**
> + * iopf_queue_remove_device - Remove producer from fault queue
> + * @dev: device to remove
> + *
> + * Caller makes sure that no more fault is reported for this device,
> and no more
> + * flush is scheduled for this device.
> + *
> + * Note: safe to call unconditionally on a cleanup path, even if the
> device
> + * isn't registered to any IOPF queue.
> + *
> + * Return 0 if the device was attached to the IOPF queue
> + */
> +int iopf_queue_remove_device(struct device *dev)
> +{
> + struct iopf_context *fault, *next;
> + struct iopf_device_param *iopf_param;
> + struct iommu_param *param = dev->iommu_param;
> +
> + if (!param)
> + return -EINVAL;
> +
> + mutex_lock(¶m->lock);
> + iopf_param = param->iopf_param;
> + if (iopf_param) {
> + refcount_dec(&iopf_param->queue->refs);
> + param->iopf_param = NULL;
> + }
> + mutex_unlock(¶m->lock);
> + if (!iopf_param)
> + return -EINVAL;
> +
> + list_for_each_entry_safe(fault, next, &iopf_param->partial,
> head)
> + kfree(fault);
> +
> + /*
> + * No more flush is scheduled, and the caller removed all
> bonds from
> + * this device. unbind() waited until any concurrent
> mm_exit() finished,
> + * therefore there is no flush() running anymore and we can
> free the
> + * param.
> + */
> + kfree(iopf_param);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(iopf_queue_remove_device);
> +
> +/**
> + * iopf_queue_alloc - Allocate and initialize a fault queue
> + * @name: a unique string identifying the queue (for workqueue)
> + * @flush: a callback that flushes the low-level queue
> + * @cookie: driver-private data passed to the flush callback
> + *
> + * The callback is called before the workqueue is flushed. The IOMMU
> driver must
> + * commit all faults that are pending in its low-level queues at the
> time of the
> + * call, into the IOPF queue (with iommu_report_device_fault). The
> callback
> + * takes a device pointer as argument, hinting what endpoint is
> causing the
> + * flush. When the device is NULL, all faults should be committed.
> + */
> +struct iopf_queue *
> +iopf_queue_alloc(const char *name, iopf_queue_flush_t flush, void
> *cookie) +{
> + struct iopf_queue *queue;
> +
> + queue = kzalloc(sizeof(*queue), GFP_KERNEL);
> + if (!queue)
> + return NULL;
> +
> + /*
> + * The WQ is unordered because the low-level handler
> enqueues faults by
> + * group. PRI requests within a group have to be ordered,
> but once
> + * that's dealt with, the high-level function can handle
> groups out of
> + * order.
> + */
> + queue->wq = alloc_workqueue("iopf_queue/%s", WQ_UNBOUND, 0,
> name);
> + if (!queue->wq) {
> + kfree(queue);
> + return NULL;
> + }
> +
> + queue->flush = flush;
> + queue->flush_arg = cookie;
> + refcount_set(&queue->refs, 1);
> +
> + return queue;
> +}
> +EXPORT_SYMBOL_GPL(iopf_queue_alloc);
> +
> +/**
> + * iopf_queue_free - Free IOPF queue
> + * @queue: queue to free
> + *
> + * Counterpart to iopf_queue_alloc(). Caller must make sure that all
> producers
> + * have been removed.
> + */
> +void iopf_queue_free(struct iopf_queue *queue)
> +{
> +
> + /* Caller should have removed all producers first */
> + if (WARN_ON(!refcount_dec_and_test(&queue->refs)))
> + return;
> +
> + destroy_workqueue(queue->wq);
> + kfree(queue);
> +}
> +EXPORT_SYMBOL_GPL(iopf_queue_free);
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index faf3390ce89d..fad3a60e1c14 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -461,11 +461,20 @@ struct iommu_fault_param {
> void *data;
> };
>
> +/**
> + * iopf_queue_flush_t - Flush low-level page fault queue
> + *
> + * Report all faults currently pending in the low-level page fault
> queue
> + */
> +struct iopf_queue;
> +typedef int (*iopf_queue_flush_t)(void *cookie, struct device *dev);
> +
> /**
> * struct iommu_param - collection of per-device IOMMU data
> *
> * @fault_param: IOMMU detected device fault reporting data
> * @sva_param: SVA parameters
> + * @iopf_param: I/O Page Fault queue and data
> *
> * TODO: migrate other per device data pointers under
> iommu_dev_data, e.g.
> * struct iommu_group *iommu_group;
> @@ -475,6 +484,7 @@ struct iommu_param {
> struct mutex lock;
> struct iommu_fault_param *fault_param;
> struct iommu_sva_param *sva_param;
> + struct iopf_device_param *iopf_param;
> };
>
> int iommu_device_register(struct iommu_device *iommu);
> @@ -874,6 +884,12 @@ static inline int
> iommu_report_device_fault(struct device *dev, struct iommu_fau return
> 0; }
>
> +static inline int iommu_page_response(struct device *dev,
> + struct page_response_msg *msg)
> +{
> + return -ENODEV;
> +}
> +
> static inline int iommu_group_id(struct iommu_group *group)
> {
> return -ENODEV;
> @@ -1038,4 +1054,46 @@ static inline struct mm_struct
> *iommu_sva_find(int pasid) }
> #endif /* CONFIG_IOMMU_SVA */
>
> +#ifdef CONFIG_IOMMU_PAGE_FAULT
> +extern int iommu_queue_iopf(struct iommu_fault_event *evt, void
> *cookie); +
> +extern int iopf_queue_add_device(struct iopf_queue *queue, struct
> device *dev); +extern int iopf_queue_remove_device(struct device
> *dev); +extern int iopf_queue_flush_dev(struct device *dev);
> +extern struct iopf_queue *
> +iopf_queue_alloc(const char *name, iopf_queue_flush_t flush, void
> *cookie); +extern void iopf_queue_free(struct iopf_queue *queue);
> +#else /* CONFIG_IOMMU_PAGE_FAULT */
> +static inline int iommu_queue_iopf(struct iommu_fault_event *evt,
> void *cookie) +{
> + return -ENODEV;
> +}
> +
> +static inline int iopf_queue_add_device(struct iopf_queue *queue,
> + struct device *dev)
> +{
> + return -ENODEV;
> +}
> +
> +static inline int iopf_queue_remove_device(struct device *dev)
> +{
> + return -ENODEV;
> +}
> +
> +static inline int iopf_queue_flush_dev(struct device *dev)
> +{
> + return -ENODEV;
> +}
> +
> +static inline struct iopf_queue *
> +iopf_queue_alloc(const char *name, iopf_queue_flush_t flush, void
> *cookie) +{
> + return NULL;
> +}
> +
> +static inline void iopf_queue_free(struct iopf_queue *queue)
> +{
> +}
> +#endif /* CONFIG_IOMMU_PAGE_FAULT */
> +
> #endif /* __LINUX_IOMMU_H */
^ permalink raw reply
* [PATCH V2] ARM: davinci_all_defconfig: set CONFIG_BACKLIGHT_PWM=m
From: Adam Ford @ 2018-05-18 18:09 UTC (permalink / raw)
To: linux-arm-kernel
The da850-evm came with an LCD with a backlight tied to a pwm. This
enables CONFIG_BACKLIGHT_PWM as a module so the PWM backlight can be
used to maintain brightness control of the backlight.
Signed-off-by: Adam Ford <aford173@gmail.com>
---
V2: Only enable CONFIG_BACKLIGHT_PWM and do not re-sync with savedefconfig
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index c302a04e8cbc..48d23956d898 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -153,6 +153,7 @@ CONFIG_TINYDRM_ST7586=m
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_DA8XX=y
+CONFIG_BACKLIGHT_PWM=m
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_LOGO=y
CONFIG_SOUND=m
--
2.17.0
^ permalink raw reply related
* [PATCH] arm64: kvm: use -fno-jump-tables with clang
From: Marc Zyngier @ 2018-05-18 18:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKwvOd=XZqg5=mkXZb-cxq3i_AGoJGAbmF=Fwc7Q98oi0tbN9g@mail.gmail.com>
On 18/05/18 18:56, Nick Desaulniers wrote:
> + Andrey
>
> On Fri, May 18, 2018 at 10:45 AM Marc Zyngier <marc.zyngier@arm.com> wrote:
>> On 18/05/18 18:40, Nick Desaulniers wrote:
>>> On Fri, May 18, 2018 at 10:30 AM Marc Zyngier <marc.zyngier@arm.com>
> wrote:
>>>> I'm going to ask the question I've asked before when this patch cropped
>>>> up (must be the 4th time now):
>
> The previous threads for context:
> https://patchwork.kernel.org/patch/10060381/
> https://lkml.org/lkml/2018/3/16/434
>
>>>> Is it guaranteed that this is the only case where LLVM/clang is going
> to
>>>> generate absolute addresses instead of using relative addressing?
>>>
>>> It seems like if there's requirements that only relative addressing be
>>> used, then the compiler should be told explicitly about this
> restriction,
>>> no?
>
>> Certainly. What's the rune?
>
> It seems like -fno-jump-tables covers all known issues and unblocks people
> from doing further work. It sounds like you'd like some kind of stronger
> guarantee? Wont those cases still "crop up" as far as needing to annotate
> either the code, or build scripts?
What I'd really like is to apply that patch knowing that:
- you have checked that with a released version of the compiler, you
don't observe any absolute address in any of the objects that are going
to be executed at EL2 on a mainline kernel,
- you have successfully run guests with a mainline kernel,
- it works for a reasonable set of common kernel configurations
(defconfig and some of the most useful debug options),
- I can reproduce your findings with the same released compiler.
Is that the case? I don't think any of the above is completely outlandish.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* AArch64 memory
From: Robin Murphy @ 2018-05-18 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJ+vNU2kK1rF-ozLSyV-ctY=ySfkkzqMoFiFgSk724mXJ_Wa-w@mail.gmail.com>
On 18/05/18 17:43, Tim Harvey wrote:
[...]
>>> My second question has to do with CMA and coherent_pool. I have
>>> understood CMA as being a chunk of physical memory carved out by the
>>> kernel for allocations from dma_alloc_coherent by drivers that need
>>> chunks of contiguous memory for DMA buffers. I believe that before CMA
>>> was introduced we had to do this by defining memory holes. I'm not
>>> understanding the difference between CMA and the coherent pool. I've
>>> noticed that if CONFIG_DMA_CMA=y then the coherent pool allocates from
>>> CMA. Is there some disadvantage of CONFIG_DMA_CMA=y other than if
>>> defined you need to make sure your CMA is larger than coherent_pool?
>>> What drivers/calls use coherent_pool vs cma?
>>
>>
>> coherent_pool is a special thing which exists for the sake of
>> non-hardware-coherent devices - normally for those we satisfy DMA-coherent
>> allocations by setting up a non-cacheable remap of the allocated buffer -
>> see dma_common_contiguous_remap(). However, drivers may call
>> dma_alloc_coherent(..., GFP_ATOMIC) from interrupt handlers, at which point
>> we can't call get_vm_area() to remap on demand, since that might sleep, so
>> we reserve a pool pre-mapped as non-cacheable to satisfy such atomic
>> allocations from. I'm not sure why its user-visible name is "coherent pool"
>> rather than the more descriptive "atomic pool" which it's named internally,
>> but there's probably some history there. If you're lucky enough not to have
>> any non-coherent DMA masters then you can safely ignore the whole thing;
>> otherwise it's still generally rare that it should need adjusting.
>
> is there an easy way to tell if I have non-coherent DMA masters? The
> Cavium SDK uses a kernel cmdline param of coherent_pool=16M so I'm
> guessing something in the CN80XX/CN81XX (BGX NIC's or CPT perhaps)
> need atomic pool mem.
AFAIK the big-boy CN88xx is fully coherent everywhere, but whether the
peripherals and interconnect in the littler Octeon TX variants are
different I have no idea. If the contents of your dts-newport repo on
GitHub are the right thing to be looking at, then you do have the
"dma-coherent" property on the PCI nodes, which should cover everything
beneath (I'd expect that in reality the SMMU may actually be coherent as
well, but fortunately that's irrelevant here). Thus everything which
matters *should* be being picked up as coherent already, and if not it
would be a Linux problem. I can't imagine what the SDK is up to there,
but 16MB of coherent pool does sound like something being done wrong,
like incorrectly compensating for bad firmware failing to describe the
hardware properly in the first place.
>> CMA is, as you surmise, a much more general thing for providing large
>> physically-contiguous areas, which the arch code correspondingly uses to get
>> DMA-contiguous buffers. Unless all your DMA masters are behind IOMMUs (such
>> that we can make any motley collection of pages look DMA-contiguous), you
>> probably don't want to turn it off. None of these details should be relevant
>> as far as drivers are concerned, since from their viewpoint it's all
>> abstracted behind dma_alloc_coherent().
>>
>
> I don't want to turn off CONFIG_CMA but I'm still not clear if I
> should turn off CONFIG_DMA_CMA. I noticed the Cavium SDK 4.9 kernel
> has CONFIG_CMA=y but does not enable CONFIG_DMA_CMA which I believe
> means that the atomic pool does not pull its chunks from the CMA pool.
I wouldn't think there's much good reason to turn DMA_CMA off either,
even if nothing actually needs huge DMA buffers. Where the atomic pool
comes from shouldn't really matter, as it's a very early one-off
allocation. To speculate wildly I suppose there *might* possibly be some
performance difference between cma_alloc() and falling back to the
regular page allocator - if that were the case it ought to be measurable
by profiling something which calls dma_alloc_coherent() in process
context a lot, under both configurations. Even then I'd imagine it's
something that would matter most on the 2-socket 96-core systems, and
not so much on the diddy ones.
Robin.
^ 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