Hi Peter,

On Wed, Mar 23, 2016 at 6:11 PM, Peter Hurley [off-list ref] wrote:

On 03/23/2016 02:33 AM, Geert Uytterhoeven wrote:

quoted

On Fri, Mar 18, 2016 at 8:07 PM, Peter Hurley [off-list ref] wrote:

quoted

On 03/17/2016 06:47 AM, Geert Uytterhoeven wrote:

quoted

Replace the custom SCIx_HAVE_RTSCTS flag in the
plat_sci_port.capabilities field by the standard UPF_HARD_FLOW flag in
the uart_port.flags and plat_sci_port.flags fields.
Remove the now unused plat_sci_port.capabilities field.
Legacy pllatform data can enable UPF_HARD_FLOW in plat_sci_port.flags.

UPF_HARD_FLOW is really for indicating the h/w supports automatic
CTS and RTS signalling; ie., RTS is automatically de-asserted when
rx fifo reaches some threshold and CTS will automatically prevent
tx fifo output.

There is no serial core flag for indicating the h/w supports (or does not)
RTS and/or CTS signalling.

Sorry for not being clearer: Renesas SCIF hardware with dedicated RTS/CTS pins
does have support for automatic RTS/CTS signalling. The driver has (unused)
support for that (cfr. setting the SCFCR_MCE (Modem Control Enable) flag), but
it seems to be busted when enabled.

Ok.

So looking at the code, IIUC, SCIF does not provide a way to directly
control RTS output or read CTS input when RTS/CTS is pinned (ie, not gpio).
Is that correct?
How to support autoRTS/autoCTS depends on the answer to this question.

Actually it does have support for controlling RTS output and reading CTS
input, but that is not yet implemented.

Magnus posted a series touching this a while ago ("serial: sh-sci: Hardware
flow control update", http://www.spinics.net/lists/linux-sh/msg38401.html),
which received some comments.

Is there a datasheet/trm that I can review describing register layout and
uart behavior?

I found a public one for an older SoC, see pages starting at (physical) page 849
http://documentation.renesas.com/doc/products/mpumcu/doc/superh/r01uh0048ej0200_sh7268.pdf

  - FIFO Control Register, bit MCE for automatic control
  - Serial Port Register for manual control

quoted

  2. If the user didn't set CRTSCTS, the RTS output pin should be controlled by
     the serial core, through .set_mctrl(),

Not quite.

_Regardless of CRTSCTS setting_, the RTS output pin should be controlled
through .set_mctrl() method. The serial core takes CRTSCTS into account on
behalf of the driver when necessary.

What does this mean exactly?
AFAIU, there are three states:
  - Force RTS asserted,
  - Force RTS deasserted,
  - Use hardware-controlled automatic RTS,
while .set_mctrl() just provides the boolean TIOCM_RTS flag?

gpio-based RTS/CTS is mutually exclusive with autoRTS/autoCTS. But I'm not
seeing any logic in these patches to prevent that.

Sure. Currently nothing sets SCIx_HAVE_RTSCTS, so this can't happen yet.

I went for GPIO-based RTS/CTS first, as we now have a framework for that,
and I can use it as a known-working base.

autoCTS without a way to read CTS input level means that although transmission
stops, the driver has no way to update port->hw_stopped so the write buffer
will keep filling up until it's full @ 4k.

SCIF allows to read CTS input level, regardless of automatic RTS/CTS is
enabled or not.

autoRTS without a way to override RTS output complicates throttling.

SCIF allows to override RTS output.

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds