>>>>> "GL" == Grant Likely <[EMAIL PROTECTED]> writes:
Hi, >> Can you please confirm if this works on PPC? GL> Yes, I've confirmed this does work on PPC; but I don't think it's GL> quite the correct fix. GL> ioread/write32 is mapped to in/out_le32, yet the bootloader driver GL> must use in/out_be32. This is because the uartlite driver follows GL> the lead of 8250 and requires an offset of 3 from the base address GL> in order to find the relevant byte wise address. In fact, I GL> believe the driver should work as-is on microblaze if the GL> offset-by-3 is not used when registering it to the platform bus. Not used? Isn't the microblaze big endian as well? GL> However, the uartlite is *not* an 8250. The 8250 turns up all GL> over the place and it's registers are defined as 8 bit wide. The GL> offset-by-3 stuff is part of the plat_serial8250_port structure GL> which is also used to specify .regshift (increment between GL> registers). Whereas the UARTLITE is defined as a 32 bit device GL> and it doesn't show up in anywhere near as many designs. GL> Registers are always 4 bytes wide and are always located at GL> multiples of 4 bytes off the base address. Well, yes and no - The registers physically contains 8 bit of information, but are commonly located on the 32bit opb bus. GL> The biggest problem with keeping the 3 byte offset and using GL> ioread/write32 on it makes every register access straddle a 32-bit GL> boundary. This means 2 bus transactions for every register GL> access. Absolutely not what we want. Exactly. GL> The problem with keeping the byte-wise access as it is now is that GL> it means the platform bus binding needs to explicitly know what GL> the host access width is and add the 3 byte offset accordingly GL> (rather than using the base address as specified in xparameters GL> unmodified and using the in/out_be32 macro take care of reading it GL> correctly & efficiently). I don't think that's a big problem. Other reasons for using 8bit I/O are: - No endianness problems (besides setting the proper base address). "There's no read/write register in native endianness" interface in the kernel. readl is always little endian, and _be32 would be wrong/not available on all archs. The uartlite interface is nice and simple - Who knows if someone would add a FPGA with a bunch of uartlite's to an ARM/MIPS/whatever design? - No bus width problems. We have designs which needed extra uarts late in the design, and have implemented uartlite compatible firmware in a SP3e FPGA connected over a 16bit bus (EMC). The uartlite driver works nicely with that as it is. With 32bit access you would double the bus transactions. - It matches 8250.c GL> (There are also annoyances that will come up when we move to GL> arch/powerpc and hook it up to the of_platform_bus) Ohh, like what? >> I note that Grant's recent bootloader driver uses in_be32/out_be32 >> - would you prefer that instead of ioread32/iowrite32? GL> I certainly think so. The device is documented as using 32 bit BE GL> registers; so the driver should access them as 32bit BE registers GL> IMHO. Or at least, if there is a good reason to continue the GL> bytewise access, then the driver should contain the smarts to GL> translate from documented base address to the appropriate offset. How should it be able to do that? Using some magic #ifdef to know if it's compiled for a big endian arch and do a +3? That seems ugly to me. In other words - I disagree. -- Bye, Peter Korsgaard _______________________________________________ Linuxppc-embedded mailing list [email protected] https://ozlabs.org/mailman/listinfo/linuxppc-embedded
