Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1662384 > unrolled thread

[PATCH v2] arm64: allwinner: a64: Add initial NanoPi A64 support

Started byJagan Teki <jagannadh.teki@gmail.com>
First post2017-06-09 14:50 +0200
Last post2017-06-10 22:30 +0200
Articles 6 — 5 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  [PATCH v2] arm64: allwinner: a64: Add initial NanoPi A64 support Jagan Teki <jagannadh.teki@gmail.com> - 2017-06-09 14:50 +0200
    Re: [PATCH v2] arm64: allwinner: a64: Add initial NanoPi A64 support Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-06-09 17:00 +0200
      Re: [linux-sunxi] Re: [PATCH v2] arm64: allwinner: a64: Add initial  NanoPi A64 support Jagan Teki <jagan@openedev.com> - 2017-06-09 17:30 +0200
        Re: [linux-sunxi] Re: [PATCH v2] arm64: allwinner: a64: Add initial  NanoPi A64 support Andre Przywara <andre.przywara@arm.com> - 2017-06-09 17:40 +0200
          Re: [linux-sunxi] Re: [PATCH v2] arm64: allwinner: a64: Add initial  NanoPi A64 support Andreas Färber <afaerber@suse.de> - 2017-06-09 19:40 +0200
          Re: [linux-sunxi] Re: [PATCH v2] arm64: allwinner: a64: Add initial  NanoPi A64 support Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-06-10 22:30 +0200

#1662384 — [PATCH v2] arm64: allwinner: a64: Add initial NanoPi A64 support

FromJagan Teki <jagannadh.teki@gmail.com>
Date2017-06-09 14:50 +0200
Subject[PATCH v2] arm64: allwinner: a64: Add initial NanoPi A64 support
Message-ID<tQrwu-1Aq-17@gated-at.bofh.it>
From: Jagan Teki <jagan@amarulasolutions.com>

NanoPi A64 is a new board of high performance with low cost
designed by FriendlyElec., using the Allwinner A64 SOC.

Nanopi A64 features
- Allwinner A64, 64-bit Quad-core Cortex-A53@648MHz to 1.152GHz, DVFS
- 1GB DDR3 RAM
- MicroSD
- Gigabit Ethernet (RTL8211E)
- Wi-Fi 802.11b/g/n
- IR receiver
- Audio In/Out
- Video In/Out
- Serial Debug Port
- microUSB 5V 2A DC power-supply

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v2:
- Added ohci0, ehci0, ohic1, ehci1, usbphy.
- Tested on A64

 arch/arm64/boot/dts/allwinner/Makefile             |   1 +
 .../boot/dts/allwinner/sun50i-a64-nanopi-a64.dts   | 131 +++++++++++++++++++++
 2 files changed, 132 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts

diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index e7d5490..1ea7709 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-bananapi-m64.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-nanopi-a64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
new file mode 100644
index 0000000..aa0b17c
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
@@ -0,0 +1,131 @@
+/*
+ * Copyright (C) 2017 Jagan Teki <jteki@openedev.com>
+ *
+ * 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 library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+	model = "FriendlyARM NanoPi A64";
+	compatible = "friendlyarm,nanopi-a64", "allwinner,sun50i-a64";
+
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	reg_vcc3v3: vcc3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+	};
+};
+
+&ehci0 {
+	status = "okay";
+};
+
+&ehci1 {
+	status = "okay";
+};
+
+&i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c1_pins>;
+	status = "okay";
+};
+
+&i2c1_pins {
+	bias-pull-up;
+};
+
+&mmc0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc0_pins>;
+	vmmc-supply = <&reg_vcc3v3>;
+	cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
+	cd-inverted;
+	disable-wp;
+	bus-width = <4>;
+	status = "okay";
+};
+
+&mmc2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc2_pins>;
+	vmmc-supply = <&reg_vcc3v3>;
+	bus-width = <8>;
+	non-removable;
+	cap-mmc-hw-reset;
+	status = "okay";
+};
+
+&ohci0 {
+	status = "okay";
+};
+
+&ohci1 {
+	status = "okay";
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_pins_a>;
+	status = "okay";
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
+	status = "okay";
+};
+
+&usbphy {
+	status = "okay";
+};
-- 
1.9.1

[toc] | [next] | [standalone]


#1662542

FromMaxime Ripard <maxime.ripard@free-electrons.com>
Date2017-06-09 17:00 +0200
Message-ID<tQtyh-2Qa-7@gated-at.bofh.it>
In reply to#1662384

[Multipart message — attachments visible in raw view] — view raw

Hi Jagan,

On Fri, Jun 09, 2017 at 12:40:52PM +0000, Jagan Teki wrote:
> +&i2c1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c1_pins>;
> +	status = "okay";
> +};
> +
> +&i2c1_pins {
> +	bias-pull-up;
> +};

What is connected on that bus?

> +&uart1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
> +	status = "okay";
> +};

And on that UART?

Maxime

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

[toc] | [prev] | [next] | [standalone]


#1662552 — Re: [linux-sunxi] Re: [PATCH v2] arm64: allwinner: a64: Add initial NanoPi A64 support

FromJagan Teki <jagan@openedev.com>
Date2017-06-09 17:30 +0200
SubjectRe: [linux-sunxi] Re: [PATCH v2] arm64: allwinner: a64: Add initial NanoPi A64 support
Message-ID<tQu1j-3gb-9@gated-at.bofh.it>
In reply to#1662542
On Friday 09 June 2017 08:21 PM, Maxime Ripard wrote:
> Hi Jagan,
> 
> On Fri, Jun 09, 2017 at 12:40:52PM +0000, Jagan Teki wrote:
>> +&i2c1 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&i2c1_pins>;
>> +	status = "okay";
>> +};
>> +
>> +&i2c1_pins {
>> +	bias-pull-up;
>> +};
> 
> What is connected on that bus?

i2c1 connected with gpio/i2s

> 
>> +&uart1 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
>> +	status = "okay";
>> +};
> 
> And on that UART?

uart1 for SDIO (Wifi connector, with RTS/CTS), this along with mmc1

Jagan.

[toc] | [prev] | [next] | [standalone]


#1662555 — Re: [linux-sunxi] Re: [PATCH v2] arm64: allwinner: a64: Add initial NanoPi A64 support

FromAndre Przywara <andre.przywara@arm.com>
Date2017-06-09 17:40 +0200
SubjectRe: [linux-sunxi] Re: [PATCH v2] arm64: allwinner: a64: Add initial NanoPi A64 support
Message-ID<tQuaZ-3k4-1@gated-at.bofh.it>
In reply to#1662552
Hi,

On 09/06/17 16:26, Jagan Teki wrote:
> On Friday 09 June 2017 08:21 PM, Maxime Ripard wrote:
>> Hi Jagan,
>>
>> On Fri, Jun 09, 2017 at 12:40:52PM +0000, Jagan Teki wrote:
>>> +&i2c1 {
>>> +    pinctrl-names = "default";
>>> +    pinctrl-0 = <&i2c1_pins>;
>>> +    status = "okay";
>>> +};
>>> +
>>> +&i2c1_pins {
>>> +    bias-pull-up;
>>> +};
>>
>> What is connected on that bus?
> 
> i2c1 connected with gpio/i2s

Those are the I2C pins connected to the headers. We have them in the
other A64 DTs as well (Pine64, BananaPi).
If that is not the right approach, we should discuss this and keep it
consistent at least across the A64 boards.

>>
>>> +&uart1 {
>>> +    pinctrl-names = "default";
>>> +    pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
>>> +    status = "okay";
>>> +};
>>
>> And on that UART?
> 
> uart1 for SDIO (Wifi connector, with RTS/CTS), this along with mmc1

To be precise, UART1 (with h/w handshake) is connected to the Bluetooth
part of the WiFi/BT chip, which is soldered on that board. Regardless of
the actual *WiFi* support state BT should work already - at least it did
when I tried this a few months ago on the Pine64 (although this involved
some userland heavy lifting).
Not sure what the approach here is in regard to the power supply and
wake-up GPIOs, shall they be described in this node as well or is that
up for userspace to control?

Cheers,
Andre.

[toc] | [prev] | [next] | [standalone]


#1662644 — Re: [linux-sunxi] Re: [PATCH v2] arm64: allwinner: a64: Add initial NanoPi A64 support

FromAndreas Färber <afaerber@suse.de>
Date2017-06-09 19:40 +0200
SubjectRe: [linux-sunxi] Re: [PATCH v2] arm64: allwinner: a64: Add initial NanoPi A64 support
Message-ID<tQw38-4rY-7@gated-at.bofh.it>
In reply to#1662555
Hi,

Am 09.06.2017 um 17:36 schrieb Andre Przywara:
> On 09/06/17 16:26, Jagan Teki wrote:
>> On Friday 09 June 2017 08:21 PM, Maxime Ripard wrote:
>>> On Fri, Jun 09, 2017 at 12:40:52PM +0000, Jagan Teki wrote:
>>>> +&uart1 {
>>>> +    pinctrl-names = "default";
>>>> +    pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
>>>> +    status = "okay";
>>>> +};
>>>
>>> And [what is connected] on that UART?
>>
>> uart1 for SDIO (Wifi connector, with RTS/CTS), this along with mmc1
> 
> To be precise, UART1 (with h/w handshake) is connected to the Bluetooth
> part of the WiFi/BT chip, which is soldered on that board. Regardless of
> the actual *WiFi* support state BT should work already - at least it did
> when I tried this a few months ago on the Pine64 (although this involved
> some userland heavy lifting).
> Not sure what the approach here is in regard to the power supply and
> wake-up GPIOs, shall they be described in this node as well or is that
> up for userspace to control?

You should use a serdev based Bluetooth driver by adding a sub-node, and
it should take care of any reset GPIOs etc. for you. Question is which
driver is needed here and what state it is in.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

[toc] | [prev] | [next] | [standalone]


#1663007 — Re: [linux-sunxi] Re: [PATCH v2] arm64: allwinner: a64: Add initial NanoPi A64 support

FromMaxime Ripard <maxime.ripard@free-electrons.com>
Date2017-06-10 22:30 +0200
SubjectRe: [linux-sunxi] Re: [PATCH v2] arm64: allwinner: a64: Add initial NanoPi A64 support
Message-ID<tQVbb-3I0-1@gated-at.bofh.it>
In reply to#1662555

[Multipart message — attachments visible in raw view] — view raw

On Fri, Jun 09, 2017 at 04:36:09PM +0100, Andre Przywara wrote:
> Hi,
> 
> On 09/06/17 16:26, Jagan Teki wrote:
> > On Friday 09 June 2017 08:21 PM, Maxime Ripard wrote:
> >> Hi Jagan,
> >>
> >> On Fri, Jun 09, 2017 at 12:40:52PM +0000, Jagan Teki wrote:
> >>> +&i2c1 {
> >>> +    pinctrl-names = "default";
> >>> +    pinctrl-0 = <&i2c1_pins>;
> >>> +    status = "okay";
> >>> +};
> >>> +
> >>> +&i2c1_pins {
> >>> +    bias-pull-up;
> >>> +};
> >>
> >> What is connected on that bus?
> > 
> > i2c1 connected with gpio/i2s
> 
> Those are the I2C pins connected to the headers. We have them in the
> other A64 DTs as well (Pine64, BananaPi).

We've always had the policy of not enabling anything outside of the
board has been there from the very start, arm64 or not.

> If that is not the right approach, we should discuss this and keep it
> consistent at least across the A64 boards.

If some boards slipped through, then that would be on me I guess,
but it's (unfortunate) exceptions.

If you want to ease that for the users, you can have that node with
the pinctrl nodes pre-set, but leave it disabled. We have that on a
number of boards already.

> >>> +&uart1 {
> >>> +    pinctrl-names = "default";
> >>> +    pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
> >>> +    status = "okay";
> >>> +};
> >>
> >> And on that UART?
> > 
> > uart1 for SDIO (Wifi connector, with RTS/CTS), this along with mmc1
> 
> To be precise, UART1 (with h/w handshake) is connected to the Bluetooth
> part of the WiFi/BT chip, which is soldered on that board. Regardless of
> the actual *WiFi* support state BT should work already - at least it did
> when I tried this a few months ago on the Pine64 (although this involved
> some userland heavy lifting).
> Not sure what the approach here is in regard to the power supply and
> wake-up GPIOs, shall they be described in this node as well or is that
> up for userspace to control?

There's probably more to it though. Most BT chips require regulators
and clocks to be enabled. Ideally, this would even be a full DT node
for the bluetooth chip.

Maxime

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

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web