Devicetree
 help / color / mirror / Atom feed
* Re: [PATCH 6/6] arm64: dts: sunxi: add support for the Orange Pi PC 2 board
From: Maxime Ripard @ 2017-01-05 22:13 UTC (permalink / raw)
  To: Icenowy Zheng
  Cc: Linus Walleij, Chen-Yu Tsai, Rob Herring, Andre Przywara,
	linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
	linux-gpio-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-clk-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161226171156.11605-3-icenowy-ymACFijhrKM@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 5748 bytes --]

On Tue, Dec 27, 2016 at 01:11:56AM +0800, Icenowy Zheng wrote:
> From: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>
> 
> The Orange Pi PC 2 is a typical single board computer using the
> Allwinner H5 SoC. Apart from the usual suspects it features three
> separately driven USB ports and a Gigabit Ethernet port.
> Also it has a SPI NOR flash soldered, from which the board can boot
> from. This enables the SBC to behave like a "real computer" with
> built-in firmware.
> 
> Add the board specific .dts file, which includes the H5 .dtsi and
> enables the peripherals that we support so far.
> 
> Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>
> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> ---
>  arch/arm64/boot/dts/allwinner/Makefile             |   1 +
>  .../boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts  | 183 +++++++++++++++++++++
>  2 files changed, 184 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
> 
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> index 1e29a5ae8282..b26bb46b934c 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -1,4 +1,5 @@
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
>  
>  always		:= $(dtb-y)
>  subdir-y	:= $(dts-dirs)
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
> new file mode 100644
> index 000000000000..a29ca6b274bb
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
> @@ -0,0 +1,183 @@
> +/*
> + * Copyright (C) 2016 ARM Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL 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 file 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 file 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 "sun50i-h5.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/pinctrl/sun4i-a10.h>
> +
> +/ {
> +	model = "Xunlong Orange Pi PC 2";
> +	compatible = "xunlong,orangepi-pc2", "allwinner,sun50i-h5";
> +
> +	reg_vcc3v3: vcc3v3 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc3v3";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +	};
> +
> +	aliases {
> +		serial0 = &uart0;
> +	};
> +
> +	chosen {
> +		stdout-path = "serial0:115200n8";
> +	};
> +
> +	leds {
> +		compatible = "gpio-leds";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&leds_opc>, <&leds_r_opc>;

There's no need to declare the LED GPIO in pinctrl.

> +
> +		pwr_led {
> +			label = "orangepi:green:pwr";
> +			gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
> +			default-state = "on";
> +		};
> +
> +		status_led {
> +			label = "orangepi:red:status";
> +			gpios = <&pio 0 15 GPIO_ACTIVE_HIGH>;
> +		};
> +	};
> +
> +	r_gpio_keys {
> +		compatible = "gpio-keys";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&sw_r_opc>;

Ditto

> +
> +		sw4 {
> +			label = "sw4";
> +			linux,code = <BTN_0>;
> +			gpios = <&r_pio 0 3 GPIO_ACTIVE_LOW>;
> +		};
> +	};
> +};
> +
> +&ehci1 {
> +	status = "okay";
> +};
> +
> +&ehci2 {
> +	status = "okay";
> +};
> +
> +&ehci3 {
> +	status = "okay";
> +};
> +
> +&ir {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&ir_pins_a>;
> +	status = "okay";
> +};
> +
> +&mmc0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;

Ditto

> +	vmmc-supply = <&reg_vcc3v3>;
> +	bus-width = <4>;
> +	cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
> +	cd-inverted;

Do you need both the GPIO flag and the cd-inverted one?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* Re: Myir AM437x Rico board support (DTS) for Linux mainline 4.9 and 4.4 Ti Processor SDK 03.02.00.05
From: Tony Lindgren @ 2017-01-05 22:12 UTC (permalink / raw)
  To: Pavel Pisa
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-xIg/pKzrS19vn6HldHNs0ANdhmdF6hFW, Dan Murphy,
	support-0A6ZgDe55FJWk0Htik3J/w, Tomi Valkeinen,
	linux-omap-u79uwXL29TY76Z2rM5mHXA, Jyri Sarha
In-Reply-To: <201701051754.03159.ppisa-hnFyeMMZ0rvQT0dZR+AlfA@public.gmane.org>

Hi,

* Pavel Pisa <ppisa-hnFyeMMZ0rvQT0dZR+AlfA@public.gmane.org> [170105 08:54]:
> Hello Tony and others,
> 
> I have found some personal time during holydays[*] and proceed
> furhers with RICO board support for perspective kernel versions.
> 
> I have prepared a device tree which provides quite complete
> board support for the most of peripherals found on MyIR
> AM437x Ricoboard. I have tested the kernel on the real board
> which I have bought for myself to do testing and can contribute
> previous work to to mainline.
> 
> LEDs, Ethernet, LEDs, SDcard, eMMC, onboard SPI NVM etc.
> works. Generally the AM437x mainline support is great except
> for SGX. It has been pleasant to work with it. I used TFTP boot
> and ramdisk overlay over NFS exported Debian Jessie RO chroot
> install.

OK nice. Please start sending the patches to linux-omap,
linux-arm-kernel and devicetree mailing lists so we can
start merging in the support :)

> Only significant missing piece is HDMI support. I have put
> setup which I prepared for Ti kernels to device-tree.
> But mainline supports SII9022 HDMI encoder only by
> 
>   drivers/gpu/drm/bridge/sii902x.c
> 
> but OMAP DSS changes "sil,sii9022" in device-tree
> to omapdss,sil,sii9022 which seems to be customized
> version found in Texas Instruments tree
> 
>   drivers/gpu/drm/omapdrm/displays/encoder-sii9022-video.c
> 
> Do you know if there are some plans to support combination
> of this driver or include customized version in mainline
> for OMAP?
> 
> I expect that non accelerated graphic with parallel
> LCD panel would work with 4.9 mainline kernel and
> the prepared device tree if #if 0 is changed to #if 1.
> 
> The 4.9 mainline support files can be found there
> 
>   http://pikron.com/files/linux/rico/linux-4.9/am437x-myir-ricoboard.dts
>   http://pikron.com/files/linux/rico/linux-4.9/am437x-myir-ricoboard.dtb
>   
> http://pikron.com/files/linux/rico/linux-4.9/config-4.9-mainline-myir-ricoboard

Seems OK for the dts on a quick glance. Tomi and Jyri would
know more about the HDMI support.

> I would be happy if they can help others, some feedback
> and cooperation would be great as well. I would be happy
> to contribute DTS to mainline if it is found acceptable.

Yeah let's do that first, then you can figure out the HDMI
part.

> I can prepare version without HDMI or complete DSS section
> if actual untested/able section is unacceptable.
> 
> Because of missing HDMI support and attempt to test SGX
> accelerated support, I have tried official Ti
> Processor SDK image for AM437x (am437x-evm-linux-03.02.00.05).
> I have prepared DTS and tested it with my overlay enabled
> kernel and Debian and Ti root filesystems as well as with
> original Ti kernel.
> 
> There are files for use with HDMI connected monitor
> 
>   files/linux/rico/linux-ti-4.4/am437x-myir-ricoboard-hdmi.dts
>   files/linux/rico/linux-ti-4.4/am437x-myir-ricoboard-hdmi.dtb
>   files/linux/rico/linux-ti-4.4/config-ti-4.4-myir-ricoboard
> 
> and another set for parallel LCD panel (untested)
> 
>   files/linux/rico/linux-ti-4.4/am437x-myir-ricoboard.dts
>   files/linux/rico/linux-ti-4.4/am437x-myir-ricoboard.dtb
> 
> I have managed to build SGX driver for my kernel configuration
> and from the testing of Ti image it seem to be used same way
> as for original Ti kernel build.
> 
> I have no luck with accelerated Xorg. But Ti release notes
> states that Xorg support is missing in 03.02.00.05.
> 
> There is question if it is permanent status or if there is some
> change.
> 
> Is there chance that Ti includes this prepared DTS in their
> kernel branch?
> 
> For sure mainline 4.9 support is even more interesting
> for me and future.

No idea about the above really, but the basic support seem
very much straight forward.

Regards,

Tony


> [*] Our company partner cares mainly (and may be pays something)
> for my work on maintenance of ancient MyIR Linux 3.12.10 kernel
> in their products. And MyIR company does not seem to really
> care about users and updates at all even if the enhancements
> are sent them for free. Typical experience but great thing about
> this board is that a schematic diagram is provided which makes
> possible to develop proper support.
> 
> 
--
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 net-next 01/10] net: netcp: ethss: add support of subsystem register region regmap
From: Murali Karicheri @ 2017-01-05 22:08 UTC (permalink / raw)
  To: Rob Herring
  Cc: netdev, linux-omap, grygorii.strashko, mugunthanvnm, linux-kernel,
	arnd, davem, devicetree, mark.rutland
In-Reply-To: <586EAFBE.1000500@ti.com>

On 01/05/2017 03:42 PM, Murali Karicheri wrote:
> Rob,
> 
> On 12/22/2016 04:24 PM, Rob Herring wrote:
>> On Tue, Dec 20, 2016 at 05:09:44PM -0500, Murali Karicheri wrote:
>>> From: WingMan Kwok <w-kwok2@ti.com>
>>>
>>> 10gbe phy driver needs to access the 10gbe subsystem control
>>> register during phy initialization. To facilitate the shared
>>> access of the subsystem register region between the 10gbe Ethernet
>>> driver and the phy driver, this patch adds support of the
>>> subsystem register region defined by a syscon node in the dts.
>>>
>>> Although there is no shared access to the gbe subsystem register
>>> region, using syscon for that is for the sake of consistency.
>>>
>>> This change is backward compatible with previously released gbe
>>> devicetree bindings.
>>>
>>> Signed-off-by: WingMan Kwok <w-kwok2@ti.com>
>>> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
>>> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
>>> ---
>>>  .../devicetree/bindings/net/keystone-netcp.txt     |  16 ++-
>>>  drivers/net/ethernet/ti/netcp_ethss.c              | 140 +++++++++++++++++----
>>>  2 files changed, 127 insertions(+), 29 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/keystone-netcp.txt b/Documentation/devicetree/bindings/net/keystone-netcp.txt
>>> index 04ba1dc..0854a73 100644
>>> --- a/Documentation/devicetree/bindings/net/keystone-netcp.txt
>>> +++ b/Documentation/devicetree/bindings/net/keystone-netcp.txt
>>> @@ -72,20 +72,24 @@ Required properties:
>>>  		"ti,netcp-gbe-2" for 1GbE N NetCP 1.5 (N=2)
>>>  		"ti,netcp-xgbe" for 10 GbE
>>>  
>>> +- syscon-subsys:	phandle to syscon node of the switch
>>> +			subsystem registers.
>>> +
>>>  - reg:		register location and the size for the following register
>>>  		regions in the specified order.
>>>  		- switch subsystem registers
>>> +		- sgmii module registers
>>
>> This needs to go on the end of the list. Otherwise, it is not backwards 
>> compatible.
> 
> Thanks for your review! I assumed backward compatibility means new kernel
> should work with old DTB. The driver code is adjusted to work with both
> DTBs. Isn't that enough?
Rob,

I will pull out 1/10 and 2/10 from the series as it needs more work and
re-submit rest of the patches in my v1 spin. However please reply to my
above backward compatibility question.

Thanks and Regards,

Murali
> 
> Murali
> 
>>
>>>  		- sgmii port3/4 module registers (only for NetCP 1.4)
>>>  		- switch module registers
>>>  		- serdes registers (only for 10G)
>>>  
>>>  		NetCP 1.4 ethss, here is the order
>>> -			index #0 - switch subsystem registers
>>> +			index #0 - sgmii module registers
>>>  			index #1 - sgmii port3/4 module registers
>>>  			index #2 - switch module registers
>>>  
>>>  		NetCP 1.5 ethss 9 port, 5 port and 2 port
>>> -			index #0 - switch subsystem registers
>>> +			index #0 - sgmii module registers
>>>  			index #1 - switch module registers
>>>  			index #2 - serdes registers
>>>  
>>> @@ -145,6 +149,11 @@ Optional properties:
>>>  
>>>  Example binding:
>>>  
>>> +gbe_subsys: subsys@2090000 {
>>> +	compatible = "syscon";
>>> +	reg = <0x02090000 0x100>;
>>> +};
>>> +
>>>  netcp: netcp@2000000 {
>>>  	reg = <0x2620110 0x8>;
>>>  	reg-names = "efuse";
>>> @@ -163,7 +172,8 @@ netcp: netcp@2000000 {
>>>  		ranges;
>>>  		gbe@90000 {
>>>  			label = "netcp-gbe";
>>> -			reg = <0x90000 0x300>, <0x90400 0x400>, <0x90800 0x700>;
>>> +			syscon-subsys = <&gbe_subsys>;
>>> +			reg = <0x90100 0x200>, <0x90400 0x200>, <0x90800 0x700>;
>>>  			/* enable-ale; */
>>>  			tx-queue = <648>;
>>>  			tx-channel = <8>;
>>
> 
> 


