Re: Resource map sanity check fails after GRUB "keeps" the gfx mode

[Pavel Roskin <proski-mXXj517/zsQ@public.gmane.org>]

Hi David,

On Thu, 3 Oct 2013 00:19:56 +0200
David Herrmann <dh.herrmann-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> >> And your PCI-BAR adjustment doesn't change
> >> anything either, sorry.
> >
> > I simply tried another approach to pacify the resource checker.
> >
> > However, there is some difference.  nvidiafb cannot access the
> > resources if IORESOURCE_BUSY is used.
> 
> Are you sure this is related to IORESOURCE_BUSY? Or is it related to
> CONFIG_X86_SYSFB?

CONFIG_X86_SYSFB is always defined.  I doubt an x86 kernel would
compile without it.  create_simplefb() is used in
arch/x86/kernel/sysfb.c that is compiled unconditionally and that
function is defined in arch/x86/kernel/sysfb_simplefb.c that is only
compiled if CONFIG_X86_SYSFB is defined.

I tried four combinations: with and without IORESOURCE_BUSY and with
and without the PCI resource adjustment.  The only combination when
nvidiafb probes the hardware is when IORESOURCE_BUSY is not used and
the BOOTFP resource is adjusted to match the PCI BAR.

It means that your patch by itself won't prevent nvidiafb from getting
the resource on my hardware (ThinkPad W530).  However, if the BOOTFP
resource matches the PCI BAR for the video card, adding IORESOURCE_BUSY
might prevent some framebuffer drivers from accessing the resource.

This complexity doesn't seem right.  I think specific drivers should
trump generic once and DRI drivers should trump non-DRI.  It shouldn't
matter whether the BOOTFP area from screen_info coincides with the PCI
BAR or occupies a part of it.

-- 
Regards,
Pavel Roskin