On Sat, Jan 7, 2017 at 1:38 PM, Fabio Estevam <festevam@xxxxxxxxx> wrote:
> From: Fabio Estevam <fabio.estevam@xxxxxxx>
>
> On a board that needs to drive RTS GPIO high in order to enable the
> transmissionof a RS485 transceiver the following description is passed
> in the devide tree:
>
> &uart4 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_uart4>;
> rts-gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>;
> status = "okay";
> };
>
> However the polarity observed on the oscilloscope is inverted.
>
> Change the mctrl_gpio_set() logic so that the RTS gpio pin can
> behave correctly.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@xxxxxxx>
> ---
> Hi,
>
> Marking as RFC as I don't know if this is the proper way to fix it.
>
> Is my device tree description correct assuming I need RTS pin going to
> high to enable the TXEN pin of the RS485 transceiver?
>
> Thanks
>
Fabio,
I also have boards that uses a GPIO as an active-high enable to an
RS485 transceiver. In my device-trees I define as 'rts-gpios = <&gpio7
1 GPIO_ACTIVE_HIGH>'. I do find that the polarity is inverted on
master and your patch does flip the polarity. However, I share your
concern that this may not be the right way to fix it.
my understanding is that the TIOCSRS485 ioctl should have 'flags =
SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND' to assert RTS on transmit.
The thing I find confusing is that in imx_start_tx the driver calls
imx_port_rts_inactive if SER_RS485_ENABLED and in imx_stop_tx the
driver calls imx_port_rts_active. To me that is what seems inverted,
not the implementation of those functions.
It's confusing because the driver accounts for two options:
SER_RS485_RTS_ON_SEND (logic level for RTS pin when sending) and
SER_RS485_RTS_AFTER_SEND (logic level for RTS pin after sending). I'm
not sure why there needed to be two options here as they both seem to
indicate the same thing with an opposite polarity.
Tim
--
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
