devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Karl Beldan <kbeldan@baylibre.com>
To: Sekhar Nori <nsekhar@ti.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	devicetree@vger.kernel.org, karl.beldan+oss@gmail.com,
	Kevin Hilman <khilman@baylibre.com>,
	Russell King <linux@armlinux.org.uk>,
	Rob Herring <robh+dt@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] ARM: dts: da850: Add missing pin muxing for the UARTs
Date: Fri, 26 Aug 2016 17:17:18 +0000	[thread overview]
Message-ID: <20160826171718.GB20752@gobelin> (raw)
In-Reply-To: <a076cc95-d338-ec13-ba05-360c1857cda5@ti.com>

On Fri, Aug 26, 2016 at 05:55:23PM +0530, Sekhar Nori wrote:
> On Wednesday 24 August 2016 02:08 PM, Karl Beldan wrote:
> > On Tue, Aug 23, 2016 at 04:46:03PM +0530, Sekhar Nori wrote:
> >> On Tuesday 23 August 2016 04:39 PM, Sekhar Nori wrote:
> >>> On Friday 05 August 2016 04:30 AM, Kevin Hilman wrote:
> >>>> Karl Beldan <kbeldan@baylibre.com> writes:
> >>>>
> >>>>> On Thu, Aug 04, 2016 at 12:20:27PM -0700, Kevin Hilman wrote:
> >>>>>> Karl Beldan <kbeldan@baylibre.com> writes:
> >>>>>>
> >>>>>>> This adds 2 pinctrl groups (rtscts, rxtx) for each of the 3 UARTs.
> >>>>>>>
> >>>>>>> Signed-off-by: Karl Beldan <kbeldan@baylibre.com>
> >>>>>>
> >>>>>> Should da850-evm be updated to use the serial2_rxtx_pins also?
> >>>>>>
> >>>>> I could not find the EVM schematics on the net and I only have an LCDK,
> >>>>> but according to the code it should, however I can't tell whether flow
> >>>>> control pins are used.
> >>>>
> >>>> Ok, let's just leave it for now, since it's working fine.  Sekhar can
> >>>> fix that up if he can dig up the schematics.
> >>>
> >>> Looks like the flow control pins are being used for McASP also on the
> >>> EVM. So lets leave the EVM as-is.
> >>
> >> Rather, the EVM dts file should be updated to use serial2_rxtx_pins like
> >> the LCDK. Right now it seems to be relying on bootloader to serial2
> >> setup pimux correctly. I can make a patch to fix that. Or if you can do
> >> it, that will be great too.
> >>
> > 
> > Indeed ATM the EVM relies on the bootloader to setup the pin muxing.
> > 
> > I just checked the uart pins routing of the EVM, the dts:
> > - should reclaim serial2_rxtx_pins and serial2_rtscts_pins
> 
> Agree.
> 
> > - can reclaim serial1_rxtx_pins (out on Audio connector but very
> >   unlikely used for audio)
> 
> I would leave alone pins which are unused on the board. Most likely the
> SPI pins are being send to audio connector for codec control over SPI.
> 
> > - should leave serial1_rtscts_pins (out on Audio connector but used by
> >   McASP so used for audio)
> 
> Agree.
> 
> > Also I think it would be better for the serial nodes to reclaim the rxtx
> > pins in the dtsi, and override the reclaimed pins in the .dts only for
> > the nodes reclaiming flow control (some other pins could also be
> > directly reclaimed in the dtsi).
> 
> You lost me here. I guess I will benefit from a code snippet to
> illustrate the intention.
> 

Sure, instead of having: {

### board.dts:
&serialN {
	pinctrl-names = "default";
	pinctrl-0 = <&serialN_rxtx_pins>;
	status = "okay";
};
&serialN+1 {
	pinctrl-names = "default";
	pinctrl-0 = <&serialN+1_rxtx_pins>, <&serialN+1_rtscts_pins>;
	status = "okay";
};

} use ------------------ {

### plat.dtsi:
serialN: serial@xxxxx {
	compatible = "ns16550a";
	pinctrl-0 = <&serialN_rxtx_pins>;
	status = "disabled";
	[...]
};
serialN+1: serial@xxxxx {
	compatible = "ns16550a";
	pinctrl-0 = <&serialN+1_rxtx_pins>;
	status = "disabled";
	[...]
};

### board.dts:
&serialN {
	status = "okay";
};
&serialN+1 {
	pinctrl-0 = <&serialN+1_rxtx_pins>, <&serialN+1_rtscts_pins>;
	status = "okay";
};

}

> > 
> > Some other cleanups would also be in order for the da850*:
> > - use labels for non dtsi (like I did for the LCDK)
> 
> Agree. That would be better and more modern.
> 
> > - add chosen,memory nodes (I guess currently only the LCDK can
> >   dispense with ATAGS)
> 
> ok.
> 
> > - use a null range translation in the da850 dtsi for the soc node
> >   (computing the offsets is error prone and is there a point)
> 
> I do agree its easier to read if offsets directly matches addresses
> specified in the technical reference manual than doing the math with
> offsets and making sure they are correct.
> 
> That said, I am not sure null range translation is really the preferred
> approach. I would go with what DT maintainers say here.
> 
> > 
> > Sure I could fix that, along with some of the above suggestions if you
> > are ok with it.
> 
> It would be nice if you could fixup mcasp0_pins in da850-evm.dts. Surely
> it is doing more than what is needed.
> 

According to the schematics it is indeed, I could squeeze it in the series.

Rgds, 
Karl

> Regards,
> Sekhar

  reply	other threads:[~2016-08-26 17:17 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-04 11:06 [PATCH] ARM: dts: da850: Add missing pin muxing for the UARTs Karl Beldan
     [not found] ` <20160804110656.25318-1-kbeldan-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
2016-08-04 19:04   ` Kevin Hilman
2016-08-04 19:20   ` Kevin Hilman
2016-08-04 19:40     ` Karl Beldan
     [not found]     ` <m2eg64pchw.fsf-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
2016-08-04 21:00       ` Karl Beldan
2016-08-04 23:00         ` Kevin Hilman
     [not found]           ` <m2fuqknnqk.fsf-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
2016-08-23 11:09             ` Sekhar Nori
2016-08-23 11:16               ` Sekhar Nori
2016-08-24  8:38                 ` Karl Beldan
2016-08-25 13:42                   ` Sekhar Nori
     [not found]                     ` <354081bd-653d-ec98-f18e-eb0b1b1ee7e3-l0cyMroinI0@public.gmane.org>
2016-08-25 14:15                       ` Karl Beldan
2016-08-26 11:42                         ` Sekhar Nori
2016-08-26 12:25                   ` Sekhar Nori
2016-08-26 17:17                     ` Karl Beldan [this message]
2016-08-30  8:54                       ` Sekhar Nori
2016-08-09 10:19   ` Sekhar Nori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160826171718.GB20752@gobelin \
    --to=kbeldan@baylibre.com \
    --cc=devicetree@vger.kernel.org \
    --cc=karl.beldan+oss@gmail.com \
    --cc=khilman@baylibre.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=nsekhar@ti.com \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).