Re: radeonfb and X800 cards

["Fabio Comolli" <fabio.comolli@gmail.com>]

Hi.
This patch does not work for me.
Relevant part of the dmesg output is:

< ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 16
< radeonfb: Reference=27.00 MHz (RefDiv=7) Memory=330.00 Mhz, System=358.00 MHz
< Device driver i2c-0 lacks bus and class support for being resumed.
< Device driver i2c-1 lacks bus and class support for being resumed.
< Device driver i2c-2 lacks bus and class support for being resumed.
< Device driver i2c-3 lacks bus and class support for being resumed.
< i2c-adapter i2c-2: unable to read EDID block.
< i2c-adapter i2c-2: unable to read EDID block.
< i2c-adapter i2c-2: unable to read EDID block.
<  * Connector 1 is Internal Panel. Head 0, Monitor: LVDS Flat panel
(EDID probed)
<    ddc port: 0, dac: -1, tmds: -1
<  * Connector 2 is VGA. Head -1, Monitor: None
<    ddc port: 2, dac: 0, tmds: -1
< radeonfb: detected LVDS panel size from BIOS: 1280x800
< radeonfb: Dynamic Clock Power Management enabled
< radeonfb (0000:01:00.0): ATI Radeon VS

My card is:

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon
Mobility X700 (PCIE) (prog-if 00 [VGA])
       Subsystem: Hewlett-Packard Company Unknown device 309e
       Flags: bus master, fast devsel, latency 0, IRQ 16
       Memory at d0000000 (32-bit, prefetchable) [size=128M]
       I/O ports at 3000 [size=256]
       Memory at c8100000 (32-bit, non-prefetchable) [size=64K]
       [virtual] Expansion ROM at c8120000 [disabled] [size=128K]
       Capabilities: [50] Power Management version 2
       Capabilities: [58] Express Endpoint IRQ 0
       Capabilities: [80] Message Signalled Interrupts: 64bit+
Queue=0/0 Enable-
       Capabilities: [100] Advanced Error Reporting

Please let me know if you need more details.
Regards,
Fabio




On 5/18/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Thu, 2007-05-17 at 22:29 +0200, Fabio Comolli wrote:
>
> > Is there a reason why this patch can't go upstream?
>
> Yes. A change of that magnitude will most certainly introduce
> regressions. So we can either:
>
>  - Have it in -mm for monthes trying to iron out all of them (and we'll
> miss some). And struggle also since it's hard to track subtle
> regressions with very big patches.
>
>  - Have it split in smaller bits, which make it possible to bisect in
> case of problem, and thus find/correct problems much faster.
>
> That's my main issue with it at this point. But I'm ok going for route
> #1 provided that you guys are willing to help with tracking regressions
> down. That also mean I need to do some serious testing on powermacs
> since those rely very heavily on a working radeonfb.
>
> Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/