R7.1 roadmap, and additional goals

[Luc Verhaegen]

On Fri, Apr 14, 2006 at 12:56:13PM +1000, Dave Airlie wrote:
> 
> yeah I don't agree with Luc on this either, he has "separated" out the
> driver in the unichrome driver but they are still part of the
> unichrome setup, still use via naming,
> 
> I've separated the Sil164 out in my i830 driver (granted by sil164
> driver does very little), but the it doesn't mention I830 at all, and
> doesn't require anything from the i830 driver other than for it to
> load it..
> 
> Some pieces of Lucs API might be worth re-using but I thought it might
> be a bit over complicated in parts, and still too tightly bound to the
> unichrome codebase to be off any use..
> 
> Dave.
>
It seems that the fact that the string via appears everywhere is the 
reason why my abstraction is deemed bad. Most people think it's bad 
to not prepend XXX to global functions and structs in drivers, but it's 
nothing sed can't handle.

Then there's the fact that it's not poured into modules yet. But what 
use is the tiny bit of loader work needed at this point, when there's no 
second driver making use of this yet. Because that should be the 
criterium for modularity. The last thing we need is more of the "ati 
uses it, let's push our lack of abstraction into xfree86/i2c/" kind of 
modularisation.

Over complicated? Compared to what's needed for TMDS, sure. But TV 
encoders are a whole different ballgame, yet they still need to fit into 
the same abstraction. In my view it still lacks a few things, but what's 
mainly holding me back is ENOHW.

Luc Verhaegen.