From: kbeldan@baylibre.com (Karl Beldan)
To: linux-arm-kernel@lists.infradead.org
Subject: [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 at xxxxx {
compatible = "ns16550a";
pinctrl-0 = <&serialN_rxtx_pins>;
status = "disabled";
[...]
};
serialN+1: serial at 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
WARNING: multiple messages have this Message-ID (diff)
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
next prev parent reply other threads:[~2016-08-26 17:17 UTC|newest]
Thread overview: 31+ 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
2016-08-04 11:06 ` Karl Beldan
2016-08-04 19:04 ` Kevin Hilman
2016-08-04 19:04 ` Kevin Hilman
2016-08-04 19:20 ` Kevin Hilman
2016-08-04 19:20 ` Kevin Hilman
2016-08-04 19:40 ` Karl Beldan
2016-08-04 21:00 ` Karl Beldan
2016-08-04 21:00 ` Karl Beldan
2016-08-04 23:00 ` Kevin Hilman
2016-08-04 23:00 ` Kevin Hilman
2016-08-23 11:09 ` Sekhar Nori
2016-08-23 11:09 ` Sekhar Nori
2016-08-23 11:16 ` Sekhar Nori
2016-08-23 11:16 ` Sekhar Nori
2016-08-24 8:38 ` Karl Beldan
2016-08-24 8:38 ` Karl Beldan
2016-08-25 13:42 ` Sekhar Nori
2016-08-25 13:42 ` Sekhar Nori
2016-08-25 14:15 ` Karl Beldan
2016-08-25 14:15 ` Karl Beldan
2016-08-26 11:42 ` Sekhar Nori
2016-08-26 11:42 ` Sekhar Nori
2016-08-26 12:25 ` Sekhar Nori
2016-08-26 12:25 ` Sekhar Nori
2016-08-26 17:17 ` Karl Beldan [this message]
2016-08-26 17:17 ` Karl Beldan
2016-08-30 8:54 ` Sekhar Nori
2016-08-30 8:54 ` Sekhar Nori
2016-08-09 10:19 ` 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=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.