* Re: [PATCH v5 15/15] devicetree: bindings: Document qcom,pvs
From: Viresh Kumar @ 2017-12-20 6:27 UTC (permalink / raw)
To: Sricharan R
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
mturquette-rdvid1DuHRBWk0Htik3J/w, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, andy.gross-QSEj5FYQhm4dnm+yROfE0A,
david.brown-QSEj5FYQhm4dnm+yROfE0A, rjw-LthD3rsA81gm4RdzfppkhA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA, linux-pm-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <b0d8147a-46e1-0787-ae37-9c1ef957d190-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On 20-12-17, 11:55, Sricharan R wrote:
> >> + opp-1400000000 {
> >> + opp-hz = /bits/ 64 <1400000000>;
> >> + opp-microvolt-speed0-pvs0-v0 = <1250000>;
> >
> > Why speed0 and v0 in all the names ?
> >
>
> Ya, all the three (speed, pvs and version) are read from efuse. So all the three
> can vary.
Okay, so may be in the example you should have a mix of all the
combinations to show how these things work ? You only showed values
for a single efuse configuration currently.
--
viresh
--
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 v5 15/15] devicetree: bindings: Document qcom,pvs
From: Sricharan R @ 2017-12-20 6:41 UTC (permalink / raw)
To: Viresh Kumar
Cc: robh+dt, mark.rutland, mturquette, sboyd, linux, andy.gross,
david.brown, rjw, linux-arm-kernel, devicetree, linux-kernel,
linux-clk, linux-arm-msm, linux-soc, linux-pm
In-Reply-To: <20171220062712.GV19815@vireshk-i7>
Hi Viresh,
On 12/20/2017 11:57 AM, Viresh Kumar wrote:
> On 20-12-17, 11:55, Sricharan R wrote:
>>>> + opp-1400000000 {
>>>> + opp-hz = /bits/ 64 <1400000000>;
>>>> + opp-microvolt-speed0-pvs0-v0 = <1250000>;
>>>
>>> Why speed0 and v0 in all the names ?
>>>
>>
>> Ya, all the three (speed, pvs and version) are read from efuse. So all the three
>> can vary.
>
> Okay, so may be in the example you should have a mix of all the
> combinations to show how these things work ? You only showed values
> for a single efuse configuration currently.
>
Ha ok. Will add other examples as well.
Regards,
Sricharan
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH v3 18/20] ARM: dts: aspeed-romulus: Update Romulus system
From: Cédric Le Goater @ 2017-12-20 6:44 UTC (permalink / raw)
To: Joel Stanley, Rob Herring, Mark Rutland, Arnd Bergmann,
Andrew Jeffery, Patrick Venture, Xo Wang, Lei YU
Cc: devicetree, linux-aspeed, Benjamin Herrenschmidt, linux-kernel,
Jeremy Kerr, linux-arm-kernel
In-Reply-To: <20171220032328.30584-19-joel@jms.id.au>
On 12/20/2017 04:23 AM, Joel Stanley wrote:
> - Fix incorrect RAM size
> - Remove alias; these are now specified in the dtsi
> - Add newly upstreamed devices
> - Include OpenBMC flash layout
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
> ---
> v3:
> - Add GPIO include
> - Fix duplicate fmc and spi nodes
> - Add unit name for memory node to fix warning
> ---
> arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 133 +++++++++++++++++++++++++--
> 1 file changed, 126 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> index a7a9386f964d..623b6ab42021 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> @@ -1,23 +1,19 @@
> // SPDX-License-Identifier: GPL-2.0+
> /dts-v1/;
> -
> #include "aspeed-g5.dtsi"
> +#include <dt-bindings/gpio/aspeed-gpio.h>
>
> / {
> model = "Romulus BMC";
> compatible = "ibm,romulus-bmc", "aspeed,ast2500";
>
> - aliases {
> - serial4 = &uart5;
> - };
> -
> chosen {
> stdout-path = &uart5;
> bootargs = "console=ttyS4,115200 earlyprintk";
> };
>
> - memory {
> - reg = <0x80000000 0x40000000>;
> + memory@80000000 {
> + reg = <0x80000000 0x20000000>;
> };
>
> reserved-memory {
> @@ -29,6 +25,49 @@
> no-map;
> reg = <0xbf000000 0x01000000>; /* 16M */
> };
> +
> + flash_memory: region@98000000 {
> + no-map;
> + reg = <0x98000000 0x04000000>; /* 64M */
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + fault {
> + gpios = <&gpio ASPEED_GPIO(N, 2) GPIO_ACTIVE_LOW>;
> + };
> +
> + identify {
> + gpios = <&gpio ASPEED_GPIO(N, 4) GPIO_ACTIVE_HIGH>;
> + };
> +
> + power {
> + gpios = <&gpio ASPEED_GPIO(R, 5) GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + fsi: gpio-fsi {
> + compatible = "fsi-master-gpio", "fsi-master";
> + #address-cells = <2>;
> + #size-cells = <0>;
> +
> + clock-gpios = <&gpio ASPEED_GPIO(AA, 0) GPIO_ACTIVE_HIGH>;
> + data-gpios = <&gpio ASPEED_GPIO(AA, 2) GPIO_ACTIVE_HIGH>;
> + mux-gpios = <&gpio ASPEED_GPIO(A, 6) GPIO_ACTIVE_HIGH>;
> + enable-gpios = <&gpio ASPEED_GPIO(D, 0) GPIO_ACTIVE_HIGH>;
> + trans-gpios = <&gpio ASPEED_GPIO(R, 2) GPIO_ACTIVE_HIGH>;
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + checkstop {
> + label = "checkstop";
> + gpios = <&gpio ASPEED_GPIO(J, 2) GPIO_ACTIVE_LOW>;
> + linux,code = <ASPEED_GPIO(J, 2)>;
> + };
> };
> };
>
> @@ -38,6 +77,7 @@
> status = "okay";
> m25p,fast-read;
> label = "bmc";
> +#include "openbmc-flash-layout.dtsi"
> };
> };
>
> @@ -53,6 +93,12 @@
> };
> };
>
> +&lpc_ctrl {
> + status = "okay";
> + memory-region = <&flash_memory>;
> + flash = <&spi1>;
> +};
> +
> &uart1 {
> /* Rear RS-232 connector */
> status = "okay";
> @@ -81,6 +127,10 @@
> pinctrl-0 = <&pinctrl_rmii1_default>;
> };
>
> +&i2c1 {
> + status = "okay";
> +};
> +
> &i2c2 {
> status = "okay";
> };
> @@ -133,8 +183,77 @@
>
> &i2c12 {
> status = "okay";
> +
> + max31785@52 {
> + compatible = "maxim,max31785";
> + reg = <0x52>;
> + };
> +};
> +
> +&gpio {
> + nic_func_mode0 {
> + gpio-hog;
> + gpios = <ASPEED_GPIO(D, 3) GPIO_ACTIVE_HIGH>;
> + output-low;
> + line-name = "nic_func_mode0";
> + };
> + nic_func_mode1 {
> + gpio-hog;
> + gpios = <ASPEED_GPIO(D, 4) GPIO_ACTIVE_HIGH>;
> + output-low;
> + line-name = "nic_func_mode1";
> + };
> };
>
> &vuart {
> status = "okay";
> };
> +
> +&gfx {
> + status = "okay";
> +};
> +
> +&pinctrl {
> + aspeed,external-nodes = <&gfx &lhc>;
> +};
> +
> +&pwm_tacho {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm0_default &pinctrl_pwm1_default>;
> +
> + fan@0 {
> + reg = <0x00>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x08>;
> + };
> +
> + fan@1 {
> + reg = <0x00>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x09>;
> + };
> +
> + fan@2 {
> + reg = <0x01>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x0a>;
> + };
> +
> + fan@3 {
> + reg = <0x01>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x0b>;
> + };
> +
> + fan@4 {
> + reg = <0x00>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x0c>;
> + };
> +
> + fan@5 {
> + reg = <0x00>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x0d>;
> + };
> +
> + fan@6 {
> + reg = <0x01>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x0e>;
> + };
> +};
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: Remove leading 0x and 0s from bindings notation
From: Andy Gross @ 2017-12-20 6:49 UTC (permalink / raw)
To: Mathieu Malaterre
Cc: Rob Herring, Wei Xu, Mark Rutland, Catalin Marinas, Will Deacon,
Matthias Brugger, David Brown, Kees Cook, Anton Vorontsov,
Colin Cross, Tony Luck,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171214165352.27902-1-malat-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
On Thu, Dec 14, 2017 at 05:53:52PM +0100, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
>
> Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
>
> and
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -E -i -e "s/@0x([0-9a-fA-F\.]+)\s?\{/@\L\1 \{/g" -e "s/@0+([0-9a-fA-F\.]+)\s?\{/@\L\1 \{/g" {} +
>
> For simplicity, two sed expressions were used to solve each warnings separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://elinux.org/Device_Tree_Linux#Linux_conventions
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
>
> Reported-by: David Daney <ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
> Suggested-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Mathieu Malaterre <malat-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
Acked-by: Andy Gross <andy.gross-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
--
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 2/2] pinctrl: Allow indicating loss of pin states during low-power
From: Linus Walleij @ 2017-12-20 7:24 UTC (permalink / raw)
To: Florian Fainelli
Cc: Tony Lindgren, linux-gpio-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Charles Keepax, Charles Keepax, Stephen Warren,
Andy Shevchenko, Al Cooper, bcm-kernel-feedback-list
In-Reply-To: <908c66f9-f9bd-a4df-e241-75595a3a3e27-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Mon, Dec 11, 2017 at 12:38 AM, Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 12/02/2017 04:48 AM, Linus Walleij wrote:
>> This should solve your problem without having to alter the semantics
>> of pinctrl_select_state() for everyone.
>
> This was exactly what I proposed initially here:
>
> http://patchwork.ozlabs.org/patch/734326/
>
> I really want to get this fixed, but I can't do that if we keep losing
> the context of the discussion (pun intended) :).
Oh sorry man. I am clearly too stupid for this job...
In accordance with things needing to be intuitive, something named
*force_* should of course force the setting into the hardware.
The original patch didn't mention the fact that it was hogs
and hogs only that was causing the trouble and that is why I
got lost. (I guess.) I have been going about this as if it was
something generic that affect all states in all devices, and to
me hogs is just an abscure corner of pin controlling...
I applied the patchwork patch from above, and elaborated
a bit on that it pertains to hogs, let's see what
happens.
For the case where a driver (not hog) needs to handle
suspend/resume transitions, proper states can hopefully
be used.
Yours,
Linus Walleij
--
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/9] devicetree: bindings: Document supported STM32 SoC family
From: Linus Walleij @ 2017-12-20 7:33 UTC (permalink / raw)
To: Ludovic Barre
Cc: Russell King, Rob Herring, Arnd Bergmann, Maxime Coquelin,
Alexandre Torgue, Gerald Baeza, Linux ARM,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Gwenael Treuveur
In-Reply-To: <1513610272-7824-2-git-send-email-ludovic.Barre-qxv4g6HH51o@public.gmane.org>
On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre <ludovic.Barre-qxv4g6HH51o@public.gmane.org> wrote:
> From: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
>
> This adds a list of supported STM32 SoC bindings.
>
> Signed-off-by: Gwenael Treuveur <gwenael.treuveur-qxv4g6HH51o@public.gmane.org>
> Signed-off-by: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
> Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Patch applied.
Yours,
Linus Walleij
--
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 6/9] pinctrl: stm32: Add STM32MP157 MPU support
From: Linus Walleij @ 2017-12-20 7:38 UTC (permalink / raw)
To: Ludovic Barre
Cc: Russell King, Rob Herring, Arnd Bergmann, Maxime Coquelin,
Alexandre Torgue, Gerald Baeza, Linux ARM,
linux-kernel@vger.kernel.org,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <1513610272-7824-7-git-send-email-ludovic.Barre@st.com>
On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre <ludovic.Barre@st.com> wrote:
> From: Ludovic Barre <ludovic.barre@st.com>
>
> This driver consists of 2 controllers due to a hole in mapping:
> -1 controller for GPIO bankA to K.
> -1 controller for GPIO bankZ.
>
> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH V2 9/9] ARM: dts: stm32: add initial support of stm32mp157c eval board
From: Linus Walleij @ 2017-12-20 7:44 UTC (permalink / raw)
To: Ludovic Barre
Cc: Russell King, Rob Herring, Arnd Bergmann, Maxime Coquelin,
Alexandre Torgue, Gerald Baeza, Linux ARM,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <1513610272-7824-10-git-send-email-ludovic.Barre-qxv4g6HH51o@public.gmane.org>
On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre <ludovic.Barre-qxv4g6HH51o@public.gmane.org> wrote:
> From: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
>
> Add support of stm32mp157c evaluation board (part number: STM32MP157C-EV1)
> split in 2 elements:
> -Daughter board (part number: STM32MP157C-ED1)
> which includes CPU, memory and power supply
> -Mother board (part number: STM32MP157C-EM1)
> which includes external peripherals (like display, camera,...)
> and extension connectors.
>
> The daughter board can run alone, this is why the device tree files
> are split in two layers, for the complete evaluation board (ev1)
> and for the daughter board alone (ed1).
>
> Signed-off-by: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
> Signed-off-by: Alexandre Torgue <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
(...)
> diff --git a/arch/arm/boot/dts/stm32mp157c-ev1.dts b/arch/arm/boot/dts/stm32mp157c-ev1.dts
Evaluation boards are important because they set a pattern that customers
will use.
Please consider to include nodes for all GPIO blocks used in this
evaluation board, and add:
gpio-line-names = "foo", "bar" ...;
See for example
arch/arm/boot/dts/bcm2835-rpi-a.dts
arch/arm/boot/dts/ste-snowball.dts
It's good to have because probably you guys have proper schematics and
know rail names of the stuff connected to those GPIO lines and so on,
so you can give the lines proper names.
It will be helpful for people using the reference design, especially with the
new character device, and also sets a pattern for people doing devices
based on the reference design and we really want to do that.
Yours,
Linus Walleij
--
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/4] dt-bindings: pinctrl: add bindings for MediaTek MT7622 SoC
From: Linus Walleij @ 2017-12-20 7:47 UTC (permalink / raw)
To: sean.wang
Cc: Rob Herring, Mark Rutland, Matthias Brugger,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/Mediatek SoC support, Linux ARM, linux-gpio,
linux-kernel@vger.kernel.org
In-Reply-To: <eb93acdb07a0205e9d3089058b45aee1a6c04d50.1513059081.git.sean.wang@mediatek.com>
On Tue, Dec 12, 2017 at 7:24 AM, <sean.wang@mediatek.com> wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> Add devicetree bindings for MediaTek MT7622 pinctrl driver.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> Reviewed-by: Biao Huang <biao.huang@mediatek.com>
Patch applied with Rob's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 2/4] pinctrl: mediatek: cleanup for placing all drivers under the menu
From: Linus Walleij @ 2017-12-20 7:48 UTC (permalink / raw)
To: sean.wang-NuS5LvNUpcJWk0Htik3J/w
Cc: Rob Herring, Mark Rutland, Matthias Brugger,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/Mediatek SoC support, Linux ARM,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <fc13c7249505784c1f89a2e0775bb9a75cd38c3f.1513059081.git.sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On Tue, Dec 12, 2017 at 7:24 AM, <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
> From: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>
> Since lots of MediaTek drivers had been added, it seems slightly better
> for that adding cleanup for placing MediaTek pinctrl drivers under the
> independent menu as other kinds of drivers usually was done.
>
> Signed-off-by: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> Reviewed-by: Biao Huang <biao.huang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Patch applied. Also very nice!
Yours,
Linus Walleij
--
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 3/4] pinctrl: mediatek: add pinctrl driver for MT7622 SoC
From: Linus Walleij @ 2017-12-20 7:58 UTC (permalink / raw)
To: sean.wang-NuS5LvNUpcJWk0Htik3J/w
Cc: Rob Herring, Mark Rutland, Matthias Brugger,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/Mediatek SoC support, Linux ARM,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <5b42c51c965fb2824646630dd93d3d531610e344.1513059081.git.sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On Tue, Dec 12, 2017 at 7:24 AM, <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
> From: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>
> Add support for pinctrl on MT7622 SoC. The IO core found on the SoC has
> the registers for pinctrl, pinconf and gpio mixed up in the same register
> range. However, the IO core for the MT7622 SoC is completely distinct from
> anyone of previous MediaTek SoCs which already had support, such as
> the hardware internal, register address map and register detailed
> definition for each pin.
>
> Therefore, instead, the driver is being newly implemented by reusing
> generic methods provided from the core layer with GENERIC_PINCONF,
> GENERIC_PINCTRL_GROUPS, and GENERIC_PINMUX_FUNCTIONS for the sake of code
> simplicity and rid of superfluous code. Where the function of pins
> determined by groups is utilized in this driver which can help developers
> less confused with what combinations of pins effective on the SoC and even
> reducing the mistakes during the integration of those relevant boards.
>
> As the gpio_chip handling is also only a few lines, the driver also
> implements the gpio functionality directly through GPIOLIB.
>
> Signed-off-by: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> Reviewed-by: Biao Huang <biao.huang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Patch applied. Very nice work!
As I've seen visiting Asia how popular MTK chips are for all kinds
of devices it's really nice to have proper upstream support directly from
Mediatek on these chips. You guys are awesome.
Some suggestions for improvements:
> +static void mtk_w32(struct mtk_pinctrl *pctl, u32 reg, u32 val)
> +{
> + writel_relaxed(val, pctl->base + reg);
> +}
> +
> +static u32 mtk_r32(struct mtk_pinctrl *pctl, u32 reg)
> +{
> + return readl_relaxed(pctl->base + reg);
> +}
> +
> +static void mtk_rmw(struct mtk_pinctrl *pctl, u32 reg, u32 mask, u32 set)
> +{
> + u32 val;
> +
> + val = mtk_r32(pctl, reg);
> + val &= ~mask;
> + val |= set;
> + mtk_w32(pctl, reg, val);
> +}
Have you considered replacing this with regmap-mmio? It does pretty much
the same thing. It could be an improvemet reducing code a bit and making
it more generic. The error codes from eg regmap_update_bits() can be
safely ignored on MMIO maps.
> +static int mtk_build_gpiochip(struct mtk_pinctrl *hw, struct device_node *np)
> +{
> + struct gpio_chip *chip = &hw->chip;
> + int ret;
> +
> + chip->label = PINCTRL_PINCTRL_DEV;
> + chip->parent = hw->dev;
> + chip->request = gpiochip_generic_request;
> + chip->free = gpiochip_generic_free;
> + chip->direction_input = mtk_gpio_direction_input;
> + chip->direction_output = mtk_gpio_direction_output;
Please submit a patch implementing chip->get_direction(), it
is really helpful, especially for debugging.
If your pin controller later adds support for things that can be
used from the GPIO side, like open drain or debounce, then
please consider at that point to also implement
chip->set_config() in the gpio_chip. That way your GPIO consumers
can use e.g. open drain through pin control as back-end.
See drivers/pinctrl/intel/pinctrl-intel.c for an example.
Yours,
Linus Walleij
--
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 4/4] pinctrl: mediatek: update MAINTAINERS entry with MediaTek pinctrl driver
From: Linus Walleij @ 2017-12-20 7:59 UTC (permalink / raw)
To: sean.wang
Cc: Rob Herring, Mark Rutland, Matthias Brugger,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/Mediatek SoC support, Linux ARM, linux-gpio,
linux-kernel@vger.kernel.org
In-Reply-To: <d41feb63ea2ebbfe58f5940ff27b031dd8024b28.1513059082.git.sean.wang@mediatek.com>
On Tue, Dec 12, 2017 at 7:24 AM, <sean.wang@mediatek.com> wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> I work for MediaTek on maintaining the existing MediaTek SoC whose target
> to home gateway such as MT7622 and MT7623 that is reusing MT2701 related
> files and will keep adding support for the following such kinds of SoCs
> in the future.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> Reviewed-by: Biao Huang <biao.huang@mediatek.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCHv2 1/3] dt-bindings: net: Add DT bindings for Socionext Netsec
From: Jassi Brar @ 2017-12-20 8:02 UTC (permalink / raw)
To: Mark Rutland
Cc: <netdev@vger.kernel.org>, Devicetree List, David S . Miller,
Arnd Bergmann, Ard Biesheuvel, Rob Herring, Jassi Brar,
Masami Hiramatsu
In-Reply-To: <20171212172919.ezd54qqcyk6fh5kq@lakrids.cambridge.arm.com>
Hi Mark,
On Tue, Dec 12, 2017 at 10:59 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> Hi,
>
> On Tue, Dec 12, 2017 at 10:45:21PM +0530, jassisinghbrar@gmail.com wrote:
>> From: Jassi Brar <jassisinghbrar@gmail.com>
>>
>> This patch adds documentation for Device-Tree bindings for the
>> Socionext NetSec Controller driver.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
>> ---
>> .../devicetree/bindings/net/socionext-netsec.txt | 43 ++++++++++++++++++++++
>> 1 file changed, 43 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/net/socionext-netsec.txt
>>
>> diff --git a/Documentation/devicetree/bindings/net/socionext-netsec.txt b/Documentation/devicetree/bindings/net/socionext-netsec.txt
>> new file mode 100644
>> index 0000000..4695969
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/socionext-netsec.txt
>> @@ -0,0 +1,45 @@
>> +* Socionext NetSec Ethernet Controller IP
>> +
>> +Required properties:
>> +- compatible: Should be "socionext,synquacer-netsec"
>> +- reg: Address and length of the control register area, followed by the
>> + address and length of the EEPROM holding the MAC address and
>> + microengine firmware
>> +- interrupts: Should contain ethernet controller interrupt
>> +- clocks: phandle to the PHY reference clock, and any other clocks to be
>> + switched by runtime_pm
>> +- clock-names: Required only if more than a single clock is listed in 'clocks'.
>> + The PHY reference clock must be named 'phy_refclk'
>
> Please define the full set of clocks (and their names) explicitly. This
> should be well-known.
>
The issue is some implementations have just the 'rate-reference' clock
going in, while others may also have 1or2 optional 'enable' clocks
(which may go to other devices as well).
The driver only needs to know which clock to read the freq from, so it
expects that clock to be named 'phy_refclk', while the 'enable' clocks
can be named anything.
Thanks
^ permalink raw reply
* Re: [PATCH v4 4/4] ARM: pinctrl: sunxi-pinctrl: fix pin funtion can not be match correctly.
From: Linus Walleij @ 2017-12-20 8:05 UTC (permalink / raw)
To: hao_zhang
Cc: thierry.reding@gmail.com, Rob Herring, Mark Rutland, Russell King,
Chen-Yu Tsai, Maxime Ripard, linux-kernel@vger.kernel.org,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, linux-pwm, open list:ARM/Amlogic Meson...
In-Reply-To: <20171213144748.GA18267@arx-s1>
On Wed, Dec 13, 2017 at 3:47 PM, hao_zhang <hao5781286@gmail.com> wrote:
> Pin function can not be match correctly when SUNXI_PIN describe with
> mutiple variant and same function.
>
> such as:
> on pinctrl-sun4i-a10.c
>
> SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 2),
> SUNXI_FUNCTION(0x0, "gpio_in"),
> SUNXI_FUNCTION(0x1, "gpio_out"),
> SUNXI_FUNCTION_VARIANT(0x2, "pwm", /* PWM0 */
> PINCTRL_SUN4I_A10 |
> PINCTRL_SUN7I_A20),
> SUNXI_FUNCTION_VARIANT(0x3, "pwm", /* PWM0 */
> PINCTRL_SUN8I_R40)),
>
> it would always match to the first variant function
> (PINCTRL_SUN4I_A10, PINCTRL_SUN7I_A20)
>
> so we should add variant compare on it.
>
> Signed-off-by: hao_zhang <hao5781286@gmail.com>
Please resend patch with Maxime's suggestions fixed and his
ACK added so I can apply it.
I can take this patch separatelt, it does not need to be part of
the PWM series.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCHv2 1/3] dt-bindings: net: Add DT bindings for Socionext Netsec
From: Jassi Brar @ 2017-12-20 8:06 UTC (permalink / raw)
To: Andrew Lunn
Cc: Jassi Brar, netdev, Devicetree List, David S. Miller,
Arnd Bergmann, Ard Biesheuvel, Rob Herring, Mark Rutland
In-Reply-To: <20171212203752.GB1523@lunn.ch>
On 13 December 2017 at 02:07, Andrew Lunn <andrew@lunn.ch> wrote:
> On Tue, Dec 12, 2017 at 10:45:21PM +0530, jassisinghbrar@gmail.com wrote:
>> From: Jassi Brar <jassisinghbrar@gmail.com>
>>
>> This patch adds documentation for Device-Tree bindings for the
>> Socionext NetSec Controller driver.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
>> ---
>> .../devicetree/bindings/net/socionext-netsec.txt | 43 ++++++++++++++++++++++
>> 1 file changed, 43 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/net/socionext-netsec.txt
>>
>> diff --git a/Documentation/devicetree/bindings/net/socionext-netsec.txt b/Documentation/devicetree/bindings/net/socionext-netsec.txt
>> new file mode 100644
>> index 0000000..4695969
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/socionext-netsec.txt
>> @@ -0,0 +1,45 @@
>> +* Socionext NetSec Ethernet Controller IP
>> +
>> +Required properties:
>> +- compatible: Should be "socionext,synquacer-netsec"
>> +- reg: Address and length of the control register area, followed by the
>> + address and length of the EEPROM holding the MAC address and
>> + microengine firmware
>> +- interrupts: Should contain ethernet controller interrupt
>> +- clocks: phandle to the PHY reference clock, and any other clocks to be
>> + switched by runtime_pm
>> +- clock-names: Required only if more than a single clock is listed in 'clocks'.
>> + The PHY reference clock must be named 'phy_refclk'
>> +- phy-mode: See ethernet.txt file in the same directory
>> +- phy-handle: phandle to select child phy
>> +
>> +Optional properties: (See ethernet.txt file in the same directory)
>> +- dma-coherent: Boolean property, must only be present if memory
>> + accesses performed by the device are cache coherent
>> +- local-mac-address
>> +- mac-address
>> +- max-speed
>> +- max-frame-size
>> +
>> +Required properties for the child phy:
>> +- reg: phy address
>
> Hi Jassi
>
> Just reference phy.txt
>
>> +
>> +Example:
>> + eth0: netsec@522D0000 {
>> + compatible = "socionext,synquacer-netsec";
>> + reg = <0 0x522D0000 0x0 0x10000>, <0 0x10000000 0x0 0x10000>;
>> + interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
>> + clocks = <&clk_netsec>;
>> + phy-mode = "rgmii";
>> + max-speed = <1000>;
>> + max-frame-size = <9000>;
>> + phy-handle = <ðphy0>;
>> +
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>
> Please add an mdio node here, and list all the phys and possibly
> Ethernet switches as children of it.
>
OK. Though in order to avoid breaking dtbs in the wild already, the
driver falls back on using the parent node if no mdio subnode is
found.
Thank you.
^ permalink raw reply
* Re: [PATCH] of: build dbts with symbols when CONFIG_OF_OVERLAY is set
From: Andre Heider @ 2017-12-20 8:08 UTC (permalink / raw)
To: Frank Rowand, Rob Herring, Masahiro Yamada, Michal Marek
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-kbuild-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <0468b711-ba39-98d8-5bbe-0246a98db863-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 18/12/17 23:10, Frank Rowand wrote:
> On 12/16/17 09:25, Andre Heider wrote:
>> Hi Frank,
>>
>> On 15/12/17 22:06, Frank Rowand wrote:
>>> On 12/14/17 07:12, Andre Heider wrote:
>>>> The overlay feature requires the base dtb to be built with symbols, so
>>>> lets build the dtbs with symbols when overlay support was explicitly
>>>> enabled.
>>>>
>>>> With CONFIG_OF_ALL_DTBS on ARCH=arm the 989 dtb files grow about ~38% on
>>>> average.
>>>>
>>>> Totals in bytes with the 3 biggest ones:
>>>>
>>>> Before:
>>>> 90471 arch/arm/boot/dts/am57xx-beagle-x15-revc.dtb
>>>> 90521 arch/arm/boot/dts/am57xx-beagle-x15-revb1.dtb
>>>> 92639 arch/arm/boot/dts/dra7-evm.dtb
>>>> 25731296 total
>>>>
>>>> After:
>>>> 133203 arch/arm/boot/dts/am57xx-beagle-x15-revc.dtb
>>>> 133237 arch/arm/boot/dts/am57xx-beagle-x15-revb1.dtb
>>>> 134545 arch/arm/boot/dts/dra7-evm.dtb
>>>> 35464440 total
>>>>
>>>> Signed-off-by: Andre Heider <a.heider-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>> ---
>>>>
>>>> Hi,
>>>>
>>>> while playing around with overlays I noticed that I needed to rebuilt
>>>> my distro's device trees because they didn't come with symbols.
>>>>
>>>> Is that for a reason, maybe the not so minor increase in size?
>>>
>>> Yes, size is the issue.
>>>
>>>
>>>>
>>>> Thanks,
>>>> Andre
>>>>
>>>> drivers/of/unittest-data/Makefile | 7 -------
>>>> scripts/Makefile.lib | 5 +++++
>>>> 2 files changed, 5 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/drivers/of/unittest-data/Makefile b/drivers/of/unittest-data/Makefile
>>>> index 32389acfa616..b65061013512 100644
>>>> --- a/drivers/of/unittest-data/Makefile
>>>> +++ b/drivers/of/unittest-data/Makefile
>>>> @@ -15,13 +15,6 @@ targets += overlay.dtb overlay.dtb.S
>>>> targets += overlay_bad_phandle.dtb overlay_bad_phandle.dtb.S
>>>> targets += overlay_bad_symbol.dtb overlay_bad_symbol.dtb.S
>>>> targets += overlay_base.dtb overlay_base.dtb.S
>>>> -
>>>> -# enable creation of __symbols__ node
>>>> -DTC_FLAGS_overlay := -@
>>>> -DTC_FLAGS_overlay_bad_phandle := -@
>>>> -DTC_FLAGS_overlay_bad_symbol := -@
>>>> -DTC_FLAGS_overlay_base := -@
>>>> -
>>>> endif
>>>> .PRECIOUS: \
>>>
>>> No. The unittests require these to be set unconditionally.
>>>
>>>
>>>> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
>>>> index 1ca4dcd2d500..c7ba4aa8a07a 100644
>>>> --- a/scripts/Makefile.lib
>>>> +++ b/scripts/Makefile.lib
>>>> @@ -278,6 +278,11 @@ DTC_FLAGS += -Wnode_name_chars_strict \
>>>> -Wproperty_name_chars_strict
>>>> endif
>>>> +ifeq ($(CONFIG_OF_OVERLAY),y)
>>>> +# enable creation of __symbols__ node
>>>> +DTC_FLAGS += -@
>>>> +endif
>>>> +
>>>> DTC_FLAGS += $(DTC_FLAGS_$(basetarget))
>>>> # Generate an assembly file to wrap the output of the device tree compiler
>>>>
>>>
>>> Not needed. Instead set DTC_FLAGS in the make command. For example:
>>>
>>> DTC_FLAGS=-@ make qcom-apq8074-dragonboard.dtb
>>>
>>> There are a few architecture Makefiles that need to be fixed to not unconditionally
>>> set DTC_FLAGS.
>>
>> Rebuilding the dts files manually with symbols isn't the problem. The
>> idea was to enable it with a switch which distros simply can flip.
>>
>> Passing DTC_FLAGS to `make` would work too I guess, but on multi
>> platform builds that's still the same issue if there're boards which
>> can't handle that because of the size increase.
>>
>> Would a solution which enables symbols per family work? E.g.
>> CONFIG_MACH_SUN7I chooses to use -@ because it can handle it.
>>
>> Thanks,
>> Andre
>
> Making it easy for distros to increase the size of .dtb files is
> not the correct answer. We are trying to decrease the footprint
> of devicetree, not increase it.
I'm not sure I follow. If it's not acceptable to increase the size,
why's there overlay support in the first place?
There're distros/downstreams that support overlays today, like armbian,
beaglebone and rpi. All carrying their own patches to enable symbols [1]
[2] [3] and I'm sure others will follow. Why can't there be some sort of
switch for those to build their dtbs with symbols?
Regards,
Andre
[1]
https://github.com/armbian/build/blob/master/patch/kernel/sunxi-next/add-overlay-compilation-support.patch#L98
[2]
https://github.com/beagleboard/linux/commit/ed6b9450c2a2ec21149f14ff24770b69888abda6
[3]
https://github.com/raspberrypi/linux/blob/rpi-4.15.y/arch/arm/boot/dts/Makefile#L1124
--
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] dt-bindings: gpio: rcar: Correct SoC family name for R8A7778
From: Simon Horman @ 2017-12-20 8:12 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linus Walleij, Rob Herring, Mark Rutland, linux-gpio, devicetree,
linux-renesas-soc
In-Reply-To: <1513699422-27671-1-git-send-email-geert+renesas@glider.be>
On Tue, Dec 19, 2017 at 05:03:42PM +0100, Geert Uytterhoeven wrote:
> R8A7778 is R-Car (not R-Mobile) M1.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH] dt-bindings: pinctrl: sh-pfc: Correct SoC family name for R8A7778
From: Simon Horman @ 2017-12-20 8:12 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linus Walleij, Rob Herring, Mark Rutland, linux-gpio, devicetree,
linux-renesas-soc
In-Reply-To: <1513699496-27931-1-git-send-email-geert+renesas@glider.be>
On Tue, Dec 19, 2017 at 05:04:56PM +0100, Geert Uytterhoeven wrote:
> R8A7778 is R-Car (not R-Mobile) M1.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH 3/3] dt-bindings: pwm: renesas-tpu: Correct SoC part numbers and family names
From: Simon Horman @ 2017-12-20 8:13 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Thierry Reding, Rob Herring, Mark Rutland, Magnus Damm, linux-pwm,
devicetree, linux-renesas-soc
In-Reply-To: <1513699327-27357-4-git-send-email-geert+renesas@glider.be>
On Tue, Dec 19, 2017 at 05:02:07PM +0100, Geert Uytterhoeven wrote:
> R8A73A4 (not R8A77A4) is R-Mobile APE6,
> R8A7740 is R-Mobile (not R-Car) A1.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH 00/45] Migrate TCB bindings
From: Nicolas Ferre @ 2017-12-20 8:14 UTC (permalink / raw)
To: Alexandre Belloni
Cc: linux-arm-kernel, linux-kernel, Antoine Aubert, devicetree,
Douglas Gilbert, Fabio Porcedda, Gregory CLEMENT,
Joachim Eastwood, Marek Vasut, Martin Reimann, Peter Rosin,
Raashid Muhammed, Rob Herring, Rodolfo Giometti, Sergio Tanzilli,
Tim Schendekehl
In-Reply-To: <20171219213209.13823-1-alexandre.belloni@free-electrons.com>
On 19/12/2017 at 22:31, Alexandre Belloni wrote:
> Hi,
>
> As the bindings were acked by Rob a while ago [1] and I think there is
> consensus on what they look like, I'm planning to apply that series for
> 4.16 so we get a smoother transition for the TCB driver rework.
>
> I've simply removed the PWM binding change that I will submit with the
> driver change itself.
> There is also a small fix in the at91sam9261ek patch.
>
> [1] https://patchwork.kernel.org/patch/9755341/
>
> Cc: Antoine Aubert <a.aubert@overkiz.com>
> Cc: devicetree@vger.kernel.org
> Cc: Douglas Gilbert <dgilbert@interlog.com>
> Cc: Fabio Porcedda <fabio.porcedda@gmail.com>
> Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Cc: Joachim Eastwood <manabian@gmail.com>
> Cc: Marek Vasut <marex@denx.de>
> Cc: Martin Reimann <martin.reimann@egnite.de>
> Cc: Peter Rosin <peda@axentia.se>
> Cc: Raashid Muhammed <raashidmuhammed@zilogic.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Rodolfo Giometti <giometti@linux.it>
> Cc: Sergio Tanzilli <tanzilli@acmesystems.it>
> Cc: Tim Schendekehl <tim.schendekehl@egnite.de>
>
> Alexandre Belloni (45):
> ARM: at91: Document new TCB bindings
> ARM: dts: at91: at91rm9200: TC blocks are also simple-mfd and syscon
> devices
> ARM: dts: at91: at91rm9200ek: use TCB0 for timers
> ARM: dts: at91: mpa1600: use TCB0 as timers
> ARM: dts: at91: at91sam9260: TC blocks are also simple-mfd and syscon
> devices
> ARM: dts: at91: at91sam9260ek: use TCB0 as timers
> ARM: dts: at91: sam9_l9260: use TCB0 as timers
> ARM: dts: at91: ethernut5: use TCB0 as timers
> ARM: dts: at91: foxg20: use TCB0 as timers
> ARM: dts: at91: animeo_ip: use TCB0 as timers
> ARM: dts: at91: kizbox: use TCB0 as timers
> ARM: dts: at91: at91sam9g20ek: use TCB0 as timers
> ARM: dts: at91: ge863-pro3: use TCB0 as timers
> ARM: dts: at91: at91sam9261: TC blocks are also simple-mfd and syscon
> devices
> ARM: dts: at91: at91sam9261ek: use TCB0 as timers
> ARM: dts: at91: at91sam9263: TC blocks are also simple-mfd and syscon
> devices
> ARM: dts: at91: at91sam9263ek: use TCB0 as timers
> ARM: dts: at91: calao: use TCB0 as timers
> ARM: dts: at91: at91sam9g45: TC blocks are also simple-mfd and syscon
> devices
> ARM: dts: at91: at91sam9m10g45ek: use TCB0 as timers
> ARM: dts: at91: pm9g45: use TCB0 as timers
> ARM: dts: at91: at91sam9rl: TC blocks are also simple-mfd and syscon
> devices
> ARM: dts: at91: at91sam9rlek: use TCB0 as timers
> ARM: dts: at91: at91sam9n12: TC blocks are also simple-mfd and syscon
> devices
> ARM: dts: at91: at91sam9n12ek: use TCB0 as timers
> ARM: dts: at91: at91sam9x5: TC blocks are also simple-mfd and syscon
> devices
> ARM: dts: at91: at91sam9x5cm: use TCB0 as timers
> ARM: dts: at91: acme/g25: use TCB0 as timers
> ARM: dts: at91: cosino: use TCB0 as timers
> ARM: dts: at91: kizboxmini: use TCB0 as timers
> ARM: dts: at91: sama5d3: TC blocks are also simple-mfd and syscon
> devices
> ARM: dts: at91: sama5d3xek: use TCB0 as timers
> ARM: dts: at91: sama5d3 Xplained: use TCB0 as timers
> ARM: dts: at91: kizbox2: use TCB0 as timers
> ARM: dts: at91: sama5d3xek_cmp: use TCB0 as timers
> ARM: dts: at91: linea/tse850-3: use TCB0 as timers
> ARM: dts: at91: sama5d4: TC blocks are also simple-mfd and syscon
> devices
> ARM: dts: at91: sama5d4: Add TCB2
> ARM: dts: at91: sama5d4ek: use TCB2 as timers
> ARM: dts: at91: sama5d4 Xplained: use TCB2 as timers
> ARM: dts: at91: ma5d4: use TCB2 as timers
> ARM: dts: at91: vinco: use TCB2 as timers
> ARM: dts: at91: sama5d2: TC blocks are also simple-mfd and syscon
> devices
> ARM: dts: at91: sama5d2 Xplained: use TCB0 as timers
> ARM: dts: at91: sama5d27_som1_ek: use TCB0 as timers
For the whole series:
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Thanks, best regards,
Nicolas
> .../devicetree/bindings/arm/atmel-at91.txt | 32 -------------
> .../devicetree/bindings/mfd/atmel-tcb.txt | 56 ++++++++++++++++++++++
> arch/arm/boot/dts/animeo_ip.dts | 12 +++++
> arch/arm/boot/dts/at91-ariag25.dts | 12 +++++
> arch/arm/boot/dts/at91-ariettag25.dts | 12 +++++
> arch/arm/boot/dts/at91-cosino.dtsi | 12 +++++
> arch/arm/boot/dts/at91-foxg20.dts | 12 +++++
> arch/arm/boot/dts/at91-kizbox.dts | 12 +++++
> arch/arm/boot/dts/at91-kizbox2.dts | 12 +++++
> arch/arm/boot/dts/at91-kizboxmini.dts | 12 +++++
> arch/arm/boot/dts/at91-linea.dtsi | 12 +++++
> arch/arm/boot/dts/at91-qil_a9260.dts | 12 +++++
> arch/arm/boot/dts/at91-sam9_l9260.dts | 12 +++++
> arch/arm/boot/dts/at91-sama5d27_som1_ek.dts | 12 +++++
> arch/arm/boot/dts/at91-sama5d2_xplained.dts | 12 +++++
> arch/arm/boot/dts/at91-sama5d3_xplained.dts | 12 +++++
> arch/arm/boot/dts/at91-sama5d4_ma5d4.dtsi | 12 +++++
> arch/arm/boot/dts/at91-sama5d4_xplained.dts | 12 +++++
> arch/arm/boot/dts/at91-sama5d4ek.dts | 12 +++++
> arch/arm/boot/dts/at91-vinco.dts | 12 +++++
> arch/arm/boot/dts/at91rm9200.dtsi | 8 +++-
> arch/arm/boot/dts/at91rm9200ek.dts | 12 +++++
> arch/arm/boot/dts/at91sam9260.dtsi | 8 +++-
> arch/arm/boot/dts/at91sam9260ek.dts | 12 +++++
> arch/arm/boot/dts/at91sam9261.dtsi | 4 +-
> arch/arm/boot/dts/at91sam9261ek.dts | 20 ++++++++
> arch/arm/boot/dts/at91sam9263.dtsi | 4 +-
> arch/arm/boot/dts/at91sam9263ek.dts | 12 +++++
> arch/arm/boot/dts/at91sam9g20ek_common.dtsi | 12 +++++
> arch/arm/boot/dts/at91sam9g45.dtsi | 8 +++-
> arch/arm/boot/dts/at91sam9m10g45ek.dts | 12 +++++
> arch/arm/boot/dts/at91sam9n12.dtsi | 8 +++-
> arch/arm/boot/dts/at91sam9n12ek.dts | 12 +++++
> arch/arm/boot/dts/at91sam9rl.dtsi | 4 +-
> arch/arm/boot/dts/at91sam9rlek.dts | 12 +++++
> arch/arm/boot/dts/at91sam9x5.dtsi | 8 +++-
> arch/arm/boot/dts/at91sam9x5cm.dtsi | 12 +++++
> arch/arm/boot/dts/ethernut5.dts | 12 +++++
> arch/arm/boot/dts/ge863-pro3.dtsi | 12 +++++
> arch/arm/boot/dts/mpa1600.dts | 12 +++++
> arch/arm/boot/dts/pm9g45.dts | 12 +++++
> arch/arm/boot/dts/sama5d2.dtsi | 8 +++-
> arch/arm/boot/dts/sama5d3.dtsi | 4 +-
> arch/arm/boot/dts/sama5d3_tcb1.dtsi | 4 +-
> arch/arm/boot/dts/sama5d3xcm.dtsi | 12 +++++
> arch/arm/boot/dts/sama5d3xcm_cmp.dtsi | 12 +++++
> arch/arm/boot/dts/sama5d4.dtsi | 18 ++++++-
> arch/arm/boot/dts/tny_a9260_common.dtsi | 12 +++++
> arch/arm/boot/dts/tny_a9263.dts | 12 +++++
> arch/arm/boot/dts/usb_a9260_common.dtsi | 12 +++++
> arch/arm/boot/dts/usb_a9263.dts | 12 +++++
> 51 files changed, 575 insertions(+), 51 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mfd/atmel-tcb.txt
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: pwm: renesas-tpu: Correct example TPU register block size
From: Simon Horman @ 2017-12-20 8:21 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Thierry Reding, Rob Herring, Mark Rutland, Magnus Damm, linux-pwm,
devicetree, linux-renesas-soc
In-Reply-To: <1513699327-27357-3-git-send-email-geert+renesas@glider.be>
On Tue, Dec 19, 2017 at 05:02:06PM +0100, Geert Uytterhoeven wrote:
> The Timer Pulse Unit on R-Mobile A1 has registers that lie outside the
> declared register block. Enlarge the register block size to fix this.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
With reference to "User's Manual: Hardware" v2.00.
^ permalink raw reply
* Re: [PATCH 1/3] ARM: dts: r8a7740: Correct TPU register block size
From: Simon Horman @ 2017-12-20 8:23 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Thierry Reding, Rob Herring, Mark Rutland, Magnus Damm, linux-pwm,
devicetree, linux-renesas-soc
In-Reply-To: <1513699327-27357-2-git-send-email-geert+renesas@glider.be>
On Tue, Dec 19, 2017 at 05:02:05PM +0100, Geert Uytterhoeven wrote:
> The Timer Pulse Unit has registers that lie outside the declared
> register block. Enlarge the register block size to fix this.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> This was probably based on the old platform code, which also assumed a
> register block size of 0x100.
Reviewed-by: Simon Horman <simon.horman@netronome.com>
With reference to "User's Manual: Hardware" v2.00.
^ permalink raw reply
* Re: [PATCH V8 2/3] OPP: Introduce "required-opp" property
From: Ulf Hansson @ 2017-12-20 8:23 UTC (permalink / raw)
To: Viresh Kumar
Cc: Kevin Hilman, Rob Herring, Viresh Kumar, Nishanth Menon,
Stephen Boyd, Rafael J. Wysocki, linux-pm@vger.kernel.org,
Vincent Guittot, Rajendra Nayak, Sudeep Holla,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <6615035f294a64a4c17e5b44ac6690d1c2ac127c.1513591822.git.viresh.kumar@linaro.org>
On 18 December 2017 at 11:21, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> Devices have inter-dependencies some times. For example a device that
> needs to run at 800 MHz, needs another device (e.g. Its power domain) to
> be configured at a particular operating performance point.
>
> This patch introduces a new property "required-opp" which can be present
> directly in a device's node (if it doesn't need to change its OPPs), or
> in device's OPP nodes. More details on the property can be seen in the
> binding itself.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> Documentation/devicetree/bindings/opp/opp.txt | 8 +++
> .../devicetree/bindings/power/power_domain.txt | 59 ++++++++++++++++++++++
> 2 files changed, 67 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
> index a3953a1bb1a1..4e4f30288c8b 100644
> --- a/Documentation/devicetree/bindings/opp/opp.txt
> +++ b/Documentation/devicetree/bindings/opp/opp.txt
> @@ -159,6 +159,14 @@ properties.
>
> - status: Marks the node enabled/disabled.
>
> +- required-opp: This contains phandle to an OPP node in another device's OPP
> + table. It may contain an array of phandles, where each phandle points to an
> + OPP of a different device. It should not contain multiple phandles to the OPP
> + nodes in the same OPP table. This specifies the minimum required OPP of the
> + device(s), whose OPP's phandle is present in this property, for the
> + functioning of the current device at the current OPP (where this property is
> + present).
> +
> Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
>
> / {
> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
> index 61549840ab3b..f824763b202e 100644
> --- a/Documentation/devicetree/bindings/power/power_domain.txt
> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> @@ -126,4 +126,63 @@ The node above defines a typical PM domain consumer device, which is located
> inside a PM domain with index 0 of a power controller represented by a node
> with the label "power".
>
> +Optional properties:
> +- required-opp: This contains phandle to an OPP node in another device's OPP
> + table. It may contain an array of phandles, where each phandle points to an
> + OPP of a different device. It should not contain multiple phandles to the OPP
> + nodes in the same OPP table. This specifies the minimum required OPP of the
> + device(s), whose OPP's phandle is present in this property, for the
> + functioning of the current device at the current OPP (where this property is
> + present).
> +
> +Example:
> +- OPP table for domain provider that provides two domains.
> +
> + domain0_opp_table: opp_table0 {
> + compatible = "operating-points-v2";
> +
> + domain0_opp_0: opp-1000000000 {
> + opp-hz = /bits/ 64 <1000000000>;
> + opp-microvolt = <975000 970000 985000>;
> + };
> + domain0_opp_1: opp-1100000000 {
> + opp-hz = /bits/ 64 <1100000000>;
> + opp-microvolt = <1000000 980000 1010000>;
> + };
> + };
> +
> + domain1_opp_table: opp_table1 {
> + compatible = "operating-points-v2";
> +
> + domain1_opp_0: opp-1200000000 {
> + opp-hz = /bits/ 64 <1200000000>;
> + opp-microvolt = <975000 970000 985000>;
> + };
> + domain1_opp_1: opp-1300000000 {
> + opp-hz = /bits/ 64 <1300000000>;
> + opp-microvolt = <1000000 980000 1010000>;
> + };
> + };
> +
> + parent: power-controller@12340000 {
Nitpick: Could you please change "parent" to "power", to be consistent
with earlier examples.
> + compatible = "foo,power-controller";
> + reg = <0x12340000 0x1000>;
> + #power-domain-cells = <1>;
> + operating-points-v2 = <&domain0_opp_table>, <&domain1_opp_table>;
> + };
> +
> + leaky-device0@12350000 {
> + compatible = "foo,i-leak-current";
> + reg = <0x12350000 0x1000>;
> + power-domains = <&parent 0>;
> + required-opp = <&domain0_opp_0>;
> + };
> +
> + leaky-device1@12350000 {
> + compatible = "foo,i-leak-current";
> + reg = <0x12350000 0x1000>;
> + power-domains = <&parent 1>;
> + required-opp = <&domain1_opp_1>;
> + };
> +
> [1]. Documentation/devicetree/bindings/power/domain-idle-state.txt
> --
> 2.15.0.194.g9af6a3dea062
>
Besides the nitpick, feel free to add:
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH v3 00/19] ARM: dts: aspeed: updates and new machines
From: Arnd Bergmann @ 2017-12-20 8:24 UTC (permalink / raw)
To: Joel Stanley
Cc: Stephen Boyd, Michael Turquette, Rob Herring,
Cédric Le Goater, Benjamin Herrenschmidt, Jeremy Kerr,
devicetree, Andrew Jeffery, Linux ARM, Linux Kernel Mailing List,
linux-aspeed-uLR06cmDAlY/bJ5BZ2RsiQ, Patrick Venture, Xo Wang,
Lei YU, Mark Rutland
In-Reply-To: <CACPK8Xdf3__yuMEvD0NiZXihU-8F1R15aEwwJueHLZ6Jfs82oQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Dec 20, 2017 at 4:37 AM, Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org> wrote:
> On Wed, Dec 20, 2017 at 1:53 PM, Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org> wrote:
>> This series of device tree patches for the ASPEED BMC machines
>> moves all systems to use the soon to be merged clk driver, and
>> updates machines to use all of the drivers we have upstream.
>>
>> v3: Address review from Rob and Cedric
>> - Move aspeed-gpio.h usage out into the patches where use of the GPIO
>> is added
>> - Clarify that the aspeed-clock.h patch will be merged as part of
>> the device tree tree. This is to ensure we don't depend on the clk
>> tree for building.
>
> Arnd, Michael, Stephen; how do we resolve this? We need the
> dt-bindings header to be present for both the clk driver and the
> device tree to build.
>
> The clk driver is not (yet - soon I hope?) merged by Michael and
> Stephen. I am about to commit the device tree changes that will go
> through the ARM SoC tree.
There are several options:
- avoid the use of the header and redefine the binding to have a
clear mapping between hardware clock lines and the numeric
representation. This works better for some SoCs than others,
YMMV.
- Don't use the constants in the dts files for now, but use the
numbers directly, and update the dts files for the next merge window
- merge only one side for 4.16, either the driver or the dts files,
and follow up with the other one in 4.17
- make one shared git branch that contains only the headers
and base both the driver and the dts files on that branch so you
get a single shared commit ID.
I'm fine with any of the above, please pick whatever suits you best.
Arnd
--
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 V8 2/3] OPP: Introduce "required-opp" property
From: Viresh Kumar @ 2017-12-20 8:26 UTC (permalink / raw)
To: Ulf Hansson
Cc: Kevin Hilman, Rob Herring, Viresh Kumar, Nishanth Menon,
Stephen Boyd, Rafael J. Wysocki, linux-pm@vger.kernel.org,
Vincent Guittot, Rajendra Nayak, Sudeep Holla,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <CAPDyKFoWo0bUMNbGFSgjdN-ZwS+o6_GUXt-sQK0Qpcndw5B8eA@mail.gmail.com>
On 20-12-17, 09:23, Ulf Hansson wrote:
> Nitpick: Could you please change "parent" to "power", to be consistent
> with earlier examples.
Sure. Thanks for the review.
--
viresh
^ 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