On Mon, Mar 02, 2015 at 01:08:04PM +0000, David Brownlee wrote: > On 28 February 2015 at 09:44, matthew green <mrg%eterna.com.au@localhost> wrote: > > > > > > hi folks. > > > > i've been trying to find a least-ugly solution to the radeondrmkms > > on i386 problem. quick summary of what's wrong: > > > > radeondrmkms doesn't complete attachments (and most > > importantly create a wsdisplay) until mountroot completes. > > this means it happens quite late in boot. in i386 GENERIC, > > vga@isa and pcdisplay@isa are still enabled and they will > > attach to the legacy vga device, and present a wsdisplay0 > > to the system. later, radeon0 attaches, and we get a > > wsdisplay1 that has taken over the console output. > > > > this leaves us with a non-working console output, and the inability > > to run X11 even if accessed remotely. > > > > my first attempt (that is currently commited), made the radeondrmkms > > driver attempt to map the isa vga registers to reserve them from the > > vga@isa, and while that worked on my serial console machine, it does > > not work on a normal system due to x86 consinit() attaching the > > basic vga console driver (so we get early console output.) in this > > case, it has already mapped these registers (ie, radeon is unable > > to map them) and the later real attachment knows not to attempt it > > again. so that method doesn't work. > > > > we could have the vga driver detach itself at the right point, but > > that leaves the console detached for quite a while, during the time > > that drm is getting setup (ie, we'd miss several of its early > > messages.) that seems less than desireable. > > > > it was suggested having a fake driver to attach instead of vga and > > thus avoiding the second phase of vga attachment, however this does > > not work due to the way isa indirect attachment works. the first > > match routine that returns non-zero is attached, and the order of > > routines called seems to be something config(1) generates. so having > > a radeon@isa that returns a history priority does nothing if the > > ordering is bad. this means that the current expectation of eg, > > the vga@isa vs pcdisplay@isa drivers (where vga returns a higher > > match) is not used, it just happens that the cfdata[] array has the > > vga@isa entry before pcdisplay@isa. > > 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? > > this is not a problem for the old drm code, as it does not create > > wsdisplay itself, but relies on the vga driver to do so. > > > > (see isa.c:isasearch() config_match*() call for where the first match > > to return non-zero is used.) > > > > any one have any other ideas? at this point to make DRMKMS work for > > i386 on -7, i think we may have to createa a LEGACY kernel that has > > the vga|pcdisplay@isa drivers (and probably no drm at all?), and turn > > these devices off in GENERIC itself, but perhaps someone has a less > > ugly 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. -- Quentin Garnier - cube%cubidou.net@localhost "See the look on my face from staying too long in one place [...] every time the morning breaks I know I'm closer to falling" KT Tunstall, Saving My Face, Drastic Fantastic, 2007.
Attachment:
pgpqfu1Mgn8nm.pgp
Description: PGP signature