-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Dec 23, 2006, at 05:18, Vincent wrote:

> Michael Lorenz =E9crit :
>
>> Thanks.
>> Hmm, so you r display does provide EDID data after all. I didn't see=20=

>> any EDID stuff in your dmesg output but since the default mode used=20=

>> by radeonfb is the same as what your display reports that doesn't=20
>> matter for now.
>
> It is supposed to do so?

Yes. And at least on my iBook it works just fine. To my surprise I=20
might add.

>> Xorg apparently manages to get data out of the BIOS - probably by=20
>> calling it which we can't really do in a supposedly=20
>> machine-independent driver ( the same thing works just fine on my=20
>> iBook for instance ) - to do this we'd have to split up the driver=20
>> into machine dependent parts.
>
> I think Xorg scans all the PCI bus, detects overlaps, and decides to=20=

> map the video BIOS in a hole.

Maybe - when X is up you can have a look with pcictl if there's=20
something else than 0x00000000 in the ROM BAR - somehow I doubt it. In=20=

fact I think there's no dedicated video BIOS ROM and video BIOS is part=20=

of the main BIOS.

> That we can't do at start, because the attach process do not keep=20
> track of the (yet) allocated PCI addresses and range, as far as I=20
> know. Which is a pity.

Well, that's not entirely true:
- - on most architectures that's the firmware's job ( be it a PCI BIOS,=20=

OpenFirmware or whatever )
- - on other architectures NetBSD does that all itself ( mostly embedded=20=

IIRC )
- - on most architectures there's code to fix mistakes made by the=20
firmware ( like overlaps, missing bus numbers, wrong IRQs, set up=20
devices the firmware 'forgot', etc. )

What you could do is:
- - find a safe address range for the ROM BAR ( usually you'll need 64kB=20=

or 128kB )
- - use pcitweak to set the address and enable the ROM
- - write a little program that mmap()s the ROM via /dev/mem ( just open=20=

/dev/mem for reading, use the address you picked as offset for mmap() )=20=

and see what's there. If you get SIGBUS, SIGSEGV or bogus data ( like=20
all 0x00000000 or 0xffffffff ) then there's likely no ROM.

Hmm, maybe it makes sense to have radeonfb look at the 'traditional'=20
physical address of the video BIOS and cross fingers.

>> Does CRT output work with radeonfb? A halfway modern monitor might=20
>> give some hints how exactly frequencies are screwed up ( like=20
>> doubled, completely off or whatever - might be interesting since all=20=

>> clocks are generated from one reference clock and ATI did pull some=20=

>> stunts with that in the past with some mach64 using ~14.7MHz, others=20=

>> ~29.4MHz )
>
> I've not tested CRT output yet, will do that now.
>
That would at least tell us if radeonfb doesn't feed the panel the=20
right way or if there's something more fundamental wrong.

have fun
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBRY2PuMpnzkX8Yg2nAQKHAggAu0XFHCZZ4g4o0cht6hWEwkIsW9FwBgWz
kXuFNU36MoerIIh5B6ICuy+BcXTpldirtChLGEFA6RU4y8LqR5R5MruZzdLARs4o
WHZN7eirPKJyQc3K8CXK59PbKzsY66mdPVMzJd82vi8lvCfskgmHkMMKkGby8vZ2
UruiBDFOmhMGerZLmUqKUqWTekWxaJZ32vChjXsXeZQVWh1337WA5rt+zG1tQZWH
rvQzB2otwRp7OmH0tHmdLRNbmkyxIMPUArgPdOZP2tut4TeaWzuCBV6V1CK5qAGf
W9aII5FFitfxcfMhVb90rB4+dudPX6z+sVcutvWqWjA4jRbxNtq26g=3D=3D
=3D5dk7
-----END PGP SIGNATURE-----