Hi Geert, On 03/23/2016 02:33 AM, Geert Uytterhoeven wrote: > On Fri, Mar 18, 2016 at 8:07 PM, Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> wrote: >> On 03/17/2016 06:47 AM, Geert Uytterhoeven wrote: >>> 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. Is there a datasheet/trm that I can review describing register layout and uart behavior? > If I understand it correctly: > 1. Automatic RTS/CTS signalling should be enabled only if the user enabled it > through termios->c_cflag & CRTSCTS, yes > 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. > 3. Regardless of the user setting CRTSCTS or not, .get_mctrl() should report > the current status of the CTS input pin. yes > Are my assumptions correct? A couple of things. gpio-based RTS/CTS is mutually exclusive with autoRTS/autoCTS. But I'm not seeing any logic in these patches to prevent that. 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. autoRTS without a way to override RTS output complicates throttling. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
