imsttfb 2.5.x

In 2.5.67 imsttfb locks the system when it's time to scrool the text. Patch below fixes that. Otherwise everything seems to work as in 2.4

Quoted 6 lines

In 2.5.67 imsttfb locks the system when it's time to scrool the text. Patch below fixes that. Otherwise everything seems to work as in 2.4

drivers/video/imsttfb.c 2003-04-11 16:44:07.000000000 +0200 line 415

Quoted 8 lines

drivers/video/imsttfb.c 2003-04-11 16:44:07.000000000 +0200 renamed from drivers/video/ORIG_imsttfb.c 2003-04-09 15:11:46.000000000 +0200 +1 -1

@@ -409,7 +409,7 @@
 static inline u32 read_reg_le32(volatile u32 *base, int regindex)
 {
 #ifdef __powerpc__
-       in_le32((volatile u32 *) (base + regindex));
+       return in_le32((volatile u32 *) (base + regindex));
 #else
        return readl(base + regindex);
 #endif

There is actually no reason not to use readl() on ppc as well

Does readl handle byte swapping on the PPC. The registers expect the data feed to them to be little endian. Actually this driver will only work on the PPC and ix86 platform. Other big endian platforms are out of luck.

P.S
This whole issue really sucks. I really wish there was a clean standard
api to this.

Quoted 4 lines

Does readl handle byte swapping on the PPC. The registers expect the data feed to them to be little endian. Actually this driver will only work on the PPC and ix86 platform. Other big endian platforms are out of luck.

Yes, readl/writel will do the right thing. Use of in_le32 here is probably for pre-historical reasons ;)

All PCI capabale big endian platforms shall have proper byteswapping readl/writel.

Quoted 3 lines

P.S
This whole issue really sucks. I really wish there was a clean standard
api to this.

There is one, and it's readl/writel ;)

The only real problem is that currently, we lack equivalent of the "s" versions of in/out macros for mmio. This is a bit annoying for the few rare case where they would be useful as those shouldn't byteswap, but re-implementing with __raw_read/writel (which doesn't byteswap neither) is nasty because it exposes the barrier problem to the driver.

It would be convenient to define {read,write}s{b,w,l} so the IO accessors and MMIO accessors apre perfectly symetric, but that's an old debate...

Quoted 4 lines · Benjamin Herrenschmidt

Quoted 4 lines

Does readl handle byte swapping on the PPC. The registers expect the data feed to them to be little endian. Actually this driver will only work on the PPC and ix86 platform. Other big endian platforms are out of luck.

It works on ix86? I thought there were problems with ramdac init..must try that someday 8)

Or would it be better to scrap the read/write_reg_le32 alltogether?

P.S.

	Please check http://knjiznica-jesenice.org/~boris/boot/101_0145.JPG

What would i need to initialize in ramdac to get rid of "checkerboard" effect? Any ideas?

drivers/video/imsttfb.c 2003-04-15 23:07:41.000000000 +0200 renamed from drivers/video/ORIG_imsttfb.c 2003-04-15 23:06:29.000000000 +0200 +0 -8

@@ -408,20 +408,12 @@
  */
 static inline u32 read_reg_le32(volatile u32 *base, int regindex)
 {
-#ifdef __powerpc__
-       return in_le32((volatile u32 *) (base + regindex));
-#else
        return readl(base + regindex);
-#endif
 }
 
 static inline void write_reg_le32(volatile u32 *base, int regindex, u32 val)
 {
-#ifdef __powerpc__
-       out_le32((volatile u32 *) (base + regindex), val);
-#else
        writel(val, base + regindex);
-#endif
 }
 
 static __u32