Received: by 10.223.176.46 with SMTP id f43csp3910116wra; Tue, 23 Jan 2018 00:52:29 -0800 (PST) X-Google-Smtp-Source: AH8x2268dQWBAtS0eDY5ReUhiS2dE+oxOtQyFTclgdDJ+3MfOEcBIo/wk5s69RAmQpHcWhh9Xw/A X-Received: by 10.99.96.23 with SMTP id u23mr7964833pgb.199.1516697549088; Tue, 23 Jan 2018 00:52:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516697549; cv=none; d=google.com; s=arc-20160816; b=eMWi/gWXq9XE4et7oWd6Zw0QmXLEBwro3HJaT7pHFpE+dpYgn0L+lLhcqfJMbfNT8b 7g9/d6m06/POMvu1UeyZCgod3prVqLyO+Ehi4NQOvA50fksl8mMJaWt3CKyHT2JOuxH5 NkdXjX+qvv+zLC4/7pHYIJteBg4P3DDAO3gh3mc8Ca4EnPyNsJMH54dTm8YEOurr/BCI SYkT1YXkSLMX3j+Xjwt+91kn4dFTzYRFJdVlsEREOiRNRKRx+zovXcfo4gVW2+7MqRAS /QpKFvoUJrWGjvxGzlY482SwzgcgZip/EIZDMFemFBYYLMH0+CPydJ9pT2K+eU3ZBAUg yc1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :references:in-reply-to:date:cc:to:from:subject:message-id :arc-authentication-results; bh=4EVN9CjjIDVrqH4/dAyelY6e/cwqbJnM48XDuRSgfiw=; b=NOGVqkzQQhPwaVklWnlXLSn2UuLiF0OQ3+UoHgTYyV/W5PH2fsYsOrEpSHGOqIsKKh W8grNZqt5EJUIS42uEkdZPHGNe2Gm9Y/EYx+mNSGTsHsPU2x2KAN1h2r/QLSBDhUTumZ OVMKjCYa8j8TFqXrR82kFyiOD5xB40otgqF2zMK78BhxOOVhqE8zbVJ9Nk0wOuTECTSc FRDweqwRSw/kvaC+bKyGPuxdAnq8HcrRR1xjyH7qv4B5KKccnznHwKqfT5ujtV8/3++O XTufwAchNOBI3OHFnEA1w/LyYfe2gX8ZikzNlYfI9r1ZesbKVwq6ZeLikBbA+oHfcpYI oDrg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d2-v6si4406521plo.114.2018.01.23.00.52.13; Tue, 23 Jan 2018 00:52:29 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751173AbeAWIvu (ORCPT + 99 others); Tue, 23 Jan 2018 03:51:50 -0500 Received: from mailgw02.mediatek.com ([210.61.82.184]:39458 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751086AbeAWIvt (ORCPT ); Tue, 23 Jan 2018 03:51:49 -0500 X-UUID: c1ad2498936a40aab03f1a7c27fc38dc-20180123 Received: from mtkcas08.mediatek.inc [(172.21.101.126)] by mailgw02.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 851278181; Tue, 23 Jan 2018 16:51:46 +0800 Received: from mtkcas08.mediatek.inc (172.21.101.126) by mtkmbs02n1.mediatek.inc (172.21.101.77) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 23 Jan 2018 16:51:45 +0800 Received: from [172.21.77.33] (172.21.77.33) by mtkcas08.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1210.3 via Frontend Transport; Tue, 23 Jan 2018 16:51:45 +0800 Message-ID: <1516697505.12197.30.camel@mtkswgap22> Subject: Re: [PATCH] arm: dts: mt7623: enable all four available UARTs on bananapi-r2 From: Sean Wang To: Matthias Brugger CC: , , , , , Date: Tue, 23 Jan 2018 16:51:45 +0800 In-Reply-To: <1514043318.30687.10.camel@mtkswgap22> References: <1514043318.30687.10.camel@mtkswgap22> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-MTK: N Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 2017-12-23 at 23:35 +0800, Sean Wang wrote: > On Sat, 2017-12-23 at 08:52 +0100, Matthias Brugger wrote: > > > > On 12/22/2017 07:06 AM, sean.wang@mediatek.com wrote: > > > From: Sean Wang > > > > > > On bpi-r2 board, totally there're four uarts which we usually called > > > uart[0-3] helpful to extend slow I/O devices. Among those ones, uart2 has > > > dedicated pin slot which is used to conolse log. uart[0-1] appear at the > > > 40-pins connector and uart3 has no pinout, but just has test points (TP47 > > > for TX and TP48 for RX, respectively) nearby uart2. Also, some missing > > > pinctrl is being complemented for those devices. > > > > > > Signed-off-by: Sean Wang > > > --- > > > arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 26 ++++++++++++++++++++++++-- > > > 1 file changed, 24 insertions(+), 2 deletions(-) > > > > > > diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts > > > index 7bf5aa2..64bf5db 100644 > > > --- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts > > > +++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts > > > @@ -409,6 +409,20 @@ > > > ; > > > };do you like it or quite want me to remove the uart3 node? > > > }; > > > + > > > + uart2_pins_a: uart@2 { > > > + pins_dat { > > > + pinmux = , > > > + ; > > > + }; > > > + }; > > > + > > > + uart3_pins_a: uart@3 { > > > + pins_dat { > > > + pinmux = , > > > + ; > > > + }; > > > + }; > > > }; > > > > > > &pwm { > > > @@ -454,16 +468,24 @@ > > > &uart0 { > > > pinctrl-names = "default"; > > > pinctrl-0 = <&uart0_pins_a>; > > > - status = "disabled"; > > > + status = "okay"; > > > }; > > > > > > &uart1 { > > > pinctrl-names = "default"; > > > pinctrl-0 = <&uart1_pins_a>; > > > - status = "disabled"; > > > + status = "okay"; > > > }; > > > > > > &uart2 { > > > + pinctrl-names = "default"; > > > + pinctrl-0 = <&uart2_pins_a>; > > > + status = "okay"; > > > +}; > > > + > > > +&uart3 { > > > + pinctrl-names = "default"; > > > + pinctrl-0 = <&uart3_pins_a>; > > > status = "okay"; > > > }; > > > > > > > Why do we want to enable uart3 when there are only test points? > > It is not very useful, or do I oversee something? > > > I have been listening to the sound from potential users of bpi-r2 to > understand what assistance I have to provide to them. Something could > be seen through [1] in the forum to know they had been trying hard to > explore all available UARTs from the SoC in the last weeks. The patch > should be really useful for these people and for the extra soldering > it shouldn't become a problem for these makers. > > [1] http://forum.banana-pi.org/t/gpio-uart-not-the-debug-port/3748 > > Sean > Hi, Matthias do you like it or quite want me to remove the uart3 node? I can take it into account along with other pending dts changes in my queue. Sean > > > Regards, > > Matthias > > >