linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Griffin <peter.griffin@linaro.org>
To: Lee Jones <lee.jones@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: Mon, 30 Jan 2017 14:23:56 +0000	[thread overview]
Message-ID: <20170130142356.GA18710@griffinp-ThinkPad-X1-Carbon-2nd> (raw)
In-Reply-To: <20170127115458.k4edg42nnna3bv4v@dell>

Hi Lee,

On Fri, 27 Jan 2017, Lee Jones wrote:

> On Wed, 25 Jan 2017, Peter Griffin wrote:
> 
> > Hi Lee,
> > 
> > On Tue, 24 Jan 2017, Lee Jones wrote:
> > 
> > > There are now 2 possible separate/different Pinctrl states which can
> > > be provided from platform data.  One which encompasses the lines
> > > required for HW flow-control (CTS/RTS) and another which does not
> > > specify these lines, such that they can be used via GPIO mechanisms
> > > for manually toggling (i.e. from a request by `stty`).
> > > 
> > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > > ---
> > >  drivers/tty/serial/st-asc.c | 28 ++++++++++++++++++++++++++++
> > >  1 file changed, 28 insertions(+)
> > > 
> > > diff --git a/drivers/tty/serial/st-asc.c b/drivers/tty/serial/st-asc.c
> > > index 397df50..03801ed 100644
> > > --- a/drivers/tty/serial/st-asc.c
> > > +++ b/drivers/tty/serial/st-asc.c
> > > @@ -37,10 +37,16 @@
> > >  #define ASC_FIFO_SIZE 16
> > >  #define ASC_MAX_PORTS 8
> > >  
> > > +/* Pinctrl states */
> > > +#define DEFAULT		0
> > > +#define MANUAL_RTS	1
> > 
> > Nit: Would be better to have them aligned.
> 
> These are aligned in code.  The patch format throws things out.
> 
> Look, same lines with the "> > +" removed:

Ah OK.

> 
> /* Pinctrl states */
> #define DEFAULT		0
> #define MANUAL_RTS	1
> 
> Try it.
> 
> > > +
> > >  struct asc_port {
> > >  	struct uart_port port;
> > >  	struct gpio_desc *rts;
> > >  	struct clk *clk;
> > > +	struct pinctrl *pinctrl;
> > > +	struct pinctrl_state *states[2];
> > >  	unsigned int hw_flow_control:1;
> > >  	unsigned int force_m1:1;
> > >  };
> > > @@ -694,6 +700,7 @@ static int asc_init_port(struct asc_port *ascport,
> > >  {
> > >  	struct uart_port *port = &ascport->port;
> > >  	struct resource *res;
> > > +	int ret;
> > >  
> > >  	port->iotype	= UPIO_MEM;
> > >  	port->flags	= UPF_BOOT_AUTOCONF;
> > > @@ -720,6 +727,27 @@ static int asc_init_port(struct asc_port *ascport,
> > >  	WARN_ON(ascport->port.uartclk == 0);
> > >  	clk_disable_unprepare(ascport->clk);
> > >  
> > > +	ascport->pinctrl = devm_pinctrl_get(&pdev->dev);
> > > +	if (IS_ERR(ascport->pinctrl)) {
> > > +		ret = PTR_ERR(ascport->pinctrl);
> > > +		dev_err(&pdev->dev, "Failed to get Pinctrl: %d\n", ret);
> > > +	}
> > > +
> > > +	ascport->states[DEFAULT] =
> > > +		pinctrl_lookup_state(ascport->pinctrl, "default");
> > > +	if (IS_ERR(ascport->states[DEFAULT])) {
> > > +		ret = PTR_ERR(ascport->states[DEFAULT]);
> > > +		dev_err(&pdev->dev,
> > > +			"Failed to look up Pinctrl state 'default': %d\n", ret);
> > > +		return ret;
> > > +	}
> > > +
> > > +	/* "manual-rts" state is optional */
> > > +	ascport->states[MANUAL_RTS] =
> > > +		pinctrl_lookup_state(ascport->pinctrl, "manual-rts");
> > > +	if (IS_ERR(ascport->states[MANUAL_RTS]))
> > > +		ascport->states[MANUAL_RTS] = NULL;
> > > +
> > 
> > The different pinctrl states looks like a neat solution to the problem.
> > 
> > My only concern here is that 'default' state is implying a hw-flow-control
> > pinmux config, and manual-rts is implying what is the current upstream
> > 'default' pinmux config.
> > 
> > Which maybe ok if you update all uarts, but currently only serial0
> > is updated. So the other uarts current 'default' is actually the same as serial0
> > 'manual-rts' grouping, which conceptually is odd.
> > 
> > Would it not be better to make 'manual-rts' the default state? As that aligns
> > to what is currently already the default for the other UARTS? And then make
> > hw-flow-control the optional state for serial0?
> > 
> > That also has the advantage that 'default' has the same meaning with older DT's.
> 
> The reason it was done is this was because none of the other UARTs
> require 2 separate Pinctrl configurations, only this one.  Moreover,
> if they support RTS/CTS then I believe that the lines should be
> defined in Pinctrl.

Yes I agree with that.

> Thus, it was my plan to update all UART's default
> Pinctrl configs to include the RTS/CTS lines.
> 

I still don't see the point in changing the meaning of 'default' group and breaking
ABI if you don't need to?

As far as I can tell if you swap the meaning of 'default' and 'maunal-rts'
groups you get all the benefits of this series whilst also maintaining backwards
compatbility with older DT's.

regards,

Peter.

  reply	other threads:[~2017-01-30 14:32 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 [this message]
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
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=20170130142356.GA18710@griffinp-ThinkPad-X1-Carbon-2nd \
    --to=peter.griffin@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.com \
    --cc=kernel@stlinux.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.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).