Re: [RFC] new bus architecture (+ byte-endianess)

Petr Vandrovec Ing. VTEI (VANDROVE@vc.cvut.cz)
Mon, 7 Jun 1999 17:19:39 MET-1


On 7 Jun 99 at 14:46, Martin Mares wrote:
> > (2) will you offer some bus_to_bus address translation functions, for
> > example for supporting DMA from one (PCI) bus to another on PowerPC
> > (PowerPC uses translating bridge)?
> Any translation will be probably done via physical addresses, i.e.
> you translate address on the first bus to a physical address and then
> the physical address to address on the second bus.
If it will work for all hardware...
> > (3) do not forget about architectures which maps regular I/O into
> > memory address space - we should have ioremap_io() and inl/outl (_le?) -
> > on ia32, ioremap_io = nothing, inl/outl are I/O operations, on
> > PreP PPC, ioremap_io = return io+0x80000000; and inl/outl are synonyms
> > for readl/writel...
> I see that it would be useful for ISA devices, but for PCI we can do this
> easily without using ioremap_io() if we just translate the I/O addresses
> read from the device before passing them to the driver. I'm not sure whether
> this is worth the effort or not as I know of no PCI device where I/O
> accesses would be time critical.
Should not we do it symmetric with MMIO access?
> I'd like to hear the opinion of PPC people, because in case we can get
> automatic conversion LE->BE at no extra cost, DaveM's argument about
> readl_be() being just extra complexity with no benefits is perfectly
> correct.
Suppose that you have an unspecified stream of bytes which is correctly
formatted to be fed to hardware (for example character bodies to be drawn).
It must be fed as 32bit elements, so you cannot use memcpy_toio because of
it uses unspecified quantities (8bit on arm, BTW). So if you have native
writel, you can simple
for (i = 0; i < max; i++)
writel(*src++, dst++);
If your writel is little endian, you must do
for (i = 0; i < max; i++)
writel(cpu_to_le32p(src++), dst++);
First look more readable to me than second. And if there is at least one bus
which is big endian, we are in real troubles.
> > For example matroxfb have to be compatible with old XF86_SVGA on PPC
> > (do not have, but it is better if it cost almost nothing...). And XF86_SVGA
> > on PPC switched matrox into big endian mode... So have I to byteswap
> > all pixels and commands written to hardware and then store these data
> > to hardware using little-endian store? Why? Or should I break backward
> > compatibility for no real reason? I do not want to do that.
> I don't understand the compatibility problem there -- what have XF86_SVGA
> and matroxfb in common?
They share same hardware. I cannot imagine, how I could drive chip in little
endian and userspace XF86_SVGA in big endian. It is hard enough if they are
using same byteordering. XF86_SVGA sets hardware to big endian, so they can
use same code - simple 'mmio[REG_ABCD] = value;' on both architectures
without bothering with htons/htonl/ntohl/ntohs (do not forget that for
userspace there is no way to portable convert number to little endian I'm
aware of (except writting unoptimized swap function in C using shifts (in
libc6.0 htons is library function; in libc6.1 you can define htoil/itohl
yourself using __BYTE_ORDER and bswap32() macros)). But it is a libc, not
kernel issue.)
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/