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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
