Received: by 10.223.176.5 with SMTP id f5csp206595wra; Thu, 8 Feb 2018 19:56:48 -0800 (PST) X-Google-Smtp-Source: AH8x2262S+1Rg4Ms6W/iGlWI6GAlPFtw2NPe8OuOEO7ewVeFfKYAHgMs874jtvt+mSSKHuyJvOws X-Received: by 2002:a17:902:6c44:: with SMTP id h4-v6mr1226523pln.373.1518148607783; Thu, 08 Feb 2018 19:56:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518148607; cv=none; d=google.com; s=arc-20160816; b=jJapY3IHNzAI/wZeO9s3SXx3fH7VJypWmQw2o2qnkOnln+RPZZzBngjjS07RReaCr2 syzYtvzBZmjvVrenj1Si9tzICfEXuLxUebclaXmuI1bLTS0GlQHK09miiSs5R1fiYliR IuPd4eDcOMqLr2P+aW77ESJ4sAV4KS7zvDMh4W5oIR4a11nlrNP1GDRCl3hlmUc2WoGI 8zCp3UF67rsniikperaW23NHCeqnVtUujNPOF9fVSWO6bdplZTmPVZoCSJSM96si2Csm hMvmlqSbCsHKgyeCi1rUr0vKCroiD/vGLUInjtiftjML80+Tj4sAkfT6YlnxtbPb2ANA gNUw== 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=Ve1tFZi6nOJZaxb5mH8oGu0DboCjQTm5Pi4TK5/43kM=; b=zQJrXtAXhC3PMj35K4Ad80m96KFT5G2+fO9bsDZOCWm3NdxdORV0Y3P4sluD4zDMY5 F5rFtugIUBfEurjaIM5I2xSLs1zH/SDv7sGI0KLZMo1THtnNPkJEWNNyf3GsEWoU+csX /MjQt6wiuI6f+mceqftA5/zkuK1cqPHa7Wmx4FQuRbS2XmRuybmxnx3uBKPsIkgGSGV2 rvDGSH4qDTL9key9vJGZtfLH6DUADZiEQ7Td6R6rNhWV80zi6KeJXAwGceOrJA/oq5fL 8FjW/gnPkPFmxLx+bqbpKZsiebA9QR/VBta4ms2xB7KWkmC2ZOUuKOh+p5b5cUE7hBwn GPtA== 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 l7-v6si977791pls.728.2018.02.08.19.56.33; Thu, 08 Feb 2018 19:56:47 -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 S1752573AbeBIDzx (ORCPT + 99 others); Thu, 8 Feb 2018 22:55:53 -0500 Received: from mailgw01.mediatek.com ([210.61.82.183]:28943 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1752201AbeBIDzv (ORCPT ); Thu, 8 Feb 2018 22:55:51 -0500 X-UUID: a7b7c364dd934e4893c164b8fb084c4a-20180209 Received: from mtkcas09.mediatek.inc [(172.21.101.178)] by mailgw01.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 1783592817; Fri, 09 Feb 2018 11:55:47 +0800 Received: from mtkcas08.mediatek.inc (172.21.101.126) by mtkmbs03n2.mediatek.inc (172.21.101.182) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 9 Feb 2018 11:55:46 +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; Fri, 9 Feb 2018 11:55:46 +0800 Message-ID: <1518148546.9025.20.camel@mtkswgap22> Subject: Re: [PATCH] arm: dts: mt7623: enable all four available UARTs on bananapi-r2 From: Sean Wang To: Matthias Brugger CC: , , , , , Date: Fri, 9 Feb 2018 11:55:46 +0800 In-Reply-To: References: <1514043318.30687.10.camel@mtkswgap22> <1516697505.12197.30.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 Wed, 2018-02-07 at 17:01 +0100, Matthias Brugger wrote: > > On 01/23/2018 09:51 AM, Sean Wang wrote: > > 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. > > > > Sorry for the late answer. > Do I understand correctly that uart3 is routed to TP47 and TP48, and these test > points are accessible through the SATA connector? Doesn't they break SATA then? > TP47 and TP48 are directly pins out from SoC, not through the SATA connector. > I think as they are only available through a non-documented test point, we > shouldn't enable it. > Okay, let's drop uart 3 setting here. > Regards, > Matthias