Hi Fabio, On Sun, Feb 19, 2017 at 07:34:15PM -0300, Fabio Estevam wrote: > Hi Clemens, > > On Sun, Feb 19, 2017 at 7:26 PM, Clemens Gruber > <clemens.gruber@xxxxxxxxxxxx> wrote: > > > But CTS_B is an active-low output, according to the IMX6DQ reference > > manual. > > This 'active-low' term is what causes confusion in my opinion. > > Active-low or active-high depends on how the user sets > SER_RS485_RTS_ON_SEND flag. > > > > The CTS field in _UCR2 has the following description on page 5252: > > 0 The CTS_B pin is high (inactive) > > 1 The CTS_B pin is low (active) > > The logic levels mentioned here are correct. > > > > > We had to invert the signal in hardware before connecting it to the > > active-high transceive-enable pin of a transceiver. > > > > If you want CTS_B high during transmit, I think you need it the other > > way around: SER_RS485_RTS_ON_SEND cleared and SER_RS485_RTS_AFTER_SEND > > set. > > On the system I tried I need to drive CTS_B pin high so that the TXEN > RS485 transceiver can trasmit data. Then it needs to go low so that RX > can happen. > > In order to do so: > > SER_RS485_RTS_ON_SEND set > SER_RS485_RTS_AFTER_SEND cleared. > > ,which works for the native CTS_B case and also the gpio-rts case. OK, now I see where the confusion comes from. I have your patch applied locally, where you changed imx_port_rts_active to clear CTS and imx_port_rts_inactive to set CTS. This is confusing because of what the manual says about the CTS_B pin states. Many manuals, schematics, etc. labeled the CTS_B signal as active-low, for example "CTS_B#". If that's not true anymore because we inverted it in software, this is even more confusing, in my opinion. It's also odd that we call imx_port_rts_inactive in places where we should really be calling imx_port_rts_active, and vice-versa. Wouldn't it be better if we did not change the imx_port_rts_(in)active functions (as your patch did) but the places where they are used? I mean, for example in imx_start_tx, not: if (port->rs485.flags & SER_RS485_RTS_ON_SEND) imx_port_rts_inactive(sport, &temp); (..) But: if (port->rs485.flags & SER_RS485_RTS_ON_SEND) imx_port_rts_active(sport, &temp); (..) And in the other places where these functions are used as well. I think this is clearer, because "RTS"/CTS being set, does not require that CTS_B is active-high. I think we should not change the assumption from the manual, that CTS_B is an "active-low" output pin. Then, setting SER_RS485_RTS_ON_SEND and clearing SER_RS485_RTS_AFTER_SEND would lead to: CTS_B being logic low during send CTS_B being logic high before and after send So, if you want CTS_B to be driven high during send, you'd have to clear SER_RS485_RTS_ON_SEND and set SER_RS485_RTS_AFTER_SEND. What do you think? Thanks, Clemens -- 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