-- 
Murali Karicheri
Linux Kernel, Keystone

^ permalink raw reply

* Re: [PATCH 1/6] drivers: pinctrl: add driver for Allwinner H5 SoC
From: Maxime Ripard @ 2017-01-05 22:08 UTC (permalink / raw)
  To: Icenowy Zheng
  Cc: Linus Walleij, Chen-Yu Tsai, Rob Herring, Andre Przywara,
	linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
	linux-gpio-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-clk-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161226162518.5367-2-icenowy-ymACFijhrKM@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 26304 bytes --]

On Tue, Dec 27, 2016 at 12:25:13AM +0800, Icenowy Zheng wrote:
> Based on the Allwinner H5 datasheet and the pinctrl driver of the
> backward-compatible H3 this introduces the pin multiplex assignments for
> the H5 SoC.
> 
> H5 introduced some more pin functions (e.g. three more groups of TS
> pins, and one more groups of SIM pins) than H3.
> 
> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> ---
>  .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
>  drivers/pinctrl/sunxi/Kconfig                      |   4 +
>  drivers/pinctrl/sunxi/Makefile                     |   1 +
>  drivers/pinctrl/sunxi/pinctrl-sun50i-h5.c          | 551 +++++++++++++++++++++
>  4 files changed, 557 insertions(+)
>  create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-h5.c
> 
> diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> index c931fb1c01a6..2fd688c8dbdb 100644
> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> @@ -23,6 +23,7 @@ Required properties:
>    "allwinner,sun8i-h3-pinctrl"
>    "allwinner,sun8i-h3-r-pinctrl"
>    "allwinner,sun50i-a64-pinctrl"
> +  "allwinner,sun50i-h5-r-pinctrl"

You're using a different compatible in your driver.

