> But my commentary (and I thought Jes's) was in the light of
> having the hardware transparently handle the endianness for you,
> be that via explicit load/store attributes or special MMU
> mappings.
The PPC can't cope with this. Thats why brokenfirmware mandates a
bigendian fb - they didnt want to cope either without MMU
assist. Most video cards thus have BE and LE apetures. The S3 I
seem to remember also has a magical autoconverting YUV->RGB apeture
or similar too.
(BTW: the S3 YUV aperature is mainly for direct MPEG decoding and
things like BTTV direct to fb...)
Why can't it cope? The facilities do exist on PPC to handle this
stuff, in fact it is used already, look in the ATI driver:
static inline u32 aty_ld_le32(volatile unsigned int regindex,
const struct fb_info_aty *info)
{
...
#if defined(__powerpc__)
temp = info->ati_regbase;
asm("lwbrx %0,%1,%2" : "=r"(val) : "r" (regindex), "r" (temp));
#elif defined(__sparc_v9__)
temp = info->ati_regbase + regindex;
asm("lduwa [%1] %2, %0" : "=r" (val) : "r" (temp), "i" (ASI_PL));
#else
temp = info->ati_regbase+regindex;
val = le32_to_cpu(*((volatile u32 *)(temp)));
#endif
...
}
We've been through the arguments before about firmware controlling how
the kernel can access a device. The kernel can do whatever it
chooses, and for weird drivers which want to share the programming
interface the firmware uses, it can do special things outside of our
general framework, because what they want to do is not general.
Later,
David S. Miller
davem@redhat.com
-
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/