* Re: [RESEND/PATCH v6 3/3] clk: qcom: Add A53 clock driver
From: Stephen Boyd @ 2016-11-02 22:55 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Georgi Djakov, mturquette, linux-clk, linux-kernel, linux-arm-msm,
devicetree, Rob Herring
In-Reply-To: <20161102205910.GQ25787@tuxbot>
On 11/02, Bjorn Andersson wrote:
> On Thu 27 Oct 18:54 PDT 2016, Stephen Boyd wrote:
>
> > On 10/19, Georgi Djakov wrote:
> > > Add a driver for the A53 Clock Controller. It is a hardware block that
> > > implements a combined mux and half integer divider functionality. It can
> > > choose between a fixed-rate clock or the dedicated A53 PLL. The source
> > > and the divider can be set both at the same time.
> > >
> > > This is required for enabling CPU frequency scaling on platforms like
> > > MSM8916.
> > >
> >
> > Please Cc DT reviewers.
> >
> > > Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> > > ---
> > > .../devicetree/bindings/clock/qcom,a53cc.txt | 22 +++
> > > drivers/clk/qcom/Kconfig | 8 ++
> > > drivers/clk/qcom/Makefile | 1 +
> > > drivers/clk/qcom/a53cc.c | 155 +++++++++++++++++++++
> > > 4 files changed, 186 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/clock/qcom,a53cc.txt
> > > create mode 100644 drivers/clk/qcom/a53cc.c
> > >
> > > diff --git a/Documentation/devicetree/bindings/clock/qcom,a53cc.txt b/Documentation/devicetree/bindings/clock/qcom,a53cc.txt
> > > new file mode 100644
> > > index 000000000000..a025f062f177
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/clock/qcom,a53cc.txt
> > > @@ -0,0 +1,22 @@
> > > +Qualcomm A53 CPU Clock Controller Binding
> > > +------------------------------------------------
> > > +The A53 CPU Clock Controller is hardware, which provides a combined
> > > +mux and divider functionality for the CPU clocks. It can choose between
> > > +a fixed rate clock and the dedicated A53 PLL.
> > > +
> > > +Required properties :
> > > +- compatible : shall contain:
> > > +
> > > + "qcom,a53cc"
> > > +
> > > +- reg : shall contain base register location and length
> > > + of the APCS region
> > > +- #clock-cells : shall contain 1
> > > +
> > > +Example:
> > > +
> > > + apcs: syscon@b011000 {
> > > + compatible = "qcom,a53cc", "syscon";
> >
> > Why is it a syscon? Is that part used?
> >
>
> I use the register at offset 8 for interrupting the other subsystems, so
> this must be available as something I can poke.
>
> Which makes me think that this should be described as a "simple-mfd" and
> "syscon" with the a53cc node as a child - grabbing the regmap of the
> syscon parent, rather then ioremapping the same region again.
>
That's sort of a question for DT reviewers. The register space
certainly seems like a free for all with a tilt toward power
management of the CPU, similar to how this was done on Krait
based designs.
I wonder why we didn't make up some provider/consumer binding for
the "kicking" feature used by SMD/RPM code. Then this could be a
clock provider and a "kick" provider (haha #kick-cells) and the
usage of syscon/regmap wouldn't be mandatory.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v4 6/8] dt-bindings: Add support for Amlogic GXBB SCPI Interface
From: Sudeep Holla @ 2016-11-02 22:20 UTC (permalink / raw)
To: Olof Johansson
Cc: Neil Armstrong, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-amlogic, Kevin Hilman, Heiko Stübner, wxt, frank.wang,
Sudeep Holla
In-Reply-To: <CAOesGMjY5_ibP7E9+DBf30nuV+2z2kecLv_ddnHjp3txuq+Kdg@mail.gmail.com>
On Sat, Oct 29, 2016 at 11:39:05AM -0700, Olof Johansson wrote:
> Hi,
>
>
> On Wed, Oct 5, 2016 at 12:33 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
> > Acked-by: Rob Herring <robh@kernel.org>
> > Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> > ---
> > Documentation/devicetree/bindings/arm/arm,scpi.txt | 8 +++++---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
> > index faa4b44..04bc171 100644
> > --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
> > +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
> > @@ -7,7 +7,7 @@ by Linux to initiate various system control and power operations.
> >
> > Required properties:
> >
> > -- compatible : should be "arm,scpi"
> > +- compatible : should be "arm,scpi" or "amlogic,meson-gxbb-scpi"
>
> This doesn't seem right to document here. If anything you might want
> to have a table of more-specific-compatibles for specific
> implementations, but "arm,scpi" should still be the compatible of the
> node (just not the most specific one).
>
I completely agree with you and I was pushing for a generic "arm,legacy-scpi"
compatible until this binding was acked by Rob.
Anyways, I will add the generic compatible and post the changes.
> Also, documenting it here indiciates that non-amlogic implementations
> can/should use that compatible, which is misleading.
>
Agreed, it's better to keep them out of this generic binding document.
> > - mboxes: List of phandle and mailbox channel specifiers
> > All the channels reserved by remote SCP firmware for use by
> > SCPI message protocol should be specified in any order
> > @@ -60,7 +60,8 @@ A small area of SRAM is reserved for SCPI communication between application
> > processors and SCP.
> >
> > Required properties:
> > -- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM on Juno
> > +- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM on Juno,
> > + or "amlogic,meson-gxbb-sram" for Amlogic GXBB SoC.
>
> Maybe you'd be better of with a meson-specific document that refers to
> these but with different compatible values.
>
> Come to think of it, the Juno-specific one maybe shouldn't be in
> arm,scpi at all, since that adds confusion here.
>
> It's somewhat confusing that ARM is both a platform, architecture and
> in some cases implementer of specific systems. :)
>
Sorry for that, I will move all juno specific references in the binding
out of this document(except the examples, which I assume should be fine)
> > The rest of the properties should follow the generic mmio-sram description
> > found in ../../sram/sram.txt
> > @@ -70,7 +71,8 @@ Each sub-node represents the reserved area for SCPI.
> > Required sub-node properties:
> > - reg : The base offset and size of the reserved area with the SRAM
> > - compatible : should be "arm,juno-scp-shmem" for Non-secure SRAM based
> > - shared memory on Juno platforms
> > + shared memory on Juno platforms or
> > + "amlogic,meson-gxbb-scp-shmem" for Amlogic GXBB SoC.
>
> Same here. It won't scale if all vendors are expected to add an entry here.
>
I will rework the patches to address the concerns as I too did share same
concern.
Hi Neil,
You may need to rework the DTS files based on that, please be aware of
that and make the necessary changes.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v5 2/2] clk: renesas: cpg-mssr: add R8A7743 support
From: Sergei Shtylyov @ 2016-11-02 21:59 UTC (permalink / raw)
To: mturquette-rdvid1DuHRBWk0Htik3J/w,
linux-clk-u79uwXL29TY76Z2rM5mHXA, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ
In-Reply-To: <1737840.BeMyoUTlpl-gHKXc3Y1Z8zGSmamagVegGFoWSdPRAKMAL8bYrjMMd8@public.gmane.org>
Add RZ/G1M (R8A7743) Clock Pulse Generator / Module Standby and Software
Reset support, using the CPG/MSSR driver core and the common R-Car Gen2
(and RZ/G) code.
Based on the proof-of-concept R8A7791 CPG/MSSR patch by Geert Uytterhoeven
<geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
---
Changes in version 5:
- describe the Z clock as PLL0/VCO divided by 2.
Changes in version 4:
- made use of the new RST driver's API to read the mode pins;
- cleaned up the table copied from the manual, fixed the manual reference.
Changes in version 3:
- exchanged Audio-DMAC0/1 entries in r8a7743_mod_clks[];
- renamed the I2C6 entry to IICDVFS;
- fixed the comment to the INTC-SYS entry in r8a7743_crit_mod_clks[];
- removed the useless EXTAL divisor check from r8a7743_cpg_mssr_init();
- added Rob's ACK and Geert's tag.
Changes in version 2:
- documented the R8A7743 device tree binding;
- fixed whitespace errors/warnings reported by checkpatch.pl;
- used tabs instead of spaces for indentation;
- fixed the PLL3 column name in the PLL table.
Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt | 4
drivers/clk/renesas/Kconfig | 1
drivers/clk/renesas/Makefile | 1
drivers/clk/renesas/r8a7743-cpg-mssr.c | 270 +++++++++++
drivers/clk/renesas/renesas-cpg-mssr.c | 6
drivers/clk/renesas/renesas-cpg-mssr.h | 1
6 files changed, 282 insertions(+), 1 deletion(-)
Index: renesas/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
===================================================================
--- renesas.orig/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
+++ renesas/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
@@ -13,6 +13,7 @@ They provide the following functionaliti
Required Properties:
- compatible: Must be one of:
+ - "renesas,r8a7743-cpg-mssr" for the r8a7743 SoC (RZ/G1M)
- "renesas,r8a7795-cpg-mssr" for the r8a7795 SoC (R-Car H3)
- "renesas,r8a7796-cpg-mssr" for the r8a7796 SoC (R-Car M3-W)
@@ -22,7 +23,8 @@ Required Properties:
- clocks: References to external parent clocks, one entry for each entry in
clock-names
- clock-names: List of external parent clock names. Valid names are:
- - "extal" (r8a7795, r8a7796)
+ - "extal" (r8a7743, r8a7795, r8a7796)
+ - "usb_extal" (r8a7743)
- "extalr" (r8a7795, r8a7796)
- #clock-cells: Must be 2
Index: renesas/drivers/clk/renesas/Kconfig
===================================================================
--- renesas.orig/drivers/clk/renesas/Kconfig
+++ renesas/drivers/clk/renesas/Kconfig
@@ -1,5 +1,6 @@
config CLK_RENESAS_CPG_MSSR
bool
+ default y if ARCH_R8A7743
default y if ARCH_R8A7795
default y if ARCH_R8A7796
Index: renesas/drivers/clk/renesas/Makefile
===================================================================
--- renesas.orig/drivers/clk/renesas/Makefile
+++ renesas/drivers/clk/renesas/Makefile
@@ -2,6 +2,7 @@ obj-$(CONFIG_ARCH_EMEV2) += clk-emev2.o
obj-$(CONFIG_ARCH_R7S72100) += clk-rz.o
obj-$(CONFIG_ARCH_R8A73A4) += clk-r8a73a4.o clk-div6.o
obj-$(CONFIG_ARCH_R8A7740) += clk-r8a7740.o clk-div6.o
+obj-$(CONFIG_ARCH_R8A7743) += r8a7743-cpg-mssr.o rcar-gen2-cpg.o
obj-$(CONFIG_ARCH_R8A7778) += clk-r8a7778.o
obj-$(CONFIG_ARCH_R8A7779) += clk-r8a7779.o
obj-$(CONFIG_ARCH_R8A7790) += clk-rcar-gen2.o clk-div6.o
Index: renesas/drivers/clk/renesas/r8a7743-cpg-mssr.c
===================================================================
--- /dev/null
+++ renesas/drivers/clk/renesas/r8a7743-cpg-mssr.c
@@ -0,0 +1,270 @@
+/*
+ * r8a7743 Clock Pulse Generator / Module Standby and Software Reset
+ *
+ * Copyright (C) 2016 Cogent Embedded Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation; of the License.
+ */
+
+#include <linux/device.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/soc/renesas/rcar-rst.h>
+
+#include <dt-bindings/clock/r8a7743-cpg-mssr.h>
+
+#include "renesas-cpg-mssr.h"
+#include "rcar-gen2-cpg.h"
+
+enum clk_ids {
+ /* Core Clock Outputs exported to DT */
+ LAST_DT_CORE_CLK = R8A7743_CLK_OSC,
+
+ /* External Input Clocks */
+ CLK_EXTAL,
+ CLK_USB_EXTAL,
+
+ /* Internal Core Clocks */
+ CLK_MAIN,
+ CLK_PLL0,
+ CLK_PLL1,
+ CLK_PLL3,
+ CLK_PLL1_DIV2,
+
+ /* Module Clocks */
+ MOD_CLK_BASE
+};
+
+static const struct cpg_core_clk r8a7743_core_clks[] __initconst = {
+ /* External Clock Inputs */
+ DEF_INPUT("extal", CLK_EXTAL),
+ DEF_INPUT("usb_extal", CLK_USB_EXTAL),
+
+ /* Internal Core Clocks */
+ DEF_BASE(".main", CLK_MAIN, CLK_TYPE_GEN2_MAIN, CLK_EXTAL),
+ DEF_BASE(".pll0", CLK_PLL0, CLK_TYPE_GEN2_PLL0, CLK_MAIN),
+ DEF_BASE(".pll1", CLK_PLL1, CLK_TYPE_GEN2_PLL1, CLK_MAIN),
+ DEF_BASE(".pll3", CLK_PLL3, CLK_TYPE_GEN2_PLL3, CLK_MAIN),
+
+ DEF_FIXED(".pll1_div2", CLK_PLL1_DIV2, CLK_PLL1, 2, 1),
+
+ /* Core Clock Outputs */
+ DEF_BASE("lb", R8A7743_CLK_LB, CLK_TYPE_GEN2_LB, CLK_PLL1),
+ DEF_BASE("sdh", R8A7743_CLK_SDH, CLK_TYPE_GEN2_SDH, CLK_PLL1),
+ DEF_BASE("sd0", R8A7743_CLK_SD0, CLK_TYPE_GEN2_SD0, CLK_PLL1),
+ DEF_BASE("qspi", R8A7743_CLK_QSPI, CLK_TYPE_GEN2_QSPI, CLK_PLL1_DIV2),
+ DEF_BASE("rcan", R8A7743_CLK_RCAN, CLK_TYPE_GEN2_RCAN, CLK_USB_EXTAL),
+
+ DEF_FIXED("z", R8A7743_CLK_Z, CLK_PLL0, 2, 1),
+ DEF_FIXED("zg", R8A7743_CLK_ZG, CLK_PLL1, 3, 1),
+ DEF_FIXED("zx", R8A7743_CLK_ZX, CLK_PLL1, 3, 1),
+ DEF_FIXED("zs", R8A7743_CLK_ZS, CLK_PLL1, 6, 1),
+ DEF_FIXED("hp", R8A7743_CLK_HP, CLK_PLL1, 12, 1),
+ DEF_FIXED("b", R8A7743_CLK_B, CLK_PLL1, 12, 1),
+ DEF_FIXED("p", R8A7743_CLK_P, CLK_PLL1, 24, 1),
+ DEF_FIXED("cl", R8A7743_CLK_CL, CLK_PLL1, 48, 1),
+ DEF_FIXED("m2", R8A7743_CLK_M2, CLK_PLL1, 8, 1),
+ DEF_FIXED("zb3", R8A7743_CLK_ZB3, CLK_PLL3, 4, 1),
+ DEF_FIXED("zb3d2", R8A7743_CLK_ZB3D2, CLK_PLL3, 8, 1),
+ DEF_FIXED("ddr", R8A7743_CLK_DDR, CLK_PLL3, 8, 1),
+ DEF_FIXED("mp", R8A7743_CLK_MP, CLK_PLL1_DIV2, 15, 1),
+ DEF_FIXED("cp", R8A7743_CLK_CP, CLK_EXTAL, 2, 1),
+ DEF_FIXED("r", R8A7743_CLK_R, CLK_PLL1, 49152, 1),
+ DEF_FIXED("osc", R8A7743_CLK_OSC, CLK_PLL1, 12288, 1),
+
+ DEF_DIV6P1("sd2", R8A7743_CLK_SD2, CLK_PLL1_DIV2, 0x078),
+ DEF_DIV6P1("sd3", R8A7743_CLK_SD3, CLK_PLL1_DIV2, 0x26c),
+ DEF_DIV6P1("mmc0", R8A7743_CLK_MMC0, CLK_PLL1_DIV2, 0x240),
+};
+
+static const struct mssr_mod_clk r8a7743_mod_clks[] __initconst = {
+ DEF_MOD("msiof0", 0, R8A7743_CLK_MP),
+ DEF_MOD("vcp0", 101, R8A7743_CLK_ZS),
+ DEF_MOD("vpc0", 103, R8A7743_CLK_ZS),
+ DEF_MOD("tmu1", 111, R8A7743_CLK_P),
+ DEF_MOD("3dg", 112, R8A7743_CLK_ZG),
+ DEF_MOD("2d-dmac", 115, R8A7743_CLK_ZS),
+ DEF_MOD("fdp1-1", 118, R8A7743_CLK_ZS),
+ DEF_MOD("fdp1-0", 119, R8A7743_CLK_ZS),
+ DEF_MOD("tmu3", 121, R8A7743_CLK_P),
+ DEF_MOD("tmu2", 122, R8A7743_CLK_P),
+ DEF_MOD("cmt0", 124, R8A7743_CLK_R),
+ DEF_MOD("tmu0", 125, R8A7743_CLK_CP),
+ DEF_MOD("vsp1du1", 127, R8A7743_CLK_ZS),
+ DEF_MOD("vsp1du0", 128, R8A7743_CLK_ZS),
+ DEF_MOD("vsp1-sy", 131, R8A7743_CLK_ZS),
+ DEF_MOD("scifa2", 202, R8A7743_CLK_MP),
+ DEF_MOD("scifa1", 203, R8A7743_CLK_MP),
+ DEF_MOD("scifa0", 204, R8A7743_CLK_MP),
+ DEF_MOD("msiof2", 205, R8A7743_CLK_MP),
+ DEF_MOD("scifb0", 206, R8A7743_CLK_MP),
+ DEF_MOD("scifb1", 207, R8A7743_CLK_MP),
+ DEF_MOD("msiof1", 208, R8A7743_CLK_MP),
+ DEF_MOD("scifb2", 216, R8A7743_CLK_MP),
+ DEF_MOD("sys-dmac1", 218, R8A7743_CLK_ZS),
+ DEF_MOD("sys-dmac0", 219, R8A7743_CLK_ZS),
+ DEF_MOD("tpu0", 304, R8A7743_CLK_CP),
+ DEF_MOD("sdhi3", 311, R8A7743_CLK_SD3),
+ DEF_MOD("sdhi2", 312, R8A7743_CLK_SD2),
+ DEF_MOD("sdhi0", 314, R8A7743_CLK_SD0),
+ DEF_MOD("mmcif0", 315, R8A7743_CLK_MMC0),
+ DEF_MOD("iic0", 318, R8A7743_CLK_HP),
+ DEF_MOD("pciec", 319, R8A7743_CLK_MP),
+ DEF_MOD("iic1", 323, R8A7743_CLK_HP),
+ DEF_MOD("usb3.0", 328, R8A7743_CLK_MP),
+ DEF_MOD("cmt1", 329, R8A7743_CLK_R),
+ DEF_MOD("usbhs-dmac0", 330, R8A7743_CLK_HP),
+ DEF_MOD("usbhs-dmac1", 331, R8A7743_CLK_HP),
+ DEF_MOD("irqc", 407, R8A7743_CLK_CP),
+ DEF_MOD("intc-sys", 408, R8A7743_CLK_ZS),
+ DEF_MOD("audio-dmac1", 501, R8A7743_CLK_HP),
+ DEF_MOD("audio-dmac0", 502, R8A7743_CLK_HP),
+ DEF_MOD("thermal", 522, CLK_EXTAL),
+ DEF_MOD("pwm", 523, R8A7743_CLK_P),
+ DEF_MOD("usb-ehci", 703, R8A7743_CLK_MP),
+ DEF_MOD("usbhs", 704, R8A7743_CLK_HP),
+ DEF_MOD("hscif2", 713, R8A7743_CLK_ZS),
+ DEF_MOD("scif5", 714, R8A7743_CLK_P),
+ DEF_MOD("scif4", 715, R8A7743_CLK_P),
+ DEF_MOD("hscif1", 716, R8A7743_CLK_ZS),
+ DEF_MOD("hscif0", 717, R8A7743_CLK_ZS),
+ DEF_MOD("scif3", 718, R8A7743_CLK_P),
+ DEF_MOD("scif2", 719, R8A7743_CLK_P),
+ DEF_MOD("scif1", 720, R8A7743_CLK_P),
+ DEF_MOD("scif0", 721, R8A7743_CLK_P),
+ DEF_MOD("du1", 723, R8A7743_CLK_ZX),
+ DEF_MOD("du0", 724, R8A7743_CLK_ZX),
+ DEF_MOD("lvds0", 726, R8A7743_CLK_ZX),
+ DEF_MOD("ipmmu-sgx", 800, R8A7743_CLK_ZX),
+ DEF_MOD("vin2", 809, R8A7743_CLK_ZG),
+ DEF_MOD("vin1", 810, R8A7743_CLK_ZG),
+ DEF_MOD("vin0", 811, R8A7743_CLK_ZG),
+ DEF_MOD("etheravb", 812, R8A7743_CLK_HP),
+ DEF_MOD("ether", 813, R8A7743_CLK_P),
+ DEF_MOD("sata1", 814, R8A7743_CLK_ZS),
+ DEF_MOD("sata0", 815, R8A7743_CLK_ZS),
+ DEF_MOD("gpio7", 904, R8A7743_CLK_CP),
+ DEF_MOD("gpio6", 905, R8A7743_CLK_CP),
+ DEF_MOD("gpio5", 907, R8A7743_CLK_CP),
+ DEF_MOD("gpio4", 908, R8A7743_CLK_CP),
+ DEF_MOD("gpio3", 909, R8A7743_CLK_CP),
+ DEF_MOD("gpio2", 910, R8A7743_CLK_CP),
+ DEF_MOD("gpio1", 911, R8A7743_CLK_CP),
+ DEF_MOD("gpio0", 912, R8A7743_CLK_CP),
+ DEF_MOD("can1", 915, R8A7743_CLK_P),
+ DEF_MOD("can0", 916, R8A7743_CLK_P),
+ DEF_MOD("qspi_mod", 917, R8A7743_CLK_QSPI),
+ DEF_MOD("i2c5", 925, R8A7743_CLK_HP),
+ DEF_MOD("iicdvfs", 926, R8A7743_CLK_CP),
+ DEF_MOD("i2c4", 927, R8A7743_CLK_HP),
+ DEF_MOD("i2c3", 928, R8A7743_CLK_HP),
+ DEF_MOD("i2c2", 929, R8A7743_CLK_HP),
+ DEF_MOD("i2c1", 930, R8A7743_CLK_HP),
+ DEF_MOD("i2c0", 931, R8A7743_CLK_HP),
+ DEF_MOD("ssi-all", 1005, R8A7743_CLK_P),
+ DEF_MOD("ssi9", 1006, MOD_CLK_ID(1005)),
+ DEF_MOD("ssi8", 1007, MOD_CLK_ID(1005)),
+ DEF_MOD("ssi7", 1008, MOD_CLK_ID(1005)),
+ DEF_MOD("ssi6", 1009, MOD_CLK_ID(1005)),
+ DEF_MOD("ssi5", 1010, MOD_CLK_ID(1005)),
+ DEF_MOD("ssi4", 1011, MOD_CLK_ID(1005)),
+ DEF_MOD("ssi3", 1012, MOD_CLK_ID(1005)),
+ DEF_MOD("ssi2", 1013, MOD_CLK_ID(1005)),
+ DEF_MOD("ssi1", 1014, MOD_CLK_ID(1005)),
+ DEF_MOD("ssi0", 1015, MOD_CLK_ID(1005)),
+ DEF_MOD("scu-all", 1017, R8A7743_CLK_P),
+ DEF_MOD("scu-dvc1", 1018, MOD_CLK_ID(1017)),
+ DEF_MOD("scu-dvc0", 1019, MOD_CLK_ID(1017)),
+ DEF_MOD("scu-ctu1-mix1", 1020, MOD_CLK_ID(1017)),
+ DEF_MOD("scu-ctu0-mix0", 1021, MOD_CLK_ID(1017)),
+ DEF_MOD("scu-src9", 1022, MOD_CLK_ID(1017)),
+ DEF_MOD("scu-src8", 1023, MOD_CLK_ID(1017)),
+ DEF_MOD("scu-src7", 1024, MOD_CLK_ID(1017)),
+ DEF_MOD("scu-src6", 1025, MOD_CLK_ID(1017)),
+ DEF_MOD("scu-src5", 1026, MOD_CLK_ID(1017)),
+ DEF_MOD("scu-src4", 1027, MOD_CLK_ID(1017)),
+ DEF_MOD("scu-src3", 1028, MOD_CLK_ID(1017)),
+ DEF_MOD("scu-src2", 1029, MOD_CLK_ID(1017)),
+ DEF_MOD("scu-src1", 1030, MOD_CLK_ID(1017)),
+ DEF_MOD("scu-src0", 1031, MOD_CLK_ID(1017)),
+ DEF_MOD("scifa3", 1106, R8A7743_CLK_MP),
+ DEF_MOD("scifa4", 1107, R8A7743_CLK_MP),
+ DEF_MOD("scifa5", 1108, R8A7743_CLK_MP),
+};
+
+static const unsigned int r8a7743_crit_mod_clks[] __initconst = {
+ MOD_CLK_ID(408), /* INTC-SYS (GIC) */
+};
+
+/*
+ * CPG Clock Data
+ */
+
+/*
+ * MD EXTAL PLL0 PLL1 PLL3
+ * 14 13 19 (MHz) *1 *1
+ *---------------------------------------------------
+ * 0 0 0 15 x172/2 x208/2 x106
+ * 0 0 1 15 x172/2 x208/2 x88
+ * 0 1 0 20 x130/2 x156/2 x80
+ * 0 1 1 20 x130/2 x156/2 x66
+ * 1 0 0 26 / 2 x200/2 x240/2 x122
+ * 1 0 1 26 / 2 x200/2 x240/2 x102
+ * 1 1 0 30 / 2 x172/2 x208/2 x106
+ * 1 1 1 30 / 2 x172/2 x208/2 x88
+ *
+ * *1 : Table 7.5a indicates VCO output (PLLx = VCO/2)
+ */
+#define CPG_PLL_CONFIG_INDEX(md) ((((md) & BIT(14)) >> 12) | \
+ (((md) & BIT(13)) >> 12) | \
+ (((md) & BIT(19)) >> 19))
+
+static const struct rcar_gen2_cpg_pll_config cpg_pll_configs[8] __initconst = {
+ /* EXTAL div PLL1 mult PLL3 mult */
+ { 1, 208, 106, },
+ { 1, 208, 88, },
+ { 1, 156, 80, },
+ { 1, 156, 66, },
+ { 2, 240, 122, },
+ { 2, 240, 102, },
+ { 2, 208, 106, },
+ { 2, 208, 88, },
+};
+
+static int __init r8a7743_cpg_mssr_init(struct device *dev)
+{
+ const struct rcar_gen2_cpg_pll_config *cpg_pll_config;
+ u32 cpg_mode;
+ int error;
+
+ error = rcar_rst_read_mode_pins(&cpg_mode);
+ if (error)
+ return error;
+
+ cpg_pll_config = &cpg_pll_configs[CPG_PLL_CONFIG_INDEX(cpg_mode)];
+
+ return rcar_gen2_cpg_init(cpg_pll_config);
+}
+
+const struct cpg_mssr_info r8a7743_cpg_mssr_info __initconst = {
+ /* Core Clocks */
+ .core_clks = r8a7743_core_clks,
+ .num_core_clks = ARRAY_SIZE(r8a7743_core_clks),
+ .last_dt_core_clk = LAST_DT_CORE_CLK,
+ .num_total_core_clks = MOD_CLK_BASE,
+
+ /* Module Clocks */
+ .mod_clks = r8a7743_mod_clks,
+ .num_mod_clks = ARRAY_SIZE(r8a7743_mod_clks),
+ .num_hw_mod_clks = 12 * 32,
+
+ /* Critical Module Clocks */
+ .crit_mod_clks = r8a7743_crit_mod_clks,
+ .num_crit_mod_clks = ARRAY_SIZE(r8a7743_crit_mod_clks),
+
+ /* Callbacks */
+ .init = r8a7743_cpg_mssr_init,
+ .cpg_clk_register = rcar_gen2_cpg_clk_register,
+};
Index: renesas/drivers/clk/renesas/renesas-cpg-mssr.c
===================================================================
--- renesas.orig/drivers/clk/renesas/renesas-cpg-mssr.c
+++ renesas/drivers/clk/renesas/renesas-cpg-mssr.c
@@ -503,6 +503,12 @@ static int __init cpg_mssr_add_clk_domai
}
static const struct of_device_id cpg_mssr_match[] = {
+#ifdef CONFIG_ARCH_R8A7743
+ {
+ .compatible = "renesas,r8a7743-cpg-mssr",
+ .data = &r8a7743_cpg_mssr_info,
+ },
+#endif
#ifdef CONFIG_ARCH_R8A7795
{
.compatible = "renesas,r8a7795-cpg-mssr",
Index: renesas/drivers/clk/renesas/renesas-cpg-mssr.h
===================================================================
--- renesas.orig/drivers/clk/renesas/renesas-cpg-mssr.h
+++ renesas/drivers/clk/renesas/renesas-cpg-mssr.h
@@ -130,6 +130,7 @@ struct cpg_mssr_info {
struct clk **clks, void __iomem *base);
};
+extern const struct cpg_mssr_info r8a7743_cpg_mssr_info;
extern const struct cpg_mssr_info r8a7795_cpg_mssr_info;
extern const struct cpg_mssr_info r8a7796_cpg_mssr_info;
#endif
--
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 v5 1/2] ARM: shmobile: r8a7743: add CPG clock index macros
From: Sergei Shtylyov @ 2016-11-02 21:57 UTC (permalink / raw)
To: robh+dt, mark.rutland, devicetree
Cc: mturquette, linux-clk, sboyd, linux-renesas-soc, horms+renesas
In-Reply-To: <1737840.BeMyoUTlpl@wasted.cogentembedded.com>
Add macros usable by the device tree sources to reference the R8A7743 CPG
clocks by index. The data comes from the table 7.2b in the revision 0.50
of the RZ/G Series User's Manual.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Changes in version 4:
- added Geert's tag.
Changes in version 3:
- renumbered the #define's in order to match the R8A7791 CPG clocks;
- added the reference to the manual in the patch description.
Changes in version 2:
- reduced the macro value indentation.
include/dt-bindings/clock/r8a7743-cpg-mssr.h | 43 +++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
Index: linux/include/dt-bindings/clock/r8a7743-cpg-mssr.h
===================================================================
--- /dev/null
+++ linux/include/dt-bindings/clock/r8a7743-cpg-mssr.h
@@ -0,0 +1,43 @@
+/*
+ * Copyright (C) 2016 Cogent Embedded Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#ifndef __DT_BINDINGS_CLOCK_R8A7743_CPG_MSSR_H__
+#define __DT_BINDINGS_CLOCK_R8A7743_CPG_MSSR_H__
+
+#include <dt-bindings/clock/renesas-cpg-mssr.h>
+
+/* r8a7743 CPG Core Clocks */
+#define R8A7743_CLK_Z 0
+#define R8A7743_CLK_ZG 1
+#define R8A7743_CLK_ZTR 2
+#define R8A7743_CLK_ZTRD2 3
+#define R8A7743_CLK_ZT 4
+#define R8A7743_CLK_ZX 5
+#define R8A7743_CLK_ZS 6
+#define R8A7743_CLK_HP 7
+#define R8A7743_CLK_B 9
+#define R8A7743_CLK_LB 10
+#define R8A7743_CLK_P 11
+#define R8A7743_CLK_CL 12
+#define R8A7743_CLK_M2 13
+#define R8A7743_CLK_ZB3 15
+#define R8A7743_CLK_ZB3D2 16
+#define R8A7743_CLK_DDR 17
+#define R8A7743_CLK_SDH 18
+#define R8A7743_CLK_SD0 19
+#define R8A7743_CLK_SD2 20
+#define R8A7743_CLK_SD3 21
+#define R8A7743_CLK_MMC0 22
+#define R8A7743_CLK_MP 23
+#define R8A7743_CLK_QSPI 26
+#define R8A7743_CLK_CP 27
+#define R8A7743_CLK_RCAN 28
+#define R8A7743_CLK_R 29
+#define R8A7743_CLK_OSC 30
+
+#endif /* __DT_BINDINGS_CLOCK_R8A7743_CPG_MSSR_H__ */
^ permalink raw reply
* Re: [PATCH v3 3/4] ARM: dts: pxa: add pxa27x cpu operating points
From: Robert Jarzmik @ 2016-11-02 21:54 UTC (permalink / raw)
To: Daniel Mack
Cc: Haojian Zhuang, Rob Herring, Mark Rutland, Rafael J Wysocki,
Viresh Kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm
In-Reply-To: <1477943696-23477-4-git-send-email-robert.jarzmik@free.fr>
Robert Jarzmik <robert.jarzmik@free.fr> writes:
> Add the relevant data taken from the PXA27x Electrical, Mechanical, and
> Thermal Specfication. This will be input data for cpufreq-dt driver.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
> Since v2: opp definition amended as per Viresh's comment
Queued to pxa/dt.
--
Robert
^ permalink raw reply
* [PATCH v5 0/2] Renesas R8A7743 CPG/MSSR clock support
From: Sergei Shtylyov @ 2016-11-02 21:53 UTC (permalink / raw)
To: mturquette-rdvid1DuHRBWk0Htik3J/w,
linux-clk-u79uwXL29TY76Z2rM5mHXA, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ
Hello.
Here's the set of 2 patches against the 'clk-next' branch of CLK group's
'linux.git' repo. I've split them from the R-Car gen2 common support patch.
As the DT patches in the R8A7743/SK-RZG1M board support series depend on the
patch #1 of this series, it might make sense to merge this patch to the
'renesas.git' repo as well...
[1/2] ARM: shmobile: r8a7743: add CPG clock index macros
[2/2] clk: renesas: cpg-mssr: add R8A7743 support
MBR, Sergei
--
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 v3 2/4] ARM: dts: pxa: add pxa25x cpu operating points
From: Robert Jarzmik @ 2016-11-02 21:53 UTC (permalink / raw)
To: Daniel Mack
Cc: Haojian Zhuang, Rob Herring, Mark Rutland, Rafael J Wysocki,
Viresh Kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm
In-Reply-To: <1477943696-23477-3-git-send-email-robert.jarzmik@free.fr>
Robert Jarzmik <robert.jarzmik@free.fr> writes:
> Add the relevant data taken from the PXA 25x Electrical, Mechanical, and
> Thermal Specfication. This will be input data for cpufreq-dt driver.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
> Since v2: opp definition amended as per Viresh's comment
Queued to pxa/dt.
--
Robert
^ permalink raw reply
* RE: [PATCH/RESEND V4 2/3] ARM64 LPC: Add missing range exception for special ISA
From: Gabriele Paoloni @ 2016-11-02 21:51 UTC (permalink / raw)
To: Bjorn Helgaas, Yuanzhichang
Cc: catalin.marinas@arm.com, will.deacon@arm.com, robh+dt@kernel.org,
bhelgaas@google.com, mark.rutland@arm.com, arnd@arndb.de,
linux-arm-kernel@lists.infradead.org, lorenzo.pieralisi@arm.com,
linux-kernel@vger.kernel.org, Linuxarm,
devicetree@vger.kernel.org, linux-pci@vger.kernel.org,
linux-serial@vger.kernel.org, minyard@acm.org,
benh@kernel.crashing.org
In-Reply-To: <20161101165934.GA5149@bhelgaas-glaptop.roam.corp.google.com>
Hi Bjorn
Many Thanks for reviewing this
> -----Original Message-----
> From: Bjorn Helgaas [mailto:helgaas@kernel.org]
> Sent: 01 November 2016 17:00
> To: Yuanzhichang
> Cc: catalin.marinas@arm.com; will.deacon@arm.com; robh+dt@kernel.org;
> bhelgaas@google.com; mark.rutland@arm.com; arnd@arndb.de; linux-arm-
> kernel@lists.infradead.org; lorenzo.pieralisi@arm.com; linux-
> kernel@vger.kernel.org; Linuxarm; devicetree@vger.kernel.org; linux-
> pci@vger.kernel.org; linux-serial@vger.kernel.org; minyard@acm.org;
> benh@kernel.crashing.org; liviu.dudau@arm.com; zourongrong@gmail.com;
> John Garry; Gabriele Paoloni; zhichang.yuan02@gmail.com;
> kantyzc@163.com; xuwei (O)
> Subject: Re: [PATCH/RESEND V4 2/3] ARM64 LPC: Add missing range
> exception for special ISA
>
> On Tue, Nov 01, 2016 at 09:28:45PM +0800, zhichang.yuan wrote:
> > Currently if the range property is not specified of_translate_one
> > returns an error. There are some special devices that work on a
> > range of I/O ports where it's is not correct to specify a range
> > property as the cpu addresses are used by special accessors.
> > Here we add a new exception in of_translate_one to return
> > the cpu address if the range property is not there. The exception
> > checks if the parent bus is ISA and if the special accessors are
> > defined.
>
> Using "()" after function names helps distinguish them from text.
>
> s/it's is/it's/
Sure we'll fix above nits in the next version
>
> I haven't been paying attention, so I missed the context. But "as the
> cpu addresses are used by special accessors" doesn't really make sense
> to me. In general, *most* acccessors use CPU addresses, i.e.,
> resource addresses. Accessors don't use bus addresses because we may
> have multiple instances of a bus, and we may reuse bus address ranges
> on the different instances.
Basically our LPC device use a CPU address range (not a bus range as
a bus range is supposed to be remapped into a cpu range using the range
property).
This CPIU address range is [0, PCIBIOS_MIN_IO-1].
This patch effectively does 2 things:
1) reserve the cpu physical range [0, PCIBIOS_MIN_IO-1] so that it cannot
be used by PCI I/O space (see drivers/pci/pci.c)
2) Avoid to translate the cpu addresses that belongs to LPC (in fact
for this device we do not specify a range property in the DT): see
changes in __of_translate_address()
3) Do not retrieve an I/O token for I/O addresses that belong to LPC
(in fact LPC accessors work directly on the CPU physical addresses):
see change in __of_address_to_resource()
Probably 1) and 3) can be put in a separate patch with respect to 2)...
What do you think?
>
> In the patch, I see a check for "parent bus is ISA"
> ("of_bus_isa_match(parent)"), but I don't see the check for whether
> the special accessors are defined, so I can't quite connect the dots.
See of_isa_indirect_io() called just before of_bus_isa_match(parent)...
>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Signed-off-by: zhichang.yuan <yuanzhichang@hisilicon.com>
> > Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
> > ---
> > arch/arm64/include/asm/io.h | 7 +++++++
> > arch/arm64/kernel/extio.c | 24 +++++++++++++++++++++++
> > drivers/of/address.c | 47
> +++++++++++++++++++++++++++++++++++++++++++--
> > drivers/pci/pci.c | 6 +++---
> > include/linux/of_address.h | 17 ++++++++++++++++
> > 5 files changed, 96 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/io.h
> b/arch/arm64/include/asm/io.h
> > index 136735d..e480199 100644
> > --- a/arch/arm64/include/asm/io.h
> > +++ b/arch/arm64/include/asm/io.h
> > @@ -175,6 +175,13 @@ static inline u64 __raw_readq(const volatile
> void __iomem *addr)
> > #define outsl outsl
> >
> > DECLARE_EXTIO(l, u32)
> > +
> > +
> > +#define indirect_io_ison indirect_io_ison
> > +extern int indirect_io_ison(void);
>
> This makes it look like "ison" is some new word I'm not familiar with.
> "indirect_io_is_on()" or even "indirect_io_enabled()" would be more
> readable.
Sure agreed
>
> > +
> > +#define chk_indirect_range chk_indirect_range
> > +extern int chk_indirect_range(u64 taddr);
> > #endif
> >
> >
> > diff --git a/arch/arm64/kernel/extio.c b/arch/arm64/kernel/extio.c
> > index 80cafd5..55df8dc 100644
> > --- a/arch/arm64/kernel/extio.c
> > +++ b/arch/arm64/kernel/extio.c
> > @@ -19,6 +19,30 @@
> >
> > struct extio_ops *arm64_extio_ops;
> >
> > +/**
> > + * indirect_io_ison - check whether indirectIO can work well. This
> function only call
> > + * before the target I/O address was obtained.
> > + *
> > + * Returns 1 when indirectIO can work.
> > + */
> > +int indirect_io_ison()
> > +{
> > + return arm64_extio_ops ? 1 : 0;
> > +}
> > +
> > +/**
> > + * check_indirect_io - check whether the input taddr is for
> indirectIO.
>
> Comment name ("check_indirect_io") doesn't match actual function name
> ("chk_indirect_range").
>
> One of my pet peeves: "check" is completely worthless as part of a
> function name because it doesn't help the reader figure out the sense
> of the result. What does a "true" result mean? Name it something
> like "address_is_indirect()" so it reads naturally when the caller
> does something like "if (address_is_indirect())"
Yes it makes sense, we can change to " address_is_indirect"
>
> > + * @taddr: the io address to be checked.
> > + *
> > + * Returns 1 when taddr is in the range; otherwise return 0.
> > + */
> > +int chk_indirect_range(u64 taddr)
> > +{
> > + if (arm64_extio_ops->start > taddr || arm64_extio_ops->end <
> taddr)
> > + return 0;
> > +
> > + return 1;
> > +}
> >
> > BUILD_EXTIO(b, u8)
> >
> > diff --git a/drivers/of/address.c b/drivers/of/address.c
> > index 02b2903..0bee822 100644
> > --- a/drivers/of/address.c
> > +++ b/drivers/of/address.c
> > @@ -479,6 +479,39 @@ static int of_empty_ranges_quirk(struct
> device_node *np)
> > return false;
> > }
> >
> > +
> > +/*
> > + * Check whether the current device being translating use
> indirectIO.
>
> What does "the current device" mean? I assume you're talking about
> "any device on 'bus'"? And apparently the caller is inquiring about a
> particular address, too?
Effectively we check if the device is lying on a ISA bus, if the accessors
struct pointer is set, if the parent device is an ISA bus and if the device
physical addresses are within the range reserved for LPC...
So we check all the conditions that allow us to say that this device
is lying on a special ISA bus device
>
> > + * return 1 if the check is past, or 0 represents fail checking.
>
> This doesn't really make sense. I assume you mean something like
> "return 1 if 'address' uses indirectIO; 0 otherwise"?
Yes the comment is quite bad; we'll change this in the next version
>
> > + */
> > +static int of_isa_indirect_io(struct device_node *parent,
> > + struct of_bus *bus, __be32 *addr,
> > + int na, u64 *presult)
> > +{
> > + unsigned int flags;
> > + unsigned int rlen;
> > +
> > + /* whether support indirectIO */
> > + if (!indirect_io_ison())
> > + return 0;
> > +
> > + if (!of_bus_isa_match(parent))
> > + return 0;
> > +
> > + flags = bus->get_flags(addr);
> > + if (!(flags & IORESOURCE_IO))
> > + return 0;
> > +
> > + /* there is ranges property, apply the normal translation
> directly. */
> > + if (of_get_property(parent, "ranges", &rlen))
> > + return 0;
> > +
> > + *presult = of_read_number(addr + 1, na - 1);
> > +
> > + return chk_indirect_range(*presult);
> > +}
> > +
> > static int of_translate_one(struct device_node *parent, struct
> of_bus *bus,
> > struct of_bus *pbus, __be32 *addr,
> > int na, int ns, int pna, const char *rprop)
> > @@ -532,7 +565,7 @@ static int of_translate_one(struct device_node
> *parent, struct of_bus *bus,
> > }
> > memcpy(addr, ranges + na, 4 * pna);
> >
> > - finish:
> > +finish:
> > of_dump_addr("parent translation for:", addr, pna);
> > pr_debug("with offset: %llx\n", (unsigned long long)offset);
> >
> > @@ -595,6 +628,15 @@ static u64 __of_translate_address(struct
> device_node *dev,
> > result = of_read_number(addr, na);
> > break;
> > }
> > + /*
> > + * For indirectIO device which has no ranges property, get
> > + * the address from reg directly.
> > + */
> > + if (of_isa_indirect_io(dev, bus, addr, na, &result)) {
> > + pr_info("isa indirectIO matched(%s)..addr =
> 0x%llx\n",
> > + of_node_full_name(dev), result);
> > + break;
> > + }
> >
> > /* Get new parent bus and counts */
> > pbus = of_match_bus(parent);
> > @@ -688,8 +730,9 @@ static int __of_address_to_resource(struct
> device_node *dev,
> > if (taddr == OF_BAD_ADDR)
> > return -EINVAL;
> > memset(r, 0, sizeof(struct resource));
> > - if (flags & IORESOURCE_IO) {
> > + if (flags & IORESOURCE_IO && taddr >= PCIBIOS_MIN_IO) {
> > unsigned long port;
> > +
> > port = pci_address_to_pio(taddr);
> > if (port == (unsigned long)-1)
> > return -EINVAL;
> > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > index ba34907..1a08511 100644
> > --- a/drivers/pci/pci.c
> > +++ b/drivers/pci/pci.c
> > @@ -3263,7 +3263,7 @@ int __weak pci_register_io_range(phys_addr_t
> addr, resource_size_t size)
> >
> > #ifdef PCI_IOBASE
> > struct io_range *range;
> > - resource_size_t allocated_size = 0;
> > + resource_size_t allocated_size = PCIBIOS_MIN_IO;
>
> I don't understand what's going on here. PCIBIOS_MIN_IO is an
> *address*, so you're setting a *size* to an address. Maybe this just
> needs an explanation. The connection to the rest of this patch isn't
> obvious. If it could be split to a separate patch, so much the
> better; then you'd have a nice place to describe it.
Please see my first comment above...this is needed to reserve the
cpu address range for the LPC...
>
> > /* check if the range hasn't been previously recorded */
> > spin_lock(&io_range_lock);
> > @@ -3312,7 +3312,7 @@ phys_addr_t pci_pio_to_address(unsigned long
> pio)
> >
> > #ifdef PCI_IOBASE
> > struct io_range *range;
> > - resource_size_t allocated_size = 0;
> > + resource_size_t allocated_size = PCIBIOS_MIN_IO;
> >
> > if (pio > IO_SPACE_LIMIT)
> > return address;
> > @@ -3335,7 +3335,7 @@ unsigned long __weak
> pci_address_to_pio(phys_addr_t address)
> > {
> > #ifdef PCI_IOBASE
> > struct io_range *res;
> > - resource_size_t offset = 0;
> > + resource_size_t offset = PCIBIOS_MIN_IO;
> > unsigned long addr = -1;
> >
> > spin_lock(&io_range_lock);
> > diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> > index 3786473..0ba7e21 100644
> > --- a/include/linux/of_address.h
> > +++ b/include/linux/of_address.h
> > @@ -24,6 +24,23 @@ struct of_pci_range {
> > #define for_each_of_pci_range(parser, range) \
> > for (; of_pci_range_parser_one(parser, range);)
> >
> > +
> > +#ifndef indirect_io_ison
> > +#define indirect_io_ison indirect_io_ison
> > +static inline int indirect_io_ison(void)
> > +{
> > + return 0;
> > +}
> > +#endif
> > +
> > +#ifndef chk_indirect_range
> > +#define chk_indirect_range chk_indirect_range
> > +static inline int chk_indirect_range(u64 taddr)
> > +{
> > + return 0;
> > +}
> > +#endif
> > +
> > /* Translate a DMA address from device space to CPU space */
> > extern u64 of_translate_dma_address(struct device_node *dev,
> > const __be32 *in_addr);
> > --
> > 1.9.1
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-pci"
> in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 0/4] PXA cpufreq conversion to clock API
From: Robert Jarzmik @ 2016-11-02 21:49 UTC (permalink / raw)
To: Viresh Kumar, Rafael J Wysocki
Cc: Daniel Mack, Haojian Zhuang, Rob Herring, Mark Rutland,
linux-arm-kernel, devicetree, linux-kernel, linux-pm
In-Reply-To: <20161102044503.GC10786@vireshk-i7>
Viresh Kumar <viresh.kumar@linaro.org> writes:
> On 31-10-16, 20:54, Robert Jarzmik wrote:
>> Hi,
>>
>> This serie is a preparation to shift the cpufreq of pxa2xx platforms to clocks
>> API, next iteration.
>>
>> The first 3 patches are review and merge material :
>> - patch 1/4 for Viresh and Rafael
>> - patches 2/4 and 3/4 for me
>>
>> The 4th on is for review but not merge, as the clock changes must be fully
>> reviewed and go in first as a prequisite
>>
>> Since previous iteration, 2 and 3 were amended per Viresh's suggestion.
>>
>> Robert Jarzmik (4):
>> cpufreq: pxa: use generic platdev driver for device-tree
>> ARM: dts: pxa: add pxa25x cpu operating points
>> ARM: dts: pxa: add pxa27x cpu operating points
>> cpufreq: pxa: convert to clock API
>>
>> arch/arm/boot/dts/pxa25x.dtsi | 25 +++++
>> arch/arm/boot/dts/pxa27x.dtsi | 40 ++++++++
>> drivers/cpufreq/cpufreq-dt-platdev.c | 2 +
>> drivers/cpufreq/pxa2xx-cpufreq.c | 191 +++++++----------------------------
>> 4 files changed, 106 insertions(+), 152 deletions(-)
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Ok, thanks Viresh.
Would you or Rafael take patch 1/4 "cpufreq: pxa: use generic platdev driver for
device-tree" through your tree please ?
I'll take patches 2 and 3 through my tree, and we'll wait for clock patches to
hit clock tree before I ask patch 4/4 to be applied.
Cheers.
--
Robert
^ permalink raw reply
* [PATCH v2 2/2] input: keyboard: Add lm8333 devicetree bindings
From: Gordan Markus @ 2016-11-02 21:43 UTC (permalink / raw)
To: robh-DgEjT+Ai2ygdnm+yROfE0A
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Gordan Markuš
In-Reply-To: <1478123029-18291-1-git-send-email-gordan.markus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
This adds LM8333 devicetree bindings documentation.
Signed-off-by: Gordan Markuš <gordan.markus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
.../devicetree/bindings/input/ti,lm8333.txt | 45 ++++++++++++++++++++++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/ti,lm8333.txt
diff --git a/Documentation/devicetree/bindings/input/ti,lm8333.txt b/Documentation/devicetree/bindings/input/ti,lm8333.txt
new file mode 100644
index 0000000..dda01e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ti,lm8333.txt
@@ -0,0 +1,45 @@
+LM8333 Keypad
+
+Required properties:
+- compatible: Compatible property value should be "ti,lm8333".
+
+- reg: Physical base address of the peripheral and length of memory mapped
+ region.
+
+- interrupts: The interrupt number for the peripheral.
+
+- linux,keymap: The keymap to use
+ (see Documentation/devicetree/bindings/input/matrix-keymap.txt)
+
+Optional properties:
+- ti,active-time-ms: Specify the time during which the keypad is scanned after
+ the last key is released, before entering Halt mode.
+ The active time must be longer than the debounce time.
+ Default 500 ms.
+
+- debounce-delay-ms: Specify the keypad debounce time.
+ This can be used for reliable scanning of keyboards with noisy contacts.
+ Default 10 ms.
+
+Example:
+input {
+ compatible = "ti,lm8333";
+ reg = <0x51>;
+ interrupts = <5>;
+
+ ti,active-time-ms = <750>;
+ debounce-delay-ms = <20>;
+
+ linux,keymap = <
+ 0x0001001e
+ 0x00020030
+ 0x0003002e
+ 0x00040020
+ 0x00050012
+ 0x00060021
+ 0x00070022
+ 0x00080023
+ 0x01010017
+ 0x01020024
+ 0x01030025>;
+};
--
1.9.1
--
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 related
* [PATCH v2 1/2] input: keyboard: Add devicetree support for lm8333
From: Gordan Markus @ 2016-11-02 21:43 UTC (permalink / raw)
To: robh-DgEjT+Ai2ygdnm+yROfE0A
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Gordan Markuš
This adds LM8333 devicetree parsing for the keypad part.
Optional properties to specify the keypad driver active
time and debounce time.
Signed-off-by: Gordan Markuš <gordan.markus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/input/keyboard/lm8333.c | 54 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
diff --git a/drivers/input/keyboard/lm8333.c b/drivers/input/keyboard/lm8333.c
index c717e8f..f1508c5 100644
--- a/drivers/input/keyboard/lm8333.c
+++ b/drivers/input/keyboard/lm8333.c
@@ -128,6 +128,51 @@ static irqreturn_t lm8333_irq_thread(int irq, void *data)
return IRQ_HANDLED;
}
+static struct lm8333_platform_data *lm8333_parse_dt(struct i2c_client *client)
+{
+ struct device_node *np = client->dev.of_node;
+ struct lm8333_platform_data *pdata;
+ struct matrix_keymap_data *matrix_data;
+ u32 *keymap;
+ u32 prop;
+ int len;
+
+ pdata = devm_kzalloc(&client->dev, sizeof(pdata),
+ GFP_KERNEL);
+ if (!pdata)
+ return ERR_PTR(-ENOMEM);
+
+ if (!of_property_read_u32(np, "ti,active-time-ms", &prop))
+ pdata->active_time = prop;
+
+ if (!of_property_read_u32(np, "debounce-delay-ms", &prop))
+ pdata->debounce_time = prop;
+ else
+ pdata->debounce_time = 10;
+
+ if (!of_get_property(np, "linux,keymap", &prop))
+ len = prop / sizeof(u32);
+ else {
+ dev_err(&client->dev, "no keymap data defined\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ keymap = devm_kzalloc(&client->dev, sizeof(len) * len, GFP_KERNEL);
+ matrix_data = devm_kzalloc(&client->dev, sizeof(matrix_data),
+ GFP_KERNEL);
+ if (!matrix_data || !keymap)
+ return ERR_PTR(-ENOMEM);
+
+ if (!of_property_read_u32_array(np, "linux,keymap", keymap, len)) {
+ matrix_data->keymap_size = len;
+ matrix_data->keymap = keymap;
+
+ pdata->matrix_data = matrix_data;
+ }
+
+ return pdata;
+}
+
static int lm8333_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -137,6 +182,15 @@ static int lm8333_probe(struct i2c_client *client,
struct input_dev *input;
int err, active_time;
+ if (!pdata && client->dev.of_node) {
+ pdata = lm8333_parse_dt(client);
+ if (IS_ERR(pdata)) {
+ dev_err(&client->dev,
+ "could not parse configuration\n");
+ return IS_ERR(pdata);
+ }
+ }
+
if (!pdata)
return -EINVAL;
--
1.9.1
--
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 related
* [PATCH 1/1] dt-binding: remoteproc: Fixup ADSP loader bindings
From: Sarangdhar Joshi @ 2016-11-02 21:38 UTC (permalink / raw)
To: Rob Herring, Mark Rutland
Cc: Sarangdhar Joshi, Bjorn Andersson,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Stephen Boyd, Trilok Soni
Fixup "dt-binding: remoteproc: Introduce ADSP loader binding"
patch to include XO clock required for booting up Qualcomm ADSP
Processor.
Signed-off-by: Sarangdhar Joshi <spjoshi-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
---
Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
index 3820151..69f185f 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
@@ -21,6 +21,16 @@ on the Qualcomm ADSP core.
Value type: <stringlist>
Definition: must be "wdog", "fatal", "ready", "handover", "stop-ack"
+- clocks:
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: reference to the xo clock
+
+- clock-names = "xo";
+ Usage: required
+ Value type: <stringlist>
+ Definition: must list the xo clock name
+
- cx-supply:
Usage: required
Value type: <phandle>
@@ -61,6 +71,9 @@ ADSP, as it is found on MSM8974 boards.
"handover",
"stop-ack";
+ clocks = <&rpmcc RPM_CXO_CLK>;
+ clock-names = "xo";
+
cx-supply = <&pm8841_s2>;
memory-region = <&adsp_region>;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [RESEND/PATCH v6 3/3] clk: qcom: Add A53 clock driver
From: Bjorn Andersson @ 2016-11-02 20:59 UTC (permalink / raw)
To: Stephen Boyd
Cc: Georgi Djakov, mturquette-rdvid1DuHRBWk0Htik3J/w,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring
In-Reply-To: <20161028015438.GG16026-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Thu 27 Oct 18:54 PDT 2016, Stephen Boyd wrote:
> On 10/19, Georgi Djakov wrote:
> > Add a driver for the A53 Clock Controller. It is a hardware block that
> > implements a combined mux and half integer divider functionality. It can
> > choose between a fixed-rate clock or the dedicated A53 PLL. The source
> > and the divider can be set both at the same time.
> >
> > This is required for enabling CPU frequency scaling on platforms like
> > MSM8916.
> >
>
> Please Cc DT reviewers.
>
> > Signed-off-by: Georgi Djakov <georgi.djakov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > ---
> > .../devicetree/bindings/clock/qcom,a53cc.txt | 22 +++
> > drivers/clk/qcom/Kconfig | 8 ++
> > drivers/clk/qcom/Makefile | 1 +
> > drivers/clk/qcom/a53cc.c | 155 +++++++++++++++++++++
> > 4 files changed, 186 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/clock/qcom,a53cc.txt
> > create mode 100644 drivers/clk/qcom/a53cc.c
> >
> > diff --git a/Documentation/devicetree/bindings/clock/qcom,a53cc.txt b/Documentation/devicetree/bindings/clock/qcom,a53cc.txt
> > new file mode 100644
> > index 000000000000..a025f062f177
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/qcom,a53cc.txt
> > @@ -0,0 +1,22 @@
> > +Qualcomm A53 CPU Clock Controller Binding
> > +------------------------------------------------
> > +The A53 CPU Clock Controller is hardware, which provides a combined
> > +mux and divider functionality for the CPU clocks. It can choose between
> > +a fixed rate clock and the dedicated A53 PLL.
> > +
> > +Required properties :
> > +- compatible : shall contain:
> > +
> > + "qcom,a53cc"
> > +
> > +- reg : shall contain base register location and length
> > + of the APCS region
> > +- #clock-cells : shall contain 1
> > +
> > +Example:
> > +
> > + apcs: syscon@b011000 {
> > + compatible = "qcom,a53cc", "syscon";
>
> Why is it a syscon? Is that part used?
>
I use the register at offset 8 for interrupting the other subsystems, so
this must be available as something I can poke.
Which makes me think that this should be described as a "simple-mfd" and
"syscon" with the a53cc node as a child - grabbing the regmap of the
syscon parent, rather then ioremapping the same region again.
Regards,
Bjorn
--
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 5/5] doc_rst: media: New SDR formats SC16, SC18 & SC20
From: Laurent Pinchart @ 2016-11-02 20:58 UTC (permalink / raw)
To: Ramesh Shanmugasundaram
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
mchehab-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org,
sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
crope-X3B1VOXEql0@public.gmane.org, Chris Paterson,
geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org,
linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <SG2PR06MB10389152CEC59BB77A5DA7DDC3A00-ESzmfEwOt/zfc7TNChRnj20DtJ1/0DrXvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
Hi Ramesh,
On Wednesday 02 Nov 2016 09:00:00 Ramesh Shanmugasundaram wrote:
> Hi Laurent,
>
> Any further thoughts on the SDR format please (especially the comment
> below). I would appreciate your feedback.
>
> >> On Wednesday 12 Oct 2016 15:10:29 Ramesh Shanmugasundaram wrote:
> >>> This patch adds documentation for the three new SDR formats
> >>>
> >>> V4L2_SDR_FMT_SCU16BE
> >>> V4L2_SDR_FMT_SCU18BE
> >>> V4L2_SDR_FMT_SCU20BE
>
> [snip]
>
> >>> +
> >>> + - start + 0:
> >>> +
> >>> + - I'\ :sub:`0[D13:D6]`
> >>> +
> >>> + - I'\ :sub:`0[D5:D0]`
> >>> +
> >>> + - .. row 2
> >>> +
> >>> + - start + buffer_size/2:
> >>> +
> >>> + - Q'\ :sub:`0[D13:D6]`
> >>> +
> >>> + - Q'\ :sub:`0[D5:D0]`
> >>
> >> The format looks planar, does it use one V4L2 plane (as does NV12) or
> >> two V4L2 planes (as does NV12M) ? Same question for the other formats.
> >
> > Thank you for bringing up this topic. This is one of the key design
> > dilemma.
> >
> > The I & Q data for these three SDR formats comes from two different DMA
> > channels and hence two separate pointers -> we could say it is v4l2 multi-
> > planar. Right now, I am making it look like a single plane by presenting
> > the data in one single buffer ptr.
> >
> > For e.g. multi-planar SC16 format would look something like this
> >
> > <------------------------32bits---------------------->
> > <--I(14 bit data) + 2bit status--16bit padded zeros--> : start0 + 0
> > <--I(14 bit data) + 2bit status--16bit padded zeros--> : start0 + 4 ...
> > <--Q(14 bit data) + 2bit status--16bit padded zeros--> : start1 + 0
> > <--Q(14 bit data) + 2bit status--16bit padded zeros--> : start1 + 4
> >
> > My concerns are
> >
> > 1) These formats are not a standard as the video "Image Formats". These
> > formats are possible when we use DRIF + MAX2175 combination. If we
> > interface with a different tuner vendor, the above format(s) MAY/MAY NOT
> > be re-usable. We do not know at this point. This is the main open item for
> > discussion in the cover letter.
If the formats are really device-specific then they should be documented
accordingly and not made generic.
> > 2) MPLANE support within V4L2 seems specific to video. Please correct me
> > if this is wrong interpretation.
> >
> > - struct v4l2_format contains v4l2_sdr_format and
> > v4l2_pix_format_mplane as members of union. Should I create a new
> > v4l2_sdr_format_mplane? If I have to use v4l2_pix_format_mplane most of
> > the video specific members would be unused (it would be similar to using
> > v4l2_pix_format itself instead of v4l2_sdr_format)?
I have no answer to that question as I'm not familiar with SDR. Antti, you've
added v4l2_sdr_format to the API, what's your opinion ? Hans, as you've acked
the patch, your input would be appreciated as well.
> > - The above decision (accomodate SDR & MPLANE) needs to be
> > propagated across the framework. Is this the preferred approach?
> >
> > It goes back to point (1). As of today, the change set for this combo
> > (DRIF+MAX2175) introduces new SDR formats only. Should it add further
> > SDR+MPLANE support to the framework as well?
> >
> > I would appreciate your suggestions on this regard.
--
Regards,
Laurent Pinchart
--
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 v3 0/6] Add support for IR transmitters
From: Heiner Kallweit @ 2016-11-02 19:57 UTC (permalink / raw)
To: Andi Shyti, Mauro Carvalho Chehab, Sean Young, Rob Herring,
Mark Rutland, Richard Purdie, Jacek Anaszewski
Cc: linux-media, devicetree, linux-leds, linux-kernel, Andi Shyti
In-Reply-To: <20161102104010.26959-1-andi.shyti@samsung.com>
Am 02.11.2016 um 11:40 schrieb Andi Shyti:
> Hi,
>
> The main goal is to add support in the rc framework for IR
> transmitters, which currently is only supported by lirc but that
> is not the preferred way.
>
> The last patch adds support for an IR transmitter driven by
> the MOSI line of an SPI controller, it's the case of the Samsung
> TM2(e) board which support is currently ongoing.
>
> The last patch adds support for an IR transmitter driven by
> the MOSI line of an SPI controller, it's the case of the Samsung
> TM2(e) board which support is currently ongoing.
>
> Thanks Sean for your prompt reviews.
>
> Andi
>
> Changelog from version 1:
>
> The RFC is now PATCH. The main difference is that this version
> doesn't try to add the any bit streaming protocol and doesn't
> modify any LIRC interface specification.
>
> patch 1: updates all the drivers using rc_allocate_device
> patch 2: fixed errors and warning reported from the kbuild test
> robot
> patch 5: this patch has been dropped and replaced with a new one
> which avoids waiting for transmitters.
> patch 6: added new properties to the dts specification
> patch 7: the driver uses the pulse/space input and converts it to
> a bit stream.
>
>
> Changelog from version 2:
>
> The original patch number 5 has been abandoned because it was not
> bringing much benenfit.
>
> patch 1: rebased on the new kernel.
> patch 3: removed the sysfs attribute protocol for transmitters
> patch 5: the binding has been moved to the leds section instead
> of the media. Fixed all the comments from Rob
> patch 6: fixed all the comments from Sean added also Sean's
> review.
>
> Andi Shyti (6):
> [media] rc-main: assign driver type during allocation
> [media] rc-main: split setup and unregister functions
> [media] rc-core: add support for IR raw transmitters
> [media] rc-ir-raw: do not generate any receiving thread for raw
> transmitters
> Documentation: bindings: add documentation for ir-spi device driver
> [media] rc: add support for IR LEDs driven through SPI
>
Hi Andi,
at least patches 1 and 2 conflict with recent extensions. See commits
ddbf7d5a698c "rc: core: add managed versions of rc_allocate_device and
rc_register_device" and b6f3ece38733 "[media] rc: nuvoton: use managed
versions of rc_allocate_device and rc_register_device".
It would be good if you could rebase your patch set on top of the
latest master branch of media tree. Most likely you will have to make
changes to the recently introduced managed versions of
rc_allocate_device and rc_register_device.
Rgds, Heiner
^ permalink raw reply
* Re: [PATCH v5 4/7] Documentation: devicetree: net: add NS2 bindings to amac
From: Sergei Shtylyov @ 2016-11-02 19:52 UTC (permalink / raw)
To: Jon Mason
Cc: David Miller, Rob Herring, Mark Rutland, Florian Fainelli, rafal,
bcm-kernel-feedback-list, netdev, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20161102172456.GA11881@broadcom.com>
On 11/02/2016 08:24 PM, Jon Mason wrote:
>>> Clean-up the documentation to the bgmac-amac driver, per suggestion by
>>> Rob Herring, and add details for NS2 support.
>>>
>>> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
>>> ---
>>> Documentation/devicetree/bindings/net/brcm,amac.txt | 16 +++++++++++-----
>>> 1 file changed, 11 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/brcm,amac.txt b/Documentation/devicetree/bindings/net/brcm,amac.txt
>>> index ba5ecc1..2fefa1a 100644
>>> --- a/Documentation/devicetree/bindings/net/brcm,amac.txt
>>> +++ b/Documentation/devicetree/bindings/net/brcm,amac.txt
>>> @@ -2,11 +2,17 @@ Broadcom AMAC Ethernet Controller Device Tree Bindings
>>> -------------------------------------------------------------
>>>
>>> Required properties:
>>> - - compatible: "brcm,amac" or "brcm,nsp-amac"
>>> - - reg: Address and length of the GMAC registers,
>>> - Address and length of the GMAC IDM registers
>>> - - reg-names: Names of the registers. Must have both "amac_base" and
>>> - "idm_base"
>>> + - compatible: "brcm,amac"
>>> + "brcm,nsp-amac"
>>> + "brcm,ns2-amac"
>>> + - reg: Address and length of the register set for the device. It
>>> + contains the information of registers in the same order as
>>> + described by reg-names
>>> + - reg-names: Names of the registers.
>>> + "amac_base": Address and length of the GMAC registers
>>> + "idm_base": Address and length of the GMAC IDM registers
>>> + "nicpm_base": Address and length of the NIC Port Manager
>>> + registers (required for Northstar2)
>>
>> Why this "_base" suffix? It looks redundant...
>
> Yes. Rob Herring pointed out the same thing. It is ugly, but follows
> the existing binding.
Sorry, I didn't realize you're reformatting the existing bindings while
adding some new text...
> Thanks,
> Jon
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 1/2] pinctrl: sunxi: Add support for interrupt debouncing
From: Maxime Ripard @ 2016-11-02 19:51 UTC (permalink / raw)
To: Linus Walleij
Cc: Alexandre Courbot, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, Rob Herring, Chen-Yu Tsai
In-Reply-To: <20161020135625.vro5cxkf3rxevwyn@lukather>
[-- Attachment #1: Type: text/plain, Size: 1861 bytes --]
Hi Linus,
On Thu, Oct 20, 2016 at 03:56:25PM +0200, Maxime Ripard wrote:
> Hi Linus,
>
> On Thu, Oct 20, 2016 at 03:04:46PM +0200, Linus Walleij wrote:
> > On Wed, Oct 19, 2016 at 11:15 AM, Maxime Ripard
> > <maxime.ripard@free-electrons.com> wrote:
> >
> > > The pin controller found in the Allwinner SoCs has support for interrupts
> > > debouncing.
> > >
> > > However, this is not done per-pin, preventing us from using the generic
> > > pinconf binding for that,
> >
> > How typical.
> >
> > > but per irq bank, which, depending on the SoC,
> > > ranges from one to five.
> > >
> > > Introduce a device-wide property to deal with this using a nanosecond
> > > resolution.
> > >
> > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > (...)
> > > +Note: For backward compatibility reasons, the hosc and losc clocks are
> > > +only required if you need to use the optional
> > > +allwinner,debounce-time-ns property. Any new device tree should set them.
> > > +
> > > +Optional properties:
> > > + - allwinner,debounce-time-ns: Array of debouncing periods in
> > > + nanoseconds. One period per irq bank found in the controller
> >
> > Do you really *need* to specify this with nanosecond resolution?
> >
> > Else I would suggest to use microsecond resolution and just use
> > the generic binding (input-debounce) but on the device node instead
> > of the specific handler.
>
> Theorically, the debouncing clock can be set at 24MHz, which means a
> 42ns resolution.
>
> I've seen that the other bindings usually use microseconds, but in our
> case, we can really go lower than that.
>
> I don't really know if it makes sense though.
Any comments on this?
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH V4] pinctrl: qcom: Add msm8994 pinctrl driver
From: Michael Scott @ 2016-11-02 19:10 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-gpio, linux-arm-msm, devicetree, linux-kernel,
Linus Walleij, Rob Herring, Mark Rutland, Andy Gross, David Brown,
Bjorn Andersson, Joonwoo Park, Jeremy McNicoll
In-Reply-To: <20161102183607.GJ16026@codeaurora.org>
On 11/02/2016 11:36 AM, Stephen Boyd wrote:
> On 11/01, Michael Scott wrote:
>> On 11/01/2016 04:53 PM, Stephen Boyd wrote:
>>> On 10/31, Michael Scott wrote:
>>>> +
>>>> +static const struct msm_pingroup msm8994_groups[] = {
>>>> + PINGROUP(0, blsp_spi1, blsp_uart1, blsp_uim1, NA, NA, NA, NA, NA, NA,
>>>> + NA, NA),
>>> I see an hdmi_rcv group here after blsp_uim1. Please add it for
>>> this gpio.
>> Hi Stephen,
>>
>> Thank you for reviewing the data-- this is really tedious stuff.
>>
>> I'd like to make sure that we're both using tech data for msm8994.
>> I don't see the hdmi_rcv function at all in my docs.
>>
>>>> + PINGROUP(1, blsp_spi1, blsp_uart1, blsp_uim1, NA, NA, NA, NA, NA, NA,
>>>> + NA, NA),
>>>> + PINGROUP(2, blsp_spi1, blsp_uart1, blsp_i2c1, NA, NA, NA, NA, NA, NA,
>>>> + NA, NA),
>>>> + PINGROUP(3, blsp_spi1, blsp_uart1, blsp_i2c1, NA, NA, NA, NA, NA, NA,
>>>> + NA, NA),
>>>> + PINGROUP(4, blsp_spi2, blsp_uart2, blsp_uim2, qdss_cti_trig_out_b,
>>>> + NA, NA, NA, NA, NA, NA, NA),
>>>> + PINGROUP(5, blsp_spi2, blsp_uart2, blsp_uim2, qdss_cti_trig_in_b, NA,
>>> The qdss_cti_* is in function 5 for both of these, not function
>>> 4.
>> These are indeed wrong, but my docs both show as function 7.
> Ok. I think your document is for 8994v1, which never got
> commercialized. I certainly see that this function assignment
> changed between v1 and v2 from 7 to 5.
>
> Now that my eyes are bleeding I'm going to do something else.
Thank you for clarifying the issue.
I'll defer to your document for the qti* and hdmi_rcv function settings
for the next patch version.
- Mike
>
^ permalink raw reply
* Re: [PATCH v5 3/7] net: phy: broadcom: Add BCM54810 PHY entry
From: Andrew Lunn @ 2016-11-02 18:37 UTC (permalink / raw)
To: Jon Mason
Cc: David Miller, Rob Herring, Mark Rutland, Florian Fainelli,
devicetree, netdev, linux-kernel, bcm-kernel-feedback-list, rafal,
linux-arm-kernel
In-Reply-To: <1478106488-11779-4-git-send-email-jon.mason@broadcom.com>
On Wed, Nov 02, 2016 at 01:08:04PM -0400, Jon Mason wrote:
> The BCM54810 PHY requires some semi-unique configuration, which results
> in some additional configuration in addition to the standard config.
> Also, some users of the BCM54810 require the PHY lanes to be swapped.
> Since there is no way to detect this, add a device tree query to see if
> it is applicable.
>
> Inspired-by: Vikas Soni <vsoni@broadcom.com>
> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH V4] pinctrl: qcom: Add msm8994 pinctrl driver
From: Stephen Boyd @ 2016-11-02 18:36 UTC (permalink / raw)
To: Michael Scott
Cc: linux-gpio, linux-arm-msm, devicetree, linux-kernel,
Linus Walleij, Rob Herring, Mark Rutland, Andy Gross, David Brown,
Bjorn Andersson, Joonwoo Park, Jeremy McNicoll
In-Reply-To: <e0bdce76-dcab-36c9-bf39-6c79b1cb2820@linaro.org>
On 11/01, Michael Scott wrote:
>
> On 11/01/2016 04:53 PM, Stephen Boyd wrote:
> >On 10/31, Michael Scott wrote:
> >>+
> >>+static const struct msm_pingroup msm8994_groups[] = {
> >>+ PINGROUP(0, blsp_spi1, blsp_uart1, blsp_uim1, NA, NA, NA, NA, NA, NA,
> >>+ NA, NA),
> >I see an hdmi_rcv group here after blsp_uim1. Please add it for
> >this gpio.
>
> Hi Stephen,
>
> Thank you for reviewing the data-- this is really tedious stuff.
>
> I'd like to make sure that we're both using tech data for msm8994.
> I don't see the hdmi_rcv function at all in my docs.
>
> >
> >>+ PINGROUP(1, blsp_spi1, blsp_uart1, blsp_uim1, NA, NA, NA, NA, NA, NA,
> >>+ NA, NA),
> >>+ PINGROUP(2, blsp_spi1, blsp_uart1, blsp_i2c1, NA, NA, NA, NA, NA, NA,
> >>+ NA, NA),
> >>+ PINGROUP(3, blsp_spi1, blsp_uart1, blsp_i2c1, NA, NA, NA, NA, NA, NA,
> >>+ NA, NA),
> >>+ PINGROUP(4, blsp_spi2, blsp_uart2, blsp_uim2, qdss_cti_trig_out_b,
> >>+ NA, NA, NA, NA, NA, NA, NA),
> >>+ PINGROUP(5, blsp_spi2, blsp_uart2, blsp_uim2, qdss_cti_trig_in_b, NA,
> >The qdss_cti_* is in function 5 for both of these, not function
> >4.
> These are indeed wrong, but my docs both show as function 7.
Ok. I think your document is for 8994v1, which never got
commercialized. I certainly see that this function assignment
changed between v1 and v2 from 7 to 5.
Now that my eyes are bleeding I'm going to do something else.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v2 2/4] ARM: dts: sun8i: Add SPI controller node in H3
From: Maxime Ripard @ 2016-11-02 18:36 UTC (permalink / raw)
To: Milo Kim
Cc: Chen-Yu Tsai, Mark Brown, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-spi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161028065412.23008-3-woogyom.kim-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 541 bytes --]
1;4600;0c
On Fri, Oct 28, 2016 at 03:54:10PM +0900, Milo Kim wrote:
> H3 SPI subsystem is almost same as A31 SPI except buffer size, so those
> DT properties are reusable.
>
> Cc: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> Cc: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> Signed-off-by: Milo Kim <woogyom.kim-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Applied both, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] ARM: DT: stm32: move dma translation to board files
From: Bruno Herrera @ 2016-11-02 18:24 UTC (permalink / raw)
To: Alexandre Torgue
Cc: Radosław Pietrzyk, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, >, >, Maxime Coquelin,
Lee Jones, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Andrea Merello
In-Reply-To: <edf05ad5-924d-87d8-fd8d-57e8e0a72052-qxv4g6HH51o@public.gmane.org>
On Wed, Nov 2, 2016 at 2:14 PM, Alexandre Torgue
<alexandre.torgue-qxv4g6HH51o@public.gmane.org> wrote:
>
>
> On 11/02/2016 05:07 PM, Bruno Herrera wrote:
>>
>> Hi
>>
>> On Wed, Nov 2, 2016 at 12:32 PM, Alexandre Torgue
>> <alexandre.torgue-qxv4g6HH51o@public.gmane.org> wrote:
>>>
>>> Hi
>>>
>>> On 10/31/2016 07:58 PM, Radosław Pietrzyk wrote:
>>>>
>>>>
>>>> I think wlcore driver searches dma-ranges in its parent that's why sdio
>>>> node needs it.
>>>
>>>
>>>
>>> Yes I agree. In this case it is needed as you have subnode in sdio node.
>>> So IMO empty dma-ranges could be removed from ethernet and usb node, but
>>> kept in future sdio subnode.
>>
>>
>> Now it is clear.
>
> Nice. Can I add your tested-by ?
>
Sure
>>
>>>
>>> Bruno,
>>> Do you plan to push sdio support ?
>>
>>
>> Yes I do, but I'm not sure how long it will take. The I had to
>> change(and hack) the mmci code because I could not get the ID from
>> STM32 SDIO IP.
>> My current WIP is at @
>>
>> https://github.com/mcoquelin-stm32/afboot-stm32/pull/4#issuecomment-247571615
>> I know Andrea Merello is also working on that (and he probably has a
>> more complete patch).
>>
>>>
>>>
>>>
>>>>
>>>> 2016-10-31 17:41 GMT+01:00 Bruno Herrera <bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>>>> <mailto:bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>>:
>>>>
>>>> On Mon, Oct 31, 2016 at 12:14 PM, Radosław Pietrzyk
>>>> <radoslaw.pietrzyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org <mailto:radoslaw.pietrzyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>>
>>>> wrote:
>>>> > This is weird because dma ddresses are recalculated using parent's
>>>> > dma-ranges property and soc already has it so there should be
>>>> absolutely no
>>>> > problem.
>>>>
>>>> These are my DTS and DTSI file.
>>>> >
>>>> > 2016-10-31 11:27 GMT+01:00 Bruno Herrera <bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>>>> <mailto:bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>>:
>>>> >>
>>>> >> On Fri, Oct 28, 2016 at 5:09 AM, Radosław Pietrzyk
>>>> >> <radoslaw.pietrzyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>>>> <mailto:radoslaw.pietrzyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:
>>>> >> > Have you defined your sdio node within soc node ?
>>>> >>
>>>> >> It is in the SOC node of the DSTI file.
>>>> >>
>>>> >> >
>>>> >> > 2016-10-27 14:57 GMT+02:00 Bruno Herrera <bruherrera-Re5JQEeQqe8@public.gmane.orgm
>>>> <mailto:bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>>:
>>>> >> >>
>>>> >> >> Hi Alex,
>>>> >> >>
>>>> >> >> On Thu, Oct 27, 2016 at 10:21 AM, Alexandre Torgue
>>>> >> >> <alexandre.torgue-qxv4g6HH51o@public.gmane.org <mailto:alexandre.torgue-qxv4g6HH51o@public.gmane.org>>
>>>> wrote:
>>>> >> >> > Hi Bruno,
>>>> >> >> >
>>>> >> >> >
>>>> >> >> > On 10/27/2016 12:43 PM, Bruno Herrera wrote:
>>>> >> >> >>
>>>> >> >> >> Hi Alex,
>>>> >> >> >>
>>>> >> >> >> On Wed, Oct 26, 2016 at 7:09 AM, Alexandre Torgue
>>>> >> >> >> <alexandre.torgue-qxv4g6HH51o@public.gmane.org <mailto:alexandre.torgue-qxv4g6HH51o@public.gmane.org>>
>>>> wrote:
>>>> >> >> >>>
>>>> >> >> >>> Hi Bruno,
>>>> >> >> >>>
>>>> >> >> >>> On 10/25/2016 11:06 PM, Bruno Herrera wrote:
>>>> >> >> >>>>
>>>> >> >> >>>>
>>>> >> >> >>>> Hi Alexandre,
>>>> >> >> >>>>
>>>> >> >> >>>>>
>>>> >> >> >>>>> stm32f469-disco and stm32f429-eval boards use SDRAM
>>>> start address
>>>> >> >> >>>>> remapping
>>>> >> >> >>>>> (to @0) to boost performances. A DMA translation through
>>>> >> >> >>>>> "dma-ranges"
>>>> >> >> >>>>> property was needed for other masters than the M4 CPU.
>>>> >> >> >>>>> stm32f429-disco doesn't use remapping so doesn't need
>>>> this DMA
>>>> >> >> >>>>> translation.
>>>> >> >> >>>>> This patches moves this DMA translation definition from
>>>> stm32f429
>>>> >> >> >>>>> soc
>>>> >> >> >>>>> file
>>>> >> >> >>>>> to board files.
>>>> >> >> >>>>>
>>>> >> >> >>>>> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com
>>>> <mailto:alexandre.torgue-qxv4g6HH51o@public.gmane.org>>
>>>>
>>>> >> >> >>>>>
>>>> >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
>>>> >> >> >>>>> b/arch/arm/boot/dts/stm32429i-eval.dts
>>>> >> >> >>>>> index 13c7cd2..a763c15 100644
>>>> >> >> >>>>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
>>>> >> >> >>>>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
>>>> >> >> >>>>> @@ -82,6 +82,10 @@
>>>> >> >> >>>>> };
>>>> >> >> >>>>> };
>>>> >> >> >>>>>
>>>> >> >> >>>>> + soc {
>>>> >> >> >>>>> + dma-ranges = <0xc0000000 0x0
>>>> 0x10000000>;
>>>> >> >> >>>>> + };
>>>> >> >> >>>>> +
>>>> >> >> >>>>> usbotg_hs_phy: usbphy {
>>>> >> >> >>>>> #phy-cells = <0>;
>>>> >> >> >>>>> compatible = "usb-nop-xceiv";
>>>> >> >> >>>>
>>>> >> >> >>>>
>>>> >> >> >>>>
>>>> >> >> >>>> Shouldn't also the peripheral dma-ranges property move to
>>>> board
>>>> >> >> >>>> specific
>>>> >> >> >>>> too?
>>>> >> >> >>>> I had this patch for while but I didn't had the time to
>>>> submit:
>>>> >> >> >>>
>>>> >> >> >>>
>>>> >> >> >>>
>>>> >> >> >>> Well spot I forgot it. Actually, discussing with Arnd
>>>> ysterday on
>>>> >> >> >>> IIRC,
>>>> >> >> >>> empty dma-ranges is not needed. Can you test on your side
>>>> by
>>>> >> >> >>> removing
>>>> >> >> >>> dma-ranges in usb node please ?
>>>> >> >> >>
>>>> >> >> >> Unfortunately will take a time for me to set up this
>>>> environment on
>>>> >> >> >> the STM32F4-EVAL board.
>>>> >> >> >> And on the discovery boards we dont have this scenario.
>>>> That was the
>>>> >> >> >> main reason I did not submit the patch right away.
>>>> >> >> >> My conclusion and I might be wrong but is based on the my
>>>> tests with
>>>> >> >> >> SDIO device at STM32F469I-DISCO board.
>>>> >> >> >>
>>>> >> >> >> I started this issue as discussion at ST Forum but Maxime
>>>> gave me
>>>> >> >> >> the
>>>> >> >> >> hint.
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >>
>>>>
>>>>
>>>> https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fDMA2%20and%20SYSCFG_MEMRMP%20relationship&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=44
>>>>
>>>>
>>>> <https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fDMA2%20and%20SYSCFG_MEMRMP%20relationship&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=44>
>>>> >> >> >>
>>>> >> >> >>> I will push a v2 by removing empty dma-ranges if tests are
>>>> ok in
>>>> >> >> >>> your
>>>> >> >> >>> side.
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >> From my understating/conclusion is: when empty
>>>> property(dma-ranges)
>>>> >> >> >> is
>>>> >> >> >> the device node, the mapping will be taken in consideration
>>>> when
>>>> >> >> >> using
>>>> >> >> >> DMA otherwise the mapping is ignored.
>>>> >> >> >> And in the SDIO case it is needed for DEV->MEM(SDRAM) and
>>>> >> >> >> MEM(SDRAM)->DEV. If it is not the case for the devices in
>>>> question
>>>> >> >> >> so
>>>> >> >> >> I suppose it can work without the property.
>>>> >> >> >
>>>> >> >> >
>>>> >> >> > For sure translation has to be done but I'm not sure that an
>>>> empty
>>>> >> >> > "dma-ranges" is needed in device node to activate it. For
>>>> Ethernet
>>>> >> >> > empty
>>>> >> >> > "dma-ranges" is not needed. I will try with usb.
>>>> >> >>
>>>> >> >> In the case of SDIO it is needed. As example this is my
>>>> working SDIO
>>>> >> >> node:
>>>> >> >>
>>>> >> >> sdio: sdio@40012c00 {
>>>> >> >> compatible = "arm,pl18x", "arm,primecell";
>>>> >> >> arm,primecell-periphid = <0x00480181>;
>>>> >> >> reg = <0x40012c00 0x400>;
>>>> >> >> dmas = <&dma2 6 4 0x10400 0x3>, /* Logical - DevToMem */
>>>> >> >> <&dma2 3 4 0x10400 0x3>; /* Logical - MemToDev */
>>>> >> >> dma-names = "rx", "tx";
>>>> >> >> clocks = <&rcc 0 171>;
>>>> >> >> clock-names = "apb_pclk";
>>>> >> >> interrupts = <49>;
>>>> >> >> status = "disabled";
>>>> >> >> };
>>>> >> >>
>>>> >> >> &sdio {
>>>> >> >> status = "okay";
>>>> >> >> vmmc-supply = <&wlan_en>;
>>>> >> >> bus-width = <4>;
>>>> >> >> max-frequency = <24000000>;
>>>> >> >> pinctrl-names = "default";
>>>> >> >> pinctrl-0 = <&sdio_pins>;
>>>> >> >> ti,non-removable;
>>>> >> >> ti,needs-special-hs-handling;
>>>> >> >> dma-ranges;
>>>> >> >> cap-power-off-card;
>>>> >> >> keep-power-in-suspend;
>>>> >> >>
>>>> >> >> #address-cells = <1>;
>>>> >> >> #size-cells = <0>;
>>>> >> >> wlcore: wlcore@0 {
>>>> >> >> compatible = "ti,wl1835";
>>>> >> >> reg = <2>;
>>>> >> >> interrupt-parent = <&gpioa>;
>>>> >> >> interrupts = <8 IRQ_TYPE_EDGE_RISING>;
>>>> >> >> };
>>>> >> >> };
>>>> >> >>
>>>> >> >> >
>>>> >> >> > alex
>>>> >> >> >
>>>> >> >> >
>>>> >> >> >>
>>>> >> >> >>>
>>>> >> >> >>> Thanks in advance
>>>> >> >> >>> Alex
>>>> >> >> >>>
>>>> >> >> >>>
>>>> >> >> >>>>
>>>> >> >> >>>> Author: Bruno Herrera <bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>>>> <mailto:bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>>
>>>>
>>>> >> >> >>>> Date: Sun Oct 16 14:50:00 2016 -0200
>>>> >> >> >>>>
>>>> >> >> >>>> ARM: DT: STM32: Use dma-ranges property per board not
>>>> at dtsi
>>>> >> >> >>>> file
>>>> >> >> >>>>
>>>> >> >> >>>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
>>>> >> >> >>>> b/arch/arm/boot/dts/stm32429i-eval.dts
>>>> >> >> >>>> index 6bfc595..2a22a82 100644
>>>> >> >> >>>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
>>>> >> >> >>>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
>>>> >> >> >>>> @@ -52,6 +52,10 @@
>>>> >> >> >>>> model = "STMicroelectronics STM32429i-EVAL
>>>> board";
>>>> >> >> >>>> compatible = "st,stm32429i-eval", "st,stm32f429";
>>>> >> >> >>>>
>>>> >> >> >>>> + soc {
>>>> >> >> >>>> + dma-ranges = <0xC0000000 0x0 0x10000000>;
>>>> >> >> >>>> + };
>>>> >> >> >>>> +
>>>> >> >> >>>> chosen {
>>>> >> >> >>>> bootargs = "root=/dev/ram
>>>> rdinit=/linuxrc";
>>>> >> >> >>>> stdout-path = "serial0:115200n8";
>>>> >> >> >>>> @@ -96,6 +100,7 @@
>>>> >> >> >>>>
>>>> >> >> >>>> ðernet0 {
>>>> >> >> >>>> status = "okay";
>>>> >> >> >>>> + dma-ranges;
>>>> >> >> >>>> pinctrl-0 = <ðernet0_mii>;
>>>> >> >> >>>> pinctrl-names = "default";
>>>> >> >> >>>> phy-mode = "mii-id";
>>>> >> >> >>>> @@ -116,6 +121,7 @@
>>>> >> >> >>>> };
>>>> >> >> >>>>
>>>> >> >> >>>> &usbotg_hs {
>>>> >> >> >>>> + dma-ranges;
>>>> >> >> >>>> dr_mode = "host";
>>>> >> >> >>>> phys = <&usbotg_hs_phy>;
>>>> >> >> >>>> phy-names = "usb2-phy";
>>>> >> >> >>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
>>>> >> >> >>>> b/arch/arm/boot/dts/stm32f429.dtsi
>>>> >> >> >>>> index 7d624a2..697a133 100644
>>>> >> >> >>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>>>> >> >> >>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>>>> >> >> >>>> @@ -59,7 +59,6 @@
>>>> >> >> >>>> };
>>>> >> >> >>>>
>>>> >> >> >>>> soc {
>>>> >> >> >>>> - dma-ranges = <0xc0000000 0x0 0x10000000>;
>>>> >> >> >>>>
>>>> >> >> >>>> timer2: timer@40000000 {
>>>> >> >> >>>> compatible = "st,stm32-timer";
>>>> >> >> >>>> @@ -472,13 +471,11 @@
>>>> >> >> >>>> st,syscon = <&syscfg 0x4>;
>>>> >> >> >>>> snps,pbl = <8>;
>>>> >> >> >>>> snps,mixed-burst;
>>>> >> >> >>>> - dma-ranges;
>>>> >> >> >>>> status = "disabled";
>>>> >> >> >>>> };
>>>> >> >> >>>>
>>>> >> >> >>>> usbotg_hs: usb@40040000 {
>>>> >> >> >>>> compatible = "snps,dwc2";
>>>> >> >> >>>> - dma-ranges;
>>>> >> >> >>>> reg = <0x40040000 0x40000>;
>>>> >> >> >>>> interrupts = <77>;
>>>> >> >> >>>> clocks = <&rcc 0 29>;
>>>> >> >> >>>>
>>>> >> >> >>>>
>>>> >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
>>>> >> >> >>>>> b/arch/arm/boot/dts/stm32f429.dtsi
>>>> >> >> >>>>> index 0596d60..3a1cfdd 100644
>>>> >> >> >>>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>>>> >> >> >>>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>>>> >> >> >>>>> @@ -59,8 +59,6 @@
>>>> >> >> >>>>> };
>>>> >> >> >>>>>
>>>> >> >> >>>>> soc {
>>>> >> >> >>>>> - dma-ranges = <0xc0000000 0x0
>>>> 0x10000000>;
>>>> >> >> >>>>> -
>>>> >> >> >>>>> timer2: timer@40000000 {
>>>> >> >> >>>>> compatible = "st,stm32-timer";
>>>> >> >> >>>>> reg = <0x40000000 0x400>;
>>>> >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts
>>>> >> >> >>>>> b/arch/arm/boot/dts/stm32f469-disco.dts
>>>> >> >> >>>>> index 9e73656..c2213c0 100644
>>>> >> >> >>>>> --- a/arch/arm/boot/dts/stm32f469-disco.dts
>>>> >> >> >>>>> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
>>>> >> >> >>>>> @@ -64,6 +64,10 @@
>>>> >> >> >>>>> aliases {
>>>> >> >> >>>>> serial0 = &usart3;
>>>> >> >> >>>>> };
>>>> >> >> >>>>> +
>>>> >> >> >>>>> + soc {
>>>> >> >> >>>>> + dma-ranges = <0xc0000000 0x0
>>>> 0x10000000>;
>>>> >> >> >>>>> + };
>>>> >> >> >>>>> };
>>>> >> >> >>>>>
>>>> >> >> >>>>> &clk_hse {
>>>> >> >> >>>>> --
>>>> >> >> >>>>
>>>> >> >> >>>>
>>>> >> >> >>>>
>>>> >> >> >>>>
>>>> >> >> >>>> Br.,
>>>> >> >> >>>> Bruno
>>>> >> >> >>>>
>>>> >> >> >>>
>>>> >> >> >
>>>> >> >>
>>>> >> >> _______________________________________________
>>>> >> >> linux-arm-kernel mailing list
>>>> >> >> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>>>> <mailto:linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
>>>> >> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>> <http://lists.infradead.org/mailman/listinfo/linux-arm-kernel>
>>>> >> >
>>>> >> >
>>>> >
>>>> >
>>>>
>>>>
>>>
>
--
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: DT: stm32: move dma translation to board files
From: Bruno Herrera @ 2016-11-02 18:23 UTC (permalink / raw)
To: Radosław Pietrzyk
Cc: Alexandre Torgue, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, >, >, Maxime Coquelin,
Lee Jones, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
andrea.merello-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <CAFvLkMSViXggGr0Set0qnQan_+bXUNzJx5WtZHP-Jyje=ZzDVw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Nov 2, 2016 at 4:05 PM, Radosław Pietrzyk
<radoslaw.pietrzyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Have you tried with
>
> sdio {
> ...
> compatible = "arm,primecell";
> arm,primecell-periphid = <id_to_define>;
> ...
> }
>
> This should register proper amba device and give it an ID you wish.
I'm using this:
sdio: sdio@40012c00 {
compatible = "arm,pl18x", "arm,primecell";
arm,primecell-periphid = <0x00480181>;
reg = <0x40012c00 0x400>;
dmas = <&dma2 6 4 0x10400 0x3>, /* Logical - DevToMem */
<&dma2 3 4 0x10400 0x3>; /* Logical - MemToDev */
dma-names = "rx", "tx";
clocks = <&rcc 0 171>;
clock-names = "apb_pclk";
interrupts = <49>;
status = "disabled";
};
And on the driver side I added this:
/* STM32 variants */
{
.id = 0x00480181,
.mask = 0xf0ffffff,
.data = &variant_stm32f4x9,
},
My .id field is the .id from variant_ux500 plus one (and what I
believe is not valid).
And I cannot read the ID from STM32 IP because it always return zero.
Maybe someone from ST(@Alex) can get the real ID. ;)
>
> 2016-11-02 17:07 GMT+01:00 Bruno Herrera <bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>>
>> Hi
>>
>> On Wed, Nov 2, 2016 at 12:32 PM, Alexandre Torgue
>> <alexandre.torgue-qxv4g6HH51o@public.gmane.org> wrote:
>> > Hi
>> >
>> > On 10/31/2016 07:58 PM, Radosław Pietrzyk wrote:
>> >>
>> >> I think wlcore driver searches dma-ranges in its parent that's why sdio
>> >> node needs it.
>> >
>> >
>> > Yes I agree. In this case it is needed as you have subnode in sdio node.
>> > So IMO empty dma-ranges could be removed from ethernet and usb node, but
>> > kept in future sdio subnode.
>>
>> Now it is clear.
>>
>> >
>> > Bruno,
>> > Do you plan to push sdio support ?
>>
>> Yes I do, but I'm not sure how long it will take. The I had to
>> change(and hack) the mmci code because I could not get the ID from
>> STM32 SDIO IP.
>> My current WIP is at @
>>
>> https://github.com/mcoquelin-stm32/afboot-stm32/pull/4#issuecomment-247571615
>> I know Andrea Merello is also working on that (and he probably has a
>> more complete patch).
>>
>> >
>> >
>> >
>> >>
>> >> 2016-10-31 17:41 GMT+01:00 Bruno Herrera <bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>> >> <mailto:bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>>:
>> >>
>> >> On Mon, Oct 31, 2016 at 12:14 PM, Radosław Pietrzyk
>> >> <radoslaw.pietrzyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org <mailto:radoslaw.pietrzyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>>
>> >> wrote:
>> >> > This is weird because dma ddresses are recalculated using
>> >> parent's
>> >> > dma-ranges property and soc already has it so there should be
>> >> absolutely no
>> >> > problem.
>> >>
>> >> These are my DTS and DTSI file.
>> >> >
>> >> > 2016-10-31 11:27 GMT+01:00 Bruno Herrera <bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>> >> <mailto:bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>>:
>> >> >>
>> >> >> On Fri, Oct 28, 2016 at 5:09 AM, Radosław Pietrzyk
>> >> >> <radoslaw.pietrzyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>> >> <mailto:radoslaw.pietrzyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:
>> >> >> > Have you defined your sdio node within soc node ?
>> >> >>
>> >> >> It is in the SOC node of the DSTI file.
>> >> >>
>> >> >> >
>> >> >> > 2016-10-27 14:57 GMT+02:00 Bruno Herrera <bruherrera@gmail.com
>> >> <mailto:bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>>:
>> >> >> >>
>> >> >> >> Hi Alex,
>> >> >> >>
>> >> >> >> On Thu, Oct 27, 2016 at 10:21 AM, Alexandre Torgue
>> >> >> >> <alexandre.torgue-qxv4g6HH51o@public.gmane.org <mailto:alexandre.torgue-qxv4g6HH51o@public.gmane.org>>
>> >> wrote:
>> >> >> >> > Hi Bruno,
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On 10/27/2016 12:43 PM, Bruno Herrera wrote:
>> >> >> >> >>
>> >> >> >> >> Hi Alex,
>> >> >> >> >>
>> >> >> >> >> On Wed, Oct 26, 2016 at 7:09 AM, Alexandre Torgue
>> >> >> >> >> <alexandre.torgue-qxv4g6HH51o@public.gmane.org <mailto:alexandre.torgue-qxv4g6HH51o@public.gmane.org>>
>> >> wrote:
>> >> >> >> >>>
>> >> >> >> >>> Hi Bruno,
>> >> >> >> >>>
>> >> >> >> >>> On 10/25/2016 11:06 PM, Bruno Herrera wrote:
>> >> >> >> >>>>
>> >> >> >> >>>>
>> >> >> >> >>>> Hi Alexandre,
>> >> >> >> >>>>
>> >> >> >> >>>>>
>> >> >> >> >>>>> stm32f469-disco and stm32f429-eval boards use SDRAM
>> >> start address
>> >> >> >> >>>>> remapping
>> >> >> >> >>>>> (to @0) to boost performances. A DMA translation
>> >> through
>> >> >> >> >>>>> "dma-ranges"
>> >> >> >> >>>>> property was needed for other masters than the M4 CPU.
>> >> >> >> >>>>> stm32f429-disco doesn't use remapping so doesn't need
>> >> this DMA
>> >> >> >> >>>>> translation.
>> >> >> >> >>>>> This patches moves this DMA translation definition from
>> >> stm32f429
>> >> >> >> >>>>> soc
>> >> >> >> >>>>> file
>> >> >> >> >>>>> to board files.
>> >> >> >> >>>>>
>> >> >> >> >>>>> Signed-off-by: Alexandre TORGUE
>> >> <alexandre.torgue-qxv4g6HH51o@public.gmane.org
>> >> <mailto:alexandre.torgue-qxv4g6HH51o@public.gmane.org>>
>> >>
>> >> >> >> >>>>>
>> >> >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
>> >> >> >> >>>>> b/arch/arm/boot/dts/stm32429i-eval.dts
>> >> >> >> >>>>> index 13c7cd2..a763c15 100644
>> >> >> >> >>>>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
>> >> >> >> >>>>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
>> >> >> >> >>>>> @@ -82,6 +82,10 @@
>> >> >> >> >>>>> };
>> >> >> >> >>>>> };
>> >> >> >> >>>>>
>> >> >> >> >>>>> + soc {
>> >> >> >> >>>>> + dma-ranges = <0xc0000000 0x0
>> >> 0x10000000>;
>> >> >> >> >>>>> + };
>> >> >> >> >>>>> +
>> >> >> >> >>>>> usbotg_hs_phy: usbphy {
>> >> >> >> >>>>> #phy-cells = <0>;
>> >> >> >> >>>>> compatible = "usb-nop-xceiv";
>> >> >> >> >>>>
>> >> >> >> >>>>
>> >> >> >> >>>>
>> >> >> >> >>>> Shouldn't also the peripheral dma-ranges property move
>> >> to
>> >> board
>> >> >> >> >>>> specific
>> >> >> >> >>>> too?
>> >> >> >> >>>> I had this patch for while but I didn't had the time to
>> >> submit:
>> >> >> >> >>>
>> >> >> >> >>>
>> >> >> >> >>>
>> >> >> >> >>> Well spot I forgot it. Actually, discussing with Arnd
>> >> ysterday on
>> >> >> >> >>> IIRC,
>> >> >> >> >>> empty dma-ranges is not needed. Can you test on your side
>> >> by
>> >> >> >> >>> removing
>> >> >> >> >>> dma-ranges in usb node please ?
>> >> >> >> >>
>> >> >> >> >> Unfortunately will take a time for me to set up this
>> >> environment on
>> >> >> >> >> the STM32F4-EVAL board.
>> >> >> >> >> And on the discovery boards we dont have this scenario.
>> >> That was the
>> >> >> >> >> main reason I did not submit the patch right away.
>> >> >> >> >> My conclusion and I might be wrong but is based on the my
>> >> tests with
>> >> >> >> >> SDIO device at STM32F469I-DISCO board.
>> >> >> >> >>
>> >> >> >> >> I started this issue as discussion at ST Forum but Maxime
>> >> gave me
>> >> >> >> >> the
>> >> >> >> >> hint.
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >>
>> >>
>> >> https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fDMA2%20and%20SYSCFG_MEMRMP%20relationship&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=44
>> >>
>> >>
>> >> <https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fDMA2%20and%20SYSCFG_MEMRMP%20relationship&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=44>
>> >> >> >> >>
>> >> >> >> >>> I will push a v2 by removing empty dma-ranges if tests
>> >> are
>> >> ok in
>> >> >> >> >>> your
>> >> >> >> >>> side.
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> From my understating/conclusion is: when empty
>> >> property(dma-ranges)
>> >> >> >> >> is
>> >> >> >> >> the device node, the mapping will be taken in
>> >> consideration
>> >> when
>> >> >> >> >> using
>> >> >> >> >> DMA otherwise the mapping is ignored.
>> >> >> >> >> And in the SDIO case it is needed for DEV->MEM(SDRAM) and
>> >> >> >> >> MEM(SDRAM)->DEV. If it is not the case for the devices in
>> >> question
>> >> >> >> >> so
>> >> >> >> >> I suppose it can work without the property.
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > For sure translation has to be done but I'm not sure that
>> >> an
>> >> empty
>> >> >> >> > "dma-ranges" is needed in device node to activate it. For
>> >> Ethernet
>> >> >> >> > empty
>> >> >> >> > "dma-ranges" is not needed. I will try with usb.
>> >> >> >>
>> >> >> >> In the case of SDIO it is needed. As example this is my
>> >> working SDIO
>> >> >> >> node:
>> >> >> >>
>> >> >> >> sdio: sdio@40012c00 {
>> >> >> >> compatible = "arm,pl18x", "arm,primecell";
>> >> >> >> arm,primecell-periphid = <0x00480181>;
>> >> >> >> reg = <0x40012c00 0x400>;
>> >> >> >> dmas = <&dma2 6 4 0x10400 0x3>, /* Logical - DevToMem */
>> >> >> >> <&dma2 3 4 0x10400 0x3>; /* Logical - MemToDev */
>> >> >> >> dma-names = "rx", "tx";
>> >> >> >> clocks = <&rcc 0 171>;
>> >> >> >> clock-names = "apb_pclk";
>> >> >> >> interrupts = <49>;
>> >> >> >> status = "disabled";
>> >> >> >> };
>> >> >> >>
>> >> >> >> &sdio {
>> >> >> >> status = "okay";
>> >> >> >> vmmc-supply = <&wlan_en>;
>> >> >> >> bus-width = <4>;
>> >> >> >> max-frequency = <24000000>;
>> >> >> >> pinctrl-names = "default";
>> >> >> >> pinctrl-0 = <&sdio_pins>;
>> >> >> >> ti,non-removable;
>> >> >> >> ti,needs-special-hs-handling;
>> >> >> >> dma-ranges;
>> >> >> >> cap-power-off-card;
>> >> >> >> keep-power-in-suspend;
>> >> >> >>
>> >> >> >> #address-cells = <1>;
>> >> >> >> #size-cells = <0>;
>> >> >> >> wlcore: wlcore@0 {
>> >> >> >> compatible = "ti,wl1835";
>> >> >> >> reg = <2>;
>> >> >> >> interrupt-parent = <&gpioa>;
>> >> >> >> interrupts = <8 IRQ_TYPE_EDGE_RISING>;
>> >> >> >> };
>> >> >> >> };
>> >> >> >>
>> >> >> >> >
>> >> >> >> > alex
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >>
>> >> >> >> >>>
>> >> >> >> >>> Thanks in advance
>> >> >> >> >>> Alex
>> >> >> >> >>>
>> >> >> >> >>>
>> >> >> >> >>>>
>> >> >> >> >>>> Author: Bruno Herrera <bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>> >> <mailto:bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>>
>> >>
>> >> >> >> >>>> Date: Sun Oct 16 14:50:00 2016 -0200
>> >> >> >> >>>>
>> >> >> >> >>>> ARM: DT: STM32: Use dma-ranges property per board
>> >> not
>> >> at dtsi
>> >> >> >> >>>> file
>> >> >> >> >>>>
>> >> >> >> >>>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
>> >> >> >> >>>> b/arch/arm/boot/dts/stm32429i-eval.dts
>> >> >> >> >>>> index 6bfc595..2a22a82 100644
>> >> >> >> >>>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
>> >> >> >> >>>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
>> >> >> >> >>>> @@ -52,6 +52,10 @@
>> >> >> >> >>>> model = "STMicroelectronics STM32429i-EVAL
>> >> board";
>> >> >> >> >>>> compatible = "st,stm32429i-eval",
>> >> "st,stm32f429";
>> >> >> >> >>>>
>> >> >> >> >>>> + soc {
>> >> >> >> >>>> + dma-ranges = <0xC0000000 0x0
>> >> 0x10000000>;
>> >> >> >> >>>> + };
>> >> >> >> >>>> +
>> >> >> >> >>>> chosen {
>> >> >> >> >>>> bootargs = "root=/dev/ram
>> >> rdinit=/linuxrc";
>> >> >> >> >>>> stdout-path = "serial0:115200n8";
>> >> >> >> >>>> @@ -96,6 +100,7 @@
>> >> >> >> >>>>
>> >> >> >> >>>> ðernet0 {
>> >> >> >> >>>> status = "okay";
>> >> >> >> >>>> + dma-ranges;
>> >> >> >> >>>> pinctrl-0 = <ðernet0_mii>;
>> >> >> >> >>>> pinctrl-names = "default";
>> >> >> >> >>>> phy-mode = "mii-id";
>> >> >> >> >>>> @@ -116,6 +121,7 @@
>> >> >> >> >>>> };
>> >> >> >> >>>>
>> >> >> >> >>>> &usbotg_hs {
>> >> >> >> >>>> + dma-ranges;
>> >> >> >> >>>> dr_mode = "host";
>> >> >> >> >>>> phys = <&usbotg_hs_phy>;
>> >> >> >> >>>> phy-names = "usb2-phy";
>> >> >> >> >>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
>> >> >> >> >>>> b/arch/arm/boot/dts/stm32f429.dtsi
>> >> >> >> >>>> index 7d624a2..697a133 100644
>> >> >> >> >>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>> >> >> >> >>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>> >> >> >> >>>> @@ -59,7 +59,6 @@
>> >> >> >> >>>> };
>> >> >> >> >>>>
>> >> >> >> >>>> soc {
>> >> >> >> >>>> - dma-ranges = <0xc0000000 0x0
>> >> 0x10000000>;
>> >> >> >> >>>>
>> >> >> >> >>>> timer2: timer@40000000 {
>> >> >> >> >>>> compatible = "st,stm32-timer";
>> >> >> >> >>>> @@ -472,13 +471,11 @@
>> >> >> >> >>>> st,syscon = <&syscfg 0x4>;
>> >> >> >> >>>> snps,pbl = <8>;
>> >> >> >> >>>> snps,mixed-burst;
>> >> >> >> >>>> - dma-ranges;
>> >> >> >> >>>> status = "disabled";
>> >> >> >> >>>> };
>> >> >> >> >>>>
>> >> >> >> >>>> usbotg_hs: usb@40040000 {
>> >> >> >> >>>> compatible = "snps,dwc2";
>> >> >> >> >>>> - dma-ranges;
>> >> >> >> >>>> reg = <0x40040000 0x40000>;
>> >> >> >> >>>> interrupts = <77>;
>> >> >> >> >>>> clocks = <&rcc 0 29>;
>> >> >> >> >>>>
>> >> >> >> >>>>
>> >> >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
>> >> >> >> >>>>> b/arch/arm/boot/dts/stm32f429.dtsi
>> >> >> >> >>>>> index 0596d60..3a1cfdd 100644
>> >> >> >> >>>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>> >> >> >> >>>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>> >> >> >> >>>>> @@ -59,8 +59,6 @@
>> >> >> >> >>>>> };
>> >> >> >> >>>>>
>> >> >> >> >>>>> soc {
>> >> >> >> >>>>> - dma-ranges = <0xc0000000 0x0
>> >> 0x10000000>;
>> >> >> >> >>>>> -
>> >> >> >> >>>>> timer2: timer@40000000 {
>> >> >> >> >>>>> compatible = "st,stm32-timer";
>> >> >> >> >>>>> reg = <0x40000000 0x400>;
>> >> >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts
>> >> >> >> >>>>> b/arch/arm/boot/dts/stm32f469-disco.dts
>> >> >> >> >>>>> index 9e73656..c2213c0 100644
>> >> >> >> >>>>> --- a/arch/arm/boot/dts/stm32f469-disco.dts
>> >> >> >> >>>>> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
>> >> >> >> >>>>> @@ -64,6 +64,10 @@
>> >> >> >> >>>>> aliases {
>> >> >> >> >>>>> serial0 = &usart3;
>> >> >> >> >>>>> };
>> >> >> >> >>>>> +
>> >> >> >> >>>>> + soc {
>> >> >> >> >>>>> + dma-ranges = <0xc0000000 0x0
>> >> 0x10000000>;
>> >> >> >> >>>>> + };
>> >> >> >> >>>>> };
>> >> >> >> >>>>>
>> >> >> >> >>>>> &clk_hse {
>> >> >> >> >>>>> --
>> >> >> >> >>>>
>> >> >> >> >>>>
>> >> >> >> >>>>
>> >> >> >> >>>>
>> >> >> >> >>>> Br.,
>> >> >> >> >>>> Bruno
>> >> >> >> >>>>
>> >> >> >> >>>
>> >> >> >> >
>> >> >> >>
>> >> >> >> _______________________________________________
>> >> >> >> linux-arm-kernel mailing list
>> >> >> >> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>> >> <mailto:linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
>> >> >> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>> >> <http://lists.infradead.org/mailman/listinfo/linux-arm-kernel>
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >
>
>
--
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: DT: stm32: move dma translation to board files
From: Radosław Pietrzyk @ 2016-11-02 18:05 UTC (permalink / raw)
To: Bruno Herrera
Cc: Alexandre Torgue, mark.rutland, devicetree, Arnd Bergmann, linux,
>, >, Maxime Coquelin, Lee Jones, linux-arm-kernel,
andrea.merello
In-Reply-To: <CAF3+TqeiPjtG7Fs1-cpbcHGxxtSS1UOGD=S=sggpaZahFLJhEQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 15279 bytes --]
Have you tried with
sdio {
...
compatible = "arm,primecell";
arm,primecell-periphid = <id_to_define>;
...
}
This should register proper amba device and give it an ID you wish.
2016-11-02 17:07 GMT+01:00 Bruno Herrera <bruherrera@gmail.com>:
> Hi
>
> On Wed, Nov 2, 2016 at 12:32 PM, Alexandre Torgue
> <alexandre.torgue@st.com> wrote:
> > Hi
> >
> > On 10/31/2016 07:58 PM, Radosław Pietrzyk wrote:
> >>
> >> I think wlcore driver searches dma-ranges in its parent that's why sdio
> >> node needs it.
> >
> >
> > Yes I agree. In this case it is needed as you have subnode in sdio node.
> > So IMO empty dma-ranges could be removed from ethernet and usb node, but
> > kept in future sdio subnode.
>
> Now it is clear.
>
> >
> > Bruno,
> > Do you plan to push sdio support ?
>
> Yes I do, but I'm not sure how long it will take. The I had to
> change(and hack) the mmci code because I could not get the ID from
> STM32 SDIO IP.
> My current WIP is at @
> https://github.com/mcoquelin-stm32/afboot-stm32/pull/4#
> issuecomment-247571615
> I know Andrea Merello is also working on that (and he probably has a
> more complete patch).
>
> >
> >
> >
> >>
> >> 2016-10-31 17:41 GMT+01:00 Bruno Herrera <bruherrera@gmail.com
> >> <mailto:bruherrera@gmail.com>>:
> >>
> >> On Mon, Oct 31, 2016 at 12:14 PM, Radosław Pietrzyk
> >> <radoslaw.pietrzyk@gmail.com <mailto:radoslaw.pietrzyk@gmail.com>>
> >> wrote:
> >> > This is weird because dma ddresses are recalculated using parent's
> >> > dma-ranges property and soc already has it so there should be
> >> absolutely no
> >> > problem.
> >>
> >> These are my DTS and DTSI file.
> >> >
> >> > 2016-10-31 11:27 GMT+01:00 Bruno Herrera <bruherrera@gmail.com
> >> <mailto:bruherrera@gmail.com>>:
> >> >>
> >> >> On Fri, Oct 28, 2016 at 5:09 AM, Radosław Pietrzyk
> >> >> <radoslaw.pietrzyk@gmail.com
> >> <mailto:radoslaw.pietrzyk@gmail.com>> wrote:
> >> >> > Have you defined your sdio node within soc node ?
> >> >>
> >> >> It is in the SOC node of the DSTI file.
> >> >>
> >> >> >
> >> >> > 2016-10-27 14:57 GMT+02:00 Bruno Herrera <bruherrera@gmail.com
> >> <mailto:bruherrera@gmail.com>>:
> >> >> >>
> >> >> >> Hi Alex,
> >> >> >>
> >> >> >> On Thu, Oct 27, 2016 at 10:21 AM, Alexandre Torgue
> >> >> >> <alexandre.torgue@st.com <mailto:alexandre.torgue@st.com>>
> >> wrote:
> >> >> >> > Hi Bruno,
> >> >> >> >
> >> >> >> >
> >> >> >> > On 10/27/2016 12:43 PM, Bruno Herrera wrote:
> >> >> >> >>
> >> >> >> >> Hi Alex,
> >> >> >> >>
> >> >> >> >> On Wed, Oct 26, 2016 at 7:09 AM, Alexandre Torgue
> >> >> >> >> <alexandre.torgue@st.com <mailto:alexandre.torgue@st.com>>
> >> wrote:
> >> >> >> >>>
> >> >> >> >>> Hi Bruno,
> >> >> >> >>>
> >> >> >> >>> On 10/25/2016 11:06 PM, Bruno Herrera wrote:
> >> >> >> >>>>
> >> >> >> >>>>
> >> >> >> >>>> Hi Alexandre,
> >> >> >> >>>>
> >> >> >> >>>>>
> >> >> >> >>>>> stm32f469-disco and stm32f429-eval boards use SDRAM
> >> start address
> >> >> >> >>>>> remapping
> >> >> >> >>>>> (to @0) to boost performances. A DMA translation through
> >> >> >> >>>>> "dma-ranges"
> >> >> >> >>>>> property was needed for other masters than the M4 CPU.
> >> >> >> >>>>> stm32f429-disco doesn't use remapping so doesn't need
> >> this DMA
> >> >> >> >>>>> translation.
> >> >> >> >>>>> This patches moves this DMA translation definition from
> >> stm32f429
> >> >> >> >>>>> soc
> >> >> >> >>>>> file
> >> >> >> >>>>> to board files.
> >> >> >> >>>>>
> >> >> >> >>>>> Signed-off-by: Alexandre TORGUE <
> alexandre.torgue@st.com
> >> <mailto:alexandre.torgue@st.com>>
> >>
> >> >> >> >>>>>
> >> >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >> >>>>> b/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >> >>>>> index 13c7cd2..a763c15 100644
> >> >> >> >>>>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >> >>>>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >> >>>>> @@ -82,6 +82,10 @@
> >> >> >> >>>>> };
> >> >> >> >>>>> };
> >> >> >> >>>>>
> >> >> >> >>>>> + soc {
> >> >> >> >>>>> + dma-ranges = <0xc0000000 0x0
> 0x10000000>;
> >> >> >> >>>>> + };
> >> >> >> >>>>> +
> >> >> >> >>>>> usbotg_hs_phy: usbphy {
> >> >> >> >>>>> #phy-cells = <0>;
> >> >> >> >>>>> compatible = "usb-nop-xceiv";
> >> >> >> >>>>
> >> >> >> >>>>
> >> >> >> >>>>
> >> >> >> >>>> Shouldn't also the peripheral dma-ranges property move to
> >> board
> >> >> >> >>>> specific
> >> >> >> >>>> too?
> >> >> >> >>>> I had this patch for while but I didn't had the time to
> >> submit:
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>> Well spot I forgot it. Actually, discussing with Arnd
> >> ysterday on
> >> >> >> >>> IIRC,
> >> >> >> >>> empty dma-ranges is not needed. Can you test on your side
> by
> >> >> >> >>> removing
> >> >> >> >>> dma-ranges in usb node please ?
> >> >> >> >>
> >> >> >> >> Unfortunately will take a time for me to set up this
> >> environment on
> >> >> >> >> the STM32F4-EVAL board.
> >> >> >> >> And on the discovery boards we dont have this scenario.
> >> That was the
> >> >> >> >> main reason I did not submit the patch right away.
> >> >> >> >> My conclusion and I might be wrong but is based on the my
> >> tests with
> >> >> >> >> SDIO device at STM32F469I-DISCO board.
> >> >> >> >>
> >> >> >> >> I started this issue as discussion at ST Forum but Maxime
> >> gave me
> >> >> >> >> the
> >> >> >> >> hint.
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >>
> >> https://my.st.com/public/STe2ecommunities/mcu/Lists/
> cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%
> 2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%
> 2fDMA2%20and%20SYSCFG_MEMRMP%20relationship&FolderCTID=
> 0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46
> A77F0FFD06506F5B¤tviews=44
> >>
> >> <https://my.st.com/public/STe2ecommunities/mcu/Lists/
> cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%
> 2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%
> 2fDMA2%20and%20SYSCFG_MEMRMP%20relationship&FolderCTID=
> 0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46
> A77F0FFD06506F5B¤tviews=44>
> >> >> >> >>
> >> >> >> >>> I will push a v2 by removing empty dma-ranges if tests are
> >> ok in
> >> >> >> >>> your
> >> >> >> >>> side.
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> From my understating/conclusion is: when empty
> >> property(dma-ranges)
> >> >> >> >> is
> >> >> >> >> the device node, the mapping will be taken in consideration
> >> when
> >> >> >> >> using
> >> >> >> >> DMA otherwise the mapping is ignored.
> >> >> >> >> And in the SDIO case it is needed for DEV->MEM(SDRAM) and
> >> >> >> >> MEM(SDRAM)->DEV. If it is not the case for the devices in
> >> question
> >> >> >> >> so
> >> >> >> >> I suppose it can work without the property.
> >> >> >> >
> >> >> >> >
> >> >> >> > For sure translation has to be done but I'm not sure that an
> >> empty
> >> >> >> > "dma-ranges" is needed in device node to activate it. For
> >> Ethernet
> >> >> >> > empty
> >> >> >> > "dma-ranges" is not needed. I will try with usb.
> >> >> >>
> >> >> >> In the case of SDIO it is needed. As example this is my
> >> working SDIO
> >> >> >> node:
> >> >> >>
> >> >> >> sdio: sdio@40012c00 {
> >> >> >> compatible = "arm,pl18x", "arm,primecell";
> >> >> >> arm,primecell-periphid = <0x00480181>;
> >> >> >> reg = <0x40012c00 0x400>;
> >> >> >> dmas = <&dma2 6 4 0x10400 0x3>, /* Logical - DevToMem */
> >> >> >> <&dma2 3 4 0x10400 0x3>; /* Logical - MemToDev */
> >> >> >> dma-names = "rx", "tx";
> >> >> >> clocks = <&rcc 0 171>;
> >> >> >> clock-names = "apb_pclk";
> >> >> >> interrupts = <49>;
> >> >> >> status = "disabled";
> >> >> >> };
> >> >> >>
> >> >> >> &sdio {
> >> >> >> status = "okay";
> >> >> >> vmmc-supply = <&wlan_en>;
> >> >> >> bus-width = <4>;
> >> >> >> max-frequency = <24000000>;
> >> >> >> pinctrl-names = "default";
> >> >> >> pinctrl-0 = <&sdio_pins>;
> >> >> >> ti,non-removable;
> >> >> >> ti,needs-special-hs-handling;
> >> >> >> dma-ranges;
> >> >> >> cap-power-off-card;
> >> >> >> keep-power-in-suspend;
> >> >> >>
> >> >> >> #address-cells = <1>;
> >> >> >> #size-cells = <0>;
> >> >> >> wlcore: wlcore@0 {
> >> >> >> compatible = "ti,wl1835";
> >> >> >> reg = <2>;
> >> >> >> interrupt-parent = <&gpioa>;
> >> >> >> interrupts = <8 IRQ_TYPE_EDGE_RISING>;
> >> >> >> };
> >> >> >> };
> >> >> >>
> >> >> >> >
> >> >> >> > alex
> >> >> >> >
> >> >> >> >
> >> >> >> >>
> >> >> >> >>>
> >> >> >> >>> Thanks in advance
> >> >> >> >>> Alex
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>>>
> >> >> >> >>>> Author: Bruno Herrera <bruherrera@gmail.com
> >> <mailto:bruherrera@gmail.com>>
> >>
> >> >> >> >>>> Date: Sun Oct 16 14:50:00 2016 -0200
> >> >> >> >>>>
> >> >> >> >>>> ARM: DT: STM32: Use dma-ranges property per board not
> >> at dtsi
> >> >> >> >>>> file
> >> >> >> >>>>
> >> >> >> >>>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >> >>>> b/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >> >>>> index 6bfc595..2a22a82 100644
> >> >> >> >>>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >> >>>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >> >>>> @@ -52,6 +52,10 @@
> >> >> >> >>>> model = "STMicroelectronics STM32429i-EVAL
> board";
> >> >> >> >>>> compatible = "st,stm32429i-eval", "st,stm32f429";
> >> >> >> >>>>
> >> >> >> >>>> + soc {
> >> >> >> >>>> + dma-ranges = <0xC0000000 0x0 0x10000000>;
> >> >> >> >>>> + };
> >> >> >> >>>> +
> >> >> >> >>>> chosen {
> >> >> >> >>>> bootargs = "root=/dev/ram
> rdinit=/linuxrc";
> >> >> >> >>>> stdout-path = "serial0:115200n8";
> >> >> >> >>>> @@ -96,6 +100,7 @@
> >> >> >> >>>>
> >> >> >> >>>> ðernet0 {
> >> >> >> >>>> status = "okay";
> >> >> >> >>>> + dma-ranges;
> >> >> >> >>>> pinctrl-0 = <ðernet0_mii>;
> >> >> >> >>>> pinctrl-names = "default";
> >> >> >> >>>> phy-mode = "mii-id";
> >> >> >> >>>> @@ -116,6 +121,7 @@
> >> >> >> >>>> };
> >> >> >> >>>>
> >> >> >> >>>> &usbotg_hs {
> >> >> >> >>>> + dma-ranges;
> >> >> >> >>>> dr_mode = "host";
> >> >> >> >>>> phys = <&usbotg_hs_phy>;
> >> >> >> >>>> phy-names = "usb2-phy";
> >> >> >> >>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >> >>>> b/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >> >>>> index 7d624a2..697a133 100644
> >> >> >> >>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >> >>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >> >>>> @@ -59,7 +59,6 @@
> >> >> >> >>>> };
> >> >> >> >>>>
> >> >> >> >>>> soc {
> >> >> >> >>>> - dma-ranges = <0xc0000000 0x0 0x10000000>;
> >> >> >> >>>>
> >> >> >> >>>> timer2: timer@40000000 {
> >> >> >> >>>> compatible = "st,stm32-timer";
> >> >> >> >>>> @@ -472,13 +471,11 @@
> >> >> >> >>>> st,syscon = <&syscfg 0x4>;
> >> >> >> >>>> snps,pbl = <8>;
> >> >> >> >>>> snps,mixed-burst;
> >> >> >> >>>> - dma-ranges;
> >> >> >> >>>> status = "disabled";
> >> >> >> >>>> };
> >> >> >> >>>>
> >> >> >> >>>> usbotg_hs: usb@40040000 {
> >> >> >> >>>> compatible = "snps,dwc2";
> >> >> >> >>>> - dma-ranges;
> >> >> >> >>>> reg = <0x40040000 0x40000>;
> >> >> >> >>>> interrupts = <77>;
> >> >> >> >>>> clocks = <&rcc 0 29>;
> >> >> >> >>>>
> >> >> >> >>>>
> >> >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >> >>>>> b/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >> >>>>> index 0596d60..3a1cfdd 100644
> >> >> >> >>>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >> >>>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >> >>>>> @@ -59,8 +59,6 @@
> >> >> >> >>>>> };
> >> >> >> >>>>>
> >> >> >> >>>>> soc {
> >> >> >> >>>>> - dma-ranges = <0xc0000000 0x0
> 0x10000000>;
> >> >> >> >>>>> -
> >> >> >> >>>>> timer2: timer@40000000 {
> >> >> >> >>>>> compatible = "st,stm32-timer";
> >> >> >> >>>>> reg = <0x40000000 0x400>;
> >> >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts
> >> >> >> >>>>> b/arch/arm/boot/dts/stm32f469-disco.dts
> >> >> >> >>>>> index 9e73656..c2213c0 100644
> >> >> >> >>>>> --- a/arch/arm/boot/dts/stm32f469-disco.dts
> >> >> >> >>>>> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
> >> >> >> >>>>> @@ -64,6 +64,10 @@
> >> >> >> >>>>> aliases {
> >> >> >> >>>>> serial0 = &usart3;
> >> >> >> >>>>> };
> >> >> >> >>>>> +
> >> >> >> >>>>> + soc {
> >> >> >> >>>>> + dma-ranges = <0xc0000000 0x0
> 0x10000000>;
> >> >> >> >>>>> + };
> >> >> >> >>>>> };
> >> >> >> >>>>>
> >> >> >> >>>>> &clk_hse {
> >> >> >> >>>>> --
> >> >> >> >>>>
> >> >> >> >>>>
> >> >> >> >>>>
> >> >> >> >>>>
> >> >> >> >>>> Br.,
> >> >> >> >>>> Bruno
> >> >> >> >>>>
> >> >> >> >>>
> >> >> >> >
> >> >> >>
> >> >> >> _______________________________________________
> >> >> >> linux-arm-kernel mailing list
> >> >> >> linux-arm-kernel@lists.infradead.org
> >> <mailto:linux-arm-kernel@lists.infradead.org>
> >> >> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >> <http://lists.infradead.org/mailman/listinfo/linux-arm-kernel>
> >> >> >
> >> >> >
> >> >
> >> >
> >>
> >>
> >
>
[-- Attachment #2: Type: text/html, Size: 28650 bytes --]
^ permalink raw reply
* Re: [PATCH] clk: cdce925: add support for CDCE913, CDCE937, and CDCE949
From: Stephen Boyd @ 2016-11-02 17:56 UTC (permalink / raw)
To: Akinobu Mita
Cc: linux-clk-u79uwXL29TY76Z2rM5mHXA, open list:OPEN FIRMWARE AND...,
Mike Looijmans, Michael Turquette
In-Reply-To: <CAC5umyj+NO7tXEfT4YEGAo6-CRfxufLHPSXQVmCdJjHDYgZiSg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 11/02, Akinobu Mita wrote:
> 2016-11-02 2:48 GMT+09:00 Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>:
> > On 11/01, Akinobu Mita wrote:
> >> 2016-11-01 3:15 GMT+09:00 Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>:
> >> > On 10/31, Akinobu Mita wrote:
> >>
> >> I think it isn't needed. Because the data field in struct of_device_id
> >> for this driver is not used even if the device is registered from
> >> device tree. But the driver_data in i2c_device_id is used instead.
> >
> > Ok. Have you tested this driver with DT or platform data? Do you
> > prefix the compatible string with "ti," in the DT case?
>
> I have tested with DT with compatible = "ti,cdce937" and checked that
> correct i2c_device_id is passed by the caller of cdce925_probe().
>
> According to of_i2c_register_device() in drivers/i2c/i2c-core.c,
> the manufacturer prefix like "ti," is stripped from i2c_client->name by
> of_modalias_node(). So i2c_match_id() can find correct i2c_device_id
> entry and ->probe() is called with it.
Great! Thanks for the explanation.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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