Re: When to use ioremap?
Petr Vandrovec Ing. VTEI (VANDROVE@vc.cvut.cz)
Mon, 26 Apr 1999 12:19:18 MET-1
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/