>    "nextthing,gr8-pinctrl"
>  
>  - reg: Should contain the register physical address and length for the
> diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
> index bff1ffc6f01e..e9c47e8b2ee0 100644
> --- a/drivers/pinctrl/sunxi/Kconfig
> +++ b/drivers/pinctrl/sunxi/Kconfig
> @@ -76,4 +76,8 @@ config PINCTRL_SUN50I_A64
>  	bool
>  	select PINCTRL_SUNXI
>  
> +config PINCTRL_SUN50I_H5
> +	bool
> +	select PINCTRL_SUNXI
> +
>  endif
> diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
> index 95f93d0561fc..bab215d25440 100644
> --- a/drivers/pinctrl/sunxi/Makefile
> +++ b/drivers/pinctrl/sunxi/Makefile
> @@ -17,5 +17,6 @@ obj-$(CONFIG_PINCTRL_SUN50I_A64)	+= pinctrl-sun50i-a64.o
>  obj-$(CONFIG_PINCTRL_SUN8I_A83T)	+= pinctrl-sun8i-a83t.o
>  obj-$(CONFIG_PINCTRL_SUN8I_H3)		+= pinctrl-sun8i-h3.o
>  obj-$(CONFIG_PINCTRL_SUN8I_H3_R)	+= pinctrl-sun8i-h3-r.o
> +obj-$(CONFIG_PINCTRL_SUN50I_H5)		+= pinctrl-sun50i-h5.o
>  obj-$(CONFIG_PINCTRL_SUN9I_A80)		+= pinctrl-sun9i-a80.o
>  obj-$(CONFIG_PINCTRL_SUN9I_A80_R)	+= pinctrl-sun9i-a80-r.o
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-h5.c b/drivers/pinctrl/sunxi/pinctrl-sun50i-h5.c
> new file mode 100644
> index 000000000000..67a55df37782
> --- /dev/null
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-h5.c
> @@ -0,0 +1,551 @@
> +/*
> + * Allwinner H5 SoC pinctrl driver.
> + *
> + * Copyright (C) 2016 Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> + *
> + * Based on pinctrl-sun8i-h3.c, which is:
> + * Copyright (C) 2015 Jens Kuske <jenskuske-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> + *
> + * Based on pinctrl-sun8i-a23.c, which is:
> + * Copyright (C) 2014 Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> + * Copyright (C) 2014 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/pinctrl/pinctrl.h>
> +
> +#include "pinctrl-sunxi.h"
> +
> +static const struct sunxi_desc_pin sun50i_h5_pins[] = {
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 0),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "uart2"),		/* TX */
> +		  SUNXI_FUNCTION(0x3, "jtag"),		/* MS */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)),	/* PA_EINT0 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 1),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "uart2"),		/* RX */
> +		  SUNXI_FUNCTION(0x3, "jtag"),		/* CK */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)),	/* PA_EINT1 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 2),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "uart2"),		/* RTS */
> +		  SUNXI_FUNCTION(0x3, "jtag"),		/* DO */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)),	/* PA_EINT2 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 3),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "uart2"),		/* CTS */
> +		  SUNXI_FUNCTION(0x3, "jtag"),		/* DI */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 3)),	/* PA_EINT3 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 4),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "uart0"),		/* TX */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 4)),	/* PA_EINT4 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 5),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "uart0"),		/* RX */
> +		  SUNXI_FUNCTION(0x3, "pwm0"),
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 5)),	/* PA_EINT5 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 6),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "sim"),		/* PWREN */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 6)),	/* PA_EINT6 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 7),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "sim"),		/* CLK */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 7)),	/* PA_EINT7 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 8),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "sim"),		/* DATA */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 8)),	/* PA_EINT8 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 9),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "sim"),		/* RST */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 9)),	/* PA_EINT9 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 10),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "sim"),		/* DET */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 10)),	/* PA_EINT10 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 11),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "i2c0"),		/* SCK */
> +		  SUNXI_FUNCTION(0x3, "di"),		/* TX */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 11)),	/* PA_EINT11 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 12),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "i2c0"),		/* SDA */
> +		  SUNXI_FUNCTION(0x3, "di"),		/* RX */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 12)),	/* PA_EINT12 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 13),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "spi1"),		/* CS */
> +		  SUNXI_FUNCTION(0x3, "uart3"),		/* TX */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 13)),	/* PA_EINT13 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 14),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "spi1"),		/* CLK */
> +		  SUNXI_FUNCTION(0x3, "uart3"),		/* RX */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 14)),	/* PA_EINT14 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 15),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "spi1"),		/* MOSI */
> +		  SUNXI_FUNCTION(0x3, "uart3"),		/* RTS */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 15)),	/* PA_EINT15 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 16),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "spi1"),		/* MISO */
> +		  SUNXI_FUNCTION(0x3, "uart3"),		/* CTS */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 16)),	/* PA_EINT16 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 17),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "spdif"),		/* OUT */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 17)),	/* PA_EINT17 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 18),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "i2s0"),		/* SYNC */
> +		  SUNXI_FUNCTION(0x3, "i2c1"),		/* SCK */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 18)),	/* PA_EINT18 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 19),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "i2s0"),		/* CLK */
> +		  SUNXI_FUNCTION(0x3, "i2c1"),		/* SDA */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 19)),	/* PA_EINT19 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 20),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "i2s0"),		/* DOUT */
> +		  SUNXI_FUNCTION(0x3, "sim"),		/* VPPEN */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 20)),	/* PA_EINT20 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 21),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "i2s0"),		/* DIN */
> +		  SUNXI_FUNCTION(0x3, "sim"),		/* VPPPP */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 21)),	/* PA_EINT21 */
> +	/* Hole */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 0),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "nand0"),		/* WE */
> +		  SUNXI_FUNCTION(0x3, "spi0")),		/* MOSI */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 1),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "nand0"),		/* ALE */
> +		  SUNXI_FUNCTION(0x3, "spi0"),		/* MISO */
> +		  SUNXI_FUNCTION(0x4, "mmc2")),		/* DS */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 2),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "nand0"),		/* CLE */
> +		  SUNXI_FUNCTION(0x3, "spi0")),		/* CLK */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 3),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "nand0"),		/* CE1 */
> +		  SUNXI_FUNCTION(0x3, "spi0")),		/* CS */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 4),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "nand0"),		/* CE0 */
> +		  SUNXI_FUNCTION(0x4, "spi0")),		/* MISO */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 5),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "nand0"),		/* RE */
> +		  SUNXI_FUNCTION(0x3, "mmc2")),		/* CLK */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 6),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "nand0"),		/* RB0 */
> +		  SUNXI_FUNCTION(0x3, "mmc2")),		/* CMD */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 7),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "nand0")),	/* RB1 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 8),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQ0 */
> +		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D0 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 9),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQ1 */
> +		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D1 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 10),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQ2 */
> +		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D2 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 11),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQ3 */
> +		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D3 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 12),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQ4 */
> +		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D4 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 13),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQ5 */
> +		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D5 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 14),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQ6 */
> +		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D6 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 15),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQ7 */
> +		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D7 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 16),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQS */
> +		  SUNXI_FUNCTION(0x3, "mmc2")),		/* RST */
> +	/* Hole */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 0),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "emac"),		/* RXD3 */
> +		  SUNXI_FUNCTION(0x3, "di"),		/* TX */
> +		  SUNXI_FUNCTION(0x4, "ts2")),		/* CLK */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 1),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "emac"),		/* RXD2 */
> +		  SUNXI_FUNCTION(0x3, "di"),		/* RX */
> +		  SUNXI_FUNCTION(0x4, "ts2")),		/* ERR */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 2),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "emac"),		/* RXD1 */
> +		  SUNXI_FUNCTION(0x4, "ts2")),		/* SYNC */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 3),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "emac"),		/* RXD0 */
> +		  SUNXI_FUNCTION(0x4, "ts2")),		/* DVLD */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 4),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "emac"),		/* RXCK */
> +		  SUNXI_FUNCTION(0x4, "ts2")),		/* D0 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 5),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "emac"),		/* RXCTL/RXDV */
> +		  SUNXI_FUNCTION(0x4, "ts2")),		/* D1 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 6),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "emac"),		/* RXERR */
> +		  SUNXI_FUNCTION(0x4, "ts2")),		/* D2 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 7),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "emac"),		/* TXD3 */
> +		  SUNXI_FUNCTION(0x4, "ts2"),		/* D3 */
> +		  SUNXI_FUNCTION(0x5, "ts3")),		/* CLK */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 8),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "emac"),		/* TXD2 */
> +		  SUNXI_FUNCTION(0x4, "ts2"),		/* D4 */
> +		  SUNXI_FUNCTION(0x5, "ts3")),		/* ERR */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 9),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "emac"),		/* TXD1 */
> +		  SUNXI_FUNCTION(0x4, "ts2"),		/* D5 */
> +		  SUNXI_FUNCTION(0x5, "ts3")),		/* SYNC */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 10),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "emac"),		/* TXD0 */
> +		  SUNXI_FUNCTION(0x4, "ts2"),		/* D6 */
> +		  SUNXI_FUNCTION(0x5, "ts3")),		/* DVLD */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 11),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "emac"),		/* CRS */
> +		  SUNXI_FUNCTION(0x4, "ts2"),		/* D7 */
> +		  SUNXI_FUNCTION(0x5, "ts3")),		/* D0 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 12),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "emac"),		/* TXCK */
> +		  SUNXI_FUNCTION(0x4, "sim")),		/* PWREN */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 13),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "emac"),		/* TXCTL/TXEN */
> +		  SUNXI_FUNCTION(0x4, "sim")),		/* CLK */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 14),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "emac"),		/* TXERR */
> +		  SUNXI_FUNCTION(0x4, "sim")),		/* DATA */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 15),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "emac"),		/* CLKIN/COL */
> +		  SUNXI_FUNCTION(0x4, "sim")),		/* RST */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 16),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "emac"),		/* MDC */
> +		  SUNXI_FUNCTION(0x4, "sim")),		/* DET */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 17),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "emac")),		/* MDIO */
> +	/* Hole */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 0),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "csi"),		/* PCLK */
> +		  SUNXI_FUNCTION(0x3, "ts0")),		/* CLK */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 1),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "csi"),		/* MCLK */
> +		  SUNXI_FUNCTION(0x3, "ts0")),		/* ERR */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 2),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "csi"),		/* HSYNC */
> +		  SUNXI_FUNCTION(0x3, "ts0")),		/* SYNC */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 3),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "csi"),		/* VSYNC */
> +		  SUNXI_FUNCTION(0x3, "ts0")),		/* DVLD */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 4),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "csi"),		/* D0 */
> +		  SUNXI_FUNCTION(0x3, "ts0")),		/* D0 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 5),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "csi"),		/* D1 */
> +		  SUNXI_FUNCTION(0x3, "ts0")),		/* D1 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 6),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "csi"),		/* D2 */
> +		  SUNXI_FUNCTION(0x3, "ts0")),		/* D2 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 7),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "csi"),		/* D3 */
> +		  SUNXI_FUNCTION(0x3, "ts0"),		/* D3 */
> +		  SUNXI_FUNCTION(0x4, "ts1")),		/* CLK */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 8),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "csi"),		/* D4 */
> +		  SUNXI_FUNCTION(0x3, "ts0"),		/* D4 */
> +		  SUNXI_FUNCTION(0x4, "ts1")),		/* ERR */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 9),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "csi"),		/* D5 */
> +		  SUNXI_FUNCTION(0x3, "ts0"),		/* D5 */
> +		  SUNXI_FUNCTION(0x4, "ts1")),		/* SYNC */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 10),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "csi"),		/* D6 */
> +		  SUNXI_FUNCTION(0x3, "ts0"),		/* D6 */
> +		  SUNXI_FUNCTION(0x4, "ts1")),		/* DVLD */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 11),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "csi"),		/* D7 */
> +		  SUNXI_FUNCTION(0x3, "ts"),		/* D7 */
> +		  SUNXI_FUNCTION(0x4, "ts1")),		/* D0 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 12),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "csi"),		/* SCK */
> +		  SUNXI_FUNCTION(0x3, "i2c2")),		/* SCK */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 13),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "csi"),		/* SDA */
> +		  SUNXI_FUNCTION(0x3, "i2c2")),		/* SDA */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 14),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x3, "sim")),		/* VPPEN */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 15),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x3, "sim")),		/* VPPPP */
> +	/* Hole */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 0),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "mmc0"),		/* D1 */
> +		  SUNXI_FUNCTION(0x3, "jtag")),		/* MS */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 1),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "mmc0"),		/* D0 */
> +		  SUNXI_FUNCTION(0x3, "jtag")),		/* DI */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 2),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "mmc0"),		/* CLK */
> +		  SUNXI_FUNCTION(0x3, "uart0")),	/* TX */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 3),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "mmc0"),		/* CMD */
> +		  SUNXI_FUNCTION(0x3, "jtag")),		/* DO */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 4),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "mmc0"),		/* D3 */
> +		  SUNXI_FUNCTION(0x3, "uart0")),	/* RX */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 5),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "mmc0"),		/* D2 */
> +		  SUNXI_FUNCTION(0x3, "jtag")),		/* CK */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 6),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out")),
> +	/* Hole */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 0),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "mmc1"),		/* CLK */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 0)),	/* PG_EINT0 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 1),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "mmc1"),		/* CMD */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 1)),	/* PG_EINT1 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 2),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "mmc1"),		/* D0 */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 2)),	/* PG_EINT2 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 3),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "mmc1"),		/* D1 */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 3)),	/* PG_EINT3 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 4),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "mmc1"),		/* D2 */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 4)),	/* PG_EINT4 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 5),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "mmc1"),		/* D3 */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 5)),	/* PG_EINT5 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 6),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "uart1"),		/* TX */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 6)),	/* PG_EINT6 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 7),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "uart1"),		/* RX */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 7)),	/* PG_EINT7 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 8),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "uart1"),		/* RTS */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 8)),	/* PG_EINT8 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 9),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "uart1"),		/* CTS */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 9)),	/* PG_EINT9 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 10),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "i2s1"),		/* SYNC */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 10)),	/* PG_EINT10 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 11),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "i2s1"),		/* CLK */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 11)),	/* PG_EINT11 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 12),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "i2s1"),		/* DOUT */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 12)),	/* PG_EINT12 */
> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 13),
> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
> +		  SUNXI_FUNCTION(0x1, "gpio_out"),
> +		  SUNXI_FUNCTION(0x2, "i2s1"),		/* DIN */
> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 13)),	/* PG_EINT13 */
> +};
> +
> +static const struct sunxi_pinctrl_desc sun50i_h5_pinctrl_data = {
> +	.pins = sun50i_h5_pins,
> +	.npins = ARRAY_SIZE(sun50i_h5_pins),
> +	.irq_banks = 2,
> +	.irq_read_needs_mux = true
> +};
> +
> +static int sun50i_h5_pinctrl_probe(struct platform_device *pdev)
> +{
> +	return sunxi_pinctrl_init(pdev,
> +				  &sun50i_h5_pinctrl_data);
> +}
> +
> +static const struct of_device_id sun50i_h5_pinctrl_match[] = {
> +	{ .compatible = "allwinner,sun50i-h5-pinctrl", },
> +	{}
> +};
> +
> +static struct platform_driver sun50i_h5_pinctrl_driver = {
> +	.probe	= sun50i_h5_pinctrl_probe,
> +	.driver	= {
> +		.name		= "sun50i-h5-pinctrl",
> +		.of_match_table	= sun50i_h5_pinctrl_match,
> +	},
> +};
> +builtin_platform_driver(sun50i_h5_pinctrl_driver);

This also looks very much like the H3. I'll post a patchset during the
weekend to avoid duplicating those drivers. This was initially done
for the sun5i, but it very much applies here.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* Re: [PATCH 3/6] clk: sunxi-ng: Add H5 clocks
From: Maxime Ripard @ 2017-01-05 22:04 UTC (permalink / raw)
  To: Icenowy Zheng
  Cc: Linus Walleij, Chen-Yu Tsai, Rob Herring, Andre Przywara,
	linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
	linux-gpio-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-clk-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161226162518.5367-4-icenowy-ymACFijhrKM@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 327 bytes --]

On Tue, Dec 27, 2016 at 12:25:15AM +0800, Icenowy Zheng wrote:
> Add the H5 CCU clocks set based on the H3 one.
> 
> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>

Is there any difference with H3's?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* Re: [RFC 0/1] Platform driver support for 'amd5536udc' driver
From: Arnd Bergmann @ 2017-01-05 22:03 UTC (permalink / raw)
  To: Raviteja Garimella
  Cc: Rob Herring, Mark Rutland, Greg Kroah-Hartman, Felipe Balbi,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
	linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1483604597-26160-1-git-send-email-raviteja.garimella-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>

On Thursday, January 5, 2017 1:53:16 PM CET Raviteja Garimella wrote:
> The UDC is based on Synopsys Designware core USB (2.0) Device controller
> IP.
...
> This is a request for comments from maintainers/others regarding approach
> on whether to have 2 different drivers (one each for AMD and Broadcom)
> with a common library (3 files in total), or have a single driver like
> it's done in this patch and have the driver filename changed to some
> common name based on ther underlying IP, like snps_udc.c.

I have not looked at the code at all, so sorry for my ignorance, but
isn't the IP block you describe the one that drivers/usb/dwc2/ is for?
Could you add support for the Broadcom hardware there instead?

	Arnd
--
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] net: ethernet: faraday: To support device tree usage.
From: Arnd Bergmann @ 2017-01-05 21:55 UTC (permalink / raw)
  To: Greentime Hu
  Cc: f.fainelli, netdev, devicetree, andrew, linux-kernel, jiri,
	jonas.jensen, davem
