* Re: [PATCH v2 1/5] dt-bindings: mtd: add Marvell NAND controller documentation
From: Rob Herring @ 2017-12-20 21:05 UTC (permalink / raw)
To: Miquel Raynal
Cc: David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
Richard Weinberger, Cyrille Pitchen, Mark Rutland, Jason Cooper,
Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Russell King,
Daniel Mack, Haojian Zhuang, Robert Jarzmik, Eric Miao,
Catalin Marinas, Will Deacon, Ezequiel
In-Reply-To: <20171219132942.27433-2-miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Tue, Dec 19, 2017 at 02:29:38PM +0100, Miquel Raynal wrote:
> Document the legacy and the new bindings for Marvell NAND controller.
>
> The pxa3xx_nand.c driver does only support legacy bindings, which are
> incomplete and inaccurate. A rework of this controller (called
> marvell_nand.c) does support both.
>
> Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> .../devicetree/bindings/mtd/marvell-nand.txt | 123 +++++++++++++++++++++
> 1 file changed, 123 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/marvell-nand.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/marvell-nand.txt b/Documentation/devicetree/bindings/mtd/marvell-nand.txt
> new file mode 100644
> index 000000000000..aa6a1ed045b2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/marvell-nand.txt
> @@ -0,0 +1,123 @@
> +Marvell NAND Flash Controller (NFC)
> +
> +Required properties:
> +- compatible: can be one of the following:
> + * "marvell,armada-8k-nand-controller"
> + * "marvell,armada370-nand-controller"
> + * "marvell,pxa3xx-nand-controller"
> + * "marvell,armada-8k-nand" (deprecated)
> + * "marvell,armada370-nand" (deprecated)
> + * "marvell,pxa3xx-nand" (deprecated)
> + Compatibles marked deprecated support only the old bindings described
> + at the bottom.
> +- reg: NAND flash controller memory area.
> +- #address-cells: shall be set to 1. Encode the NAND CS.
> +- #size-cells: shall be set to 0.
> +- interrupts: shall define the NAND controller interrupt.
> +- clocks: shall reference the NAND controller clock.
> +- marvell,system-controller: Set to retrieve the syscon node that handles
> + NAND controller related registers (only required with the
> + "marvell,armada-8k-nand[-controller]" compatibles).
> +
> +Optional properties:
> +- label: see partition.txt. New platforms shall omit this property.
> +- dmas: shall reference DMA channel associated to the NAND controller.
> + This property is only used with "marvell,pxa3xx-nand[-controller]"
> + compatible strings.
> +- dma-names: shall be "rxtx".
> + This property is only used with "marvell,pxa3xx-nand[-controller]"
> + compatible strings.
> +
> +Optional children nodes:
> +Children nodes represent the available NAND chips.
> +
> +Required properties:
> +- reg: shall contain the native Chip Select ids (0-3)
> +- marvell,rb: shall contain the native Ready/Busy ids (0-1)
We already have at least 2 other <vendor>,rb properties. Let's not add a
3rd and make a common one instead.
> +
> +Optional properties:
> +- marvell,nand-keep-config: orders the driver not to take the timings
> + from the core and leaving them completely untouched. Bootloader
> + timings will then be used.
> +- label: MTD name.
> +- nand-on-flash-bbt: see nand.txt.
> +- nand-ecc-mode: see nand.txt. Will use hardware ECC if not specified.
> +- nand-ecc-algo: see nand.txt. This property may be added when using
> + hardware ECC for clarification but will be ignored by the driver
> + because ECC mode is chosen depending on the page size and the strength
> + required by the NAND chip. This value may be overwritten with
> + nand-ecc-strength property.
If not used, then drop it.
> +- nand-ecc-strength: see nand.txt.
> +- nand-ecc-step-size: see nand.txt. This has no effect and will be
> + ignored by the driver when using hardware ECC because Marvell's NAND
> + flash controller does use fixed strength (1-bit for Hamming, 16-bit
> + for BCH), so the step size will shrink or grow in order to fit the
> + required strength. Step sizes are not completely random for all and
> + follow certain patterns described in AN-379, "Marvell SoC NFC ECC".
Same here.
> +
> +See Documentation/devicetree/bindings/mtd/nand.txt for more details on
> +generic bindings.
> +
> +
> +Example:
> +nand_controller: nand-controller@d0000 {
> + compatible = "marvell,armada370-nand-controller";
> + reg = <0xd0000 0x54>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&coredivclk 0>;
> +
> + nand@0 {
> + reg = <0>;
> + label = "main-storage";
> + marvell,rb = <0>;
> + nand-ecc-mode = "hw";
> + marvell,nand-keep-config;
> + nand-on-flash-bbt;
> + nand-ecc-strength = <4>;
> + nand-ecc-step-size = <512>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "Rootfs";
> + reg = <0x00000000 0x40000000>;
> + };
> + };
> + };
> +};
> +
> +
> +Note on legacy bindings: One can find, in not-updated device trees,
> +bindings slightly differents than described above with other properties
s/differents/different/
> +described below as well as the partitions node at the root of a so
> +called "nand" node (without clear controller/chip separation).
> +
> +Legacy properties:
> +- marvell,nand-enable-arbiter: To enable the arbiter, all boards blindly
> + used it, this bit was set by the bootloader for many boards and even if
> + it is marked reserved in several datasheets, it might be needed to set
> + it (otherwise it is harmless) so whether or not this property is set,
> + the bit is selected by the driver.
> +- num-cs: Number of chip-select lines to use, all boards blindly set 1
> + to this and for a reason, other values would have failed. The value of
> + this property is ignored.
> +
> +Example:
> +
> + nand0: nand@43100000 {
> + compatible = "marvell,pxa3xx-nand";
> + reg = <0x43100000 90>;
> + interrupts = <45>;
> + dmas = <&pdma 97 0>;
> + dma-names = "rxtx";
> + #address-cells = <1>;
> + marvell,nand-keep-config;
> + marvell,nand-enable-arbiter;
> + num-cs = <1>;
> + /* Partitions (optional) */
> + };
> --
> 2.11.0
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 4/5] dt-bindings: mtd: remove pxa3xx NAND controller documentation
From: Rob Herring @ 2017-12-20 21:06 UTC (permalink / raw)
To: Miquel Raynal
Cc: David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
Richard Weinberger, Cyrille Pitchen, Mark Rutland, Jason Cooper,
Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Russell King,
Daniel Mack, Haojian Zhuang, Robert Jarzmik, Eric Miao,
Catalin Marinas, Will Deacon, Ezequiel
In-Reply-To: <20171219132942.27433-5-miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Tue, Dec 19, 2017 at 02:29:41PM +0100, Miquel Raynal wrote:
> The deprecated pxa3xx_nand.c driver does not exist anymore, it has been
> replaced by marvell_nand.c which has its own up-to-date documentation.
>
> Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> .../devicetree/bindings/mtd/pxa3xx-nand.txt | 50 ----------------------
> 1 file changed, 50 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110
From: Rob Herring @ 2017-12-20 21:08 UTC (permalink / raw)
To: Miquel Raynal
Cc: Zhang Rui, Eduardo Valentin, Mark Rutland,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Gregory Clement, Antoine Tenart, Nadav Haklai,
Baruch Siach, David Sniatkiwicz
In-Reply-To: <20171219135719.9531-2-miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Tue, Dec 19, 2017 at 02:57:09PM +0100, Miquel Raynal wrote:
> From: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
>
> Add compatible strings for AP806 and CP110 that are part of the Armada
> 8k/7k line of SoCs.
>
> Add a note on the differences in the size of the control area in
> different bindings. This is an existing difference between the Armada
> 375 binding and the other boards already supported. The new AP806 and
> CP110 bindings are similar to the existing Armada 375 in this regard.
>
> Signed-off-by: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
> [<miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>: reword, additional details]
> Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> .../devicetree/bindings/thermal/armada-thermal.txt | 37 +++++++++++++++-------
> 1 file changed, 25 insertions(+), 12 deletions(-)
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 05/15] devicetree: bindings: Document qcom,hfpll
From: Rob Herring @ 2017-12-20 21:11 UTC (permalink / raw)
To: Sricharan R
Cc: mark.rutland-5wv7dgnIgG8, mturquette-rdvid1DuHRBWk0Htik3J/w,
sboyd-sgV2jX0FEOL9JmXXK+q4OQ, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
andy.gross-QSEj5FYQhm4dnm+yROfE0A,
david.brown-QSEj5FYQhm4dnm+yROfE0A, rjw-LthD3rsA81gm4RdzfppkhA,
viresh.kumar-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA, linux-pm-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1513698900-10638-6-git-send-email-sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Tue, Dec 19, 2017 at 09:24:50PM +0530, Sricharan R wrote:
> From: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>
> Adds bindings document for qcom,hfpll instantiated within
> the Krait processor subsystem as separate register region.
>
> Signed-off-by: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> ---
> .../devicetree/bindings/clock/qcom,hfpll.txt | 46 ++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/qcom,hfpll.txt
"dt-bindings: " is the preferred subject prefix. Otherwise,
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 10/15] devicetree: bindings: Document qcom,kpss-gcc
From: Rob Herring @ 2017-12-20 21:13 UTC (permalink / raw)
To: Sricharan R
Cc: mark.rutland, mturquette, sboyd, linux, andy.gross, david.brown,
rjw, viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-clk, linux-arm-msm, linux-soc, linux-pm
In-Reply-To: <1513698900-10638-11-git-send-email-sricharan@codeaurora.org>
On Tue, Dec 19, 2017 at 09:24:55PM +0530, Sricharan R wrote:
> From: Stephen Boyd <sboyd@codeaurora.org>
>
> The ACC and GCC regions present in KPSSv1 contain registers to
> control clocks and power to each Krait CPU and L2. Documenting
> the bindings here.
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> .../devicetree/bindings/arm/msm/qcom,kpss-acc.txt | 7 +++++
> .../devicetree/bindings/arm/msm/qcom,kpss-gcc.txt | 32 ++++++++++++++++++++++
> 2 files changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v5 12/15] devicetree: bindings: Document qcom,krait-cc
From: Rob Herring @ 2017-12-20 21:14 UTC (permalink / raw)
To: Sricharan R
Cc: mark.rutland, mturquette, sboyd, linux, andy.gross, david.brown,
rjw, viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-clk, linux-arm-msm, linux-soc, linux-pm
In-Reply-To: <1513698900-10638-13-git-send-email-sricharan@codeaurora.org>
On Tue, Dec 19, 2017 at 09:24:57PM +0530, Sricharan R wrote:
> From: Stephen Boyd <sboyd@codeaurora.org>
>
> The Krait clock controller controls the krait CPU and the L2 clocks
> consisting a primary mux and secondary mux. Add document for that.
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> .../devicetree/bindings/clock/qcom,krait-cc.txt | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/qcom,krait-cc.txt
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v5 15/15] devicetree: bindings: Document qcom,pvs
From: Rob Herring @ 2017-12-20 21:18 UTC (permalink / raw)
To: Sricharan R
Cc: Viresh Kumar, mark.rutland-5wv7dgnIgG8,
mturquette-rdvid1DuHRBWk0Htik3J/w, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, andy.gross-QSEj5FYQhm4dnm+yROfE0A,
david.brown-QSEj5FYQhm4dnm+yROfE0A, rjw-LthD3rsA81gm4RdzfppkhA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA, linux-pm-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <b0d8147a-46e1-0787-ae37-9c1ef957d190-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Wed, Dec 20, 2017 at 11:55:33AM +0530, Sricharan R wrote:
> Hi Viresh,
>
> On 12/20/2017 8:56 AM, Viresh Kumar wrote:
> > On 19-12-17, 21:25, Sricharan R wrote:
> >> + cpu@0 {
> >> + compatible = "qcom,krait";
> >> + enable-method = "qcom,kpss-acc-v1";
> >> + device_type = "cpu";
> >> + reg = <0>;
> >> + qcom,acc = <&acc0>;
> >> + qcom,saw = <&saw0>;
> >> + clocks = <&kraitcc 0>;
> >> + clock-names = "cpu";
> >> + cpu-supply = <&smb208_s2a>;
> >> + operating-points-v2 = <&cpu_opp_table>;
> >> + };
> >> +
> >> + qcom,pvs {
> >> + qcom,pvs-format-a;
> >> + };
> >
> > Not sure what Rob is going to say on that :)
> >
>
> Yes. Would be good to know the best way.
Seems like this should be a property of an efuse node either implied by
the compatible or a separate property. What determines format A vs. B?
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: pwm: renesas-tpu: Correct example TPU register block size
From: Rob Herring @ 2017-12-20 21:19 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Thierry Reding, Mark Rutland, Simon Horman, Magnus Damm,
linux-pwm, devicetree, linux-renesas-soc
In-Reply-To: <1513699327-27357-3-git-send-email-geert+renesas@glider.be>
On Tue, Dec 19, 2017 at 05:02:06PM +0100, Geert Uytterhoeven wrote:
> The Timer Pulse Unit on R-Mobile A1 has registers that lie outside the
> declared register block. Enlarge the register block size to fix this.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 3/3] dt-bindings: pwm: renesas-tpu: Correct SoC part numbers and family names
From: Rob Herring @ 2017-12-20 21:19 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Thierry Reding, Mark Rutland, Simon Horman, Magnus Damm,
linux-pwm, devicetree, linux-renesas-soc
In-Reply-To: <1513699327-27357-4-git-send-email-geert+renesas@glider.be>
On Tue, Dec 19, 2017 at 05:02:07PM +0100, Geert Uytterhoeven wrote:
> R8A73A4 (not R8A77A4) is R-Mobile APE6,
> R8A7740 is R-Mobile (not R-Car) A1.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] dt-bindings: gpio: rcar: Correct SoC family name for R8A7778
From: Rob Herring @ 2017-12-20 21:20 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linus Walleij, Mark Rutland, linux-gpio, devicetree,
linux-renesas-soc
In-Reply-To: <1513699422-27671-1-git-send-email-geert+renesas@glider.be>
On Tue, Dec 19, 2017 at 05:03:42PM +0100, Geert Uytterhoeven wrote:
> R8A7778 is R-Car (not R-Mobile) M1.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 2/9] dt-bindings: arm: brcmstb: Correct BIUCTRL node documentation
From: Rob Herring @ 2017-12-20 21:24 UTC (permalink / raw)
To: Florian Fainelli
Cc: bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Mark Rutland,
Brian Norris, Gregory Fong,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM7XXX ARM ARCHITECTURE, open list
In-Reply-To: <20171219192247.29799-3-f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, Dec 19, 2017 at 11:22:40AM -0800, Florian Fainelli wrote:
> Correct the Device Tree bindings for the HIF_CPUBIUCTRL node whose
> compatible string is actually brcm,bcm<chip-id>-cpu-biu-ctrl. Also
> document in the binding the fallback property
> ("brcm,brcmstb-cpu-biu-ctrl") and update the example accordingly.
>
> Signed-off-by: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> .../devicetree/bindings/arm/bcm/brcm,brcmstb.txt | 22 ++++++++++++----------
> 1 file changed, 12 insertions(+), 10 deletions(-)
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 0/4] rtc: add mxc driver for i.MX53 SRTC
From: Alexandre Belloni @ 2017-12-20 21:25 UTC (permalink / raw)
To: linux-kernel-dev-QonKdJ6Bx35Wk0Htik3J/w
Cc: Patrick Bruenn, Alessandro Zummo, Rob Herring, Mark Rutland,
open list:REAL TIME CLOCK (RTC) SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Fabio Estevam, Juergen Borleis, Noel Vellemans,
Shawn Guo, Sascha Hauer, Russell King,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Philippe Ombredanne, Lothar
In-Reply-To: <20171218115133.16371-1-linux-kernel-dev-QonKdJ6Bx35Wk0Htik3J/w@public.gmane.org>
On 18/12/2017 at 12:51:29 +0100, linux-kernel-dev-QonKdJ6Bx35Wk0Htik3J/w@public.gmane.org wrote:
> From: Patrick Bruenn <p.bruenn-QonKdJ6Bx35Wk0Htik3J/w@public.gmane.org>
>
> Neither rtc-imxdi, rtc-mxc nor rtc-snvs are compatible with i.MX53.
>
> This is driver enables support for the low power domain SRTC features:
> - 32-bit MSB of non-rollover time counter
> - 32-bit alarm register
>
> Select the new config option RTC_DRV_MXC_V2 to build this driver
>
> Based on:
> http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/drivers/rtc/rtc-mxc_v2.c?h=imx_2.6.35_11.09.01
>
> Signed-off-by: Patrick Bruenn <p.bruenn-QonKdJ6Bx35Wk0Htik3J/w@public.gmane.org>
>
Applied 1/4 and 3/4, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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 00/12] Marvell NAND controller rework with ->exec_op()
From: Robert Jarzmik @ 2017-12-20 21:26 UTC (permalink / raw)
To: Miquel RAYNAL
Cc: Boris Brezillon, David Woodhouse, Brian Norris, Marek Vasut,
Richard Weinberger, Cyrille Pitchen, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Russell King, Daniel Mack, Haojian Zhuang, Eric Miao,
Catalin Marinas, Will Deacon
In-Reply-To: <20171218092535.2ca1fe13@xps13>
Miquel RAYNAL <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> writes:
> Hello Robert,
>
> On Mon, 18 Dec 2017 08:11:35 +0100
> Robert Jarzmik <robert.jarzmik-GANU6spQydw@public.gmane.org> wrote:
>
>> Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> writes:
>>
>> >> Robert, it would be great if you could also do more testing on PXA
>> >> and validate this driver. If needed, a branch ready to be tested is
>> >> available at [3]. It is based on nand/next and has all the changes
>> >> brought by the previously mentionned series as well as this one.
>> >
>> > Robert, do you think you'll have some time to test Miquel's branch
>> > on your PXA boards? Miquel already tested on one of these boards
>> > (CM-X300), but we'd like to have other testers. Also feel free to
>> > review the driver if have the time.
>> >
>> > Thanks,
>> >
>> > Boris
>>
>> Hi Boris and Miquel,
>>
>> I have applied the whole serie to linux-next yesterday.
>>
>> A boot attempt on my zylonite with my old defconfig (with the new
>> Marvell NAND config activated) yields to :
>> - this message
>> [ 3.136818] marvell-nfc pxa3xx-nand: could not identify the nand
>> chip [ 3.143874] marvell-nfc: probe of pxa3xx-nand failed with
>> error -22
>> - then my board hangs
>>
>> Is there something to be done to improve the trace level so that you
>> can guess what's happening ?
>
> Thank you very much for testing this.
>
> Could you please try this branch [1] instead of linux-next + the
> patches?
>
> Also, can you please add #define DEBUG in marvell_nand.c + nand_base.c,
> it should help us figuring out what is wrong.
Done, same result, the dmesg is in [1].
Cheers.
--
Robert
[1] Kernel output
Loading ARM Linux zImage '/mnt/tftp/zImage_jenkins'
commandline: ram=64M console=ttyS0,115200 ip=dhcp root=/dev/nfs nfsroot=/home/none/nfsroot/zylonite,v3,tcp earlycon mtdparts=pxa3xx_nand-0:128k@0(TIMH)ro,128k@128k(OBMI)ro,768k@256k(barebox),256k@1024k(barebox-env),12M@1280k(kernel),38016k@13568k(root)
arch_number: 1233
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.15.0-rc1-00041-g4dc0195 (jenkins@belgarath) (gcc version 4.8.3 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-29)) #721 PREEMPT Wed Dec 20 22:15:08 CET 2017
[ 0.000000] CPU: XScale-V3 based processor [69056891] revision 1 (ARMv5TE), cr=0000397f
[ 0.000000] CPU: VIVT data cache, VIVT instruction cache
[ 0.000000] Machine: PXA3xx Platform Development Kit (aka Zylonite)
[ 0.000000] Ignoring tag cmdline (using the default kernel command line)
[ 0.000000] Memory policy: Data cache writeback
[ 0.000000] RO Mode clock: 0.00MHz
[ 0.000000] Run Mode clock: 0.00MHz
[ 0.000000] Turbo Mode clock: 0.00MHz
[ 0.000000] System bus clock: 0.00MHz
[ 0.000000] On node 0 totalpages: 16384
[ 0.000000] Normal zone: 128 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 16384 pages, LIFO batch:3
[ 0.000000] random: fast init done
[ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[ 0.000000] pcpu-alloc: [0] 0
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 16256
[ 0.000000] Kernel command line: root=/dev/ram0 ip=192.168.1.232:192.168.1.5::255.255.255.0::eth0:on console=ttyS0,115200 mem=64M mtdparts=pxa3xx_nand-0:128k@0(TIMH)ro,128k@128k(OBMI)ro,768k@256k(barebox),256k@1024k(barebox-env),12M@1280k(kernel),38016k@13568k(root) ubi.mtd=5 earlycon=pxa,io,0xf6200000,115200n8 debug no_console_suspend
[ 0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.000000] Memory: 56856K/65536K available (4225K kernel code, 202K rwdata, 972K rodata, 2396K init, 102K bss, 8680K reserved, 0K cma-reserved)
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
[ 0.000000] vmalloc : 0xc4800000 - 0xff800000 ( 944 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xc4000000 ( 64 MB)
[ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB)
[ 0.000000] .text : 0xc0008000 - 0xc04289e8 (4227 kB)
[ 0.000000] .init : 0xc053f000 - 0xc0796000 (2396 kB)
[ 0.000000] .data : 0xc0796000 - 0xc07c8bec ( 203 kB)
[ 0.000000] .bss : 0xc07c8bec - 0xc07e25fc ( 103 kB)
[ 0.000000] Preemptible hierarchical RCU implementation.
[ 0.000000] Tasks RCU enabled.
[ 0.000000] NR_IRQS: 16, nr_irqs: 336, preallocated irqs: 336
[ 0.000000] RJK: parent_rate=13000000, xl=8, xn=1
[ 0.000069] sched_clock: 32 bits at 3250kHz, resolution 307ns, wraps every 660764198758ns
[ 0.000267] clocksource: oscr0: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 588080137591 ns
[ 0.002142] Console: colour dummy device 80x30
[ 0.002302] Calibrating delay loop... 103.83 BogoMIPS (lpj=519168)
[ 0.081019] pid_max: default: 32768 minimum: 301
[ 0.081860] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.081960] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.085178] CPU: Testing write buffer coherency: ok
[ 0.089002] Setting up static identity map for 0x80008200 - 0x80008260
[ 0.089962] Hierarchical SRCU implementation.
[ 0.102994] devtmpfs: initialized
[ 0.113882] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.114023] futex hash table entries: 256 (order: -1, 3072 bytes)
[ 0.116361] NET: Registered protocol family 16
[ 0.119175] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.389891] Advanced Linux Sound Architecture Driver Initialized.
[ 0.394261] clocksource: Switched to clocksource oscr0
[ 0.552465] NET: Registered protocol family 2
[ 0.559531] TCP established hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.559757] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.559938] TCP: Hash tables configured (established 1024 bind 1024)
[ 0.560478] UDP hash table entries: 256 (order: 0, 4096 bytes)
[ 0.560660] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[ 0.561794] NET: Registered protocol family 1
[ 0.563834] RPC: Registered named UNIX socket transport module.
[ 0.563934] RPC: Registered udp transport module.
[ 0.563988] RPC: Registered tcp transport module.
[ 0.564046] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 2.503938] Initialise system trusted keyrings
[ 2.506180] workingset: timestamp_bits=30 max_order=14 bucket_order=0
[ 2.510083] NFS: Registering the id_resolver key type
[ 2.510312] Key type id_resolver registered
[ 2.510374] Key type id_legacy registered
[ 2.516887] Key type asymmetric registered
[ 2.516991] Asymmetric key parser 'x509' registered
[ 2.517149] io scheduler noop registered
[ 2.517213] io scheduler deadline registered
[ 2.517601] io scheduler cfq registered (default)
[ 2.517671] io scheduler mq-deadline registered
[ 2.517732] io scheduler kyber registered
[ 2.577937] pxa-dma pxa-dma.0: initialized 32 channels on 100 requestors
[ 2.581363] pxa2xx-uart.0: ttyS0 at MMIO 0x40100000 (irq = 38, base_baud = 928571) is a UART1
[ 3.056921] console [ttyS0] enabled
[ 3.063284] pxa2xx-uart.1: ttyS1 at MMIO 0x40200000 (irq = 37, base_baud = 928571) is a UART2
[ 3.076187] pxa2xx-uart.2: ttyS2 at MMIO 0x40700000 (irq = 36, base_baud = 928571) is a UART3
[ 3.091759] nand: executing subop:
[ 3.097924] nand: ->CMD [0xff]
[ 3.101830] nand: ->WAITRDY [max 250 ms]
[ 3.106998] marvell-nfc pxa3xx-nand:
[ 3.106998] NDCR: 0x90079fff
[ 3.106998] NDCB0: 0x00a000ff
[ 3.106998] NDCB1: 0x00000000
[ 3.106998] NDCB2: 0x00000000
[ 3.106998] NDCB3: 0x00000000
[ 3.126261] nand: executing subop:
[ 3.129732] nand: ->CMD [0x90]
[ 3.133605] nand: ->ADDR [1 cyc: 00]
[ 3.138275] nand: ->DATA_IN [2 B, force 8-bit]
[ 3.143276] marvell-nfc pxa3xx-nand:
[ 3.143276] NDCR: 0x90079fff
[ 3.143276] NDCB0: 0x00610090
[ 3.143276] NDCB1: 0x00000000
[ 3.143276] NDCB2: 0x00000000
[ 3.143276] NDCB3: 0x00000000
[ 3.162111] nand: executing subop:
[ 3.165754] nand: ->CMD [0x90]
[ 3.169644] nand: ->ADDR [1 cyc: 00]
[ 3.173945] nand: ->DATA_IN [8 B, force 8-bit]
[ 3.179056] marvell-nfc pxa3xx-nand:
[ 3.179056] NDCR: 0x90079fff
[ 3.179056] NDCB0: 0x00610090
[ 3.179056] NDCB1: 0x00000000
[ 3.179056] NDCB2: 0x00000000
[ 3.179056] NDCB3: 0x00000000
[ 3.197729] nand: executing subop:
[ 3.201185] nand: ->CMD [0x90]
[ 3.205207] nand: ->ADDR [1 cyc: 20]
[ 3.209519] nand: ->DATA_IN [4 B, force 8-bit]
[ 3.214626] marvell-nfc pxa3xx-nand:
[ 3.214626] NDCR: 0x90079fff
[ 3.214626] NDCB0: 0x00610090
[ 3.214626] NDCB1: 0x00000020
[ 3.214626] NDCB2: 0x00000000
[ 3.214626] NDCB3: 0x00000000
[ 3.233249] nand: executing subop:
[ 3.236837] nand: ->CMD [0x90]
[ 3.240719] nand: ->ADDR [1 cyc: 40]
[ 3.245158] nand: ->DATA_IN [5 B, force 8-bit]
[ 3.250133] marvell-nfc pxa3xx-nand:
[ 3.250133] NDCR: 0x90079fff
[ 3.250133] NDCB0: 0x00610090
[ 3.250133] NDCB1: 0x00000040
[ 3.250133] NDCB2: 0x00000000
[ 3.250133] NDCB3: 0x00000000
[ 3.268756] nand: device found, Manufacturer ID: 0x20, Chip ID: 0xba
[ 3.275239] nand: ST Micro pxa3xx-nand
[ 3.279028] nand: bus width 8 instead of 16 bits
[ 3.283651] nand: No NAND device found
[ 3.287582] marvell-nfc pxa3xx-nand: could not identify the nand chip
[ 3.294466] marvell-nfc: probe of pxa3xx-nand failed with error -22
--
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 00/12] Marvell NAND controller rework with ->exec_op()
From: Boris Brezillon @ 2017-12-20 21:41 UTC (permalink / raw)
To: Robert Jarzmik
Cc: Miquel RAYNAL, David Woodhouse, Brian Norris, Marek Vasut,
Richard Weinberger, Cyrille Pitchen, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Russell King, Daniel Mack, Haojian Zhuang, Eric Miao,
Catalin Marinas, Will Deacon, Ezequiel Garcia <ezequi>
In-Reply-To: <87y3lxccr7.fsf-4ty26DBLk+jEm7gnYqmdkQ@public.gmane.org>
On Wed, 20 Dec 2017 22:26:04 +0100
Robert Jarzmik <robert.jarzmik-GANU6spQydw@public.gmane.org> wrote:
> Miquel RAYNAL <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> writes:
>
> > Hello Robert,
> >
> > On Mon, 18 Dec 2017 08:11:35 +0100
> > Robert Jarzmik <robert.jarzmik-GANU6spQydw@public.gmane.org> wrote:
> >
> >> Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> writes:
> >>
> >> >> Robert, it would be great if you could also do more testing on PXA
> >> >> and validate this driver. If needed, a branch ready to be tested is
> >> >> available at [3]. It is based on nand/next and has all the changes
> >> >> brought by the previously mentionned series as well as this one.
> >> >
> >> > Robert, do you think you'll have some time to test Miquel's branch
> >> > on your PXA boards? Miquel already tested on one of these boards
> >> > (CM-X300), but we'd like to have other testers. Also feel free to
> >> > review the driver if have the time.
> >> >
> >> > Thanks,
> >> >
> >> > Boris
> >>
> >> Hi Boris and Miquel,
> >>
> >> I have applied the whole serie to linux-next yesterday.
> >>
> >> A boot attempt on my zylonite with my old defconfig (with the new
> >> Marvell NAND config activated) yields to :
> >> - this message
> >> [ 3.136818] marvell-nfc pxa3xx-nand: could not identify the nand
> >> chip [ 3.143874] marvell-nfc: probe of pxa3xx-nand failed with
> >> error -22
> >> - then my board hangs
> >>
> >> Is there something to be done to improve the trace level so that you
> >> can guess what's happening ?
> >
> > Thank you very much for testing this.
> >
> > Could you please try this branch [1] instead of linux-next + the
> > patches?
> >
> > Also, can you please add #define DEBUG in marvell_nand.c + nand_base.c,
> > it should help us figuring out what is wrong.
>
> Done, same result, the dmesg is in [1].
Looks like there is a mismatch on the nand bus width detected by the
core and the one declared by the driver. Can you try with the following
diff applied?
Thanks,
Boris
--->8---
diff --git a/drivers/mtd/nand/marvell_nand.c b/drivers/mtd/nand/marvell_nand.c
index c618ccb22a61..ddd6a07888e2 100644
--- a/drivers/mtd/nand/marvell_nand.c
+++ b/drivers/mtd/nand/marvell_nand.c
@@ -2481,6 +2481,7 @@ static int marvell_nand_chip_init(struct device *dev, struct marvell_nfc *nfc,
*/
chip->ecc.mode = NAND_ECC_HW;
+ chip->options |= NAND_BUSWIDTH_AUTO;
ret = nand_scan_ident(mtd, marvell_nand->nsels, NULL);
if (ret) {
dev_err(dev, "could not identify the nand chip\n");
--
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] arm64: dts: stratix10: fix SPI settings
From: thor.thayer-VuQAYsv1563Yd54FQh9/CA @ 2017-12-20 21:44 UTC (permalink / raw)
To: dinguyen-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Thor Thayer
From: Thor Thayer <thor.thayer-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Correct the SPI Master node settings.
Signed-off-by: Thor Thayer <thor.thayer-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
---
arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
index 7c9bdc7ab50b..367bc00be802 100644
--- a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
+++ b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
@@ -248,7 +248,9 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0xffda4000 0x1000>;
- interrupts = <0 101 4>;
+ interrupts = <0 99 4>;
+ resets = <&rst SPIM0_RESET>;
+ reg-io-width = <4>;
num-chipselect = <4>;
bus-num = <0>;
status = "disabled";
@@ -259,7 +261,9 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0xffda5000 0x1000>;
- interrupts = <0 102 4>;
+ interrupts = <0 100 4>;
+ resets = <&rst SPIM1_RESET>;
+ reg-io-width = <4>;
num-chipselect = <4>;
bus-num = <0>;
status = "disabled";
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v2] ARM: dts: sunxi: Add sid for a83t
From: Rob Herring @ 2017-12-20 21:45 UTC (permalink / raw)
To: kevans91-OYTqUY/oFF8
Cc: Srinivas Kandagatla, Mark Rutland, Maxime Ripard, Chen-Yu Tsai,
Russell King, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20171219210523.10428-1-kevans91-OYTqUY/oFF8@public.gmane.org>
On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevans91-OYTqUY/oFF8@public.gmane.org wrote:
> Allwinner a83t has a 1 KB sid block with efuse for security rootkey and
> thermal calibration data, add node to describe it.
>
> a83t-sid is not currently supported by nvmem/sunxi-sid, but it is
> supported in an external driver for FreeBSD.
>
> Signed-off-by: Kyle Evans <kevans91-OYTqUY/oFF8@public.gmane.org>
> ---
>
> Changes in v2:
> - remove bogus "From:" line in commit text; no functional change
>
> Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt | 1 +
> arch/arm/boot/dts/sun8i-a83t.dtsi | 5 +++++
> 2 files changed, 6 insertions(+)
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 02/20] dt-bindings: gpio: Add ASPEED constants
From: Rob Herring @ 2017-12-20 21:46 UTC (permalink / raw)
To: Joel Stanley
Cc: Mark Rutland, Arnd Bergmann, Andrew Jeffery, Patrick Venture,
Xo Wang, Lei YU, Cédric Le Goater, Benjamin Herrenschmidt,
Jeremy Kerr, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-aspeed-uLR06cmDAlY/bJ5BZ2RsiQ
In-Reply-To: <20171220032328.30584-3-joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
On Wed, Dec 20, 2017 at 01:53:10PM +1030, Joel Stanley wrote:
> These are used to by the device tree to map pin numbers to constants
> required by the GPIO bindings.
>
> Signed-off-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
> --
> v3:
> - Remove dtsi includes from this patch, they will come later
> ---
> include/dt-bindings/gpio/aspeed-gpio.h | 49 ++++++++++++++++++++++++++++++++++
> 1 file changed, 49 insertions(+)
> create mode 100644 include/dt-bindings/gpio/aspeed-gpio.h
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: at24: new optional property - wp-gpios
From: Rob Herring @ 2017-12-20 21:48 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Andy Shevchenko, Mark Rutland, Linus Walleij, Peter Rosin,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171220082633.32237-2-brgl-ARrdPY/1zhM@public.gmane.org>
On Wed, Dec 20, 2017 at 09:26:32AM +0100, Bartosz Golaszewski wrote:
> AT24 EEPROMs have a write-protect pin, which - when pulled high -
> inhibits writes to the upper quadrant of memory (although it has been
> observed that on some chips it disables writing to the entire memory
> range).
>
> On some boards, this pin is connected to a GPIO and pulled high by
> default, which forces the user to manually change its state before
> writing. On linux this means that we either need to hog the line all
> the time, or set the GPIO value before writing from outside of the
> at24 driver.
>
> Add a new optional property to the device tree binding document, which
> allows to specify the GPIO line to which the write-protect pin is
> connected.
>
> Signed-off-by: Bartosz Golaszewski <brgl-ARrdPY/1zhM@public.gmane.org>
> ---
> Documentation/devicetree/bindings/eeprom/at24.txt | 3 +++
> 1 file changed, 3 insertions(+)
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v16 0/5] ZII RAVE platform driver
From: Philippe Ombredanne @ 2017-12-20 21:51 UTC (permalink / raw)
To: Andrey Smirnov
Cc: Lee Jones, Pavel Machek, Greg Kroah-Hartman,
cphealy-Re5JQEeQqe8AvxtiuMwx3w, Andy Shevchenko, Lucas Stach,
Nikita Yushchenko, Guenter Roeck, Rob Herring, Mark Rutland,
Johan Hovold,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, LKML,
Sebastian Reichel
In-Reply-To: <20171220204517.28313-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Andrey,
On Wed, Dec 20, 2017 at 9:45 PM, Andrey Smirnov
<andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Everyone:
>
> This patch series is v16 of the driver for supervisory processor found
> on RAVE series of devices from ZII. Supervisory processor is a PIC
> microcontroller connected to various electrical subsystems on RAVE
> devices whose firmware implements protocol to command/qery them.
>
> NOTE:
>
> * This driver dependends on crc_ccitt_false(), added by
> 2da9378d531f8cc6670c7497f20d936b706ab80b in 'linux-next', the patch
> was pulled in by Andrew Morton and is currently avaiting users, so
> this series might have to go in through Andrew's tree
>
> Changes since [v15]:
>
> - Adopted SPDX tags for licensing information per Philippe's
> request
Thank you for using the SPDX tags: you have my cheerful ack for the
SPDX tags for the whole patch set
There is one minor problem though: your comment style for the SPDX tag
lines. Check Thomas doc patches and Linus comments on this topic: you
should use // C++ style commnent in .c files and /* */ C-style
comments in .h files.
e.g. do not use this for a .c file:
> +++ b/drivers/watchdog/rave-sp-wdt.c
> @@ -0,0 +1,337 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
But this instead:
> +++ b/drivers/watchdog/rave-sp-wdt.c
> @@ -0,0 +1,337 @@
> +// SPDX-License-Identifier: GPL-2.0+
Acked-by: Philippe Ombredanne <pombredanne-kIH2VFuay/A@public.gmane.org>
--
Cordially
Philippe
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/2] media: coda: Add i.MX51 (CodaHx4) support
From: kbuild test robot @ 2017-12-20 21:52 UTC (permalink / raw)
Cc: kbuild-all-JC7UmRfGjtg, linux-media-u79uwXL29TY76Z2rM5mHXA,
Mauro Carvalho Chehab, Rob Herring, Mark Rutland, Fabio Estevam,
Chris Healy, devicetree-u79uwXL29TY76Z2rM5mHXA,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, Philipp Zabel
In-Reply-To: <20171218101629.31395-2-p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 6138 bytes --]
Hi Philipp,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.15-rc4 next-20171220]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Philipp-Zabel/media-dt-bindings-coda-Add-compatible-for-CodaHx4-on-i-MX51/20171221-050217
base: git://linuxtv.org/media_tree.git master
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
drivers/media/platform/coda/coda-bit.c: In function 'coda_setup_iram':
>> drivers/media/platform/coda/coda-bit.c:648:28: warning: 'me_bits' may be used uninitialized in this function [-Wmaybe-uninitialized]
iram_info->axi_sram_use |= me_bits;
^~
vim +/me_bits +648 drivers/media/platform/coda/coda-bit.c
588
589 static void coda_setup_iram(struct coda_ctx *ctx)
590 {
591 struct coda_iram_info *iram_info = &ctx->iram_info;
592 struct coda_dev *dev = ctx->dev;
593 int w64, w128;
594 int mb_width;
595 int dbk_bits;
596 int bit_bits;
597 int ip_bits;
598 int me_bits;
599
600 memset(iram_info, 0, sizeof(*iram_info));
601 iram_info->next_paddr = dev->iram.paddr;
602 iram_info->remaining = dev->iram.size;
603
604 if (!dev->iram.vaddr)
605 return;
606
607 switch (dev->devtype->product) {
608 case CODA_HX4:
609 dbk_bits = CODA7_USE_HOST_DBK_ENABLE;
610 bit_bits = CODA7_USE_HOST_BIT_ENABLE;
611 ip_bits = CODA7_USE_HOST_IP_ENABLE;
612 me_bits = CODA7_USE_HOST_ME_ENABLE;
613 break;
614 case CODA_7541:
615 dbk_bits = CODA7_USE_HOST_DBK_ENABLE | CODA7_USE_DBK_ENABLE;
616 bit_bits = CODA7_USE_HOST_BIT_ENABLE | CODA7_USE_BIT_ENABLE;
617 ip_bits = CODA7_USE_HOST_IP_ENABLE | CODA7_USE_IP_ENABLE;
618 me_bits = CODA7_USE_HOST_ME_ENABLE | CODA7_USE_ME_ENABLE;
619 break;
620 case CODA_960:
621 dbk_bits = CODA9_USE_HOST_DBK_ENABLE | CODA9_USE_DBK_ENABLE;
622 bit_bits = CODA9_USE_HOST_BIT_ENABLE | CODA7_USE_BIT_ENABLE;
623 ip_bits = CODA9_USE_HOST_IP_ENABLE | CODA7_USE_IP_ENABLE;
624 break;
625 default: /* CODA_DX6 */
626 return;
627 }
628
629 if (ctx->inst_type == CODA_INST_ENCODER) {
630 struct coda_q_data *q_data_src;
631
632 q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
633 mb_width = DIV_ROUND_UP(q_data_src->width, 16);
634 w128 = mb_width * 128;
635 w64 = mb_width * 64;
636
637 /* Prioritize in case IRAM is too small for everything */
638 if (dev->devtype->product == CODA_HX4 ||
639 dev->devtype->product == CODA_7541) {
640 iram_info->search_ram_size = round_up(mb_width * 16 *
641 36 + 2048, 1024);
642 iram_info->search_ram_paddr = coda_iram_alloc(iram_info,
643 iram_info->search_ram_size);
644 if (!iram_info->search_ram_paddr) {
645 pr_err("IRAM is smaller than the search ram size\n");
646 goto out;
647 }
> 648 iram_info->axi_sram_use |= me_bits;
649 }
650
651 /* Only H.264BP and H.263P3 are considered */
652 iram_info->buf_dbk_y_use = coda_iram_alloc(iram_info, w64);
653 iram_info->buf_dbk_c_use = coda_iram_alloc(iram_info, w64);
654 if (!iram_info->buf_dbk_c_use)
655 goto out;
656 iram_info->axi_sram_use |= dbk_bits;
657
658 iram_info->buf_bit_use = coda_iram_alloc(iram_info, w128);
659 if (!iram_info->buf_bit_use)
660 goto out;
661 iram_info->axi_sram_use |= bit_bits;
662
663 iram_info->buf_ip_ac_dc_use = coda_iram_alloc(iram_info, w128);
664 if (!iram_info->buf_ip_ac_dc_use)
665 goto out;
666 iram_info->axi_sram_use |= ip_bits;
667
668 /* OVL and BTP disabled for encoder */
669 } else if (ctx->inst_type == CODA_INST_DECODER) {
670 struct coda_q_data *q_data_dst;
671
672 q_data_dst = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE);
673 mb_width = DIV_ROUND_UP(q_data_dst->width, 16);
674 w128 = mb_width * 128;
675
676 iram_info->buf_dbk_y_use = coda_iram_alloc(iram_info, w128);
677 iram_info->buf_dbk_c_use = coda_iram_alloc(iram_info, w128);
678 if (!iram_info->buf_dbk_c_use)
679 goto out;
680 iram_info->axi_sram_use |= dbk_bits;
681
682 iram_info->buf_bit_use = coda_iram_alloc(iram_info, w128);
683 if (!iram_info->buf_bit_use)
684 goto out;
685 iram_info->axi_sram_use |= bit_bits;
686
687 iram_info->buf_ip_ac_dc_use = coda_iram_alloc(iram_info, w128);
688 if (!iram_info->buf_ip_ac_dc_use)
689 goto out;
690 iram_info->axi_sram_use |= ip_bits;
691
692 /* OVL and BTP unused as there is no VC1 support yet */
693 }
694
695 out:
696 if (!(iram_info->axi_sram_use & CODA7_USE_HOST_IP_ENABLE))
697 v4l2_dbg(1, coda_debug, &ctx->dev->v4l2_dev,
698 "IRAM smaller than needed\n");
699
700 if (dev->devtype->product == CODA_HX4 ||
701 dev->devtype->product == CODA_7541) {
702 /* TODO - Enabling these causes picture errors on CODA7541 */
703 if (ctx->inst_type == CODA_INST_DECODER) {
704 /* fw 1.4.50 */
705 iram_info->axi_sram_use &= ~(CODA7_USE_HOST_IP_ENABLE |
706 CODA7_USE_IP_ENABLE);
707 } else {
708 /* fw 13.4.29 */
709 iram_info->axi_sram_use &= ~(CODA7_USE_HOST_IP_ENABLE |
710 CODA7_USE_HOST_DBK_ENABLE |
711 CODA7_USE_IP_ENABLE |
712 CODA7_USE_DBK_ENABLE);
713 }
714 }
715 }
716
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 62395 bytes --]
^ permalink raw reply
* [PATCH 0/4] vf610-zii-dev updates
From: Russell King - ARM Linux @ 2017-12-20 23:11 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Sascha Hauer, Shawn Guo, Stefan Agner,
Andrew Lunn, Florian Fainelli, Linus Walleij
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Hi,
These patches update the DT for the ZII VF610 boards.
The first patch fixes complaints at boot about missing DMAs on rev C
boards, particularly for the SPI interface. This is because edma1 is
not enabled. This seems to be a regression from the 4.10 era.
The second patch fixes an interrupt storm during boot on rev B boards,
which causes boot to take 80+ seconds - this seems to be a long
standing issue since the DT description was first added. The PTB28
pin is definitely GPIO 98, and GPIO 98 is definitely part of the
gpio3 block, not the gpio2 block. Since GPIO 66 (which is the
corresponding GPIO in gpio2) is low, and the IRQ trigger is level-low,
this causes an interrupt storm.
The last two patches add an explicit description of the PHYs that are
actually connected to the switch - the 88e1545 is a quad PHY, and
without describing the MDIO bus, DSA assumes that any PHYs it can
discover are present for the switch. As only the first three PHYs
are connected, this leads the 4th port to believe it is connected to
the 4th PHY when the fixed-link definition is (eventually) removed.
Head this off by providing the proper descriptions, and as we have
them, also describe the interrupts for these PHYs.
Note, however, that the interrupt description is not quite correct -
the 88e1545 PHYs all share one interrupt line, and there is a register
in the PHY which can be used to demux the interrupt to the specific
PHY. However, in this description, we ignore the demux register, and
just share the interrupt between the PHYs. That much is fine, but
the pinmuxing becomes problematical - if we describe the same pinmux
settings for each PHY for the interrupt line, the 2nd/3rd PHYs fail.
This has no known solution. Suggestions welcome.
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 34 ++++++++++++++++++++++++++++++-
arch/arm/boot/dts/vf610-zii-dev.dtsi | 4 ++++
2 files changed, 37 insertions(+), 1 deletion(-)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
--
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 1/4] ARM: dts: vf610-zii-dev: enable edma1
From: Russell King @ 2017-12-20 23:11 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Sascha Hauer, Shawn Guo, Stefan Agner,
Andrew Lunn, Florian Fainelli, Linus Walleij
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171220231108.GJ10595-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
EDMA1 is required for the SPI controller used on the ZII boards to be
functional. Enable EDMA1.
Fixes: 14c416336820 ("ARM: dts: vfxxx: Enable DMA for DSPI on Vybrid")
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
arch/arm/boot/dts/vf610-zii-dev.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/vf610-zii-dev.dtsi b/arch/arm/boot/dts/vf610-zii-dev.dtsi
index 6b58d3a97992..aadd36db0092 100644
--- a/arch/arm/boot/dts/vf610-zii-dev.dtsi
+++ b/arch/arm/boot/dts/vf610-zii-dev.dtsi
@@ -96,6 +96,10 @@
status = "okay";
};
+&edma1 {
+ status = "okay";
+};
+
&esdhc1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_esdhc1>;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/4] ARM: dts: vf610-zii-dev-rev-b: fix interrupt for GPIO expander
From: Russell King @ 2017-12-20 23:11 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Sascha Hauer, Shawn Guo, Stefan Agner,
Andrew Lunn, Florian Fainelli, Linus Walleij
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171220231108.GJ10595-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
The interrupt specification for the GPIO expander is wrong - the
expander is wired to PTB28, which is GPIO98. GPIO98 is on gpio chip
3, not 2.
In addition, the device is missing a required property. Interrupt
controllers must have the "interrupt-controller" property specified.
Add this.
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
index acdf12ad0622..ede8649ba515 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
@@ -371,7 +371,8 @@
reg = <0x22>;
gpio-controller;
#gpio-cells = <2>;
- interrupt-parent = <&gpio2>;
+ interrupt-controller;
+ interrupt-parent = <&gpio3>;
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
};
};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 3/4] ARM: dts: vf610-zii-dev-rev-b: add PHYs for switch2
From: Russell King @ 2017-12-20 23:11 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Sascha Hauer, Shawn Guo, Stefan Agner,
Andrew Lunn, Florian Fainelli, Linus Walleij
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171220231108.GJ10595-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
Switch 2 has an 88e1545 PHY behind it, which is a quad PHY. Only the
first three PHYs are used, the remaining PHY is unused. When we wire
up the SFF sockets in a later commit, the omission of this causes the
fourth PHY to be used for port 3. Specifying the PHYs in DT avoids
the auto-probing of the bus, and discovery of this PHY.
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
index ede8649ba515..782b69a3acdf 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
@@ -255,16 +255,19 @@
port@0 {
reg = <0>;
label = "lan6";
+ phy-handle = <&switch2phy0>;
};
port@1 {
reg = <1>;
label = "lan7";
+ phy-handle = <&switch2phy1>;
};
port@2 {
reg = <2>;
label = "lan8";
+ phy-handle = <&switch2phy2>;
};
port@3 {
@@ -304,6 +307,20 @@
};
};
};
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch2phy0: phy@0 {
+ reg = <0>;
+ };
+ switch2phy1: phy@1 {
+ reg = <1>;
+ };
+ switch2phy2: phy@2 {
+ reg = <2>;
+ };
+ };
};
};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 4/4] ARM: dts: vf610-zii-dev-rev-b: add interrupts for 88e1545 PHY
From: Russell King @ 2017-12-20 23:12 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Sascha Hauer, Shawn Guo, Stefan Agner,
Andrew Lunn, Florian Fainelli, Linus Walleij
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171220231108.GJ10595-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
The 88e1545 PHY has its interrupts wired to the VF610, so we might as
well use them.
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
This is certainly not correct, as all PHYs on this device share the
same interrupt line, but we can't specify the pinmux settings
individually on each PHY. How should this be handled?
---
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
index 782b69a3acdf..d6786c5d0109 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
@@ -312,12 +312,20 @@
#size-cells = <0>;
switch2phy0: phy@0 {
+ interrupt-parent = <&gpio0>;
+ interrupts = <22 IRQ_TYPE_LEVEL_LOW>;
reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mv88e1545>;
};
switch2phy1: phy@1 {
+ interrupt-parent = <&gpio0>;
+ interrupts = <22 IRQ_TYPE_LEVEL_LOW>;
reg = <1>;
};
switch2phy2: phy@2 {
+ interrupt-parent = <&gpio0>;
+ interrupts = <22 IRQ_TYPE_LEVEL_LOW>;
reg = <2>;
};
};
@@ -488,6 +496,12 @@
>;
};
+ pinctrl_mv88e1545: pinctrl-mv88e1545 {
+ fsl,pins = <
+ VF610_PAD_PTB0__GPIO_22 0x219d
+ >;
+ };
+
pinctrl_pca9554_22: pinctrl-pca95540-22 {
fsl,pins = <
VF610_PAD_PTB28__GPIO_98 0x219d
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
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