| Message ID | 20170124134310.27512-4-lee.jones@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | serial: st-asc: Allow handling of RTS line | expand |
Hi Lee, On Mon, 30 Jan 2017, Lee Jones wrote: > On Mon, 30 Jan 2017, Peter Griffin wrote: > > On Mon, 30 Jan 2017, Lee Jones wrote: > > > On Mon, 30 Jan 2017, Peter Griffin wrote: > > > > On Fri, 27 Jan 2017, Lee Jones wrote: > > > > > On Wed, 25 Jan 2017, Peter Griffin wrote: > > > > > > 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 > > [...] > > > > > > > > + 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. > > > > > > What makes you think this will break ABI? > > > > I've not tried it, but an older DT defines one group, 'default' which contains > > the same pin config as your new optional 'manual-rts' group. > > > > The driver now reads like the manual-rts pin config is optional and should be stored in > > ascport->states[MANUAL_RTS]. An older DT will pass that same pin config as the default > > group and it will be stored in ascport->states[DEFAULT]. > > > > That seems wrong to me, and if it executes OK it wouldn't be what you > > expect by reading the code. > > This makes no sense at a functional level. > > Old kernel, old DTB: > > ASC driver doesn't understand Pinctrl, but since only the "default" > state is defined, that's what will be used as a matter of course. > RTS/CTS aren't configured, but that doesn't matter because the DTS > does not advertise that HW flow-control is available. In this > use-case neither HW flow-control, nor manual toggling of the RTS line > is possible. > > New kernel, old DTB: > > ASC driver demands "default" and requests "manual-rts" Pinctrl states, > but "manual-rts" isn't available so "default" will be the only > utilised state. Unlike the first example above, "default" now > contains the RTS and CTS lines, No it doesn't, default just contains 'tx' & 'rx' pins, as it has always done until now. Which is IMO where the condusion arises, as it is the same pin configuration as what you are now calling 'manual-rts' which the driver just tried and failed to obtain (although in reality it has actually obtained those pins but stored them in DEFAULT instead. I presume this is why it didn't make sense to you above. >but since the DTS does not advertise > HW flow-control as available they will be harmlessly unused. This > configuration culminates in the same result as the first example > i.e. no HW flow-control and no manual toggling. However, there are no > detremental effects to the driver's functions. > <snip> >New kernel, new DTB: > > ASC driver demands "default" and requests "manual-rts" Pinctrl > states. If DTS advertises that HW flow-control is possible and the > client requests it, ASC will use the "default" state and HW > flow-control will commence. If HW flow-control is not requested by > the client and "manual-rts" is available, then ASC will request the > RTS line is handled by GPIO until such times as the client requests > HW flow-control, at which point ASC will disable GPIO and request the > "default" state again. Unless it is uart 1 or 2, in which case 'default' still only contains tx & rx pins, and you have the same situation as above. > > It is not possible to read C-code and make assumptions that the DTB > will be in a particular state as you suggest. > No disparity ever > exists and the code is always clear IMHO. > Really? ascport->states[DEFAULT]: may contain "tx, rx" or "tx, rx, cts & rts" ascport->states[MANUAL_RTS]: may contain "tx, rx", or it could be stored in DEFAULT And as the series currently is you have a mixture of the two in the same kernel depending on what instance of the UART you are. regards, Peter. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > > 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 + 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; + return 0; }
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(+) -- 2.10.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html