On Thu, Sep 21, 2017 at 8:28 AM, Uwe Kleine-König
<u.kleine-koenig@xxxxxxxxxxxxxx> wrote:
> on an i.MX25 machine on my desk a UART RX line is guarded by a transistor
> like this:
>
> ,------------------------.
> | ,---------. |
> | | imx25 o--RX----◁---o---
> | | o--GPIO--' |
> | `---------' |
> `------------------------'
This is inside the SoC, right, not outside it?
In the rest of my answer I assume this.
If this is on the board, using enable-gpios is proper.
> My first idea was to make this a property of the UART and added a
> enable-gpios property for it[1]. But now I wonder if this is better
> abstracted as an enable-gpios property in the pinctrl node. Something
> like:
>
> pinctrl_uart5: uart5 {
> fsl,pins = <
> MX25_PAD_ECB__UART5_TXD 0x00002080 /* TXD */
> MX25_PAD_LBA__UART5_RXD 0x00000000 /* RXD */
> MX25_PAD_CS4__UART5_CTS 0x00002001 /* RTS */
> MX25_PAD_CS5__GPIO_3_21 0x00002001 /* #RXD_EN */
> >;
> enable-gpios = <&gpio3 21 GPIO_ACTIVE_LOW>;
> };
>
> Would this make sense? Maybe with a more intuitive name?
I would point to "GPIO mode pitfalls" in
Documentation/driver-api/pinctl.rst
If the construction above is inside the SoC, this line is just called
"GPIO" out of habit.
Think about it: is it really "general purpose input/output"?
It looks more like "special purpose, output-only, RX-enable line".
The only reason it is called "GPIO" is because the bit activating
it happens to be inside some silicon block that the hardware
engineer calls "GPIO", but it is not GPIO.
I would definately try to set it up as part of the pin control state
in the device tree like you illustrate, and not use the enable-gpios
at all.
Possibly, if this bit also appears in a generic GPIO block with a bunch
of other GPIOs you need to mask off this GPIO from generic use
if you want to be pedantic about things. But generally we just leave
that kind of things open for the developer so they can freely
shoot themselves in the foot with it.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