In-Reply-To: <20170105102345.GA25774@app09>

On Thursday, January 5, 2017 6:23:53 PM CET Greentime Hu wrote:
> Signed-off-by: Greentime Hu <green.hu@gmail.com>
> ---
> Changes in v4:
>   - Use the same binding document to describe the same faraday ethernet controller and add faraday to vendor-prefixes.txt.
> Changes in v3:
>   - Nothing changed in this patch but I have committed andestech to vendor-prefixes.txt.
> Changes in v2:
>   - Change atmac100_of_ids to ftmac100_of_ids
> 

The patch looks good to me now, but please add a proper commit log
before your Signed-off-by tag.

	Arnd

^ permalink raw reply

* Re: [PATCHv2 2/5] arm: mvebu: support for SMP on 98DX3336 SoC
From: Chris Packham @ 2017-01-05 20:49 UTC (permalink / raw)
  To: Florian Fainelli,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
  Cc: Rob Herring, Mark Rutland, Jason Cooper, Andrew Lunn,
	Gregory Clement, Sebastian Hesselbarth, Russell King,
	Geert Uytterhoeven, Chris Brand, Sudeep Holla, Jayachandran C,
	Juri Lelli, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <dd384eda81d2420dafe740bf5bb4dae0@svr-chch-ex1.atlnz.lc>

On 05/01/17 17:46, Chris Packham wrote:
> On 05/01/17 17:04, Florian Fainelli wrote:
>> Le 01/04/17 à 19:36, Chris Packham a écrit :
>>> +}
>>> +
>>> +static int __init mv98dx3236_resume_init(void)
>>> +{
>>> +	struct device_node *np;
>>> +	struct resource res;
>>> +	int ret = 0;
>>> +
>>> +	np = of_find_matching_node(NULL, of_mv98dx3236_resume_table);
>>> +	if (!np)
>>> +		return 0;
>>
>> Can't this function be implemented as a smp_ops::smp_init_cpus instead
>> of having this initialization done at arch_initcall time?
>>
>
> I'll look into it. My initial reaction is no because I still need
> armada_xp_smp_init_cpus().
>

I looked at this. I could write a mv98dx3236_smp_init_cpus() that calls 
armada_xp_smp_init_cpus() and inits the resume controller address. My 
original reason for this approach was to parallel mvebu_v7_pmsu_init. I 
won't do anything just yet but is there any downside to the current 
approach?

--
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 net-next 01/10] net: netcp: ethss: add support of subsystem register region regmap
From: Murali Karicheri @ 2017-01-05 20:42 UTC (permalink / raw)
  To: Rob Herring
  Cc: netdev, linux-omap, grygorii.strashko, mugunthanvnm, linux-kernel,
	arnd, davem, devicetree, mark.rutland
In-Reply-To: <20161222212409.arhurpl4bpqf2yw6@rob-hp-laptop>

Rob,

On 12/22/2016 04:24 PM, Rob Herring wrote:
> On Tue, Dec 20, 2016 at 05:09:44PM -0500, Murali Karicheri wrote:
>> From: WingMan Kwok <w-kwok2@ti.com>
>>
>> 10gbe phy driver needs to access the 10gbe subsystem control
>> register during phy initialization. To facilitate the shared
>> access of the subsystem register region between the 10gbe Ethernet
>> driver and the phy driver, this patch adds support of the
>> subsystem register region defined by a syscon node in the dts.
>>
>> Although there is no shared access to the gbe subsystem register
>> region, using syscon for that is for the sake of consistency.
>>
>> This change is backward compatible with previously released gbe
>> devicetree bindings.
>>
>> Signed-off-by: WingMan Kwok <w-kwok2@ti.com>
>> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
>> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
>> ---
>>  .../devicetree/bindings/net/keystone-netcp.txt     |  16 ++-
>>  drivers/net/ethernet/ti/netcp_ethss.c              | 140 +++++++++++++++++----
>>  2 files changed, 127 insertions(+), 29 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/keystone-netcp.txt b/Documentation/devicetree/bindings/net/keystone-netcp.txt
>> index 04ba1dc..0854a73 100644
>> --- a/Documentation/devicetree/bindings/net/keystone-netcp.txt
>> +++ b/Documentation/devicetree/bindings/net/keystone-netcp.txt
>> @@ -72,20 +72,24 @@ Required properties:
>>  		"ti,netcp-gbe-2" for 1GbE N NetCP 1.5 (N=2)
>>  		"ti,netcp-xgbe" for 10 GbE
>>  
>> +- syscon-subsys:	phandle to syscon node of the switch
>> +			subsystem registers.
>> +
>>  - reg:		register location and the size for the following register
>>  		regions in the specified order.
>>  		- switch subsystem registers
>> +		- sgmii module registers
> 
> This needs to go on the end of the list. Otherwise, it is not backwards 
> compatible.

Thanks for your review! I assumed backward compatibility means new kernel
should work with old DTB. The driver code is adjusted to work with both
DTBs. Isn't that enough?

Murali

