Re: [PATCH] booting-without-of: add Xilinx uart 16550.

Grant Likely wrote:

quoted

Add uart 16550 properties description to Xilinx portion of booting-without-of.txt

quoted

Signed-off-by: Pavel Kiryukhin <redacted>
---
 Documentation/powerpc/booting-without-of.txt |   16 ++++++++++++++--
 1 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 7b4e8a7..dd77bbc 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt

@@ -2575,10 +2575,22 @@ platforms are moved over to use the flattened-device-tree model.

      Xilinx uartlite devices are simple fixed speed serial ports.

-      Requred properties:
+      Required properties:
       - current-speed : Baud rate of uartlite

-      v) Xilinx hwicap
+      v) Xilinx Uart 16550
+
+      Xilinx uart 16550 device registers are compatible with all standard 16540
+      and 16550 UARTs.

Not strictly true; the xilinx uart is *almost* compatible with the
ns16550.  The same driver can be made to work, but it is not register
level compatible so we cannot claim compatible="ns16550".

    How much incompatible it is with 16550? Does that only extend to register 
stride of 4 instead of 1 -- if so, it should be considered compatible since
the same chip can be into address space mapped with stride of 1, 2, or 4, or 
whatever power of 2. If it has some actual register difference, like e. g. 
DLAB not existing and the divisor latch mapped to a separate register rather 
than 0..1, then indeed, new compatible property must be defined.

We need a new compatible property for 16550 like devices with a reg shift and
offset.

    No, we don't strictly need it if all incompatibilty is constrained to how 
the same 16550 registers mapped to address space which is a function of the 
address decoder, not the chip itself. Well, that's of course based in 8250.c's 
ability to handle different strides -- an imaginary driver could only handle 
1:1 chip mapping.

Instead of attempting to come up with a generic description
of this, I recommend just naming it after the actual device instance;
something like compatible="xlnx,opb-uart16550";

    Well, that means that we'll need a to add a code which "glues" the chip to 
8250.c driver... well, of_serial.c could be that glue layer if we add to it 
the ability to recognize Xilinx UART... well, legacy_serial.c could be taught 
that trick too...
    Well, we could also add the new compatible, but still claim "ns16550" 
compatibility...

Cheers,
g.

WBR, Sergei