* [PATCH 1/4] ARM: davinci: da8xx: VPIF: enable DT init
From: Kevin Hilman @ 2016-11-22 19:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122194551.3420-1-khilman@baylibre.com>
Add basic support for DT initializaion of VPIF (capture) via DT. Clocks
and mux still need to happen in this file until there are real clock and
pinctrl drivers, but the video nodes and subdevs can all come from DT.
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
arch/arm/mach-davinci/da8xx-dt.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index c9f7e9274aa8..7b41611f2665 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -17,6 +17,7 @@
#include <mach/common.h>
#include "cp_intc.h"
#include <mach/da8xx.h>
+#include <mach/mux.h>
static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("ti,davinci-i2c", 0x01c22000, "i2c_davinci.1", NULL),
@@ -38,14 +39,30 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
NULL),
OF_DEV_AUXDATA("ti,da830-mcasp-audio", 0x01d00000, "davinci-mcasp.0", NULL),
OF_DEV_AUXDATA("ti,da850-aemif", 0x68000000, "ti-aemif", NULL),
+ OF_DEV_AUXDATA("ti,da850-vpif", 0x01e17000, "vpif", NULL),
{}
};
#ifdef CONFIG_ARCH_DAVINCI_DA850
+#if IS_ENABLED(CONFIG_VIDEO_DAVINCI_VPIF_CAPTURE)
+static __init void da850_vpif_capture_init(void)
+{
+ int ret;
+
+ ret = davinci_cfg_reg_list(da850_vpif_capture_pins);
+ if (ret)
+ pr_warn("da850_evm_init: VPIF capture mux setup failed: %d\n",
+ ret);
+}
+#else
+#define da850_vpif_capture_init()
+#endif
+
static void __init da850_init_machine(void)
{
of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
+ da850_vpif_capture_init();
}
static const char *const da850_boards_compat[] __initconst = {
--
2.9.3
^ permalink raw reply related
* [PATCH 2/4] ARM: dts: davinci: da850: add VPIF
From: Kevin Hilman @ 2016-11-22 19:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122194551.3420-1-khilman@baylibre.com>
Add VPIF and VPIF capture nodes to da850. VPIF capture has two input
channels describe using the standard DT ports and enpoints.
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
arch/arm/boot/dts/da850.dtsi | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 6205917b4f59..e05e2bb834e8 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -453,7 +453,35 @@
interrupts = <52>;
status = "disabled";
};
+
+ vpif: video at 0x00217000 {
+ compatible = "ti,da850-vpif";
+ reg = <0x00217000 0x1000>;
+ status = "disabled";
+ };
+
+ vpif_capture: video-capture at 0x00217000 {
+ compatible = "ti,da850-vpif-capture";
+ reg = <0x00217000 0x1000>;
+ interrupts = <92>;
+ status = "disabled";
+
+ /* VPIF capture: input channels */
+ port {
+ vpif_ch0: endpoint at 0 {
+ reg = <0>;
+ bus-width = <8>;
+ };
+
+ vpif_ch1: endpoint at 1 {
+ reg = <1>;
+ bus-width = <8>;
+ data-shift = <8>;
+ };
+ };
+ };
};
+
aemif: aemif at 68000000 {
compatible = "ti,da850-aemif";
#address-cells = <2>;
--
2.9.3
^ permalink raw reply related
* [PATCH 3/4] ARM: dts: davinci: da850-lcdk: enable VPIF capture via TVP5147
From: Kevin Hilman @ 2016-11-22 19:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122194551.3420-1-khilman@baylibre.com>
Enable video capture via the on-board TVP5147 decoder hooked up to ch0
one of the VPIF capture input.
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
arch/arm/boot/dts/da850-lcdk.dts | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index 03f9bfda5385..39db2ffa1902 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -138,6 +138,24 @@
reg = <0x18>;
status = "okay";
};
+
+ tvp5147 at 5d {
+ compatible = "ti,tvp5147";
+ reg = <0x5d>;
+ status = "okay";
+
+ port {
+ composite: endpoint {
+ hsync-active = <1>;
+ vsync-active = <1>;
+ pclk-sample = <0>;
+
+ /* VPIF channel 0 (lower 8-bits) */
+ remote-endpoint = <&vpif_ch0>;
+ bus-width = <8>;
+ };
+ };
+ };
};
&mcasp0 {
@@ -227,3 +245,15 @@
};
};
};
+
+&vpif {
+ status = "okay";
+};
+
+&vpif_capture {
+ status = "okay";
+};
+
+&vpif_ch0 {
+ remote-endpoint = <&composite>;
+};
--
2.9.3
^ permalink raw reply related
* [PATCH 4/4] ARM: davinci_all_defconfig: enable video capture as modules
From: Kevin Hilman @ 2016-11-22 19:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122194551.3420-1-khilman@baylibre.com>
Enable media support and V4L2 capture, along with video decoders used
on da850 platforms.
Tested on da850-lcdk.
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
arch/arm/configs/davinci_all_defconfig | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index 5e5dd6bc5ed9..fd05bc35fb36 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -123,6 +123,12 @@ CONFIG_TPS6507X=y
CONFIG_REGULATOR=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
CONFIG_REGULATOR_TPS6507X=y
+CONFIG_MEDIA_SUPPORT=m
+CONFIG_MEDIA_CAMERA_SUPPORT=y
+CONFIG_V4L_PLATFORM_DRIVERS=y
+CONFIG_VIDEO_DAVINCI_VPIF_CAPTURE=m
+# CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set
+CONFIG_VIDEO_TVP514X=m
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_DA8XX=y
--
2.9.3
^ permalink raw reply related
* [PATCH 2/4] ARM: dts: davinci: da850: add VPIF
From: David Lechner @ 2016-11-22 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122194551.3420-3-khilman@baylibre.com>
On 11/22/2016 01:45 PM, Kevin Hilman wrote:
> Add VPIF and VPIF capture nodes to da850. VPIF capture has two input
> channels describe using the standard DT ports and enpoints.
>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> ---
> arch/arm/boot/dts/da850.dtsi | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index 6205917b4f59..e05e2bb834e8 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -453,7 +453,35 @@
> interrupts = <52>;
> status = "disabled";
> };
> +
> + vpif: video at 0x00217000 {
Should be @217000
> + compatible = "ti,da850-vpif";
> + reg = <0x00217000 0x1000>;
Could omit leading 0's to be consistent with existing entries.
reg = <0x217000 0x1000>;
> + status = "disabled";
> + };
> +
> + vpif_capture: video-capture at 0x00217000 {
Again, @217000. But it seems odd to have two device nodes with the same
address. Is enabling these mutually exclusive?
> + compatible = "ti,da850-vpif-capture";
> + reg = <0x00217000 0x1000>;
Ditto on the leading 0's.
> + interrupts = <92>;
> + status = "disabled";
> +
> + /* VPIF capture: input channels */
> + port {
> + vpif_ch0: endpoint at 0 {
> + reg = <0>;
> + bus-width = <8>;
> + };
> +
> + vpif_ch1: endpoint at 1 {
> + reg = <1>;
> + bus-width = <8>;
> + data-shift = <8>;
> + };
> + };
> + };
> };
> +
> aemif: aemif at 68000000 {
> compatible = "ti,da850-aemif";
> #address-cells = <2>;
>
^ permalink raw reply
* [PATCH 1/4] ARM: davinci: da8xx: VPIF: enable DT init
From: David Lechner @ 2016-11-22 20:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122194551.3420-2-khilman@baylibre.com>
On 11/22/2016 01:45 PM, Kevin Hilman wrote:
> Add basic support for DT initializaion of VPIF (capture) via DT. Clocks
> and mux still need to happen in this file until there are real clock and
> pinctrl drivers, but the video nodes and subdevs can all come from DT.
>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> ---
> arch/arm/mach-davinci/da8xx-dt.c | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
> index c9f7e9274aa8..7b41611f2665 100644
> --- a/arch/arm/mach-davinci/da8xx-dt.c
> +++ b/arch/arm/mach-davinci/da8xx-dt.c
> @@ -17,6 +17,7 @@
> #include <mach/common.h>
> #include "cp_intc.h"
> #include <mach/da8xx.h>
> +#include <mach/mux.h>
>
> static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
> OF_DEV_AUXDATA("ti,davinci-i2c", 0x01c22000, "i2c_davinci.1", NULL),
> @@ -38,14 +39,30 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
> NULL),
> OF_DEV_AUXDATA("ti,da830-mcasp-audio", 0x01d00000, "davinci-mcasp.0", NULL),
> OF_DEV_AUXDATA("ti,da850-aemif", 0x68000000, "ti-aemif", NULL),
> + OF_DEV_AUXDATA("ti,da850-vpif", 0x01e17000, "vpif", NULL),
> {}
> };
>
> #ifdef CONFIG_ARCH_DAVINCI_DA850
>
> +#if IS_ENABLED(CONFIG_VIDEO_DAVINCI_VPIF_CAPTURE)
> +static __init void da850_vpif_capture_init(void)
> +{
> + int ret;
> +
> + ret = davinci_cfg_reg_list(da850_vpif_capture_pins);
Why can't we use the existing pinctrl-single node in device tree for
muxing the pins?
> + if (ret)
> + pr_warn("da850_evm_init: VPIF capture mux setup failed: %d\n",
> + ret);
> +}
> +#else
> +#define da850_vpif_capture_init()
> +#endif
> +
> static void __init da850_init_machine(void)
> {
> of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
> + da850_vpif_capture_init();
> }
>
> static const char *const da850_boards_compat[] __initconst = {
>
^ permalink raw reply
* [PATCH] clk: bcm2835: Fix ->fixed_divider of pllh_aux
From: Eric Anholt @ 2016-11-22 20:45 UTC (permalink / raw)
To: linux-arm-kernel
From: Boris Brezillon <boris.brezillon@free-electrons.com>
There is no fixed divider on pllh_aux.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
---
This was copy and paste failure on my (anholt's) part. The divider of
10 is on PLLH_PIX. No need to worry about backporting, as this
channel is only used for the VEC support I'm hoping to land for
4.11.
drivers/clk/bcm/clk-bcm2835.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
index b68bf573dcfb..82568bfe5a72 100644
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -1599,7 +1599,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.a2w_reg = A2W_PLLH_AUX,
.load_mask = CM_PLLH_LOADAUX,
.hold_mask = 0,
- .fixed_divider = 10),
+ .fixed_divider = 1),
[BCM2835_PLLH_PIX] = REGISTER_PLL_DIV(
.name = "pllh_pix",
.source_pll = "pllh",
--
2.10.2
^ permalink raw reply related
* [PATCH v3 1/2] devicetree: Add vendor prefix for CZ.NIC
From: Uwe Kleine-König @ 2016-11-22 20:59 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
Acked-by: Rob Herring <robh@kernel.org>
---
changes since v2:
- add ack by Rob Herring
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index f0a48ea78659..ae9fce9fed03 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -67,6 +67,7 @@ creative Creative Technology Ltd
crystalfontz Crystalfontz America, Inc.
cubietech Cubietech, Ltd.
cypress Cypress Semiconductor Corporation
+cznic CZ.NIC, z.s.p.o.
dallas Maxim Integrated Products (formerly Dallas Semiconductor)
davicom DAVICOM Semiconductor, Inc.
delta Delta Electronics, Inc.
--
2.10.2
^ permalink raw reply related
* [PATCH v3 2/2] ARM: dts: add support for Turris Omnia
From: Uwe Kleine-König @ 2016-11-22 20:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122205908.7297-1-uwe@kleine-koenig.org>
This machine is an open hardware router by cz.nic driven by a
Marvell Armada 385.
Signed-off-by: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
---
Changes since (implicit) v1:
- disable rtc
- change compatible to "cznic,turris-omnia"
Changes since v2:
- fix comment for usb at 58000
- add gpio-expander that serves SPF and phy irq
I kept all three eth devices to keep the ethernet names when users upgrade.
Tomas said that he had problems with the emmc when operating it in DDR50
mode. I didn't see any I/O errors so far and didn't find a way to
limit the device to SDR50 via dt.
IMHO even with some peripherals still missing (SFP, switch, wlan) it
would be the right thing to take this patch as a base to get the
remaining bits sorted. Is it still possible to get it into 4.10?
Best regards
Uwe
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-385-turris-omnia.dts | 282 ++++++++++++++++++++++++++
2 files changed, 283 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-385-turris-omnia.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd2619902..f1d3b9ff257e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -920,6 +920,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
armada-385-db-ap.dtb \
armada-385-linksys-caiman.dtb \
armada-385-linksys-cobra.dtb \
+ armada-385-turris-omnia.dtb \
armada-388-clearfog.dtb \
armada-388-db.dtb \
armada-388-gp.dtb \
diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
new file mode 100644
index 000000000000..a750fd8d8225
--- /dev/null
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -0,0 +1,282 @@
+/*
+ * Device Tree file for the Turris Omnia
+ * Schematic available at https://www.turris.cz/doc/_media/rtrom01-schema.pdf
+ *
+ * Copyright (C) 2016 Uwe Kleine-K?nig <uwe@kleine-koenig.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "armada-385.dtsi"
+
+/ {
+ model = "Turris Omnia";
+ compatible = "cznic,turris-omnia", "marvell,armada385", "marvell,armada380";
+
+ chosen {
+ stdout-path = &uart0;
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x40000000>; /* 1024 MB */
+ };
+
+ soc {
+ ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
+ MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000>;
+
+ internal-regs {
+
+ /* part of PCIe */
+ usb at 58000 {
+ status = "okay";
+ };
+
+ rtc at a3800 {
+ /*
+ * There are several errata for this device
+ * still unimplemented. Without some love it only reports
+ * 2016-12-19 22:00:24. So disable for now.
+ */
+ status = "disabled";
+ };
+
+ sata at a8000 {
+ status = "okay";
+ };
+
+ sdhci at d8000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdhci_pins>;
+ status = "okay";
+
+ bus-width = <8>;
+ no-1-8-v;
+ non-removable;
+ };
+
+ usb3 at f0000 {
+ status = "okay";
+ };
+
+ usb3 at f8000 {
+ status = "okay";
+ };
+ };
+
+ pcie-controller {
+ status = "okay";
+
+ pcie at 1,0 {
+ /* Port 0, Lane 0 */
+ status = "okay";
+ };
+
+ pcie at 2,0 {
+ /* Port 2, Lane 0 */
+ status = "okay";
+ };
+
+ pcie at 3,0 {
+ /* Port 3, Lane 0 */
+ status = "okay";
+ };
+ };
+ };
+};
+
+ð0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ge0_rgmii_pins>;
+ status = "okay";
+ phy-mode = "rgmii-id";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
+
+ð1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ge1_rgmii_pins>;
+ status = "okay";
+ phy-mode = "rgmii-id";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
+
+/* WAN port */
+ð2 {
+ status = "okay";
+ phy-mode = "sgmii";
+ phy = <&phy1>;
+};
+
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+ status = "okay";
+
+ i2cmux at 70 {
+ compatible = "nxp,pca9547";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x70>;
+ status = "okay";
+
+ i2c at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ status = "okay";
+
+ /* STM32F0 at address 0x2a */
+ /* leds device at address 0x2b */
+
+ eeprom at 54 {
+ /* holds configuration about RAM, evaluated by bootloader */
+ compatible = "at,24c64";
+ reg = <0x54>;
+ };
+ };
+
+ i2c at 5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+
+ /* ATSHA204A at address 0x64 */
+ };
+
+ i2c at 6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+
+ /* exposed on pin header */
+ };
+
+ i2c at 7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+
+ pcawan: gpio at 71 {
+ compatible = "nxp,pca9538";
+ reg = <0x71>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcawan_pins>;
+
+ interrupt-parent = <&gpio1>;
+ interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+ };
+};
+
+&mdio {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mdio_pins>;
+ status = "okay";
+
+ phy1: phy at 1 {
+ status = "okay";
+ compatible = "ethernet-phy-id0141.0DD1", "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+
+ /* There is a Switch (MV88E7176) at address 0x10 */
+};
+
+&pinctrl {
+ pcawan_pins: pcawan-pins {
+ marvell,pins = "mpp46";
+ marvell,function = "gpio";
+ };
+
+ spi0cs1_pins: spi0-pins-0cs1 {
+ marvell,pins = "mpp26";
+ marvell,function = "spi0";
+ };
+};
+
+&spi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_pins &spi0cs1_pins>;
+ status = "okay";
+
+ spi-nor at 0 {
+ compatible = "spansion,s25fl164k", "jedec,spi-nor";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0>;
+ spi-max-frequency = <40000000>;
+
+ partition at 0 {
+ reg = <0x0 0x00100000>;
+ label = "U-Boot";
+ };
+
+ partition at 1 {
+ reg = <0x00100000 0x00700000>;
+ label = "Rescue system";
+ };
+ };
+
+ /* @1 is on pin header */
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins>;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>;
+ status = "okay";
+};
--
2.10.2
^ permalink raw reply related
* [PATCH net-next 1/4] net: mvneta: Convert to be 64 bits compatible
From: Arnd Bergmann @ 2016-11-22 21:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122164844.19566-2-gregory.clement@free-electrons.com>
On Tuesday, November 22, 2016 5:48:41 PM CET Gregory CLEMENT wrote:
> +#ifdef CONFIG_64BIT
> + void *data_tmp;
> +
> + /* In Neta HW only 32 bits data is supported, so in order to
> + * obtain whole 64 bits address from RX descriptor, we store
> + * the upper 32 bits when allocating buffer, and put it back
> + * when using buffer cookie for accessing packet in memory.
> + * Frags should be allocated from single 'memory' region,
> + * hence common upper address half should be sufficient.
> + */
> + data_tmp = mvneta_frag_alloc(pp->frag_size);
> + if (data_tmp) {
> + pp->data_high = (u64)upper_32_bits((u64)data_tmp) << 32;
> + mvneta_frag_free(pp->frag_size, data_tmp);
> + }
>
How does this work when the region spans a n*4GB address boundary?
Arnd
^ permalink raw reply
* [PATCH] dt-bindings: mfd: Improve readability for TPS65217 interrupt sources
From: Arnd Bergmann @ 2016-11-22 21:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122160013.GH10134@dell.home>
On Tuesday, November 22, 2016 4:00:13 PM CET Lee Jones wrote:
> > > diff --git a/include/dt-bindings/mfd/tps65217.h b/include/dt-bindings/mfd/tps65217.h
> > > index cafb9e6..0293fdd 100644
> > > --- a/include/dt-bindings/mfd/tps65217.h
> > > +++ b/include/dt-bindings/mfd/tps65217.h
> > > @@ -19,8 +19,8 @@
> > > #ifndef __DT_BINDINGS_TPS65217_H__
> > > #define __DT_BINDINGS_TPS65217_H__
> > >
> > > -#define TPS65217_IRQ_USB 0
> > > -#define TPS65217_IRQ_AC 1
> > > -#define TPS65217_IRQ_PB 2
> > > +#define TPS65217_IRQ_USB_POWER 0 /* USB power state change */
> > > +#define TPS65217_IRQ_AC_POWER 1 /* AC power state change */
> > > +#define TPS65217_IRQ_PUSHBUTTON 2 /* Push button state change */
> >
> > This changes the ABI.
> >
> > It will require a DT Ack.
>
> Tell a lie. Sorry, I was getting false positives from my grep. It
> looks like you use the same scheme from within include/linux. I
> suggest that you probable don't want to do that.
Doing this change however would cause a bisection problem: you
can't rename just the constants in the header or just the driver
using those constants.
Arnd
^ permalink raw reply
* [PATCH 1/2] PCI: iproc: fix 32-bit build
From: Arnd Bergmann @ 2016-11-22 21:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e03e5c52-f321-916e-4650-c8bb271cd041@broadcom.com>
On Tuesday, November 22, 2016 9:42:05 AM CET Ray Jui wrote:
>
> Hmmm, somehow we've never seen this link error for the ARM32 based
> platforms that we build for. Does it behave differently between
> different versions of compilers?
>
> Nevertheless, this is a good change to take, thanks!
I looked at it again, and see now that it only happens with
a 64-bit RESOURCE_SIZE_T, which is only used on 32-bit
platforms with more than 4GB of memory addresses. It would
however show up in a multiplatform distro build for ARMv7VE,
so the fix is still clearly needed.
Arnd
^ permalink raw reply
* [PATCH] ARM: fix kmemleak for XIP_KERNEL
From: Kees Cook @ 2016-11-22 21:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122142829.1776129-1-arnd@arndb.de>
On Tue, Nov 22, 2016 at 6:28 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The newly added check for RO_AFTER_INIT_DATA in kmemleak breaks ARM whenever
> XIP_KERNEL is enabled:
>
> mm/kmemleak.o: In function `kmemleak_scan':
> kmemleak.c:(.text.kmemleak_scan+0x2e4): undefined reference to `__end_data_ro_after_init'
> kmemleak.c:(.text.kmemleak_scan+0x2e8): undefined reference to `__start_data_ro_after_init'
>
> This adds the start/end symbols for the section even in the case of having
> no data in the section, to make the check work while keeping the architecture
> specific override in one place.
>
> Fixes: d7c19b066dcf ("mm: kmemleak: scan .data.ro_after_init")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Kees Cook <keescook@chromium.org>
-Kees
> ---
> The patch causing this was merged late into v4.9-rc, this one should
> probably go there as well.
>
> I assume the same problem exists on s390, but I have not checked that.
> ---
> arch/arm/kernel/vmlinux-xip.lds.S | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/kernel/vmlinux-xip.lds.S b/arch/arm/kernel/vmlinux-xip.lds.S
> index 06c178214629..bf900f5421a1 100644
> --- a/arch/arm/kernel/vmlinux-xip.lds.S
> +++ b/arch/arm/kernel/vmlinux-xip.lds.S
> @@ -3,8 +3,11 @@
> * Written by Martin Mares <mj@atrey.karlin.mff.cuni.cz>
> */
>
> -/* No __ro_after_init data in the .rodata section - which will always be ro */
> -#define RO_AFTER_INIT_DATA
> +/* empty __ro_after_init data in the .rodata section - it will always be ro */
> +#define RO_AFTER_INIT_DATA \
> + __start_data_ro_after_init = .; \
> + __end_data_ro_after_init = .;
> +
>
> #include <asm-generic/vmlinux.lds.h>
> #include <asm/cache.h>
> --
> 2.9.0
>
--
Kees Cook
Nexus Security
^ permalink raw reply
* [PATCH 2/2] PCI: iproc: avoid maybe-uninitialized warning
From: Arnd Bergmann @ 2016-11-22 21:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <31c4c52b-3de5-2277-7a44-2a4231531074@broadcom.com>
On Tuesday, November 22, 2016 9:45:24 AM CET Ray Jui wrote:
> > diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
> > index 857ff5198317..0359569c8d78 100644
> > --- a/drivers/pci/host/pcie-iproc.c
> > +++ b/drivers/pci/host/pcie-iproc.c
> > @@ -936,6 +936,7 @@ static int iproc_pcie_setup_ib(struct iproc_pcie *pcie,
> >
> > }
> > }
> > + ret = -EINVAL;
> > err_ib:
> > dev_err(dev, "unable to configure inbound mapping\n");
> > dev_err(dev, "axi %pap, pci %pap, res size %pap\n",
> >
>
> This change is good, but in my opinion, a further improvement for
> clarity would be to initialize 'ret' to -EINVAL in the beginning of this
> function when 'ret' is declared. What do you think?
>
I never do that, see https://rusty.ozlabs.org/?p=232 for a great
explanation about why.
Arnd
^ permalink raw reply
* [RFC PATCH 04/11] PCI: tegra: limit to MMU build only
From: Arnd Bergmann @ 2016-11-22 21:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <65053923-c783-d8d9-d594-aa18cbed413e@wwwdotorg.org>
On Tuesday, November 22, 2016 9:15:13 AM CET Stephen Warren wrote:
> On 11/22/2016 02:26 AM, Vladimir Murzin wrote:
> > This driver uses functionality which available for MMU build only,
> > thus add dependency on MMU.
>
> I'd expect ARCH_TEGRA to depend on MMU instead.
>
Any particular reason for why we'd single out Tegra?
Arnd
^ permalink raw reply
* [PATCH 1/6] arm64: Use full path in KBUILD_IMAGE definition
From: Michal Marek @ 2016-11-22 21:34 UTC (permalink / raw)
To: linux-arm-kernel
The KBUILD_IMAGE variable is used by the rpm and deb-pkg targets, which
expect it to point to the image file in the build directory. The
builddeb script has a workaround for architectures which only provide
the basename, but let's provide a clean interface for packaging tools.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Michal Marek <mmarek@suse.com>
---
arch/arm64/Makefile | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 3635b8662724..80b6866bcacb 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -94,12 +94,12 @@ libs-y := arch/arm64/lib/ $(libs-y)
core-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
# Default target when executing plain make
-KBUILD_IMAGE := Image.gz
+boot := arch/arm64/boot
+KBUILD_IMAGE := $(boot)/Image.gz
KBUILD_DTBS := dtbs
-all: $(KBUILD_IMAGE) $(KBUILD_DTBS)
+all: Image.gz $(KBUILD_DTBS)
-boot := arch/arm64/boot
Image: vmlinux
$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
--
2.10.0
^ permalink raw reply related
* [PATCH 2/6] arm: Use full path in KBUILD_IMAGE definition
From: Michal Marek @ 2016-11-22 21:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122213434.14788-1-mmarek@suse.com>
The KBUILD_IMAGE variable is used by the rpm and deb-pkg targets, which
expect it to point to the image file in the build directory. The
builddeb script has a workaround for architectures which only provide
the basename, but let's provide a clean interface for packaging tools.
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Michal Marek <mmarek@suse.com>
---
arch/arm/Makefile | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 6be9ee148b78..f3fa2cafca15 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -296,10 +296,11 @@ drivers-$(CONFIG_OPROFILE) += arch/arm/oprofile/
libs-y := arch/arm/lib/ $(libs-y)
# Default target when executing plain make
+boot := arch/arm/boot
ifeq ($(CONFIG_XIP_KERNEL),y)
-KBUILD_IMAGE := xipImage
+KBUILD_IMAGE := $(boot)/xipImage
else
-KBUILD_IMAGE := zImage
+KBUILD_IMAGE := $(boot)/zImage
endif
# Build the DT binary blobs if we have OF configured
@@ -307,9 +308,8 @@ ifeq ($(CONFIG_USE_OF),y)
KBUILD_DTBS := dtbs
endif
-all: $(KBUILD_IMAGE) $(KBUILD_DTBS)
+all: $(notdir $(KBUILD_IMAGE)) $(KBUILD_DTBS)
-boot := arch/arm/boot
archprepare:
$(Q)$(MAKE) $(build)=arch/arm/tools include/generated/mach-types.h
--
2.10.0
^ permalink raw reply related
* [PATCH RFC] ARM: dts: add support for Turris Omnia
From: tomas.hlavacek at nic.cz @ 2016-11-22 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161120203037.pd5mhqyjeotileve@perseus.defre.kleine-koenig.org>
Hi Uwe!
On Sun, Nov 20, 2016 at 9:30 PM, Uwe Kleine-K?nig
<uwe@kleine-koenig.org> wrote:
> Hello Tomas,
>
> On Sat, Nov 19, 2016 at 09:09:07PM +0100, tomas.hlavacek at nic.cz wrote:
>> On Mon, Nov 14, 2016 at 9:28 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> > Interrupts don't seem to work very well with the nxp,pca9538.
>> Which
>> > is probably why it is disabled by default.
>>
>> I was thinking about this issue and I can remember that there was
>> an earlier
>> prototype that had a shared interrupt line from PHY (88E1514) and
>> from the
>> PCA9538. In this case we needed to specifically disable the
>> interrupt of the
>> PHY to release the interrupt line (which needed a hack into PHY
>> driver
>> code). The IRQ from PHY is connected as an ordinary input to
>> PCA9538 in
>> later board prototype. And the same holds for the production
>> version.
>
> That would explain why I see an "irq but nobody cared" message when
> booting the original system.
>
> This isn't the problem I meant though. When adding interrupt-parent =
> <&pcawan>; interrupts = <7 IRQ_TYPE_LEVEL_LOW>; to the phy node I get
> an
> error saying that there is no irq domain associated with this device.
>
>> Do you have CZ11NIC13 or older board revision?
>
> CZ11NIC12 is indicated on my board.
:-( Well, this board version has wrongly matched length of some
differential pairs, IRQ from 88E1514 is connected differently, there
are slight differences in power supplies and (if I am not mistaken)
something changed in RTC support circuitry. It looks like a huge
mistake on our side.
Anyway I took your patch and tried few things:
- clean up comments
- add pca9538 interrupt-controller
- remove rtc disable (WFM with CZ11NIC13, which is the production board)
- add MBUS mem regions for CESA
- add IRQ for 88E1514 PHY - and there is a problem:
It seems that libphy is probed before pca9538 and we end up with:
[ 4.217550] libphy: orion_mdio_bus: probed
[ 4.221777] irq: no irq domain found for
/soc/internal-regs/i2c at 11000/i2cmux at 70/i2c at 7/gpio at 71 !
Any clue where to look in order to defer probing libphy or at least
orion_mdio_bus?
I'll post my version of the patch without the PHY IRQ (therefore
polling will kick in).
Thanks,
Tomas
^ permalink raw reply
* [PATCH v2] ARM: dts: da850: add the mstpri and ddrctl nodes
From: David Lechner @ 2016-11-22 22:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479207611-18028-1-git-send-email-bgolaszewski@baylibre.com>
On 11/15/2016 05:00 AM, Bartosz Golaszewski wrote:
> Add the nodes for the MSTPRI configuration and DDR2/mDDR memory
> controller drivers to da850.dtsi.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> v1 -> v2:
> - moved the priority controller node above the cfgchip node
> - renamed added nodes to better reflect their purpose
>
> arch/arm/boot/dts/da850.dtsi | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index 1bb1f6d..412eec6 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -210,6 +210,10 @@
> };
>
> };
> + prictrl: priority-controller at 14110 {
> + compatible = "ti,da850-mstpri";
> + reg = <0x14110 0x0c>;
I think we should add status = "disabled"; here and let boards opt in.
> + };
> cfgchip: chip-controller at 1417c {
> compatible = "ti,da830-cfgchip", "syscon", "simple-mfd";
> reg = <0x1417c 0x14>;
> @@ -451,4 +455,8 @@
> 1 0 0x68000000 0x00008000>;
> status = "disabled";
> };
> + memctrl: memory-controller at b0000000 {
> + compatible = "ti,da850-ddr-controller";
> + reg = <0xb0000000 0xe8>;
same here. status = "disabled";
> + };
> };
>
^ permalink raw reply
* [RFC PATCH 04/11] PCI: tegra: limit to MMU build only
From: Stephen Warren @ 2016-11-22 22:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4182371.efWsDqfOeS@wuerfel>
On 11/22/2016 02:16 PM, Arnd Bergmann wrote:
> On Tuesday, November 22, 2016 9:15:13 AM CET Stephen Warren wrote:
>> On 11/22/2016 02:26 AM, Vladimir Murzin wrote:
>>> This driver uses functionality which available for MMU build only,
>>> thus add dependency on MMU.
>>
>> I'd expect ARCH_TEGRA to depend on MMU instead.
>>
>
> Any particular reason for why we'd single out Tegra?
From the cover letter, it sounded like the point of the series was to
all !MMU builds for a bunch of SoCs with M-class cores. Tegra doesn't
have an M-class core so I wouldn't expect it to be included in such a
build. I'd expect the same fix that I suggested to apply to all
non-M-class SoCs, rather than fixing up individual drivers to depend on
!MMU.
^ permalink raw reply
* [PATCH V9 1/6] tracing: add a possibility of exporting function trace to other places instead of ring buffer only
From: Steven Rostedt @ 2016-11-22 22:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479715043-6534-2-git-send-email-zhang.chunyan@linaro.org>
On Mon, 21 Nov 2016 15:57:18 +0800
Chunyan Zhang <zhang.chunyan@linaro.org> wrote:
> Currently Function traces can be only exported to ring buffer, this
> patch added trace_export concept which can process traces and export
> them to a registered destination as an addition to the current only
> one output of Ftrace - i.e. ring buffer.
>
> In this way, if we want Function traces to be sent to other destination
> rather than ring buffer only, we just need to register a new trace_export
> and implement its own .write() function for writing traces to storage.
>
> With this patch, only Function trace (trace type is TRACE_FN)
> is supported.
>
> Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org>
> ---
> include/linux/trace.h | 28 +++++++++++
> kernel/trace/trace.c | 129 +++++++++++++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 156 insertions(+), 1 deletion(-)
> create mode 100644 include/linux/trace.h
>
> diff --git a/include/linux/trace.h b/include/linux/trace.h
> new file mode 100644
> index 0000000..9330a58
> --- /dev/null
> +++ b/include/linux/trace.h
> @@ -0,0 +1,28 @@
> +#ifndef _LINUX_TRACE_H
> +#define _LINUX_TRACE_H
> +
> +#ifdef CONFIG_TRACING
> +/*
> + * The trace export - an export of Ftrace output. The trace_export
> + * can process traces and export them to a registered destination as
> + * an addition to the current only output of Ftrace - i.e. ring buffer.
> + *
> + * If you want traces to be sent to some other place rather than ring
> + * buffer only, just need to register a new trace_export and implement
> + * its own .write() function for writing traces to the storage.
> + *
> + * next - pointer to the next trace_export
> + * write - copy traces which have been delt with ->commit() to
> + * the destination
> + */
> +struct trace_export {
> + struct trace_export __rcu *next;
> + void (*write)(const void *, unsigned int);
> +};
> +
> +int register_ftrace_export(struct trace_export *export);
> +int unregister_ftrace_export(struct trace_export *export);
> +
> +#endif /* CONFIG_TRACING */
> +
> +#endif /* _LINUX_TRACE_H */
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 8696ce6..038291d 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -40,6 +40,7 @@
> #include <linux/poll.h>
> #include <linux/nmi.h>
> #include <linux/fs.h>
> +#include <linux/trace.h>
> #include <linux/sched/rt.h>
>
> #include "trace.h"
> @@ -2128,6 +2129,129 @@ void trace_buffer_unlock_commit_regs(struct trace_array *tr,
> ftrace_trace_userstack(buffer, flags, pc);
> }
>
> +static void
> +trace_process_export(struct trace_export *export,
> + struct ring_buffer_event *event)
> +{
> + struct trace_entry *entry;
> + unsigned int size = 0;
> +
> + entry = ring_buffer_event_data(event);
> + size = ring_buffer_event_length(event);
> + export->write(entry, size);
> +}
> +
> +static DEFINE_MUTEX(ftrace_export_lock);
> +
> +static struct trace_export __rcu *ftrace_exports_list __read_mostly;
> +
> +static DEFINE_STATIC_KEY_FALSE(ftrace_exports_enabled);
> +
> +static inline void ftrace_exports_enable(void)
> +{
> + static_branch_enable(&ftrace_exports_enabled);
> +}
> +
> +static inline void ftrace_exports_disable(void)
> +{
> + static_branch_disable(&ftrace_exports_enabled);
> +}
> +
> +void ftrace_exports(struct ring_buffer_event *event)
I'm currently testing the patches, but is there a reason that
ftrace_exports() is not static?
-- Steve
> +{
> + struct trace_export *export;
> +
> + preempt_disable_notrace();
> +
> + export = rcu_dereference_raw_notrace(ftrace_exports_list);
> + while (export) {
> + trace_process_export(export, event);
> + export = rcu_dereference_raw_notrace(export->next);
> + }
> +
> + preempt_enable_notrace();
> +}
> +
> +static inline void
> +add_trace_export(struct trace_export **list, struct trace_export *export)
> +{
> + rcu_assign_pointer(export->next, *list);
> + /*
> + * We are entering export into the list but another
> + * CPU might be walking that list. We need to make sure
> + * the export->next pointer is valid before another CPU sees
> + * the export pointer included into the list.
> + */
> + rcu_assign_pointer(*list, export);
> +}
> +
> +static inline int
> +rm_trace_export(struct trace_export **list, struct trace_export *export)
> +{
> + struct trace_export **p;
> +
> + for (p = list; *p != NULL; p = &(*p)->next)
> + if (*p == export)
> + break;
> +
> + if (*p != export)
> + return -1;
> +
> + rcu_assign_pointer(*p, (*p)->next);
> +
> + return 0;
> +}
> +
> +static inline void
> +add_ftrace_export(struct trace_export **list, struct trace_export *export)
> +{
> + if (*list == NULL)
> + ftrace_exports_enable();
> +
> + add_trace_export(list, export);
> +}
> +
> +static inline int
> +rm_ftrace_export(struct trace_export **list, struct trace_export *export)
> +{
> + int ret;
> +
> + ret = rm_trace_export(list, export);
> + if (*list == NULL)
> + ftrace_exports_disable();
> +
> + return ret;
> +}
> +
> +int register_ftrace_export(struct trace_export *export)
> +{
> + if (WARN_ON_ONCE(!export->write))
> + return -1;
> +
> + mutex_lock(&ftrace_export_lock);
> +
> + add_ftrace_export(&ftrace_exports_list, export);
> +
> + mutex_unlock(&ftrace_export_lock);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(register_ftrace_export);
> +
> +int unregister_ftrace_export(struct trace_export *export)
> +{
> + int ret;
> +
> + mutex_lock(&ftrace_export_lock);
> +
> + ret = rm_ftrace_export(&ftrace_exports_list, export);
> +
> + mutex_unlock(&ftrace_export_lock);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(unregister_ftrace_export);
> +
> void
> trace_function(struct trace_array *tr,
> unsigned long ip, unsigned long parent_ip, unsigned long flags,
> @@ -2146,8 +2270,11 @@ trace_function(struct trace_array *tr,
> entry->ip = ip;
> entry->parent_ip = parent_ip;
>
> - if (!call_filter_check_discard(call, entry, buffer, event))
> + if (!call_filter_check_discard(call, entry, buffer, event)) {
> + if (static_branch_unlikely(&ftrace_exports_enabled))
> + ftrace_exports(event);
> __buffer_unlock_commit(buffer, event);
> + }
> }
>
> #ifdef CONFIG_STACKTRACE
^ permalink raw reply
* [RFC PATCH 04/11] PCI: tegra: limit to MMU build only
From: Arnd Bergmann @ 2016-11-22 22:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d9fd3fab-d648-0664-bd73-994bebf36bf4@wwwdotorg.org>
On Tuesday, November 22, 2016 3:27:35 PM CET Stephen Warren wrote:
> On 11/22/2016 02:16 PM, Arnd Bergmann wrote:
> > On Tuesday, November 22, 2016 9:15:13 AM CET Stephen Warren wrote:
> >> On 11/22/2016 02:26 AM, Vladimir Murzin wrote:
> >>> This driver uses functionality which available for MMU build only,
> >>> thus add dependency on MMU.
> >>
> >> I'd expect ARCH_TEGRA to depend on MMU instead.
> >>
> >
> > Any particular reason for why we'd single out Tegra?
>
> From the cover letter, it sounded like the point of the series was to
> all !MMU builds for a bunch of SoCs with M-class cores. Tegra doesn't
> have an M-class core so I wouldn't expect it to be included in such a
> build. I'd expect the same fix that I suggested to apply to all
> non-M-class SoCs, rather than fixing up individual drivers to depend on
> !MMU.
I think you misread that, the point is to get NOMMU support back for
machines other than ARMv7-M, the Cortex-M based machines already work
without this.
Arnd
^ permalink raw reply
* [PATCH V9 11/11] ARM64/PCI: Support for ACPI based PCI host controller
From: Bjorn Helgaas @ 2016-11-22 23:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1465588519-11334-12-git-send-email-tn@semihalf.com>
Hi Tomasz,
On Fri, Jun 10, 2016 at 09:55:19PM +0200, Tomasz Nowicki wrote:
> Implement pci_acpi_scan_root and other arch-specific call so that ARM64
> can start using ACPI to setup and enumerate PCI buses.
>
> Prior to buses enumeration the pci_acpi_scan_root() implementation looks
> for configuration space start address (obtained through ACPI _CBA method or
> MCFG interface). If succeed, it uses ECAM library to create new mapping.
> Then it attaches generic ECAM ops (pci_generic_ecam_ops) which are used
> for accessing configuration space later on.
> ...
> +static struct acpi_pci_root_ops acpi_pci_root_ops = {
> + .release_info = pci_acpi_generic_release_info,
> +};
> +
> +/* Interface called from ACPI code to setup PCI host controller */
> struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
> {
> - /* TODO: Should be revisited when implementing PCI on ACPI */
> - return NULL;
> + int node = acpi_get_node(root->device->handle);
> + struct acpi_pci_generic_root_info *ri;
> + struct pci_bus *bus, *child;
> +
> + ri = kzalloc_node(sizeof(*ri), GFP_KERNEL, node);
> + if (!ri)
> + return NULL;
> +
> + ri->cfg = pci_acpi_setup_ecam_mapping(root);
> + if (!ri->cfg) {
> + kfree(ri);
> + return NULL;
> + }
> +
> + acpi_pci_root_ops.pci_ops = &ri->cfg->ops->pci_ops;
This has already been merged, but this isn't right, is it? We're
writing a host controller-specific pointer into the single system-wide
acpi_pci_root_ops, then passing it on to acpi_pci_root_create().
Today, I think ri->cfg->ops->pci_ops is always &pci_generic_ecam_ops,
from this path:
ri->cfg = pci_acpi_setup_ecam_mapping
cfg = pci_ecam_create(..., &pci_generic_ecam_ops)
cfg = kzalloc(...)
cfg->ops = ops # &pci_generic_ecam_ops
But we're about to merge the ECAM quirks series, which will mean it
may not be &pci_generic_ecam_ops. Even apart from the ECAM quirks, we
should avoid this pattern of putting device-specific info in a single
shared structure because it's too difficult to verify that it's
correct.
> + bus = acpi_pci_root_create(root, &acpi_pci_root_ops, &ri->common,
> + ri->cfg);
Bjorn
^ permalink raw reply
* [GIT PULL] Second Round of Renesas ARM Based SoC Updates for v4.10
From: Olof Johansson @ 2016-11-22 23:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdUtu9N28rOb+813DumtbyAZJB3G+euD0mwwXD_jCiXrRg@mail.gmail.com>
On Tue, Nov 22, 2016 at 1:56 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Olof,
>
> On Mon, Nov 21, 2016 at 5:35 PM, Olof Johansson <olof@lixom.net> wrote:
>> On Mon, Nov 21, 2016 at 8:27 AM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> On Mon, Nov 21, 2016 at 5:19 PM, Olof Johansson <olof@lixom.net> wrote:
>>>> On Mon, Nov 21, 2016 at 1:31 AM, Geert Uytterhoeven
>>>> <geert@linux-m68k.org> wrote:
>>>>> On Sat, Nov 19, 2016 at 2:28 AM, Olof Johansson <olof@lixom.net> wrote:
>>>>>> On Thu, Nov 17, 2016 at 02:34:25PM +0100, Simon Horman wrote:
>>>>>>> Please consider these second round of Renesas ARM based SoC updates for v4.10.
>>>>>
>>>>>>> * Basic support for r8a7745 SoC
>>>>>>>
>>>>>>> ----------------------------------------------------------------
>>>>>>> Sergei Shtylyov (2):
>>>>>>> ARM: shmobile: r8a7745: basic SoC support
>>>>>>> ARM: shmobile: document SK-RZG1E board
>>>>>>
>>>>>> Is there a reason you're adding a config option per SoC?
>>>>>>
>>>>>> I think you'd be better off not adding these config options, and just adding
>>>>>> support for the SoCs through compatibles (and adding the drivers to defconfigs,
>>>>>> etc).
>>>>>
>>>>> Yes there is a reason: kernel size.
>>>>> The main offenders are the pinctrl tables, which add ca. 20-50 KiB per
>>>>> supported SoC.
>>>>
>>>> So don't turn on that pinctrl driver unless you have that SoC?
>>>
>>> The enablement of the pinctrl driver (and the clock driver, FWIW) is controlled
>>> by the SoC Kconfig symbol. If you want support for the SoC, you want the
>>> pinctrl driver, too.
>>
>> Oh, that's trivial to fix! Do as almost all other SoCs do, and don't
>> use silent options.
>
> What does that gain us? The ability to enable support for an SoC, without
> enabling the accompanying pinctrl driver, leading to a non-booting system?
It doesn't enable anything new, it just makes it less awkward for you
to add new SoCs in the future without creating dependencies on new
Kconfig symbols in the arch directory.
> As soon as you have any pinctrl properties in the DT, you need the pinctrl
> driver. Unless you disable CONFIG_PINCTRL (it's selected, and not
> user-controlled), and rely on fragile reset state/boot loader.
>
> Pinctrl (and clock and irqchip) on-SoC drivers are special: if you fail to
> include them, the system won't boot.
This isn't about booting without a pinctrl driver. It's about avoiding
adding new config symbols when they're not needed.
I started out comparing your way of using config options with, for
example, Exynos that has a bunch of different SoCs enabled. Having
dependencies described clearly has some value, since it can be hard to
know if you can turn off a driver and still have a bootable system
with some of the other platforms.
That being said, I think you should look at changing how you use your
config options to make it less messy to add new ones:
Looking around a bit, I noticed CLK_RENESAS_CPG_MSTP. This config
option is used awkwardly -- what you should have is a (silent) config
option that it depends on (such as {NEEDS|HAS}_CLK_CPG_MSTP or
similar), that each platform needing this can select. Then
CLK_RENESAS_CPG_MSTP only depends on that. No more need to touch this
config entry for every new SoC that is enabled.
Also, right now drivers/clk/renesas/Makefile is all keyed off of the
SoC config option, when instead you should consider a CLK_* option to
avoid duplication like you have today. For the shared platforms you
can do it just as above with HAS_.* config entries. Again, for some of
these you won't have to touch the clk/ directory at all any more for
new SoCs, the way the rcar2 ones have been made!
pinctrl config seems like it's a bit heavy on boiler plate as well.
Most of the entries do the same things. Many other platforms instead
select the pinctrl driver from the SoC Kconfig entry, maybe this is a
good approach here too, and avoids more boilerplate in the driver
directory. Of course, legacy SH platforms can probably be left alone
as they are though.
-Olof
^ permalink raw reply
* linux-next: manual merge of the clk tree with the arm-soc tree
From: Stephen Rothwell @ 2016-11-22 23:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdU5Df2kNT=ccr7Ts6=a1ELRJdiBbh1xxuqo+e_UeYw-tw@mail.gmail.com>
Hi Geert,
On Tue, 22 Nov 2016 10:36:46 +0100 Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Most of these are of the "add both sides" type.
> The only exception is the one in arch/arm/mach-shmobile/setup-rcar-gen2.c,
> where you just want to keep the call to of_clk_init(NULL);
>
> There's a resolution in
> https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git/log/?h=renesas-devel-20161117v2-v4.9-rc5%2brcar-rst
>
> Sorry for the mess.
Thanks for the help. Today I did this much earlier in the build and
got the following merge resolution (which matches yours, I think).
The resolution for arch/arm/mach-shmobile/setup-rcar-gen2.c is empty
because I used the clk tree side of the conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm/boot/dts/r8a7779.dtsi
index 9d3bb74bd3f6,8cf16008a09b..000000000000
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@@ -590,11 -590,11 +590,16 @@@
};
};
+ prr: chipid at ff000044 {
+ compatible = "renesas,prr";
+ reg = <0xff000044 4>;
+ };
+
+ rst: reset-controller at ffcc0000 {
+ compatible = "renesas,r8a7779-reset-wdt";
+ reg = <0xffcc0000 0x48>;
+ };
+
sysc: system-controller at ffd85000 {
compatible = "renesas,r8a7779-sysc";
reg = <0xffd85000 0x0200>;
diff --cc arch/arm/boot/dts/r8a7790.dtsi
index f554ef3c8096,3f10b0bf1b08..000000000000
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@@ -1471,11 -1471,11 +1471,16 @@@
};
};
+ prr: chipid at ff000044 {
+ compatible = "renesas,prr";
+ reg = <0 0xff000044 0 4>;
+ };
+
+ rst: reset-controller at e6160000 {
+ compatible = "renesas,r8a7790-rst";
+ reg = <0 0xe6160000 0 0x0100>;
+ };
+
sysc: system-controller at e6180000 {
compatible = "renesas,r8a7790-sysc";
reg = <0 0xe6180000 0 0x0200>;
diff --cc arch/arm/boot/dts/r8a7791.dtsi
index 4c50de2faef1,c465c79bcca6..000000000000
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@@ -1485,11 -1482,11 +1485,16 @@@
};
};
+ prr: chipid at ff000044 {
+ compatible = "renesas,prr";
+ reg = <0 0xff000044 0 4>;
+ };
+
+ rst: reset-controller at e6160000 {
+ compatible = "renesas,r8a7791-rst";
+ reg = <0 0xe6160000 0 0x0100>;
+ };
+
sysc: system-controller at e6180000 {
compatible = "renesas,r8a7791-sysc";
reg = <0 0xe6180000 0 0x0200>;
diff --cc arch/arm/boot/dts/r8a7792.dtsi
index 69789020cf39,6e1f61f65d29..000000000000
--- a/arch/arm/boot/dts/r8a7792.dtsi
+++ b/arch/arm/boot/dts/r8a7792.dtsi
@@@ -120,11 -118,11 +120,16 @@@
IRQ_TYPE_LEVEL_LOW)>;
};
+ prr: chipid at ff000044 {
+ compatible = "renesas,prr";
+ reg = <0 0xff000044 0 4>;
+ };
+
+ rst: reset-controller at e6160000 {
+ compatible = "renesas,r8a7792-rst";
+ reg = <0 0xe6160000 0 0x0100>;
+ };
+
sysc: system-controller at e6180000 {
compatible = "renesas,r8a7792-sysc";
reg = <0 0xe6180000 0 0x0200>;
diff --cc arch/arm/boot/dts/r8a7793.dtsi
index a377dda17724,e4b385eccf74..000000000000
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@@ -1306,11 -1279,11 +1306,16 @@@
};
};
+ prr: chipid at ff000044 {
+ compatible = "renesas,prr";
+ reg = <0 0xff000044 0 4>;
+ };
+
+ rst: reset-controller at e6160000 {
+ compatible = "renesas,r8a7793-rst";
+ reg = <0 0xe6160000 0 0x0100>;
+ };
+
sysc: system-controller at e6180000 {
compatible = "renesas,r8a7793-sysc";
reg = <0 0xe6180000 0 0x0200>;
diff --cc arch/arm/boot/dts/r8a7794.dtsi
index 63dc7f29d216,69e4f4fad89b..000000000000
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@@ -1377,11 -1375,11 +1377,16 @@@
};
};
+ prr: chipid at ff000044 {
+ compatible = "renesas,prr";
+ reg = <0 0xff000044 0 4>;
+ };
+
+ rst: reset-controller at e6160000 {
+ compatible = "renesas,r8a7794-rst";
+ reg = <0 0xe6160000 0 0x0100>;
+ };
+
sysc: system-controller at e6180000 {
compatible = "renesas,r8a7794-sysc";
reg = <0 0xe6180000 0 0x0200>;
diff --cc arch/arm/mach-shmobile/setup-rcar-gen2.c
index 14c1f0ed2ecb,b527258e0a62..000000000000
--- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
+++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
diff --cc arch/arm64/boot/dts/renesas/r8a7795.dtsi
index a39a702b904d,625dda713548..000000000000
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@@ -321,11 -321,11 +321,16 @@@
#power-domain-cells = <0>;
};
+ prr: chipid at fff00044 {
+ compatible = "renesas,prr";
+ reg = <0 0xfff00044 0 4>;
+ };
+
+ rst: reset-controller at e6160000 {
+ compatible = "renesas,r8a7795-rst";
+ reg = <0 0xe6160000 0 0x0200>;
+ };
+
sysc: system-controller at e6180000 {
compatible = "renesas,r8a7795-sysc";
reg = <0 0xe6180000 0 0x0400>;
diff --cc arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 41a050d2f192,75c8c55a8248..000000000000
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@@ -243,11 -233,11 +243,16 @@@
#power-domain-cells = <0>;
};
+ prr: chipid at fff00044 {
+ compatible = "renesas,prr";
+ reg = <0 0xfff00044 0 4>;
+ };
+
+ rst: reset-controller at e6160000 {
+ compatible = "renesas,r8a7796-rst";
+ reg = <0 0xe6160000 0 0x0200>;
+ };
+
sysc: system-controller at e6180000 {
compatible = "renesas,r8a7796-sysc";
reg = <0 0xe6180000 0 0x0400>;
diff --cc drivers/soc/renesas/Makefile
index 91c42b34705f,86cc78cd1962..000000000000
--- a/drivers/soc/renesas/Makefile
+++ b/drivers/soc/renesas/Makefile
@@@ -1,7 -1,8 +1,12 @@@
+obj-$(CONFIG_SOC_BUS) += renesas-soc.o
+
+ obj-$(CONFIG_ARCH_RCAR_GEN1) += rcar-rst.o
+ obj-$(CONFIG_ARCH_RCAR_GEN2) += rcar-rst.o
+ obj-$(CONFIG_ARCH_R8A7795) += rcar-rst.o
+ obj-$(CONFIG_ARCH_R8A7796) += rcar-rst.o
+
+obj-$(CONFIG_ARCH_R8A7743) += rcar-sysc.o r8a7743-sysc.o
+obj-$(CONFIG_ARCH_R8A7745) += rcar-sysc.o r8a7745-sysc.o
obj-$(CONFIG_ARCH_R8A7779) += rcar-sysc.o r8a7779-sysc.o
obj-$(CONFIG_ARCH_R8A7790) += rcar-sysc.o r8a7790-sysc.o
obj-$(CONFIG_ARCH_R8A7791) += rcar-sysc.o r8a7791-sysc.o
^ 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