> 
>>  		- sgmii port3/4 module registers (only for NetCP 1.4)
>>  		- switch module registers
>>  		- serdes registers (only for 10G)
>>  
>>  		NetCP 1.4 ethss, here is the order
>> -			index #0 - switch subsystem registers
>> +			index #0 - sgmii module registers
>>  			index #1 - sgmii port3/4 module registers
>>  			index #2 - switch module registers
>>  
>>  		NetCP 1.5 ethss 9 port, 5 port and 2 port
>> -			index #0 - switch subsystem registers
>> +			index #0 - sgmii module registers
>>  			index #1 - switch module registers
>>  			index #2 - serdes registers
>>  
>> @@ -145,6 +149,11 @@ Optional properties:
>>  
>>  Example binding:
>>  
>> +gbe_subsys: subsys@2090000 {
>> +	compatible = "syscon";
>> +	reg = <0x02090000 0x100>;
>> +};
>> +
>>  netcp: netcp@2000000 {
>>  	reg = <0x2620110 0x8>;
>>  	reg-names = "efuse";
>> @@ -163,7 +172,8 @@ netcp: netcp@2000000 {
>>  		ranges;
>>  		gbe@90000 {
>>  			label = "netcp-gbe";
>> -			reg = <0x90000 0x300>, <0x90400 0x400>, <0x90800 0x700>;
>> +			syscon-subsys = <&gbe_subsys>;
>> +			reg = <0x90100 0x200>, <0x90400 0x200>, <0x90800 0x700>;
>>  			/* enable-ale; */
>>  			tx-queue = <648>;
>>  			tx-channel = <8>;
> 


-- 
Murali Karicheri
Linux Kernel, Keystone

^ permalink raw reply

* Re: [PATCHv2 4/5] arm: mvebu: Add device tree for 98DX3236 SoCs
From: Chris Packham @ 2017-01-05 20:10 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Andrew Lunn, Jason Cooper, devicetree@vger.kernel.org,
	Russell King, linux-kernel@vger.kernel.org, Rob Herring,
	Gregory Clement, linux-arm-kernel@lists.infradead.org,
	Sebastian Hesselbarth
In-Reply-To: <20170105135837.GC25333@leverpostej>

On 06/01/17 02:59, Mark Rutland wrote:
> On Thu, Jan 05, 2017 at 04:36:40PM +1300, Chris Packham wrote:
>> +		internal-regs {
>> +			coreclk: mvebu-sar@18230 {
>> +				compatible = "marvell,mv98dx3236-core-clock";
>> +			};
>> +
>> +			cpuclk: clock-complex@18700 {
>> +				compatible = "marvell,mv98dx3236-cpu-clock";
>> +			};
>> +
>> +			corediv-clock@18740 {
>> +				compatible = "marvell,mv98dx3236-corediv-clock";
>> +				reg = <0xf8268 0xc>;
>> +				base = <&dfx>;
>> +				#clock-cells = <1>;
>> +				clocks = <&mainpll>;
>> +				clock-output-names = "nand";
>> +			};
>
> [...]
>
>> +		};
>> +
>> +		dfx-registers {
>> +			compatible = "simple-bus";
>> +			#address-cells = <1>;
>> +			#size-cells = <1>;
>> +			ranges = <0 MBUS_ID(0x08, 0x00) 0 0x100000>;
>> +
>> +			dfx: dfx@0 {
>> +				compatible = "simple-bus";
>> +				reg = <0 0x100000>;
>> +			};
>> +		};
>
> What is this dfx-registers, exactly?

I've been trying to get that info out of Marvell for a while I'm not 
even sure what the "DFX" acronym stands for. The Armdada 38x also has a 
thing called "DFX" but it seems to be quite different to this one. From 
what I can tell it contains common elements used by both the CPU and 
switch chip so there are things related to clocking and IO pad 
configuration. It is necessary for both the switch and CPU to have a 
handle to access it.

> It has no children, so why is it a
> simple-bus?
>
> From the above, and the patch adding the corediv driver, it looks like
> the corediv-clock actually lives in this block, so I don't understand
> why the corediv-clock is sitting in internal-regs with a sideband
> reference to dfx.

Yeah I think the corediv-clock should be a child of this node. I'll move 
it there.

>
> Thanks,
> Mark.
>

^ permalink raw reply

* Re: [PATCH v2 3/4] ARM64: dts: exynos5433: use macros for pinctrl configuration on Exynos5433
From: Krzysztof Kozlowski @ 2017-01-05 20:08 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Mark Rutland, devicetree@vger.kernel.org, linux-samsung-soc,
	Kukjin Kim, Javier Martinez Canillas, Catalin Marinas,
	Will Deacon, Tomasz Figa, Andi Shyti,
	linux-kernel@vger.kernel.org, Chanwoo Choi, Rob Herring,
	Krzysztof Kozlowski, Sylwester Nawrocki, stable, Andi Shyti,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <CACRpkdbX_MuLSCerq08-1VZV6VJfynjkv1QOr7ssOCGvM5aB_Q@mail.gmail.com>

On Tue, Jan 03, 2017 at 09:24:34AM +0100, Linus Walleij wrote:
> On Fri, Dec 30, 2016 at 4:17 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > On Fri, Dec 30, 2016 at 02:32:39PM +0100, Linus Walleij wrote:
> >> On Fri, Dec 30, 2016 at 5:14 AM, Andi Shyti <andi.shyti@samsung.com> wrote:
> >>
> >> > Use the macros defined in include/dt-bindings/pinctrl/samsung.h
> >> > instead of hardcoded values.
> >> >
> >> > Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> >>
> >> These look fine, but that this and the other DTS patch through ARM SoC.
> >>
> >> If you also need the headerfile patch (patch 2) to go through ARM SoC
> >> that is fine,
> >> I can take it out of pinctrl if you want.
> >
> > Yes, I need the header. It would be much appreciated if you could
> > provide a tag or stable branch with it.
> 
> Nah better just merge that patch into the ARM SoC tree only.
> 
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> 
> I'll remove it from the pinctrl tree.

Thanks, I see it being dropped.

Andi,
Please fix missing Signed-off-by and resend with Linus' tags for #1 and
#2 and with other accumulated tags.

Best regards,
Krzysztof

^ permalink raw reply

* Re: [PATCHv2 0/5] Support for Marvell switches with integrated CPUs
From: Chris Packham @ 2017-01-05 20:02 UTC (permalink / raw)
  To: Marcin Wojtas
  Cc: linux-arm-kernel@lists.infradead.org, Mark Rutland, Andrew Lunn,
	Geert Uytterhoeven, Michael Turquette, Laxman Dewangan,
	linux-clk@vger.kernel.org, Florian Fainelli, Juri Lelli,
	Russell King, Thierry Reding, Linus Walleij,
	Sebastian Hesselbarth, devicetree@vger.kernel.org, Jason Cooper,
	Arnd Bergmann, Kalyan Kinthada
In-Reply-To: <CAPv3WKcT8MxX+g12C1o81MmQJWRt7Rpd-hgBh8rTpLOS3vdtqA@mail.gmail.com>

On 06/01/17 03:09, Marcin Wojtas wrote:
> Hi Chris,
>
> Thanks a lot for your work and v2. Can you please add changelog
> between patchset versions in your cover letter?

Will do for v3. I did actually include a changelog in the individual 
patches but I can collate that here.

clk: mvebu: support for 98DX3236 SoC
- Update devicetree binding documentation for new compatible string
arm: mvebu: support for SMP on 98DX3336 SoC
- Document new enable-method value
- Correct some references from 98DX4521 to 98DX3236
pinctrl: mvebu: pinctrl driver for 98DX3236 SoC
- include sdio support for the 98DX4251
arm: mvebu: Add device tree for 98DX3236 SoCs
- Update devicetree binding documentation to reflect that 98DX3336 and
   984251 are supersets of 98DX3236.
- disable crypto block
- disable sdio for 98DX3236, enable for 98DX4251
arm: mvebu: Add device tree for db-dxbc2 and db-xc3-24g4xg boards
- None

Here's the interdiff

diff --git a/Documentation/devicetree/bindings/arm/cpus.txt 
b/Documentation/devicetree/bindings/arm/cpus.txt
index a1bcfeed5f24..3c2fd72d0bf9 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -202,6 +202,7 @@ nodes to be present and contain the properties 
described below.
                             "marvell,armada-380-smp"
                             "marvell,armada-390-smp"
                             "marvell,armada-xp-smp"
+                           "marvell,98dx3236-smp"
                             "mediatek,mt6589-smp"
                             "mediatek,mt81xx-tz-smp"
                             "qcom,gcc-msm8660"
diff --git a/Documentation/devicetree/bindings/arm/marvell/98dx3236.txt 
b/Documentation/devicetree/bindings/arm/marvell/98dx3236.txt
index e7dc9b2dd90b..64e8c73fc5ab 100644
--- a/Documentation/devicetree/bindings/arm/marvell/98dx3236.txt
+++ b/Documentation/devicetree/bindings/arm/marvell/98dx3236.txt
@@ -6,5 +6,18 @@ shall have the following property:

  Required root node property:

-compatible: one of "marvell,armadaxp-98dx3236", "marvell,armadaxp-98dx3336"
-            or "marvell,armadaxp-98dx4251"
+compatible: must contain "marvell,armadaxp-98dx3236"
+
+In addition, boards using the Marvell 98DX3336 SoC shall have the
+following property:
+
+Required root node property:
+
+compatible: must contain "marvell,armadaxp-98dx3336"
+
+In addition, boards using the Marvell 98DX4251 SoC shall have the
+following property:
+
+Required root node property:
+
+compatible: must contain "marvell,armadaxp-98dx4251"
diff --git a/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt 
b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
index 99c214660bdc..7f28506eaee7 100644
--- a/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
+++ b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
@@ -3,6 +3,7 @@ Device Tree Clock bindings for cpu clock of Marvell EBU 
platforms
  Required properties:
  - compatible : shall be one of the following:
         "marvell,armada-xp-cpu-clock" - cpu clocks for Armada XP
+       "marvell,mv98dx3236-cpu-clock" - cpu clocks for 98DX3236 SoC
  - reg : Address and length of the clock complex register set, followed
          by address and length of the PMU DFS registers
  - #clock-cells : should be set to 1.
diff --git 
a/Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt
index 34c1e380adaa..d4e6ecdfc853 100644
--- 
a/Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt
+++ 
b/Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt
@@ -4,7 +4,7 @@ Please refer to marvell,mvebu-pinctrl.txt in this 
directory for common binding
  part and usage

  Required properties:
-- compatible: "marvell,98dx3236-pinctrl"
+- compatible: "marvell,98dx3236-pinctrl" or "marvell,98dx4251-pinctrl"
  - reg: register specifier of MPP registers

  This driver supports all 98dx3236, 98dx3336 and 98dx4251 variants
@@ -16,12 +16,12 @@ mpp1          1        gpio, spi0(miso), dev(ad9)
  mpp2          2        gpio, spi0(sck), dev(ad10)
  mpp3          3        gpio, spi0(cs0), dev(ad11)
  mpp4          4        gpio, spi0(cs1), smi(mdc), dev(cs0)
-mpp5          5        gpio, pex(rsto), dev(bootcs)
-mpp6          6        gpio, dev(a2)
-mpp7          7        gpio, dev(ale0)
-mpp8          8        gpio, dev(ale1)
-mpp9          9        gpio, dev(ready0)
-mpp10         10       gpio, dev(ad12)
+mpp5          5        gpio, pex(rsto), sd0(cmd), dev(bootcs)
+mpp6          6        gpio, sd0(clk), dev(a2)
+mpp7          7        gpio, sd0(d0), dev(ale0)
+mpp8          8        gpio, sd0(d1), dev(ale1)
+mpp9          9        gpio, sd0(d2), dev(ready0)
+mpp10         10       gpio, sd0(d3), dev(ad12)
  mpp11         11       gpio, uart1(rxd), uart0(cts), dev(ad13)
  mpp12         12       gpio, uart1(txd), uart0(rts), dev(ad14)
  mpp13         13       gpio, intr(out), dev(ad15)
diff --git a/arch/arm/boot/dts/armada-xp-98dx3236.dtsi 
b/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
index bac53f8b44af..61bd3acc5cfe 100644
--- a/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
+++ b/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
@@ -138,6 +138,10 @@
                                 status = "disabled";
                         };

+                       crypto@90000 {
+                               status = "disabled";
+                       };
+
                         xor@f0900 {
                                 status = "disabled";
                         };
@@ -229,3 +233,15 @@
                 marvell,function = "spi0";
         };
  };
+
+&sdio {
+       status = "disabled";
+};
+
+&crypto_sram0 {
+       status = "disabled";
+};
+
+&crypto_sram1 {
+       status = "disabled";
+};
diff --git a/arch/arm/boot/dts/armada-xp-98dx4251.dtsi 
b/arch/arm/boot/dts/armada-xp-98dx4251.dtsi
index 5d1da8513fae..5f7edc23d5ae 100644
--- a/arch/arm/boot/dts/armada-xp-98dx4251.dtsi
+++ b/arch/arm/boot/dts/armada-xp-98dx4251.dtsi
@@ -76,3 +76,17 @@
                 };
         };
  };
+
+&sdio {
+       status = "okay";
+};
+
+&pinctrl {
+       compatible = "marvell,98dx4251-pinctrl";
+
+       sdio_pins: sdio-pins {
+               marvell,pins = "mpp5", "mpp6", "mpp7",
+                              "mpp8", "mpp9", "mpp10";
+               marvell,function = "sd0";
+       };
+};
diff --git a/arch/arm/mach-mvebu/pmsu-98dx3236.c 
b/arch/arm/mach-mvebu/pmsu-98dx3236.c
index fadc81d0c051..87ca42ef40c7 100644
--- a/arch/arm/mach-mvebu/pmsu-98dx3236.c
+++ b/arch/arm/mach-mvebu/pmsu-98dx3236.c
@@ -1,5 +1,5 @@
  /**
- * CPU resume support for 98DX4521 internal CPU (a.k.a. MSYS).
+ * CPU resume support for 98DX3236 internal CPU (a.k.a. MSYS).
   */

  #define pr_fmt(fmt) "mv98dx3236-resume: " fmt
@@ -38,7 +38,7 @@ static int __init mv98dx3236_resume_init(void)
         if (!np)
                 return 0;

