Messages in this thread | | | From | "Petr Vandrovec Ing. VTEI" <> | Date | Mon, 26 Apr 1999 12:19:18 MET-1 | Subject | Re: When to use ioremap? |
| |
Jeff Garzik wrote: > Why, then, does drivers/video/matroxfb.c have code for the case where > READx_WORKS is not true? Is this simply a performance optimization, or > a real requirement? Hi Jeff, this is real requirement because of there are architectures where read[bwl] and write[bwl] does not work as expected: On powerpc, read[bwl] and write[bwl] stores data in little-endian ordering - and this is not native ordering for PowerPC (*). To achieve maximum compatibility with existing support for Matrox devices on PPC I decided to use Matrox internal features to switch it to big endian mode, but if I did it, I have two choices: (1) use read/write[wl] together with cpu_to_le16/32 (2) or write simple procedures which simply dereferences pointer (works on everything except Alpha (and AFAIK works on Alpha for dwords) I decided for (2) because of sometime, maybe, readle32 and readbe32 will appear (I've heard something about 2.3...) It also has performance gain on i386, because of readl (__io_virt) does infamous `ptr |= PAGE_OFFSET'. Because of this 'or' operation is followed by *((volatile ...*)ptr) = val; gcc (and egcs) reloads ptr each time from memory, causing two additional operations and one (cached) memory reference. Without 'or'ing gcc stores value in register without reloads... Same applies for MEMCPYTOIO_WORKS - some architectures guarantees (by current implementation) that they'll transfer 4 bytes at a time, some (ARM) copy one byte at time. As Matrox requires 4 bytes (full PCI32 width) cycles, MEMCPYTOIO cannot be used... (+byte ordering on PPC) Best regards, Petr Vandrovec vandrove@vc.cvut.cz
(*) If I'm talking about PPC: Is it known that if you have compiled in both vgacon and matroxfb, screen is not correctly moved from vgacon to matroxfb (characters are byte-swapped with attributes)? I do not think that it is only matroxfb problem, as screen is moving from GD5434 to matroxfb in my case.
- 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/
| |