Subject: Re: X server on NetBSD/shark 4.0
To: Izumi Tsutsui <email@example.com>
From: Michael Lorenz <macallan@NetBSD.org>
Date: 12/27/2007 11:50:10
-----BEGIN PGP SIGNED MESSAGE-----
On Dec 27, 2007, at 10:27, Izumi Tsutsui wrote:
> macallan@NetBSD.org wrote:
>> If someone would send me a Rev. 4 or
>> older Shark I'd also make chipsfb ( and probably XFree's chips
>> driver ) work - shouldn't be hard, just add the same kind of
>> attachment code as I did for igsfb and fixup chipsfb to work on non-
>> PCI buses.
> I have some piece of code to split sys/dev/pci/chipsfb.c
> into MI dev/ic/chipsfb.c and dev/pci/chipsfb_pci.c, but
> current pci/chipsfb.c has PCI specific ioctls.
> How should they be handled in the MI driver?
Split the chipsfb_ioctl() as well? Personally I don't like those ioctl
()s at all since they allow the Xserver to shuffle BAR mappings around.
> The rest problem is to investigate how we can get
> chipsfb memory address for registers and framebuffers.
Do you have the ct65550 datasheet? If not I can mail it to you or I
think you can still download it from intel.com. You can get the
aperture address from the extended VGA registers if the chip runs in
VLB mode. The aperture only contains the framebuffer and blitter
registers, each in big- and little endian format. All flat panel,
video IO and so on registers are accessible through VGA registers.
In VLB mode the aperture might be little endian only IIRC. One
problem I ran into with igsfb was that I couldn't get the shark to
map the whole aperture into kernel address space, look at the igsfb
attachment code and you'll see what I mean - chipsfb will likely need
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
-----END PGP SIGNATURE-----