* [PATCH v1.1] ARM: multi_v7_defconfig: Enable power sequence for Odroid U3
From: Javier Martinez Canillas @ 2017-01-09 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170107091651.10560-1-krzk@kernel.org>
Hello Krzysztof,
I think it would had been clearer if the subject prefix was "[PATCH v1.1 4/4]" :)
On 01/07/2017 06:16 AM, Krzysztof Kozlowski wrote:
> Odroid U3 needs a power sequence for lan9730, if it was enabled by
> bootloader. Also enable the USB3503 HSCI to USB2.0 driver (device
> is present on Odroid U3).
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> ---
>
Do you think that makes sense to also enable GPIO_SYS for debugging
purposes as you do in patch 3/4?
In any case the patch looks good to me:
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH 3/4] ARM: exynos_defconfig: Enable power sequence for Odroid U3
From: Javier Martinez Canillas @ 2017-01-09 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170107085203.4431-4-krzk@kernel.org>
Hello Krzysztof,
On 01/07/2017 05:52 AM, Krzysztof Kozlowski wrote:
> Odroid U3 needs a power sequence for lan9730, if it was enabled by
> bootloader. Enable also GPIO_SYSFS which is useful for playing with
> GPIO during debug process.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH 2/4] ARM: dts: exynos: Fix LAN9730 on Odroid U3 after tftpboot
From: Javier Martinez Canillas @ 2017-01-09 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170107085203.4431-3-krzk@kernel.org>
Hello Krzysztof,
On 01/07/2017 05:52 AM, Krzysztof Kozlowski wrote:
> The ethernet adapter LAN9730, after enabling in bootloader (e.g. for
> tftpboot) requires reset during boot. Otherwise it won't come up.
>
> The schematics of Odroid U3 are detailed enough but after grabbing
> knowledge also from other sources (like U-Boot) the overall design looks
> like:
> 1. LAN9730 is connected to HSIC0 and USB3503 to HSIC1 of EHCI controller.
> 2. USB3503 comes with its own reset pin: gpx3-5.
> 3. Reset pin of LAN9730 is pulled up to 3.3 V so it cannot be used.
> 4. The supply of 3.3 V for LAN9730 is delivered from buck8.
> 5. Buck8 state is a logical OR of registry value (through I2C command)
> and ENB8 pin. The ENB8, not described in schematics, is in fact
> gpa1-1.
> 6. Missing or wrongly timed reset of LAN9730 might result in missing of
> two devices: LAN9730 and USB3503. Without reset, LAN9730 will not
> come up, if it was enabled by bootloader.
>
> To fix the issue use the generic power sequence driver and toggle the
> ENB8 (buck8) pin. Reset duration of 500 us was chosen by experiments
> (shortest working time was 400 us). This is an easiest way to fix the
> long standing LAN9730 reset issue.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
Thanks for keep pushing a fix for this long standing issue.
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [RESEND 3/3] ARM: davinci_all_defconfig: enable iio and ADS7950
From: David Lechner @ 2017-01-09 16:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483978300-403-1-git-send-email-david@lechnology.com>
This enables the iio subsystem and the TI ADS7950 driver. This is used by
LEGO MINDSTORMS EV3, which has an ADS7957 chip.
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/configs/davinci_all_defconfig | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index 2b1967a..a899876 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -200,6 +200,13 @@ CONFIG_TI_EDMA=y
CONFIG_MEMORY=y
CONFIG_TI_AEMIF=m
CONFIG_DA8XX_DDRCTL=y
+CONFIG_IIO=m
+CONFIG_IIO_BUFFER_CB=m
+CONFIG_IIO_SW_DEVICE=m
+CONFIG_IIO_SW_TRIGGER=m
+CONFIG_TI_ADS7950=m
+CONFIG_IIO_HRTIMER_TRIGGER=m
+CONFIG_IIO_SYSFS_TRIGGER=m
CONFIG_PWM=y
CONFIG_PWM_TIECAP=m
CONFIG_PWM_TIEHRPWM=m
--
2.7.4
^ permalink raw reply related
* [RESEND 2/3] ARM: davinci_all_defconfig: Enable PWM modules
From: David Lechner @ 2017-01-09 16:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483978300-403-1-git-send-email-david@lechnology.com>
This enables PWM and the TI ECAP and EHRWPM modules. These are used on LEGO
MINDSTORMS EV3.
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/configs/davinci_all_defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index a12e4c2..2b1967a 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -200,6 +200,9 @@ CONFIG_TI_EDMA=y
CONFIG_MEMORY=y
CONFIG_TI_AEMIF=m
CONFIG_DA8XX_DDRCTL=y
+CONFIG_PWM=y
+CONFIG_PWM_TIECAP=m
+CONFIG_PWM_TIEHRPWM=m
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
CONFIG_EXT4_FS_POSIX_ACL=y
--
2.7.4
^ permalink raw reply related
* [RESEND 1/3] ARM: davinci_all_defconfig: enable DA8xx pinconf
From: David Lechner @ 2017-01-09 16:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483978300-403-1-git-send-email-david@lechnology.com>
This enables the DA8xx pinconf driver by default. It is needed by LEGO
MINDSTORMS EV3.
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/configs/davinci_all_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index ddb586a..a12e4c2 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -114,6 +114,7 @@ CONFIG_I2C_CHARDEV=y
CONFIG_I2C_DAVINCI=y
CONFIG_SPI=y
CONFIG_SPI_DAVINCI=m
+CONFIG_PINCTRL_DA850_PUPD=m
CONFIG_PINCTRL_SINGLE=y
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_PCA953X=y
--
2.7.4
^ permalink raw reply related
* [RESEND 0/3] davinci_all_defconfig patches for LEGO MINDSTORMS EV3
From: David Lechner @ 2017-01-09 16:11 UTC (permalink / raw)
To: linux-arm-kernel
Resending the patches that were missing my Signed-off-by:
David Lechner (3):
ARM: davinci_all_defconfig: enable DA8xx pinconf
ARM: davinci_all_defconfig: Enable PWM modules
ARM: davinci_all_defconfig: enable iio and ADS7950
arch/arm/configs/davinci_all_defconfig | 11 +++++++++++
1 file changed, 11 insertions(+)
--
2.7.4
^ permalink raw reply
* [PATCH 2/2] usb: host: ohci-exynos: Decrese node refcount on exynos_ehci_get_phy() error paths
From: Alan Stern @ 2017-01-09 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170107084141.3731-2-krzk@kernel.org>
On Sat, 7 Jan 2017, Krzysztof Kozlowski wrote:
> Returning from for_each_available_child_of_node() loop requires cleaning
> up node refcount. Error paths lacked it so for example in case of
> deferred probe, the refcount of phy node was left increased.
>
> Fixes: 6d40500ac9b6 ("usb: ehci/ohci-exynos: Fix of_node_put() for child when getting PHYs")
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> drivers/usb/host/ohci-exynos.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
> index 2cd105be7319..6865b919403f 100644
> --- a/drivers/usb/host/ohci-exynos.c
> +++ b/drivers/usb/host/ohci-exynos.c
> @@ -66,10 +66,12 @@ static int exynos_ohci_get_phy(struct device *dev,
> if (IS_ERR(phy)) {
> ret = PTR_ERR(phy);
> if (ret == -EPROBE_DEFER) {
> + of_node_put(child);
> return ret;
> } else if (ret != -ENOSYS && ret != -ENODEV) {
> dev_err(dev,
> "Error retrieving usb2 phy: %d\n", ret);
> + of_node_put(child);
> return ret;
> }
> }
Acked-by: Alan Stern <stern@rowland.harvard.edu>
^ permalink raw reply
* [PATCH 1/2] usb: host: ehci-exynos: Decrese node refcount on exynos_ehci_get_phy() error paths
From: Alan Stern @ 2017-01-09 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170107084141.3731-1-krzk@kernel.org>
On Sat, 7 Jan 2017, Krzysztof Kozlowski wrote:
> Returning from for_each_available_child_of_node() loop requires cleaning
> up node refcount. Error paths lacked it so for example in case of
> deferred probe, the refcount of phy node was left increased.
>
> Fixes: 6d40500ac9b6 ("usb: ehci/ohci-exynos: Fix of_node_put() for child when getting PHYs")
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> drivers/usb/host/ehci-exynos.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
> index 42e5b66353ef..7a603f66a9bc 100644
> --- a/drivers/usb/host/ehci-exynos.c
> +++ b/drivers/usb/host/ehci-exynos.c
> @@ -77,10 +77,12 @@ static int exynos_ehci_get_phy(struct device *dev,
> if (IS_ERR(phy)) {
> ret = PTR_ERR(phy);
> if (ret == -EPROBE_DEFER) {
> + of_node_put(child);
> return ret;
> } else if (ret != -ENOSYS && ret != -ENODEV) {
> dev_err(dev,
> "Error retrieving usb2 phy: %d\n", ret);
> + of_node_put(child);
> return ret;
> }
> }
>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
^ permalink raw reply
* [PATCH 1/4] ARM: dts: exynos: Fix indentation of EHCI and OHCI ports
From: Javier Martinez Canillas @ 2017-01-09 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170107085203.4431-2-krzk@kernel.org>
Hello Krzysztof,
On 01/07/2017 05:52 AM, Krzysztof Kozlowski wrote:
> Replace spaces with tabs in EHCI and OHCI ports indentation.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH 1/1] ARM: dts: add Armadeus Systems OPOS6UL AND OPOS6ULDEV support
From: Sébastien Szymanski @ 2017-01-09 16:00 UTC (permalink / raw)
To: linux-arm-kernel
OPOS6UL is an i.MX6UL based SoM.
OPOS6ULDev is a carrier board for the OPOS6UL SoM.
For more details see:
http://www.opossom.com/english/products-processor_boards-opos6ul.html
http://www.opossom.com/english/products-development_boards-opos6ul_dev.html
Signed-off-by: S?bastien Szymanski <sebastien.szymanski@armadeus.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6ul-opos6ul.dtsi | 192 +++++++++++++++
arch/arm/boot/dts/imx6ul-opos6uldev.dts | 414 ++++++++++++++++++++++++++++++++
3 files changed, 607 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6ul-opos6ul.dtsi
create mode 100644 arch/arm/boot/dts/imx6ul-opos6uldev.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7327250..f839c75 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -435,6 +435,7 @@ dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ul-14x14-evk.dtb \
imx6ul-geam-kit.dtb \
imx6ul-liteboard.dtb \
+ imx6ul-opos6uldev.dtb \
imx6ul-pico-hobbit.dtb \
imx6ul-tx6ul-0010.dtb \
imx6ul-tx6ul-0011.dtb \
diff --git a/arch/arm/boot/dts/imx6ul-opos6ul.dtsi b/arch/arm/boot/dts/imx6ul-opos6ul.dtsi
new file mode 100644
index 0000000..4673dde
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-opos6ul.dtsi
@@ -0,0 +1,192 @@
+/*
+ * Copyright 2016 Armadeus Systems <support@armadeus.com>
+ *
+ * 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 free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this file; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * 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.
+ */
+
+#include "imx6ul.dtsi"
+
+/ {
+ memory {
+ reg = <0x80000000 0>; /* will be filled by U-Boot */
+ };
+
+ reg_3v3: regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ usdhc3_pwrseq: usdhc3_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&gpio2 9 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&fec1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet1>;
+ phy-mode = "rmii";
+ phy-reset-duration = <1>;
+ phy-reset-gpios = <&gpio4 2 GPIO_ACTIVE_LOW>;
+ phy-handle = <ðphy1>;
+ phy-supply = <®_3v3>;
+ status = "okay";
+
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy1: ethernet-phy at 1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <16 IRQ_TYPE_LEVEL_LOW>;
+ status = "okay";
+ };
+ };
+};
+
+/* Bluetooth */
+&uart8 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart8>;
+ fsl,uart-has-rtscts;
+ status = "okay";
+};
+
+/* eMMC */
+&usdhc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ bus-width = <8>;
+ no-1-8-v;
+ non-removable;
+ status = "okay";
+};
+
+/* WiFi */
+&usdhc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ bus-width = <4>;
+ no-1-8-v;
+ non-removable;
+ mmc-pwrseq = <&usdhc3_pwrseq>;
+ status = "okay";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ brcmf: bcrmf at 1 {
+ compatible = "brcm,bcm4329-fmac";
+ reg = <1>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "host-wake";
+ };
+};
+
+&iomuxc {
+ pinctrl_enet1: enet1grp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO06__ENET1_MDIO 0x1b0b0
+ MX6UL_PAD_GPIO1_IO07__ENET1_MDC 0x1b0b0
+ MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER 0x130b0
+ MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x130b0
+ MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x130b0
+ MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x130b0
+ MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b0b0
+ MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b0b0
+ MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN 0x1b0b0
+ /* INT# */
+ MX6UL_PAD_NAND_DQS__GPIO4_IO16 0x1b0b0
+ /* RST# */
+ MX6UL_PAD_NAND_DATA00__GPIO4_IO02 0x130b0
+ MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 0x4001b031
+ >;
+ };
+
+ pinctrl_uart8: uart8grp {
+ fsl,pins = <
+ MX6UL_PAD_ENET2_TX_EN__UART8_DCE_RX 0x1b0b0
+ MX6UL_PAD_ENET2_TX_DATA1__UART8_DCE_TX 0x1b0b0
+ MX6UL_PAD_ENET2_RX_ER__UART8_DCE_RTS 0x1b0b0
+ MX6UL_PAD_ENET2_TX_CLK__UART8_DCE_CTS 0x1b0b0
+ /* BT_REG_ON */
+ MX6UL_PAD_ENET2_RX_EN__GPIO2_IO10 0x130b0
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x17059
+ MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x10059
+ MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x17059
+ MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x17059
+ MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x17059
+ MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x17059
+ MX6UL_PAD_NAND_READY_B__USDHC1_DATA4 0x17059
+ MX6UL_PAD_NAND_CE0_B__USDHC1_DATA5 0x17059
+ MX6UL_PAD_NAND_CE1_B__USDHC1_DATA6 0x17059
+ MX6UL_PAD_NAND_CLE__USDHC1_DATA7 0x17059
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6UL_PAD_LCD_DATA18__USDHC2_CMD 0x1b0b0
+ MX6UL_PAD_LCD_DATA19__USDHC2_CLK 0x100b0
+ MX6UL_PAD_LCD_DATA20__USDHC2_DATA0 0x1b0b0
+ MX6UL_PAD_LCD_DATA21__USDHC2_DATA1 0x1b0b0
+ MX6UL_PAD_LCD_DATA22__USDHC2_DATA2 0x1b0b0
+ MX6UL_PAD_LCD_DATA23__USDHC2_DATA3 0x1b0b0
+ /* WL_REG_ON */
+ MX6UL_PAD_ENET2_RX_DATA1__GPIO2_IO09 0x130b0
+ /* WL_IRQ */
+ MX6UL_PAD_ENET2_RX_DATA0__GPIO2_IO08 0x1b0b0
+ >;
+ };
+};
diff --git a/arch/arm/boot/dts/imx6ul-opos6uldev.dts b/arch/arm/boot/dts/imx6ul-opos6uldev.dts
new file mode 100644
index 0000000..a373562
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-opos6uldev.dts
@@ -0,0 +1,414 @@
+/*
+ * Copyright 2016 Armadeus Systems <support@armadeus.com>
+ *
+ * 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 free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this file; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * 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 "imx6ul-opos6ul.dtsi"
+
+/ {
+ model = "Armadeus Systems OPOS6UL SoM on OPOS6ULDev board";
+ compatible = "armadeus,opos6uldev", "armadeus,opos6ul", "fsl,imx6ul";
+
+ chosen {
+ stdout-path = &uart1;
+ };
+
+ lcd_backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm3 0 191000>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <7>;
+ power-supply = <®_5v>;
+ status = "okay";
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_keys>;
+
+ user-button {
+ label = "User button";
+ gpios = <&gpio2 11 GPIO_ACTIVE_LOW>;
+ linux,code = <BTN_MISC>;
+ wakeup-source;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ user_led {
+ label = "User";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_led>;
+ gpios = <&gpio3 4 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ onewire {
+ compatible = "w1-gpio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_w1>;
+ gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+ };
+
+ reg_5v: regulator-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "5V";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ reg_usbotg1_vbus: regulator-usbotg1vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usbotg1vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg1_vbus>;
+ gpio = <&gpio1 5 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_usbotg2_vbus: regulator-usbotg2vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usbotg2vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg2_vbus>;
+ gpio = <&gpio5 9 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+};
+
+&pwm3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm3>;
+ status = "okay";
+};
+
+&adc1 {
+ vref-supply = <®_3v3>;
+ status = "okay";
+};
+
+&can1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan1>;
+ xceiver-supply = <®_5v>;
+ status = "okay";
+};
+
+&can2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan2>;
+ xceiver-supply = <®_5v>;
+ status = "okay";
+};
+
+&ecspi4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi4>;
+ fsl,spi-num-chipselects = <2>;
+ cs-gpios = <&gpio4 9 GPIO_ACTIVE_LOW>, <&gpio4 3 GPIO_ACTIVE_LOW>;
+ status = "okay";
+
+ spidev0: spi at 0 {
+ compatible = "spidev";
+ reg = <0>;
+ spi-max-frequency = <5000000>;
+ };
+
+ spidev1: spi at 1 {
+ compatible = "spidev";
+ reg = <1>;
+ spi-max-frequency = <5000000>;
+ };
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ clock_frequency = <400000>;
+ status = "okay";
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ clock_frequency = <400000>;
+ status = "okay";
+};
+
+&lcdif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcdif>;
+ display = <&display0>;
+ lcd-supply = <®_3v3>;
+ status = "okay";
+
+ display0: display0 {
+ bits-per-pixel = <32>;
+ bus-width = <18>;
+
+ display-timings {
+ timing0: timing0 {
+ clock-frequency = <33000033>;
+ hactive = <800>;
+ vactive = <480>;
+ hback-porch = <96>;
+ hfront-porch = <96>;
+ vback-porch = <20>;
+ vfront-porch = <21>;
+ hsync-len = <64>;
+ vsync-len = <4>;
+ de-active = <1>;
+ pixelclk-active = <0>;
+ };
+ };
+ };
+};
+
+&snvs_pwrkey {
+ status = "disabled";
+};
+
+&tsc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tsc>;
+ xnur-gpio = <&gpio1 3 GPIO_ACTIVE_LOW>;
+ measure-delay-time = <0xffff>;
+ pre-charge-time = <0xffff>;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ status = "okay";
+};
+
+&usbotg1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg1_id>;
+ vbus-supply = <®_usbotg1_vbus>;
+ dr_mode = "otg";
+ disable-over-current;
+ status = "okay";
+};
+
+&usbotg2 {
+ vbus-supply = <®_usbotg2_vbus>;
+ dr_mode = "host";
+ disable-over-current;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpios>;
+
+ pinctrl_pwm3: pwm3grp {
+ fsl,pins = <
+ MX6UL_PAD_NAND_ALE__PWM3_OUT 0x1b0b0
+ >;
+ };
+
+ pinctrl_ecspi4: ecspi4grp {
+ fsl,pins = <
+ MX6UL_PAD_NAND_DATA04__ECSPI4_SCLK 0x1b0b0
+ MX6UL_PAD_NAND_DATA05__ECSPI4_MOSI 0x1b0b0
+ MX6UL_PAD_NAND_DATA06__ECSPI4_MISO 0x1b0b0
+ MX6UL_PAD_NAND_DATA01__GPIO4_IO03 0x1b0b0
+ MX6UL_PAD_NAND_DATA07__GPIO4_IO09 0x1b0b0
+ >;
+ };
+
+ pinctrl_flexcan1: flexcan1grp {
+ fsl,pins = <
+ MX6UL_PAD_UART3_CTS_B__FLEXCAN1_TX 0x0b0b0
+ MX6UL_PAD_UART3_RTS_B__FLEXCAN1_RX 0x0b0b0
+ >;
+ };
+
+ pinctrl_flexcan2: flexcan2grp {
+ fsl,pins = <
+ MX6UL_PAD_UART2_CTS_B__FLEXCAN2_TX 0x0b0b0
+ MX6UL_PAD_UART2_RTS_B__FLEXCAN2_RX 0x0b0b0
+ >;
+ };
+
+ pinctrl_gpios: gpiosgrp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO09__GPIO1_IO09 0x0b0b0
+ MX6UL_PAD_UART3_RX_DATA__GPIO1_IO25 0x0b0b0
+ MX6UL_PAD_UART3_TX_DATA__GPIO1_IO24 0x0b0b0
+ MX6UL_PAD_NAND_RE_B__GPIO4_IO00 0x0b0b0
+ MX6UL_PAD_GPIO1_IO08__GPIO1_IO08 0x0b0b0
+ MX6UL_PAD_UART1_CTS_B__GPIO1_IO18 0x0b0b0
+ MX6UL_PAD_UART1_RTS_B__GPIO1_IO19 0x0b0b0
+ MX6UL_PAD_NAND_WE_B__GPIO4_IO01 0x0b0b0
+ MX6UL_PAD_SNVS_TAMPER0__GPIO5_IO00 0x0b0b0
+ MX6UL_PAD_SNVS_TAMPER2__GPIO5_IO02 0x0b0b0
+ MX6UL_PAD_SNVS_TAMPER3__GPIO5_IO03 0x0b0b0
+ MX6UL_PAD_SNVS_TAMPER4__GPIO5_IO04 0x0b0b0
+ MX6UL_PAD_SNVS_TAMPER5__GPIO5_IO05 0x0b0b0
+ MX6UL_PAD_SNVS_TAMPER6__GPIO5_IO06 0x0b0b0
+ MX6UL_PAD_SNVS_TAMPER7__GPIO5_IO07 0x0b0b0
+ MX6UL_PAD_SNVS_TAMPER8__GPIO5_IO08 0x0b0b0
+ >;
+ };
+
+ pinctrl_w1: w1grp {
+ fsl,pins = <
+ MX6UL_PAD_SNVS_TAMPER1__GPIO5_IO01 0x0b0b0
+ >;
+ };
+
+ pinctrl_gpio_keys: gpio_keysgrp {
+ fsl,pins = <
+ MX6UL_PAD_ENET2_TX_DATA0__GPIO2_IO11 0x0b0b0
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX6UL_PAD_UART4_RX_DATA__I2C1_SDA 0x4001b8b0
+ MX6UL_PAD_UART4_TX_DATA__I2C1_SCL 0x4001b8b0
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX6UL_PAD_UART5_RX_DATA__I2C2_SDA 0x4001b8b0
+ MX6UL_PAD_UART5_TX_DATA__I2C2_SCL 0x4001b8b0
+ >;
+ };
+
+ pinctrl_lcdif: lcdifgrp {
+ fsl,pins = <
+ MX6UL_PAD_LCD_CLK__LCDIF_CLK 0x100b1
+ MX6UL_PAD_LCD_ENABLE__LCDIF_ENABLE 0x100b1
+ MX6UL_PAD_LCD_HSYNC__LCDIF_HSYNC 0x100b1
+ MX6UL_PAD_LCD_VSYNC__LCDIF_VSYNC 0x100b1
+ MX6UL_PAD_LCD_DATA00__LCDIF_DATA00 0x100b1
+ MX6UL_PAD_LCD_DATA01__LCDIF_DATA01 0x100b1
+ MX6UL_PAD_LCD_DATA02__LCDIF_DATA02 0x100b1
+ MX6UL_PAD_LCD_DATA03__LCDIF_DATA03 0x100b1
+ MX6UL_PAD_LCD_DATA04__LCDIF_DATA04 0x100b1
+ MX6UL_PAD_LCD_DATA05__LCDIF_DATA05 0x100b1
+ MX6UL_PAD_LCD_DATA06__LCDIF_DATA06 0x100b1
+ MX6UL_PAD_LCD_DATA07__LCDIF_DATA07 0x100b1
+ MX6UL_PAD_LCD_DATA08__LCDIF_DATA08 0x100b1
+ MX6UL_PAD_LCD_DATA09__LCDIF_DATA09 0x100b1
+ MX6UL_PAD_LCD_DATA10__LCDIF_DATA10 0x100b1
+ MX6UL_PAD_LCD_DATA11__LCDIF_DATA11 0x100b1
+ MX6UL_PAD_LCD_DATA12__LCDIF_DATA12 0x100b1
+ MX6UL_PAD_LCD_DATA13__LCDIF_DATA13 0x100b1
+ MX6UL_PAD_LCD_DATA14__LCDIF_DATA14 0x100b1
+ MX6UL_PAD_LCD_DATA15__LCDIF_DATA15 0x100b1
+ MX6UL_PAD_LCD_DATA16__LCDIF_DATA16 0x100b1
+ MX6UL_PAD_LCD_DATA17__LCDIF_DATA17 0x100b1
+ >;
+ };
+
+ pinctrl_led: ledgrp {
+ fsl,pins = <
+ MX6UL_PAD_LCD_RESET__GPIO3_IO04 0x0b0b0
+ >;
+ };
+
+ pinctrl_tsc: tscgrp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO01__GPIO1_IO01 0xb0
+ MX6UL_PAD_GPIO1_IO02__GPIO1_IO02 0xb0
+ MX6UL_PAD_GPIO1_IO03__GPIO1_IO03 0xb0
+ MX6UL_PAD_GPIO1_IO04__GPIO1_IO04 0xb0
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX6UL_PAD_UART1_TX_DATA__UART1_DCE_TX 0x1b0b1
+ MX6UL_PAD_UART1_RX_DATA__UART1_DCE_RX 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX6UL_PAD_UART2_TX_DATA__UART2_DCE_TX 0x1b0b1
+ MX6UL_PAD_UART2_RX_DATA__UART2_DCE_RX 0x1b0b1
+ >;
+ };
+
+ pinctrl_usbotg1_id: usbotg1_idgrp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO00__ANATOP_OTG1_ID 0x1b0b0
+ >;
+ };
+
+ pinctrl_usbotg1_vbus: usbotg1_vbusgrp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO05__GPIO1_IO05 0x1b0b0
+ >;
+ };
+
+ pinctrl_usbotg2_vbus: usbotg2_vbusgrp {
+ fsl,pins = <
+ MX6UL_PAD_SNVS_TAMPER9__GPIO5_IO09 0x1b0b0
+ >;
+ };
+};
--
2.7.3
^ permalink raw reply related
* [PATCH 1/2] ARM: hyp-stub: improve ABI
From: Russell King - ARM Linux @ 2017-01-09 15:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109150138.GJ4348@cbox>
On Mon, Jan 09, 2017 at 04:01:38PM +0100, Christoffer Dall wrote:
> Nobody is arguing with the need for documentation, and I think I
> understan the reason for needing to support a common ABI with a common
> set of functions regardless of the logic in place in Hyp mode.
>
> We just have to agree on a sane ABI and I'll be happy to help
> write/review the API docs and clean things up.
Let me make this crystal clear - this is where I am with this problem.
I've identified many issues with the ABI, and that there are several
differnet chunks of code which are a problem.
Although I've proposed a change to the hyp-stub ABI, which has since
been found to be insufficient, right now I have no better suggestions
to make. I'm operating in an information vaccuum here, and it is not
yet clear to me what changes to the hyp-stub and KVM ABI would be
acceptable. I don't know what environment the KVM hypervisor operates
in yet, eg whether it can see the kernel, whether it can see the IDMAP
region, etc.
Why would the IDMAP region be important? The hyp-stub doesn't setup
any page tables, so it seems to operate without any MMU translation.
That rather rules out passing virtual address pointers through a
common hyp-mode interface.
However, it seems that the KVM hypervisor does setup MMU translations,
making virtual addresses acceptable but physical/IDMAP addresses not.
So, right now I've no idea what a replacement ABI would look like.
Hence, the lack of _current_ documentation is hampering the situation.
Now, you've said to me privately that you think my demands for
documentation are unwarranted. I've been trying to gain enough
understanding that I can move forward, with my requests for
documentation being treated as "we'll do that later." Well, given
that, it leads me to only one possible outcome.
Enough is enough. Since there's no movement on the documentation
front, and because you're now saying that my demands for documentation
are unreasonable, I've reached the end of the road. There's nothing
more that I'm willing to do on this problem - at least not until there's
a change of heart wrt documentation.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCHv9 6/6] dmaengine: rcar-dmac: add iommu support for slave transfers
From: Niklas Söderlund @ 2017-01-09 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <26490346.qhNpbOL6eO@avalon>
Hi Laurent,
On 2017-01-02 01:08:04 +0200, Laurent Pinchart wrote:
> Hi Niklas,
>
> On Monday 05 Sep 2016 12:52:44 Laurent Pinchart wrote:
> > On Wednesday 10 Aug 2016 13:22:19 Niklas S?derlund wrote:
> > > Enable slave transfers to a device behind a IPMMU by mapping the slave
> > > addresses using the dma-mapping API.
> > >
> > > Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
> > > ---
> > > drivers/dma/sh/rcar-dmac.c | 82 ++++++++++++++++++++++++++++++++++++-----
> > > 1 file changed, 74 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
> > > index cf983a9..22a5e40 100644
> > > --- a/drivers/dma/sh/rcar-dmac.c
> > > +++ b/drivers/dma/sh/rcar-dmac.c
>
> [snip]
>
> > > +static int rcar_dmac_map_slave_addr(struct dma_chan *chan,
> > > + enum dma_transfer_direction dir)
> > > +{
> > > + struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
> > > + struct rcar_dmac_chan_map *map = &rchan->map;
> > > + phys_addr_t dev_addr;
> > > + size_t dev_size;
> > > + enum dma_data_direction dev_dir;
> > > +
> > > + if (dir == DMA_DEV_TO_MEM) {
> > > + dev_addr = rchan->src.slave_addr;
> > > + dev_size = rchan->src.xfer_size;
> > > + dev_dir = DMA_TO_DEVICE;
> >
> > Shouldn't this be DMA_FROM_DEVICE, and DMA_TO_DEVICE below ?
>
> This comment can be ignored (thank you Robin for the explanation), but ...
>
> > > + } else {
> > > + dev_addr = rchan->dst.slave_addr;
> > > + dev_size = rchan->dst.xfer_size;
> > > + dev_dir = DMA_FROM_DEVICE;
> > > + }
> > > +
> > > + /* Reuse current map if possible. */
> > > + if (dev_addr == map->slave.slave_addr &&
> > > + dev_size == map->slave.xfer_size &&
> > > + dev_dir == map->dir)
> > > + return 0;
> > > +
> > > + /* Remove old mapping if present. */
> > > + if (map->slave.xfer_size)
> > > + dma_unmap_resource(chan->device->dev, map->addr,
> > > + map->slave.xfer_size, map->dir, 0);
> >
> > Unless I'm mistaken the resource will not be unmapped when freeing channel
> > resources, will it ?
>
> I believe this one still needs to be addressed.
I believe you are correct, I will look in to it and hopefully submit a
patch to address it. Thanks for brining it up.
>
> > > + map->slave.xfer_size = 0;
> > > +
> > > + /* Create new slave address map. */
> > > + map->addr = dma_map_resource(chan->device->dev, dev_addr, dev_size,
> > > + dev_dir, 0);
> > > +
> > > + if (dma_mapping_error(chan->device->dev, map->addr)) {
> > > + dev_err(chan->device->dev,
> > > + "chan%u: failed to map %zx@%pap", rchan->index,
> > > + dev_size, &dev_addr);
> > > + return -EIO;
> > > + }
> > > +
> > > + dev_dbg(chan->device->dev, "chan%u: map %zx@%pap to %pad dir: %s\n",
> > > + rchan->index, dev_size, &dev_addr, &map->addr,
> >
> > > + dev_dir == DMA_TO_DEVICE ? "DMA_TO_DEVICE" :
> > "DMA_FROM_DEVICE");
> >
> > > +
> > > + map->slave.slave_addr = dev_addr;
> > > + map->slave.xfer_size = dev_size;
> > > + map->dir = dev_dir;
> > > +
> > > + return 0;
> > > +}
>
> [snip]
>
> --
> Regards,
>
> Laurent Pinchart
>
--
Regards,
Niklas S?derlund
^ permalink raw reply
* [PATCH 2/2] usb: host: ohci-exynos: Decrese node refcount on exynos_ehci_get_phy() error paths
From: Javier Martinez Canillas @ 2017-01-09 15:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170107084141.3731-2-krzk@kernel.org>
Hello Krzysztof,
On 01/07/2017 05:41 AM, Krzysztof Kozlowski wrote:
> Returning from for_each_available_child_of_node() loop requires cleaning
> up node refcount. Error paths lacked it so for example in case of
> deferred probe, the refcount of phy node was left increased.
>
> Fixes: 6d40500ac9b6 ("usb: ehci/ohci-exynos: Fix of_node_put() for child when getting PHYs")
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH 1/2] usb: host: ehci-exynos: Decrese node refcount on exynos_ehci_get_phy() error paths
From: Javier Martinez Canillas @ 2017-01-09 15:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170107084141.3731-1-krzk@kernel.org>
Hello Krzysztof,
On 01/07/2017 05:41 AM, Krzysztof Kozlowski wrote:
> Returning from for_each_available_child_of_node() loop requires cleaning
> up node refcount. Error paths lacked it so for example in case of
> deferred probe, the refcount of phy node was left increased.
>
> Fixes: 6d40500ac9b6 ("usb: ehci/ohci-exynos: Fix of_node_put() for child when getting PHYs")
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH V9 3/3] irqchip: qcom: Add IRQ combiner driver
From: Marc Zyngier @ 2017-01-09 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a1d3e5706ea8c97a4712a8fb33db71ca@codeaurora.org>
On 06/01/17 13:17, Agustin Vega-Frias wrote:
> Hey Marc,
>
> On 2017-01-05 11:48, Marc Zyngier wrote:
>> Hi Agustin,
>>
>> On 14/12/16 22:10, Agustin Vega-Frias wrote:
>>> Driver for interrupt combiners in the Top-level Control and Status
>>> Registers (TCSR) hardware block in Qualcomm Technologies chips.
>>>
>>> An interrupt combiner in this block combines a set of interrupts by
>>> OR'ing the individual interrupt signals into a summary interrupt
>>> signal routed to a parent interrupt controller, and provides read-
>>> only, 32-bit registers to query the status of individual interrupts.
>>> The status bit for IRQ n is bit (n % 32) within register (n / 32)
>>> of the given combiner. Thus, each combiner can be described as a set
>>> of register offsets and the number of IRQs managed.
>>>
>>> Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
>>> ---
>>> drivers/irqchip/Kconfig | 9 +
>>> drivers/irqchip/Makefile | 1 +
>>> drivers/irqchip/qcom-irq-combiner.c | 322
>>> ++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 332 insertions(+)
>>> create mode 100644 drivers/irqchip/qcom-irq-combiner.c
>>>
>>> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
>>> index bc0af33..3e3430c 100644
>>> --- a/drivers/irqchip/Kconfig
>>> +++ b/drivers/irqchip/Kconfig
>>> @@ -279,3 +279,12 @@ config EZNPS_GIC
>>> config STM32_EXTI
>>> bool
>>> select IRQ_DOMAIN
>>> +
>>> +config QCOM_IRQ_COMBINER
>>> + bool "QCOM IRQ combiner support"
>>> + depends on ARCH_QCOM && ACPI
>>> + select IRQ_DOMAIN
>>> + select IRQ_DOMAIN_HIERARCHY
>>> + help
>>> + Say yes here to add support for the IRQ combiner devices embedded
>>> + in Qualcomm Technologies chips.
>>> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
>>> index e4dbfc8..1818a0b 100644
>>> --- a/drivers/irqchip/Makefile
>>> +++ b/drivers/irqchip/Makefile
>>> @@ -74,3 +74,4 @@ obj-$(CONFIG_LS_SCFG_MSI) += irq-ls-scfg-msi.o
>>> obj-$(CONFIG_EZNPS_GIC) += irq-eznps.o
>>> obj-$(CONFIG_ARCH_ASPEED) += irq-aspeed-vic.o
>>> obj-$(CONFIG_STM32_EXTI) += irq-stm32-exti.o
>>> +obj-$(CONFIG_QCOM_IRQ_COMBINER) += qcom-irq-combiner.o
>>> diff --git a/drivers/irqchip/qcom-irq-combiner.c
>>> b/drivers/irqchip/qcom-irq-combiner.c
>>> new file mode 100644
>>> index 0000000..0055e08
>>> --- /dev/null
>>> +++ b/drivers/irqchip/qcom-irq-combiner.c
>>> @@ -0,0 +1,322 @@
>>> +/* Copyright (c) 2015-2016, The Linux Foundation. All rights
>>> reserved.
>>> + *
>>> + * This program is free software; you can redistribute it and/or
>>> modify
>>> + * it under the terms of the GNU General Public License version 2 and
>>> + * only version 2 as published by the Free Software Foundation.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + */
>>> +
>>> +/*
>>> + * Driver for interrupt combiners in the Top-level Control and Status
>>> + * Registers (TCSR) hardware block in Qualcomm Technologies chips.
>>> + * An interrupt combiner in this block combines a set of interrupts
>>> by
>>> + * OR'ing the individual interrupt signals into a summary interrupt
>>> + * signal routed to a parent interrupt controller, and provides read-
>>> + * only, 32-bit registers to query the status of individual
>>> interrupts.
>>> + * The status bit for IRQ n is bit (n % 32) within register (n / 32)
>>> + * of the given combiner. Thus, each combiner can be described as a
>>> set
>>> + * of register offsets and the number of IRQs managed.
>>> + */
>>> +
>>> +#include <linux/acpi.h>
>>> +#include <linux/irqchip/chained_irq.h>
>>> +#include <linux/irqdomain.h>
>>> +#include <linux/platform_device.h>
>>> +
>>> +#define REG_SIZE 32
>>> +
>>> +struct combiner_reg {
>>> + void __iomem *addr;
>>> + unsigned long mask;
>>> +};
>>> +
>>> +struct combiner {
>>> + struct irq_domain *domain;
>>> + int parent_irq;
>>> + u32 nirqs;
>>> + u32 nregs;
>>> + struct combiner_reg regs[0];
>>> +};
>>> +
>>> +static inline u32 irq_register(int irq)
>>> +{
>>> + return irq / REG_SIZE;
>>> +}
>>> +
>>> +static inline u32 irq_bit(int irq)
>>> +{
>>> + return irq % REG_SIZE;
>>> +
>>> +}
>>> +
>>> +static inline int irq_nr(u32 reg, u32 bit)
>>> +{
>>> + return reg * REG_SIZE + bit;
>>> +}
>>> +
>>> +/*
>>> + * Handler for the cascaded IRQ.
>>> + */
>>> +static void combiner_handle_irq(struct irq_desc *desc)
>>> +{
>>> + struct combiner *combiner = irq_desc_get_handler_data(desc);
>>> + struct irq_chip *chip = irq_desc_get_chip(desc);
>>> + u32 reg;
>>> +
>>> + chained_irq_enter(chip, desc);
>>> +
>>> + for (reg = 0; reg < combiner->nregs; reg++) {
>>> + int virq;
>>> + int hwirq;
>>> + u32 bit;
>>> + u32 status;
>>> +
>>> + if (combiner->regs[reg].mask == 0)
>>> + continue;
>>
>> I'm a bit worried by this. If I understand it well, this is a pure
>> software construct (controlled from combiner_irq_chip_{un,}mask_irq)
>> and
>> there is nothing that actually masks the interrupt at the HW level.
>>
>> So if a device asserts its interrupt line, what mechanism do we have to
>> make sure that we don't end-up with the CPU pegged in interrupt
>> context?
>>
>
> Yes, unfortunately this is a dumb hardware combiner; however, the
> real use of mask here is to optimize IRQ handling if the combiner
> instance has its IRQ statuses across more than one register.
> Currently all active instances only use one register, but we are
> getting close to 32 in one case, so I wanted to accommodate a general
> case where an instance can combine more than 32 IRQs.
>
> Having said that, what I'm inclined to do is to remove the use of mask
> on the status read form the register on the next two lines, and then let
> irq_find_mapping fail if we are getting an unexpected IRQ, then call
> handle_bad_irq(desc).
Unfortunately, having a mapping in place is not an indication that
someone can handle the interrupt. Also, you still need to handle
mask/unmask, and I don't see how you manage that, given that this
interrupt combiner seems to be a glorified OR gate.
> Do you have any other suggestions to handle the scenario? E.g., can we
> safely disable the parent IRQ from this context if we see too many
> spurious interrupts?
I don't think so. There is two issues here:
- If a device is stuck with an active interrupt, you won't be able to
reliably detect that this is an invalid condition (the mapping trick
above is not reliable, and generic_handle_irq doesn't return anything
useful)
- Even if you could detect it, what do you do? Killing the cascade
interrupt would also kill all the other devices. Is that something
acceptable in your setup? Can you implement mask/unmask the same way?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* Unhandled level 2 translation fault (11) at 0x000000b8, esr 0x92000046, rpi3 (aarch64)
From: Catalin Marinas @ 2017-01-09 15:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGDbNAAGqFqt7X+=XYRLAp=L_fTv9dAAe=wu4T_W-FCGqnYHHg@mail.gmail.com>
On Fri, Dec 30, 2016 at 01:21:00PM +0100, Bas van Tiel wrote:
> >> when using a signal handler as a way to context switch between
> >> different usercontexts a reproducible exception occurs on my rpi3 in
> >> 64-bit mode. (https://gist.github.com/DanGe42/7148946)
> >>
> >> Running the context_demo program as a 32-bit ARM executable on a
> >> 64-bit kernel is OK, running as a 32 || 64 bit executable on an x86
> >> kernel is OK.
> >>
> >> In the first exception the PC doesn?t look correct, and the *pmd is 0.
> >> The 2nd exception happens after running the program again, the PC is 0x0.
> >>
> >> A successful function trace was not possible -> complete kernel hangup
> >> when enabling.
> >>
> >> Is there another way to gather more information about what is happening?
> >
> > I can reproduce Segmentation fault with your program on Marvell berlin SoCs
> > my kernel version is 4.1, I didn't tested 4.9, 4.10-rc1 etc..
> >
> > Then I increased the STACKSIZE from 4096 to 8192 in context_demo.c,
> > everything works fine now. Maybe arm64 need a bit larger signalstack?
>
> yes, increased STACKSIZE to 8192 helps on 4.9/4,10-rc1 but after a
> while the exception still occurs, although the message is different.
> The *pmd is not 0 in this case.
I defined STACKSIZE to the kernel's SIGSTKSZ (16384) and it seems to run
fine, though I'll leave it longer/overnight (on a Juno board). With the
4K signal stack it was crashing shortly after start.
--
Catalin
^ permalink raw reply
* [PATCH v2 2/4] dmaengine: Forward slave device pointer to of_xlate callback
From: kbuild test robot @ 2017-01-09 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483970598-6191-3-git-send-email-m.szyprowski@samsung.com>
Hi Marek,
[auto build test ERROR on next-20170106]
[also build test ERROR on v4.10-rc3]
[cannot apply to linus/master linux/master xlnx/master v4.9-rc8 v4.9-rc7 v4.9-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Marek-Szyprowski/dmaengine-pl330-remove-pdata-based-initialization/20170109-224452
config: i386-randconfig-x001-201702 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/dma/dw/platform.c: In function 'dw_dma_of_xlate':
>> drivers/dma/dw/platform.c:35:22: error: 'slave' redeclared as different kind of symbol
struct dw_dma_slave slave = {
^~~~~
drivers/dma/dw/platform.c:32:47: note: previous definition of 'slave' was here
struct of_dma *ofdma, struct device *slave)
^~~~~
vim +/slave +35 drivers/dma/dw/platform.c
a104a45ba7 Andy Shevchenko 2015-03-09 29 #define DRV_NAME "dw_dmac"
a104a45ba7 Andy Shevchenko 2015-03-09 30
9cade1a46c Andy Shevchenko 2013-06-05 31 static struct dma_chan *dw_dma_of_xlate(struct of_phandle_args *dma_spec,
7b7c0c79d7 Marek Szyprowski 2017-01-09 32 struct of_dma *ofdma, struct device *slave)
9cade1a46c Andy Shevchenko 2013-06-05 33 {
9cade1a46c Andy Shevchenko 2013-06-05 34 struct dw_dma *dw = ofdma->of_dma_data;
4d130de20c Andy Shevchenko 2014-08-19 @35 struct dw_dma_slave slave = {
4d130de20c Andy Shevchenko 2014-08-19 36 .dma_dev = dw->dma.dev,
9cade1a46c Andy Shevchenko 2013-06-05 37 };
9cade1a46c Andy Shevchenko 2013-06-05 38 dma_cap_mask_t cap;
:::::: The code at line 35 was first introduced by commit
:::::: 4d130de20c3f39fc1a1aecd3969b50d49ff2e358 dmaengine: dw: introduce generic filter function
:::::: TO: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
:::::: CC: Vinod Koul <vinod.koul@intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 28695 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170109/ddcca592/attachment-0001.gz>
^ permalink raw reply
* mmc: sdhci-of-at91: Internal clock never stabilised
From: Alex Gershgorin @ 2017-01-09 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109135855.dquiysi5wnilujgp@rfolt0960.corp.atmel.com>
Thanks for your help, I will replace the chip with Rev B so I can
indeed start working on my board normally J
Regards,
Alex
On Mon, Jan 9, 2017 at 3:58 PM, Ludovic Desroches
<ludovic.desroches@atmel.com> wrote:
> On Mon, Jan 09, 2017 at 12:44:42PM +0200, Alex Gershgorin wrote:
>> Hi Ludovic,
>> As we read the chip ID from CHIPID_CIDR register we get 0x8a5c08c0 (we
>> use ATSAMA5D27A-CU).
>>
>
> It seems the device you have is a rev A device, this issue should be fixed in
> the revision B.
>
> I say should, because the bug was identified and I provided a workaround with
> the use of our own set_clock function has been done. Unfortunately, even
> if it happens less frequently, it seems the bug is still here.
>
> The hardware part has been reworked on the revision B. I don't recall facing
> this issue again but I can't guarantee that it won't happen anymore
> since the root cause was not properly identified on rev A.
>
> Regards
>
> Ludovic
>
>>
>> Thanks,
>> Alex
>>
>> On Mon, Jan 9, 2017 at 9:19 AM, Ludovic Desroches
>> <ludovic.desroches@atmel.com> wrote:
>> > Hi Alex,
>> >
>> > Which revision of SoC are you using?
>> >
>> > Regards
>> >
>> > Ludovic
>> >
>> > On Sun, Jan 08, 2017 at 01:53:44PM +0100, Alexandre Belloni wrote:
>> >> Hi,
>> >>
>> >> I think Cyrille worked on that a few month ago, maybe he has a comment.
>> >>
>> >> On 08/01/2017 at 14:07:53 +0200, Alex Gershgorin wrote :
>> >> > Hi All,
>> >> > We have two different HW platforms based on SAMA5D2 SoC (SAMA5D2 Xplained
>> >> > Board and our own HW).
>> >> > On both of them we are facing stabilization of the internal
>> >> > clock problem, it does not happen all the time but quite often.
>> >> > Please see below my Kernel boot messages:
>> >> >
>> >> > sdhci: Copyright(c) Pierre Ossman
>> >> > sdhci-pltfm: SDHCI platform and OF driver helper
>> >> > sdhci-at91 a0000000.sdio-host: update clk mul to 39 as gck rate is
>> >> > 480000000 Hz
>> >> > mmc0: Internal clock never stabilised.
>> >> > mmc0: Internal clock never stabilised.
>> >> > mmc0: SDHCI controller on a0000000.sdio-host [a0000000.sdio-host] using ADMA
>> >> >
>> >> > snip
>> >> >
>> >> > snip
>> >> >
>> >> > Waiting for root device /dev/mmcblk0p2...
>> >> > mmc0: Internal clock never stabilised.
>> >> > mmc0: Timeout waiting for hardware cmd interrupt.
>> >> > sdhci: =========== REGISTER DUMP (mmc0)===========
>> >> > sdhci: Sys addr: 0x00000000 | Version: 0x00001502
>> >> > sdhci: Blk size: 0x00000000 | Blk cnt: 0x00000000
>> >> > sdhci: Argument: 0x00000000 | Trn mode: 0x00000000
>> >> > sdhci: Present: 0x01ff0001 | Host ctl: 0x00000001
>> >> > sdhci: Power: 0x0000000f | Blk gap: 0x00000000
>> >> > sdhci: Wake-up: 0x00000000 | Clock: 0x0000ffe1
>> >> > sdhci: Timeout: 0x00000000 | Int stat: 0x00000000
>> >> > sdhci: Int enab: 0x00ff0003 | Sig enab: 0x00ff0003
>> >> > sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
>> >> > sdhci: Caps: 0x27ec0c8c | Caps_1: 0x00270f77
>> >> > sdhci: Cmd: 0x00000000 | Max curr: 0x00000000
>> >> > sdhci: Host ctl2: 0x00000000
>> >> > sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x00000000
>> >> > sdhci: ===========================================
>> >> >
>> >> > Any direction to solve this problem?
>> >> >
>> >> > Thanks,
>> >> > Alex Gershgorin
>> >>
>> >> --
>> >> Alexandre Belloni, Free Electrons
>> >> Embedded Linux and Kernel engineering
>> >> http://free-electrons.com
>> >>
>> >> _______________________________________________
>> >> linux-arm-kernel mailing list
>> >> linux-arm-kernel at lists.infradead.org
>> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFC 00/55] Nested Virtualization on KVM/ARM
From: David Hildenbrand @ 2017-01-09 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483943091-1364-1-git-send-email-jintack@cs.columbia.edu>
> Even though this work is not complete (see limitations below), I'd appreciate
> early feedback on this RFC. Specifically, I'm interested in:
> - Is it better to have a kernel config or to make it configurable at runtime?
x86 and s390x have a kernel module parameter (nested) that can only be
changed when loading the module and should default to false. So the
admin explicitly has to enable it. Maybe going the same path makes
sense.
--
David
^ permalink raw reply
* [PATCH 1/2] ARM: hyp-stub: improve ABI
From: Christoffer Dall @ 2017-01-09 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109140500.GA14217@n2100.armlinux.org.uk>
On Mon, Jan 09, 2017 at 02:05:00PM +0000, Russell King - ARM Linux wrote:
> On Mon, Jan 09, 2017 at 02:26:36PM +0100, Christoffer Dall wrote:
> > On Mon, Jan 09, 2017 at 12:26:39PM +0000, Russell King - ARM Linux wrote:
> > > On Tue, Jan 03, 2017 at 10:51:49AM +0100, Christoffer Dall wrote:
> > > > Hi Russell,
> > > >
> > > > On Thu, Dec 15, 2016 at 06:57:18PM +0000, Russell King - ARM Linux wrote:
> > > > > What's also coming clear is that there's very few people who understand
> > > > > all the interactions here, and the whole thing seems to be an undocumented
> > > > > mess.
> > > >
> > > > I think the hyp stub has just served a very limited purpose so far, and
> > > > therefore is a somewhat immature implementation. Now we've discovered a
> > > > need to clean it up, and we're all for that. Again, I don't think the
> > > > problem is any larger than that, we just need to fix it, and it seems to
> > > > me everyone is willing to work on that.
> > >
> > > What I want to see is some documentation of the hyp-stub, so that there
> > > can be some element of confidence that changes there are properly
> > > coordinated. As I said in a follow up email:
> > >
> > > | Either we need more people to have an understanding (so if one of them
> > > | gets run over by a bus, we're not left floundering around) or we need
> > > | it to be documented - even if it's just a simple comment "the ABI in
> > > | this file is shared with XYZ, if you change the ABI here, also update
> > > | XYZ too."
> > >
> > > > Marc even offered to work on your suggestion to support the general
> > > > hyp ABI commands in KVM.
> > >
> > > ... which is pointless, because it's a duplication of the effort I've
> > > already put in. My patches already do the:
> > >
> > > #define HVC_GET_VECTORS 0
> > > #define HVC_SET_VECTORS 1
> > > #define HVC_SOFT_RESTART 2
> > >
> > > thing which ARM64 does, passing the arguments in via the appropriate
> > > registers. However, such a change is a major revision of hyp-stub's
> > > ABI, which completely changes the way it works.
> >
> > Sorry, I'm afraid I might have been unclear. What I meant with "general
> > hyp ABI commands in KVM" was, that if there's a need for KVM to support
> > the operations (using a unified and documented ABI) that the hyp stub
> > supports, then we could add that in KVM as well. I thought your patches
> > added the functionality for the hyp stub, and Marc would add whichever
> > remaining pieces in the KVM side.
>
> The view over Christmas was "we only need to ensure the GET_VECTORS call
> continues to work", which is what Marc's patch does. I've come to
> realise (through no help of the documentation situation) that that is
> far from the full story, because of the way kdump works.
>
> Let me refresh...
>
> In normal kexec(), kernel_restart_prepare() is called, which calls the
> reboot_notifier_list. KVM uses this via kvm_reboot() and
> kvm_arch_hardware_disable() to call cpu_hyp_reset(), and in turn
> __kvm_hyp_reset in HYP mode. That sets the stub vectors back to the
> hyp-stub implementation. So, normal kexec should work fine.
>
> However, kernel_restart_prepare() is _not_ called in the kdump case.
Thanks for this, it was slightly unclear to me in which way kdump
different from the other cases, but makes sense now.
> So, with my two patches in place, we will issue a HVC call with the
> arguments that I've given to whatever hypervisor is in place at the
> time, and as I've pointed out, with the KVM hypervisor, we will try to
> branch to address 2 or 3 - who knows what effect that'll have.
>
> So, although Marc produced a patch which updates the KVM hypervisor for
> the GET_VECTORS change, through reading the code today, it's become clear
> that much more is needed, so I'm yet again banging on about documentation.
> It's only become clear to me today that the KVM stub calling convention
> for the host kernel is:
Just for clarity: I understood that Marc said he was willing to write
the code to support the common ABI that we agree on in KVM. The fact
that he sent another small patch was a separate contribution, but that's
how I understood. it.
>
> entry:
> r0 = function pointer
> r1 = 32-bit function argument 0
> r2 = 32-bit function argument 1
> r3 = 32-bit function argument 2
> no further arguments are supported
> --- or ---
> r0 = -1 (or 0 post Marc's patch) for get_vectors
> exit:
> r0 = vectors (if get_vectors call was made)
> otherwise, who knows...
>
> I specify "32-bit" there because they're shifted by one register, which,
> if a 64-bit argument is passed with EABI, the arguments will no longer be
> appropriately aligned... so it's an important detail to be aware of with
> the current KVM hypervisor interface.
>
> What I want to do here is to fix this kexec issue completely, not in a
> piecemeal fashion - I'm not interested in fixing one small problem, then
> coming back to it in a few months time to fix another problem. That's a
> waste of time (well, unless you're into job creation.) I've always been
> for "if you're going to do the job, damn well do the job properly". So
> I'm not going to accept anything short of fixing _both_ kexec and kdump
> together.
>
> So, given that the hyp-stub has this ABI after my patches:
>
> entry:
> r0 = argument (0 = get vectors, 1 = set vectors, 2 = call function)
> r1 = vectors for r0 = 1
> r3 = function pointer (with bit 0 already set for thumb functions)
> for r0 = 2
> exit:
> r0 = -1 for invalid calls
> r0 = current vectors address (for r0 = 0 on entry)
> is not expected to return for r0 = 2 on entry
> otherwise registers preserved preserved
>
> which is clearly incompatible with the current KVM stub, can we come up
> with a common ABI that is satisfactory to both.
>
> The above are probably the very first time anyone has written out the
> ABI of these things, and as can be seen, it's still something of a mess.
>
> > > Longer term, I'd like to see the existing hypervisor documentation in
> > > Documentation/virtual/kvm/hypercalls.txt updated with the ARM details.
> > > According to that document, KVM effectively only exists on PPC and x86
> > > at the present time...
> > >
> >
> > I'm afraid I don't think this is right place to document this behavior.
> >
> > There's a difference between an internal ABI between code running in two
> > CPU modes but both part of the same kernel, and a hypervisor running
> > a guest OS on top.
> >
> > I believe that Documentation/virtual/kvm/hypercalls.txt documents the
> > latter case (i.e. guest hypercalls supported by the KVM host
> > hypervisor), not the former case, and these things should not be
> > combined.
> >
> > I would suggest adding something like
> > Documentation/virtual/kvm/arm/hyp-abi.txt instead.
>
> I'm fine with that - I just want there to be some documentation so we can
> stop poking around in the dark, with people stating random different and
> incorrect opinions about the code when problems like broken kexec/kdump
> come up.
>
> The only way to make me shut up about the documentation thing is to do
> something about it...
>
Nobody is arguing with the need for documentation, and I think I
understan the reason for needing to support a common ABI with a common
set of functions regardless of the logic in place in Hyp mode.
We just have to agree on a sane ABI and I'll be happy to help
write/review the API docs and clean things up.
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH 1/2] ARM: hyp-stub: improve ABI
From: Christoffer Dall @ 2017-01-09 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109144235.GC14217@n2100.armlinux.org.uk>
On Mon, Jan 09, 2017 at 02:42:35PM +0000, Russell King - ARM Linux wrote:
> On Mon, Jan 09, 2017 at 02:05:00PM +0000, Russell King - ARM Linux wrote:
> > So, although Marc produced a patch which updates the KVM hypervisor for
> > the GET_VECTORS change, through reading the code today, it's become clear
> > that much more is needed, so I'm yet again banging on about documentation.
> > It's only become clear to me today that the KVM stub calling convention
> > for the host kernel is:
> >
> > entry:
> > r0 = function pointer
> > r1 = 32-bit function argument 0
> > r2 = 32-bit function argument 1
> > r3 = 32-bit function argument 2
> > no further arguments are supported
> > --- or ---
> > r0 = -1 (or 0 post Marc's patch) for get_vectors
> > exit:
> > r0 = vectors (if get_vectors call was made)
> > otherwise, who knows...
>
> Hang on, even this is nowhere near the full picture.
>
> static inline void __cpu_init_hyp_mode(phys_addr_t pgd_ptr,
> unsigned long hyp_stack_ptr,
> unsigned long vector_ptr)
> {
> /*
> * Call initialization code, and switch to the full blown HYP
> * code. The init code doesn't need to preserve these
> * registers as r0-r3 are already callee saved according to
> * the AAPCS.
> * Note that we slightly misuse the prototype by casting the
> * stack pointer to a void *.
>
> * The PGDs are always passed as the third argument, in order
> * to be passed into r2-r3 to the init code (yes, this is
> * compliant with the PCS!).
> */
>
> kvm_call_hyp((void*)hyp_stack_ptr, vector_ptr, pgd_ptr);
> }
>
> This results in a completely different calling convention -
>
> r0 = hyp_stack_ptr
> r1 = vector_ptr
> r2,r3 = pgd_ptr
>
> Which clearly doesn't fit the KVM hypervisor's calling requirements...
> and, looking deeper at this:
>
> /* Switch from the HYP stub to our own HYP init vector */
> __hyp_set_vectors(kvm_get_idmap_vector());
>
> pgd_ptr = kvm_mmu_get_httbr();
> stack_page = __this_cpu_read(kvm_arm_hyp_stack_page);
> hyp_stack_ptr = stack_page + PAGE_SIZE;
> vector_ptr = (unsigned long)kvm_ksym_ref(__kvm_hyp_vector);
>
> __cpu_init_hyp_mode(pgd_ptr, hyp_stack_ptr, vector_ptr);
>
> So we actually have _another_ hypervisor stub to care about - should
> anything go wrong between __hyp_set_vectors() and __cpu_init_hyp_mode(),
> we will be hitting the __do_hyp_init assembly code with maybe a get
> vectors or soft reboot call, which, reading the code, would be bad
> news.
>
> Since this code is run at several different times - CPU hotplug (when
> the system will be quiescent) and also cpuidle PM (when the system is
> not quiescent). With kdump/kexec, I think this could be racy.
> Certainly if anything were to go wrong between the two with a kdump
> kernel in place, we'd be making HVC calls to the KVM init stub and
> expecting them to work.
>
Indeed it looks like interrupts are enabled during cpu_init_hyp_mode,
and if it's possible to be preempted there or if kdump can be initiated
from interrupt context, this could go wrong, so you're probably right
that we need to support a common hyp-ABI for the kernel hyp stub, the
KVM stub (a.k.a. the trampoline code), and KVM's hyp layer itself.
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH] arm64: head.S: fix up stale comments
From: Mark Rutland @ 2017-01-09 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_t7n8PUAeAYe2kkFpPciC0eJ+Qg7sHu_tTfux=3LwyTg@mail.gmail.com>
On Mon, Jan 09, 2017 at 02:55:51PM +0000, Ard Biesheuvel wrote:
> On 9 January 2017 at 14:31, Mark Rutland <mark.rutland@arm.com> wrote:
> > In commit 23c8a500c24d02dd ("arm64: kernel: use ordinary return/argument
> > register for el2_setup()"), we stopped using w20 as a global stash of
> > the boot mode flag, and instead pass this around in w0 as a function
> > parameter.
> >
> > Unfortunately, we missed a couple of comments, which still refer to the
> > old convention of using w20/x20.
> >
> > This patch fixes up the comments to describe the code as it currently
> > works.
> >
>
> Ah yes, apologies for the sloppiness
No worries; I missed this in review, too...
> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cheers!
Mark.
> > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > ---
> > arch/arm64/kernel/head.S | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> > index 4b1abac..9b0857a 100644
> > --- a/arch/arm64/kernel/head.S
> > +++ b/arch/arm64/kernel/head.S
> > @@ -483,7 +483,7 @@ ENTRY(kimage_vaddr)
> > * If we're fortunate enough to boot at EL2, ensure that the world is
> > * sane before dropping to EL1.
> > *
> > - * Returns either BOOT_CPU_MODE_EL1 or BOOT_CPU_MODE_EL2 in x20 if
> > + * Returns either BOOT_CPU_MODE_EL1 or BOOT_CPU_MODE_EL2 in w0 if
> > * booted in EL1 or EL2 respectively.
> > */
> > ENTRY(el2_setup)
> > @@ -628,7 +628,7 @@ ENDPROC(el2_setup)
> >
> > /*
> > * Sets the __boot_cpu_mode flag depending on the CPU boot mode passed
> > - * in x20. See arch/arm64/include/asm/virt.h for more info.
> > + * in w0. See arch/arm64/include/asm/virt.h for more info.
> > */
> > set_cpu_boot_mode_flag:
> > adr_l x1, __boot_cpu_mode
> > --
> > 1.9.1
> >
^ permalink raw reply
* [PATCH] arm64: head.S: fix up stale comments
From: Ard Biesheuvel @ 2017-01-09 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483972315-12782-1-git-send-email-mark.rutland@arm.com>
On 9 January 2017 at 14:31, Mark Rutland <mark.rutland@arm.com> wrote:
> In commit 23c8a500c24d02dd ("arm64: kernel: use ordinary return/argument
> register for el2_setup()"), we stopped using w20 as a global stash of
> the boot mode flag, and instead pass this around in w0 as a function
> parameter.
>
> Unfortunately, we missed a couple of comments, which still refer to the
> old convention of using w20/x20.
>
> This patch fixes up the comments to describe the code as it currently
> works.
>
Ah yes, apologies for the sloppiness
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/kernel/head.S | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index 4b1abac..9b0857a 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -483,7 +483,7 @@ ENTRY(kimage_vaddr)
> * If we're fortunate enough to boot at EL2, ensure that the world is
> * sane before dropping to EL1.
> *
> - * Returns either BOOT_CPU_MODE_EL1 or BOOT_CPU_MODE_EL2 in x20 if
> + * Returns either BOOT_CPU_MODE_EL1 or BOOT_CPU_MODE_EL2 in w0 if
> * booted in EL1 or EL2 respectively.
> */
> ENTRY(el2_setup)
> @@ -628,7 +628,7 @@ ENDPROC(el2_setup)
>
> /*
> * Sets the __boot_cpu_mode flag depending on the CPU boot mode passed
> - * in x20. See arch/arm64/include/asm/virt.h for more info.
> + * in w0. See arch/arm64/include/asm/virt.h for more info.
> */
> set_cpu_boot_mode_flag:
> adr_l x1, __boot_cpu_mode
> --
> 1.9.1
>
^ permalink raw reply
* [RFC PATCH] vring: Force use of DMA API for ARM-based systems
From: Will Deacon @ 2017-01-09 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fbf1a09a-bdb2-504a-f4a7-56fa54b6292b@arm.com>
On Mon, Jan 09, 2017 at 11:24:04AM +0000, Robin Murphy wrote:
> On 06/01/17 21:51, Andy Lutomirski wrote:
> > On Fri, Jan 6, 2017 at 10:32 AM, Robin Murphy <robin.murphy@arm.com> wrote:
> >> On 06/01/17 17:48, Jean-Philippe Brucker wrote:
> >>> It used to work with 4.9, but since 9491ae4 ("mm: don't cap request size
> >>> based on read-ahead setting") unlocked read-ahead, we quickly run into
> >>> the limit of swiotlb and panic:
> >>>
> >>> [ 5.382359] virtio-mmio 1c130000.virtio_block: swiotlb buffer is full
> >>> (sz: 491520 bytes)
> >>> [ 5.382452] virtio-mmio 1c130000.virtio_block: DMA: Out of SW-IOMMU
> >>> space for 491520 bytes
> >>> [ 5.382531] Kernel panic - not syncing: DMA: Random memory could be
> >>> DMA written
> >>> ...
> >>> [ 5.383148] [<ffff0000083ad754>] swiotlb_map_page+0x194/0x1a0
> >>> [ 5.383226] [<ffff000008096bb8>] __swiotlb_map_page+0x20/0x88
> >>> [ 5.383320] [<ffff0000084bf738>] vring_map_one_sg.isra.1+0x70/0x88
> >>> [ 5.383417] [<ffff0000084c04fc>] virtqueue_add_sgs+0x2ec/0x4e8
> >>> [ 5.383505] [<ffff00000856d99c>] __virtblk_add_req+0x9c/0x1a8
> >>> ...
> >>> [ 5.384449] [<ffff0000081829c4>] ondemand_readahead+0xfc/0x2b8
> >>>
> >>> Commit 9491ae4 caps the read-ahead request to a limit set by the backing
> >>> device. For virtio-blk, it is infinite (as set by the call to
> >>> blk_queue_max_hw_sectors in virtblk_probe).
> >>>
> >>> I'm not sure how to fix this. Setting an arbitrary sector limit in the
> >>> virtio-blk driver seems unfair to other users. Maybe we should check if
> >>> the device is behind a hardware IOMMU before using the DMA API?
> >>
> >> Hmm, this looks more like the virtio_block device simply has the wrong
> >> DMA mask to begin with. For virtio-pci we set the streaming DMA mask to
> >> 64 bits - should a platform device not be similarly capable?
> >
> > If it's not, then turning off DMA API will cause random corruption.
> > ISTM one way or another the bug is in either the DMA ops or in the
> > driver initialization.
>
> OK, having looked a little deeper, I reckon virtio_mmio_probe() is
> indeed missing a dma_set_mask() call compared to its PCI friends. The
> only question then is where does virtio-mmio stand with respect to
> legacy/modern/44-bit/64-bit etc.?
Legacy virtio-mmio has a variable page granule (GuestPageSize), so the
44-bit limitation shouldn't apply. The legacy spec doesn't actually
initialise GuestPageSize in the example initialisation sequence, but
Linux does. Non-legacy uses absolute, 64-bit addresses regardless of
transport, so yes, it might be as simple as adding:
dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
to virtio_mmio_probe. Jean-Philippe -- does that fix things for you?
Will
^ 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