Messages in this thread | | | Date | Mon, 7 Jun 1999 09:27:46 -0700 | From | "David S. Miller" <> | Subject | Re: RFC: Devices, buses and hotplug |
| |
Date: Mon, 7 Jun 1999 17:11:58 +0100 (BST) From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> 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/
| |