From: Filip S. <fs...@st...> - 2002-06-11 16:00:19
|
On Mon, 10 Jun 2002, Brian S. Julin wrote: > > On Mon, 10 Jun 2002, Filip Spacek wrote: > > After a long discussion with Paul Redmond, we have come up with a list of > > things that currently need fixing in KGI. > > Sounds good to me. OK, well ONE thing :-) -- > > > Since most modern card have integrated ramdac and clocks kgim needs to be > > able to handle display drivers with only a chipset subsystem. Every > > subsystem should be optional. Only the subsystems specified in the .spec > > file should be used. > > I would put this low on the list. The only problem I've seen with the > current system is extra shim code and a lack of a solution to weird > chips like some old WD laptop sets where the chipset and clock need to > have a little private discussion about the speed of the memory refresh > clock. > > Changing the current system would be more of an overhaul than you may > suspect, because there are a lot of nuances in the checkmode/setmode > loop that are not immediately obvious, and the whole timing situation > is a can of worms waiting to be opened. > > Plus, even though they are integrated, very often the onboard clocks > appear on more than one IC and only need to have a few constants changed > to use the same driver code as another IC. I think a lot of the > IC-specific clock drivers we have in there now are only there because > the authors didn't want to invest the time at the moment to improve > the "generic" drivers to where they could simply be passed their params > when the modules were assembled into a display. > The problem I have with the current separation on integrated chipsets is that it isn't just a little bit of code. Until I implemented a CLUT resource in the MACH64 RAMDAC subsystem, the subsystem didn't do absolutely anything. That's a total of 12K of dead code. For MACH64 the separation needs to be kept since the older GX chipsets use different clocks and ramdacs but for newer cards it amounts to a lot of wasted code, memory and effort to make it do what you want (which is nothing at all). I do realize that it's no trivial matter to remove the unneeded subsystems (I've been bitten by the timing command system many a time), but since we were planing to overhaul kgim to fix the monitor situation, I figured I'd attempt to look into this too. Fixing up the generic clock system is a good idea though. I'll definitely look into making it flexible enough for anybody's needs (better way of specifying post dividers and so on) -Filip |