* [PATCH] ARM: dts: aspeed-g4: fix AHB window size of the SMC controllers
From: Cédric Le Goater @ 2017-04-19 13:43 UTC (permalink / raw)
To: Joel Stanley
Cc: Mark Rutland, devicetree, Russell King, Rob Herring,
Cédric Le Goater, linux-arm-kernel
The window of the Aspeed AST2400 SMC Controllers to map chips on the
AHB Bus has a 256MB size. The full window range is
[ 0x20000000 - 0x2FFFFFFF ] for the FMC controller
[ 0x30000000 - 0x3FFFFFFF ] for the SPI controller
This change requires CONFIG_VMSPLIT_2G to be set.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
arch/arm/boot/dts/aspeed-g4.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
index 4e3f055b365c..a7b6e04d5f1b 100644
--- a/arch/arm/boot/dts/aspeed-g4.dtsi
+++ b/arch/arm/boot/dts/aspeed-g4.dtsi
@@ -26,7 +26,7 @@
fmc: flash-controller@1e620000 {
reg = < 0x1e620000 0x94
- 0x20000000 0x02000000 >;
+ 0x20000000 0x10000000 >;
#address-cells = <1>;
#size-cells = <0>;
compatible = "aspeed,ast2400-fmc";
@@ -41,7 +41,7 @@
spi: flash-controller@1e630000 {
reg = < 0x1e630000 0x18
- 0x30000000 0x02000000 >;
+ 0x30000000 0x10000000 >;
#address-cells = <1>;
#size-cells = <0>;
compatible = "aspeed,ast2400-spi";
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 0/4] of: remove *phandle properties from expanded device tree
From: Rob Herring @ 2017-04-19 13:38 UTC (permalink / raw)
To: Frank Rowand
Cc: Stephen Boyd, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <58F6804A.3080206-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, Apr 18, 2017 at 4:08 PM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi Rob,
>
> Please do not apply this patch series.
What about patches 2-4? Those seem unrelated. But #2 didn't apply for
me, so resend if I should apply.
Rob
>
> The more context I look at, the less this approach seems good.
>
> I hope to have a simpler version completed quickly.
>
> Thanks,
>
> - Frank
--
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/6] arm64: dts: Add symlinks for cros-ec-keyboard and cros-ec-sbs
From: Olof Johansson @ 2017-04-19 13:31 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Brian Norris, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Doug Anderson,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
open list:ARM/Rockchip SoC..., Rob Herring, Chris Zhong,
Stephen Barber,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Caesar Wang, Maxime Ripard
In-Reply-To: <2579212.374vCSe9xi@phil>
On Wed, Apr 19, 2017 at 10:25 PM, Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org> wrote:
> Am Mittwoch, 19. April 2017, 21:54:09 CEST schrieb Olof Johansson:
>> Hi,
>>
>> On Tue, Feb 28, 2017 at 3:20 AM, Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org> wrote:
>> > Hi Olof,
>> >
>> > Am Dienstag, 21. Februar 2017, 15:47:31 CET schrieb Olof Johansson:
>> >> On Thu, Feb 9, 2017 at 5:05 PM, Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
>> >> > From: Douglas Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>> >> >
>> >> > We'd like to be able to use the cros-ec-keyboard.dtsi and
>> >> > cros-ec-sbs.dtsi snippets for arm64 devices. Currently those files live
>> >> > in the arm/boot/dts directory.
>> >> >
>> >> > Let's follow the convention set by commit 8ee57b8182c4 ("ARM64: dts:
>> >> > vexpress: Use a symlink to vexpress-v2m-rs1.dtsi from arch=arm") and use
>> >> > a symlink. Note that in this case we put the files in a new
>> >> > "include/common" directory since these snippets may need to be
>> >> > referenced by dts files in many different subdirectories.
>> >>
>> >> I'd rather have something like this:
>> >>
>> >> https://marc.info/?m=147547436324674&w=2
>> >>
>> >> Instead of having everybody move things over. I.e. make it easy to
>> >> refer to the arm version from arm64 instead of creating a "common"
>> >> layer inbetween.
>> >
>> > just so it gets noticed, I've done and tested [0], which hopefully should
>> > implement your suggestions above.
>> >
>> > If that looks ok, how do you want that picked up? Should I just include
>> > them in my regular rockchip branches or do you to pick them into some
>> > immutable branch, if other surprise-users turn up in time for 4.12?
>>
>> Sigh. I completely dropped the ball on this, and I didn't see it
>> included in any of your pull requests for 4.12 since I never actually
>> acked that approach.
>>
>> I've applied the patches onto a dt/include-paths stable branch, but
>> we're late for merging dependent code on top of it for 4.12.
>
> Didn't you merge the patches into a branch already and the rk3399-gru
> support on top of it?
>
> Aka
> https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git/log/?h=shared/dt-symlinks
>
> Which one of my previous pull requests was already based on.
Yeah, ignore the above (the original branch is the one to use). I must
be turning blind.
Adding Maxime on Cc since I asked him to move over to the new include
model post-rc1 for some of his stuff.
-Olof
--
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/6] arm64: dts: Add symlinks for cros-ec-keyboard and cros-ec-sbs
From: Heiko Stuebner @ 2017-04-19 13:25 UTC (permalink / raw)
To: Olof Johansson
Cc: Brian Norris, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Doug Anderson,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
open list:ARM/Rockchip SoC..., Rob Herring, Chris Zhong,
Stephen Barber,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Caesar Wang
In-Reply-To: <CAOesGMirj2j5P7_Ri4CSCux+O3hH_wxvrra7-p33AdXO4Ej5Hg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Am Mittwoch, 19. April 2017, 21:54:09 CEST schrieb Olof Johansson:
> Hi,
>
> On Tue, Feb 28, 2017 at 3:20 AM, Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org> wrote:
> > Hi Olof,
> >
> > Am Dienstag, 21. Februar 2017, 15:47:31 CET schrieb Olof Johansson:
> >> On Thu, Feb 9, 2017 at 5:05 PM, Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
> >> > From: Douglas Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> >> >
> >> > We'd like to be able to use the cros-ec-keyboard.dtsi and
> >> > cros-ec-sbs.dtsi snippets for arm64 devices. Currently those files live
> >> > in the arm/boot/dts directory.
> >> >
> >> > Let's follow the convention set by commit 8ee57b8182c4 ("ARM64: dts:
> >> > vexpress: Use a symlink to vexpress-v2m-rs1.dtsi from arch=arm") and use
> >> > a symlink. Note that in this case we put the files in a new
> >> > "include/common" directory since these snippets may need to be
> >> > referenced by dts files in many different subdirectories.
> >>
> >> I'd rather have something like this:
> >>
> >> https://marc.info/?m=147547436324674&w=2
> >>
> >> Instead of having everybody move things over. I.e. make it easy to
> >> refer to the arm version from arm64 instead of creating a "common"
> >> layer inbetween.
> >
> > just so it gets noticed, I've done and tested [0], which hopefully should
> > implement your suggestions above.
> >
> > If that looks ok, how do you want that picked up? Should I just include
> > them in my regular rockchip branches or do you to pick them into some
> > immutable branch, if other surprise-users turn up in time for 4.12?
>
> Sigh. I completely dropped the ball on this, and I didn't see it
> included in any of your pull requests for 4.12 since I never actually
> acked that approach.
>
> I've applied the patches onto a dt/include-paths stable branch, but
> we're late for merging dependent code on top of it for 4.12.
Didn't you merge the patches into a branch already and the rk3399-gru
support on top of it?
Aka
https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git/log/?h=shared/dt-symlinks
Which one of my previous pull requests was already based on.
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v6 6/8] coresight: add support for CPU debug module
From: Suzuki K Poulose @ 2017-04-19 13:23 UTC (permalink / raw)
To: Leo Yan, Jonathan Corbet, Rob Herring, Mark Rutland, Wei Xu,
Catalin Marinas, Will Deacon, Andy Gross, David Brown,
Mathieu Poirier, Stephen Boyd, linux-doc, linux-kernel,
devicetree, linux-arm-kernel, linux-arm-msm, linux-soc,
Mike Leach, Sudeep Holla
In-Reply-To: <1491485461-22800-7-git-send-email-leo.yan@linaro.org>
On 06/04/17 14:30, Leo Yan wrote:
> Coresight includes debug module and usually the module connects with CPU
> debug logic. ARMv8 architecture reference manual (ARM DDI 0487A.k) has
> description for related info in "Part H: External Debug".
>
> Chapter H7 "The Sample-based Profiling Extension" introduces several
> sampling registers, e.g. we can check program counter value with
> combined CPU exception level, secure state, etc. So this is helpful for
> analysis CPU lockup scenarios, e.g. if one CPU has run into infinite
> loop with IRQ disabled. In this case the CPU cannot switch context and
> handle any interrupt (including IPIs), as the result it cannot handle
> SMP call for stack dump.
>
> This patch is to enable coresight debug module, so firstly this driver
> is to bind apb clock for debug module and this is to ensure the debug
> module can be accessed from program or external debugger. And the driver
> uses sample-based registers for debug purpose, e.g. when system triggers
> panic, the driver will dump program counter and combined context
> registers (EDCIDSR, EDVIDSR); by parsing context registers so can
> quickly get to know CPU secure state, exception level, etc.
>
> Some of the debug module registers are located in CPU power domain, so
> this requires the CPU power domain stays on when access related debug
> registers, but the power management for CPU power domain is quite
> dependent on SoC integration for power management. For the platforms
> which with sane power controller implementations, this driver follows
> the method to set EDPRCR to try to pull the CPU out of low power state
> and then set 'no power down request' bit so the CPU has no chance to
> lose power.
>
> If the SoC has not followed up this design well for power management
> controller, the user should use the command line parameter or sysfs
> to constrain all or partial idle states to ensure the CPU power
> domain is enabled and access coresight CPU debug component safely.
Hi Leo,
This version looks good to me. I have two minor comments below.
> +
> +static struct notifier_block debug_notifier = {
> + .notifier_call = debug_notifier_call,
> +};
> +
> +static int debug_enable_func(void)
> +{
> + struct debug_drvdata *drvdata;
> + int cpu;
> +
> + for_each_possible_cpu(cpu) {
> + drvdata = per_cpu(debug_drvdata, cpu);
> + if (!drvdata)
> + continue;
> +
> + pm_runtime_get_sync(drvdata->dev);
> + }
> +
> + return atomic_notifier_chain_register(&panic_notifier_list,
> + &debug_notifier);
> +}
> +
> +static int debug_disable_func(void)
> +{
> + struct debug_drvdata *drvdata;
> + int cpu;
> +
> + for_each_possible_cpu(cpu) {
> + drvdata = per_cpu(debug_drvdata, cpu);
> + if (!drvdata)
> + continue;
> +
> + pm_runtime_put(drvdata->dev);
> + }
> +
> + return atomic_notifier_chain_unregister(&panic_notifier_list,
> + &debug_notifier);
> +}
I believe you should, reverse the order of these operations in debug_disable_func()
to prevent getting a panic notifier after we have released the power domain for the
debug.
i.e, :
atomic_notifier_chain_unregister(...);
for_each_possible_cpu(cpu) {}
> +
> +static ssize_t debug_func_knob_write(struct file *f,
> + const char __user *buf, size_t count, loff_t *ppos)
> +{
> + u8 val;
> + int ret;
> +
> + ret = kstrtou8_from_user(buf, count, 2, &val);
> + if (ret)
> + return ret;
> +
> + mutex_lock(&debug_lock);
> +
> + if (val == debug_enable)
> + goto out;
> +
> + if (val)
> + ret = debug_enable_func();
> + else
> + ret = debug_disable_func();
> +
> + if (ret) {
> + pr_err("%s: unable to %s debug function: %d\n",
> + __func__, val ? "enable" : "disable", ret);
> + goto err;
> + }
> +
> + debug_enable = val;
> +out:
> + ret = count;
> +err:
> + mutex_unlock(&debug_lock);
> + return ret;
> +}
> +
> +static ssize_t debug_func_knob_read(struct file *f,
> + char __user *ubuf, size_t count, loff_t *ppos)
> +{
> + ssize_t ret;
> + char buf[2];
> +
> + mutex_lock(&debug_lock);
> +
> + buf[0] = '0' + debug_enable;
> + buf[1] = '\n';
> + ret = simple_read_from_buffer(ubuf, count, ppos, buf, sizeof(buf));
> +
> + mutex_unlock(&debug_lock);
> + return ret;
> +}
> +
> +static const struct file_operations debug_func_knob_fops = {
> + .open = simple_open,
> + .read = debug_func_knob_read,
> + .write = debug_func_knob_write,
> +};
> +
> +static int debug_func_init(void)
> +{
> + struct dentry *file;
> + int ret;
> +
> + /* Create debugfs node */
> + debug_debugfs_dir = debugfs_create_dir("coresight_cpu_debug", NULL);
> + if (!debug_debugfs_dir) {
> + pr_err("%s: unable to create debugfs directory\n", __func__);
> + return -ENOMEM;
> + }
> +
> + file = debugfs_create_file("enable", S_IRUGO | S_IWUSR,
> + debug_debugfs_dir, NULL, &debug_func_knob_fops);
> + if (!file) {
> + pr_err("%s: unable to create enable knob file\n", __func__);
> + ret = -ENOMEM;
> + goto err;
> + }
> +
> + /* Use sysfs node to enable functionality */
> + if (!debug_enable)
> + return 0;
> +
> + /* Register function to be called for panic */
> + ret = atomic_notifier_chain_register(&panic_notifier_list,
> + &debug_notifier);
> + if (ret) {
> + pr_err("%s: unable to register notifier: %d\n",
> + __func__, ret);
> + goto err;
> + }
> +
Since we depend on the value of debug_enable above, below in debug_probe()
and in debug_remove(), we should protect these paths using the debug_lock mutex,
like we do above, to make sure we don't create a race.
> + return 0;
> +
> +err:
> + debugfs_remove_recursive(debug_debugfs_dir);
> + return ret;
> +}
> +
> +static void debug_func_exit(void)
> +{
> + debugfs_remove_recursive(debug_debugfs_dir);
> +
> + /* Unregister panic notifier callback */
> + if (debug_enable)
> + atomic_notifier_chain_unregister(&panic_notifier_list,
> + &debug_notifier);
> +}
> +
> +static int debug_probe(struct amba_device *adev, const struct amba_id *id)
> +{
> + void __iomem *base;
> + struct device *dev = &adev->dev;
> + struct debug_drvdata *drvdata;
> + struct resource *res = &adev->res;
> + struct device_node *np = adev->dev.of_node;
> + int ret;
> +
> + drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
> + if (!drvdata)
> + return -ENOMEM;
> +
> + drvdata->cpu = np ? of_coresight_get_cpu(np) : 0;
> + if (per_cpu(debug_drvdata, drvdata->cpu)) {
> + dev_err(dev, "CPU%d drvdata has been initialized\n",
> + drvdata->cpu);
May be we could warn about a possible issue in the DT ?
Cheers
Suzuki
^ permalink raw reply
* Re: [PATCH V5 1/4] arm64: dts: Add basic DT to support Spreadtrum's SP9860G
From: Chunyan Zhang @ 2017-04-19 13:12 UTC (permalink / raw)
To: arm-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Mark Rutland,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
Catalin Marinas, Will Deacon, Arnd Bergmann, Mathieu Poirier,
Orson Zhai (翟京),
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Chunyan Zhang
In-Reply-To: <1490599960-27330-1-git-send-email-chunyan.zhang-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
Hi Arnd, Olof
Could you please take this patch through arm-soc git if there are no
further comments? (The three other patches in this series have been
taken by Greg.)
Thanks,
Chunyan
On 27 March 2017 at 15:32, Chunyan Zhang <chunyan.zhang-lxIno14LUO0EEoCn2XhGlw@public.gmane.org> wrote:
> From: Orson Zhai <orson.zhai-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
>
> SC9860G is a 8 cores of A53 SoC with 4G LTE support SoC from Spreadtrum.
>
> According to regular hierarchy of sprd dts, whale2.dtsi contains SoC
> peripherals IP nodes, sc9860.dtsi contains stuff related to ARM core stuff
> and sp9860g dts is for the board level.
>
> Signed-off-by: Orson Zhai <orson.zhai-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
> Signed-off-by: Chunyan Zhang <chunyan.zhang-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
> Reviewed-by: Mathieu Poirier <mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> arch/arm64/boot/dts/sprd/Makefile | 3 +-
> arch/arm64/boot/dts/sprd/sc9860.dtsi | 569 ++++++++++++++++++++++++++++++
> arch/arm64/boot/dts/sprd/sp9860g-1h10.dts | 56 +++
> arch/arm64/boot/dts/sprd/whale2.dtsi | 71 ++++
> 4 files changed, 698 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm64/boot/dts/sprd/sc9860.dtsi
> create mode 100644 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts
> create mode 100644 arch/arm64/boot/dts/sprd/whale2.dtsi
>
> diff --git a/arch/arm64/boot/dts/sprd/Makefile b/arch/arm64/boot/dts/sprd/Makefile
> index b658c5e..f0535e6 100644
> --- a/arch/arm64/boot/dts/sprd/Makefile
> +++ b/arch/arm64/boot/dts/sprd/Makefile
> @@ -1,4 +1,5 @@
> -dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb
> +dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb \
> + sp9860g-1h10.dtb
>
> always := $(dtb-y)
> subdir-y := $(dts-dirs)
> diff --git a/arch/arm64/boot/dts/sprd/sc9860.dtsi b/arch/arm64/boot/dts/sprd/sc9860.dtsi
> new file mode 100644
> index 0000000..7b7d8ce
> --- /dev/null
> +++ b/arch/arm64/boot/dts/sprd/sc9860.dtsi
> @@ -0,0 +1,569 @@
> +/*
> + * Spreadtrum SC9860 SoC
> + *
> + * Copyright (C) 2016, Spreadtrum Communications Inc.
> + *
> + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> + */
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include "whale2.dtsi"
> +
> +/ {
> + cpus {
> + #address-cells = <2>;
> + #size-cells = <0>;
> +
> + cpu-map {
> + cluster0 {
> + core0 {
> + cpu = <&CPU0>;
> + };
> + core1 {
> + cpu = <&CPU1>;
> + };
> + core2 {
> + cpu = <&CPU2>;
> + };
> + core3 {
> + cpu = <&CPU3>;
> + };
> + };
> +
> + cluster1 {
> + core0 {
> + cpu = <&CPU4>;
> + };
> + core1 {
> + cpu = <&CPU5>;
> + };
> + core2 {
> + cpu = <&CPU6>;
> + };
> + core3 {
> + cpu = <&CPU7>;
> + };
> + };
> + };
> +
> + CPU0: cpu@530000 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0 0x530000>;
> + enable-method = "psci";
> + cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
> + };
> +
> + CPU1: cpu@530001 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0 0x530001>;
> + enable-method = "psci";
> + cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
> + };
> +
> + CPU2: cpu@530002 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0 0x530002>;
> + enable-method = "psci";
> + cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
> + };
> +
> + CPU3: cpu@530003 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0 0x530003>;
> + enable-method = "psci";
> + cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
> + };
> +
> + CPU4: cpu@530100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0 0x530100>;
> + enable-method = "psci";
> + cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
> + };
> +
> + CPU5: cpu@530101 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0 0x530101>;
> + enable-method = "psci";
> + cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
> + };
> +
> + CPU6: cpu@530102 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0 0x530102>;
> + enable-method = "psci";
> + cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
> + };
> +
> + CPU7: cpu@530103 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0 0x530103>;
> + enable-method = "psci";
> + cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
> + };
> + };
> +
> + idle-states{
> + entry-method = "arm,psci";
> +
> + CORE_PD: core_pd {
> + compatible = "arm,idle-state";
> + entry-latency-us = <1000>;
> + exit-latency-us = <700>;
> + min-residency-us = <2500>;
> + local-timer-stop;
> + arm,psci-suspend-param = <0x00010002>;
> + };
> +
> + CLUSTER_PD: cluster_pd {
> + compatible = "arm,idle-state";
> + entry-latency-us = <1000>;
> + exit-latency-us = <1000>;
> + min-residency-us = <3000>;
> + local-timer-stop;
> + arm,psci-suspend-param = <0x01010003>;
> + };
> + };
> +
> + gic: interrupt-controller@12001000 {
> + compatible = "arm,gic-400";
> + reg = <0 0x12001000 0 0x1000>,
> + <0 0x12002000 0 0x2000>,
> + <0 0x12004000 0 0x2000>,
> + <0 0x12006000 0 0x2000>;
> + #interrupt-cells = <3>;
> + interrupt-controller;
> + interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(8)
> + | IRQ_TYPE_LEVEL_HIGH)>;
> + };
> +
> + psci {
> + compatible = "arm,psci-0.2";
> + method = "smc";
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8)
> + | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8)
> + | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8)
> + | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8)
> + | IRQ_TYPE_LEVEL_LOW)>;
> + };
> +
> + pmu {
> + compatible = "arm,cortex-a53-pmu", "arm,armv8-pmuv3";
> + interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-affinity = <&CPU0>,
> + <&CPU1>,
> + <&CPU2>,
> + <&CPU3>,
> + <&CPU4>,
> + <&CPU5>,
> + <&CPU6>,
> + <&CPU7>;
> + };
> +
> + soc {
> + funnel@10001000 { /* SoC Funnel */
> + compatible = "arm,coresight-funnel", "arm,primecell";
> + reg = <0 0x10001000 0 0x1000>;
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + soc_funnel_out_port: endpoint {
> + remote-endpoint = <&etb_in>;
> + };
> + };
> +
> + port@1 {
> + reg = <0>;
> + soc_funnel_in_port0: endpoint {
> + slave-mode;
> + remote-endpoint =
> + <&main_funnel_out_port>;
> + };
> + };
> +
> + port@2 {
> + reg = <4>;
> + soc_funnel_in_port1: endpoint {
> + slave-mode;
> + remote-endpioint =
> + <&stm_out_port>;
> + };
> + };
> + };
> + };
> +
> + etb@10003000 {
> + compatible = "arm,coresight-tmc", "arm,primecell";
> + reg = <0 0x10003000 0 0x1000>;
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> + port {
> + etb_in: endpoint {
> + slave-mode;
> + remote-endpoint =
> + <&soc_funnel_out_port>;
> + };
> + };
> + };
> +
> + stm@10006000 {
> + compatible = "arm,coresight-stm", "arm,primecell";
> + reg = <0 0x10006000 0 0x1000>,
> + <0 0x01000000 0 0x180000>;
> + reg-names = "stm-base", "stm-stimulus-base";
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> + port {
> + stm_out_port: endpoint {
> + remote-endpoint =
> + <&soc_funnel_in_port1>;
> + };
> + };
> + };
> +
> + funnel@11001000 { /* Cluster0 Funnel */
> + compatible = "arm,coresight-funnel", "arm,primecell";
> + reg = <0 0x11001000 0 0x1000>;
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + cluster0_funnel_out_port: endpoint {
> + remote-endpoint =
> + <&cluster0_etf_in>;
> + };
> + };
> +
> + port@1 {
> + reg = <0>;
> + cluster0_funnel_in_port0: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm0_out>;
> + };
> + };
> +
> + port@2 {
> + reg = <1>;
> + cluster0_funnel_in_port1: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm1_out>;
> + };
> + };
> +
> + port@3 {
> + reg = <2>;
> + cluster0_funnel_in_port2: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm2_out>;
> + };
> + };
> +
> + port@4 {
> + reg = <4>;
> + cluster0_funnel_in_port3: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm3_out>;
> + };
> + };
> + };
> + };
> +
> + funnel@11002000 { /* Cluster1 Funnel */
> + compatible = "arm,coresight-funnel", "arm,primecell";
> + reg = <0 0x11002000 0 0x1000>;
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + cluster1_funnel_out_port: endpoint {
> + remote-endpoint =
> + <&cluster1_etf_in>;
> + };
> + };
> +
> + port@1 {
> + reg = <0>;
> + cluster1_funnel_in_port0: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm4_out>;
> + };
> + };
> +
> + port@2 {
> + reg = <1>;
> + cluster1_funnel_in_port1: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm5_out>;
> + };
> + };
> +
> + port@3 {
> + reg = <2>;
> + cluster1_funnel_in_port2: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm6_out>;
> + };
> + };
> +
> + port@4 {
> + reg = <3>;
> + cluster1_funnel_in_port3: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm7_out>;
> + };
> + };
> + };
> + };
> +
> + etf@11003000 { /* ETF on Cluster0 */
> + compatible = "arm,coresight-tmc", "arm,primecell";
> + reg = <0 0x11003000 0 0x1000>;
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + cluster0_etf_out: endpoint {
> + remote-endpoint =
> + <&main_funnel_in_port0>;
> + };
> + };
> +
> + port@1 {
> + reg = <0>;
> + cluster0_etf_in: endpoint {
> + slave-mode;
> + remote-endpoint =
> + <&cluster0_funnel_out_port>;
> + };
> + };
> + };
> + };
> +
> + etf@11004000 { /* ETF on Cluster1 */
> + compatible = "arm,coresight-tmc", "arm,primecell";
> + reg = <0 0x11004000 0 0x1000>;
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + cluster1_etf_out: endpoint {
> + remote-endpoint =
> + <&main_funnel_in_port1>;
> + };
> + };
> +
> + port@1 {
> + reg = <0>;
> + cluster1_etf_in: endpoint {
> + slave-mode;
> + remote-endpoint =
> + <&cluster1_funnel_out_port>;
> + };
> + };
> + };
> + };
> +
> + funnel@11005000 { /* Main Funnel */
> + compatible = "arm,coresight-funnel", "arm,primecell";
> + reg = <0 0x11005000 0 0x1000>;
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + main_funnel_out_port: endpoint {
> + remote-endpoint =
> + <&soc_funnel_in_port0>;
> + };
> + };
> +
> + port@1 {
> + reg = <0>;
> + main_funnel_in_port0: endpoint {
> + slave-mode;
> + remote-endpoint =
> + <&cluster0_etf_out>;
> + };
> + };
> +
> + port@2 {
> + reg = <1>;
> + main_funnel_in_port1: endpoint {
> + slave-mode;
> + remote-endpoint =
> + <&cluster1_etf_out>;
> + };
> + };
> + };
> + };
> +
> + etm@11440000 {
> + compatible = "arm,coresight-etm4x", "arm,primecell";
> + reg = <0 0x11440000 0 0x1000>;
> + cpu = <&CPU0>;
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> +
> + port {
> + etm0_out: endpoint {
> + remote-endpoint =
> + <&cluster0_funnel_in_port0>;
> + };
> + };
> + };
> +
> + etm@11540000 {
> + compatible = "arm,coresight-etm4x", "arm,primecell";
> + reg = <0 0x11540000 0 0x1000>;
> + cpu = <&CPU1>;
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> +
> + port {
> + etm1_out: endpoint {
> + remote-endpoint =
> + <&cluster0_funnel_in_port1>;
> + };
> + };
> + };
> +
> + etm@11640000 {
> + compatible = "arm,coresight-etm4x", "arm,primecell";
> + reg = <0 0x11640000 0 0x1000>;
> + cpu = <&CPU2>;
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> +
> + port {
> + etm2_out: endpoint {
> + remote-endpoint =
> + <&cluster0_funnel_in_port2>;
> + };
> + };
> + };
> +
> + etm@11740000 {
> + compatible = "arm,coresight-etm4x", "arm,primecell";
> + reg = <0 0x11740000 0 0x1000>;
> + cpu = <&CPU3>;
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> +
> + port {
> + etm3_out: endpoint {
> + remote-endpoint =
> + <&cluster0_funnel_in_port3>;
> + };
> + };
> + };
> +
> + etm@11840000 {
> + compatible = "arm,coresight-etm4x", "arm,primecell";
> + reg = <0 0x11840000 0 0x1000>;
> + cpu = <&CPU4>;
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> +
> + port {
> + etm4_out: endpoint {
> + remote-endpoint =
> + <&cluster1_funnel_in_port0>;
> + };
> + };
> + };
> +
> + etm@11940000 {
> + compatible = "arm,coresight-etm4x", "arm,primecell";
> + reg = <0 0x11940000 0 0x1000>;
> + cpu = <&CPU5>;
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> +
> + port {
> + etm5_out: endpoint {
> + remote-endpoint =
> + <&cluster1_funnel_in_port1>;
> + };
> + };
> + };
> +
> + etm@11a40000 {
> + compatible = "arm,coresight-etm4x", "arm,primecell";
> + reg = <0 0x11a40000 0 0x1000>;
> + cpu = <&CPU6>;
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> +
> + port {
> + etm6_out: endpoint {
> + remote-endpoint =
> + <&cluster1_funnel_in_port2>;
> + };
> + };
> + };
> +
> + etm@11b40000 {
> + compatible = "arm,coresight-etm4x", "arm,primecell";
> + reg = <0 0x11b40000 0 0x1000>;
> + cpu = <&CPU7>;
> + clocks = <&ext_26m>;
> + clock-names = "apb_pclk";
> +
> + port {
> + etm7_out: endpoint {
> + remote-endpoint =
> + <&cluster1_funnel_in_port3>;
> + };
> + };
> + };
> + };
> +};
> diff --git a/arch/arm64/boot/dts/sprd/sp9860g-1h10.dts b/arch/arm64/boot/dts/sprd/sp9860g-1h10.dts
> new file mode 100644
> index 0000000..ae0b28c
> --- /dev/null
> +++ b/arch/arm64/boot/dts/sprd/sp9860g-1h10.dts
> @@ -0,0 +1,56 @@
> +/*
> + * Spreadtrum SP9860g board
> + *
> + * Copyright (C) 2017, Spreadtrum Communications Inc.
> + *
> + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> + */
> +
> +/dts-v1/;
> +
> +#include "sc9860.dtsi"
> +
> +/ {
> + model = "Spreadtrum SP9860G 3GFHD Board";
> +
> + compatible = "sprd,sp9860g-1h10", "sprd,sc9860";
> +
> + aliases {
> + serial0 = &uart0; /* for Bluetooth */
> + serial1 = &uart1; /* UART console */
> + serial2 = &uart2; /* Reserved */
> + serial3 = &uart3; /* for GPS */
> + };
> +
> + memory{
> + device_type = "memory";
> + reg = <0x0 0x80000000 0 0x60000000>,
> + <0x1 0x80000000 0 0x60000000>;
> + };
> +
> + chosen {
> + stdout-path = "serial1:115200n8";
> + };
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> + };
> +};
> +
> +&uart0 {
> + status = "okay";
> +};
> +
> +&uart1 {
> + status = "okay";
> +};
> +
> +&uart2 {
> + status = "okay";
> +};
> +
> +&uart3 {
> + status = "okay";
> +};
> diff --git a/arch/arm64/boot/dts/sprd/whale2.dtsi b/arch/arm64/boot/dts/sprd/whale2.dtsi
> new file mode 100644
> index 0000000..7c217c5
> --- /dev/null
> +++ b/arch/arm64/boot/dts/sprd/whale2.dtsi
> @@ -0,0 +1,71 @@
> +/*
> + * Spreadtrum Whale2 platform peripherals
> + *
> + * Copyright (C) 2016, Spreadtrum Communications Inc.
> + *
> + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> + */
> +
> +/ {
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + soc: soc {
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + ap-apb {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x0 0x70000000 0x10000000>;
> +
> + uart0: serial@0 {
> + compatible = "sprd,sc9860-uart",
> + "sprd,sc9836-uart";
> + reg = <0x0 0x100>;
> + interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ext_26m>;
> + status = "disabled";
> + };
> +
> + uart1: serial@100000 {
> + compatible = "sprd,sc9860-uart",
> + "sprd,sc9836-uart";
> + reg = <0x100000 0x100>;
> + interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ext_26m>;
> + status = "disabled";
> + };
> +
> + uart2: serial@200000 {
> + compatible = "sprd,sc9860-uart",
> + "sprd,sc9836-uart";
> + reg = <0x200000 0x100>;
> + interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ext_26m>;
> + status = "disabled";
> + };
> +
> + uart3: serial@300000 {
> + compatible = "sprd,sc9860-uart",
> + "sprd,sc9836-uart";
> + reg = <0x300000 0x100>;
> + interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ext_26m>;
> + status = "disabled";
> + };
> + };
> +
> + };
> +
> + ext_26m: ext-26m {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <26000000>;
> + clock-output-names = "ext_26m";
> + };
> +};
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: at91: sama5d2: add m_can nodes
From: Quentin Schulz @ 2017-04-19 13:07 UTC (permalink / raw)
To: Wenyou Yang, Nicolas.Ferre, Alexandre Belloni, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King
Cc: devicetree, Wenyou Yang, Oliver Hartkopp, linux-kernel, linux-can,
linux-arm-kernel
In-Reply-To: <20170419084606.27543-1-wenyou.yang@atmel.com>
Hi,
On 19/04/2017 10:46, Wenyou Yang wrote:
> Add nodes to support the Controller Area Network(M_CAN) on SAMA5D2.
> The version of M_CAN IP core is 3.1.0 (CREL = 0x31040730).
>
> As said in SAMA5D2 datasheet, the CAN clock is recommended to use
> frequencies of 20, 40 or 80 MHz. To achieve these frequencies,
> PMC GCLK3 must select the UPLLCK(480 MHz) as source clock and
> divide by 24, 12, or 6. So, the "assigned-clock-rates" property
> has three options: 20000000, 40000000, and 80000000.
> The "assigned-clock-parents" property should be referred to utmi
> fixedly.
>
> The MSBs [bits 31:16] of the CAN Message RAM for CAN0 and CAN1 are
> default configured in 0x00200000. To avoid conflict with SRAM map
> for PM, change them to 0x00210000 in the AT91Bootstrap via setting
> the CAN Memories Address-based Register(SFR_CAN) of SFR.
>
> Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
> ---
> The patch is tested on SAMA5D2 Xplained and based on the patch set,
> 1. [PATCH v4 1/7] can: m_can: Disabled Interrupt Line 1
> http://marc.info/?l=linux-can&m=149165343604033&w=2
>
> Changes in v2:
> - Configures 10 TX Event FIFO elements and 10 TX Buffers/FIFO slots,
> because the TXE FIFO is needed to be configured.
> - Configure the offset of Message RAM for CAN1 followed from CAN0's.
>
I've tested with the v4 patch series of Mario Hüttel on a SAMA5D2
Xplained and did the following:
# ip link set can0 down
# ip link set can0 up type can bitrate 125000
# cansend can0 500#1E.10.10
Last line at least 10 times, every message is received on my computer.
Same with can1. Tested with candump can0 as well, everything looks fine.
Tested-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Thanks,
Quentin
> arch/arm/boot/dts/at91-sama5d2_xplained.dts | 24 +++++++++++++
> arch/arm/boot/dts/sama5d2.dtsi | 56 +++++++++++++++++++++++++++++
> 2 files changed, 80 insertions(+)
>
> diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
> index 9f7f8a7d8ff9..2f19b08dc226 100644
> --- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
> +++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
> @@ -257,6 +257,12 @@
> status = "okay";
> };
>
> + can0: can@f8054000 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_can0_default>;
> + status = "okay";
> + };
> +
> uart3: serial@fc008000 {
> atmel,use-dma-rx;
> atmel,use-dma-tx;
> @@ -321,6 +327,18 @@
> bias-disable;
> };
>
> + pinctrl_can0_default: can0_default {
> + pinmux = <PIN_PC10__CANTX0>,
> + <PIN_PC11__CANRX0>;
> + bias-disable;
> + };
> +
> + pinctrl_can1_default: can1_default {
> + pinmux = <PIN_PC26__CANTX1>,
> + <PIN_PC27__CANRX1>;
> + bias-disable;
> + };
> +
> pinctrl_charger_chglev: charger_chglev {
> pinmux = <PIN_PA12__GPIO>;
> bias-disable;
> @@ -468,6 +486,12 @@
> };
>
> };
> +
> + can1: can@fc050000 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_can1_default>;
> + status = "okay";
> + };
> };
> };
>
> diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
> index 22332be72140..383ca9307edf 100644
> --- a/arch/arm/boot/dts/sama5d2.dtsi
> +++ b/arch/arm/boot/dts/sama5d2.dtsi
> @@ -762,6 +762,18 @@
> atmel,clk-output-range = <0 83000000>;
> };
>
> + can0_clk: can0_clk {
> + #clock-cells = <0>;
> + reg = <56>;
> + atmel,clk-output-range = <0 83000000>;
> + };
> +
> + can1_clk: can1_clk {
> + #clock-cells = <0>;
> + reg = <57>;
> + atmel,clk-output-range = <0 83000000>;
> + };
> +
> classd_clk: classd_clk {
> #clock-cells = <0>;
> reg = <59>;
> @@ -890,6 +902,18 @@
> #clock-cells = <0>;
> reg = <55>;
> };
> +
> + can0_gclk: can0_gclk {
> + #clock-cells = <0>;
> + reg = <56>;
> + atmel,clk-output-range = <0 80000000>;
> + };
> +
> + can1_gclk: can1_gclk {
> + #clock-cells = <0>;
> + reg = <57>;
> + atmel,clk-output-range = <0 80000000>;
> + };
> };
> };
>
> @@ -1144,6 +1168,22 @@
> clocks = <&clk32k>;
> };
>
> + can0: can@f8054000 {
> + compatible = "bosch,m_can";
> + reg = <0xf8054000 0x4000>, <0x210000 0x4000>;
> + reg-names = "m_can", "message_ram";
> + interrupts = <56 IRQ_TYPE_LEVEL_HIGH 7>,
> + <64 IRQ_TYPE_LEVEL_HIGH 7>;
> + interrupt-names = "int0", "int1";
> + clocks = <&can0_clk>, <&can0_gclk>;
> + clock-names = "hclk", "cclk";
> + assigned-clocks = <&can0_gclk>;
> + assigned-clock-parents = <&utmi>;
> + assigned-clock-rates = <40000000>;
> + bosch,mram-cfg = <0x0 0 0 32 0 0 10 10>;
> + status = "disabled";
> + };
> +
> spi1: spi@fc000000 {
> compatible = "atmel,at91rm9200-spi";
> reg = <0xfc000000 0x100>;
> @@ -1305,6 +1345,22 @@
> status = "okay";
> };
>
> + can1: can@fc050000 {
> + compatible = "bosch,m_can";
> + reg = <0xfc050000 0x4000>, <0x210000 0x4000>;
> + reg-names = "m_can", "message_ram";
> + interrupts = <57 IRQ_TYPE_LEVEL_HIGH 7>,
> + <65 IRQ_TYPE_LEVEL_HIGH 7>;
> + interrupt-names = "int0", "int1";
> + clocks = <&can1_clk>, <&can1_gclk>;
> + clock-names = "hclk", "cclk";
> + assigned-clocks = <&can1_gclk>;
> + assigned-clock-parents = <&utmi>;
> + assigned-clock-rates = <40000000>;
> + bosch,mram-cfg = <0x1100 0 0 32 0 0 10 10>;
> + status = "disabled";
> + };
> +
> chipid@fc069000 {
> compatible = "atmel,sama5d2-chipid";
> reg = <0xfc069000 0x8>;
>
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v2 1/6] arm64: dts: Add symlinks for cros-ec-keyboard and cros-ec-sbs
From: Olof Johansson @ 2017-04-19 12:54 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Brian Norris, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Doug Anderson,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
open list:ARM/Rockchip SoC..., Rob Herring, Chris Zhong,
Stephen Barber,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Caesar Wang
In-Reply-To: <1529949.5djtX72aeJ@phil>
Hi,
On Tue, Feb 28, 2017 at 3:20 AM, Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org> wrote:
> Hi Olof,
>
> Am Dienstag, 21. Februar 2017, 15:47:31 CET schrieb Olof Johansson:
>> On Thu, Feb 9, 2017 at 5:05 PM, Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
>> > From: Douglas Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>> >
>> > We'd like to be able to use the cros-ec-keyboard.dtsi and
>> > cros-ec-sbs.dtsi snippets for arm64 devices. Currently those files live
>> > in the arm/boot/dts directory.
>> >
>> > Let's follow the convention set by commit 8ee57b8182c4 ("ARM64: dts:
>> > vexpress: Use a symlink to vexpress-v2m-rs1.dtsi from arch=arm") and use
>> > a symlink. Note that in this case we put the files in a new
>> > "include/common" directory since these snippets may need to be
>> > referenced by dts files in many different subdirectories.
>>
>> I'd rather have something like this:
>>
>> https://marc.info/?m=147547436324674&w=2
>>
>> Instead of having everybody move things over. I.e. make it easy to
>> refer to the arm version from arm64 instead of creating a "common"
>> layer inbetween.
>
> just so it gets noticed, I've done and tested [0], which hopefully should
> implement your suggestions above.
>
> If that looks ok, how do you want that picked up? Should I just include
> them in my regular rockchip branches or do you to pick them into some
> immutable branch, if other surprise-users turn up in time for 4.12?
Sigh. I completely dropped the ball on this, and I didn't see it
included in any of your pull requests for 4.12 since I never actually
acked that approach.
I've applied the patches onto a dt/include-paths stable branch, but
we're late for merging dependent code on top of it for 4.12.
-Olof
--
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
* [PATCH v3] usb: dwc3: add disable u2mac linestate check quirk
From: William Wu @ 2017-04-19 12:11 UTC (permalink / raw)
To: balbi-DgEjT+Ai2ygdnm+yROfE0A,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
Cc: huangtao-TNX95d0MmH7DzftRWevZcw,
devicetree-u79uwXL29TY76Z2rM5mHXA, heiko-4mtYJXux2i+zQB+pC5nmwQ,
groeck-hpIqsD4AKlfQT0dZR+AlfA, frank.wang-TNX95d0MmH7DzftRWevZcw,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dianders-hpIqsD4AKlfQT0dZR+AlfA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, william.wu-TNX95d0MmH7DzftRWevZcw,
briannorris-hpIqsD4AKlfQT0dZR+AlfA,
John.Youn-HKixBCOQz3hWk0Htik3J/w,
daniel.meng-TNX95d0MmH7DzftRWevZcw
This patch adds a quirk to disable USB 2.0 MAC linestate check
during HS transmit. Refer the dwc3 databook, we can use it for
some special platforms if the linestate not reflect the expected
line state(J) during transmission.
When use this quirk, the controller implements a fixed 40-bit
TxEndDelay after the packet is given on UTMI and ignores the
linestate during the transmit of a token (during token-to-token
and token-to-data IPGAP).
On some rockchip platforms (e.g. rk3399), it requires to disable
the u2mac linestate check to decrease the SSPLIT token to SETUP
token inter-packet delay from 566ns to 466ns, and fix the issue
that FS/LS devices not recognized if inserted through USB 3.0 HUB.
Signed-off-by: William Wu <william.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
---
Changes in v3:
- change quirk name
- only read and write GUCTL1 if dwc3 version >= 2.50a
Changes in v2:
- fix coding style
Documentation/devicetree/bindings/usb/dwc3.txt | 2 ++
drivers/usb/dwc3/core.c | 20 ++++++++++++++------
drivers/usb/dwc3/core.h | 4 ++++
3 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
index f658f39..52fb410 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -45,6 +45,8 @@ Optional properties:
a free-running PHY clock.
- snps,dis-del-phy-power-chg-quirk: when set core will change PHY power
from P0 to P1/P2/P3 without delay.
+ - snps,dis-tx-ipgap-linecheck-quirk: when set, disable u2mac linestate check
+ during HS transmit.
- snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
utmi_l1_suspend_n, false when asserts utmi_sleep_n
- snps,hird-threshold: HIRD threshold
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 455d89a..9d5a67c 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -796,13 +796,19 @@ static int dwc3_core_init(struct dwc3 *dwc)
dwc3_writel(dwc->regs, DWC3_GUCTL2, reg);
}
- /*
- * Enable hardware control of sending remote wakeup in HS when
- * the device is in the L1 state.
- */
- if (dwc->revision >= DWC3_REVISION_290A) {
+ if (dwc->revision >= DWC3_REVISION_250A) {
reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
- reg |= DWC3_GUCTL1_DEV_L1_EXIT_BY_HW;
+
+ /*
+ * Enable hardware control of sending remote wakeup
+ * in HS when the device is in the L1 state.
+ */
+ if (dwc->revision >= DWC3_REVISION_290A)
+ reg |= DWC3_GUCTL1_DEV_L1_EXIT_BY_HW;
+
+ if (dwc->dis_tx_ipgap_linecheck_quirk)
+ reg |= DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS;
+
dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
}
@@ -1023,6 +1029,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
"snps,dis-u2-freeclk-exists-quirk");
dwc->dis_del_phy_power_chg_quirk = device_property_read_bool(dev,
"snps,dis-del-phy-power-chg-quirk");
+ dwc->dis_tx_ipgap_linecheck_quirk = device_property_read_bool(dev,
+ "snps,dis-tx-ipgap-linecheck-quirk");
dwc->tx_de_emphasis_quirk = device_property_read_bool(dev,
"snps,tx_de_emphasis_quirk");
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 981c77f..6f6294d 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -204,6 +204,7 @@
#define DWC3_GCTL_DSBLCLKGTNG BIT(0)
/* Global User Control 1 Register */
+#define DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS BIT(28)
#define DWC3_GUCTL1_DEV_L1_EXIT_BY_HW BIT(24)
/* Global USB2 PHY Configuration Register */
@@ -850,6 +851,8 @@ struct dwc3_scratchpad_array {
* provide a free-running PHY clock.
* @dis_del_phy_power_chg_quirk: set if we disable delay phy power
* change quirk.
+ * @dis_tx_ipgap_linecheck_quirk: set if we disable u2mac linestate
+ * check during HS transmit.
* @tx_de_emphasis_quirk: set if we enable Tx de-emphasis quirk
* @tx_de_emphasis: Tx de-emphasis value
* 0 - -6dB de-emphasis
@@ -1004,6 +1007,7 @@ struct dwc3 {
unsigned dis_rxdet_inp3_quirk:1;
unsigned dis_u2_freeclk_exists_quirk:1;
unsigned dis_del_phy_power_chg_quirk:1;
+ unsigned dis_tx_ipgap_linecheck_quirk:1;
unsigned tx_de_emphasis_quirk:1;
unsigned tx_de_emphasis:2;
--
2.0.0
^ permalink raw reply related
* Re: [PATCH V5 1/4] arm64: dts: Add basic DT to support Spreadtrum's SP9860G
From: Lyra Zhang @ 2017-04-19 12:09 UTC (permalink / raw)
To: Arnd Bergmann, arm@kernel.org
Cc: robh+dt@kernel.org, Mark Rutland, gregkh@linuxfoundation.org,
Catalin Marinas, Will Deacon, Mathieu Poirier,
Orson Zhai (翟京), linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Chunyan Zhang
In-Reply-To: <CAAfSe-s-Jbvin0GV6F6W8OM5zp3kSzHO0YLTM3Gt_Qxv_vA6ag@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 20179 bytes --]
Hi Arnd, Olof, Could you please take this patch through arm-soc git if there are no further comments? (The three other patches in this series have been taken by Greg.) Thanks, Chunyan On 27 March 2017 at 15:32, Chunyan Zhang <chunyan.zhang@spreadtrum.com> wrote: > From: Orson Zhai <orson.zhai@spreadtrum.com> > > SC9860G is a 8 cores of A53 SoC with 4G LTE support SoC from Spreadtrum. > > According to regular hierarchy of sprd dts, whale2.dtsi contains SoC > peripherals IP nodes, sc9860.dtsi contains stuff related to ARM core stuff > and sp9860g dts is for the board level. > > Signed-off-by: Orson Zhai <orson.zhai@spreadtrum.com> > Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com> > Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> > --- > arch/arm64/boot/dts/sprd/Makefile | 3 +- > arch/arm64/boot/dts/sprd/sc9860.dtsi | 569 ++++++++++++++++++++++++++++++ > arch/arm64/boot/dts/sprd/sp9860g-1h10.dts | 56 +++ > arch/arm64/boot/dts/sprd/whale2.dtsi | 71 ++++ > 4 files changed, 698 insertions(+), 1 deletion(-) > create mode 100644 arch/arm64/boot/dts/sprd/sc9860.dtsi > create mode 100644 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts > create mode 100644 arch/arm64/boot/dts/sprd/whale2.dtsi > > diff --git a/arch/arm64/boot/dts/sprd/Makefile b/arch/arm64/boot/dts/sprd/Makefile > index b658c5e..f0535e6 100644 > --- a/arch/arm64/boot/dts/sprd/Makefile > +++ b/arch/arm64/boot/dts/sprd/Makefile > @@ -1,4 +1,5 @@ > -dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb > +dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb \ > + sp9860g-1h10.dtb > > always := $(dtb-y) > subdir-y := $(dts-dirs) > diff --git a/arch/arm64/boot/dts/sprd/sc9860.dtsi b/arch/arm64/boot/dts/sprd/sc9860.dtsi > new file mode 100644 > index 0000000..7b7d8ce > --- /dev/null > +++ b/arch/arm64/boot/dts/sprd/sc9860.dtsi > @@ -0,0 +1,569 @@ > +/* > + * Spreadtrum SC9860 SoC > + * > + * Copyright (C) 2016, Spreadtrum Communications Inc. > + * > + * SPDX-License-Identifier: (GPL-2.0+ OR MIT) > + */ > + > +#include <dt-bindings/interrupt-controller/arm-gic.h> > +#include "whale2.dtsi" > + > +/ { > + cpus { > + #address-cells = <2>; > + #size-cells = <0>; > + > + cpu-map { > + cluster0 { > + core0 { > + cpu = <&CPU0>; > + }; > + core1 { > + cpu = <&CPU1>; > + }; > + core2 { > + cpu = <&CPU2>; > + }; > + core3 { > + cpu = <&CPU3>; > + }; > + }; > + > + cluster1 { > + core0 { > + cpu = <&CPU4>; > + }; > + core1 { > + cpu = <&CPU5>; > + }; > + core2 { > + cpu = <&CPU6>; > + }; > + core3 { > + cpu = <&CPU7>; > + }; > + }; > + }; > + > + CPU0: cpu@530000 { > + device_type = "cpu"; > + compatible = "arm,cortex-a53", "arm,armv8"; > + reg = <0x0 0x530000>; > + enable-method = "psci"; > + cpu-idle-states = <&CORE_PD &CLUSTER_PD>; > + }; > + > + CPU1: cpu@530001 { > + device_type = "cpu"; > + compatible = "arm,cortex-a53", "arm,armv8"; > + reg = <0x0 0x530001>; > + enable-method = "psci"; > + cpu-idle-states = <&CORE_PD &CLUSTER_PD>; > + }; > + > + CPU2: cpu@530002 { > + device_type = "cpu"; > + compatible = "arm,cortex-a53", "arm,armv8"; > + reg = <0x0 0x530002>; > + enable-method = "psci"; > + cpu-idle-states = <&CORE_PD &CLUSTER_PD>; > + }; > + > + CPU3: cpu@530003 { > + device_type = "cpu"; > + compatible = "arm,cortex-a53", "arm,armv8"; > + reg = <0x0 0x530003>; > + enable-method = "psci"; > + cpu-idle-states = <&CORE_PD &CLUSTER_PD>; > + }; > + > + CPU4: cpu@530100 { > + device_type = "cpu"; > + compatible = "arm,cortex-a53", "arm,armv8"; > + reg = <0x0 0x530100>; > + enable-method = "psci"; > + cpu-idle-states = <&CORE_PD &CLUSTER_PD>; > + }; > + > + CPU5: cpu@530101 { > + device_type = "cpu"; > + compatible = "arm,cortex-a53", "arm,armv8"; > + reg = <0x0 0x530101>; > + enable-method = "psci"; > + cpu-idle-states = <&CORE_PD &CLUSTER_PD>; > + }; > + > + CPU6: cpu@530102 { > + device_type = "cpu"; > + compatible = "arm,cortex-a53", "arm,armv8"; > + reg = <0x0 0x530102>; > + enable-method = "psci"; > + cpu-idle-states = <&CORE_PD &CLUSTER_PD>; > + }; > + > + CPU7: cpu@530103 { > + device_type = "cpu"; > + compatible = "arm,cortex-a53", "arm,armv8"; > + reg = <0x0 0x530103>; > + enable-method = "psci"; > + cpu-idle-states = <&CORE_PD &CLUSTER_PD>; > + }; > + }; > + > + idle-states{ > + entry-method = "arm,psci"; > + > + CORE_PD: core_pd { > + compatible = "arm,idle-state"; > + entry-latency-us = <1000>; > + exit-latency-us = <700>; > + min-residency-us = <2500>; > + local-timer-stop; > + arm,psci-suspend-param = <0x00010002>; > + }; > + > + CLUSTER_PD: cluster_pd { > + compatible = "arm,idle-state"; > + entry-latency-us = <1000>; > + exit-latency-us = <1000>; > + min-residency-us = <3000>; > + local-timer-stop; > + arm,psci-suspend-param = <0x01010003>; > + }; > + }; > + > + gic: interrupt-controller@12001000 { > + compatible = "arm,gic-400"; > + reg = <0 0x12001000 0 0x1000>, > + <0 0x12002000 0 0x2000>, > + <0 0x12004000 0 0x2000>, > + <0 0x12006000 0 0x2000>; > + #interrupt-cells = <3>; > + interrupt-controller; > + interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(8) > + | IRQ_TYPE_LEVEL_HIGH)>; > + }; > + > + psci { > + compatible = "arm,psci-0.2"; > + method = "smc"; > + }; > + > + timer { > + compatible = "arm,armv8-timer"; > + interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) > + | IRQ_TYPE_LEVEL_LOW)>, > + <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) > + | IRQ_TYPE_LEVEL_LOW)>, > + <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8) > + | IRQ_TYPE_LEVEL_LOW)>, > + <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8) > + | IRQ_TYPE_LEVEL_LOW)>; > + }; > + > + pmu { > + compatible = "arm,cortex-a53-pmu", "arm,armv8-pmuv3"; > + interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>; > + interrupt-affinity = <&CPU0>, > + <&CPU1>, > + <&CPU2>, > + <&CPU3>, > + <&CPU4>, > + <&CPU5>, > + <&CPU6>, > + <&CPU7>; > + }; > + > + soc { > + funnel@10001000 { /* SoC Funnel */ > + compatible = "arm,coresight-funnel", "arm,primecell"; > + reg = <0 0x10001000 0 0x1000>; > + clocks = <&ext_26m>; > + clock-names = "apb_pclk"; > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { > + reg = <0>; > + soc_funnel_out_port: endpoint { > + remote-endpoint = <&etb_in>; > + }; > + }; > + > + port@1 { > + reg = <0>; > + soc_funnel_in_port0: endpoint { > + slave-mode; > + remote-endpoint = > + <&main_funnel_out_port>; > + }; > + }; > + > + port@2 { > + reg = <4>; > + soc_funnel_in_port1: endpoint { > + slave-mode; > + remote-endpioint = > + <&stm_out_port>; > + }; > + }; > + }; > + }; > + > + etb@10003000 { > + compatible = "arm,coresight-tmc", "arm,primecell"; > + reg = <0 0x10003000 0 0x1000>; > + clocks = <&ext_26m>; > + clock-names = "apb_pclk"; > + port { > + etb_in: endpoint { > + slave-mode; > + remote-endpoint = > + <&soc_funnel_out_port>; > + }; > + }; > + }; > + > + stm@10006000 { > + compatible = "arm,coresight-stm", "arm,primecell"; > + reg = <0 0x10006000 0 0x1000>, > + <0 0x01000000 0 0x180000>; > + reg-names = "stm-base", "stm-stimulus-base"; > + clocks = <&ext_26m>; > + clock-names = "apb_pclk"; > + port { > + stm_out_port: endpoint { > + remote-endpoint = > + <&soc_funnel_in_port1>; > + }; > + }; > + }; > + > + funnel@11001000 { /* Cluster0 Funnel */ > + compatible = "arm,coresight-funnel", "arm,primecell"; > + reg = <0 0x11001000 0 0x1000>; > + clocks = <&ext_26m>; > + clock-names = "apb_pclk"; > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { > + reg = <0>; > + cluster0_funnel_out_port: endpoint { > + remote-endpoint = > + <&cluster0_etf_in>; > + }; > + }; > + > + port@1 { > + reg = <0>; > + cluster0_funnel_in_port0: endpoint { > + slave-mode; > + remote-endpoint = <&etm0_out>; > + }; > + }; > + > + port@2 { > + reg = <1>; > + cluster0_funnel_in_port1: endpoint { > + slave-mode; > + remote-endpoint = <&etm1_out>; > + }; > + }; > + > + port@3 { > + reg = <2>; > + cluster0_funnel_in_port2: endpoint { > + slave-mode; > + remote-endpoint = <&etm2_out>; > + }; > + }; > + > + port@4 { > + reg = <4>; > + cluster0_funnel_in_port3: endpoint { > + slave-mode; > + remote-endpoint = <&etm3_out>; > + }; > + }; > + }; > + }; > + > + funnel@11002000 { /* Cluster1 Funnel */ > + compatible = "arm,coresight-funnel", "arm,primecell"; > + reg = <0 0x11002000 0 0x1000>; > + clocks = <&ext_26m>; > + clock-names = "apb_pclk"; > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { > + reg = <0>; > + cluster1_funnel_out_port: endpoint { > + remote-endpoint = > + <&cluster1_etf_in>; > + }; > + }; > + > + port@1 { > + reg = <0>; > + cluster1_funnel_in_port0: endpoint { > + slave-mode; > + remote-endpoint = <&etm4_out>; > + }; > + }; > + > + port@2 { > +
[-- Attachment #2: Type: text/html, Size: 48164 bytes --]
^ permalink raw reply
* Re: [PATCH v13 03/10] mux: minimal mux subsystem and gpio-based mux controller
From: Peter Rosin @ 2017-04-19 12:00 UTC (permalink / raw)
To: Philipp Zabel
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Wolfram Sang, Rob Herring, Mark Rutland, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
Jonathan Corbet, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Andrew Morton, Colin Ian King,
Paul Gortmaker, kernel-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <1492592817.2970.14.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 2017-04-19 11:06, Philipp Zabel wrote:
> On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin wrote:
>> Add a new minimalistic subsystem that handles multiplexer controllers.
>> When multiplexers are used in various places in the kernel, and the
>> same multiplexer controller can be used for several independent things,
>> there should be one place to implement support for said multiplexer
>> controller.
>>
>> A single multiplexer controller can also be used to control several
>> parallel multiplexers, that are in turn used by different subsystems
>> in the kernel, leading to a need to coordinate multiplexer accesses.
>> The multiplexer subsystem handles this coordination.
>>
>> This new mux controller subsystem initially comes with a single backend
>> driver that controls gpio based multiplexers. Even though not needed by
>> this initial driver, the mux controller subsystem is prepared to handle
>> chips with multiple (independent) mux controllers.
>>
>> Reviewed-by: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Signed-off-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
>> ---
*snip*
>> +int mux_control_select(struct mux_control *mux, int state)
>
> If we let two of these race, ...
The window for this "race" is positively huge. If there are several
mux consumers of a single mux controller, it is self-evident that
if one of them grabs the mux for a long time, the others will suffer.
The design is that the rwsem is reader-locked for the full duration
of a select/deselect operation by the mux consumer.
>> +{
>> + int ret;
>> +
>> + if (down_read_trylock(&mux->lock)) {
>> + if (mux->cached_state == state)
>> + return 0;
>> + /* Sigh, the mux needs updating... */
>> + up_read(&mux->lock);
>
> ... and both decide the mux needs updating ...
>
>> + }
>> +
>> + /* ...or it's just contended. */
>> + down_write(&mux->lock);
>
> ... then the last to get to down_write will just wait here forever (or
> until the first consumer calls mux_control_deselect, which may never
> happen)?
It is vital that the mux consumer call _deselect when it is done with
the mux. Not doing so will surely starve out any other mux consumers.
The whole thing is designed around the fact that mux consumers should
deselect the mux as soon as it's no longer needed.
It's simply not possible to share something as fundamental as a mux
without some cooperation. It's not like suffering mux consumers can
go off and use some other mux, and it's also not possible for a
"competing" mux consumer to just clobber the mux state.
>> +
>> + if (mux->cached_state == state) {
>> + /*
>> + * Hmmm, someone else changed the mux to my liking.
>> + * That makes me wonder how long I waited for nothing?
>> + */
>> + downgrade_write(&mux->lock);
>> + return 0;
>> + }
>> +
>> + ret = mux_control_set(mux, state);
>> + if (ret < 0) {
>> + if (mux->idle_state != MUX_IDLE_AS_IS)
>> + mux_control_set(mux, mux->idle_state);
>> +
>> + up_write(&mux->lock);
>> + return ret;
>> + }
>> +
>> + downgrade_write(&mux->lock);
>> +
>> + return 1;
>> +}
>> +EXPORT_SYMBOL_GPL(mux_control_select);
>
> I wonder if these should be called mux_control_lock/unlock instead,
> which would allow for try_lock and lock_timeout variants.
Maybe, I'm not totally against it. Do others care to opine?
But mux_control_try_select and mux_control_select_timeout does not
look all that bad either. But maybe foo_lock is making it clearer
that a foo_unlock is needed, if you compared it to foo_select and
foo_unselect? I'm probably not the best person to make the call,
as I know all to well what to expect from the functions...
Cheers,
peda
--
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: [RFC 2/2] mux: mmio-based syscon mux controller
From: Peter Rosin @ 2017-04-19 11:58 UTC (permalink / raw)
To: Philipp Zabel, Steve Longerbeam
Cc: Rob Herring, Mark Rutland, Sakari Ailus,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <1492602613.2970.92.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 2017-04-19 13:50, Philipp Zabel wrote:
> On Thu, 2017-04-13 at 18:09 -0700, Steve Longerbeam wrote:
>>
>> On 04/13/2017 08:48 AM, Philipp Zabel wrote:
>>> This adds a driver for mmio-based syscon multiplexers controlled by a
>>> single bitfield in a syscon register range.
>>>
>>> Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>>> ---
>>> drivers/mux/Kconfig | 13 +++++
>>> drivers/mux/Makefile | 1 +
>>> drivers/mux/mux-syscon.c | 130 +++++++++++++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 144 insertions(+)
>>> create mode 100644 drivers/mux/mux-syscon.c
>>>
>>> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
>>> index 86668b4d2fc52..a5e6a3b01ac24 100644
>>> --- a/drivers/mux/Kconfig
>>> +++ b/drivers/mux/Kconfig
>>> @@ -43,4 +43,17 @@ config MUX_GPIO
>>> To compile the driver as a module, choose M here: the module will
>>> be called mux-gpio.
>>>
>>> +config MUX_SYSCON
>>
>> my preference would be CONFIG_MUX_MMIO.
>>
>>> + tristate "MMIO bitfield-controlled Multiplexer"
>>
>> "MMIO register bitfield-controlled Multiplexer"
>>
>> The rest looks good to me.
>
> I'll change those. mux-syscon.c should probably be renamed to
> mux-mmio.c, too.
I think I disagree. But I'm not familiar with syscon so I don't know.
IIUC, syscon uses regmap to do mmio and this driver requires syscon
to get at the regmap, and in the end this driver doesn't know anything
about mmio. All it knows is syscon/regmap. If some warped syscon
thing shows up that wraps something other than mmio in its regmap,
this driver wouldn't care about it. And syscon is something that
is also known in the DT world. Given that, I think everything in this
driver should be named syscon and not mmio.
Or?
Cheers,
peda
--
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: [RFC 2/2] mux: mmio-based syscon mux controller
From: Philipp Zabel @ 2017-04-19 11:50 UTC (permalink / raw)
To: Steve Longerbeam
Cc: Peter Rosin, Rob Herring, Mark Rutland, Sakari Ailus,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <58fd5844-f24a-37cc-be81-26a716251860-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, 2017-04-13 at 18:09 -0700, Steve Longerbeam wrote:
>
> On 04/13/2017 08:48 AM, Philipp Zabel wrote:
> > This adds a driver for mmio-based syscon multiplexers controlled by a
> > single bitfield in a syscon register range.
> >
> > Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> > ---
> > drivers/mux/Kconfig | 13 +++++
> > drivers/mux/Makefile | 1 +
> > drivers/mux/mux-syscon.c | 130 +++++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 144 insertions(+)
> > create mode 100644 drivers/mux/mux-syscon.c
> >
> > diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
> > index 86668b4d2fc52..a5e6a3b01ac24 100644
> > --- a/drivers/mux/Kconfig
> > +++ b/drivers/mux/Kconfig
> > @@ -43,4 +43,17 @@ config MUX_GPIO
> > To compile the driver as a module, choose M here: the module will
> > be called mux-gpio.
> >
> > +config MUX_SYSCON
>
> my preference would be CONFIG_MUX_MMIO.
>
> > + tristate "MMIO bitfield-controlled Multiplexer"
>
> "MMIO register bitfield-controlled Multiplexer"
>
> The rest looks good to me.
I'll change those. mux-syscon.c should probably be renamed to
mux-mmio.c, too.
regards
Philipp
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains
From: Viresh Kumar @ 2017-04-19 11:47 UTC (permalink / raw)
To: Sudeep Holla
Cc: Rafael Wysocki, ulf.hansson, Kevin Hilman, Viresh Kumar,
Nishanth Menon, Stephen Boyd, linaro-kernel, linux-pm,
linux-kernel, Vincent Guittot, robh+dt, lina.iyer, rnayak,
devicetree
In-Reply-To: <95aa4b97-4e1a-13bb-f4d8-982b778012ba@arm.com>
On 18-04-17, 17:01, Sudeep Holla wrote:
> Understood. I would incline towards reusing regulators we that's what is
It can be just a regulator, but it can be anything else as well. That
entity may have its own clock/volt/current tunables, etc.
> changed behind the scene. Calling this operating performance point
> is misleading and doesn't align well with existing specs/features.
Yeah, but there are no voltage levels available here and that doesn't
fit as a regulator then.
> Understood. We have exactly same thing with SCPI but it controls both
> frequency and voltage referred as operating points. In general, this OPP
> terminology is used in SCPI/ACPI/SCMI specifications as both frequency
> and voltage control. I am bit worried that this binding might introduce
> confusions on the definitions. But it can be reworded/renamed easily if
> required.
Yeah, so far we have been looking at OPPs as freq-voltage pairs ONLY
and that is changing. I am not sure if it going in the wrong
direction really. Without frequency also it is an operating point for
the domain. Isn't it?
--
viresh
^ permalink raw reply
* Re: [RFC 1/2] dt-bindings: add mmio-based syscon mux controller DT bindings
From: Philipp Zabel @ 2017-04-19 11:47 UTC (permalink / raw)
To: Steve Longerbeam
Cc: Peter Rosin, Rob Herring, Mark Rutland, Sakari Ailus,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <d6d32063-5df3-3848-32f5-824c500a8927-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, 2017-04-13 at 18:03 -0700, Steve Longerbeam wrote:
>
> On 04/13/2017 08:48 AM, Philipp Zabel wrote:
> > This adds device tree binding documentation for mmio-based syscon
> > multiplexers controlled by a single bitfield in a syscon register
> > range.
>
> Nice! (you beat me to it, I was about to embark on this myself :)
>
> Looks good to me, just some minor comments below.
>
[...]
> > +Define a syscon bitfield to be used to control a multiplexer. The parent
> I think "Define a register bitfield to be used ..." is more clear.
[...]
> > +- compatible : "gpio-mux"
> Er, "mmio-mux"
I'll change those, thanks.
[...]
> > +Example:
> > +
> > + syscon {
> > + compatible = "syscon";
> > +
> > + mux: mux-controller@3 {
> > + compatible = "mmio-mux";
> > + reg = <0x3>;
> > + bit-mask = <0x1>;
> > + bit-shift = <5>;
> > + #mux-control-cells = <0>;
> > + };
> > + };
> > +
> > + video-mux {
>
> I like this as an example consumer of a mmio-mux, but just
> the same some might argue this doesn't really fit here.
I don't think this is a problem, of course assuming that this video-mux
binding will actually come into existence.
regards
Philipp
--
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] usb: dwc3: add disable u2mac linestate check quirk
From: wlf @ 2017-04-19 11:32 UTC (permalink / raw)
To: Guenter Roeck
Cc: William Wu, Felipe Balbi, johnyoun-HKixBCOQz3hWk0Htik3J/w,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, Heiko Stübner,
linux-kernel, linux-usb-u79uwXL29TY76Z2rM5mHXA,
open list:ARM/Rockchip SoC..., devicetree-u79uwXL29TY76Z2rM5mHXA,
Rob Herring, Frank Wang, Tao Huang, Doug Anderson, Brian Norris,
daniel.meng-TNX95d0MmH7DzftRWevZcw
In-Reply-To: <CABXOdTeszyp834fjYpqESqpKkgzt58Qjms=g+5G5U3Mx4y=b+A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Dear Guenter，
在 2017年04月19日 13:15, Guenter Roeck 写道:
> On Tue, Apr 18, 2017 at 8:59 PM, wlf <wulf-TNX95d0MmH7DzftRWevZcw@public.gmane.org> wrote:
>> Dear Guenter,
>>
>>
>>
>> 在 2017年04月18日 21:18, Guenter Roeck 写道:
>>> On Mon, Apr 17, 2017 at 10:17 PM, William Wu <william.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>>> wrote:
>>>> This patch adds a quirk to disable USB 2.0 MAC linestate check
>>>> during HS transmit. Refer the dwc3 databook, we can use it for
>>>> some special platforms if the linestate not reflect the expected
>>>> line state(J) during transmission.
>>>>
>>>> When use this quirk, the controller implements a fixed 40-bit
>>>> TxEndDelay after the packet is given on UTMI and ignores the
>>>> linestate during the transmit of a token (during token-to-token
>>>> and token-to-data IPGAP).
>>>>
>>>> On some rockchip platforms (e.g. rk3399), it requires to disable
>>>> the u2mac linestate check to decrease the SSPLIT token to SETUP
>>>> token inter-packet delay from 566ns to 466ns, and fix the issue
>>>> that FS/LS devices not recognized if inserted through USB 3.0 HUB.
>>>>
>>>> Signed-off-by: William Wu <william.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>>>> ---
>>>> Changes in v2:
>>>> - fix coding style
>>>>
>>>> Documentation/devicetree/bindings/usb/dwc3.txt | 2 ++
>>>> drivers/usb/dwc3/core.c | 14 ++++++++++----
>>>> drivers/usb/dwc3/core.h | 4 ++++
>>>> 3 files changed, 16 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
>>>> b/Documentation/devicetree/bindings/usb/dwc3.txt
>>>> index f658f39..6a89f0c 100644
>>>> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
>>>> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
>>>> @@ -45,6 +45,8 @@ Optional properties:
>>>> a free-running PHY clock.
>>>> - snps,dis-del-phy-power-chg-quirk: when set core will change PHY
>>>> power
>>>> from P0 to P1/P2/P3 without delay.
>>>> + - snps,tx-ipgap-linecheck-dis-quirk: when set, disable u2mac linestate
>>>> check
>>>> + during HS transmit.
>>> All other disable-something quirks are named
>>> "snps,dis-something-quirk". Maybe use the same naming convention ?
>> Yes, good idea！ I will fix it with "snps,dis-tx-ipgap-linecheck-quirk" in
>> next patch verison.
>> Thanks:-)
>>>
>>>> - snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
>>>> utmi_l1_suspend_n, false when asserts
>>>> utmi_sleep_n
>>>> - snps,hird-threshold: HIRD threshold
>>>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>>>> index 455d89a..03429c5 100644
>>>> --- a/drivers/usb/dwc3/core.c
>>>> +++ b/drivers/usb/dwc3/core.c
>>>> @@ -796,15 +796,19 @@ static int dwc3_core_init(struct dwc3 *dwc)
>>>> dwc3_writel(dwc->regs, DWC3_GUCTL2, reg);
>>>> }
>>>>
>>>> + reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
>>>> +
>>> My understanding is that the register was only introduced with dwc3
>>> revision 2.50a. Is it ok to read and write it unconditionally ?
>> Yes, refer to dwc3 databook, the DWC3_GUCTL1 was introduced since 2.50a.
>> Maybe it's better
>> to read and write it only when we know our controller version.
>>
>> Is it good to fix it like the following patch?
>> But this patch has a problem that we need to read and write the register
>> twice if our controller verison > = 2.90a, and need this quirk.
>>
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -806,6 +806,12 @@ static int dwc3_core_init(struct dwc3 *dwc)
>> dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
>> }
>>
>> + if (dwc->dis_tx_ipgap_linecheck_quirk) {
>> + reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
>> + reg |= DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS;
>> + dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
>> + }
>> +
>>
> How about this ?
>
> if (dwc->revision >= DWC3_REVISION_250A) {
> reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
> if (dwc->revision >= DWC3_REVISION_290A)
> reg |= DWC3_GUCTL1_DEV_L1_EXIT_BY_HW;
> if (dwc->dis_tx_ipgap_linecheck_quirk)
> reg |= DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS;
> dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
> }
>
> Thanks,
> Guenter
Thanks， looks good to me. I will fix it in patch v2.
>
>> Hi John & Felipe,
>> Could you provide me some suggestion？
>> Thank you！
>>
>>>> /*
>>>> * Enable hardware control of sending remote wakeup in HS when
>>>> * the device is in the L1 state.
>>>> */
>>>> - if (dwc->revision >= DWC3_REVISION_290A) {
>>>> - reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
>>>> + if (dwc->revision >= DWC3_REVISION_290A)
>>>> reg |= DWC3_GUCTL1_DEV_L1_EXIT_BY_HW;
>>>> - dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
>>>> - }
>>>> +
>>>> + if (dwc->tx_ipgap_linecheck_dis_quirk)
>>>> + reg |= DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS;
>>>> +
>>>> + dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
>>>>
>>>> return 0;
>>>>
>>>> @@ -1023,6 +1027,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
>>>> "snps,dis-u2-freeclk-exists-quirk");
>>>> dwc->dis_del_phy_power_chg_quirk =
>>>> device_property_read_bool(dev,
>>>> "snps,dis-del-phy-power-chg-quirk");
>>>> + dwc->tx_ipgap_linecheck_dis_quirk =
>>>> device_property_read_bool(dev,
>>>> + "snps,tx-ipgap-linecheck-dis-quirk");
>>>>
>>>> dwc->tx_de_emphasis_quirk = device_property_read_bool(dev,
>>>> "snps,tx_de_emphasis_quirk");
>>>> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
>>>> index 981c77f..3c2537b 100644
>>>> --- a/drivers/usb/dwc3/core.h
>>>> +++ b/drivers/usb/dwc3/core.h
>>>> @@ -204,6 +204,7 @@
>>>> #define DWC3_GCTL_DSBLCLKGTNG BIT(0)
>>>>
>>>> /* Global User Control 1 Register */
>>>> +#define DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS BIT(28)
>>>> #define DWC3_GUCTL1_DEV_L1_EXIT_BY_HW BIT(24)
>>>>
>>>> /* Global USB2 PHY Configuration Register */
>>>> @@ -850,6 +851,8 @@ struct dwc3_scratchpad_array {
>>>> * provide a free-running PHY clock.
>>>> * @dis_del_phy_power_chg_quirk: set if we disable delay phy power
>>>> * change quirk.
>>>> + * @tx_ipgap_linecheck_dis_quirk: set if we disable u2mac linestate
>>>> + * check during HS transmit.
>>>> * @tx_de_emphasis_quirk: set if we enable Tx de-emphasis quirk
>>>> * @tx_de_emphasis: Tx de-emphasis value
>>>> * 0 - -6dB de-emphasis
>>>> @@ -1004,6 +1007,7 @@ struct dwc3 {
>>>> unsigned dis_rxdet_inp3_quirk:1;
>>>> unsigned dis_u2_freeclk_exists_quirk:1;
>>>> unsigned dis_del_phy_power_chg_quirk:1;
>>>> + unsigned tx_ipgap_linecheck_dis_quirk:1;
>>>>
>>>> unsigned tx_de_emphasis_quirk:1;
>>>> unsigned tx_de_emphasis:2;
>>>> --
>>>> 2.0.0
>>>>
>>>>
>>>
>>
>
>
--
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 v13 02/10] dt-bindings: document devicetree bindings for mux-controllers and gpio-mux
From: Peter Rosin @ 2017-04-19 11:23 UTC (permalink / raw)
To: Philipp Zabel
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
Lars-Peter Clausen, Wolfram Sang,
linux-iio-u79uwXL29TY76Z2rM5mHXA, Jonathan Corbet,
linux-doc-u79uwXL29TY76Z2rM5mHXA, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
Paul Gortmaker, Rob Herring, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
Peter Meerwald-Stadler, Hartmut Knaack, Colin Ian King,
Andrew Morton, Jonathan Cameron
In-Reply-To: <1492599958.2970.84.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 2017-04-19 13:05, Philipp Zabel wrote:
> On Wed, 2017-04-19 at 12:41 +0200, Peter Rosin wrote:
>> On 2017-04-19 11:17, Philipp Zabel wrote:
>>> On Tue, 2017-04-18 at 15:36 +0200, Peter Rosin wrote:
>>>> If I got things wrong when I skimmed whatever I came across, and if the
>>>> mmio register is the only mux control option in the stars, it becomes
>>>> less obvious... It's of course still possible to hook into the mux
>>>> subsystem, but the benefit is questionable. And you do get the extra
>>>> device tree node. You could of course also implement a mux driver
>>>> outside of drivers/mux and thus make use of the mux api, but it's tiny
>>>> and any benefit is truly small.
>>>
>>> What I wondered mostly is whether it would be a good idea to move the
>>> OF-graph ports into the mux controller node, and let the video capture
>>> device be the consumer of the mux.
>>> But this wouldn't fit well with the clear split between the mux
>>> controller and the actual mux hardware in the mux DT bindings.
>>
>> I have tried to do something similar. I think. The current
>> drivers/i2c/muxes/i2c-mux-gpio.c is a good candidate for the same thing
>> IIUC.
>>
>> That dedicated driver and the general purpose i2c mux driver does pretty
>> much the same thing with these two DT snippets:
>>
>> Dedicated i2c-mux-gpio DT snippet:
>>
>> i2c-mux {
>> compatible = "i2c-mux-gpio";
>> i2c-parent = <&i2c1>;
>>
>> mux-gpios = <&gpio1 22 0 &gpio1 23 0>;
>>
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> i2c@1 {
>> ...
>> };
>>
>> i2c@3 {
>> ...
>> };
>> };
>>
>> General purpose mux DT snippet:
>>
>> mux: mux-controller {
>> compatible = "gpio-mux";
>> #mux-control-cells = <0>;
>>
>> mux-gpios = <&gpio1 22 0 &gpio1 23 0>;
>> };
>>
>> i2c-mux {
>> compatible = "i2c-mux";
>> i2c-parent = <&i2c1>;
>>
>> mux-controls = <&mux>;
>>
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> i2c@1 {
>> ...
>> };
>>
>> i2c@3 {
>> ...
>> };
>> };
>
> Yes, replace i2c-mux with video-mux and the i2c@x nodes with port@x
> nodes, and this is very close to what I am thinking about.
>
>> I would love to find a way to cleanly get the mux framework to handle
>> the first DT as well, and thus being able to obsolete the dedicated
>> i2c-mux-gpio driver. I have not figured out how to accomplish that
>> without abusing the driver-model to a point that it's not working.
>> Help with that task is dearly appreciated.
>>
>> What I have stumbled on, I think, is that two drivers needs to be
>> instantiated from the same DT node. At the same time, I need the
>> mux framework to handle the current out-of-node thing with a
>> phandle as well, so that several mux consumers can share a common
>> mux controller. My understanding of these matters are apparently not
>> deep enough...
>
> Not necessarily, if the framework could export a function to create a
> gpio/mmio mux_chip on a given device and the gpio-mux and *-mux-gpio
> drivers just reuse that.
I've been up that creek. Why should the gpio mux be special cased?
That's not clean, the implication is that all mux consumers need
to handle the gpio case and have a special compatible for that
case etc. Then someone thinks the DT should look equally "clean" for
some i2c based mux, and the weeds start piling up. This is exactly
what we don't want. We want the mux consumer drivers to be totally
agnostic about the fact that they happen to use a gpio mux.
Cheers,
peda
^ permalink raw reply
* Re: [PATCH v13 02/10] dt-bindings: document devicetree bindings for mux-controllers and gpio-mux
From: Philipp Zabel @ 2017-04-19 11:05 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-kernel, Greg Kroah-Hartman, Mark Rutland, devicetree,
Lars-Peter Clausen, Wolfram Sang, linux-iio, Jonathan Corbet,
linux-doc, kernel, Paul Gortmaker, Rob Herring, linux-i2c,
Peter Meerwald-Stadler, Hartmut Knaack, Colin Ian King,
Andrew Morton, Jonathan Cameron
In-Reply-To: <0cf0254e-0e43-37c3-f14d-eeffa7d7b9ba@axentia.se>
On Wed, 2017-04-19 at 12:41 +0200, Peter Rosin wrote:
> On 2017-04-19 11:17, Philipp Zabel wrote:
> > On Tue, 2017-04-18 at 15:36 +0200, Peter Rosin wrote:
> >> If I got things wrong when I skimmed whatever I came across, and if the
> >> mmio register is the only mux control option in the stars, it becomes
> >> less obvious... It's of course still possible to hook into the mux
> >> subsystem, but the benefit is questionable. And you do get the extra
> >> device tree node. You could of course also implement a mux driver
> >> outside of drivers/mux and thus make use of the mux api, but it's tiny
> >> and any benefit is truly small.
> >
> > What I wondered mostly is whether it would be a good idea to move the
> > OF-graph ports into the mux controller node, and let the video capture
> > device be the consumer of the mux.
> > But this wouldn't fit well with the clear split between the mux
> > controller and the actual mux hardware in the mux DT bindings.
>
> I have tried to do something similar. I think. The current
> drivers/i2c/muxes/i2c-mux-gpio.c is a good candidate for the same thing
> IIUC.
>
> That dedicated driver and the general purpose i2c mux driver does pretty
> much the same thing with these two DT snippets:
>
> Dedicated i2c-mux-gpio DT snippet:
>
> i2c-mux {
> compatible = "i2c-mux-gpio";
> i2c-parent = <&i2c1>;
>
> mux-gpios = <&gpio1 22 0 &gpio1 23 0>;
>
> #address-cells = <1>;
> #size-cells = <0>;
>
> i2c@1 {
> ...
> };
>
> i2c@3 {
> ...
> };
> };
>
> General purpose mux DT snippet:
>
> mux: mux-controller {
> compatible = "gpio-mux";
> #mux-control-cells = <0>;
>
> mux-gpios = <&gpio1 22 0 &gpio1 23 0>;
> };
>
> i2c-mux {
> compatible = "i2c-mux";
> i2c-parent = <&i2c1>;
>
> mux-controls = <&mux>;
>
> #address-cells = <1>;
> #size-cells = <0>;
>
> i2c@1 {
> ...
> };
>
> i2c@3 {
> ...
> };
> };
Yes, replace i2c-mux with video-mux and the i2c@x nodes with port@x
nodes, and this is very close to what I am thinking about.
> I would love to find a way to cleanly get the mux framework to handle
> the first DT as well, and thus being able to obsolete the dedicated
> i2c-mux-gpio driver. I have not figured out how to accomplish that
> without abusing the driver-model to a point that it's not working.
> Help with that task is dearly appreciated.
>
> What I have stumbled on, I think, is that two drivers needs to be
> instantiated from the same DT node. At the same time, I need the
> mux framework to handle the current out-of-node thing with a
> phandle as well, so that several mux consumers can share a common
> mux controller. My understanding of these matters are apparently not
> deep enough...
Not necessarily, if the framework could export a function to create a
gpio/mmio mux_chip on a given device and the gpio-mux and *-mux-gpio
drivers just reuse that.
> I think you would like a DT that looks more like the first DT
> snippet but still enjoy the flexibility of the mux framework and w/o
> implementing a (another) full muxing sub-sub-system like the i2c
> sub-system has done. Correct?
Correct.
regards
Philipp
^ permalink raw reply
* Re: [PATCH] media: mtk-vcodec: remove informative log
From: Mauro Carvalho Chehab @ 2017-04-19 10:56 UTC (permalink / raw)
To: Tiffany Lin
Cc: Minghsiu Tsai, Hans Verkuil, daniel.thompson, Rob Herring,
Matthias Brugger, Daniel Kurtz, Pawel Osciak, srv_heupstream,
Eddie Huang, Yingjoe Chen, Wu-Cheng Li, devicetree, linux-kernel,
linux-arm-kernel, linux-media, linux-mediatek
In-Reply-To: <1491390599.32502.1.camel@mtksdaap41>
Em Wed, 5 Apr 2017 19:09:59 +0800
Tiffany Lin <tiffany.lin@mediatek.com> escreveu:
> On Wed, 2017-04-05 at 18:54 +0800, Minghsiu Tsai wrote:
> > Driver is stable. Remove DEBUG definition from driver.
> >
> > There are debug message in /var/log/messages if DEBUG is defined,
> > such as:
> > [MTK_V4L2] level=0 fops_vcodec_open(),170: decoder capability 0
> > [MTK_V4L2] level=0 fops_vcodec_open(),177: 16000000.vcodec decoder [0]
> > [MTK_V4L2] level=0 fops_vcodec_release(),200: [0] decoder
> >
> > Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
> Acked-by:Tiffany Lin <Tiffany.lin@mediatek.com>
>
> > ---
> > drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> > index 7d55975..1248083 100644
> > --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> > +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> > @@ -31,7 +31,6 @@ struct mtk_vcodec_mem {
> > extern int mtk_v4l2_dbg_level;
> > extern bool mtk_vcodec_dbg;
> >
> > -#define DEBUG 1
> >
> > #if defined(DEBUG)
> >
After this patch, building the Kernel with W=1 now shows warnings:
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c: In function 'mtk_vcodec_dec_pw_on':
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c:114:51: warning: suggest braces around empty body in an 'if' statement [-Wempty-body]
mtk_v4l2_err("pm_runtime_get_sync fail %d", ret);
^
I wrote a patch fixing it, as this is really a trivial issue.
Yet, after that, this one still remains:
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c: In function 'mtk_vdec_pic_info_update':
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c:284:6: warning: variable 'ret' set but not used [-Wunused-but-set-variable]
int ret;
^~~
Shouldn't be mtk_vdec_pic_info_update() returning an error code?
Also, IMHO, at least errors should be shown at dmesg.
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH v13 02/10] dt-bindings: document devicetree bindings for mux-controllers and gpio-mux
From: Peter Rosin @ 2017-04-19 10:41 UTC (permalink / raw)
To: Philipp Zabel
Cc: linux-kernel, Greg Kroah-Hartman, Mark Rutland, devicetree,
Lars-Peter Clausen, Wolfram Sang, linux-iio, Jonathan Corbet,
linux-doc, kernel, Paul Gortmaker, Rob Herring, linux-i2c,
Peter Meerwald-Stadler, Hartmut Knaack, Colin Ian King,
Andrew Morton, Jonathan Cameron
In-Reply-To: <1492593449.2970.24.camel@pengutronix.de>
On 2017-04-19 11:17, Philipp Zabel wrote:
> On Tue, 2017-04-18 at 15:36 +0200, Peter Rosin wrote:
>> If I got things wrong when I skimmed whatever I came across, and if the
>> mmio register is the only mux control option in the stars, it becomes
>> less obvious... It's of course still possible to hook into the mux
>> subsystem, but the benefit is questionable. And you do get the extra
>> device tree node. You could of course also implement a mux driver
>> outside of drivers/mux and thus make use of the mux api, but it's tiny
>> and any benefit is truly small.
>
> What I wondered mostly is whether it would be a good idea to move the
> OF-graph ports into the mux controller node, and let the video capture
> device be the consumer of the mux.
> But this wouldn't fit well with the clear split between the mux
> controller and the actual mux hardware in the mux DT bindings.
I have tried to do something similar. I think. The current
drivers/i2c/muxes/i2c-mux-gpio.c is a good candidate for the same thing
IIUC.
That dedicated driver and the general purpose i2c mux driver does pretty
much the same thing with these two DT snippets:
Dedicated i2c-mux-gpio DT snippet:
i2c-mux {
compatible = "i2c-mux-gpio";
i2c-parent = <&i2c1>;
mux-gpios = <&gpio1 22 0 &gpio1 23 0>;
#address-cells = <1>;
#size-cells = <0>;
i2c@1 {
...
};
i2c@3 {
...
};
};
General purpose mux DT snippet:
mux: mux-controller {
compatible = "gpio-mux";
#mux-control-cells = <0>;
mux-gpios = <&gpio1 22 0 &gpio1 23 0>;
};
i2c-mux {
compatible = "i2c-mux";
i2c-parent = <&i2c1>;
mux-controls = <&mux>;
#address-cells = <1>;
#size-cells = <0>;
i2c@1 {
...
};
i2c@3 {
...
};
};
I would love to find a way to cleanly get the mux framework to handle
the first DT as well, and thus being able to obsolete the dedicated
i2c-mux-gpio driver. I have not figured out how to accomplish that
without abusing the driver-model to a point that it's not working.
Help with that task is dearly appreciated.
What I have stumbled on, I think, is that two drivers needs to be
instantiated from the same DT node. At the same time, I need the
mux framework to handle the current out-of-node thing with a
phandle as well, so that several mux consumers can share a common
mux controller. My understanding of these matters are apparently not
deep enough...
I think you would like a DT that looks more like the first DT
snippet but still enjoy the flexibility of the mux framework and w/o
implementing a (another) full muxing sub-sub-system like the i2c
sub-system has done. Correct?
Cheers,
peda
^ permalink raw reply
* Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle
From: Michael Ellerman @ 2017-04-19 10:13 UTC (permalink / raw)
To: Oliver O'Halloran, Rob Herring
Cc: devicetree@vger.kernel.org, linuxppc-dev,
linux-kernel@vger.kernel.org, rostedt-nx8X9YLhiw1AfugRpC6u6w,
Ingo Molnar, Tyrel Datwyler, Nathan Fontenot, Frank Rowand
In-Reply-To: <CAOSf1CH8HgP0rKd0WCp87BADYcEGT5OCoq_yq+f3ZeoyTcXeng-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Oliver O'Halloran <oohall-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> On Wed, Apr 19, 2017 at 2:46 AM, Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> On Mon, Apr 17, 2017 at 7:32 PM, Tyrel Datwyler
>> <tyreld-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> wrote:
>>> This patch introduces event tracepoints for tracking a device_nodes
>>> reference cycle as well as reconfig notifications generated in response
>>> to node/property manipulations.
>>>
>>> With the recent upstreaming of the refcount API several device_node
>>> underflows and leaks have come to my attention in the pseries (DLPAR) dynamic
>>> logical partitioning code (ie. POWER speak for hotplugging virtual and physcial
>>> resources at runtime such as cpus or IOAs). These tracepoints provide a
>>> easy and quick mechanism for validating the reference counting of
>>> device_nodes during their lifetime.
>>
>> Not really relevant for this patch, but since you are looking at
>> pseries and refcounting, the refcounting largely exists for pseries.
>> It's also hard to get right as this type of fix is fairly common. It's
>> now used for overlays, but we really probably only need to refcount
>> the overlays or changesets as a whole, not at a node level. If you
>> have any thoughts on how a different model of refcounting could work
>> for pseries, I'd like to discuss it.
>
> One idea I've been kicking around is differentiating short and long
> term references to a node.
I actually did this a long time ago, but balked at the size of the patch
to do the conversion. Let me see if I can find it lying around ...
cheers
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains
From: Viresh Kumar @ 2017-04-19 10:12 UTC (permalink / raw)
To: Sudeep Holla
Cc: Rafael Wysocki, ulf.hansson, Kevin Hilman, Viresh Kumar,
Nishanth Menon, Stephen Boyd, linaro-kernel, linux-pm,
linux-kernel, Vincent Guittot, robh+dt, lina.iyer, rnayak,
devicetree
In-Reply-To: <2128c09a-0656-0878-c4e7-c327007021c7@arm.com>
On 18-04-17, 17:03, Sudeep Holla wrote:
> Was it posted externally ? Was there any objections for that approach ?
> IMO that's better approach but if I am late to the party, I would like
> to read through the discussions that happened on it(if any)
Maybe Stephen can tell more about it. AFAIK, there were some offline
discussions around it.
--
viresh
^ permalink raw reply
* Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains
From: Viresh Kumar @ 2017-04-19 10:11 UTC (permalink / raw)
To: Sudeep Holla
Cc: Rafael Wysocki, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Kevin Hilman,
Viresh Kumar, Nishanth Menon, Stephen Boyd,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Vincent Guittot,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, lina.iyer-QSEj5FYQhm4dnm+yROfE0A,
rnayak-sgV2jX0FEOL9JmXXK+q4OQ, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <95aa4b97-4e1a-13bb-f4d8-982b778012ba-5wv7dgnIgG8@public.gmane.org>
On 18-04-17, 17:01, Sudeep Holla wrote:
> No, may be I was not so clear. I am just referring a power controller
> that provides say 3 different power domains and are indexed 0 - 2.
> The consumer just passes the index along with the phandle for the power
> domain info.
Ahh, I got you now. Will take care of it in next version.
--
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 1/2] arm64: dts: juno: fix few unit address format warnings
From: Liviu Dudau @ 2017-04-19 10:08 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1492538279-16405-1-git-send-email-sudeep.holla-5wv7dgnIgG8@public.gmane.org>
On Tue, Apr 18, 2017 at 06:57:58PM +0100, Sudeep Holla wrote:
> This patch fixes the following set of warnings on juno.
>
> smb@08000000 unit name should not have leading 0s
> sysctl@020000 simple-bus unit address format error, expected "20000"
> apbregs@010000 simple-bus unit address format error, expected "10000"
> mmci@050000 simple-bus unit address format error, expected "50000"
> kmi@060000 simple-bus unit address format error, expected "60000"
> kmi@070000 simple-bus unit address format error, expected "70000"
> wdt@0f0000 simple-bus unit address format error, expected "f0000"
>
> Cc: Liviu Dudau <liviu.dudau-5wv7dgnIgG8@public.gmane.org>
Acked-by: Liviu Dudau <liviu.dudau-5wv7dgnIgG8@public.gmane.org>
Thanks!
Liviu
> Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
> ---
> arch/arm64/boot/dts/arm/juno-base.dtsi | 2 +-
> arch/arm64/boot/dts/arm/juno-motherboard.dtsi | 12 ++++++------
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
> index 8ffaff2043d0..bfe7d683a42e 100644
> --- a/arch/arm64/boot/dts/arm/juno-base.dtsi
> +++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
> @@ -699,7 +699,7 @@
> <0x00000008 0x80000000 0x1 0x80000000>;
> };
>
> - smb@08000000 {
> + smb@8000000 {
> compatible = "simple-bus";
> #address-cells = <2>;
> #size-cells = <1>;
> diff --git a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
> index 098601657f82..2ac43221ddb6 100644
> --- a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
> +++ b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
> @@ -137,7 +137,7 @@
> #size-cells = <1>;
> ranges = <0 3 0 0x200000>;
>
> - v2m_sysctl: sysctl@020000 {
> + v2m_sysctl: sysctl@20000 {
> compatible = "arm,sp810", "arm,primecell";
> reg = <0x020000 0x1000>;
> clocks = <&v2m_refclk32khz>, <&v2m_refclk1mhz>, <&mb_clk24mhz>;
> @@ -148,7 +148,7 @@
> assigned-clock-parents = <&v2m_refclk1mhz>, <&v2m_refclk1mhz>, <&v2m_refclk1mhz>, <&v2m_refclk1mhz>;
> };
>
> - apbregs@010000 {
> + apbregs@10000 {
> compatible = "syscon", "simple-mfd";
> reg = <0x010000 0x1000>;
>
> @@ -216,7 +216,7 @@
> };
> };
>
> - mmci@050000 {
> + mmci@50000 {
> compatible = "arm,pl180", "arm,primecell";
> reg = <0x050000 0x1000>;
> interrupts = <5>;
> @@ -228,7 +228,7 @@
> clock-names = "mclk", "apb_pclk";
> };
>
> - kmi@060000 {
> + kmi@60000 {
> compatible = "arm,pl050", "arm,primecell";
> reg = <0x060000 0x1000>;
> interrupts = <8>;
> @@ -236,7 +236,7 @@
> clock-names = "KMIREFCLK", "apb_pclk";
> };
>
> - kmi@070000 {
> + kmi@70000 {
> compatible = "arm,pl050", "arm,primecell";
> reg = <0x070000 0x1000>;
> interrupts = <8>;
> @@ -244,7 +244,7 @@
> clock-names = "KMIREFCLK", "apb_pclk";
> };
>
> - wdt@0f0000 {
> + wdt@f0000 {
> compatible = "arm,sp805", "arm,primecell";
> reg = <0x0f0000 0x10000>;
> interrupts = <7>;
> --
> 2.7.4
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
--
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] ARM: dts: vexpress: fix few unit address format warnings
From: Liviu Dudau @ 2017-04-19 10:07 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Lorenzo Pieralisi
In-Reply-To: <1492537507-7783-1-git-send-email-sudeep.holla-5wv7dgnIgG8@public.gmane.org>
On Tue, Apr 18, 2017 at 06:45:07PM +0100, Sudeep Holla wrote:
> This patch fixes the following set of warnings on vexpress platforms:
>
> sysreg@010000 simple-bus unit address format error, expected "10000"
> sysctl@020000 simple-bus unit address format error, expected "20000"
> i2c@030000 simple-bus unit address format error, expected "30000"
> aaci@040000 simple-bus unit address format error, expected "40000"
> mmci@050000 simple-bus unit address format error, expected "50000"
> kmi@060000 simple-bus unit address format error, expected "60000"
> kmi@070000 simple-bus unit address format error, expected "70000"
> uart@090000 simple-bus unit address format error, expected "90000"
> uart@0a0000 simple-bus unit address format error, expected "a0000"
> uart@0b0000 simple-bus unit address format error, expected "b0000"
> uart@0c0000 simple-bus unit address format error, expected "c0000"
> wdt@0f0000 simple-bus unit address format error, expected "f0000"
>
> Cc: Liviu Dudau <liviu.dudau-5wv7dgnIgG8@public.gmane.org>
Acked-by: Liviu Dudau <liviu.dudau-5wv7dgnIgG8@public.gmane.org>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
> Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
> ---
> arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 24 ++++++++++++------------
> arch/arm/boot/dts/vexpress-v2m.dtsi | 24 ++++++++++++------------
> arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 2 +-
> arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 18 +++++++++---------
> arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 2 +-
> arch/arm/boot/dts/vexpress-v2p-ca9.dts | 2 +-
> 6 files changed, 36 insertions(+), 36 deletions(-)
>
> Hi,
>
> I observed few warning in linux-next due to the enhanced DTC checks
> introduced with DTC upgrade in linux-next. The patch fixes few warnings
All changes look sensible to me in order to fix the warnings, but I feel like
letting out a minor rant from me: the fact that DTC now complains about leading
zeros in what is usually a numeric field is silly. I find it easier to parse numbers
that have the same width. Also, now the reg property doesn't match the @<number>
part if you grep for it.
Best regards,
Liviu
>
> Regards,
> Sudeep
>
> diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> index 3086efacd00e..35714ff6f467 100644
> --- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> +++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> @@ -71,7 +71,7 @@
> #size-cells = <1>;
> ranges = <0 3 0 0x200000>;
>
> - v2m_sysreg: sysreg@010000 {
> + v2m_sysreg: sysreg@10000 {
> compatible = "arm,vexpress-sysreg";
> reg = <0x010000 0x1000>;
>
> @@ -94,7 +94,7 @@
> };
> };
>
> - v2m_sysctl: sysctl@020000 {
> + v2m_sysctl: sysctl@20000 {
> compatible = "arm,sp810", "arm,primecell";
> reg = <0x020000 0x1000>;
> clocks = <&v2m_refclk32khz>, <&v2m_refclk1mhz>, <&smbclk>;
> @@ -106,7 +106,7 @@
> };
>
> /* PCI-E I2C bus */
> - v2m_i2c_pcie: i2c@030000 {
> + v2m_i2c_pcie: i2c@30000 {
> compatible = "arm,versatile-i2c";
> reg = <0x030000 0x1000>;
>
> @@ -119,7 +119,7 @@
> };
> };
>
> - aaci@040000 {
> + aaci@40000 {
> compatible = "arm,pl041", "arm,primecell";
> reg = <0x040000 0x1000>;
> interrupts = <11>;
> @@ -127,7 +127,7 @@
> clock-names = "apb_pclk";
> };
>
> - mmci@050000 {
> + mmci@50000 {
> compatible = "arm,pl180", "arm,primecell";
> reg = <0x050000 0x1000>;
> interrupts = <9 10>;
> @@ -139,7 +139,7 @@
> clock-names = "mclk", "apb_pclk";
> };
>
> - kmi@060000 {
> + kmi@60000 {
> compatible = "arm,pl050", "arm,primecell";
> reg = <0x060000 0x1000>;
> interrupts = <12>;
> @@ -147,7 +147,7 @@
> clock-names = "KMIREFCLK", "apb_pclk";
> };
>
> - kmi@070000 {
> + kmi@70000 {
> compatible = "arm,pl050", "arm,primecell";
> reg = <0x070000 0x1000>;
> interrupts = <13>;
> @@ -155,7 +155,7 @@
> clock-names = "KMIREFCLK", "apb_pclk";
> };
>
> - v2m_serial0: uart@090000 {
> + v2m_serial0: uart@90000 {
> compatible = "arm,pl011", "arm,primecell";
> reg = <0x090000 0x1000>;
> interrupts = <5>;
> @@ -163,7 +163,7 @@
> clock-names = "uartclk", "apb_pclk";
> };
>
> - v2m_serial1: uart@0a0000 {
> + v2m_serial1: uart@a0000 {
> compatible = "arm,pl011", "arm,primecell";
> reg = <0x0a0000 0x1000>;
> interrupts = <6>;
> @@ -171,7 +171,7 @@
> clock-names = "uartclk", "apb_pclk";
> };
>
> - v2m_serial2: uart@0b0000 {
> + v2m_serial2: uart@b0000 {
> compatible = "arm,pl011", "arm,primecell";
> reg = <0x0b0000 0x1000>;
> interrupts = <7>;
> @@ -179,7 +179,7 @@
> clock-names = "uartclk", "apb_pclk";
> };
>
> - v2m_serial3: uart@0c0000 {
> + v2m_serial3: uart@c0000 {
> compatible = "arm,pl011", "arm,primecell";
> reg = <0x0c0000 0x1000>;
> interrupts = <8>;
> @@ -187,7 +187,7 @@
> clock-names = "uartclk", "apb_pclk";
> };
>
> - wdt@0f0000 {
> + wdt@f0000 {
> compatible = "arm,sp805", "arm,primecell";
> reg = <0x0f0000 0x1000>;
> interrupts = <0>;
> diff --git a/arch/arm/boot/dts/vexpress-v2m.dtsi b/arch/arm/boot/dts/vexpress-v2m.dtsi
> index c6393d3f1719..1b6f6393be93 100644
> --- a/arch/arm/boot/dts/vexpress-v2m.dtsi
> +++ b/arch/arm/boot/dts/vexpress-v2m.dtsi
> @@ -70,7 +70,7 @@
> #size-cells = <1>;
> ranges = <0 7 0 0x20000>;
>
> - v2m_sysreg: sysreg@00000 {
> + v2m_sysreg: sysreg@0 {
> compatible = "arm,vexpress-sysreg";
> reg = <0x00000 0x1000>;
>
> @@ -93,7 +93,7 @@
> };
> };
>
> - v2m_sysctl: sysctl@01000 {
> + v2m_sysctl: sysctl@1000 {
> compatible = "arm,sp810", "arm,primecell";
> reg = <0x01000 0x1000>;
> clocks = <&v2m_refclk32khz>, <&v2m_refclk1mhz>, <&smbclk>;
> @@ -105,7 +105,7 @@
> };
>
> /* PCI-E I2C bus */
> - v2m_i2c_pcie: i2c@02000 {
> + v2m_i2c_pcie: i2c@2000 {
> compatible = "arm,versatile-i2c";
> reg = <0x02000 0x1000>;
>
> @@ -118,7 +118,7 @@
> };
> };
>
> - aaci@04000 {
> + aaci@4000 {
> compatible = "arm,pl041", "arm,primecell";
> reg = <0x04000 0x1000>;
> interrupts = <11>;
> @@ -126,7 +126,7 @@
> clock-names = "apb_pclk";
> };
>
> - mmci@05000 {
> + mmci@5000 {
> compatible = "arm,pl180", "arm,primecell";
> reg = <0x05000 0x1000>;
> interrupts = <9 10>;
> @@ -138,7 +138,7 @@
> clock-names = "mclk", "apb_pclk";
> };
>
> - kmi@06000 {
> + kmi@6000 {
> compatible = "arm,pl050", "arm,primecell";
> reg = <0x06000 0x1000>;
> interrupts = <12>;
> @@ -146,7 +146,7 @@
> clock-names = "KMIREFCLK", "apb_pclk";
> };
>
> - kmi@07000 {
> + kmi@7000 {
> compatible = "arm,pl050", "arm,primecell";
> reg = <0x07000 0x1000>;
> interrupts = <13>;
> @@ -154,7 +154,7 @@
> clock-names = "KMIREFCLK", "apb_pclk";
> };
>
> - v2m_serial0: uart@09000 {
> + v2m_serial0: uart@9000 {
> compatible = "arm,pl011", "arm,primecell";
> reg = <0x09000 0x1000>;
> interrupts = <5>;
> @@ -162,7 +162,7 @@
> clock-names = "uartclk", "apb_pclk";
> };
>
> - v2m_serial1: uart@0a000 {
> + v2m_serial1: uart@a000 {
> compatible = "arm,pl011", "arm,primecell";
> reg = <0x0a000 0x1000>;
> interrupts = <6>;
> @@ -170,7 +170,7 @@
> clock-names = "uartclk", "apb_pclk";
> };
>
> - v2m_serial2: uart@0b000 {
> + v2m_serial2: uart@b000 {
> compatible = "arm,pl011", "arm,primecell";
> reg = <0x0b000 0x1000>;
> interrupts = <7>;
> @@ -178,7 +178,7 @@
> clock-names = "uartclk", "apb_pclk";
> };
>
> - v2m_serial3: uart@0c000 {
> + v2m_serial3: uart@c000 {
> compatible = "arm,pl011", "arm,primecell";
> reg = <0x0c000 0x1000>;
> interrupts = <8>;
> @@ -186,7 +186,7 @@
> clock-names = "uartclk", "apb_pclk";
> };
>
> - wdt@0f000 {
> + wdt@f000 {
> compatible = "arm,sp805", "arm,primecell";
> reg = <0x0f000 0x1000>;
> interrupts = <0>;
> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> index 15f4fd3f4695..0c8de0ca73ee 100644
> --- a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> +++ b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> @@ -220,7 +220,7 @@
> };
> };
>
> - smb@08000000 {
> + smb@8000000 {
> compatible = "simple-bus";
>
> #address-cells = <2>;
> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
> index bd107c5a0226..65ecf206388c 100644
> --- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
> +++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
> @@ -385,7 +385,7 @@
> };
> };
>
> - etb@0,20010000 {
> + etb@20010000 {
> compatible = "arm,coresight-etb10", "arm,primecell";
> reg = <0 0x20010000 0 0x1000>;
>
> @@ -399,7 +399,7 @@
> };
> };
>
> - tpiu@0,20030000 {
> + tpiu@20030000 {
> compatible = "arm,coresight-tpiu", "arm,primecell";
> reg = <0 0x20030000 0 0x1000>;
>
> @@ -449,7 +449,7 @@
> };
> };
>
> - funnel@0,20040000 {
> + funnel@20040000 {
> compatible = "arm,coresight-funnel", "arm,primecell";
> reg = <0 0x20040000 0 0x1000>;
>
> @@ -513,7 +513,7 @@
> };
> };
>
> - ptm@0,2201c000 {
> + ptm@2201c000 {
> compatible = "arm,coresight-etm3x", "arm,primecell";
> reg = <0 0x2201c000 0 0x1000>;
>
> @@ -527,7 +527,7 @@
> };
> };
>
> - ptm@0,2201d000 {
> + ptm@2201d000 {
> compatible = "arm,coresight-etm3x", "arm,primecell";
> reg = <0 0x2201d000 0 0x1000>;
>
> @@ -541,7 +541,7 @@
> };
> };
>
> - etm@0,2203c000 {
> + etm@2203c000 {
> compatible = "arm,coresight-etm3x", "arm,primecell";
> reg = <0 0x2203c000 0 0x1000>;
>
> @@ -555,7 +555,7 @@
> };
> };
>
> - etm@0,2203d000 {
> + etm@2203d000 {
> compatible = "arm,coresight-etm3x", "arm,primecell";
> reg = <0 0x2203d000 0 0x1000>;
>
> @@ -569,7 +569,7 @@
> };
> };
>
> - etm@0,2203e000 {
> + etm@2203e000 {
> compatible = "arm,coresight-etm3x", "arm,primecell";
> reg = <0 0x2203e000 0 0x1000>;
>
> @@ -583,7 +583,7 @@
> };
> };
>
> - smb@08000000 {
> + smb@8000000 {
> compatible = "simple-bus";
>
> #address-cells = <2>;
> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
> index 1acecaf4b13d..6e69b8e6c1a7 100644
> --- a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
> +++ b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
> @@ -190,7 +190,7 @@
> };
> };
>
> - smb@08000000 {
> + smb@8000000 {
> compatible = "simple-bus";
>
> #address-cells = <2>;
> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca9.dts b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
> index b608a03ee02f..c9305b58afc2 100644
> --- a/arch/arm/boot/dts/vexpress-v2p-ca9.dts
> +++ b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
> @@ -300,7 +300,7 @@
> };
> };
>
> - smb@04000000 {
> + smb@4000000 {
> compatible = "simple-bus";
>
> #address-cells = <2>;
> --
> 2.7.4
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox