Re: [patch] [radeonfb] Radeon M26 and ATOM bios support (take 4)

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> I basically have two chunks of remaining code to write:
> 
> 1) The OpenFirmware stuff, which basically requires some re-jiggering of 
>    arguments passed in and return codes.  

Or just write a small howto and I will do the job :) I've been very busy
lately mostly due to my newborn child, thus I didn't help more than
that, but I'm really interested in your work. I also want to bring along
a bunch of fixes like the memory mapping fixes I've been doing on X.org
radeon driver recently.

> 2) User-specified layout code isn't smart enough to try the secondary 
>    connectors if the primary connectors don't have anything connected.
>    (This could be lessened by extending the syntax to explicitly state 
>     CRT,CRT2,DFP,DFP2,etc..)

Agreed. (And X too btw ...)

In fact, we need a way to provide the driver with the full connector
mapping I think, in case it can't be obtained from the firmware.

> Then there's the big open question of how we should allow the user
> to override the connector table, in case we mis-detect or don't have a
> table to begin with.  If we have DDC enabled we can build a 
> connector table by probing all DDC ports, using the existing logic. 

module option is the easy/cheap way but sucks in some ways... sysfs per
device instance is nice but a bit "too late" unless we have a way for
the driver to re-probe... which is a good thing to have anyway since we
might finally deal with screen hotplug :)

In fact, a mix of both might do the trick... module/kernel argument for
a default override and sysfs for "live" override ?

I would however not bother too much at the moment with that. Let's get
the rest working first

> Thoughts?
> 
> (This work builds on the radeon-atom-4 patch, and is definately in the 
>  "heavily experimental" stage.  I'll post a patch once I have time to 
>  clean it up and fix the first two points)

Thanks.

I'll look at your stuff in more detail asap and will then let it simmer
in -mm if I'm happy enough for at least a kernel version...

Ben.




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642