[PATCH] New radeonfb fork

[PATCH] New radeonfb fork

[Benjamin Herrenschmidt]

Hi !

As I told a while ago, I'm forking radeonfb for now, at least
until Ani (current maintainer) either give me maintainership
or gets all that stuff in the official version.

I need testers, and I'd appreciate any patches people may have
for it as well since I know a bunch of ppl have been spreading
various radeonfb patches around, I want to take over all of these
and see what is worth getting in. For 2.5, I'm working on a
complete rewrite (& split) of the driver.

So far, I already have something to play with that fixes a
bunch of issues. Patches against 2.4.20 and 2.4.21-pre7 can
be found here: (too big to inline). Note that I also bring
in various other pci_ids.h updates but that shouldn't harm
you and is easier that way for me ;)

http://penguinppc.org/~benh/radeonfb-040603-2.4.20.diff
http://penguinppc.org/~benh/radeonfb-040603-2.4.21-pre7.diff

NOTE: It's known that radeonfb is incompatible with ATI binary
GL drivers (at least it crashes the machine on a friend's r300),
I'm investigating.

Ben.

Re: [PATCH] New radeonfb fork

[Daniele Venzano]

[-- Attachment #1: Type: text/plain, Size: 1395 bytes --]

I tried your patch for Radeon framebuffer on kernel 2.4.21-pre7, it
works better than before, but still I have some problems:

the cursor is visible only at 8 bit depth, with 16 or 32 bit it just
disappears, and at 8 bit it is a big full scale rectangular cursor
(no underline).

I couldn't find a way to set the resolution at boot time (I use the
driver compiled in), I tried the following, all being ignored:
radeonfb:1024x768-8@60
radeon:1024x768-8@60

I am using an ugly fbset in a random boot script, but it just changes the
resolution for the first console. This is probably the biggest problem I
saw until now...

Finally dmesg says:

PCI: Found IRQ 11 for device 01:00.0
radeonfb: ref_clk=2700, ref_div=12, xclk=20000 from BIOS
Console: switching to colour frame buffer device 80x30
radeonfb: ATI Radeon 9000 If DDR SGRAM 64 MB
radeonfb: DVI port no monitor connected
radeonfb: CRT port CRT monitor connected
                   ^^^
But I have an LCD on the CRT port, I saw some LCD support in radeonfb.c,
but perhaps it was only on DVI port.

I have a:
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R250 If [Radeon 9000] (rev 01)

with 64Mb DDR on a PIII 500Mhz, Asus P3C2000 (i820 chipset) motherboard.

Thanks for your work.

-- 
----------------------------------------
Daniele Venzano
Web: http://digilander.iol.it/webvenza/


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] New radeonfb fork

[Benjamin Herrenschmidt]

On Thu, 2003-04-10 at 10:46, Daniele Venzano wrote:
> I tried your patch for Radeon framebuffer on kernel 2.4.21-pre7, it
> works better than before, but still I have some problems:
> 
> the cursor is visible only at 8 bit depth, with 16 or 32 bit it just
> disappears, and at 8 bit it is a big full scale rectangular cursor
> (no underline).

Known problem with fbdev's in 2.4. I have to find out if
that can be fixed easily, though implementing HW cursor would
cure it as well...

> I couldn't find a way to set the resolution at boot time (I use the
> driver compiled in), I tried the following, all being ignored:
> radeonfb:1024x768-8@60
> radeon:1024x768-8@60

That should work (the second one actually), I'll investigate why
it doesn't. What mode do you get instead ?

Make sure you used "video=", that is you should have on your kernel
command line video=radeon:1024x768-8@60

> I am using an ugly fbset in a random boot script, but it just changes the
> resolution for the first console. This is probably the biggest problem I
> saw until now...

Use fbset -a

> Finally dmesg says:
> 
> PCI: Found IRQ 11 for device 01:00.0
> radeonfb: ref_clk=2700, ref_div=12, xclk=20000 from BIOS
> Console: switching to colour frame buffer device 80x30
> radeonfb: ATI Radeon 9000 If DDR SGRAM 64 MB
> radeonfb: DVI port no monitor connected
> radeonfb: CRT port CRT monitor connected
>                    ^^^
> But I have an LCD on the CRT port, I saw some LCD support in radeonfb.c,
> but perhaps it was only on DVI port.

