Messages in this thread | | | From | "Petr Vandrovec Ing. VTEI" <> | Date | Mon, 7 Jun 1999 17:19:39 MET-1 | Subject | Re: [RFC] new bus architecture (+ byte-endianess) |
| |
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/
| |