-       pr_info("Initializing 98DX4521 Resume\n");
+       pr_info("Initializing 98DX3236 Resume\n");

         if (of_address_to_resource(np, 0, &res)) {
                 pr_err("unable to get resource\n");
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c 
b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
index 2586903c59f0..554eeae8cd21 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
@@ -389,21 +389,27 @@ static struct mvebu_mpp_mode 
mv98dx3236_mpp_modes[] = {
         MPP_MODE(5,
                  MPP_VAR_FUNCTION(0x0, "gpio", NULL, 
V_98DX3236_PLUS),
                  MPP_VAR_FUNCTION(0x1, "pex", "rsto", 
V_98DX3236_PLUS),
+                MPP_VAR_FUNCTION(0x2, "sd0", "cmd",         V_98DX4251),
                  MPP_VAR_FUNCTION(0x4, "dev", "bootcs0", 
V_98DX3236_PLUS)),
         MPP_MODE(6,
                  MPP_VAR_FUNCTION(0x0, "gpo", NULL, 
V_98DX3236_PLUS),
+                MPP_VAR_FUNCTION(0x2, "sd0", "clk",         V_98DX4251),
                  MPP_VAR_FUNCTION(0x4, "dev", "a2", 
V_98DX3236_PLUS)),
         MPP_MODE(7,
                  MPP_VAR_FUNCTION(0x0, "gpio", NULL, 
V_98DX3236_PLUS),
+                MPP_VAR_FUNCTION(0x2, "sd0", "d0",          V_98DX4251),
                  MPP_VAR_FUNCTION(0x4, "dev", "ale0", 
V_98DX3236_PLUS)),
         MPP_MODE(8,
                  MPP_VAR_FUNCTION(0x0, "gpio", NULL, 
V_98DX3236_PLUS),
+                MPP_VAR_FUNCTION(0x2, "sd0", "d1",          V_98DX4251),
                  MPP_VAR_FUNCTION(0x4, "dev", "ale1", 
V_98DX3236_PLUS)),
         MPP_MODE(9,
                  MPP_VAR_FUNCTION(0x0, "gpio", NULL, 
V_98DX3236_PLUS),
+                MPP_VAR_FUNCTION(0x2, "sd0", "d2",          V_98DX4251),
                  MPP_VAR_FUNCTION(0x4, "dev", "ready0", 
V_98DX3236_PLUS)),
         MPP_MODE(10,
                  MPP_VAR_FUNCTION(0x0, "gpio", NULL, 
V_98DX3236_PLUS),
+                MPP_VAR_FUNCTION(0x2, "sd0", "d3",          V_98DX4251),
                  MPP_VAR_FUNCTION(0x4, "dev", "ad12", 
V_98DX3236_PLUS)),
         MPP_MODE(11,
                  MPP_VAR_FUNCTION(0x0, "gpio", NULL, 
V_98DX3236_PLUS),
@@ -501,6 +507,10 @@ static const struct of_device_id 
armada_xp_pinctrl_of_match[] = {
                 .compatible = "marvell,98dx3236-pinctrl",
                 .data       = (void *) V_98DX3236,
         },
+       {
+               .compatible = "marvell,98dx4251-pinctrl",
+               .data       = (void *) V_98DX4251,
+       },
         { },
  };



>
> Best regards,
> Marcin
>
> 2017-01-05 4:36 GMT+01:00 Chris Packham <chris.packham@alliedtelesis.co.nz>:
>> The 98DX3236, 98DX3336 and 98DX4251 are a set of switch ASICs with
>> integrated CPUs. They CPU block is common within these product lines and
>> (as far as I can tell/have been told) is based on the Armada XP. There
>> are a few differences due to the fact they have to squeeze the CPU into
>> the same package as the switch.
>>
>> Chris Packham (4):
>>   clk: mvebu: support for 98DX3236 SoC
>>   arm: mvebu: support for SMP on 98DX3336 SoC
>>   arm: mvebu: Add device tree for 98DX3236 SoCs
>>   arm: mvebu: Add device tree for db-dxbc2 and db-xc3-24g4xg boards
>>
>> Kalyan Kinthada (1):
>>   pinctrl: mvebu: pinctrl driver for 98DX3236 SoC
>>
>>  Documentation/devicetree/bindings/arm/cpus.txt     |   1 +
>>  .../bindings/arm/marvell/98dx3236-resume-ctrl.txt  |  18 ++
>>  .../devicetree/bindings/arm/marvell/98dx3236.txt   |  23 ++
>>  .../devicetree/bindings/clock/mvebu-cpu-clock.txt  |   1 +
>>  .../pinctrl/marvell,armada-98dx3236-pinctrl.txt    |  46 ++++
>>  arch/arm/boot/dts/armada-xp-98dx3236.dtsi          | 247 +++++++++++++++++++++
>>  arch/arm/boot/dts/armada-xp-98dx3336.dtsi          |  78 +++++++
>>  arch/arm/boot/dts/armada-xp-98dx4251.dtsi          |  92 ++++++++
>>  arch/arm/boot/dts/db-dxbc2.dts                     | 159 +++++++++++++
>>  arch/arm/boot/dts/db-xc3-24g4xg.dts                | 155 +++++++++++++
>>  arch/arm/mach-mvebu/Makefile                       |   1 +
>>  arch/arm/mach-mvebu/common.h                       |   1 +
>>  arch/arm/mach-mvebu/platsmp.c                      |  43 ++++
>>  arch/arm/mach-mvebu/pmsu-98dx3236.c                |  69 ++++++
>>  drivers/clk/mvebu/Makefile                         |   2 +-
>>  drivers/clk/mvebu/armada-xp.c                      |  42 ++++
>>  drivers/clk/mvebu/clk-cpu.c                        |  33 ++-
>>  drivers/clk/mvebu/mv98dx3236-corediv.c             | 207 +++++++++++++++++
>>  drivers/pinctrl/mvebu/pinctrl-armada-xp.c          | 155 +++++++++++++
>>  19 files changed, 1369 insertions(+), 4 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/arm/marvell/98dx3236-resume-ctrl.txt
>>  create mode 100644 Documentation/devicetree/bindings/arm/marvell/98dx3236.txt
>>  create mode 100644 Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt
>>  create mode 100644 arch/arm/boot/dts/armada-xp-98dx3236.dtsi
>>  create mode 100644 arch/arm/boot/dts/armada-xp-98dx3336.dtsi
>>  create mode 100644 arch/arm/boot/dts/armada-xp-98dx4251.dtsi
>>  create mode 100644 arch/arm/boot/dts/db-dxbc2.dts
>>  create mode 100644 arch/arm/boot/dts/db-xc3-24g4xg.dts
>>  create mode 100644 arch/arm/mach-mvebu/pmsu-98dx3236.c
>>  create mode 100644 drivers/clk/mvebu/mv98dx3236-corediv.c
>>
>> --
>> 2.11.0.24.ge6920cf
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>


^ permalink raw reply related

* Re: [PATCHv2 0/5] Support for Marvell switches with integrated CPUs
From: Florian Fainelli @ 2017-01-05 19:52 UTC (permalink / raw)
  To: Chris Packham, Andrew Lunn
  Cc: Mark Rutland, Geert Uytterhoeven, Michael Turquette,
	Laxman Dewangan, linux-clk@vger.kernel.org, Juri Lelli,
	Russell King, Thierry Reding, Linus Walleij,
	Sebastian Hesselbarth, devicetree@vger.kernel.org, Jason Cooper,
	Arnd Bergmann, Kalyan Kinthada, Rob Herring, Gregory Clement,
	linux-arm-kernel@lists.infradead.org, Thomas Petazzoni,
	linux-gpio@vger.kernel.org
In-Reply-To: <059c78eaa7dd40c9a46cb08616bae2eb@svr-chch-ex1.atlnz.lc>

On 01/05/2017 11:46 AM, Chris Packham wrote:
> On 06/01/17 02:10, Andrew Lunn wrote:
>>> I'd love to see a switchdev driver but it's a huge task (and no I'm not
>>> committing to writing it). As it stands Marvell ship a switch SDK
>>> largely executes in userspace with a small kernel module providing some
>>> linkage to the underlying hardware.
>>
>> Is there any similarity to the mv88e6xxx family?
>>
>> If it was similar registers, just a different access mechanising, we
>> could probably extend the mv88e6xxx to support MMIO as well as MDIO.
> 
> No the prestera family of devices are considerably more powerful (and 
> complex) than the linkstreet devices.

I see, we have a similar situation with some of the Broadcom SoCs, the
BCM534xx/BCM5334x have a completely different integrated switching
engine that is not roboswitch compatible.

Thanks for the information, this is still valuable to have this
supported upstream.
-- 
Florian

^ permalink raw reply

* Re: [PATCHv2 0/5] Support for Marvell switches with integrated CPUs
From: Chris Packham @ 2017-01-05 19:46 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Florian Fainelli, linux-arm-kernel@lists.infradead.org,
	Rob Herring, Mark Rutland, Michael Turquette, Stephen Boyd,
	Linus Walleij, Jason Cooper, Gregory Clement,
	Sebastian Hesselbarth, Russell King, Geert Uytterhoeven,
	Arnd Bergmann, Thierry Reding, Sudeep Holla, Juri Lelli,
	Thomas Petazzoni, Laxman
In-Reply-To: <20170105130945.GA18033@lunn.ch>

On 06/01/17 02:10, Andrew Lunn wrote:
>> I'd love to see a switchdev driver but it's a huge task (and no I'm not
>> committing to writing it). As it stands Marvell ship a switch SDK
>> largely executes in userspace with a small kernel module providing some
>> linkage to the underlying hardware.
>
> Is there any similarity to the mv88e6xxx family?
>
> If it was similar registers, just a different access mechanising, we
> could probably extend the mv88e6xxx to support MMIO as well as MDIO.

No the prestera family of devices are considerably more powerful (and 
complex) than the linkstreet devices.

^ permalink raw reply

* Re: [PATCH v2] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Krzysztof Kozlowski @ 2017-01-05 19:40 UTC (permalink / raw)
  To: Javier Martinez Canillas
  Cc: Mark Rutland, devicetree@vger.kernel.org, Thomas Abraham,
	Bartlomiej Zolnierkiewicz, Ben Gamari,
	linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	Doug Anderson, Krzysztof Kozlowski, Russell King,
	linux-samsung-soc, Rob Herring, Kukjin Kim, Arjun K V,
	Andreas Faerber, linux-arm-kernel@lists.infradead.org
In-Reply-To: <2c85559a-dc12-610b-c842-c89d078e1c2a@osg.samsung.com>

On Wed, Jan 04, 2017 at 08:57:47PM -0300, Javier Martinez Canillas wrote:
> Hello Doug,
> 
> On 01/04/2017 06:05 PM, Doug Anderson wrote:
> > Hi,
> > 
> > On Thu, Dec 29, 2016 at 6:17 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >> On Thu, Dec 15, 2016 at 04:54:30PM -0800, Doug Anderson wrote:
> >>>> Index: b/arch/arm/boot/dts/exynos5800.dtsi
> >>>> ===================================================================
> >>>> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-15 12:43:54.365955950 +0100
> >>>> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-15 12:43:54.361955949 +0100
> >>>> @@ -24,6 +24,16 @@
> >>>>  };
> >>>>
> >>>>  &cluster_a15_opp_table {
> >>>> +       opp@2000000000 {
> >>>> +               opp-hz = /bits/ 64 <2000000000>;
> >>>> +               opp-microvolt = <1250000>;
> >>>> +               clock-latency-ns = <140000>;
> >>>> +       };
> >>>> +       opp@1900000000 {
> >>>> +               opp-hz = /bits/ 64 <1900000000>;
> >>>> +               opp-microvolt = <1250000>;
> >>>> +               clock-latency-ns = <140000>;
> >>>> +       };
> >>>
> >>> I don't think the voltages you listed are high enough for all peach pi
> >>> boards for A15 at 1.9 GHz and 2.0 GHz, at least based on the research
> >>> I did.  See my response to v1.
> >>
> >> I wanted to apply this but saw this remaining issue. Javier tested it
> >> on Peach Pi so is this concern still valid?
> > 
> > I'm not sure.  It's been years since I did anything with exynos, so I
> > won't stand in the way if everyone else agrees that this patch is
> > good, but I will point out that testing on a single Peach Pi board is
> > not really enough given the massive difference in voltage needed
> > between the highest ASV group and the lowest (a whopping 112.5 mV from
> > looking in the Chrome OS source tree).
> > 
> 
> I agree. That's why answered that I wasn't able to find regressions on the
> Peach Pi I've access to, but I couldn't provide a Reviewed-by tag since it
> wasn't clear to me that the values were safe for any Exynos5420/5422/5800.

The value of 1.250 V seems to be covering only half of ASV values for
2.0 GHz so indeed it might be insufficient for some of the chips.
Unfortunately...

Best regards,
Krzysztof

^ permalink raw reply

* [PATCH v2 8/8] ARM: dts: kirkwood-rd88f6281: Utilize new DSA binding
From: Florian Fainelli @ 2017-01-05 19:29 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: Florian Fainelli, Jason Cooper, Andrew Lunn, Gregory Clement,
	Sebastian Hesselbarth, Rob Herring, Mark Rutland, Russell King,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	open list, vivien.didelot
In-Reply-To: <20170105192957.14304-1-f.fainelli@gmail.com>

Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net: dsa:
Document new binding"). The legacy binding node is kept included, but is marked
disabled.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 arch/arm/boot/dts/kirkwood-rd88f6281-z0.dts | 11 ++++++++
 arch/arm/boot/dts/kirkwood-rd88f6281.dtsi   | 44 +++++++++++++++++++++++++++++
 2 files changed, 55 insertions(+)

diff --git a/arch/arm/boot/dts/kirkwood-rd88f6281-z0.dts b/arch/arm/boot/dts/kirkwood-rd88f6281-z0.dts
index 1a797381d3d4..6a4a65ec7944 100644
--- a/arch/arm/boot/dts/kirkwood-rd88f6281-z0.dts
+++ b/arch/arm/boot/dts/kirkwood-rd88f6281-z0.dts
@@ -33,3 +33,14 @@
 &eth1 {
       status = "disabled";
 };
+
+&switch {
+	reg = <0>;
+
+	ports {
+		port@4 {
+			reg = <4>;
+			label = "wan";
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-rd88f6281.dtsi b/arch/arm/boot/dts/kirkwood-rd88f6281.dtsi
index d5aacf137e40..91f5da5dae5f 100644
--- a/arch/arm/boot/dts/kirkwood-rd88f6281.dtsi
+++ b/arch/arm/boot/dts/kirkwood-rd88f6281.dtsi
@@ -54,6 +54,8 @@
 	};
 
 	dsa {
+		status = "disabled";
+
 		compatible = "marvell,dsa";
 		#address-cells = <2>;
 		#size-cells = <0>;
@@ -115,6 +117,48 @@
 
 &mdio {
 	status = "okay";
+
+	switch: switch@0 {
+		compatible = "marvell,mv88e6085";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+				label = "lan1";
+			};
+
+			port@1 {
+				reg = <1>;
+				label = "lan2";
+			};
+
+			port@2 {
+				reg = <2>;
+				label = "lan3";
+			};
+
+			port@3 {
+				reg = <3>;
+				label = "lan4";
+			};
+
+			port@5 {
+				reg = <5>;
+				label = "cpu";
+				ethernet = <&eth0port>;
+				fixed-link {
+					speed = <1000>;
+					full-duplex;
+				};
+			};
+
+		};
+	};
 };
 
 &eth0 {
-- 
2.9.3

^ permalink raw reply related

* [PATCH v2 7/8] ARM: dts: kirkwood-mv88f6281gtw-ge: Utilize new DSA binding
From: Florian Fainelli @ 2017-01-05 19:29 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: Florian Fainelli, Jason Cooper, Andrew Lunn, Gregory Clement,
	Sebastian Hesselbarth, Rob Herring, Mark Rutland, Russell King,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	open list, vivien.didelot
In-Reply-To: <20170105192957.14304-1-f.fainelli@gmail.com>

Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net: dsa:
Document new binding"). The legacy binding node is kept included, but is marked
disabled.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts | 49 ++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)

diff --git a/arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts b/arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts
index 172a38c0b8a9..327023a477b8 100644
--- a/arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts
+++ b/arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts
@@ -112,6 +112,8 @@
 	};
 
 	dsa {
+		status = "disabled";
+
 		compatible = "marvell,dsa";
 		#address-cells = <1>;
 		#size-cells = <0>;
@@ -159,6 +161,53 @@
 
 &mdio {
 	status = "okay";
+
+	switch@0 {
+		compatible = "marvell,mv88e6085";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+				label = "lan1";
+			};
+
+			port@1 {
+				reg = <1>;
+				label = "lan2";
+			};
+
+			port@2 {
+				reg = <2>;
+				label = "lan3";
+			};
+
+			port@3 {
+				reg = <3>;
+				label = "lan4";
+			};
+
+			port@4 {
+				reg = <4>;
+				label = "wan";
+			};
+
+			port@5 {
+				reg = <5>;
+				label = "cpu";
+				ethernet = <&eth0port>;
+				fixed-link {
+					speed = <1000>;
+					full-duplex;
+				};
+			};
+		};
+	};
 };
 
 &eth0 {
-- 
2.9.3

^ permalink raw reply related

* [PATCH v2 6/8] ARM: dts: kirkwood-linksys-viper: Utilize new DSA binding
From: Florian Fainelli @ 2017-01-05 19:29 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: Florian Fainelli, Jason Cooper, Andrew Lunn, Gregory Clement,
	Sebastian Hesselbarth, Rob Herring, Mark Rutland, Russell King,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	open list, vivien.didelot
In-Reply-To: <20170105192957.14304-1-f.fainelli@gmail.com>

Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net: dsa:
Document new binding"). The legacy binding node is kept included, but is marked
disabled.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 arch/arm/boot/dts/kirkwood-linksys-viper.dts | 49 ++++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)

diff --git a/arch/arm/boot/dts/kirkwood-linksys-viper.dts b/arch/arm/boot/dts/kirkwood-linksys-viper.dts
index 345fcac48dc7..df7851820507 100644
--- a/arch/arm/boot/dts/kirkwood-linksys-viper.dts
+++ b/arch/arm/boot/dts/kirkwood-linksys-viper.dts
@@ -70,6 +70,8 @@
 	};
 
 	dsa {
+		status = "disabled";
+
 		compatible = "marvell,dsa";
 		#address-cells = <2>;
 		#size-cells = <0>;
@@ -207,6 +209,53 @@
 
 &mdio {
 	status = "okay";
+
+	switch@10 {
+		compatible = "marvell,mv88e6085";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <16>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+				label = "ethernet1";
+			};
+
+			port@1 {
+				reg = <1>;
+				label = "ethernet2";
+			};
+
+			port@2 {
+				reg = <2>;
+				label = "ethernet3";
+			};
+
+			port@3 {
+				reg = <3>;
+				label = "ethernet4";
+			};
+
+			port@4 {
+				reg = <4>;
+				label = "internet";
+			};
+
+			port@5 {
+				reg = <5>;
+				label = "cpu";
+				ethernet = <&eth0port>;
+				fixed-link {
+					speed = <1000>;
+					full-duplex;
+				};
+			};
+		};
+	};
 };
 
 &uart0 {
-- 
2.9.3

^ permalink raw reply related

* [PATCH v2 5/8] ARM: dts: kirkwood-dir665: Utilize new DSA binding
From: Florian Fainelli @ 2017-01-05 19:29 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: Florian Fainelli, Jason Cooper, Andrew Lunn, Gregory Clement,
	Sebastian Hesselbarth, Rob Herring, Mark Rutland, Russell King,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	open list, vivien.didelot
In-Reply-To: <20170105192957.14304-1-f.fainelli@gmail.com>

Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net: dsa:
Document new binding"). The legacy binding node is kept included, but is marked
disabled.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 arch/arm/boot/dts/kirkwood-dir665.dts | 49 +++++++++++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)

