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

On Fri, Feb 15, 2008 at 11:56 AM, Sergei Shtylyov
[off-list ref] wrote:

Grant Likely wrote:

 >> +      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.

The definition of compatible (from the OpenFirmware) docs is that the
*device* is register level compatible.   That includes register
locations and offsets.  The registers are not at the same location,
therefore it is not compatible.

However, the *driver* can be easily made compatible with the devices.
We just teach the driver to bind against both "ns16550" and whatever
value is chosen for these reg-shifted devices.  Not a big deal.

 > 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.

compatible also covers bus binding when it is a memory mapped device.
Otherwise you need another node between the bus and the ns16550 type
device that does translation from the wide stride (regshift=2) to the
ns16550 register definitions (regshift=0).

 > 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...

No, we cannot because it is not register level compatible (and once
again, that definition includes the stride between registers)

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.