* [RFC PATCH 3/5] arm64: defconfig: sunxi: include options for Allwinner H5 SoC
From: Andre Przywara @ 2016-11-24 1:17 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, Icenowy Zheng, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479950235-26821-1-git-send-email-andre.przywara-5wv7dgnIgG8@public.gmane.org>
The Allwinner H5 SoC is closely related to the H3 SoC, so select the
basic pinctrl driver and the DMA driver to let a defconfig kernel boot
on those boards.
Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>
---
arch/arm64/Kconfig.platforms | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index cfbdf02..8300677 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -5,8 +5,12 @@ config ARCH_SUNXI
select GENERIC_IRQ_CHIP
select PINCTRL
select PINCTRL_SUN50I_A64
+ select PINCTRL_SUN8I_H3
+ select PINCTRL_SUN8I_H3_R
+ select DMA_SUN6I
help
- This enables support for Allwinner sunxi based SoCs like the A64.
+ This enables support for Allwinner sunxi based SoCs like the A64
+ and the H5.
config ARCH_ALPINE
bool "Annapurna Labs Alpine platform"
--
2.8.2
^ permalink raw reply related
* [RFC PATCH 4/5] arm64: dts: sunxi: add Allwinner H5 .dtsi
From: Andre Przywara @ 2016-11-24 1:17 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, Icenowy Zheng, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479950235-26821-1-git-send-email-andre.przywara-5wv7dgnIgG8@public.gmane.org>
The Allwinner H5 SoC is pin-compatible to the H3 SoC, but uses
Cortex-A53 cores instead.
Based on the now shared base .dtsi describing the common peripherals
describe the H5 specific nodes on top of that.
That symlinks in the sun8i-h3-h5.dtsi from the arch/arm tree.
Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>
---
arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 165 +++++++++++++++++++++++++
arch/arm64/boot/dts/allwinner/sun8i-h3-h5.dtsi | 1 +
2 files changed, 166 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
create mode 120000 arch/arm64/boot/dts/allwinner/sun8i-h3-h5.dtsi
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
new file mode 100644
index 0000000..495edf5
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
@@ -0,0 +1,165 @@
+/*
+ * Copyright (C) 2016 ARM Ltd.
+ *
+ * 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.
+ *
+ * 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 "sun8i-h3-h5.dtsi"
+
+/ {
+ interrupt-parent = <&gic>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ device_type = "cpu";
+ reg = <0>;
+ enable-method = "psci";
+ };
+
+ cpu@1 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ device_type = "cpu";
+ reg = <1>;
+ enable-method = "psci";
+ };
+
+ cpu@2 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ device_type = "cpu";
+ reg = <2>;
+ enable-method = "psci";
+ };
+
+ cpu@3 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ device_type = "cpu";
+ reg = <3>;
+ enable-method = "psci";
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = <GIC_PPI 13
+ (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14
+ (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11
+ (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10
+ (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+ };
+
+ soc {
+ mmc0: mmc@01c0f000 {
+ compatible = "allwinner,sun50i-h5-mmc",
+ "allwinner,sun50i-a64-mmc",
+ "allwinner,sun5i-a13-mmc";
+ reg = <0x01c0f000 0x1000>;
+ clocks = <&ccu CLK_BUS_MMC0>, <&ccu CLK_MMC0>;
+ clock-names = "ahb", "mmc";
+ resets = <&ccu RST_BUS_MMC0>;
+ reset-names = "ahb";
+ interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mmc1: mmc@01c10000 {
+ compatible = "allwinner,sun50i-h5-mmc",
+ "allwinner,sun50i-a64-mmc",
+ "allwinner,sun5i-a13-mmc";
+ reg = <0x01c10000 0x1000>;
+ clocks = <&ccu CLK_BUS_MMC1>, <&ccu CLK_MMC1>;
+ clock-names = "ahb", "mmc";
+ resets = <&ccu RST_BUS_MMC1>;
+ reset-names = "ahb";
+ interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mmc2: mmc@01c11000 {
+ compatible = "allwinner,sun50i-h5-mmc",
+ "allwinner,sun50i-a64-mmc",
+ "allwinner,sun5i-a13-mmc";
+ reg = <0x01c11000 0x1000>;
+ clocks = <&ccu CLK_BUS_MMC2>, <&ccu CLK_MMC2>;
+ clock-names = "ahb", "mmc";
+ resets = <&ccu RST_BUS_MMC2>;
+ reset-names = "ahb";
+ interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ ccu: clock@01c20000 {
+ compatible = "allwinner,sun50i-h5-ccu",
+ "allwinner,sun8i-h3-ccu";
+ reg = <0x01c20000 0x400>;
+ clocks = <&osc24M>, <&osc32k>;
+ clock-names = "hosc", "losc";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ gic: interrupt-controller@1c81000 {
+ compatible = "arm,gic-400";
+ reg = <0x01c81000 0x1000>,
+ <0x01c82000 0x2000>,
+ <0x01c84000 0x2000>,
+ <0x01c86000 0x2000>;
+ interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/allwinner/sun8i-h3-h5.dtsi b/arch/arm64/boot/dts/allwinner/sun8i-h3-h5.dtsi
new file mode 120000
index 0000000..74f3ce9
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun8i-h3-h5.dtsi
@@ -0,0 +1 @@
+../../../../arm/boot/dts/sun8i-h3-h5.dtsi
\ No newline at end of file
--
2.8.2
^ permalink raw reply related
* [RFC PATCH 5/5] arm64: dts: sunxi: add support for the Orange Pi PC 2 board
From: Andre Przywara @ 2016-11-24 1:17 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, Icenowy Zheng, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479950235-26821-1-git-send-email-andre.przywara-5wv7dgnIgG8@public.gmane.org>
The Orange Pi PC 2 is a typical single board computer using the
Allwinner H5 SoC. Apart from the usual suspects it features three
separately driven USB ports and a Gigabit Ethernet port.
Also it has a SPI NOR flash soldered, from which the board can boot
from. This enables the SBC to behave like a "real computer" with
built-in firmware.
Add the board specific .dts file, which includes the H5 .dtsi and
enables the peripherals that we support so far.
Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>
---
arch/arm64/boot/dts/allwinner/Makefile | 1 +
.../boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts | 183 +++++++++++++++++++++
2 files changed, 184 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index 1e29a5a..b26bb46 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -1,4 +1,5 @@
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
always := $(dtb-y)
subdir-y := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
new file mode 100644
index 0000000..a29ca6b
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
@@ -0,0 +1,183 @@
+/*
+ * Copyright (C) 2016 ARM Ltd.
+ *
+ * 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.
+ *
+ * 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 "sun50i-h5.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/pinctrl/sun4i-a10.h>
+
+/ {
+ model = "Xunlong Orange Pi PC 2";
+ compatible = "xunlong,orangepi-pc2", "allwinner,sun50i-h5";
+
+ reg_vcc3v3: vcc3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&leds_opc>, <&leds_r_opc>;
+
+ pwr_led {
+ label = "orangepi:green:pwr";
+ gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+
+ status_led {
+ label = "orangepi:red:status";
+ gpios = <&pio 0 15 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ r_gpio_keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&sw_r_opc>;
+
+ sw4 {
+ label = "sw4";
+ linux,code = <BTN_0>;
+ gpios = <&r_pio 0 3 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&ehci2 {
+ status = "okay";
+};
+
+&ehci3 {
+ status = "okay";
+};
+
+&ir {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ir_pins_a>;
+ status = "okay";
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
+ cd-inverted;
+ status = "okay";
+};
+
+&ohci1 {
+ status = "okay";
+};
+
+&ohci2 {
+ status = "okay";
+};
+
+&ohci3 {
+ status = "okay";
+};
+
+&pio {
+ leds_opc: led_pins@0 {
+ allwinner,pins = "PA15";
+ allwinner,function = "gpio_out";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+};
+
+&r_pio {
+ leds_r_opc: led_pins@0 {
+ allwinner,pins = "PL10";
+ allwinner,function = "gpio_out";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+
+ sw_r_opc: key_pins@0 {
+ allwinner,pins = "PL3";
+ allwinner,function = "gpio_in";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins_a>;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>;
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2_pins>;
+};
+
+&usbphy {
+ /* USB VBUS is always on */
+ status = "okay";
+};
--
2.8.2
^ permalink raw reply related
* Re: [alsa-devel] [PATCH v2] clkdev: add devm_of_clk_get()
From: Kuninori Morimoto @ 2016-11-24 1:45 UTC (permalink / raw)
To: Stephen Boyd
Cc: Michael Turquette, Rob Herring, Russell King, Mark Brown,
Linux-ALSA, Linux-DT, Linux-Kernel,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Linux-ARM
In-Reply-To: <20161123191037.GE25626-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Hi Stephen
Thank you for your feedback
> I've seen bindings that have the 'clocks' property at the top
> level and the appropriate 'clock-names' property to relate the
> clocks to a subnode.
>
> sound_soc {
> clocks = <&xxx>, <&xxx>;
> clock-names = "cpu", "codec";
> ...
> cpu {
> ...
> };
> codec {
> ...
> };
> };
>
> Then the subnodes call clk_get() with the top level device and
> the name of their node and things match up. I suppose this
> binding is finalized though, so we can't really do that?
>
> I see that the gpio framework has a similar design called
> devm_get_gpiod_from_child(), so how about we add a
> devm_get_clk_from_child() API? That would more closely match the
> intent here, which is to restrict the clk_get() operation to
> child nodes of the device passed as the first argument.
>
> struct clk *devm_get_clk_from_child(struct device *dev,
> const char *con_id,
> struct device_node *child);
Thanks. I will check above 2 ideas.
Best regards
---
Kuninori Morimoto
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] PM / Domains: Introduce domain-performance-state binding
From: Stephen Boyd @ 2016-11-24 2:03 UTC (permalink / raw)
To: Kevin Hilman
Cc: Vincent Guittot, Viresh Kumar, Rob Herring, Rafael Wysocki,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw@public.gmane.org,
linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel,
Mark Rutland, Ulf Hansson, Lina Iyer,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Nayak Rajendra
In-Reply-To: <m2fumhx21h.fsf-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On 11/23, Kevin Hilman wrote:
> Vincent Guittot <vincent.guittot-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> writes:
>
> > On 23 November 2016 at 16:51, Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
> >> Vincent Guittot <vincent.guittot-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> writes:
> >>
> >>> On 22 November 2016 at 19:12, Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
> >>>> Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> writes:
> >>>>
> >>>>> On 21-11-16, 09:07, Rob Herring wrote:
> >>>>>> On Fri, Nov 18, 2016 at 02:53:12PM +0530, Viresh Kumar wrote:
> >>>>>> > Some platforms have the capability to configure the performance state of
> >>>>>> > their Power Domains. The performance levels are represented by positive
> >>>>>> > integer values, a lower value represents lower performance state.
> >>>>>> >
> >>>>>> > The power-domains until now were only concentrating on the idle state
> >>>>>> > management of the device and this needs to change in order to reuse the
> >>>>>> > infrastructure of power domains for active state management.
> >>>>>> >
> >>>>>> > This patch introduces a new optional property for the consumers of the
> >>>>>> > power-domains: domain-performance-state.
> >>>>>> >
> >>>>>> > If the consumers don't need the capability of switching to different
> >>>>>> > domain performance states at runtime, then they can simply define their
> >>>>>> > required domain performance state in their node directly. Otherwise the
> >>>>>> > consumers can define their requirements with help of other
> >>>>>> > infrastructure, for example the OPP table.
> >>>>>> >
> >>>>>> > Signed-off-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >>>>>> > ---
> >>>>>> > Documentation/devicetree/bindings/power/power_domain.txt | 6 ++++++
> >>>>>> > 1 file changed, 6 insertions(+)
> >>>>>> >
> >>>>>> > diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
> >>>>>> > index e1650364b296..db42eacf8b5c 100644
> >>>>>> > --- a/Documentation/devicetree/bindings/power/power_domain.txt
> >>>>>> > +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> >>>>>> > @@ -106,6 +106,12 @@ domain provided by the 'parent' power controller.
> >>>>>> > - power-domains : A phandle and PM domain specifier as defined by bindings of
> >>>>>> > the power controller specified by phandle.
> >>>>>> >
> >>>>>> > +Optional properties:
> >>>>>> > +- domain-performance-state: A positive integer value representing the minimum
> >>>>>> > + performance level (of the parent domain) required by the consumer for its
> >>>>>> > + working. The integer value '1' represents the lowest performance level and the
> >>>>>> > + highest value represents the highest performance level.
> >>>>>>
> >>>>>> How does one come up with the range of values?
> >>>>>
> >>>>> Why would we need a range here? The value here represents the minimum 'state'
> >>>>> and the assumption is that everything above that level would be fine. So the
> >>>>> range is automatically: domain-performance-state -> MAX.
> >>>>>
> >>>>>> It seems like you are
> >>>>>> just making up numbers. Couldn't the domain performance level be an OPP
> >>>>>> in the sense that it is a collection of clock frequencies and voltage
> >>>>>> settings?
> >>>>>
> >>>>> The clock is going to be handled by the device itself (at least for the case we
> >>>>> have today) and the performance-state lies with the power-domain which is
> >>>>> configured separately. If the performance level includes both clk and voltage,
> >>>>> then why would we need to show the clock rates in the DT ? Wouldn't a
> >>>>> performance level be enough in such cases?
> >>>>
> >>>> I think the question is: what does the performance-level of a domain
> >>>> actually mean? Or, what are the units?
> >>>>
> >>>> Depending on the SoC, there's probably a few things this could mean. It
> >>>> might mean is that an underlying bus/interconnect can be configured to
> >>>> guarantee a specific bandwidth or throughput. That in turn might mean
> >>>> that that bus/interconnect might have to be set at a specific
> >>>> frequency/voltage.
> >>>>
> >>>> In your case, IIUC, you're just passing some magic value to some
> >>>> firmware running on a micro-controller, but under the hood that uC is
> >>>> probably configuring a frequency/voltage someplace.
> >>>
> >>> In the case described by Viresh, it's only about setting the voltage
> >>> of a power domain that is shared between different devices. these
> >>> devices wants to run at different frequency (set by the devices) but
> >>> we have to select a Volateg value that will match with the constraint
> >>> of all devices (in this case the highest voltage)
> >>
> >> Then, at least for this use case, we're talking about voltage, not some
> >> unspecified units.
In some cases we actually know the voltage of the domain and
would want to put some voltage mapping in DT. For example, level
1 is voltage 2V and level 2 is voltage 2.5V. In other cases we
don't know the voltage, all we know is the voltage "corner" which
is a number from 0 to N that is translated into a voltage by the
firmware but is otherwise unknown what that is outside of the
firmware. In this case we've lost the units, but otherwise we're
still interested in requesting some 'level' that the domain be
operating in.
> >>
> >> But that makes me wonder, this performance state sounds like something
> >> that is changing dynamically at runtime, so why do you want to describe
> >> this statically in DT?
> >>
> >> This sounds to me like the job of the genpd. When any device in the
> >> domain does its pm_runtime_get(), the domain could check the device
> >> frequency and see if it needs to change the domain voltage in order for
> >> that device to operate at that frequency.
How do we check the device frequency? Does the domain need to
know about the clocks for all devices that are in the domain and
what clocks in there are contributing to the voltage requirement?
In out of tree solutions we've 'bucketized' the requirements of
the devices into an array sized to the number of levels of the
voltage domain. When a device requires a new level, we increment
the new level and decrement the old level and then look for the
largest non-zero index in the array. This is the inverse design
of iterating over all devices in the domain to see what frequency
they're running at to determine the voltage requirement. I guess
using PM QoS would be similar here to do the aggregation and then
tell the domain to go to that level.
> >> When the device goes away
> >> (using pm_runtime_put()) the domain can check again if it could lower
> >> the voltage and still meet the requirements of the remaining devices.
> >
> > That's only part of the job. The device can change its frequency and
> > as a result ask for a new voltage index while it is already running
>
> That's fine. Use clock notifiers, or better use QoS (with notifiers) so
> that the genpd knows when any of those change.
>
>From my perspective clock notifiers are going to be ugly. At the
point we notify that a rate has changed we're deep in the clk
framework holding the prepare mutex and we're calling it from an
SRCU callback. If those callbacks need to turn on an i2c clk to
communicate with some PMIC to change voltages we're in a world of
pain due to our locking scheme. Maybe that's solvable with a
different clk locking scheme though so I may be overly concerned
here and everything will work out. Also, we don't have any
notification that a clock is turned on or off right now, which
sounds like we're going to assume is the case when a device gets
pm_runtime_put().
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v6 1/5] mmc: dt-bindings: add ZTE ZX296718 MMC bindings
From: Jun Nie @ 2016-11-24 2:17 UTC (permalink / raw)
To: Shawn Guo, xie.baoyou, Rob Herring, mark.rutland
Cc: Ulf Hansson, Jaehoon Chung, Jason Liu, chen.chaokai, lai.binz,
linux-mmc, Jun Nie, devicetree
In-Reply-To: <1479450555-19047-2-git-send-email-jun.nie@linaro.org>
2016-11-18 14:29 GMT+08:00 Jun Nie <jun.nie@linaro.org>:
> Document the device-tree binding of ZTE MMC host on
> ZX296718 SoC.
>
> Signed-off-by: Jun Nie <jun.nie@linaro.org>
> ---
> .../devicetree/bindings/mmc/zx-dw-mshc.txt | 35 ++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt
>
> diff --git a/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt
> new file mode 100644
> index 0000000..c175c4b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt
> @@ -0,0 +1,35 @@
> +* ZTE specific extensions to the Synopsys Designware Mobile Storage
> + Host Controller
> +
> +The Synopsys designware mobile storage host controller is used to interface
> +a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
> +differences between the core Synopsys dw mshc controller properties described
> +by synopsys-dw-mshc.txt and the properties used by the ZTE specific
> +extensions to the Synopsys Designware Mobile Storage Host Controller.
> +
> +Required Properties:
> +
> +* compatible: should be
> + - "zte,zx296718-dw-mshc": for ZX SoCs
> +
> +Example:
> +
> + mmc1: mmc@1110000 {
> + compatible = "zte,zx296718-dw-mshc";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x01110000 0x1000>;
> + interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
> + fifo-depth = <32>;
> + data-addr = <0x200>;
> + fifo-watermark-aligned;
> + bus-width = <4>;
> + clock-frequency = <50000000>;
> + clocks = <&topcrm SD0_AHB>, <&topcrm SD0_WCLK>;
> + clock-names = "biu", "ciu";
> + num-slots = <1>;
> + max-frequency = <50000000>;
> + cap-sdio-irq;
> + cap-sd-highspeed;
> + status = "disabled";
> + };
> --
> 1.9.1
>
Hi Rob & Mark,
Could you help review and act this patch if you think it is OK? Thank you!
Jun
^ permalink raw reply
* Re: [PATCH v6 3/5] Documentation: synopsys-dw-mshc: add binding for fifo quirks
From: Jun Nie @ 2016-11-24 2:19 UTC (permalink / raw)
To: Shawn Guo, xie.baoyou, Rob Herring, mark.rutland
Cc: Ulf Hansson, Jaehoon Chung, Jason Liu, chen.chaokai, lai.binz,
linux-mmc, Jun Nie, devicetree
In-Reply-To: <1479450555-19047-4-git-send-email-jun.nie@linaro.org>
2016-11-18 14:29 GMT+08:00 Jun Nie <jun.nie@linaro.org>:
> Add fifo-addr property and fifo-watermark-quirk property to
> synopsys-dw-mshc bindings. It is intended to provide more
> dt interface to support SoCs specific configuration.
>
> Signed-off-by: Jun Nie <jun.nie@linaro.org>
> ---
> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
> index 4e00e85..8bf2e41 100644
> --- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
> +++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
> @@ -76,6 +76,17 @@ Optional properties:
>
> * broken-cd: as documented in mmc core bindings.
>
> +* data-addr: Override fifo address with value provided by DT. The default FIFO reg
> + offset is assumed as 0x100 (version < 0x240A) and 0x200(version >= 0x240A) by
> + driver. If the controller does not follow this rule, please use this property
> + to set fifo address in device tree.
> +
> +* fifo-watermark-aligned: Data done irq is expected if data length is less than
> + watermark in PIO mode. But fifo watermark is requested to be aligned with data
> + length in some SoC so that TX/RX irq can be generated with data done irq. Add this
> + watermark quirk to mark this requirement and force fifo watermark setting
> + accordingly.
> +
> * vmmc-supply: The phandle to the regulator to use for vmmc. If this is
> specified we'll defer probe until we can find this regulator.
>
> @@ -103,6 +114,8 @@ board specific portions as listed below.
> interrupts = <0 75 0>;
> #address-cells = <1>;
> #size-cells = <0>;
> + data-addr = <0x200>;
> + fifo-watermark-aligned;
> };
>
> [board specific internal DMA resources]
> --
> 1.9.1
>
Hi Rob & Mark,
Could you help review and act this patch if you think it is OK? Thank you!
Jun
^ permalink raw reply
* Re: [PATCH v7 4/4] vcodec: mediatek: Add Maintainers entry for Mediatek JPEG driver
From: Rick Chang @ 2016-11-24 2:53 UTC (permalink / raw)
To: Hans Verkuil
Cc: Laurent Pinchart, Mauro Carvalho Chehab, Matthias Brugger,
Rob Herring, linux-kernel, linux-media, srv_heupstream,
linux-mediatek, linux-arm-kernel, devicetree, Minghsiu Tsai
In-Reply-To: <1479786377-11567-5-git-send-email-rick.chang@mediatek.com>
Hi Hans,
Is it possible to update this patch? or I should create another new one.
I may need to update it.
Sorry for the inconvenience.
On Tue, 2016-11-22 at 11:46 +0800, Rick Chang wrote:
> Signed-off-by: Rick Chang <rick.chang@mediatek.com>
> Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
> ---
> MAINTAINERS | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 93e9f42..a9e7ee0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7818,6 +7818,13 @@ L: netdev@vger.kernel.org
> S: Maintained
> F: drivers/net/ethernet/mediatek/
>
> +MEDIATEK JPEG DRIVER
> +M: Rick Chang <rick.chang@mediatek.com>
> +M: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
> +S: Supported
> +F: drivers/media/platform/mtk-jpeg/
> +F: Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
> +
> MEDIATEK MEDIA DRIVER
> M: Tiffany Lin <tiffany.lin@mediatek.com>
> M: Andrew-CT Chen <andrew-ct.chen@mediatek.com>
^ permalink raw reply
* Re: [PATCH v2 4/5] arm: dts: am57xx-beagle-x15-common: Add overide powerhold property
From: Keerthy @ 2016-11-24 3:45 UTC (permalink / raw)
To: Tony Lindgren
Cc: Lee Jones, robh+dt, linux-omap, linux-kernel, devicetree,
linux-gpio, nm, t-kristo
In-Reply-To: <20161123160841.GG4082@atomide.com>
On Wednesday 23 November 2016 09:38 PM, Tony Lindgren wrote:
> * Keerthy <j-keerthy@ti.com> [161123 00:33]:
>> On Wednesday 23 November 2016 02:03 PM, Lee Jones wrote:
>>> On Wed, 23 Nov 2016, Keerthy wrote:
>>>> On Tuesday 15 November 2016 05:38 AM, Tony Lindgren wrote:
>>>>> * Keerthy <j-keerthy@ti.com> [161109 21:10]:
>>>>>> The PMICs have POWERHOLD set by default which prevents PMIC shutdown
>>>>>> even on DEV_CTRL On bit set to 0 as the Powerhold has higher priority.
>>>>>> So to enable pmic power off this property lets one over ride the default
>>>>>> value and enable pmic power off.
>>>>>
>>>>> This should not cause merge conflicts so probably best to merge along
>>>>> with the driver changes:
>>>>>
>>>>> Acked-by: Tony Lindgren <tony@atomide.com>
>>>>>
>>>>> If you guys want me to pick up this separately let me know.
>>>>
>>>> Hi Lee Jones,
>>>>
>>>> Are you planning to pull DT and Documentation patches as well?
>>>
>>> No need. They can be safely applied to their own subsystems.
>>
>> Okay. Thanks for the response.
>>
>> Tony,
>>
>> Hope you can pull the DT patches.
>
> Applying both into omap-for-v4.10/dt thanks. Please send dts changes
> seprately next time if there are no dependencies. This leaves out
> the second guessing who should apply what.
Sure Tony.
>
> Regards,
>
> Tony
>
^ permalink raw reply
* Re: [RFC PATCH 2/5] dmaengine: allow sun6i-dma for more SoCs
From: Chen-Yu Tsai @ 2016-11-24 4:16 UTC (permalink / raw)
To: Andre Przywara
Cc: Maxime Ripard, Chen-Yu Tsai, Icenowy Zheng, linux-sunxi,
linux-arm-kernel, Mark Rutland, Rob Herring, devicetree
In-Reply-To: <1479950235-26821-3-git-send-email-andre.przywara-5wv7dgnIgG8@public.gmane.org>
Hi,
On Thu, Nov 24, 2016 at 9:17 AM, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> wrote:
> The sun6i DMA driver is used in the Allwinner A64 and H5 SoC, which
> have arm64 capable cores. Add the generic sunxi config symbol to allow
> the driver to be selected by arm64 Kconfigs, which don't feature
> SoC specific MACH_xxxx configs.
>
> Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>
> ---
> drivers/dma/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index af63a6b..003c284 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -157,7 +157,7 @@ config DMA_SUN4I
>
> config DMA_SUN6I
> tristate "Allwinner A31 SoCs DMA support"
> - depends on MACH_SUN6I || MACH_SUN8I || COMPILE_TEST
> + depends on MACH_SUN6I || MACH_SUN8I || COMPILE_TEST || ARCH_SUNXI
AFAIK ARCH_SUNXI encompasses/supersedes MACH_SUN*I.
(And I don't have to add MACH_SUN9I later :) )
ChenYu
> depends on RESET_CONTROLLER
> select DMA_ENGINE
> select DMA_VIRTUAL_CHANNELS
> --
> 2.8.2
>
^ permalink raw reply
* Re: [PATCH 1/2] PM / Domains: Introduce domain-performance-state binding
From: Viresh Kumar @ 2016-11-24 4:40 UTC (permalink / raw)
To: Stephen Boyd
Cc: Kevin Hilman, Vincent Guittot, Rob Herring, Rafael Wysocki,
linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org,
linux-kernel, Mark Rutland, Ulf Hansson, Lina Iyer,
devicetree@vger.kernel.org, Nayak Rajendra
In-Reply-To: <20161124020322.GI6095@codeaurora.org>
On 23-11-16, 18:03, Stephen Boyd wrote:
> On 11/23, Kevin Hilman wrote:
> > Vincent Guittot <vincent.guittot@linaro.org> writes:
> > > On 23 November 2016 at 16:51, Kevin Hilman <khilman@baylibre.com> wrote:
> > >> Then, at least for this use case, we're talking about voltage, not some
> > >> unspecified units.
>
> In some cases we actually know the voltage of the domain and
> would want to put some voltage mapping in DT. For example, level
> 1 is voltage 2V and level 2 is voltage 2.5V.
But even in these cases we wouldn't be using the voltage values within the
kernel as we will be giving only a performance state to the M3 core, right?
> In other cases we
> don't know the voltage, all we know is the voltage "corner" which
> is a number from 0 to N that is translated into a voltage by the
> firmware but is otherwise unknown what that is outside of the
> firmware. In this case we've lost the units, but otherwise we're
> still interested in requesting some 'level' that the domain be
> operating in.
> > >> But that makes me wonder, this performance state sounds like something
> > >> that is changing dynamically at runtime, so why do you want to describe
> > >> this statically in DT?
Each frequency a device can operate in has the requirement of minimum
performance state of the domain and so we need these values in the DT.
> > >>
> > >> This sounds to me like the job of the genpd. When any device in the
> > >> domain does its pm_runtime_get(), the domain could check the device
> > >> frequency and see if it needs to change the domain voltage in order for
> > >> that device to operate at that frequency.
Also note that the performance index may be required to be changed before
updating the frequency in case we are increasing the frequency which needs a
higher performance index to be set.
> How do we check the device frequency? Does the domain need to
> know about the clocks for all devices that are in the domain and
> what clocks in there are contributing to the voltage requirement?
>
> In out of tree solutions we've 'bucketized' the requirements of
> the devices into an array sized to the number of levels of the
> voltage domain. When a device requires a new level, we increment
> the new level and decrement the old level and then look for the
> largest non-zero index in the array.
For such a design we need to know the index-size in advance and I am not sure if
we should get anything like that from the DT.
> This is the inverse design
> of iterating over all devices in the domain to see what frequency
> they're running at to determine the voltage requirement. I guess
> using PM QoS would be similar here to do the aggregation and then
> tell the domain to go to that level.
>
> > >> When the device goes away
> > >> (using pm_runtime_put()) the domain can check again if it could lower
> > >> the voltage and still meet the requirements of the remaining devices.
This will be done nevertheless.
> > >
> > > That's only part of the job. The device can change its frequency and
> > > as a result ask for a new voltage index while it is already running
> >
> > That's fine. Use clock notifiers, or better use QoS (with notifiers) so
> > that the genpd knows when any of those change.
Yes genpd will be handling it all but it will surely need to know the
performance index for each individual clock rate we support.
The way I have written the code for now is this with another QOS request type
DEV_PM_QOS_PERFORMANCE:
+static int _generic_set_opp_pd(...)
+{
+
...
+ /* Scaling up? Scale voltage before frequency */
+ if (freq > old_freq)
+ dev_pm_qos_update_request(req, perf);
+
+ clk_set_rate(...);
+
+ if (freq < old_freq)
+ dev_pm_qos_update_request(req, perf);
+
+ return 0;
+}
And genpd is registering its notifier for DEV_PM_QOS_PERFORMANCE request type
where it accumulates requests from all the devices and selects the highest one.
--
viresh
^ permalink raw reply
* Re: [alsa-devel] [PATCH v2] clkdev: add devm_of_clk_get()
From: Kuninori Morimoto @ 2016-11-24 4:57 UTC (permalink / raw)
To: Stephen Boyd, Rob Herring, Linux-ALSA, Linux-DT,
Michael Turquette, Russell King, Linux-Kernel, Mark Brown,
linux-clk, Linux-ARM
In-Reply-To: <87a8cpejn5.wl%kuninori.morimoto.gx@renesas.com>
Hi Stephen, again
> > I've seen bindings that have the 'clocks' property at the top
> > level and the appropriate 'clock-names' property to relate the
> > clocks to a subnode.
> >
> > sound_soc {
> > clocks = <&xxx>, <&xxx>;
> > clock-names = "cpu", "codec";
> > ...
> > cpu {
> > ...
> > };
> > codec {
> > ...
> > };
> > };
> >
> > Then the subnodes call clk_get() with the top level device and
> > the name of their node and things match up. I suppose this
> > binding is finalized though, so we can't really do that?
> >
> > I see that the gpio framework has a similar design called
> > devm_get_gpiod_from_child(), so how about we add a
> > devm_get_clk_from_child() API? That would more closely match the
> > intent here, which is to restrict the clk_get() operation to
> > child nodes of the device passed as the first argument.
> >
> > struct clk *devm_get_clk_from_child(struct device *dev,
> > const char *con_id,
> > struct device_node *child);
Thanks, but, my point is that Linux already have "of_clk_get()",
but we don't have its devm_ version.
The point is that of_clk_get() can get clock from "device_node".
Why having devm_ version become so problem ?
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: da850: add the mstpri and ddrctl nodes
From: Sekhar Nori @ 2016-11-24 5:03 UTC (permalink / raw)
To: David Lechner, Kevin Hilman
Cc: Bartosz Golaszewski, Michael Turquette, Rob Herring, Frank Rowand,
Mark Rutland, Peter Ujfalusi, Russell King, linux-devicetree,
David Airlie, LKML, linux-drm, Tomi Valkeinen, Jyri Sarha,
arm-soc, Laurent Pinchart
In-Reply-To: <f88df859-3c0f-38f2-275d-ce6a9996fb6e-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
On Thursday 24 November 2016 04:18 AM, David Lechner wrote:
> On 11/23/2016 04:32 PM, Kevin Hilman wrote:
>> David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org> writes:
>>
>>> On 11/23/2016 04:27 AM, Bartosz Golaszewski wrote:
>>>> 2016-11-22 23:23 GMT+01:00 David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>:
>>>>> On 11/15/2016 05:00 AM, Bartosz Golaszewski wrote:
>>>>>>
>>>>>> Add the nodes for the MSTPRI configuration and DDR2/mDDR memory
>>>>>> controller drivers to da850.dtsi.
>>>>>>
>>>>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>>>>>> ---
>>>>>> v1 -> v2:
>>>>>> - moved the priority controller node above the cfgchip node
>>>>>> - renamed added nodes to better reflect their purpose
>>>>>>
>>>>>> arch/arm/boot/dts/da850.dtsi | 8 ++++++++
>>>>>> 1 file changed, 8 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm/boot/dts/da850.dtsi
>>>>>> b/arch/arm/boot/dts/da850.dtsi
>>>>>> index 1bb1f6d..412eec6 100644
>>>>>> --- a/arch/arm/boot/dts/da850.dtsi
>>>>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>>>>> @@ -210,6 +210,10 @@
>>>>>> };
>>>>>>
>>>>>> };
>>>>>> + prictrl: priority-controller@14110 {
>>>>>> + compatible = "ti,da850-mstpri";
>>>>>> + reg = <0x14110 0x0c>;
>>>>>
>>>>>
>>>>> I think we should add status = "disabled"; here and let boards opt in.
>>>>>
>>>>>> + };
>>>>>> cfgchip: chip-controller@1417c {
>>>>>> compatible = "ti,da830-cfgchip", "syscon",
>>>>>> "simple-mfd";
>>>>>> reg = <0x1417c 0x14>;
>>>>>> @@ -451,4 +455,8 @@
>>>>>> 1 0 0x68000000 0x00008000>;
>>>>>> status = "disabled";
>>>>>> };
>>>>>> + memctrl: memory-controller@b0000000 {
>>>>>> + compatible = "ti,da850-ddr-controller";
>>>>>> + reg = <0xb0000000 0xe8>;
>>>>>
>>>>>
>>>>> same here. status = "disabled";
>>>>>
>>>>>> + };
>>>>>> };
>>>>>>
>>>>
>>>> Hi David,
>>>>
>>>> I did that initially[1][2] and it was rejected by Kevin[3] and
>>>> Laurent[4].
>>>>
>>>> FYI this patch has already been queued by Sekhar.
>>>
>>> Thanks. I did not see those threads.
>>>
>>> FYI to maintainers, having these enabled by default causes error
>>> messages in the kernel log for other boards that are not supported by
>>> the drivers.
>>
>> Then the driver is too noisy and should be cleaned up.
>>
>>> Since there is only one board that is supported and soon
>>> to be 2 that are not, I would rather have this disabled by default to
>>> avoid the error messages.
>>
>> IMO, what exactly are the error messages? Sounds like the driver is
>> being too verbose, and calling things errors that are not really errors.
>
> It is just one line per driver.
>
> dev_err(dev, "no master priorities defined for this board\n");
>
> and
>
> dev_err(dev, "no settings defined for this board\n");
>
>
> Since "ti,da850-lcdk" is the only board supported in these drivers, all
> other boards will see these error messages.
Thats pretty bad. Sorry about that. The original justification for
keeping them enabled all the time was that they are in-SoC modules with
no external dependencies (like IO lines or voltage rails) so they can be
enabled on all boards that use DA850. While that remains true, the
configuration itself is board specific.
I think the error messages are still useful, so instead of silencing
them, I think we should go back to keeping these nodes disabled by
default and enabling only on boards which have support for it in the driver.
Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 3/3] dmaengine: sun6i: share the dma driver with sun50i
From: Chen-Yu Tsai @ 2016-11-24 5:04 UTC (permalink / raw)
To: Hao Zhang
Cc: Maxime Ripard, Chen-Yu Tsai, Dan Williams, Vinod Koul,
Mark Rutland, Rob Herring, Catalin Marinas, Will Deacon,
dmaengine-u79uwXL29TY76Z2rM5mHXA, linux-kernel, devicetree,
linux-arm-kernel
In-Reply-To: <1479638740-20520-4-git-send-email-hao5781286-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi,
On Sun, Nov 20, 2016 at 6:45 PM, Hao Zhang <hao5781286-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Changes the limited buswith to 8 bytes,and add
> the test in sun6i_dma_config function
>
> Accroding to sun6i dma driver, i think ,if the client
> doesn't configure the address width with dmaengine_slave_config
> function, it would use the default width. So we can add the test
> in sun6i_dma_config function called by dmaengine_slave_config,
> and test the configuration whether is support for the device.
>
One thing people haven't really noticed is that starting with
A80, A83T, H3, the DMA channel configuration registers have
been slightly changed when compared to A31/A23/A33. The DMA
burst length field offset was changed by 1.
We need to fix this.
ChenYu
> Signed-off-by: Hao Zhang <hao5781286-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/dma/sun6i-dma.c | 33 ++++++++++++++++++++++++++++++++-
> 1 file changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index a235878..f7c90b6 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -250,7 +250,7 @@ static inline s8 convert_burst(u32 maxburst)
> static inline s8 convert_buswidth(enum dma_slave_buswidth addr_width)
> {
> if ((addr_width < DMA_SLAVE_BUSWIDTH_1_BYTE) ||
> - (addr_width > DMA_SLAVE_BUSWIDTH_4_BYTES))
> + (addr_width > DMA_SLAVE_BUSWIDTH_8_BYTES))
> return -EINVAL;
>
> return addr_width >> 1;
> @@ -758,6 +758,18 @@ static int sun6i_dma_config(struct dma_chan *chan,
> {
> struct sun6i_vchan *vchan = to_sun6i_vchan(chan);
>
> + if ((BIT(config->src_addr_width) | chan->device->src_addr_widths) !=
> + chan->device->src_addr_widths) {
> + dev_err(chan2dev(chan), "Invalid DMA configuration\n");
> + return -EINVAL;
> + }
> +
> + if ((BIT(config->dst_addr_width) | chan->device->dst_addr_widths) !=
> + chan->device->dst_addr_widths) {
> + dev_err(chan2dev(chan), "Invalid DMA configuration\n");
> + return -EINVAL;
> + }
> +
> memcpy(&vchan->cfg, config, sizeof(*config));
>
> return 0;
> @@ -1028,11 +1040,23 @@ static struct sun6i_dma_config sun8i_h3_dma_cfg = {
> .nr_max_vchans = 34,
> };
>
> +/*
> + * The A64 has 8 physical channels, a maximum DRQ port id of 27,
> + * and a total of 38 usable source and destination endpoints.
> + */
> +
> +static struct sun6i_dma_config sun50i_a64_dma_cfg = {
> + .nr_max_channels = 8,
> + .nr_max_requests = 27,
> + .nr_max_vchans = 38,
> +};
> +
> static const struct of_device_id sun6i_dma_match[] = {
> { .compatible = "allwinner,sun6i-a31-dma", .data = &sun6i_a31_dma_cfg },
> { .compatible = "allwinner,sun8i-a23-dma", .data = &sun8i_a23_dma_cfg },
> { .compatible = "allwinner,sun8i-a83t-dma", .data = &sun8i_a83t_dma_cfg },
> { .compatible = "allwinner,sun8i-h3-dma", .data = &sun8i_h3_dma_cfg },
> + { .compatible = "allwinner,sun50i-a64-dma", .data = &sun50i_a64_dma_cfg },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, sun6i_dma_match);
> @@ -1112,6 +1136,13 @@ static int sun6i_dma_probe(struct platform_device *pdev)
> BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
> sdc->slave.directions = BIT(DMA_DEV_TO_MEM) |
> BIT(DMA_MEM_TO_DEV);
> +
> + if (of_device_is_compatible(pdev->dev.of_node,
> + "allwinner,sun50i-a64-dma")) {
> + sdc->slave.src_addr_widths |= BIT(DMA_SLAVE_BUSWIDTH_8_BYTES);
> + sdc->slave.dst_addr_widths |= BIT(DMA_SLAVE_BUSWIDTH_8_BYTES);
> + }
> +
> sdc->slave.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
> sdc->slave.dev = &pdev->dev;
>
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/5] Documentation: pinctrl: palmas: Add ti,palmas-powerhold-override property definition
From: Keerthy @ 2016-11-24 5:28 UTC (permalink / raw)
To: Rob Herring
Cc: tony, lee.jones, linux-omap, linux-kernel, devicetree, linux-gpio,
nm, t-kristo
In-Reply-To: <20161115014352.5d3qwoonlo63mp5p@rob-hp-laptop>
On Tuesday 15 November 2016 07:13 AM, Rob Herring wrote:
> On Thu, Nov 10, 2016 at 10:39:16AM +0530, Keerthy wrote:
>> GPIO7 is configured in POWERHOLD mode which has higher priority
>> over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON
>> bit is turned off. This property enables driver to over ride the
>> POWERHOLD value to GPIO7 so as to turn off the PMIC in power off
>> scenarios.
>>
>> Signed-off-by: Keerthy <j-keerthy@ti.com>
>> ---
>> Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>
> Acked-by: Rob Herring <robh@kernel.org>
Tony,
Are you planning to pick this one as well?
- Keerthy
>
^ permalink raw reply
* Re: [PATCH 1/2] gpio: axp209: use correct register for GPIO input status
From: Chen-Yu Tsai @ 2016-11-24 5:52 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Quentin Schulz, Linus Walleij, Alexandre Courbot, Rob Herring,
Mark Rutland, Chen-Yu Tsai, linux-gpio@vger.kernel.org,
devicetree, linux-kernel
In-Reply-To: <20161123144532.3089ebfd@free-electrons.com>
On Wed, Nov 23, 2016 at 9:45 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Wed, 23 Nov 2016 14:27:48 +0100, Quentin Schulz wrote:
>> The GPIO input status was read from control register
>> (AXP20X_GPIO[210]_CTRL) instead of status register (AXP20X_GPIO20_SS).
>>
>> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
>
> This smells like a bug fix, so perhaps Cc: stable?
Presently there are no in-tree boards that use the GPIOs
as input. And the only user I see is the CHIP, for the headphone
jack detection. Again, not supported in mainline yet.
Not sure if there is value in sending it for stable.
ChenYu
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 3/3] ARM: dts: da850: Add node for pullup/pulldown pinconf
From: Sekhar Nori @ 2016-11-24 5:54 UTC (permalink / raw)
To: David Lechner, Linus Walleij, Rob Herring, Mark Rutland,
Kevin Hilman
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
Axel Haslam, Alexandre Bailon, Bartosz Gołaszewski
In-Reply-To: <06bc8517-8c33-85a1-9d5a-29042c7281db@lechnology.com>
On Wednesday 23 November 2016 09:54 PM, David Lechner wrote:
> On 11/23/2016 05:12 AM, Sekhar Nori wrote:
>> On Wednesday 23 November 2016 08:59 AM, David Lechner wrote:
>>> This SoC has a separate pin controller for configuring pullup/pulldown
>>> bias on groups of pins.
>>>
>>> Signed-off-by: David Lechner <david@lechnology.com>
>>> ---
>>> arch/arm/boot/dts/da850.dtsi | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>>> index 8945815..1c0224c 100644
>>> --- a/arch/arm/boot/dts/da850.dtsi
>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>> @@ -210,6 +210,11 @@
>>> };
>>>
>>> };
>>> + pinconf: pin-controller@22c00c {
>>> + compatible = "ti,da850-pupd";
>>> + reg = <0x22c00c 0x8>;
>>> + status = "disabled";
>>> + };
>>
>> Can you please place this below the i2c1 node. I am trying to keep the
>> nodes sorted by unit address. I know thats broken in many places today,
>> but lets add the new ones where they should eventually end up.
>
> I can do this, but it seems that the predominant sorting pattern here is
> to keep subsystems together (e.g. all i2c are together, all uart are
> together, etc.)
Yeah, but that quickly gives away as there are many singleton devices
and everyone tries to add theirs at the end of the list resulting in
merge conflicts.
> Would a separate patch to sort everything by unit address to get this
> cleaned up be acceptable?
Agree with Kevin that it would be churn. If done, it should be last
thing that gets done in a merge window. I would not attempt it in
relatively busy merge windows like this one.
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH v4 0/2] da8xx: fix section mismatch in new drivers
From: Sekhar Nori @ 2016-11-24 6:01 UTC (permalink / raw)
To: Bartosz Golaszewski, Kevin Hilman, Michael Turquette, Rob Herring,
Frank Rowand, Mark Rutland, Peter Ujfalusi, Russell King
Cc: LKML, arm-soc, linux-drm, linux-devicetree, Jyri Sarha,
Tomi Valkeinen, David Airlie, Laurent Pinchart, Robin Murphy,
Sudeep Holla
In-Reply-To: <1479908400-10136-1-git-send-email-bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On Wednesday 23 November 2016 07:09 PM, Bartosz Golaszewski wrote:
> Sekhar noticed there's a section mismatch in the da8xx-mstpri and
> da8xx-ddrctl drivers. This is caused by calling
> of_flat_dt_get_machine_name() which has an __init annotation.
>
> This series makes the drivers drop the call and not print the
> machine name in the error message.
Applied both. Thanks!
Regards,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/5] smd: Make packet size a constant
From: Bjorn Andersson @ 2016-11-24 6:14 UTC (permalink / raw)
To: Jeremy McNicoll
Cc: linux-arm-msm, linux-soc, devicetree, linux-mmc, andy.gross,
sboyd, robh, arnd, riteshh
In-Reply-To: <1479863388-23678-3-git-send-email-jeremymc@redhat.com>
On Tue 22 Nov 17:09 PST 2016, Jeremy McNicoll wrote:
> Use a macro to define the maximum size of a RPM message.
>
No thanks.
> Signed-off-by: Jeremy McNicoll <jeremymc@redhat.com>
> ---
> drivers/soc/qcom/smd-rpm.c | 2 +-
> include/linux/soc/qcom/smd.h | 7 +++++++
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/qcom/smd-rpm.c b/drivers/soc/qcom/smd-rpm.c
> index 6609d7e..b5a2836 100644
> --- a/drivers/soc/qcom/smd-rpm.c
> +++ b/drivers/soc/qcom/smd-rpm.c
> @@ -114,7 +114,7 @@ int qcom_rpm_smd_write(struct qcom_smd_rpm *rpm,
> size_t size = sizeof(*pkt) + count;
>
> /* SMD packets to the RPM may not exceed 256 bytes */
> - if (WARN_ON(size >= 256))
> + if (WARN_ON(size >= SMD_RPM_MAX_SIZE))
> return -EINVAL;
The only thing you do is to change "oh, the max packet size is 256
bytes" to "hmm, i wonder what SMD_RPM_MAX_SIZE is and if the comment is
still valid".
>
> pkt = kmalloc(size, GFP_KERNEL);
> diff --git a/include/linux/soc/qcom/smd.h b/include/linux/soc/qcom/smd.h
> index f148e0f..8039015 100644
> --- a/include/linux/soc/qcom/smd.h
> +++ b/include/linux/soc/qcom/smd.h
> @@ -4,6 +4,13 @@
> #include <linux/device.h>
> #include <linux/mod_devicetable.h>
>
> +
> +/*
> + * SMD packets to the RPM may not exceed 256 bytes
> + */
> +#define SMD_RPM_MAX_SIZE 256
> +
And this has nothing to do with SMD, it's a limitation of RPM.
Regards,
Bjorn
^ permalink raw reply
* [PATCH 0/2] ARM: dts: sun6i: Disable display pipeline by default
From: Chen-Yu Tsai @ 2016-11-24 6:43 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Hi,
While we now support the internal display pipeline found on sun6i, it
is possible that we are unable to enable the display for some boards,
due to a lack of drivers for the panels or bridges found on them. If
the display pipeline is enabled, the driver will try to enable, and
possibly screw up the simple framebuffer U-boot had configured.
This series disables the display pipeline by default, and re-enables
it for the A31 Hummingbird, which already had its display pipeline
enabled.
The series can go in after 4.10-rc1, as a fix, but should not be delayed
till the next release.
Regards
ChenYu
Chen-Yu Tsai (2):
ARM: dts: sun6i: Disable display pipeline by default
ARM: dts: sun6i: hummingbird: Enable display engine again
arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 4 ++++
arch/arm/boot/dts/sun6i-a31.dtsi | 1 +
2 files changed, 5 insertions(+)
--
2.10.2
^ permalink raw reply
* [PATCH 1/2] ARM: dts: sun6i: Disable display pipeline by default
From: Chen-Yu Tsai @ 2016-11-24 6:43 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20161124064339.12615-1-wens-jdAy2FN1RRM@public.gmane.org>
While we now support the internal display pipeline found on sun6i, it
is possible that we are unable to enable the display for some boards,
due to a lack of drivers for the panels or bridges found on them. If
the display pipeline is enabled, the driver will try to enable, and
possibly screw up the simple framebuffer U-boot had configured.
Disable the display pipeline by default.
Fixes: 6d0e5b70be13 ("ARM: dts: sun6i: Add device nodes for first
display pipeline")
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
arch/arm/boot/dts/sun6i-a31.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 20a0331ddfb5..4662d3344cd2 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -234,6 +234,7 @@
de: display-engine {
compatible = "allwinner,sun6i-a31-display-engine";
allwinner,pipelines = <&fe0>;
+ status = "disabled";
};
soc@01c00000 {
--
2.10.2
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: sun6i: hummingbird: Enable display engine again
From: Chen-Yu Tsai @ 2016-11-24 6:43 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20161124064339.12615-1-wens-jdAy2FN1RRM@public.gmane.org>
Now that we disable the display engine by default, we need to re-enable
it for the Hummingbird A31, which already had its display pipeline
enabled.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
index b168d6df2b30..83643bbd51dc 100644
--- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
+++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
@@ -140,6 +140,10 @@
cpu-supply = <®_dcdc3>;
};
+&de {
+ status = "okay";
+};
+
&ehci0 {
status = "okay";
};
--
2.10.2
^ permalink raw reply related
* RE: [PATCH][v2] arm64: Add DTS support for FSL's LS1012A SoC
From: Yao Yuan @ 2016-11-24 7:18 UTC (permalink / raw)
To: shawnguo@kernel.org, robh+dt@kernel.org, mark.rutland@arm.com
Cc: oss@buserror.net, Harninder Rai, Bhaskar U,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
In-Reply-To: <1479320647-24460-1-git-send-email-harninder.rai@nxp.com>
Hi Shawn and All,
Any comment for this LS1012A platform support patch?
Is this a good enough base for consequence dts update patches?
If yes, I'd like to send some dts patches for DSPI and QSPI based on this patch.
Thanks.
Yao
On 11/17/2016 02:24 AM, Harninder Rai wrote:
> LS1012A features an advanced 64-bit ARM v8 CortexA53 processor with 32 KB
> of parity protected L1-I cache, 32 KB of ECC protected L1-D cache, as well as 256
> KB of ECC protected L2 cache.
>
> Features summary
> One 64-bit ARM-v8 Cortex-A53 core with the following capabilities
> - Arranged as a cluster of one core supporting a 256 KB L2 cache with ECC
> protection
> - Speed up to 800 MHz
> - Parity-protected 32 KB L1 instruction cache and 32 KB L1 data cache
> - Neon SIMD engine
> - ARM v8 cryptography extensions
> One 16-bit DDR3L SDRAM memory controller ARM core-link CCI-400 cache
> coherent interconnect Cryptography acceleration (SEC) One Configurable x3
> SerDes One PCI Express Gen2 controller, supporting x1 operation One serial
> ATA (SATA Gen 3.0) controller One USB 3.0/2.0 controller with integrated PHY
>
> Following levels of DTSI/DTS files have been created for the LS1012A
> SoC family:
>
> - fsl-ls1012a.dtsi:
> DTS-Include file for FSL LS1012A SoC.
>
> - fsl-ls1012a-frdm.dts:
> DTS file for FSL LS1012A FRDM board.
>
> - fsl-ls1012a-qds.dts:
> DTS file for FSL LS1012A QDS board.
>
> - fsl-ls1012a-rdb.dts:
> DTS file for FSL LS1012A RDB board.
>
> Signed-off-by: Harninder Rai <harninder.rai@nxp.com>
> Signed-off-by: Bhaskar Upadhaya <Bhaskar.Upadhaya@nxp.com>
> ---
> Changes in v2: Incorporated Shawn's comments
> - Brief introduction of the SoC in commit message
> - Alphabetic ordering of labeled nodes
> - Better naming to be used for regulator node
> - Make timer node's comments more readable
> - Sort nodes with unit-address in order of the address
>
> arch/arm64/boot/dts/freescale/Makefile | 3 +
> arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts | 115 ++++++++++
> arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts | 128 +++++++++++
> arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts | 59 +++++
> arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 245
> +++++++++++++++++++++
> 5 files changed, 550 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
>
^ permalink raw reply
* Re: [RFC PATCH] ARM: dts: Add support for Turris Omnia
From: Uwe Kleine-König @ 2016-11-24 8:37 UTC (permalink / raw)
To: Andrew Lunn, Tomas Hlavacek
Cc: Rob Herring, Mark Rutland, Russell King, Jason Cooper,
Gregory Clement, Sebastian Hesselbarth, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20161123003505.GL2691@lunn.ch>
[-- Attachment #1.1: Type: text/plain, Size: 1525 bytes --]
On 11/23/2016 01:35 AM, Andrew Lunn wrote:
>> +++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
>> @@ -0,0 +1,279 @@
>> +/*
>> + * Device Tree file for the Turris Omnia
>> + * Schematic available at https://www.turris.cz/doc/_media/rtrom01-schema.pdf
>
> Cool that there is a link to the schematics. But please could you put
> it lower down. It is more likely to be seen if it comes after the
> copyright and license section.
I added to the top because that's where I would look. But checking other
dts files it seems indeed to be more common after the copyright stuff.
I'd suggest to even start a new comment (i.e.
* last blabla of copyright
*/
/*
* Schematic available at ...
) to be more "loud".
@Tomas: I think it doesn't make sense when we alternate sending patches
without prior arrangement. Do you already work on a v5? If not I can do
that to fix the last few comments. Not sure when a submission is too
late to enter v4.10, but I think the window isn't that big any more.
> No leds? No buttons via gpio-keys?
The leds are controlled by a Cortex-M0 and without intervention blink
according to a hardware function (network, power, pci). IMHO that's ok
for an initial setup.
And there are no buttons that are routed to the Armada CPU. Just a reset
button (well, ok, this one is routed to the Armada CPU, but you cannot
make this a gpio-key :-) and the other button is used to control the
brightness of the LEDs and is only routed to the M0.
Best regards
Uwe
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH V4 0/2] pinctrl: tegra: Add support for IO pad control
From: Laxman Dewangan @ 2016-11-24 8:38 UTC (permalink / raw)
To: linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
swarren-3lzwWm7+Weoh9ZMKESR00Q,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
gnurou-Re5JQEeQqe8AvxtiuMwx3w, jonathanh-DDmLM1+adcrQT0dZR+AlfA,
joe-6d6DIl74uiNBDgjK7y7TUQ
Cc: yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Laxman Dewangan
NVIDIA Tegra124 and later SoCs support the multi-voltage level and
low power state of some of its IO pads. The IO pads can work in
the voltage of the 1.8V and 3.3V of IO power rail sources. When IO
interface are not used then IO pads can be configure in low power
state to reduce the power from that IO pads.
This series add the support of configuration of IO pad via pinctrl
framework. The io pad driver uses the tegra PMC interface.
---
This driver was sent earlier for review along with soc/tegra pmc
changes. During review, decided to first conclude in soc/tegra pmc
patches and then review this.
Thierry applied the pmc patches in the private tree
https://github.com/thierryreding/linux/tree/tegra186
and he wanted to have the patches for user of the new APIs so that
it can be pushed to mainline.
Sending the pinctrl driver. This needs Ack/reviewed from pinctrl subsystem
i.e. Linus Welleij to apply in the Thierry's T186 branch along with
PMC patches.
---
Changes from V1:
- use the regulator framework to get the IO voltage instead of table from
DT. The regulator handle is provided from DT.
Changes from V2:
- Nit fixes and variable/allocation optimisation as per review comment from
V2.
Changes from V3:
Use devm_regulator_get() instead of devm_regulator_get_optional().
Laxman Dewangan (2):
pinctrl: tegra: Add DT binding for io pads control
pinctrl: tegra: Add driver to configure voltage and power of io pads
.../bindings/pinctrl/nvidia,tegra-io-pad.txt | 126 +++++
drivers/pinctrl/tegra/Kconfig | 12 +
drivers/pinctrl/tegra/Makefile | 1 +
drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c | 530 +++++++++++++++++++++
4 files changed, 669 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pinctrl/nvidia,tegra-io-pad.txt
create mode 100644 drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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