re: i386 vs radeondrmkms problem - isa attachments suck

[matthew green <mrg%eterna.com.au@localhost>]

Brian Buhrow writes:
> 	hello.  Here is a very naive question.  Could the vga driver be
> altered to not do its mapping until the Radeon, or other graphics driver,
> has had a chance to map and/or attach?
> 
> 	To solve the loss of the printed copyright messages, perhaps a buffer
> could be allocated, much like the dmesg buffer, which could be written to
> while things are still attaching.  Then, once all is attached, a function
> could be called to print the contents of the accumulated buffer to the
> final, correct, device.  Doing things this way could also allow us to have 
> serial consoles using usb attached serial ports.  I've thought about trying
> something like this, but haven't gotten  frustrated enough yet to do it.

i think the diagnostic benefit of having console messages appear as
soon as they're printed is too important to give up.

it's already bad enough right now when drmkms takes over and the 
display goes blank for a couple of seconds (on my laptop, suddenly
/etc/rc has completed a bunch of early tasks by the time it turns
back on.)

ie, i think we should do our best to keep these timely as much as
possible, and in this case, we can kind of just ignore that they've
been initialiised initially for the console, as drm takes over and
we won't access them as VGA again.  mlelstv has been working on
making vga detach actually work properly lately, and when that is
finished, we may have a true non-super-ugly solution.

all that said, what you mention about delayed console isn't a bad
idea -- i'd like to be able to have multiple console output as well,
like linux has provided with 'console=vga console=com1' since at
least 2.4 days...


.mrg.

> Thoughts?
> 
> -Brian
> 
> On Mar 4,  9:10am, matthew green wrote:
> } Subject: re: i386 vs radeondrmkms problem - isa attachments suck
> } 
> } > > Is the ignoring of attach priority a general characteristic of
> } > > indirect buses, and might it make sense for config to be able to
> } > > explicitly prioritise the order the cfdata[] entries? I know uebayasi@
> } > > has been rototilling config and wondered if he could be interested...
> } > > :)
> } > 
> } > The problem is that there is no notion of priority for indirect buses
> } > because it is up to the attaching driver to determine if it should
> } > attach or not.
> } > 
> } > You could imagine working around that by adding code to check whether
> } > two drivers claim conflicting resources, and then the idea of priority
> } > would work.
> } > 
> } > GSoC project maybe?
> } 
> } the problem is that the relevant kernel resources *are already*
> } mapped by the vga driver, just well before it attaches.  that
> } happens before the copyright is printed in consinit().  otherwise
> } we'd get no kernel output..
> } 
> } i have a hack on the radeon@pci driver to do this, and it works..
> } on serial console.
> } 
> } i figured out the ordering problem with doing radeonhack@isa, and
> } got it to attach first, but it doesn't help since vga already has
> } claimed those registers, and knows it should attach, which it
> } does.. and then attaches wsdisplay.
> } 
> } basically, the only real solution is to get vga to give up these
> } entirely (ie, to detach itself and its wsdisplays) and that's
> } proven to be more tricky than hoped.  at this point i'm going with
> } my LEGACY kernel idea.
> } 
> } > I'd actually create a i386-legacy arch and get rid of all the crud in
> } > i386 that deals with stuff built before 2005 or so.  And move that to
> } > tier-infinity and let it die peacefully.
> } 
> } they still sell i586 based systems so this seems like a fairly
> } early cut off.  also sounds a like a lot more effort than simply
> } having an relatively small LEGACY kernel that has it (i'm thinking
> } of releng work, source code additions, etc., not just my effort.)
> } 
> } thanks.
> } 
> } 
> } .mrg.
> >-- End of excerpt from matthew green
> 
>