diff --git a/arch/arm/boot/dts/kirkwood-dir665.dts b/arch/arm/boot/dts/kirkwood-dir665.dts
index 41acbb6dd6ab..4d2b15d6244a 100644
--- a/arch/arm/boot/dts/kirkwood-dir665.dts
+++ b/arch/arm/boot/dts/kirkwood-dir665.dts
@@ -194,6 +194,8 @@
 	};
 
 	dsa {
+		status = "disabled";
+
 		compatible = "marvell,dsa";
 		#address-cells = <2>;
 		#size-cells = <0>;
@@ -241,6 +243,53 @@
 
 &mdio {
 	status = "okay";
+
+	switch@0 {
+		compatible = "marvell,mv88e6085";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+				label = "lan4";
+			};
+
+			port@1 {
+			       reg = <1>;
+			       label = "lan3";
+			};
+
+			port@2 {
+			       reg = <2>;
+			       label = "lan2";
+			};
+
+			port@3 {
+			       reg = <3>;
+			       label = "lan1";
+			};
+
+			port@4 {
+				reg = <4>;
+				label = "wan";
+			};
+
+			port@6 {
+				reg = <6>;
+				label = "cpu";
+				ethernet = <&eth0port>;
+				fixed-link {
+					speed = <1000>;
+					full-duplex;
+				};
+			};
+		};
+	};
 };
 
 /* eth0 is connected to a Marvell 88E6171 switch, without a PHY. So set
-- 
2.9.3

^ permalink raw reply related

* [PATCH v2 4/8] ARM: dts: armada-xp-linksys-mamba: Utilize new DSA binding
From: Florian Fainelli @ 2017-01-05 19:29 UTC (permalink / raw)
  To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
  Cc: Florian Fainelli, Jason Cooper, Andrew Lunn, Gregory Clement,
	Sebastian Hesselbarth, Rob Herring, Mark Rutland, Russell King,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	open list, vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/
In-Reply-To: <20170105192957.14304-1-f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net: dsa:
Document new binding"). The legacy binding node is kept included, but is marked
disabled.

Signed-off-by: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 arch/arm/boot/dts/armada-xp-linksys-mamba.dts | 53 +++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp-linksys-mamba.dts b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
index 83ac884c0f8a..42ea8764814c 100644
--- a/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
+++ b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
@@ -302,6 +302,8 @@
 	};
 
 	dsa {
+		status = "disabled";
+
 		compatible = "marvell,dsa";
 		#address-cells = <2>;
 		#size-cells = <0>;
@@ -398,3 +400,54 @@
 		spi-max-frequency = <40000000>;
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	switch@0 {
+		compatible = "marvell,mv88e6085";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+				label = "lan4";
+			};
+
+			port@1 {
+				reg = <1>;
+				label = "lan3";
+			};
+
+			port@2 {
+				reg = <2>;
+				label = "lan2";
+			};
+
+			port@3 {
+				reg = <3>;
+				label = "lan1";
+			};
+
+			port@4 {
+				reg = <4>;
+				label = "internet";
+			};
+
+			port@5 {
+				reg = <5>;
+				label = "cpu";
+				ethernet = <&eth0>;
+				fixed-link {
+					speed = <1000>;
+					full-duplex;
+				};
+			};
+		};
+	};
+};
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related

* [PATCH v2 3/8] ARM: dts: armada-388-clearfog: Utilize new DSA binding
From: Florian Fainelli @ 2017-01-05 19:29 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: Mark Rutland, Andrew Lunn, Florian Fainelli, Jason Cooper,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	vivien.didelot, Russell King, open list, Rob Herring,
	Gregory Clement, Sebastian Hesselbarth
In-Reply-To: <20170105192957.14304-1-f.fainelli@gmail.com>

Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net:
dsa: Document new binding"). The legacy binding node is kept included, but is
marked disabled.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 arch/arm/boot/dts/armada-388-clearfog.dts | 65 +++++++++++++++++++++++++++++++
 1 file changed, 65 insertions(+)

diff --git a/arch/arm/boot/dts/armada-388-clearfog.dts b/arch/arm/boot/dts/armada-388-clearfog.dts
index 71ce201c903e..40ec6d768669 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dts
+++ b/arch/arm/boot/dts/armada-388-clearfog.dts
@@ -351,6 +351,8 @@
 	};
 
 	dsa@0 {
+		status = "disabled";
+
 		compatible = "marvell,dsa";
 		dsa,ethernet = <&eth1>;
 		dsa,mii-bus = <&mdio>;
@@ -444,3 +446,66 @@
 		status = "disabled";
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	switch@4 {
+		compatible = "marvell,mv88e6085";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <4>;
+		pinctrl-0 = <&clearfog_dsa0_clk_pins &clearfog_dsa0_pins>;
+		pinctrl-names = "default";
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+				label = "lan5";
+			};
+
+			port@1 {
+				reg = <1>;
+				label = "lan4";
+			};
+
+			port@2 {
+				reg = <2>;
+				label = "lan3";
+			};
+
+			port@3 {
+				reg = <3>;
+				label = "lan2";
+			};
+
+			port@4 {
+				reg = <4>;
+				label = "lan1";
+			};
+
+			port@5 {
+				reg = <5>;
+				label = "cpu";
+				ethernet = <&eth1>;
+				fixed-link {
+					speed = <1000>;
+					full-duplex;
+				};
+			};
+
+			port@6 {
+				/* 88E1512 external phy */
+				reg = <6>;
+				label = "lan6";
+				fixed-link {
+					speed = <1000>;
+					full-duplex;
+				};
+			};
+		};
+	};
+};
-- 
2.9.3

