* RE: [PATCH v2] arm64: dts: ls1088a: Add USB support
From: Yinbo Zhu @ 2017-12-20 4:42 UTC (permalink / raw)
To: Shawn Guo
Cc: Rob Herring, Mark Rutland, Catalin Marinas ), Will Deacon ),
Harninder Rai, Raghav Dogra, Ashish Kumar, Andy Tang,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Ran Wang,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
open list
In-Reply-To: <20171220025239.GB3766@dragon>
-----Original Message-----
From: Shawn Guo [mailto:shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org]
Sent: Wednesday, December 20, 2017 10:53 AM
To: Yinbo Zhu <yinbo.zhu-3arQi8VN3Tc@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>; Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>; Catalin Marinas ) <catalin.marinas-5wv7dgnIgG8@public.gmane.org>; Will Deacon ) <will.deacon@arm.com>; Harninder Rai <harninder.rai-3arQi8VN3Tc@public.gmane.org>; Raghav Dogra <raghav.dogra@nxp.com>; Ashish Kumar <ashish.kumar-3arQi8VN3Tc@public.gmane.org>; Andy Tang <andy.tang-3arQi8VN3Tc@public.gmane.org>; open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS <devicetree@vger.kernel.org>; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] arm64: dts: ls1088a: Add USB support
On Thu, Dec 07, 2017 at 07:33:28AM +0000, Yinbo Zhu wrote:
> Hi shawn guo,
>
> If my patch has no other issue,
> Can you help me push it to upstream.
>Are you talking about v4 patch? First of all, I cannot find v4 in my mailbox. That said, it seems you did not send
>the patch to me.
>Secondly, by checking the patch on patchwork, the usb nodes in fsl-ls1088a-rdb.dts do not sorted alphabetically
>in label name.
>Shawn
Hi shawn,
I will change the code as follows, right?
&esdhc {
status = "okay";
};
...
+&usb0 {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+};
+
https://patchwork.kernel.org/patch/10059097/
Thanks
Yinbo.
--
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 14/15] cpufreq: Add module to register cpufreq on Krait CPUs
From: Sricharan R @ 2017-12-20 6:19 UTC (permalink / raw)
To: Viresh Kumar
Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, rjw-LthD3rsA81gm4RdzfppkhA,
mturquette-rdvid1DuHRBWk0Htik3J/w, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
david.brown-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
andy.gross-QSEj5FYQhm4dnm+yROfE0A,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171220033608.GR19815@vireshk-i7>
Hi Viresh,
On 12/20/2017 9:06 AM, Viresh Kumar wrote:
> On 19-12-17, 21:24, Sricharan R wrote:
>> From: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>>
>> Register a cpufreq-generic device whenever we detect that a
>> "qcom,krait" compatible CPU is present in DT.
>>
>> Cc: <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
>> [Sricharan: updated to use dev_pm_opp_set_prop_name]
>> Signed-off-by: Sricharan R <sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> Signed-off-by: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> ---
>> drivers/cpufreq/Kconfig.arm | 9 ++
>> drivers/cpufreq/Makefile | 1 +
>> drivers/cpufreq/cpufreq-dt-platdev.c | 3 +-
>> drivers/cpufreq/qcom-cpufreq.c | 171 +++++++++++++++++++++++++++++++++++
>> 4 files changed, 183 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/cpufreq/qcom-cpufreq.c
>>
>> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
>> index bdce448..60f28e7 100644
>> --- a/drivers/cpufreq/Kconfig.arm
>> +++ b/drivers/cpufreq/Kconfig.arm
>> @@ -100,6 +100,15 @@ config ARM_OMAP2PLUS_CPUFREQ
>> depends on ARCH_OMAP2PLUS
>> default ARCH_OMAP2PLUS
>>
>> +config ARM_QCOM_CPUFREQ
>> + tristate "Qualcomm based"
>
> Qualcomm based ... ? You want to add something after this ?
>
Hmm, got truncated. Will add a proper one.
> And why tristate ? Do you really want to build a module for this ?
>
Given that cpufreq-dt that registers the driver already supports module,
don't think this needs to be a module. So will make it a bool.
>> + depends on ARCH_QCOM
>> + select PM_OPP
>> + help
>> + This adds the CPUFreq driver for Qualcomm SoC based boards.
>> +
>> + If in doubt, say N.
>> +
>> config ARM_S3C_CPUFREQ
>> bool
>> help
>> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
>> index 812f9e0..1496464 100644
>> --- a/drivers/cpufreq/Makefile
>> +++ b/drivers/cpufreq/Makefile
>> @@ -62,6 +62,7 @@ obj-$(CONFIG_ARM_MEDIATEK_CPUFREQ) += mediatek-cpufreq.o
>> obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
>> obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o
>> obj-$(CONFIG_PXA3xx) += pxa3xx-cpufreq.o
>> +obj-$(CONFIG_ARM_QCOM_CPUFREQ) += qcom-cpufreq.o
>> obj-$(CONFIG_ARM_S3C24XX_CPUFREQ) += s3c24xx-cpufreq.o
>> obj-$(CONFIG_ARM_S3C24XX_CPUFREQ_DEBUGFS) += s3c24xx-cpufreq-debugfs.o
>> obj-$(CONFIG_ARM_S3C2410_CPUFREQ) += s3c2410-cpufreq.o
>> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
>> index ecc56e2..032ac4f 100644
>> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
>> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
>> @@ -118,7 +118,7 @@
>> { .compatible = "ti,am33xx", },
>> { .compatible = "ti,am43", },
>> { .compatible = "ti,dra7", },
>> -
>
> Keep this blank line as is..
>
ok
>> + { .compatible = "qcom,ipq8064", },
>
> And add another one here.
>
ok
>> { }
>> };
>>
>> @@ -157,6 +157,7 @@ static int __init cpufreq_dt_platdev_init(void)
>>
>> create_pdev:
>> of_node_put(np);
>> +
>
> Remove this.
>
ok
>> return PTR_ERR_OR_ZERO(platform_device_register_data(NULL, "cpufreq-dt",
>> -1, data,
>> sizeof(struct cpufreq_dt_platform_data)));
>> diff --git a/drivers/cpufreq/qcom-cpufreq.c b/drivers/cpufreq/qcom-cpufreq.c
>> new file mode 100644
>> index 0000000..3e5583d
>> --- /dev/null
>> +++ b/drivers/cpufreq/qcom-cpufreq.c
>> @@ -0,0 +1,171 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
>> +
>> +#include <linux/cpu.h>
>> +#include <linux/err.h>
>> +#include <linux/init.h>
>> +#include <linux/io.h>
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/pm_opp.h>
>> +#include <linux/slab.h>
>> +#include "cpufreq-dt.h"
>> +
>> +static void __init get_krait_bin_format_a(int *speed, int *pvs, int *pvs_ver)
>> +{
>> + void __iomem *base;
>> + u32 pte_efuse;
>> +
>> + *speed = *pvs = *pvs_ver = 0;
>> +
>> + base = ioremap(0x007000c0, 4);
>> + if (!base) {
>> + pr_warn("Unable to read efuse data. Defaulting to 0!\n");
>> + return;
>> + }
>> +
>> + pte_efuse = readl_relaxed(base);
>> + iounmap(base);
>> +
>> + *speed = pte_efuse & 0xf;
>> + if (*speed == 0xf)
>> + *speed = (pte_efuse >> 4) & 0xf;
>> +
>> + if (*speed == 0xf) {
>> + *speed = 0;
>> + pr_warn("Speed bin: Defaulting to %d\n", *speed);
>> + } else {
>> + pr_info("Speed bin: %d\n", *speed);
>> + }
>> +
>> + *pvs = (pte_efuse >> 10) & 0x7;
>> + if (*pvs == 0x7)
>> + *pvs = (pte_efuse >> 13) & 0x7;
>> +
>> + if (*pvs == 0x7) {
>> + *pvs = 0;
>> + pr_warn("PVS bin: Defaulting to %d\n", *pvs);
>> + } else {
>> + pr_info("PVS bin: %d\n", *pvs);
>> + }
>> +}
>> +
>> +static void __init get_krait_bin_format_b(int *speed, int *pvs, int *pvs_ver)
>> +{
>> + u32 pte_efuse, redundant_sel;
>> + void __iomem *base;
>> +
>> + *speed = 0;
>> + *pvs = 0;
>> + *pvs_ver = 0;
>> +
>> + base = ioremap(0xfc4b80b0, 8);
>> + if (!base) {
>> + pr_warn("Unable to read efuse data. Defaulting to 0!\n");
>> + return;
>> + }
>> +
>> + pte_efuse = readl_relaxed(base);
>> + redundant_sel = (pte_efuse >> 24) & 0x7;
>> + *speed = pte_efuse & 0x7;
>> + /* 4 bits of PVS are in efuse register bits 31, 8-6. */
>> + *pvs = ((pte_efuse >> 28) & 0x8) | ((pte_efuse >> 6) & 0x7);
>> + *pvs_ver = (pte_efuse >> 4) & 0x3;
>> +
>> + switch (redundant_sel) {
>> + case 1:
>> + *speed = (pte_efuse >> 27) & 0xf;
>> + break;
>> + case 2:
>> + *pvs = (pte_efuse >> 27) & 0xf;
>> + break;
>> + }
>> +
>> + /* Check SPEED_BIN_BLOW_STATUS */
>> + if (pte_efuse & BIT(3)) {
>> + pr_info("Speed bin: %d\n", *speed);
>> + } else {
>> + pr_warn("Speed bin not set. Defaulting to 0!\n");
>> + *speed = 0;
>> + }
>> +
>> + /* Check PVS_BLOW_STATUS */
>> + pte_efuse = readl_relaxed(base + 0x4) & BIT(21);
>> + if (pte_efuse) {
>> + pr_info("PVS bin: %d\n", *pvs);
>> + } else {
>> + pr_warn("PVS bin not set. Defaulting to 0!\n");
>> + *pvs = 0;
>> + }
>> +
>> + pr_info("PVS version: %d\n", *pvs_ver);
>> + iounmap(base);
>> +}
>> +
>> +static int __init qcom_cpufreq_populate_opps(void)
>> +{
>> + int speed, pvs, pvs_ver;
>> + struct device_node *np;
>> + struct device *dev;
>> + int cpu = 0;
>> + char pvs_name[] = "speedXX-pvsXX-vXX";
>> +
>> + np = of_find_node_by_name(NULL, "qcom,pvs");
>> + if (!np)
>> + return -ENODEV;
>> +
>> + if (of_property_read_bool(np, "qcom,pvs-format-a"))
>> + get_krait_bin_format_a(&speed, &pvs, &pvs_ver);
>> + else if (of_property_read_bool(np, "qcom,pvs-format-b"))
>> + get_krait_bin_format_b(&speed, &pvs, &pvs_ver);
>> + else
>> + return -ENODEV;
>> +
>> + snprintf(pvs_name, sizeof(pvs_name), "speed%d-pvs%d-v%d",
>> + speed, pvs, pvs_ver);
>> +
>> + for (cpu = 0; cpu < num_possible_cpus(); cpu++) {
>> + dev = get_cpu_device(cpu);
>> + if (!dev)
>> + return -ENODEV;
>> +
>> + if (IS_ERR(dev_pm_opp_set_prop_name(dev, pvs_name)))
>> + pr_warn("failed to add OPP name %s\n", pvs_name);
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int __init qcom_cpufreq_driver_init(void)
>> +{
>> + struct device *cpu_dev;
>> + struct device_node *np;
>> + int ret;
>> +
>> + cpu_dev = get_cpu_device(0);
>> + if (!cpu_dev)
>> + return -ENODEV;
>> +
>> + np = of_node_get(cpu_dev->of_node);
>> + if (!np)
>> + return -ENOENT;
>> +
>> + if (!of_device_is_compatible(np, "qcom,krait")) {
>> + of_node_put(np);
>> + return -ENODEV;
>> + }
>> + of_node_put(np);
>> +
>> + ret = qcom_cpufreq_populate_opps();
>> + if (ret)
>> + return ret;
>> +
>> + return PTR_ERR(platform_device_register_simple("cpufreq-dt",
>> + -1, NULL, 0));
>> +}
>> +module_init(qcom_cpufreq_driver_init);
>
> As there is no module exit, it doesn't make sense to keep this as
> tristate.
>
ok
> Looks mostly fine now other than these minor nits.
>
Ok, Thanks for the review. Will wait on feedback for rest of the patches
and repost with these fixed.
Regards,
Sricharan
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
--
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:25 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: <20171220032614.GQ19815@vireshk-i7>
Hi Viresh,
On 12/20/2017 8:56 AM, Viresh Kumar wrote:
> On 19-12-17, 21:25, Sricharan R wrote:
>> + cpu@0 {
>> + compatible = "qcom,krait";
>> + enable-method = "qcom,kpss-acc-v1";
>> + device_type = "cpu";
>> + reg = <0>;
>> + qcom,acc = <&acc0>;
>> + qcom,saw = <&saw0>;
>> + clocks = <&kraitcc 0>;
>> + clock-names = "cpu";
>> + cpu-supply = <&smb208_s2a>;
>> + operating-points-v2 = <&cpu_opp_table>;
>> + };
>> +
>> + qcom,pvs {
>> + qcom,pvs-format-a;
>> + };
>
> Not sure what Rob is going to say on that :)
>
Yes. Would be good to know the best way.
>> +
>> +
>> + cpu_opp_table: opp_table {
>> + compatible = "operating-points-v2";
>> +
>> + /*
>> + * Missing opp-shared property means CPUs switch DVFS states
>> + * independently.
>> + */
>> +
>> + 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.
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 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
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