[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
i386 vs radeondrmkms problem - isa attachments suck
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.
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
Main Index |
Thread Index |