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. I'd disagree here: register offsets are the function of the chip select, not a chip itself -- you can possible wire chip selects to 16550 so that the registers would be spaced by 4 bytes. > 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. You're going to "teach" 8250.c? Good luck. :-) IMO we can only teach a glue layer which "passes" UARTs to 8250.c via platform devices. >> > 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). The chip can be connected to the bus (via chip select circuitry) in different ways, therefore we need a "glue" node for that circuitry? >> > 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) Once again, I disagree. :-) > Cheers, > g. WBR, Sergei _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev