Re: [PATCH 0/4] UART slave device support - version 4

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Hi Neil,

first, this is a *VERY* interesting and much needed patch series,
I intend to look closer at it, and if possible test it with some
(heh) board file device. Would be happy of you put me on CC for these.

On Mon, May 11, 2015 at 3:56 AM, NeilBrown <neil@xxxxxxxxxx> wrote:

>  When a device is connected to a UART via RS-232 (or similar), there
>  is a DTR line that can be used for power management, and other "modem
>  control" lines.
>
>  On an embedded board, it is very likely that there is no "DTR", and
>  any power management need to be done using some completely separate
>  mechanism.
>
>  So these "slaves" are really just for devices permanently attached to
>  UARTs without a full "RS-232" (or similar) connection.  The driver
>  does all the extra control beyond Tx/Rx.

What is usually happening (and I have seen it in a few places) is that
the SoC has *one* fully featured RS232 with CTS/RTS and even
DTS,DCD,RI and other esoterica, which is intended to be connected to a
host serial port or so, for example if this SoC is to act as a modem
or a fax machine, or if it is to drive one.

Then they often have a few more UART blocks, usually identical, which
only have RxD+TxD available, so they are "just" UARTs.

To complicate things further, you may wonder what happened with
the CTS/RTS (etc) signals from the other blocks. Usually they are there
in the silicon but just routed to dead ends.

To complicate it even further, usually all these pins are placed under
pin control multiplexing, so in an actual electronic design, the
system will mux out CTS/RTS (etc) from the fully featured RS232
blocks and only use them as UARTs anyways.

Then there are those who created real simple RxD/TxD-only UARTs
("yeah lets dump this RS232 legacy crap" / "yeah yeah")
and then realized they want to drive modems ("oh crap, it seemed
like a good idea at the time"). Then they usually take
two GPIO pins for CTS/RTS and drive them as GPIOs using
software and you have a cheap 4-line modem line. This is what
drivers/tty/serial/serial_mctrl_gpio.c is for if you wondered.

> I've tested this set and it seems to work ... except that something
>  is sadly broken with bluetooth support in 4.1-rc1 so I've only really
>  tested the GPS driver.  I guess it is time to rebase to -rc3.

You have a hardware taget I see. Which one?

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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux