All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Helge Deller <deller@gmx.de>
Cc: Thomas Zimmermann <tzimmermann@suse.de>,
	javierm@redhat.com, daniel.vetter@ffwll.ch,
	patrik.r.jakobsson@gmail.com, dri-devel@lists.freedesktop.org,
	Daniel Vetter <daniel.vetter@intel.com>,
	linux-fbdev@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH v5 2/9] video/aperture: use generic code to figure out the vga default device
Date: Tue, 11 Apr 2023 16:36:27 +0200	[thread overview]
Message-ID: <ZDVwa44NvIXWKWrv@phenom.ffwll.local> (raw)
In-Reply-To: <85282243-33a6-a311-0b50-a7edfc4c4c6e@gmx.de>

On Fri, Apr 07, 2023 at 10:54:00PM +0200, Helge Deller wrote:
> On 4/6/23 15:21, Thomas Zimmermann wrote:
> > From: Daniel Vetter <daniel.vetter@ffwll.ch>
> > 
> > Since vgaarb has been promoted to be a core piece of the pci subsystem
> > we don't have to open code random guesses anymore, we actually know
> > this in a platform agnostic way, and there's no need for an x86
> > specific hack. See also commit 1d38fe6ee6a8 ("PCI/VGA: Move vgaarb to
> > drivers/pci")
> > 
> > This should not result in any functional change, and the non-x86
> > multi-gpu pci systems are probably rare enough to not matter (I don't
> > know of any tbh). But it's a nice cleanup, so let's do it.
> > 
> > There's been a few questions on previous iterations on dri-devel and
> > irc:
> > 
> > - fb_is_primary_device() seems to be yet another implementation of
> >    this theme, and at least on x86 it checks for both
> >    vga_default_device OR rom shadowing. There shouldn't ever be a case
> >    where rom shadowing gives any additional hints about the boot vga
> >    device, but if there is then the default vga selection in vgaarb
> >    should probably be fixed. And not special-case checks replicated all
> >    over.
> > 
> > - Thomas also brought up that on most !x86 systems
> >    fb_is_primary_device() returns 0, except on sparc/parisc. But these
> >    2 special cases are about platform specific devices and not pci, so
> >    shouldn't have any interactions.
> 
> Nearly all graphics cards on parisc machines are actually PCI cards,
> but the way we handle the handover to graphics mode with STIcore doesn't
> conflicts with your planned aperture changes.
> So no problem as far as I can see for parisc...

Ah I thought sticore was some very special bus, if those can be pci cards
underneath then I guess some cleanup eventually might be a good idea? For
anything with a pci bus it's rather strange when vgaarb and
fb_is_primary_device() aren't a match ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Helge Deller <deller@gmx.de>
Cc: linux-fbdev@vger.kernel.org, daniel.vetter@ffwll.ch,
	javierm@redhat.com, dri-devel@lists.freedesktop.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH v5 2/9] video/aperture: use generic code to figure out the vga default device
Date: Tue, 11 Apr 2023 16:36:27 +0200	[thread overview]
Message-ID: <ZDVwa44NvIXWKWrv@phenom.ffwll.local> (raw)
In-Reply-To: <85282243-33a6-a311-0b50-a7edfc4c4c6e@gmx.de>

On Fri, Apr 07, 2023 at 10:54:00PM +0200, Helge Deller wrote:
> On 4/6/23 15:21, Thomas Zimmermann wrote:
> > From: Daniel Vetter <daniel.vetter@ffwll.ch>
> > 
> > Since vgaarb has been promoted to be a core piece of the pci subsystem
> > we don't have to open code random guesses anymore, we actually know
> > this in a platform agnostic way, and there's no need for an x86
> > specific hack. See also commit 1d38fe6ee6a8 ("PCI/VGA: Move vgaarb to
> > drivers/pci")
> > 
> > This should not result in any functional change, and the non-x86
> > multi-gpu pci systems are probably rare enough to not matter (I don't
> > know of any tbh). But it's a nice cleanup, so let's do it.
> > 
> > There's been a few questions on previous iterations on dri-devel and
> > irc:
> > 
> > - fb_is_primary_device() seems to be yet another implementation of
> >    this theme, and at least on x86 it checks for both
> >    vga_default_device OR rom shadowing. There shouldn't ever be a case
> >    where rom shadowing gives any additional hints about the boot vga
> >    device, but if there is then the default vga selection in vgaarb
> >    should probably be fixed. And not special-case checks replicated all
> >    over.
> > 
> > - Thomas also brought up that on most !x86 systems
> >    fb_is_primary_device() returns 0, except on sparc/parisc. But these
> >    2 special cases are about platform specific devices and not pci, so
> >    shouldn't have any interactions.
> 
> Nearly all graphics cards on parisc machines are actually PCI cards,
> but the way we handle the handover to graphics mode with STIcore doesn't
> conflicts with your planned aperture changes.
> So no problem as far as I can see for parisc...

Ah I thought sticore was some very special bus, if those can be pci cards
underneath then I guess some cleanup eventually might be a good idea? For
anything with a pci bus it's rather strange when vgaarb and
fb_is_primary_device() aren't a match ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

  reply	other threads:[~2023-04-11 14:36 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-06 13:21 [PATCH v5 0/9] video/aperture: Ignore firmware framebuffers with non-primary devices Thomas Zimmermann
2023-04-06 13:21 ` [PATCH v5 1/9] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers Thomas Zimmermann
2023-04-07 10:27   ` Javier Martinez Canillas
2023-04-06 13:21 ` [PATCH v5 2/9] video/aperture: use generic code to figure out the vga default device Thomas Zimmermann
2023-04-06 13:21   ` Thomas Zimmermann
2023-04-07 20:54   ` Helge Deller
2023-04-07 20:54     ` Helge Deller
2023-04-11 14:36     ` Daniel Vetter [this message]
2023-04-11 14:36       ` Daniel Vetter
2023-04-11 15:25       ` Helge Deller
2023-04-11 15:25         ` Helge Deller
2023-04-13  8:54         ` Daniel Vetter
2023-04-13  8:54           ` Daniel Vetter
2023-04-06 13:21 ` [PATCH v5 3/9] drm/aperture: Remove primary argument Thomas Zimmermann
2023-04-06 13:21   ` Thomas Zimmermann
2023-04-06 13:21   ` Thomas Zimmermann
2023-04-06 13:21   ` Thomas Zimmermann
2023-04-06 13:21 ` [PATCH v5 4/9] video/aperture: Only kick vgacon when the pdev is decoding vga Thomas Zimmermann
2023-04-06 13:21   ` Thomas Zimmermann
2023-04-06 13:21 ` [PATCH v5 5/9] video/aperture: Move vga handling to pci function Thomas Zimmermann
2023-04-06 13:21   ` Thomas Zimmermann
2023-04-06 13:21 ` [PATCH v5 6/9] video/aperture: Drop primary argument Thomas Zimmermann
2023-04-06 13:21   ` Thomas Zimmermann
2023-04-06 13:21 ` [PATCH v5 7/9] video/aperture: Only remove sysfb on the default vga pci device Thomas Zimmermann
2023-04-06 13:21   ` Thomas Zimmermann
2023-04-06 13:21 ` [PATCH v5 8/9] fbdev: Simplify fb_is_primary_device for x86 Thomas Zimmermann
2023-04-06 13:21 ` [PATCH v5 9/9] video/aperture: Provide a VGA helper for gma500 and internal use Thomas Zimmermann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZDVwa44NvIXWKWrv@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=bhelgaas@google.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=deller@gmx.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=javierm@redhat.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=patrik.r.jakobsson@gmail.com \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.