If it's connected to an analgog VGA output, it is considered as a CRT
and that's normal, there's nothing "smart" I can do about it. I could
probably figure out it's a flat panel from the EDID and default to a
better mode, but complete EDID & DDC management is something I don't
plan on implementing in 2.4 though I will do it in 2.5/2.6 as soon
as I get enough time.

Ben.

Re: [PATCH] New radeonfb fork

[Daniele Venzano]

On Thu, Apr 10, 2003 at 04:26:16PM +0200, Benjamin Herrenschmidt wrote:
> > I couldn't find a way to set the resolution at boot time (I use the
> > driver compiled in), I tried the following, all being ignored:
> > radeonfb:1024x768-8@60
> > radeon:1024x768-8@60
> 
> Make sure you used "video=", that is you should have on your kernel
> command line video=radeon:1024x768-8@60

That made it work 8) thanks.
But there is something curious, with video=radeon:1024x768-8@60 I get:

renditai:~# fbset

mode "1024x768-60"
    # D: 65.003 MHz, H: 48.365 kHz, V: 60.006 Hz
    geometry 1024 768 1024 768 8
    timings 15384 168 8 29 3 144 6
    accel true
    rgba 8/0,8/0,8/0,0/0
endmode
					
But with fbset "1024x768-60" I get:

renditai:~# fbset

mode "1024x768-60"
    # D: 64.998 MHz, H: 48.362 kHz, V: 60.002 Hz
    geometry 1024 768 1024 768 8
    timings 15385 160 24 29 3 136 6
    accel true
    rgba 8/0,8/0,8/0,0/0
endmode

There's very little difference, but I was expecting to get the same
mode. I'll go read how that modedb stuff works...

Thanks again, bye.

-- 
----------------------------------------
Daniele Venzano
Web: http://digilander.iol.it/webvenza/

Re: [PATCH] New radeonfb fork

[Benjamin Herrenschmidt]

On Thu, 2003-04-10 at 23:13, Daniele Venzano wrote:

> There's very little difference, but I was expecting to get the same
> mode. I'll go read how that modedb stuff works...

The mode asked during boot comes from the in-kernel modedb,
the mode passed in by fbset comes from fbset own files
/etc/fb.modes

This is not very consistent, I hope /etc/fb.modes can be
deprecated one day once we have proper mode management in
the kernel, something Tony Dapalas have been working on
lately.


Ben.

Re: [PATCH] New radeonfb fork

[James Simmons]

For the new radeonfb driver will you be switching to DMA mode now that the 
fbdev can support it?

Re: [PATCH] New radeonfb fork

[Benjamin Herrenschmidt]

On Fri, 2003-04-11 at 20:23, James Simmons wrote:
> For the new radeonfb driver will you be switching to DMA mode now that the 
> fbdev can support it?

Not at first. There is already much I can do without that, and that
requires proper setup of the card's internal memory map, which I
want to avoid until I've figured out with ATI how to make that
compatible between radeonfb, XFree/ATI, ATI binary drivers and
GATOS drivers...

I'm more interested, at first, in getting proper monitor detection
& DDC/EDID stuff and dual head & mirorring support.

Ben.

Re: [PATCH] New radeonfb fork

[Benjamin Herrenschmidt]

On Sun, 2003-04-06 at 19:01, Kronos wrote:
> Nell'articolo <20030406153018$1b2f@gated-at.bofh.it> hai scritto:
> > Note that I also bring
> > in various other pci_ids.h updates but that shouldn't harm
> > you and is easier that way for me ;)
>
> Hi Ben,
> your patch breaks ide-pci.c. PCI_DEVICE_ID_CMD_680 and
> PCI_DEVICE_ID_PDC_1841 aren't defined any more. This patch fixes the
> compilation:

Ah, sorry, I updated pci_ids.h to 2.4.21 level along with the patch,
that must be the cause.

I'll update the patch tomorrow, I lack time today though, except if
you can send me a patch against the patch (just revert the entries
in pci_ids.h then).

Ben.