Re: [PATCH -mm] video: uvesafb: Add X86 dependency.

[Paul Mundt]

On Tue, Sep 11, 2007 at 01:19:57PM +0100, Paulo Marques wrote:
> Paul Mundt wrote:
> >On Tue, Sep 11, 2007 at 12:41:49PM +0100, Paulo Marques wrote:
> >>[...]
> >>Why do you say that it's x86 specific? Am I missing something?
> >>
> >The emulator it uses only runs on x86 and x86_64. Thus, it's x86
> >specific. The v86d and uvesafb pages seem to be in disagremeent, unless
> >by 'non-x86' it's only implying x86_64.
> >
> >Additionally, it needs the vga I/O routines, as per vgacon. Most
> >platforms don't define these.
> 
> I just saw the v86d emulator code, and you're right. It mmaps /dev/mem 
> and assumes the video BIOS is mapped there.
> 
> We should try to change that to mmap something like 
> "/sys/bus/pci/devices/0000:01:00.0/rom" instead so that it can work on 
> any system with a video card plugged on a PCI bus.
> 
> It should also be possible for the emulator to translate in/out 
> instructions to appropriate memory mapped I/O equivalents, no?
> 
> Anyway, I think it is up to Michal to decide if we should remove the 
> kernel support for other archs, or let it stay a bit more while working 
> on solving the v86d side of things. So I'll just step aside now....
> 
Once v86d is fixed up to get at the ROM directly and the driver uses MMIO
directly, I don't see a problem with unrestricting it. For the time being
however, the build is both broken, and the emulator it uses won't run on
anything but x86, so I see no reason not to add a Kconfig dependency that
reflects this until such a time where it's no longer true.

At least if there's a set of restrictions on something fairly generic,
they tend to be visible, and they also tend to get fixed up over time. We
should however not enable something generically which at the moment is
very much tied to a single platform. Later patches can remove the
dependency at such a time that that assertion no longer holds true.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/