* Re: [PATCH/RFC 0/5] arm64: dts: renesas: Break out common board support
From: Simon Horman @ 2017-04-28 7:04 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Geert Uytterhoeven, Magnus Damm, Kuninori Morimoto,
Yoshihiro Shimoda, Rob Herring, Mark Rutland, Linux-Renesas,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Vladimir Barinov
In-Reply-To: <CAMuHMdV1SQoeEACaNLZbByRLbosMj5oxEysNDVevYgxqStDaug-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Apr 27, 2017 at 03:32:49PM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Wed, Apr 26, 2017 at 10:11 AM, Geert Uytterhoeven
> <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
> > CC Vladimir (which I forgot to CC initially, sorry for that)
> >
> > On Wed, Apr 26, 2017 at 10:06 AM, Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
> >> On Fri, Apr 21, 2017 at 02:55:16PM +0200, Geert Uytterhoeven wrote:
> >>> The Renesas Salvator-X and ULCB development board can be equipped with
> >>> either an R-Car H3 or M3-W SiP, which are pin-compatible. All boards
> >>> use separate DTBs, but currently there's no sharing of board-specific
> >>> devices in DTS.
> >>>
> >>> This series reduces duplication by extracting common board support into
> >>> their own .dtsi files. As the level of support varies across boards and
> >>> SoCs, this requires the addition of a few external clocks and
> >>> placeholder devices on R-Car M3-W, so the common board support DTS can
> >>> refer to them.
> >>>
> >>> - Patches 1 and 2 add the external audio and PCIe bus clocks on R-Car
> >>> M3-W, which are present in r8a7795.dtsi, and used in
> >>> r8a7795-salvator-x.dts,
> >>> - RFC patch 3 adds placeholders for devices that are not yet supported
> >>> and/or tested on R-Car M3-W, but used on R-Car H3,
> >>> - RFC patch 4 extracts common Salvator-X board support,
> >>> - RFC patch 5 extracts common ULCB board support.
> >>>
> >>> For R-Car H3 based boards, there are no functional changes.
> >>> For R-Car M3-W based boards, some new devices are now described in DT.
> >>>
> >>> Dependencies:
> >>> - renesas-devel-20170420-v4.11-rc7,
> >>> - Patches 1 and 2 can be applied as-is,
> >>> - Patches 4 and 5 depend on "[PATCH 0/8] arm64: dts: renesas: Break
> >>> out R-Car H3 and M3-W SiP"
> >>> (http://www.spinics.net/lists/devicetree/msg173820.html).
> >>>
> >>> DTB changes have been inspected using scripts/dtc/dtx_diff.
> >>> This has been tested on Salvator-X (both H3 and M3-W).
> >>> This has not been tested on H3ULCB and M3ULCB due to lack of hardware.
> >>>
> >>> Thanks for your comments!
> >>
> >> Thanks for tackling this important problem. I have looked over the changes
> >> and they seem nice to me. I would, however, be more comfortable applying
> >> them if they were rested on the ULCB boards.
> >
> > tested?
> >
> > I've pushed a branch for testing to topic/rcar3-dtsi-sharing in
> > git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git.
>
> I managed to test it on the new H3ULCB and M3ULCB baords in Magnus' farm.
> No issues detected.
Great! Any objections to me queuing this 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
* Re: [PATCH/RFC 0/5] arm64: dts: renesas: Break out common board support
From: Geert Uytterhoeven @ 2017-04-28 7:11 UTC (permalink / raw)
To: Simon Horman
Cc: Geert Uytterhoeven, Magnus Damm, Kuninori Morimoto,
Yoshihiro Shimoda, Rob Herring, Mark Rutland, Linux-Renesas,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Vladimir Barinov
In-Reply-To: <20170428070458.GB10196@verge.net.au>
Hi SImon,
On Fri, Apr 28, 2017 at 9:04 AM, Simon Horman <horms@verge.net.au> wrote:
> On Thu, Apr 27, 2017 at 03:32:49PM +0200, Geert Uytterhoeven wrote:
>> On Wed, Apr 26, 2017 at 10:11 AM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>> > CC Vladimir (which I forgot to CC initially, sorry for that)
>> >
>> > On Wed, Apr 26, 2017 at 10:06 AM, Simon Horman <horms@verge.net.au> wrote:
>> >> On Fri, Apr 21, 2017 at 02:55:16PM +0200, Geert Uytterhoeven wrote:
>> >>> The Renesas Salvator-X and ULCB development board can be equipped with
>> >>> either an R-Car H3 or M3-W SiP, which are pin-compatible. All boards
>> >>> use separate DTBs, but currently there's no sharing of board-specific
>> >>> devices in DTS.
>> >>>
>> >>> This series reduces duplication by extracting common board support into
>> >>> their own .dtsi files. As the level of support varies across boards and
>> >>> SoCs, this requires the addition of a few external clocks and
>> >>> placeholder devices on R-Car M3-W, so the common board support DTS can
>> >>> refer to them.
>> >>>
>> >>> - Patches 1 and 2 add the external audio and PCIe bus clocks on R-Car
>> >>> M3-W, which are present in r8a7795.dtsi, and used in
>> >>> r8a7795-salvator-x.dts,
>> >>> - RFC patch 3 adds placeholders for devices that are not yet supported
>> >>> and/or tested on R-Car M3-W, but used on R-Car H3,
>> >>> - RFC patch 4 extracts common Salvator-X board support,
>> >>> - RFC patch 5 extracts common ULCB board support.
>> >>>
>> >>> For R-Car H3 based boards, there are no functional changes.
>> >>> For R-Car M3-W based boards, some new devices are now described in DT.
>> >>>
>> >>> Dependencies:
>> >>> - renesas-devel-20170420-v4.11-rc7,
>> >>> - Patches 1 and 2 can be applied as-is,
>> >>> - Patches 4 and 5 depend on "[PATCH 0/8] arm64: dts: renesas: Break
>> >>> out R-Car H3 and M3-W SiP"
>> >>> (http://www.spinics.net/lists/devicetree/msg173820.html).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> >>> DTB changes have been inspected using scripts/dtc/dtx_diff.
>> >>> This has been tested on Salvator-X (both H3 and M3-W).
>> >>> This has not been tested on H3ULCB and M3ULCB due to lack of hardware.
>> >>>
>> >>> Thanks for your comments!
>> >>
>> >> Thanks for tackling this important problem. I have looked over the changes
>> >> and they seem nice to me. I would, however, be more comfortable applying
>> >> them if they were rested on the ULCB boards.
>> >
>> > tested?
>> >
>> > I've pushed a branch for testing to topic/rcar3-dtsi-sharing in
>> > git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git.
>>
>> I managed to test it on the new H3ULCB and M3ULCB baords in Magnus' farm.
>> No issues detected.
>
> Great! Any objections to me queuing this up?
The dependency above (no feedback about the SiP types yet).
I can respin without that dependency, if that is preferred...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group
From: Geert Uytterhoeven @ 2017-04-28 7:18 UTC (permalink / raw)
To: Chris Brandt
Cc: Jacopo Mondi, Linus Walleij, Geert Uytterhoeven, Laurent Pinchart,
Rob Herring, Mark Rutland, Russell King, Linux-Renesas,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <SG2PR06MB1165D46E83254B1757C790498A100@SG2PR06MB1165.apcprd06.prod.outlook.com>
Hi Chris,
On Thu, Apr 27, 2017 at 12:48 PM, Chris Brandt <Chris.Brandt@renesas.com> wrote:
> On Thursday, April 27, 2017, Geert Uytterhoeven wrote:
>> > +ðer {
>> > + pinctrl-names = "default";
>> > + pinctrl-0 = <ðer_pins>;
>> > +
>> > + status = "okay";
>> > +
>> > + renesas,no-ether-link;
>> > + phy-handle = <&phy0>;
>> > + phy0: ethernet-phy@0 {
>> > + reg = <0>;
>>
>> Shouldn't the interrupt (connected to P1_15) be described?
>
> That interrupt pin from the PHY is not used. It did not need to be connected.
But it is connected, according to the schematics.
DT describes hardware, not software limitations.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* RE: [PATCH] arm64: dts: freescale: ls2081ardb: Add DTS support for NXP LS2081ARDB
From: Priyanka Jain @ 2017-04-28 7:20 UTC (permalink / raw)
To: Yang Li
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Mark Rutland, Shawn Guo,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Leo Li
In-Reply-To: <CADRPPNRM9Orc=RtRJstA-qpCcdCvrgab0n3d=CC7i6O7ua8nNg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 7895 bytes --]
> -----Original Message-----
> From: Yang Li [mailto:pku.leo@gmail.com]
> Sent: Monday, April 24, 2017 10:51 PM
> To: Priyanka Jain <priyanka.jain@nxp.com>
> Cc: devicetree@vger.kernel.org; Rob Herring <robh@kernel.org>; Mark Rutland
> <mark.rutland@arm.com>; Shawn Guo <shawnguo@kernel.org>; linux-arm-
> kernel@lists.infradead.org; Leo Li <leoyang.li@nxp.com>
> Subject: Re: [PATCH] arm64: dts: freescale: ls2081ardb: Add DTS support for NXP
> LS2081ARDB
>
> We probably should rename the freescale folder to nxp with a separate patch,
> but it is better to stop using the name in the patch title right now.
>
OK, I will correct this
> On Wed, Apr 19, 2017 at 11:37 PM, Priyanka Jain <priyanka.jain@nxp.com>
> wrote:
> > This patch add support for NXP LS2081ARDB board which has LS2081A SoC.
> >
> > LS2081A SoC is 40-pin derivative of LS2088A SoC So, from functional
> > perspective both are same.
> > Hence,ls2088a SoC dtsi files are included from ls2081ARDB dts
> >
> > Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
> > ---
> > arch/arm64/boot/dts/freescale/Makefile | 1 +
> > arch/arm64/boot/dts/freescale/fsl-ls2081a-rdb.dts | 139
> > +++++++++++++++++++++
> > 2 files changed, 140 insertions(+), 0 deletions(-) create mode
> > 100755 arch/arm64/boot/dts/freescale/fsl-ls2081a-rdb.dts
> >
> > diff --git a/arch/arm64/boot/dts/freescale/Makefile
> > b/arch/arm64/boot/dts/freescale/Makefile
> > index 72c4b52..58b80de 100644
> > --- a/arch/arm64/boot/dts/freescale/Makefile
> > +++ b/arch/arm64/boot/dts/freescale/Makefile
> > @@ -9,6 +9,7 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1088a-qds.dtb
> > dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1088a-rdb.dtb
> > dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-qds.dtb
> > dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-rdb.dtb
> > +dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2081a-rdb.dtb
> > dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-simu.dtb
> > dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2088a-qds.dtb
> > dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2088a-rdb.dtb diff --git
> > a/arch/arm64/boot/dts/freescale/fsl-ls2081a-rdb.dts
> > b/arch/arm64/boot/dts/freescale/fsl-ls2081a-rdb.dts
> > new file mode 100444
> > index 0000000..7ae408e
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls2081a-rdb.dts
> > @@ -0,0 +1,139 @@
> > +/*
> > + * Device Tree file for NXP LS2081A RDB Board.
> > + *
> > + * Copyright (C) 2017, NXP Semiconductors
>
> The formal copyright claim formal should be Copyright 2017 NXP
>
OK, I will correct this
Priyanka
> > + *
> > + * Priyanka Jain <priyanka.jain@nxp.com>
> > + *
> > + * This file is dual-licensed: you can use it either under the terms
> > + * of the GPLv2 or the X11 license, at your option. Note that this
> > + dual
> > + * licensing only applies to this file, and not this project as a
> > + * whole.
> > + *
> > + * a) This library 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.
> > + *
> > + * This library is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + *
> > + * Or, alternatively,
> > + *
> > + * b) Permission is hereby granted, free of charge, to any person
> > + * obtaining a copy of this software and associated documentation
> > + * files (the "Software"), to deal in the Software without
> > + * restriction, including without limitation the rights to use,
> > + * copy, modify, merge, publish, distribute, sublicense, and/or
> > + * sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following
> > + * conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be
> > + * included in all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
> KIND,
> > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
> WARRANTIES
> > + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
> COPYRIGHT
> > + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> > + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE
> OR
> > + * OTHER DEALINGS IN THE SOFTWARE.
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include "fsl-ls2088a.dtsi"
> > +
> > +/ {
> > + model = "NXP Layerscape 2081A RDB Board";
> > + compatible = "fsl,ls2081a-rdb", "fsl,ls2081a";
> > +
> > + aliases {
> > + serial0 = &serial0;
> > + serial1 = &serial1;
> > + };
> > +
> > + chosen {
> > + stdout-path = "serial1:115200n8";
> > + };
> > +};
> > +
> > +&esdhc {
> > + status = "okay";
> > +};
> > +
> > +&ifc {
> > + status = "disabled";
> > +};
> > +
> > +&i2c0 {
> > + status = "okay";
> > + pca9547@75 {
> > + compatible = "nxp,pca9547";
> > + reg = <0x75>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + i2c@1 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0x01>;
> > + rtc@51 {
> > + compatible = "nxp,pcf2129";
> > + reg = <0x51>;
> > + };
> > + };
> > +
> > + i2c@3 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0x3>;
> > +
> > + adt7481@4c {
> > + compatible = "adi,adt7461";
> > + reg = <0x4c>;
> > + };
> > + };
> > + };
> > +};
> > +
> > +&dspi {
> > + status = "okay";
> > + dflash0: n25q512a {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "st,m25p80";
> > + spi-max-frequency = <3000000>;
> > + reg = <0>;
> > + };
> > +};
> > +
> > +
> > +&qspi {
> > + status = "okay";
> > + flash0: n25q512a@0 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "st,m25p80";
> > + spi-max-frequency = <20000000>;
> > + reg = <0>;
> > + };
> > + flash1: n25q512a@1 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "st,m25p80";
> > + spi-max-frequency = <20000000>;
> > + reg = <0>;
> > + };
> > +};
> > +
> > +&usb0 {
> > + status = "okay";
> > +};
> > +
> > +&usb1 {
> > + status = "okay";
> > +};
> > --
> > 1.7.4.1
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree"
> > in the body of a message to majordomo@vger.kernel.org More majordomo
> > info at http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> - Leo
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·zøœzÚÞz)í…æèw*\x1fjg¬±¨\x1e¶‰šŽŠÝ¢j.ïÛ°\½½MŽúgjÌæa×\x02››–' ™©Þ¢¸\f¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾\a«‘êçzZ+ƒùšŽŠÝ¢j"ú!¶i
^ permalink raw reply
* Re: [PATCH] ARM: dts: r7s72100: add usb clocks to device tree
From: Simon Horman @ 2017-04-28 7:24 UTC (permalink / raw)
To: Chris Brandt
Cc: Geert Uytterhoeven, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170427191045.21199-1-chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
On Thu, Apr 27, 2017 at 12:10:45PM -0700, Chris Brandt wrote:
> This adds the USB0 and USB1 clocks to the device tree.
>
> Signed-off-by: Chris Brandt <chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
> ---
> arch/arm/boot/dts/r7s72100.dtsi | 6 +++---
> include/dt-bindings/clock/r7s72100-clock.h | 2 ++
> 2 files changed, 5 insertions(+), 3 deletions(-)
Hi Chris,
could you break the .h patch out into a separate patch so that I can apply
it to my dt-bindings branch? The reason for that branch is to allow better
management of dependencies; something I got burnt by a few releases back.
>
> diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
> index fb54cb5d3fad..4ed12a4d9d51 100644
> --- a/arch/arm/boot/dts/r7s72100.dtsi
> +++ b/arch/arm/boot/dts/r7s72100.dtsi
> @@ -144,9 +144,9 @@
> #clock-cells = <1>;
> compatible = "renesas,r7s72100-mstp-clocks", "renesas,cpg-mstp-clocks";
> reg = <0xfcfe0430 4>;
> - clocks = <&b_clk>;
> - clock-indices = <R7S72100_CLK_ETHER>;
> - clock-output-names = "ether";
> + clocks = <&b_clk>, <&p1_clk>, <&p1_clk>;
> + clock-indices = <R7S72100_CLK_ETHER R7S72100_CLK_USB0 R7S72100_CLK_USB1>;
> + clock-output-names = "ether", "usb0", "usb1";
The above looks fine to me although I was unable to find the USB parent
clock in the documentation I have available.
> };
>
> mstp8_clks: mstp8_clks@fcfe0434 {
> diff --git a/include/dt-bindings/clock/r7s72100-clock.h b/include/dt-bindings/clock/r7s72100-clock.h
> index bc256d31099a..dcd2072151fc 100644
> --- a/include/dt-bindings/clock/r7s72100-clock.h
> +++ b/include/dt-bindings/clock/r7s72100-clock.h
> @@ -34,6 +34,8 @@
>
> /* MSTP7 */
> #define R7S72100_CLK_ETHER 4
> +#define R7S72100_CLK_USB0 1
> +#define R7S72100_CLK_USB1 0
>
> /* MSTP8 */
> #define R7S72100_CLK_MMCIF 4
The above also looks fine to me.
--
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 00/10] Renesas RZ/A1 pin and gpio controller
From: jmondi @ 2017-04-28 7:24 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Jacopo Mondi, Linus Walleij, Geert Uytterhoeven, Laurent Pinchart,
Chris Brandt, Rob Herring, Mark Rutland, Russell King,
Linux-Renesas, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <CAMuHMdWw1JpFLT0QY4yQK6VH0oSeQOHUWMuKFSj6b6vrhHPCdA@mail.gmail.com>
Hi Geert, Simon,
On Thu, Apr 27, 2017 at 10:42:02AM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi
> <jacopo+renesas@jmondi.org> wrote:
> > this is 5th round of gpio/pincontroller for RZ/A1 devices.
> >
> > I have updated the pin controller driver to use the newly introduced
> > "pinctrl_enable()" function.
> > This is required since v4.11-rc7 as otherwise, as reported by Chris Brandt,
> > the pin controller does not start.
> >
> > I have incorporated your comments on the device tree bindings documentation,
> > and added to pinctrl-generic.h header file two macros to unpack generic
> > properties and their arguments.
> >
> > Tested with SCIF, RIIC, ETHER and gpio-leds on Genmai board.
>
> Thanks for the update!
>
> > Jacopo Mondi (10):
> > pinctrl: generic: Add bi-directional and output-enable
>
> Already applied by LinusW.
>
> > pinctrl: generic: Add macros to unpack properties
>
> LinusW: do you want me to queue this together with the driver for v4.13,
> or will you take this single patch for v4.12?
>
> > pinctrl: Renesas RZ/A1 pin and gpio controller
> > dt-bindings: pinctrl: Add RZ/A1 bindings doc
>
> Will queue in sh-pfc-for-v4.13.
>
> > arm: dts: dt-bindings: Add Renesas RZ/A1 pinctrl header
> > arm: dts: r7s72100: Add pin controller node
> > arm: dts: genmai: Add SCIF2 pin group
> > arm: dts: genmai: Add RIIC2 pin group
> > arm: dts: genmai: Add user led device nodes
> > arm: dts: genmai: Add ethernet pin group
>
> These are for Simon.
>
> Does applying the DTS changes before the driver introduce regressions?
> If no, Simon can queue them for v4.13.
> If yes, they'll have to wait for v4.14.
>
I tried reverting patch [03/10] which introduces the driver, and I
lose serial output on Genmai. So I guess the dts patches have to be
taken after the driver has been merged.
One question: why can't they be taken at the same time? (eg. for
v4.13?)
Thanks
j
> Thanks!
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v5 00/10] Renesas RZ/A1 pin and gpio controller
From: Geert Uytterhoeven @ 2017-04-28 7:30 UTC (permalink / raw)
To: jmondi
Cc: Jacopo Mondi, Linus Walleij, Geert Uytterhoeven, Laurent Pinchart,
Chris Brandt, Rob Herring, Mark Rutland, Russell King,
Linux-Renesas, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20170428072457.GA4911@w540>
Hi Jacopo,
On Fri, Apr 28, 2017 at 9:24 AM, jmondi <jacopo@jmondi.org> wrote:
> On Thu, Apr 27, 2017 at 10:42:02AM +0200, Geert Uytterhoeven wrote:
>> On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi
>> <jacopo+renesas@jmondi.org> wrote:
>> > this is 5th round of gpio/pincontroller for RZ/A1 devices.
>> >
>> > I have updated the pin controller driver to use the newly introduced
>> > "pinctrl_enable()" function.
>> > This is required since v4.11-rc7 as otherwise, as reported by Chris Brandt,
>> > the pin controller does not start.
>> >
>> > I have incorporated your comments on the device tree bindings documentation,
>> > and added to pinctrl-generic.h header file two macros to unpack generic
>> > properties and their arguments.
>> >
>> > Tested with SCIF, RIIC, ETHER and gpio-leds on Genmai board.
>>
>> Thanks for the update!
>>
>> > Jacopo Mondi (10):
>> > pinctrl: generic: Add bi-directional and output-enable
>>
>> Already applied by LinusW.
>>
>> > pinctrl: generic: Add macros to unpack properties
>>
>> LinusW: do you want me to queue this together with the driver for v4.13,
>> or will you take this single patch for v4.12?
>>
>> > pinctrl: Renesas RZ/A1 pin and gpio controller
>> > dt-bindings: pinctrl: Add RZ/A1 bindings doc
>>
>> Will queue in sh-pfc-for-v4.13.
>>
>> > arm: dts: dt-bindings: Add Renesas RZ/A1 pinctrl header
>> > arm: dts: r7s72100: Add pin controller node
>> > arm: dts: genmai: Add SCIF2 pin group
>> > arm: dts: genmai: Add RIIC2 pin group
>> > arm: dts: genmai: Add user led device nodes
>> > arm: dts: genmai: Add ethernet pin group
>>
>> These are for Simon.
>>
>> Does applying the DTS changes before the driver introduce regressions?
>> If no, Simon can queue them for v4.13.
>> If yes, they'll have to wait for v4.14.
>>
>
> I tried reverting patch [03/10] which introduces the driver, and I
> lose serial output on Genmai. So I guess the dts patches have to be
> taken after the driver has been merged.
>
> One question: why can't they be taken at the same time? (eg. for
> v4.13?)
Because the driver goes in through me and LinusW, while the DTS goes in
through Simon and arm-soc.
If Simon applies the DTS patches, it will regress genmai in renesas-devel
until the release of v4.13-rc1.
An immutable branch would solve that, but for adding PFC we usuable just
postpone the DT part by one cycle.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v5 00/10] Renesas RZ/A1 pin and gpio controller
From: Simon Horman @ 2017-04-28 7:31 UTC (permalink / raw)
To: jmondi
Cc: Geert Uytterhoeven, Jacopo Mondi, Linus Walleij,
Geert Uytterhoeven, Laurent Pinchart, Chris Brandt, Rob Herring,
Mark Rutland, Russell King, Linux-Renesas,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20170428072457.GA4911@w540>
On Fri, Apr 28, 2017 at 09:24:57AM +0200, jmondi wrote:
> Hi Geert, Simon,
>
> On Thu, Apr 27, 2017 at 10:42:02AM +0200, Geert Uytterhoeven wrote:
> > Hi Jacopo,
> >
> > On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi
> > <jacopo+renesas@jmondi.org> wrote:
> > > this is 5th round of gpio/pincontroller for RZ/A1 devices.
> > >
> > > I have updated the pin controller driver to use the newly introduced
> > > "pinctrl_enable()" function.
> > > This is required since v4.11-rc7 as otherwise, as reported by Chris Brandt,
> > > the pin controller does not start.
> > >
> > > I have incorporated your comments on the device tree bindings documentation,
> > > and added to pinctrl-generic.h header file two macros to unpack generic
> > > properties and their arguments.
> > >
> > > Tested with SCIF, RIIC, ETHER and gpio-leds on Genmai board.
> >
> > Thanks for the update!
> >
> > > Jacopo Mondi (10):
> > > pinctrl: generic: Add bi-directional and output-enable
> >
> > Already applied by LinusW.
> >
> > > pinctrl: generic: Add macros to unpack properties
> >
> > LinusW: do you want me to queue this together with the driver for v4.13,
> > or will you take this single patch for v4.12?
> >
> > > pinctrl: Renesas RZ/A1 pin and gpio controller
> > > dt-bindings: pinctrl: Add RZ/A1 bindings doc
> >
> > Will queue in sh-pfc-for-v4.13.
> >
> > > arm: dts: dt-bindings: Add Renesas RZ/A1 pinctrl header
> > > arm: dts: r7s72100: Add pin controller node
> > > arm: dts: genmai: Add SCIF2 pin group
> > > arm: dts: genmai: Add RIIC2 pin group
> > > arm: dts: genmai: Add user led device nodes
> > > arm: dts: genmai: Add ethernet pin group
> >
> > These are for Simon.
> >
> > Does applying the DTS changes before the driver introduce regressions?
> > If no, Simon can queue them for v4.13.
> > If yes, they'll have to wait for v4.14.
> >
>
> I tried reverting patch [03/10] which introduces the driver, and I
> lose serial output on Genmai. So I guess the dts patches have to be
> taken after the driver has been merged.
>
> One question: why can't they be taken at the same time? (eg. for
> v4.13?)
The problem is that the changes go through different trees. It may,
however, be possible to arrange for both sets of changes to go into v4.13
by negotiating with the ARM-SoC maintainers.
^ permalink raw reply
* Re: [PATCH/RFC 0/5] arm64: dts: renesas: Break out common board support
From: Simon Horman @ 2017-04-28 7:32 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Geert Uytterhoeven, Magnus Damm, Kuninori Morimoto,
Yoshihiro Shimoda, Rob Herring, Mark Rutland, Linux-Renesas,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Vladimir Barinov
In-Reply-To: <CAMuHMdVypXM59rk50Guc90ktD2PKHsVHgXyN34Cz3EC1hMTs8g@mail.gmail.com>
On Fri, Apr 28, 2017 at 09:11:36AM +0200, Geert Uytterhoeven wrote:
> Hi SImon,
>
> On Fri, Apr 28, 2017 at 9:04 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Thu, Apr 27, 2017 at 03:32:49PM +0200, Geert Uytterhoeven wrote:
> >> On Wed, Apr 26, 2017 at 10:11 AM, Geert Uytterhoeven
> >> <geert@linux-m68k.org> wrote:
> >> > CC Vladimir (which I forgot to CC initially, sorry for that)
> >> >
> >> > On Wed, Apr 26, 2017 at 10:06 AM, Simon Horman <horms@verge.net.au> wrote:
> >> >> On Fri, Apr 21, 2017 at 02:55:16PM +0200, Geert Uytterhoeven wrote:
> >> >>> The Renesas Salvator-X and ULCB development board can be equipped with
> >> >>> either an R-Car H3 or M3-W SiP, which are pin-compatible. All boards
> >> >>> use separate DTBs, but currently there's no sharing of board-specific
> >> >>> devices in DTS.
> >> >>>
> >> >>> This series reduces duplication by extracting common board support into
> >> >>> their own .dtsi files. As the level of support varies across boards and
> >> >>> SoCs, this requires the addition of a few external clocks and
> >> >>> placeholder devices on R-Car M3-W, so the common board support DTS can
> >> >>> refer to them.
> >> >>>
> >> >>> - Patches 1 and 2 add the external audio and PCIe bus clocks on R-Car
> >> >>> M3-W, which are present in r8a7795.dtsi, and used in
> >> >>> r8a7795-salvator-x.dts,
> >> >>> - RFC patch 3 adds placeholders for devices that are not yet supported
> >> >>> and/or tested on R-Car M3-W, but used on R-Car H3,
> >> >>> - RFC patch 4 extracts common Salvator-X board support,
> >> >>> - RFC patch 5 extracts common ULCB board support.
> >> >>>
> >> >>> For R-Car H3 based boards, there are no functional changes.
> >> >>> For R-Car M3-W based boards, some new devices are now described in DT.
> >> >>>
> >> >>> Dependencies:
> >> >>> - renesas-devel-20170420-v4.11-rc7,
> >> >>> - Patches 1 and 2 can be applied as-is,
> >> >>> - Patches 4 and 5 depend on "[PATCH 0/8] arm64: dts: renesas: Break
> >> >>> out R-Car H3 and M3-W SiP"
> >> >>> (http://www.spinics.net/lists/devicetree/msg173820.html).
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> >> >>> DTB changes have been inspected using scripts/dtc/dtx_diff.
> >> >>> This has been tested on Salvator-X (both H3 and M3-W).
> >> >>> This has not been tested on H3ULCB and M3ULCB due to lack of hardware.
> >> >>>
> >> >>> Thanks for your comments!
> >> >>
> >> >> Thanks for tackling this important problem. I have looked over the changes
> >> >> and they seem nice to me. I would, however, be more comfortable applying
> >> >> them if they were rested on the ULCB boards.
> >> >
> >> > tested?
> >> >
> >> > I've pushed a branch for testing to topic/rcar3-dtsi-sharing in
> >> > git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git.
> >>
> >> I managed to test it on the new H3ULCB and M3ULCB baords in Magnus' farm.
> >> No issues detected.
> >
> > Great! Any objections to me queuing this up?
>
> The dependency above (no feedback about the SiP types yet).
>
> I can respin without that dependency, if that is preferred...
It seems to me that it would be nice to get these in sooner than later - in
particular earlier rather than later in the (v4.13) development cycle. But
I defer to your judgement on what is best.
^ permalink raw reply
* Re: [PATCH] ARM: dts: r7s72100: add usb clocks to device tree
From: Geert Uytterhoeven @ 2017-04-28 7:34 UTC (permalink / raw)
To: Chris Brandt
Cc: Simon Horman, Rob Herring, Mark Rutland,
devicetree@vger.kernel.org, Linux-Renesas
In-Reply-To: <20170427191045.21199-1-chris.brandt@renesas.com>
On Thu, Apr 27, 2017 at 9:10 PM, Chris Brandt <chris.brandt@renesas.com> wrote:
> This adds the USB0 and USB1 clocks to the device tree.
>
> Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Simon: see Section 29.3.2 (BUSWAIT) for the reference to the P1 clock.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 10/18] pinctrl: madera: Add driver for Cirrus Logic Madera codecs
From: Linus Walleij @ 2017-04-28 7:39 UTC (permalink / raw)
To: Richard Fitzgerald
Cc: Alexandre Courbot, alsa-devel@alsa-project.org, Jason Cooper,
devicetree@vger.kernel.org,
open list:WOLFSON MICROELECTRONICS DRIVERS,
linux-kernel@vger.kernel.org, Rob Herring,
linux-gpio@vger.kernel.org, Mark Brown, Thomas Gleixner,
Lee Jones
In-Reply-To: <1493050124-5970-11-git-send-email-rf@opensource.wolfsonmicro.com>
On Mon, Apr 24, 2017 at 6:08 PM, Richard Fitzgerald
<rf@opensource.wolfsonmicro.com> wrote:
> These codecs have a variable number of I/O lines each of which
> is individually selectable to a wide range of possible functions.
>
> The functionality is slightly different from the traditional muxed
> GPIO since most of the functions can be mapped to any pin (and even
> the same function to multiple pins). Most pins have a dedicated
> "alternate" function that is only available on that pin. The
> alternate functions are usually a group of signals, though it is
> not always necessary to enable the full group, depending on the
> alternate function and how it is to be used. The mapping between
> alternate functions and GPIO pins varies between codecs depending
> on the number of alternate functions and available pins.
>
> Note on the Kconfig options:
> The formula "default y if..." is used for PINCTRL_MADERA so that its
> select options will be processed, allowing us to group selects for
> pinctrl into the pinctrl Kconfig where they logically belong instead
> of accumulating under the parent MFD Kconfig.
>
> Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
> ---
> Changes since V1:
> - dt binding moved to separate patch
> - moved all source into a subdirectory drivers/pinctrl/cirrus
> - split chip-specific tables into separate files
> - codec-specific build options are now selected from MFD
> - print useful information from madera_pin_dbg_show()
> - added gpio_set_direciton / gpio_request_enable / gpio_disable_free functions
> - added strict mode so GPIO and other functions are exclusive
> - replace #ifdefs with if (IS_ENABLED(...)) in probe
> - fixed bug reading registers in madera_pin_conf_get()
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
I guess you will apply this through MFD, so waiting for Lee to
pick it up. Alternatively I can apply it after the MFD core parts
are upstream.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 12/18] gpio: madera: Support Cirrus Logic Madera class codecs
From: Linus Walleij @ 2017-04-28 7:44 UTC (permalink / raw)
To: Richard Fitzgerald
Cc: Alexandre Courbot, alsa-devel@alsa-project.org, Jason Cooper,
devicetree@vger.kernel.org,
open list:WOLFSON MICROELECTRONICS DRIVERS,
linux-kernel@vger.kernel.org, Rob Herring,
linux-gpio@vger.kernel.org, Mark Brown, Thomas Gleixner,
Lee Jones
In-Reply-To: <1493050124-5970-13-git-send-email-rf@opensource.wolfsonmicro.com>
On Mon, Apr 24, 2017 at 6:08 PM, Richard Fitzgerald
<rf@opensource.wolfsonmicro.com> wrote:
> This adds support for the GPIOs on Cirrus Logic Madera class codecs.
> Any pins not used for special functions (see the pinctrl driver) can be
> used as general single-bit input or output lines. The number of available
> GPIOs varies between codecs.
>
> Signed-off-by: Nariman Poushin <nariman@opensource.wolfsonmicro.com>
> Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
> Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
> ---
> Changes from V1:
> - dt bindings moved to a separate patch
> - dependent on pinctrl driver instead of parent MFD
> - added get_direction function
> - added .request / .free / .set_config to work with pinctrl driver
> - register range with pinctrl driver
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 12/18] gpio: madera: Support Cirrus Logic Madera class codecs
From: Linus Walleij @ 2017-04-28 7:46 UTC (permalink / raw)
To: Richard Fitzgerald
Cc: Alexandre Courbot, alsa-devel@alsa-project.org, Jason Cooper,
devicetree@vger.kernel.org,
open list:WOLFSON MICROELECTRONICS DRIVERS,
linux-kernel@vger.kernel.org, Rob Herring,
linux-gpio@vger.kernel.org, Mark Brown, Thomas Gleixner,
Lee Jones
In-Reply-To: <1493131461.4826.66.camel@rf-debian.wolfsonmicro.main>
On Tue, Apr 25, 2017 at 4:44 PM, Richard Fitzgerald
<rf@opensource.wolfsonmicro.com> wrote:
> On Tue, 2017-04-25 at 16:13 +0200, Linus Walleij wrote:
>> On Mon, Apr 24, 2017 at 6:08 PM, Richard Fitzgerald
>> <rf@opensource.wolfsonmicro.com> wrote:
>>
>> > This adds support for the GPIOs on Cirrus Logic Madera class codecs.
>> > Any pins not used for special functions (see the pinctrl driver) can be
>> > used as general single-bit input or output lines. The number of available
>> > GPIOs varies between codecs.
>> >
>> > Signed-off-by: Nariman Poushin <nariman@opensource.wolfsonmicro.com>
>> > Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
>> > Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
>> > ---
>> > Changes from V1:
>> > - dt bindings moved to a separate patch
>> > - dependent on pinctrl driver instead of parent MFD
>> > - added get_direction function
>> > - added .request / .free / .set_config to work with pinctrl driver
>> > - register range with pinctrl driver
>>
>> Nice, but...
>>
>> > + ret = gpiochip_add_pin_range(&madera_gpio->gpio_chip, "madera-pinctrl",
>> > + 0, 0, madera_gpio->gpio_chip.ngpio);
>> > + if (ret) {
>> > + dev_warn(&pdev->dev, "Failed to add pin range (%d)\n", ret);
>> > + return ret;
>> > + }
>>
>> This is all fine, but we have generic code for adding ranges from
>> the device tree, see
>> Documentation/devicetree/bindings/gpio/gpio.txt
>>
>
> The range of gpio pins is a fixed property of the chip, and so is the
> combination of gpio+pinctrl drivers.
Well so is the IRQ number, but we still put that in the device tree.
> I think the general principle of the DT maintainers is that DT should be
> used for things that the drivers don't already know and can't figure
> out.
It's a grayzone. People use ranges in the device tree for example when
there are several instances of the same GPIO block with different
ranges into a single pin controller and then it makes sense.
But in this case you have your separate chip with one instance so
it doesn't make sense, keep it like this.
Also it is necessary to proble from boardfiles as you explained in the
pinctrl patch.
Good job, it's a nice driver. Also the pinctrl driver is very nice.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 01/30] pinctrl: mediatek: Add missing pinctrl bindings for mt7623
From: Linus Walleij @ 2017-04-28 7:55 UTC (permalink / raw)
To: sean.wang
Cc: Rob Herring, Matthias Brugger, John Crispin, Mark Rutland,
Russell King, devicetree@vger.kernel.org,
moderated list:ARM/Mediatek SoC support,
linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1493198774-4478-2-git-send-email-sean.wang@mediatek.com>
On Wed, Apr 26, 2017 at 11:25 AM, <sean.wang@mediatek.com> wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> Add missing pinctrl binding these which would be used in
> devicetree related files.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Patch applied. This way we avoid subsystem noise in the next
merge window.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 02/30] pinctrl: mediatek: reuse pinctrl driver for mt7623
From: Linus Walleij @ 2017-04-28 8:01 UTC (permalink / raw)
To: sean.wang-NuS5LvNUpcJWk0Htik3J/w
Cc: Rob Herring, Matthias Brugger, John Crispin, Mark Rutland,
Russell King, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
moderated list:ARM/Mediatek SoC support,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1493198774-4478-3-git-send-email-sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On Wed, Apr 26, 2017 at 11:25 AM, <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
> From: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>
> mt7623 pinctrl driver can be compatible with mt2701 one,
> so the patch reuses the driver and deletes those redundant
> ones.
>
> Cc: John Crispin <john-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>
> Signed-off-by: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Partly correct.
> "mediatek,mt6397-pinctrl", compatible with mt6397 pinctrl.
> - "mediatek,mt7623-pinctrl", compatible with mt7623 pinctrl.
NO don't do this.
"compatible" means exactly this: this hardware is compatible with
this driver. That is why we have it!
So instead of mt7623 pretending to be mt2701, let the mt2701 driver
list that it is compatible with mt7623, simple.
So patch pinctrl-mt2701.c mt2701_pctrl_match[] instead.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 07/30] arm: dts: mt7623: add pinctrl nodes to the mt7623 dtsi file
From: Linus Walleij @ 2017-04-28 8:03 UTC (permalink / raw)
To: sean.wang-NuS5LvNUpcJWk0Htik3J/w
Cc: Rob Herring, Matthias Brugger, John Crispin, Mark Rutland,
Russell King, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
moderated list:ARM/Mediatek SoC support,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1493198774-4478-8-git-send-email-sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On Wed, Apr 26, 2017 at 11:25 AM, <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
> From: John Crispin <john-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>
>
> Add pin controller node to the mt7623.dtsi file
>
> Signed-off-by: John Crispin <john-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>
> Signed-off-by: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
(...)
> + pio: pinctrl@10005000 {
> + compatible = "mediatek,mt7623-pinctrl",
> + "mediatek,mt2701-pinctrl";
This looks right. And that is why we should not delete that compatible
string.
Reviewed-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ARM: dts: r7s72100: add usb clocks to device tree
From: Simon Horman @ 2017-04-28 8:04 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Chris Brandt, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas
In-Reply-To: <CAMuHMdXEtefpaUJbbJ7LYjYR2oHaE-epy=eZnAyE-+=GWsy9xg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Apr 28, 2017 at 09:34:54AM +0200, Geert Uytterhoeven wrote:
> On Thu, Apr 27, 2017 at 9:10 PM, Chris Brandt <chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org> wrote:
> > This adds the USB0 and USB1 clocks to the device tree.
> >
> > Signed-off-by: Chris Brandt <chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
>
> Simon: see Section 29.3.2 (BUSWAIT) for the reference to the P1 clock.
Thanks, I see that now.
--
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 2/9] pinctrl: Renesas RZ/A1 pin and gpio controller
From: Linus Walleij @ 2017-04-28 8:06 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Jacopo Mondi, Geert Uytterhoeven, Laurent Pinchart, Chris Brandt,
Rob Herring, Mark Rutland, Russell King, Linux-Renesas,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CAMuHMdUy3wo9x=nkpdSVSt34q5yaARc4+kFDC592V2LF7Cxzrg@mail.gmail.com>
On Wed, Apr 26, 2017 at 2:21 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Wed, Apr 5, 2017 at 4:07 PM, Jacopo Mondi <jacopo+renesas@jmondi.org> wrote:
>> Add combined gpio and pin controller driver for Renesas RZ/A1
>> r7s72100 SoC.
>>
>> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>
>> --- /dev/null
>> +++ b/drivers/pinctrl/pinctrl-rza1.c
>
>> +/*
>> + * Keep this up-to-date with pinconf-generic.h: it performs packing of
>> + * pin conf flags and argument during pinconf_generic_parse_dt_config();
>> + * we simply discard pinconf argument here
>> + */
>> +#define PIN_CONF_UNPACK(pinconf) ((pinconf) & 0xffUL)
>
> Perhaps this should be moved to pinconf-generic.h, to make sure it stays
> up-to-date?
I agree. Use the generic macros.
If further processing is needed, make a static inline to discard config flags
etc.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v5 02/10] pinctrl: generic: Add macros to unpack properties
From: Linus Walleij @ 2017-04-28 8:16 UTC (permalink / raw)
To: Jacopo Mondi
Cc: Geert Uytterhoeven, Laurent Pinchart, Chris Brandt, Rob Herring,
Mark Rutland, Russell King, Linux-Renesas,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1493281194-5200-3-git-send-email-jacopo+renesas@jmondi.org>
On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi
<jacopo+renesas@jmondi.org> wrote:
> Add PIN_CONF_UNPACK_PARAM and PIN_CONF_UNPACK_ARGS macros useful to
> unpack generic properties and their arguments
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
(...)
/*
* Helpful configuration macro to be used in tables etc.
Then this should say "macros" rather than "macro".
> -#define PIN_CONF_PACKED(p, a) ((a << 8) | ((unsigned long) p & 0xffUL))
> +#define PIN_CONF_PACKED(p, a) (((a) << 8) | ((unsigned long) (p) & 0xffUL))
Also adding some extra parantheses I see.
> +#define PIN_CONF_UNPACK_PARAM(c) ((c) & 0xffUL)
> +#define PIN_CONF_UNPACK_ARGS(c) ((c) >> 8)
But why.
I have these two static inlines just below your new macros:
static inline enum pin_config_param pinconf_to_config_param(unsigned
long config)
{
return (enum pin_config_param) (config & 0xffUL);
}
static inline u32 pinconf_to_config_argument(unsigned long config)
{
return (u32) ((config >> 8) & 0xffffffUL);
}
Why can't you use this in your code instead of macros?
We generally prefer static inlines over macros because they are easier
to read.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH][v2] arm64: dts: ls2081ardb: Add DTS support for NXP LS2081ARDB
From: Priyanka Jain @ 2017-04-28 8:25 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA, robh-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, shawnguo-DgEjT+Ai2ygdnm+yROfE0A
Cc: scott.wood-3arQi8VN3Tc, stuart.yoder-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
leoyang.li-3arQi8VN3Tc, Priyanka Jain
This patch add support for NXP LS2081ARDB board which has
LS2081A SoC.
LS2081A SoC is 40-pin derivative of LS2088A SoC
So, from functional perspective both are same.
Hence,ls2088a SoC dtsi files are included from ls2081ARDB dts
Signed-off-by: Priyanka Jain <priyanka.jain-3arQi8VN3Tc@public.gmane.org>
---
Changes for v2: Updated subject and NXP copyright
based on Leo's comments
arch/arm64/boot/dts/freescale/Makefile | 1 +
arch/arm64/boot/dts/freescale/fsl-ls2081a-rdb.dts | 139 +++++++++++++++++++++
2 files changed, 140 insertions(+), 0 deletions(-)
create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2081a-rdb.dts
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 72c4b52..58b80de 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -9,6 +9,7 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1088a-qds.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1088a-rdb.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-qds.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-rdb.dtb
+dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2081a-rdb.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-simu.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2088a-qds.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2088a-rdb.dtb
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2081a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls2081a-rdb.dts
new file mode 100644
index 0000000..bc1c4f6
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2081a-rdb.dts
@@ -0,0 +1,139 @@
+/*
+ * Device Tree file for NXP LS2081A RDB Board.
+ *
+ * Copyright 2017, NXP
+ *
+ * Priyanka Jain <priyanka.jain-3arQi8VN3Tc@public.gmane.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPLv2 or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library 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.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "fsl-ls2088a.dtsi"
+
+/ {
+ model = "NXP Layerscape 2081A RDB Board";
+ compatible = "fsl,ls2081a-rdb", "fsl,ls2081a";
+
+ aliases {
+ serial0 = &serial0;
+ serial1 = &serial1;
+ };
+
+ chosen {
+ stdout-path = "serial1:115200n8";
+ };
+};
+
+&esdhc {
+ status = "okay";
+};
+
+&ifc {
+ status = "disabled";
+};
+
+&i2c0 {
+ status = "okay";
+ pca9547@75 {
+ compatible = "nxp,pca9547";
+ reg = <0x75>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x01>;
+ rtc@51 {
+ compatible = "nxp,pcf2129";
+ reg = <0x51>;
+ };
+ };
+
+ i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x3>;
+
+ adt7481@4c {
+ compatible = "adi,adt7461";
+ reg = <0x4c>;
+ };
+ };
+ };
+};
+
+&dspi {
+ status = "okay";
+ dflash0: n25q512a {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "st,m25p80";
+ spi-max-frequency = <3000000>;
+ reg = <0>;
+ };
+};
+
+
+&qspi {
+ status = "okay";
+ flash0: n25q512a@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "st,m25p80";
+ spi-max-frequency = <20000000>;
+ reg = <0>;
+ };
+ flash1: n25q512a@1 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "st,m25p80";
+ spi-max-frequency = <20000000>;
+ reg = <0>;
+ };
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+};
--
1.7.4.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
* Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable
From: Linus Walleij @ 2017-04-28 8:32 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jacopo Mondi, Geert Uytterhoeven, Laurent Pinchart, Chris Brandt,
Rob Herring, Mark Rutland, Russell King - ARM Linux,
Linux-Renesas, linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAHp75Vcy1OE+9htFx9k3kQhGARQPT1C0gg3SEKZd7ULu_vkUMA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Apr 27, 2017 at 4:56 PM, Andy Shevchenko
<andy.shevchenko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Apr 27, 2017 at 11:19 AM, Jacopo Mondi
> <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org> wrote:
>> Add bi-directional and output-enable pin configuration properties.
>>
>> bi-directional allows to specify when a pin shall operate in input and
>> output mode at the same time. This is particularly useful in platforms
>> where input and output buffers have to be manually enabled.
>>
>> output-enable is just syntactic sugar to specify that a pin shall
>> operate in output mode, ignoring the provided argument.
>> This pairs with input-enable pin configuration option.
>
> For me it looks like you are trying to alias open-drain + bias or
> alike. Don't actually see the benefit of it.
Andy is bringing up a valid point. And I remember asking about
this before.
What does "bi-directional" really mean, electrically speaking?
Does is just mean open drain and/or open source actually?
(See Documentation/gpio/driver.txt for an explanation of
how open drain/source works.)
When you set an output without setting a value, what happens
electrically?
Isn't this bias-high-impedance / High-Z?
Hopefully you can find the answer from Renesas hardware dept.
You can certainly call it whatever the datasheet calls it
in your driver #defines but for the DT bindings we would
ideally have the physical world things.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] arm: dts: sun7i-a20-bananapi: name the GPIO lines
From: Linus Walleij @ 2017-04-28 8:45 UTC (permalink / raw)
To: Oleksij Rempel
Cc: devicetree@vger.kernel.org, Chen-Yu Tsai, Oleksij Rempel,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <60d2e24d-91c8-7563-9ecc-f203b12e0983@rempel-privat.de>
On Fri, Apr 28, 2017 at 7:11 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
> Am 08.08.2016 um 19:51 schrieb Linus Walleij:
>> On Fri, Aug 5, 2016 at 10:06 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>>
>>> This names the GPIO lines on the Banana Pi board in accordance with
>>> the A20_Banana_Pi v1.4 Specification.
>>>
>>> This will make these line names reflect through to userspace
>>> so that they can easily be identified and used with the new
>>> character device ABI.
>>>
>>> Some care has been taken to name all lines, not just those used
>>> by the external connectors, also lines that are muxed into some
>>> other function than GPIO: these are named "[FOO]" so that users
>>> can see with lsgpio what all lines are used for.
>>>
>>> Ps: most of the text was taken from Linus Wallej patch.
>>>
>>> Cc: devicetree@vger.kernel.org
>>> Cc: Linus Walleij <linus.walleij@linaro.org>
>>> Cc: linux-arm-kernel@lists.infradead.org
>>> Cc: Chen-Yu Tsai <wens@csie.org>
>>> Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
>>
>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>>
>> Yours,
>> Linus Walleij
>
> Hm... i assume this patch was lost. Should i resend it?
Yes, but I'm not applying DTS patches. Make sure that the
sunxi maintainers get it and merge it.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group
From: Linus Walleij @ 2017-04-28 8:49 UTC (permalink / raw)
To: Jacopo Mondi
Cc: Geert Uytterhoeven, Laurent Pinchart, Chris Brandt, Rob Herring,
Mark Rutland, Russell King, Linux-Renesas,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1493281194-5200-11-git-send-email-jacopo+renesas@jmondi.org>
On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi
<jacopo+renesas@jmondi.org> wrote:
> Add pin configuration subnode for ETHER ethernet controller.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
(...)
> + pins_bidir {
> + pinmux = <RZA1_PINMUX(3, 3, 2)>;/* P3_3 = ET_MDIO */
> + bi-directional;
> + };
So I'm against merging this until someone explains what "bi-directional"
actually means, electrically speaking. What happens physically on this pin?
I think this just means open drain.
It is dangerous to merge things we don't understand.
Surely someone inside Renesas can answer this question.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2] arm: dts: sun7i-a20-bananapi: name the GPIO lines
From: Oleksij Rempel @ 2017-04-28 9:03 UTC (permalink / raw)
To: Linus Walleij
Cc: devicetree@vger.kernel.org, Chen-Yu Tsai,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CACRpkdZcnJ1eCNW4ZF_A4zbeCt3JcAuw-1meB_Pn7ctMy99B_g@mail.gmail.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 1419 bytes --]
Am 28.04.2017 um 10:45 schrieb Linus Walleij:
> On Fri, Apr 28, 2017 at 7:11 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>> Am 08.08.2016 um 19:51 schrieb Linus Walleij:
>>> On Fri, Aug 5, 2016 at 10:06 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>>>
>>>> This names the GPIO lines on the Banana Pi board in accordance with
>>>> the A20_Banana_Pi v1.4 Specification.
>>>>
>>>> This will make these line names reflect through to userspace
>>>> so that they can easily be identified and used with the new
>>>> character device ABI.
>>>>
>>>> Some care has been taken to name all lines, not just those used
>>>> by the external connectors, also lines that are muxed into some
>>>> other function than GPIO: these are named "[FOO]" so that users
>>>> can see with lsgpio what all lines are used for.
>>>>
>>>> Ps: most of the text was taken from Linus Wallej patch.
>>>>
>>>> Cc: devicetree@vger.kernel.org
>>>> Cc: Linus Walleij <linus.walleij@linaro.org>
>>>> Cc: linux-arm-kernel@lists.infradead.org
>>>> Cc: Chen-Yu Tsai <wens@csie.org>
>>>> Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
>>>
>>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>>
>> Hm... i assume this patch was lost. Should i resend it?
>
> Yes, but I'm not applying DTS patches. Make sure that the
> sunxi maintainers get it and merge it.
Chen-Yu Tsai - ping.
--
Regards,
Oleksij
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1 0/2] Add PCIe host driver support for Mediatek SoCs
From: Ryder Lee @ 2017-04-28 9:10 UTC (permalink / raw)
To: Bjorn Helgaas, Rob Herring, Arnd Bergmann
Cc: linux-pci, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, Red Hung, Ryder Lee
Hi,
This patch series add Mediatek Gen2 PCIe host controller driver and
dt-binding document. It can be found on MT7623 series SoCs.
This driver was validated using Broadcom Tigon3 and Intel(R) 82575/82576
gigabit ethernet card.
Changes since v1:
- add .suppress_bind_attrs.
- remove unnecessary *_valid_device() pattern.
- remove PCI_PROBE_ONLY.
- use the regular readl() instead of readl_relaxed().
- add .map_bus() and change to use pci_generic_config_read/pci_generic_config_write.
- revise dt-binding document and move nonstandard properties to root node.
- change compatible string.
- use interrupt-map property and replace mtk_pcie_map_irq() with of_irq_parse_and_map_pci().
- use the new pci_register_host_bridge() method instead of pci_scan_root_bus().
Ryder Lee (2):
PCI: mediatek: Add Mediatek PCIe host controller support
dt-bindings: pcie: Add documentation for Mediatek PCIe
.../bindings/pci/mediatek,gen2v1-pcie.txt | 174 +++++++
drivers/pci/host/Kconfig | 11 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pcie-mediatek.c | 563 +++++++++++++++++++++
4 files changed, 749 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/mediatek,gen2v1-pcie.txt
create mode 100644 drivers/pci/host/pcie-mediatek.c
--
1.9.1
^ 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