* [PATCH] drivers: clk: qoriq: Add ls2088a key to clk OF match table
From: Stephen Boyd @ 2016-12-09 0:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478595315-441-1-git-send-email-abhimanyu.saini@nxp.com>
On 11/08, Abhimanyu Saini wrote:
> Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
> Signed-off-by: Ashish Kumar <ashish.kumar@nxp.com>
> Signed-off-by: Abhimanyu Saini <abhimanyu.saini@nxp.com>
> ---
Is there a DT binding update for this?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 5/8] efi: Get the secure boot status [ver #5]
From: Lukas Wunner @ 2016-12-09 0:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <14655.1481218273@warthog.procyon.org.uk>
On Thu, Dec 08, 2016 at 05:31:13PM +0000, David Howells wrote:
> Lukas Wunner <lukas@wunner.de> wrote:
> > > +out_efi_err:
> > > + pr_efi_err(sys_table_arg, "Could not determine UEFI Secure Boot status.\n");
> > > + if (status == EFI_NOT_FOUND)
> > > + return efi_secureboot_mode_disabled;
> > > + return efi_secureboot_mode_unknown;
> > > +}
> >
> > In the out_efi_err path, the if-statement needs to come before the
> > pr_efi_err() call. Otherwise it would be a change of behaviour for
> > ARM to what we have now.
>
> As I understand it, if the BIOS is an EFI BIOS, these variables must exist -
> in which case I would argue that the pr_efi_err-statement should be before
> the if-statement.
The existing efi_get_secureboot() in arm-stub.c returns 0 in the
EFI_NOT_FOUND case and the "Could not determine ..." error is only
printed if the return value is < 0. So you're introducing a change
of behaviour.
If you feel the change is justified, fine, I won't argue against it
since I don't have a dog in this fight.
But obviously it's something that a reader of your patch will trip over,
so@least explain it in the commit message. It would also be good to
explain why you're moving the pr_efi_err() calls in the first place.
ISTR it has to do with the different interpretation of an error,
what I wrote in my previous e-mail: x86 defaults to considering secureboot
disabled on error, ARM to enabled. I'm not even sure that's correct,
I'd have to go re-read the whole thread, which again shows that there's
too little documentation in the commit message.
Thanks,
Lukas
^ permalink raw reply
* [PATCH 3/3] ASoC: simple-card-utils: enable clocks/clock-names/clock-ranges
From: Kuninori Morimoto @ 2016-12-09 0:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209002635.GD5423@codeaurora.org>
Hi Stephen
> > > I don't see any reason why we need this patch though. The binding
> > > works as is, so supporting different styles doesn't seem like a
> > > good idea to me. Let's just keep what we have? Even if a sub-node
> > > like cpu or codec gets more than one element in the clocks list
> > > property, we can make that work by passing a clock-name then
> > > based on some sort of other knowledge.
> >
> > OK, thanks. Let's skip this patch.
> > But I believe this idea/method itself is not wrong (?)
> >
> Right it's not wrong, just seems confusing to have two methods.
Thanks.
Very clear for me :)
^ permalink raw reply
* [PATCH] ARM64: defconfig: enable DRM_MESON as module
From: Kevin Hilman @ 2016-12-09 0:57 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
To be added when the DRM driver lands upstream.
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 0f9d8900d685..2ce367dffb05 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -301,6 +301,7 @@ CONFIG_DRM_TEGRA=m
CONFIG_DRM_PANEL_SIMPLE=m
CONFIG_DRM_I2C_ADV7511=m
CONFIG_DRM_HISI_KIRIN=m
+CONFIG_DRM_MESON=m
CONFIG_FB=y
CONFIG_FB_ARMCLCD=y
CONFIG_BACKLIGHT_GENERIC=m
--
2.9.3
^ permalink raw reply related
* [PATCH v3 0/3] ARM: dts: imx6: Support Poslab Savageboard dual & quad
From: Milo Kim @ 2016-12-09 1:04 UTC (permalink / raw)
To: linux-arm-kernel
Poslab Savageboard is i.MX6 SoC base, but BSP code from the vendor is
not mainline u-boot and kernel. Personal reason of using this board is
testing etnaviv user-space driver, so I re-write device tree files based on
mainline kernel for the first step.
This patchset includes common DT file, dual and quad board files.
Supported components are
- Display: HDMI and LVDS panel
- eMMC and SD card
- Ethernet
- Pinmux configuration
- SATA: only for Savageboard quad
- UART1 for debug console
- USB host
Missing features are
- Audio (WM8903)
- USB OTG
- PMIC WM8326: default settings are used so no issue to bring-up the system
- MIPI DSI, CSI
Patches are tested on the Savageboard quad but the dual version should work
because the only difference between dual and quad is SATA support.
More information in http://www.savageboard.org
v3:
Specify the dtbs for i.MX6 build.
v2:
Fix DT node for regulator, phy-reset-gpios and iomuxc node.
Milo Kim (3):
ARM: dts: imx6: Add Savageboard common file
ARM: dts: imx6: Support Savageboard dual
ARM: dts: imx6: Support Savageboard quad
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/imx6dl-savageboard.dts | 50 ++++++
arch/arm/boot/dts/imx6q-savageboard.dts | 54 ++++++
arch/arm/boot/dts/imx6qdl-savageboard.dtsi | 262 +++++++++++++++++++++++++++++
4 files changed, 368 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-savageboard.dts
create mode 100644 arch/arm/boot/dts/imx6q-savageboard.dts
create mode 100644 arch/arm/boot/dts/imx6qdl-savageboard.dtsi
--
2.9.3
^ permalink raw reply
* [PATCH v3 1/3] ARM: dts: imx6: Add Savageboard common file
From: Milo Kim @ 2016-12-09 1:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209010436.7994-1-woogyom.kim@gmail.com>
* Memory
memblock for DDR3 1GB
* Regulator
3.3V for panel and backlight.
* Display
Enable HDMI and LVDS panel. Savageboard supports AVIC TM097TDH02 panel
which is compatible with Hannstar HSD100PXN1, so reuse it.
* Clock
The commit d28be499c45e6 is applied to support LVDS and HDMI output
simultaneously.
* Pinmux
eMMC, ethernet, HDMI, I2C, power button, PWM, SD card and UART.
* Others
Enable ethernet, UART1 debug, USB host, USDHC3 for microSD card and
USDHC4 for built-in eMMC storage.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/imx6qdl-savageboard.dtsi | 262 +++++++++++++++++++++++++++++
1 file changed, 262 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6qdl-savageboard.dtsi
diff --git a/arch/arm/boot/dts/imx6qdl-savageboard.dtsi b/arch/arm/boot/dts/imx6qdl-savageboard.dtsi
new file mode 100644
index 0000000..a7a7e1d
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-savageboard.dtsi
@@ -0,0 +1,262 @@
+/*
+ * Copyright (C) 2016 Milo Kim <woogyom.kim@gmail.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
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * 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 , 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 <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+/ {
+ chosen {
+ stdout-path = &uart1;
+ };
+
+ memory at 10000000 {
+ device_type = "memory";
+ reg = <0x10000000 0x40000000>;
+ };
+
+ backlight: panel_bl {
+ compatible = "pwm-backlight";
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <4>;
+ power-supply = <®_3p3v>;
+ pwms = <&pwm1 0 10000>;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_keys>;
+
+ power {
+ gpios = <&gpio3 7 GPIO_ACTIVE_LOW>;
+ label = "Power Button";
+ linux,code = <KEY_POWER>;
+ wakeup-source;
+ };
+ };
+
+ panel {
+ compatible = "avic, tm097tdh02", "hannstar,hsd100pxn1";
+ backlight = <&backlight>;
+ power-supply = <®_3p3v>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+};
+
+&clks {
+ assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
+ <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
+ assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
+ <&clks IMX6QDL_CLK_PLL3_USB_OTG>;
+};
+
+&fec {
+ phy-mode = "rgmii";
+ phy-reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet>;
+ status = "okay";
+};
+
+&hdmi {
+ ddc-i2c-bus = <&i2c2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hdmi_tx_cec>;
+ status = "okay";
+};
+
+&i2c2 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+};
+
+&ldb {
+ status = "okay";
+
+ lvds-channel at 0 {
+ reg = <0>;
+ status = "okay";
+
+ port at 4 {
+ reg = <4>;
+
+ lvds0_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+};
+
+&pwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm1>;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+&usbh1 {
+ status = "okay";
+};
+
+/* SD card */
+&usdhc3 {
+ bus-width = <4>;
+ cd-gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
+ no-1-8-v;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sd>;
+ status = "okay";
+};
+
+/* eMMC */
+&usdhc4 {
+ bus-width = <8>;
+ keep-power-in-suspend;
+ no-1-8-v;
+ non-removable;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_emmc>;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_emmc: emmcgrp {
+ fsl,pins = <
+ MX6QDL_PAD_SD4_CMD__SD4_CMD 0x17059
+ MX6QDL_PAD_SD4_CLK__SD4_CLK 0x10059
+ MX6QDL_PAD_SD4_DAT0__SD4_DATA0 0x17059
+ MX6QDL_PAD_SD4_DAT1__SD4_DATA1 0x17059
+ MX6QDL_PAD_SD4_DAT2__SD4_DATA2 0x17059
+ MX6QDL_PAD_SD4_DAT3__SD4_DATA3 0x17059
+ MX6QDL_PAD_SD4_DAT4__SD4_DATA4 0x17059
+ MX6QDL_PAD_SD4_DAT5__SD4_DATA5 0x17059
+ MX6QDL_PAD_SD4_DAT6__SD4_DATA6 0x17059
+ MX6QDL_PAD_SD4_DAT7__SD4_DATA7 0x17059
+ >;
+ };
+
+ pinctrl_enet: enetgrp {
+ fsl,pins = <
+ MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
+ MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
+ MX6QDL_PAD_RGMII_TXC__RGMII_TXC 0x1b030
+ MX6QDL_PAD_RGMII_TD0__RGMII_TD0 0x1b030
+ MX6QDL_PAD_RGMII_TD1__RGMII_TD1 0x1b030
+ MX6QDL_PAD_RGMII_TD2__RGMII_TD2 0x1b030
+ MX6QDL_PAD_RGMII_TD3__RGMII_TD3 0x1b030
+ MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x1b030
+ MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x1b0b0
+ MX6QDL_PAD_RGMII_RXC__RGMII_RXC 0x1b030
+ MX6QDL_PAD_RGMII_RD0__RGMII_RD0 0x1b030
+ MX6QDL_PAD_RGMII_RD1__RGMII_RD1 0x1b030
+ MX6QDL_PAD_RGMII_RD2__RGMII_RD2 0x1b030
+ MX6QDL_PAD_RGMII_RD3__RGMII_RD3 0x1b030
+ MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b030
+ /* PHY reset */
+ MX6QDL_PAD_ENET_CRS_DV__GPIO1_IO25 0x1b0b0
+ >;
+ };
+
+ pinctrl_hdmi_tx_cec: hdmitxcecgrp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_ROW2__HDMI_TX_CEC_LINE 0x1f8b0
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
+ MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_gpio_keys: gpiokeysgrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_DA7__GPIO3_IO07 0x1b0b1
+ >;
+ };
+
+ pinctrl_pwm1: pwm1grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_DAT3__PWM1_OUT 0x1b0b1
+ >;
+ };
+
+ pinctrl_sd: sdgrp {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059
+ MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10059
+ MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17059
+ MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059
+ MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059
+ MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059
+ /* CD pin */
+ MX6QDL_PAD_NANDF_D0__GPIO2_IO00 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT10__UART1_TX_DATA 0x1b0b1
+ MX6QDL_PAD_CSI0_DAT11__UART1_RX_DATA 0x1b0b1
+ >;
+ };
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v3 2/3] ARM: dts: imx6: Support Savageboard dual
From: Milo Kim @ 2016-12-09 1:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209010436.7994-1-woogyom.kim@gmail.com>
Common savageboard DT file is used for board support.
Specify this dtb file for i.MX6Q build.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6dl-savageboard.dts | 50 ++++++++++++++++++++++++++++++++
2 files changed, 51 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-savageboard.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index c558ba7..64660c7 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -348,6 +348,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-sabreauto.dtb \
imx6dl-sabrelite.dtb \
imx6dl-sabresd.dtb \
+ imx6dl-savageboard.dtb \
imx6dl-ts4900.dtb \
imx6dl-tx6dl-comtft.dtb \
imx6dl-tx6s-8034.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-savageboard.dts b/arch/arm/boot/dts/imx6dl-savageboard.dts
new file mode 100644
index 0000000..2cac30d
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-savageboard.dts
@@ -0,0 +1,50 @@
+/*
+ * Copyright (C) 2016 Milo Kim <woogyom.kim@gmail.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
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * 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 , 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 "imx6dl.dtsi"
+#include "imx6qdl-savageboard.dtsi"
+
+/ {
+ model = "Poslab SavageBoard Dual";
+ compatible = "poslab,imx6dl-savageboard", "fsl,imx6dl";
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v3 3/3] ARM: dts: imx6: Support Savageboard quad
From: Milo Kim @ 2016-12-09 1:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209010436.7994-1-woogyom.kim@gmail.com>
Use common board file and support SATA interface additionally.
Specify this dtb file for i.MX6 build.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6q-savageboard.dts | 54 +++++++++++++++++++++++++++++++++
2 files changed, 55 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-savageboard.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 64660c7..25b1e19 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -392,6 +392,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-sabreauto.dtb \
imx6q-sabrelite.dtb \
imx6q-sabresd.dtb \
+ imx6q-savageboard.dtb \
imx6q-sbc6x.dtb \
imx6q-tbs2910.dtb \
imx6q-ts4900.dtb \
diff --git a/arch/arm/boot/dts/imx6q-savageboard.dts b/arch/arm/boot/dts/imx6q-savageboard.dts
new file mode 100644
index 0000000..8d74002
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-savageboard.dts
@@ -0,0 +1,54 @@
+/*
+ * Copyright (C) 2016 Milo Kim <woogyom.kim@gmail.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
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * 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 , 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 "imx6q.dtsi"
+#include "imx6qdl-savageboard.dtsi"
+
+/ {
+ model = "Poslab SavageBoard Quad";
+ compatible = "poslab,imx6q-savageboard", "fsl,imx6q";
+};
+
+&sata {
+ status = "okay";
+};
--
2.9.3
^ permalink raw reply related
* [PATCH] ARM: dts: sun8i: Support DTB build for NanoPi M1
From: Milo Kim @ 2016-12-09 1:47 UTC (permalink / raw)
To: linux-arm-kernel
The commit 10efbf5f1633 introduced NanoPi M1 board but it's missing in
Allwinner H3 DTB build.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index cccdbcb..4cbdf6f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -845,6 +845,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-a83t-allwinner-h8homlet-v2.dtb \
sun8i-a83t-cubietruck-plus.dtb \
sun8i-h3-bananapi-m2-plus.dtb \
+ sun8i-h3-nanopi-m1.dtb \
sun8i-h3-nanopi-neo.dtb \
sun8i-h3-orangepi-2.dtb \
sun8i-h3-orangepi-lite.dtb \
--
2.9.3
^ permalink raw reply related
* [PATCH v3 1/2] dt-bindings: Document the hi3660 reset bindings
From: zhangfei @ 2016-12-09 2:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481031753.3202.57.camel@pengutronix.de>
On 2016?12?06? 21:42, Philipp Zabel wrote:
> Am Dienstag, den 06.12.2016, 09:51 +0800 schrieb Zhangfei Gao:
>> Add DT bindings documentation for hi3660 SoC reset controller.
>>
>> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
>> ---
>> .../bindings/reset/hisilicon,hi3660-reset.txt | 36 ++++++++++++++++++++++
>> 1 file changed, 36 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
>>
>> diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
>> new file mode 100644
>> index 0000000..178e478
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
>> @@ -0,0 +1,36 @@
>> +Hisilicon System Reset Controller
>> +======================================
>> +
>> +Please also refer to reset.txt in this directory for common reset
>> +controller binding usage.
>> +
>> +The reset controller registers are part of the system-ctl block on
>> +hi3660 SoC.
>> +
>> +Required properties:
>> +- compatible: should be
>> + "hisilicon,hi3660-reset"
>> +- #reset-cells: 2, see below
>> +- hisi,rst-syscon: phandle of the reset's syscon.
>> +
>> +Example:
>> + iomcu: iomcu at ffd7e000 {
>> + compatible = "hisilicon,hi3660-iomcu", "syscon";
>> + reg = <0x0 0xffd7e000 0x0 0x1000>;
>> + };
>> +
>> + iomcu_rst: iomcu_rst_controller {
>> + compatible = "hisilicon,hi3660-reset";
>> + hisi,rst-syscon = <&iomcu>;
>> + #reset-cells = <2>;
>> + };
>> +
>> +Specifying reset lines connected to IP modules
>> +==============================================
>> +example:
>> +
>> + i2c0: i2c at ..... {
>> + ...
>> + resets = <&iomcu_rst 0x20 3>; /* offset: 0x20; bit: 3 */
> Should this mention somewhere what register the offset is supposed to
> point to? This is the address offset to the set register, with the
> corresponding clear register being placed at offset + 4.
How about this description.
-- #reset-cells: 2, see below
- hisi,rst-syscon: phandle of the reset's syscon.
+- #reset-cells : Specifies the number of cells needed to encode a
+ reset source. The type shall be a <u32> and the value shall be 2.
+
+ Cell #1 : offset of the reset assert control
+ register from the syscon register base
+ offset + 4: deassert control register
+ offset + 8: status control register
+ Cell #2 : bit position of the reset in the reset control register
May paste in this thread for a clear view.
Thanks
^ permalink raw reply
* [PATCH] dt-bindings: Document the hi3660 reset bindings
From: Zhangfei Gao @ 2016-12-09 2:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480989092-31847-2-git-send-email-zhangfei.gao@linaro.org>
Add DT bindings documentation for hi3660 SoC reset controller.
Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
---
.../bindings/reset/hisilicon,hi3660-reset.txt | 43 ++++++++++++++++++++++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
new file mode 100644
index 0000000..2bf3344
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
@@ -0,0 +1,43 @@
+Hisilicon System Reset Controller
+======================================
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+The reset controller registers are part of the system-ctl block on
+hi3660 SoC.
+
+Required properties:
+- compatible: should be
+ "hisilicon,hi3660-reset"
+- hisi,rst-syscon: phandle of the reset's syscon.
+- #reset-cells : Specifies the number of cells needed to encode a
+ reset source. The type shall be a <u32> and the value shall be 2.
+
+ Cell #1 : offset of the reset assert control
+ register from the syscon register base
+ offset + 4: deassert control register
+ offset + 8: status control register
+ Cell #2 : bit position of the reset in the reset control register
+
+Example:
+ iomcu: iomcu at ffd7e000 {
+ compatible = "hisilicon,hi3660-iomcu", "syscon";
+ reg = <0x0 0xffd7e000 0x0 0x1000>;
+ };
+
+ iomcu_rst: iomcu_rst_controller {
+ compatible = "hisilicon,hi3660-reset";
+ hisi,rst-syscon = <&iomcu>;
+ #reset-cells = <2>;
+ };
+
+Specifying reset lines connected to IP modules
+==============================================
+example:
+
+ i2c0: i2c at ..... {
+ ...
+ resets = <&iomcu_rst 0x20 3>; /* offset: 0x20; bit: 3 */
+ ...
+ };
--
2.7.4
^ permalink raw reply related
* boot hang issue on S5PV210 with the latest kernel
From: Yong Li @ 2016-12-09 2:28 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
I am testing the latest kernel(4.8+) on my S5PV210 ARM boards. I found I
have to add the kputc debug in __armv7_mmu_cache_on in
boot/compressed/head.S:
mov r11, r3
kputc #'x'
mov r3, r11
Without the above kputc, the kernel boot hang, there is no any output on UART
Any suggestions?
Thanks,
Yong
^ permalink raw reply
* [PATCH 4/4] ARM: versatile: support configuring versatile machine for no-MMU
From: Greg Ungerer @ 2016-12-09 3:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58481DD1.6090606@arm.com>
Hi Vladimir,
On 08/12/16 00:33, Vladimir Murzin wrote:
> Hi Linus,
>
> On 07/12/16 14:11, Linus Walleij wrote:
>> Another target I had in mind was the Integrator which
>> incidentally supports a bunch of the old noMMU core
>> tiles where we can swap in an ARM946, which I guess
>> could work with this?
>
> Do you mind trying my "Allow NOMMU for MULTIPLATFORM" series [1]? Greg just
> reported it did a trick for Versatile, there is a good chance it would work
> for Integrator too ;)
>
> [1] https://www.spinics.net/lists/arm-kernel/msg546823.html
I won't speak for Linus...
But I tried building with your patches for Integrator/CP and
that builds (with an appropriate configuration) with CONFIG_MMU
disabled and runs successfully in qemu (with machine target
"integratorcp"). No other patches required.
Regards
Greg
^ permalink raw reply
* [PATCH 16/16] drivers/fsi: Add GPIO based FSI master
From: Jeremy Kerr @ 2016-12-09 4:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481069677-53660-17-git-send-email-christopher.lee.bostic@gmail.com>
Hi Chris,
> +static ssize_t store_scan(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf,
> + size_t count)
> +{
> + struct fsi_master_gpio *master = dev_get_drvdata(dev);
> +
> + fsi_master_gpio_init(master);
> +
> + /* clear out any old scan data if present */
> + fsi_master_unregister(&master->master);
> + fsi_master_register(&master->master);
> +
> + return count;
> +}
> +
> +static DEVICE_ATTR(scan, 0200, NULL, store_scan);
I think it would make more sense to have the scan attribute populated by
the fsi core; we want this on all masters, not just GPIO.
Currently, the only GPIO-master-specific functionality here is the
fsi_master_gpio_init() - but isn't this something that we can do at
probe time instead?
> +static int fsi_master_gpio_probe(struct platform_device *pdev)
> +{
> + struct fsi_master_gpio *master;
> + struct gpio_desc *gpio;
> +
> + master = devm_kzalloc(&pdev->dev, sizeof(*master), GFP_KERNEL);
> + if (!master)
> + return -ENOMEM;
We should be populating master->dev.parent, see
https://github.com/jk-ozlabs/linux/commit/5225d6c47
> + /* Optional pins */
> +
> + gpio = devm_gpiod_get(&pdev->dev, "trans", 0);
> + if (IS_ERR(gpio))
> + dev_dbg(&pdev->dev, "probe: failed to get trans pin\n");
> + else
> + master->gpio_trans = gpio;
I found devm_gpiod_get_optional(), which might make this a little
neater.
Cheers,
Jeremy
^ permalink raw reply
* [PATCH v2 0/2] GXL and GXM SCPI improvements
From: Kevin Hilman @ 2016-12-09 4:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202230849.11422-1-martin.blumenstingl@googlemail.com>
Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
> This series adds SCPI support to GXL and GXM SoCs by moving the nodes
> to meson-gx.dtsi.
> Now that we have SCPI support for GXM we can also use it to configure
> the CPU cores using the SCPI DVFS clocks.
>
> Changes since v1:
> - added Tested-By and Acked-By tags from Neil Armstrong (thanks!)
> - rebased to khilman/linux-amlogic.git/amlogic-dt64-2-v2
> - updated description of patch 1 because the "arm,scpi-pre-1.0" change
> is already part of the amlogic-dt64-2-v2 tag
Thanks for the respin. It's now too late for v4.10 (I freeze things
around -rc6 or -rc7, and it's now -rc8), but I'll queue this up for
v4.11.
Thanks,
Kevin
^ permalink raw reply
* [PATCH 3/3] iio: adc: add a driver for Qualcomm PM8xxx HK/XOADC
From: Bjorn Andersson @ 2016-12-09 5:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481032279-27115-1-git-send-email-linus.walleij@linaro.org>
On Tue 06 Dec 05:51 PST 2016, Linus Walleij wrote:
> +static struct pm8xxx_chan_info *
> +pm8xxx_get_channel(struct pm8xxx_xoadc *adc, u8 chan)
> +{
> + struct pm8xxx_chan_info *ch;
> + int i;
> +
> + if (chan >= adc->nchans)
> + return NULL;
nchans is the number of children and chan is the channel id, so this
doesn't seem right (I think you should just drop this check).
> +
> + for (i = 0; i < adc->nchans; i++) {
> + ch = &adc->chans[i];
> + if (ch->amux_channel == chan)
> + break;
> + }
> + if (i == adc->nchans)
> + return NULL;
> +
> + return ch;
> +}
> +
> +static int pm8xxx_read_channel_rsv(struct pm8xxx_xoadc *adc,
> + const struct pm8xxx_chan_info *ch,
> + u8 rsv, u16 *adc_code)
> +{
> + int ret;
> + unsigned int val;
> + u8 rsvmask, rsvval;
> + u8 lsb, msb;
> +
> + dev_dbg(adc->dev, "read channel \"%s\", amux %d, mpp %d, rsv %d\n",
> + ch->name, ch->amux_channel, ch->amux_mpp_channel, rsv);
> +
> + /* Mux in this channel */
> + ret = regmap_write(adc->map, ADC_ARB_USRP_AMUX_CNTRL,
> + ch->amux_channel << ADC_AMUX_SEL_SHIFT |
> + ch->amux_mpp_channel << ADC_AMUX_PREMUX_SHIFT);
Does this need synchronization to stop multiple clients to stomp on each
other here?
> + if (ret)
> + return ret;
> +
Regards,
Bjorn
^ permalink raw reply
* [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence GEM.
From: Harini Katakam @ 2016-12-09 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <07C910AB6AC6C345A093D5A08F5AF568CB74AF28@CHN-SV-EXMX03.mchp-main.com>
Hi,
On Thu, Dec 8, 2016 at 8:11 PM, <Andrei.Pistirica@microchip.com> wrote:
>
>
>> -----Original Message-----
>> From: Richard Cochran [mailto:richardcochran at gmail.com]
>> Sent: Wednesday, December 07, 2016 11:04 PM
>> To: Andrei Pistirica - M16132
>> Cc: netdev at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm-
>> kernel at lists.infradead.org; davem at davemloft.net;
>> nicolas.ferre at atmel.com; harinikatakamlinux at gmail.com;
>> harini.katakam at xilinx.com; punnaia at xilinx.com; michals at xilinx.com;
>> anirudh at xilinx.com; boris.brezillon at free-electrons.com;
>> alexandre.belloni at free-electrons.com; tbultel at pixelsurmer.com;
>> rafalo at cadence.com
>> Subject: Re: [RFC PATCH net-next v3 1/2] macb: Add 1588 support in
>> Cadence GEM.
>>
>> On Wed, Dec 07, 2016 at 08:39:09PM +0100, Richard Cochran wrote:
>> > > +static s32 gem_ptp_max_adj(unsigned int f_nom) {
>> > > + u64 adj;
>> > > +
>> > > + /* The 48 bits of seconds for the GEM overflows every:
>> > > + * 2^48/(365.25 * 24 * 60 *60) =~ 8 925 512 years (~= 9 mil years),
>> > > + * thus the maximum adjust frequency must not overflow CNS
>> register:
>> > > + *
>> > > + * addend = 10^9/nominal_freq
>> > > + * adj_max = +/- addend*ppb_max/10^9
>> > > + * max_ppb = (2^8-1)*nominal_freq-10^9
>> > > + */
>> > > + adj = f_nom;
>> > > + adj *= 0xffff;
>> > > + adj -= 1000000000ULL;
>> >
>> > What is this computation, and how does it relate to the comment?
>
> I considered the following simple equation: increment value at nominal frequency (which is 10^9/nominal frequency nsecs) + the maximum drift value (nsecs) <= maximum increment value@nominal frequency (which is 8bit:0xffff).
> If maximum drift is written as function of nominal frequency and maximum ppb, then the equation above yields that the maximum ppb is: (2^8 - 1) *nominal_frequency - 10^9. The equation is also simplified by the fact that the drift is written as ppm + 16bit_fractions and the increment value is written as nsec + 16bit_fractions.
>
> Rafal said that this value is hardcoded: 0x64E6, while Harini said: 250000000.
@ Andrei, I may have equated max ppb to max tsu frequency allowed on
the system and set that.
That will be wrong.
>
> I need to dig into this...
>
>>
>> I am not sure what you meant, but it sounds like you are on the wrong track.
>> Let me explain...
>
> Thanks.
>
>>
>> The max_adj has nothing at all to do with the width of the time register.
>> Rather, it should reflect the maximum possible change in the tuning word.
>>
>> For example, with a nominal 8 ns period, the tuning word is 0x80000.
>> Looking at running the clock more slowly, the slowest possible word is
>> 0x00001, meaning a difference of 0x7FFFF. This implies an adjustment of
>> 0x7FFFF/0x80000 or 999998092 ppb. Running more quickly, we can already
>> have 0x100000, twice as fast, or just under 2 billion ppb.
>>
>> You should consider the extreme cases to determine the most limited
>> (smallest) max_adj value:
>>
>> Case 1 - high frequency
>> ~~~~~~~~~~~~~~~~~~~~~~~
>>
>> With a nominal 1 ns period, we have the nominal tuning word 0x10000.
>> The smallest is 0x1 for a difference of 0xFFFF. This corresponds to an
>> adjustment of 0xFFFF/0x10000 = .9999847412109375 or 999984741 ppb.
>>
>> Case 2 - low frequency
>> ~~~~~~~~~~~~~~~~~~~~~~
>>
>> With a nominal 255 ns period, the nominal word is 0xFF0000, the largest
>> 0xFFFFFF, and the difference is 0xFFFF. This corresponds to and adjustment
>> of 0xFFFF/0xFF0000 = .0039215087890625 or 3921508 ppb.
>>
>> Since 3921508 ppb is a huge adjustment, you can simply use that as a safe
>> maximum, ignoring the actual input clock.
>>
Thanks Richard.
So, if I understand right, this is theoretically limited by the
maximum input clock:
So if the highest frequency allowed (also commonly sourced in my case)
is 200MHz,
then with a 5ns time period, considering the adjustment to slowest
possible word,
0x4FFFF/0x50000 will be 999996948 ppb.
Shouldn't this be the max_adj?
I'm afraid I don't get why we are choosing the most limited max adj..
Sorry if I'm missing something - could you please help me understand?
Regards,
Harini
^ permalink raw reply
* [PATCH 0/4] dt-bindings: mfd: Update TPS65217 interrupts
From: Milo Kim @ 2016-12-09 6:28 UTC (permalink / raw)
To: linux-arm-kernel
This patch-set fixes wrong property name and uses TPS65217 HW interrupt
number from the datasheet instead of the DT ABI. DT bindings are also
updated.
Milo Kim (4):
ARM: dts: am335x: Fix the interrupt name of TPS65217
dt-bindings: mfd: Remove TPS65217 interrupts
dt-bindings: power/supply: Update TPS65217 properties
dt-bindings: input: Add interrupt number for TPS65217
.../bindings/input/tps65218-pwrbutton.txt | 4 +++-
.../bindings/power/supply/tps65217_charger.txt | 7 +++++-
arch/arm/boot/dts/am335x-bone-common.dtsi | 8 +++----
include/dt-bindings/mfd/tps65217.h | 26 ----------------------
4 files changed, 12 insertions(+), 33 deletions(-)
delete mode 100644 include/dt-bindings/mfd/tps65217.h
--
2.9.3
^ permalink raw reply
* [PATCH 1/4] ARM: dts: am335x: Fix the interrupt name of TPS65217
From: Milo Kim @ 2016-12-09 6:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209062833.5768-1-woogyom.kim@gmail.com>
Use 'interrupt-names' for getting the charger interrupt number.
Fixes: 1934e89a769b ("ARM: dts: am335x: Add the charger interrupt")
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
index dc561d5..14b6269 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -320,7 +320,7 @@
charger {
interrupts = <TPS65217_IRQ_AC>, <TPS65217_IRQ_USB>;
- interrupts-names = "AC", "USB";
+ interrupt-names = "AC", "USB";
status = "okay";
};
--
2.9.3
^ permalink raw reply related
* [PATCH 2/4] dt-bindings: mfd: Remove TPS65217 interrupts
From: Milo Kim @ 2016-12-09 6:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209062833.5768-1-woogyom.kim@gmail.com>
Interrupt numbers are from the datasheet, so no need to keep them in
the ABI. Use the number in the DT file.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 8 +++-----
include/dt-bindings/mfd/tps65217.h | 26 --------------------------
2 files changed, 3 insertions(+), 31 deletions(-)
delete mode 100644 include/dt-bindings/mfd/tps65217.h
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 14b6269..3e32dd1 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -6,8 +6,6 @@
* published by the Free Software Foundation.
*/
-#include <dt-bindings/mfd/tps65217.h>
-
/ {
cpus {
cpu at 0 {
@@ -319,13 +317,13 @@
ti,pmic-shutdown-controller;
charger {
- interrupts = <TPS65217_IRQ_AC>, <TPS65217_IRQ_USB>;
- interrupt-names = "AC", "USB";
+ interrupts = <0>, <1>;
+ interrupt-names = "USB", "AC";
status = "okay";
};
pwrbutton {
- interrupts = <TPS65217_IRQ_PB>;
+ interrupts = <2>;
status = "okay";
};
diff --git a/include/dt-bindings/mfd/tps65217.h b/include/dt-bindings/mfd/tps65217.h
deleted file mode 100644
index cafb9e6..0000000
--- a/include/dt-bindings/mfd/tps65217.h
+++ /dev/null
@@ -1,26 +0,0 @@
-/*
- * This header provides macros for TI TPS65217 DT bindings.
- *
- * Copyright (C) 2016 Texas Instruments
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License 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.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program. If not, see <http://www.gnu.org/licenses/>.
- */
-
-#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
-
-#endif
--
2.9.3
^ permalink raw reply related
* [PATCH 3/4] dt-bindings: power/supply: Update TPS65217 properties
From: Milo Kim @ 2016-12-09 6:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209062833.5768-1-woogyom.kim@gmail.com>
Add interrupt specifiers for USB and AC charger input. Interrupt numbers
are from the datasheet.
Fix wrong property for compatible string.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
.../devicetree/bindings/power/supply/tps65217_charger.txt | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/power/supply/tps65217_charger.txt b/Documentation/devicetree/bindings/power/supply/tps65217_charger.txt
index 98d131a..a11072c 100644
--- a/Documentation/devicetree/bindings/power/supply/tps65217_charger.txt
+++ b/Documentation/devicetree/bindings/power/supply/tps65217_charger.txt
@@ -2,11 +2,16 @@ TPS65217 Charger
Required Properties:
-compatible: "ti,tps65217-charger"
+-interrupts: TPS65217 interrupt numbers for the AC and USB charger input change.
+ Should be <0> for the USB charger and <1> for the AC adapter.
+-interrupt-names: Should be "USB" and "AC"
This node is a subnode of the tps65217 PMIC.
Example:
tps65217-charger {
- compatible = "ti,tps65090-charger";
+ compatible = "ti,tps65217-charger";
+ interrupts = <0>, <1>;
+ interrupt-names = "USB", "AC";
};
--
2.9.3
^ permalink raw reply related
* [PATCH 4/4] dt-bindings: input: Specify the interrupt number of TPS65217 power button
From: Milo Kim @ 2016-12-09 6:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209062833.5768-1-woogyom.kim@gmail.com>
Specify the power button interrupt number which is from the datasheet.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt b/Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt
index 3e5b979..8682ab6 100644
--- a/Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt
+++ b/Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt
@@ -8,8 +8,9 @@ This driver provides a simple power button event via an Interrupt.
Required properties:
- compatible: should be "ti,tps65217-pwrbutton" or "ti,tps65218-pwrbutton"
-Required properties for TPS65218:
+Required properties:
- interrupts: should be one of the following
+ - <2>: For controllers compatible with tps65217
- <3 IRQ_TYPE_EDGE_BOTH>: For controllers compatible with tps65218
Examples:
@@ -17,6 +18,7 @@ Examples:
&tps {
tps65217-pwrbutton {
compatible = "ti,tps65217-pwrbutton";
+ interrupts = <2>;
};
};
--
2.9.3
^ permalink raw reply related
* [PATCH] arm64: ls1012a: dts: add eSDHC nodes
From: Yangbo Lu @ 2016-12-09 6:29 UTC (permalink / raw)
To: linux-arm-kernel
There are two eSDHC controllers in LS1012A. This patch is to add
eSDHC nodes for ls1012a dts. Also enable eSDHC for RDB/QDS boards.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
---
Changes for v2:
- Added 'broken-cd' in esdhc2 node
- Enabled esdhc in board dts
---
arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts | 8 ++++++++
arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts | 8 ++++++++
arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 25 +++++++++++++++++++++++
3 files changed, 41 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
index b841251..cc35114 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
@@ -126,3 +126,11 @@
&sai2 {
status = "okay";
};
+
+&esdhc0 {
+ status = "okay";
+};
+
+&esdhc1 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
index 62c5c71..0eef319 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
@@ -57,3 +57,11 @@
&i2c0 {
status = "okay";
};
+
+&esdhc0 {
+ status = "okay";
+};
+
+&esdhc1 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
index 24874d7..18310ca 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
@@ -128,6 +128,31 @@
clocks = <&sysclk>;
};
+ esdhc0: esdhc at 1560000 {
+ compatible = "fsl,ls1012a-esdhc", "fsl,esdhc";
+ reg = <0x0 0x1560000 0x0 0x10000>;
+ interrupts = <0 62 0x4>;
+ clock-frequency = <0>;
+ voltage-ranges = <1800 1800 3300 3300>;
+ sdhci,auto-cmd12;
+ big-endian;
+ bus-width = <4>;
+ status = "disabled";
+ };
+
+ esdhc1: esdhc at 1580000 {
+ compatible = "fsl,ls1012a-esdhc", "fsl,esdhc";
+ reg = <0x0 0x1580000 0x0 0x10000>;
+ interrupts = <0 65 0x4>;
+ clock-frequency = <0>;
+ voltage-ranges = <1800 1800 3300 3300>;
+ sdhci,auto-cmd12;
+ big-endian;
+ broken-cd;
+ bus-width = <4>;
+ status = "disabled";
+ };
+
i2c0: i2c at 2180000 {
compatible = "fsl,vf610-i2c";
#address-cells = <1>;
--
2.1.0.27.g96db324
^ permalink raw reply related
* Tearing down DMA transfer setup after DMA client has finished
From: Vinod Koul @ 2016-12-09 6:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <yw1xy3zqxt7x.fsf@unicorn.mansr.com>
On Thu, Dec 08, 2016 at 04:48:18PM +0000, M?ns Rullg?rd wrote:
> Vinod Koul <vinod.koul@intel.com> writes:
>
> > To make it efficient, disregarding your Sbox HW issue, the solution is
> > virtual channels. You can delink physical channels and virtual channels. If
> > one has SW controlled MUX then a channel can service any client. For few
> > controllers request lines are hard wired so they cant use any channel. But
> > if you dont have this restriction then driver can queue up many transactions
> > from different controllers.
>
> Have you been paying attention at all? This exactly what the driver
> ALREADY DOES.
And have you read what the question was?
--
~Vinod
^ permalink raw reply
* [RESEND PATCH v2 0/7] drm/vc4: VEC (SDTV) output support
From: Stefan Wahren @ 2016-12-09 7:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480686493-4813-1-git-send-email-boris.brezillon@free-electrons.com>
Hi,
> Boris Brezillon <boris.brezillon@free-electrons.com> hat am 2. Dezember 2016 um 14:48 geschrieben:
>
>
> Sorry for the noise, but I forgot to Cc the DT maintainers.
>
> Here is the 2nd version of the VC4/VEC series.
>
> We still miss the two clock patches mentioned by Eric in the first
> version to make the encoder work no matter the setting applied by the
> bootloader.
are there any advices to test this feature?
Is it possible to use an old Raspberry Pi B (256 MB RAM) for this?
Thanks
Stefan
^ 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