^ permalink raw reply related

* [PATCH v2 2/8] ARM: dts: armada-385-linksys: Utilize new DSA binding
From: Florian Fainelli @ 2017-01-05 19:29 UTC (permalink / raw)
  To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
  Cc: Florian Fainelli, Jason Cooper, Andrew Lunn, Gregory Clement,
	Sebastian Hesselbarth, Rob Herring, Mark Rutland, Russell King,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	open list, vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/
In-Reply-To: <20170105192957.14304-1-f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net: dsa:
Document new binding"). The legacy binding node is kept included, but is marked
disabled.

Signed-off-by: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 arch/arm/boot/dts/armada-385-linksys.dtsi | 52 ++++++++++++++++++++++++++++++-
 1 file changed, 51 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/armada-385-linksys.dtsi b/arch/arm/boot/dts/armada-385-linksys.dtsi
index 8f0e508f64ae..20d5e8b00f2d 100644
--- a/arch/arm/boot/dts/armada-385-linksys.dtsi
+++ b/arch/arm/boot/dts/armada-385-linksys.dtsi
@@ -103,8 +103,56 @@
 				};
 			};
 
-			mdio {
+			mdio@72004 {
 				status = "okay";
+
+				switch@0 {
+					compatible = "marvell,mv88e6095";
+					#address-cells = <1>;
+					#size-cells = <0>;
+					reg = <0>;
+
+					ports {
+						#address-cells = <1>;
+						#size-cells = <0>;
+
+						port@0 {
+							reg = <0>;
+							label = "lan4";
+						};
+
+						port@1 {
+							reg = <1>;
+							label = "lan3";
+						};
+
+						port@2 {
+							reg = <2>;
+							label = "lan2";
+						};
+
+						port@3 {
+							reg = <3>;
+							label = "lan1";
+						};
+
+						port@4 {
+							reg = <4>;
+							label = "wan";
+						};
+
+						port@5 {
+							reg = <5>;
+							label = "cpu";
+							ethernet = <&eth2>;
+
+							fixed-link {
+								speed = <1000>;
+								full-duplex;
+							};
+						};
+					};
+				};
 			};
 
 			sata@a8000 {
@@ -261,6 +309,8 @@
 	};
 
 	dsa@0 {
+		status = "disabled";
+
 		compatible = "marvell,dsa";
 		#address-cells = <2>;
 		#size-cells = <0>;
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related

* [PATCH v2 1/8] ARM: dts: armada-370-rd: Utilize new DSA binding
From: Florian Fainelli @ 2017-01-05 19:29 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: Mark Rutland, Andrew Lunn, Florian Fainelli, Jason Cooper,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	vivien.didelot, Russell King, open list, Rob Herring,
	Gregory Clement, Sebastian Hesselbarth
In-Reply-To: <20170105192957.14304-1-f.fainelli@gmail.com>

Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net: dsa:
Document new binding"). The legacy binding node is kept included, but is marked
disabled.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 arch/arm/boot/dts/armada-370-rd.dts | 44 +++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts
index c3fd6e49212f..ade956cbd41a 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -173,6 +173,8 @@
 	};
 
 	dsa {
+		status = "disabled";
+
 		compatible = "marvell,dsa";
 		#address-cells = <2>;
 		#size-cells = <0>;
@@ -235,6 +237,48 @@
 	phy0: ethernet-phy@0 {
 		reg = <0>;
 	};
+
+	switch: switch@10 {
+		compatible = "marvell,mv88e6085";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0x10>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+				label = "lan0";
+			};
+
+			port@1 {
+			       reg = <1>;
+			       label = "lan1";
+			};
+
+			port@2 {
+			       reg = <2>;
+			       label = "lan2";
+			};
+
+			port@3 {
+			       reg = <3>;
+			       label = "lan3";
+			};
+
+			port@5 {
+				reg = <5>;
+				label = "cpu";
+				ethernet = <&eth1>;
+				fixed-link {
+					speed = <1000>;
+					full-duplex;
+				};
+			};
+		};
+	};
 };
 
 
-- 
2.9.3

^ permalink raw reply related

* [PATCH v2 0/8] ARM: dts: Switch to new DSA binding
From: Florian Fainelli @ 2017-01-05 19:29 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: Mark Rutland, Andrew Lunn, Florian Fainelli, Jason Cooper,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	vivien.didelot, Russell King, open list, Rob Herring,
	Gregory Clement, Sebastian Hesselbarth

Hi all,

This patch series converts the in-tree users to utilize the new (relatively)
DSA binding that was introduced with commit 8c5ad1d6179d ("net: dsa: Document
new binding"). The legacy binding node is kept included, but is marked
disabled.

Changes in v2:

- patch 1: Use an hexadecimal reg property
- patch 2: fixed the subject
- patch 3: s/okay/disabled/ for the legacy DSA node
- patches 7/8: fixed a stray whitespace

In about 2-3 releases we may consider removing the old DSA binding entirely
from the kernel.

Thank you!

Florian Fainelli (8):
  ARM: dts: armada-370-rd: Utilize new DSA binding
  ARM: dts: armada-385-linksys: Utilize new DSA binding
  ARM: dts: armada-388-clearfog: Utilize new DSA binding
  ARM: dts: armada-xp-linksys-mamba: Utilize new DSA binding
  ARM: dts: kirkwood-dir665: Utilize new DSA binding
  ARM: dts: kirkwood-linksys-viper: Utilize new DSA binding
  ARM: dts: kirkwood-mv88f6281gtw-ge: Utilize new DSA binding
  ARM: dts: kirkwood-rd88f6281: Utilize new DSA binding

 arch/arm/boot/dts/armada-370-rd.dts            | 44 +++++++++++++++++
 arch/arm/boot/dts/armada-385-linksys.dtsi      | 52 ++++++++++++++++++++-
 arch/arm/boot/dts/armada-388-clearfog.dts      | 65 ++++++++++++++++++++++++++
 arch/arm/boot/dts/armada-xp-linksys-mamba.dts  | 53 +++++++++++++++++++++
 arch/arm/boot/dts/kirkwood-dir665.dts          | 49 +++++++++++++++++++
 arch/arm/boot/dts/kirkwood-linksys-viper.dts   | 49 +++++++++++++++++++
 arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts | 49 +++++++++++++++++++
 arch/arm/boot/dts/kirkwood-rd88f6281-z0.dts    | 11 +++++
 arch/arm/boot/dts/kirkwood-rd88f6281.dtsi      | 44 +++++++++++++++++
 9 files changed, 415 insertions(+), 1 deletion(-)

-- 
2.9.3

^ permalink raw reply

* Re: [PATCH v2 04/19] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors
From: Steve Longerbeam @ 2017-01-05 19:20 UTC (permalink / raw)
  To: Vladimir Zapolskiy, shawnguo, kernel, fabio.estevam, robh+dt,
	mark.rutland, linux, mchehab, gregkh, p.zabel
  Cc: devel, devicetree, Steve Longerbeam, linux-kernel,
	linux-arm-kernel, linux-media
In-Reply-To: <0a343705-1d38-9fe2-6419-56ab9bdfb0c2@mentor.com>

Hi Vladimir,


On 01/04/2017 04:25 AM, Vladimir Zapolskiy wrote:
> Hi Steve,
>
> On 01/03/2017 10:57 PM, Steve Longerbeam wrote:
>> Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor.
>> Both hang off the same i2c2 bus, so they require different (and non-
>> default) i2c slave addresses.
>>
>> The OV5642 connects to the parallel-bus mux input port on ipu1_csi0_mux.
>>
>> The OV5640 connects to the input port on the MIPI CSI-2 receiver on
>> mipi_csi. It is set to transmit over MIPI virtual channel 1.
>>
>> Note there is a pin conflict with GPIO6. This pin functions as a power
>> input pin to the OV5642, but ENET uses it as the h/w workaround for
>> erratum ERR006687, to wake-up the ARM cores on normal RX and TX packet
>> done events (see 6261c4c8). So workaround 6261c4c8 is reverted here to
>> support the OV5642, and the "fsl,err006687-workaround-present" boolean
>> also must be removed. The result is that the CPUidle driver will no longer
>> allow entering the deep idle states on the sabrelite.
> For me it sounds like a candidate of its own separate change.

Yes, I split out the two partial reverts into a separate commit
("ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687
  workaround").

>
>
>
>> +
>> +	mipi_camera: ov5640@40 {
> Please reorder device nodes by address value,

done.

>   also according to ePAPR
> node names should be generic, labels can be specific:
>
> 	ov5640: camera@40 {
> 		...
> 	};
>
> 	ov5642: camera@42 {
> 		...
> 	};

fixed.

>
>> +		pinctrl_ipu1_csi0: ipu1grp-csi0 {
> Please rename node name to ipu1csi0grp.

done.

>
>> +
>> +                pinctrl_ov5640: ov5640grp {
>> +                        fsl,pins = <
>> +				MX6QDL_PAD_NANDF_D5__GPIO2_IO05 0x000b0
>> +				MX6QDL_PAD_NANDF_WP_B__GPIO6_IO09 0x0b0b0
>> +                        >;
>> +                };
>> +
> Indentation issues above, please use tabs instead of spaces.

fixed.

>
> Also please add new pin control groups preserving the alphanimerical order.

done.

Steve

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox