Re: i386 vs radeondrmkms problem - isa attachments suck

[David Brownlee <abs%absd.org@localhost>]

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...
:)

> 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.