Linux-kernel mailing list archive 1999-23,: Re: RFC: Devices, buses and hotplug

# Re: RFC: Devices, buses and hotplug

Geert Uytterhoeven (Geert.Uytterhoeven@cs.kuleuven.ac.be)
Mon, 7 Jun 1999 17:30:58 +0200 (CEST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Davide Libenzi: "O(1) scheduler need help ... (resend)"
- Previous message: Petr Vandrovec Ing. VTEI: "Re: [RFC] new bus architecture (+ byte-endianess)"
- In reply to: David S. Miller: "Re: RFC: Devices, buses and hotplug"
- Next in thread: David S. Miller: "Re: RFC: Devices, buses and hotplug"

On Mon, 7 Jun 1999, David S. Miller wrote:
> Date: Mon, 7 Jun 1999 15:08:23 +0200 (CEST)
> From: Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be>
>
> The Open Firmware specs explicitly state that the frame buffer must
> be big endian.
>
> And this means?
>
> Nothing stops you from using the frame buffer in little endian mode in
> the kernel. On Sparc we do many things which are against the
> environment OpenFirmware expects.
>
> But when we must go into the OpenFirmware we restore much of the
> environment (in fact if you break out to the firmware prompt, we
> restore the palette of the framebuffer etc.).
>
> Also you can use different mappings for the frame buffer than what the
> firmware uses.
>
> All in all, firmware can say all it wants, it has no bearing on how
> the kernel accesses the framebuffer, and thus it should not tie our
> hands about how we do so.

True.

But at least offb (the Open Firmware frame buffer device driver we use for
boards without a real driver) should have a big endian fbcon-cfb8 since OF
provides a big endian frame buffer only. On most other boards we could use the
little endian aperture.

Besides, I think we'll end up with two versions (little and big endian) of all
fbcon-* drivers anyway on some platforms. Imagine an Amiga with APUS (PPC
board) and two graphics cards:

- a Zorro III board on the motherboard, in big endian mode
- a Permedia II board on the PCI bus of the APUS, in little endian mode

You can say `doh, {read,write}l() should test for the addresses and behave
different for Zorro and PCI' (either through explicit tests or through (yuck)
function pointers), but you don't really want that overhead for the text
console, do you?

Greetings,

Geert

    --
    Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
    Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
    Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium

    -
    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/

- Next message: Davide Libenzi: "O(1) scheduler need help ... (resend)"
- Previous message: Petr Vandrovec Ing. VTEI: "Re: [RFC] new bus architecture (+ byte-endianess)"
- In reply to: David S. Miller: "Re: RFC: Devices, buses and hotplug"
- Next in thread: David S. Miller: "Re: RFC: Devices, buses and hotplug"