From: Lee Jones <lee.jones@linaro.org>
To: Peter Griffin <peter.griffin@linaro.org>
Cc: gregkh@linuxfoundation.org, jslaby@suse.com,
linux-serial@vger.kernel.org, robh+dt@kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kernel@stlinux.com
Subject: Re: [STLinux Kernel] [PATCH 3/8] serial: st-asc: Read in all Pinctrl states
Date: Wed, 1 Feb 2017 12:47:51 +0000 [thread overview]
Message-ID: <20170201124751.f3r7l52vneqgilac@dell> (raw)
In-Reply-To: <20170201115006.GA23479@griffinp-ThinkPad-X1-Carbon-2nd>
> > > > Again, doesn't matter, since it's the DTB that provides the default
> > > > state. So, back when it was authored, the default state was HW
> > > > flow-control disabled. And in a newer DTB (again, until I follow-up
> > > > with more changes), the defaults for UART 1 and UART 2 are HW
> > > > flow-control disabled.
> > > >
> > > > Your issue seems to be that you've assumed since we now provide the
> > > > possibility of a "manual-rts" state, then the "default" state should
> > > > *only* be HW flow-control capable, which is not the case.
> > >
> > > No my feedback was that it would be clearer & simpler to make manual-rts the
> > > 'default' state, and 'hw-flow-control' the optional state.
> >
> > Absolutely not. The use of "manual-rts" is the corner-case here and
> > is not normally required.
>
> See below.
>
> > The "default" state should normally be
> > populated with whatever pins are available i.e. all 4 pins (including
> > "rts, cts") if they are wired up and only 2 pins (just "tx, rx") if
> > they are not.
>
> Yep OK, I agree :)
\o/
> > The submission of "manual-rts" is only required if the
> > RTS pin is required for some other purpose e.g. resetting a uC on a
> > draughtboard.
>
> All UARTs the SoC have the same st-asc IP, which suffers from the same
> hw flow control limitation. Also all instances on the SoC have rts/cts
> pins, the only limitation is board wiring.
>
> So I can't see why would you ever *not* want to deploy this dynamic pin
> switching solution if rts/cts is wired up at board level now the facility
> exists?
Mainly because it's surplus to requirement, in that there is very
seldom any point in manually toggling the RTS line (at least to my
knowledge). I figure we'd add >1 Pinctrl states only when the need
arises, thus keeping the DTS' as simple as possible.
> Also regarding the naming of the second pin group, 'manual-rts' seems like
> a bad name as a logical extension of this set is to also offer the same
> dynamic switching for the CTS line.
>
> Maybe a better name would be 'tx-rx-only' or 'no-rts-cts'.
Works for me. Will fix.
> > > > It's the
> > > > 'uart-has-rtscts' property which determines this *not* whether the
> > > > second state has been provided.
> > >
> > > Yep, which is why IMO it makes more sense for the optional pin group to be the hw
> > > flow control pins which are obtained if the uart-has-rtscts property is present.
> >
> > There would normally only be one pin group. Your method would insist
> > we always provided 2, which would be surplus to requirement.
>
> Yep OK, agree with your point.
\o/
> Yep OK, I agree.
\o/
> Yep OK, I agree.
\o/
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2017-02-01 12:47 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-24 13:43 [PATCH 0/8] serial: st-asc: Allow handling of RTS line Lee Jones
2017-01-24 13:43 ` [PATCH 1/8] serial: st-asc: Ignore the parity error bit if 8-bit mode is enabled Lee Jones
2017-01-25 11:02 ` [STLinux Kernel] " Peter Griffin
2017-01-24 13:43 ` [PATCH 2/8] serial: st-asc: Provide RTS functionality Lee Jones
2017-01-25 11:03 ` [STLinux Kernel] " Peter Griffin
2017-01-24 13:43 ` [PATCH 3/8] serial: st-asc: Read in all Pinctrl states Lee Jones
2017-01-24 21:28 ` kbuild test robot
2017-01-25 11:21 ` [STLinux Kernel] " Peter Griffin
2017-01-27 11:54 ` Lee Jones
2017-01-30 14:23 ` Peter Griffin
2017-01-30 15:32 ` Lee Jones
2017-01-30 16:10 ` Peter Griffin
2017-01-30 19:11 ` Lee Jones
2017-01-30 22:35 ` Peter Griffin
2017-01-31 10:13 ` Lee Jones
2017-01-31 11:31 ` Peter Griffin
2017-01-31 12:27 ` Lee Jones
2017-02-01 11:50 ` Peter Griffin
2017-02-01 12:47 ` Lee Jones [this message]
2017-01-24 13:43 ` [PATCH 4/8] serial: st-asc: (De)Register GPIOD and swap Pinctrl profiles Lee Jones
2017-01-24 22:00 ` kbuild test robot
2017-01-25 11:24 ` [STLinux Kernel] " Peter Griffin
2017-01-24 13:43 ` [PATCH 5/8] ARM: dts: STiH410-b2260: Identify the UART RTS line Lee Jones
2017-01-24 13:43 ` [PATCH 6/8] ARM: dts: STiH407-pinctrl: Add Pinctrl group for HW flow-control Lee Jones
2017-01-25 11:01 ` [STLinux Kernel] " Peter Griffin
2017-01-24 13:43 ` [PATCH 7/8] ARM: dts: STiH407-family: Use new Pinctrl groups Lee Jones
2017-01-25 11:54 ` [STLinux Kernel] " Peter Griffin
2017-01-27 11:03 ` Lee Jones
2017-01-27 11:29 ` Lee Jones
2017-01-24 13:43 ` [PATCH 8/8] ARM: dts: STiH407-family: Enable HW flow-control Lee Jones
2017-01-25 10:59 ` [STLinux Kernel] " Peter Griffin
2017-01-25 11:40 ` Peter Griffin
2017-01-27 11:33 ` Lee Jones
2017-01-27 11:32 ` Lee Jones
2017-01-25 10:07 ` [PATCH 0/8] serial: st-asc: Allow handling of RTS line Greg KH
2017-01-25 15:35 ` Lee Jones
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=20170201124751.f3r7l52vneqgilac@dell \
--to=lee.jones@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jslaby@suse.com \
--cc=kernel@stlinux.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=peter.griffin@linaro.org \
--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).