LinuxPPC-Dev Archive on lore.kernel.org

* Re: [PATCH] booting-without-of: add Xilinx uart 16550.
From: Grant Likely @ 2008-02-15 19:02 UTC (permalink / raw)
  To: Sergei Shtylyov; +Cc: linuxppc-dev, Pavel Kiryukhin
In-Reply-To: <47B5E042.9050805@ru.mvista.com>

On Fri, Feb 15, 2008 at 11:56 AM, Sergei Shtylyov
<sshtylyov@ru.mvista.com> 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.

^ permalink raw reply