All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: DRI Development <dri-devel@lists.freedesktop.org>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Daniel Vetter <daniel.vetter@intel.com>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Javier Martinez Canillas <javierm@redhat.com>,
	Helge Deller <deller@gmx.de>,
	linux-fbdev@vger.kernel.org
Subject: [PATCH 5/8] video/aperture: Move vga handling to pci function
Date: Tue,  4 Apr 2023 22:18:39 +0200	[thread overview]
Message-ID: <20230404201842.567344-5-daniel.vetter@ffwll.ch> (raw)
In-Reply-To: <20230404201842.567344-1-daniel.vetter@ffwll.ch>

A few reasons for this:

- It's really the only one where this matters. I tried looking around,
  and I didn't find any non-pci vga-compatible controllers for x86
  (since that's the only platform where we had this until a few
  patches ago), where a driver participating in the aperture claim
  dance would interfere.

- I also don't expect that any future bus anytime soon will
  not just look like pci towards the OS, that's been the case for like
  25+ years by now for practically everything (even non non-x86).

- Also it's a bit funny if we have one part of the vga removal in the
  pci function, and the other in the generic one.

v2: Rebase.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Helge Deller <deller@gmx.de>
Cc: linux-fbdev@vger.kernel.org
---
 drivers/video/aperture.c | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c
index 552cffdb827b..ec9387d94049 100644
--- a/drivers/video/aperture.c
+++ b/drivers/video/aperture.c
@@ -298,14 +298,6 @@ int aperture_remove_conflicting_devices(resource_size_t base, resource_size_t si
 
 	aperture_detach_devices(base, size);
 
-	/*
-	 * If this is the primary adapter, there could be a VGA device
-	 * that consumes the VGA framebuffer I/O range. Remove this device
-	 * as well.
-	 */
-	if (primary)
-		aperture_detach_devices(VGA_FB_PHYS_BASE, VGA_FB_PHYS_SIZE);
-
 	return 0;
 }
 EXPORT_SYMBOL(aperture_remove_conflicting_devices);
@@ -342,6 +334,13 @@ int aperture_remove_conflicting_pci_devices(struct pci_dev *pdev, const char *na
 	}
 
 	if (primary) {
+		/*
+		 * If this is the primary adapter, there could be a VGA device
+		 * that consumes the VGA framebuffer I/O range. Remove this
+		 * device as well.
+		 */
+		aperture_detach_devices(VGA_FB_PHYS_BASE, VGA_FB_PHYS_SIZE);
+
 		/*
 		 * WARNING: Apparently we must kick fbdev drivers before vgacon,
 		 * otherwise the vga fbdev driver falls over.
-- 
2.40.0


WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: DRI Development <dri-devel@lists.freedesktop.org>
Cc: linux-fbdev@vger.kernel.org,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Javier Martinez Canillas <javierm@redhat.com>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Daniel Vetter <daniel.vetter@intel.com>,
	Helge Deller <deller@gmx.de>
Subject: [PATCH 5/8] video/aperture: Move vga handling to pci function
Date: Tue,  4 Apr 2023 22:18:39 +0200	[thread overview]
Message-ID: <20230404201842.567344-5-daniel.vetter@ffwll.ch> (raw)
In-Reply-To: <20230404201842.567344-1-daniel.vetter@ffwll.ch>

A few reasons for this:

- It's really the only one where this matters. I tried looking around,
  and I didn't find any non-pci vga-compatible controllers for x86
  (since that's the only platform where we had this until a few
  patches ago), where a driver participating in the aperture claim
  dance would interfere.

- I also don't expect that any future bus anytime soon will
  not just look like pci towards the OS, that's been the case for like
  25+ years by now for practically everything (even non non-x86).

- Also it's a bit funny if we have one part of the vga removal in the
  pci function, and the other in the generic one.

v2: Rebase.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Helge Deller <deller@gmx.de>
Cc: linux-fbdev@vger.kernel.org
---
 drivers/video/aperture.c | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c
index 552cffdb827b..ec9387d94049 100644
--- a/drivers/video/aperture.c
+++ b/drivers/video/aperture.c
@@ -298,14 +298,6 @@ int aperture_remove_conflicting_devices(resource_size_t base, resource_size_t si
 
 	aperture_detach_devices(base, size);
 
-	/*
-	 * If this is the primary adapter, there could be a VGA device
-	 * that consumes the VGA framebuffer I/O range. Remove this device
-	 * as well.
-	 */
-	if (primary)
-		aperture_detach_devices(VGA_FB_PHYS_BASE, VGA_FB_PHYS_SIZE);
-
 	return 0;
 }
 EXPORT_SYMBOL(aperture_remove_conflicting_devices);
@@ -342,6 +334,13 @@ int aperture_remove_conflicting_pci_devices(struct pci_dev *pdev, const char *na
 	}
 
 	if (primary) {
+		/*
+		 * If this is the primary adapter, there could be a VGA device
+		 * that consumes the VGA framebuffer I/O range. Remove this
+		 * device as well.
+		 */
+		aperture_detach_devices(VGA_FB_PHYS_BASE, VGA_FB_PHYS_SIZE);
+
 		/*
 		 * WARNING: Apparently we must kick fbdev drivers before vgacon,
 		 * otherwise the vga fbdev driver falls over.
-- 
2.40.0


WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: DRI Development <dri-devel@lists.freedesktop.org>
Cc: linux-fbdev@vger.kernel.org,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Javier Martinez Canillas <javierm@redhat.com>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Daniel Vetter <daniel.vetter@intel.com>,
	Helge Deller <deller@gmx.de>
Subject: [Intel-gfx] [PATCH 5/8] video/aperture: Move vga handling to pci function
Date: Tue,  4 Apr 2023 22:18:39 +0200	[thread overview]
Message-ID: <20230404201842.567344-5-daniel.vetter@ffwll.ch> (raw)
In-Reply-To: <20230404201842.567344-1-daniel.vetter@ffwll.ch>

A few reasons for this:

- It's really the only one where this matters. I tried looking around,
  and I didn't find any non-pci vga-compatible controllers for x86
  (since that's the only platform where we had this until a few
  patches ago), where a driver participating in the aperture claim
  dance would interfere.

- I also don't expect that any future bus anytime soon will
  not just look like pci towards the OS, that's been the case for like
  25+ years by now for practically everything (even non non-x86).

- Also it's a bit funny if we have one part of the vga removal in the
  pci function, and the other in the generic one.

v2: Rebase.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Helge Deller <deller@gmx.de>
Cc: linux-fbdev@vger.kernel.org
---
 drivers/video/aperture.c | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c
index 552cffdb827b..ec9387d94049 100644
--- a/drivers/video/aperture.c
+++ b/drivers/video/aperture.c
@@ -298,14 +298,6 @@ int aperture_remove_conflicting_devices(resource_size_t base, resource_size_t si
 
 	aperture_detach_devices(base, size);
 
-	/*
-	 * If this is the primary adapter, there could be a VGA device
-	 * that consumes the VGA framebuffer I/O range. Remove this device
-	 * as well.
-	 */
-	if (primary)
-		aperture_detach_devices(VGA_FB_PHYS_BASE, VGA_FB_PHYS_SIZE);
-
 	return 0;
 }
 EXPORT_SYMBOL(aperture_remove_conflicting_devices);
@@ -342,6 +334,13 @@ int aperture_remove_conflicting_pci_devices(struct pci_dev *pdev, const char *na
 	}
 
 	if (primary) {
+		/*
+		 * If this is the primary adapter, there could be a VGA device
+		 * that consumes the VGA framebuffer I/O range. Remove this
+		 * device as well.
+		 */
+		aperture_detach_devices(VGA_FB_PHYS_BASE, VGA_FB_PHYS_SIZE);
+
 		/*
 		 * WARNING: Apparently we must kick fbdev drivers before vgacon,
 		 * otherwise the vga fbdev driver falls over.
-- 
2.40.0


  parent reply	other threads:[~2023-04-04 20:18 UTC|newest]

Thread overview: 112+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-04 20:18 [PATCH 1/8] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers Daniel Vetter
2023-04-04 20:18 ` [Intel-gfx] " Daniel Vetter
2023-04-04 20:18 ` [PATCH 2/8] video/aperture: use generic code to figure out the vga default device Daniel Vetter
2023-04-04 20:18   ` [Intel-gfx] " Daniel Vetter
2023-04-04 20:18   ` Daniel Vetter
2023-04-05 11:27   ` Javier Martinez Canillas
2023-04-05 11:27     ` Javier Martinez Canillas
2023-04-05 11:27     ` [Intel-gfx] " Javier Martinez Canillas
2023-04-04 20:18 ` [PATCH 3/8] drm/aperture: Remove primary argument Daniel Vetter
2023-04-04 20:18   ` Daniel Vetter
2023-04-04 20:18   ` Daniel Vetter
2023-04-04 20:18   ` [Intel-gfx] " Daniel Vetter
2023-04-04 20:18   ` Daniel Vetter
2023-04-04 21:20   ` Martin Blumenstingl
2023-04-04 21:20     ` [Intel-gfx] " Martin Blumenstingl
2023-04-04 21:20     ` Martin Blumenstingl
2023-04-04 21:20     ` Martin Blumenstingl
2023-04-04 21:20     ` Martin Blumenstingl
2023-04-05  9:25   ` Thierry Reding
2023-04-05  9:25     ` Thierry Reding
2023-04-05  9:25     ` Thierry Reding
2023-04-05  9:25     ` Thierry Reding
2023-04-05  9:25     ` [Intel-gfx] " Thierry Reding
2023-04-05 11:30   ` Javier Martinez Canillas
2023-04-05 11:30     ` Javier Martinez Canillas
2023-04-05 11:30     ` Javier Martinez Canillas
2023-04-05 11:30     ` Javier Martinez Canillas
2023-04-05 11:30     ` Javier Martinez Canillas
2023-04-04 20:18 ` [PATCH 4/8] video/aperture: Only kick vgacon when the pdev is decoding vga Daniel Vetter
2023-04-04 20:18   ` [Intel-gfx] " Daniel Vetter
2023-04-04 20:18   ` Daniel Vetter
2023-04-05 11:31   ` Javier Martinez Canillas
2023-04-05 11:31     ` [Intel-gfx] " Javier Martinez Canillas
2023-04-05 11:31     ` Javier Martinez Canillas
2023-04-04 20:18 ` Daniel Vetter [this message]
2023-04-04 20:18   ` [Intel-gfx] [PATCH 5/8] video/aperture: Move vga handling to pci function Daniel Vetter
2023-04-04 20:18   ` Daniel Vetter
2023-04-05 11:34   ` Javier Martinez Canillas
2023-04-05 11:34     ` Javier Martinez Canillas
2023-04-05 11:34     ` [Intel-gfx] " Javier Martinez Canillas
2023-04-04 20:18 ` [PATCH 6/8] video/aperture: Drop primary argument Daniel Vetter
2023-04-04 20:18   ` [Intel-gfx] " Daniel Vetter
2023-04-04 20:18   ` Daniel Vetter
2023-04-05 11:36   ` Javier Martinez Canillas
2023-04-05 11:36     ` Javier Martinez Canillas
2023-04-05 11:36     ` [Intel-gfx] " Javier Martinez Canillas
2023-04-04 20:18 ` [PATCH 7/8] video/aperture: Only remove sysfb on the default vga pci device Daniel Vetter
2023-04-04 20:18   ` [Intel-gfx] " Daniel Vetter
2023-04-04 20:18   ` Daniel Vetter
2023-04-04 20:59   ` Aaron Plattner
2023-04-04 20:59     ` Aaron Plattner
2023-04-04 20:59     ` [Intel-gfx] " Aaron Plattner
2023-04-05  8:48     ` Daniel Vetter
2023-04-05  8:48       ` [Intel-gfx] " Daniel Vetter
2023-04-05  8:48       ` Daniel Vetter
2023-04-05 11:37   ` Javier Martinez Canillas
2023-04-05 11:37     ` Javier Martinez Canillas
2023-04-05 11:37     ` [Intel-gfx] " Javier Martinez Canillas
2023-04-04 20:18 ` [PATCH 8/8] fbdev: Simplify fb_is_primary_device for x86 Daniel Vetter
2023-04-04 20:18   ` [Intel-gfx] " Daniel Vetter
2023-04-05 11:40   ` Javier Martinez Canillas
2023-04-05 11:40     ` [Intel-gfx] " Javier Martinez Canillas
2023-04-04 23:44 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/8] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers Patchwork
2023-04-04 23:44 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2023-04-04 23:51 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-04-05  7:49 ` [PATCH 1/8] " Thomas Zimmermann
2023-04-05  7:49   ` [Intel-gfx] " Thomas Zimmermann
2023-04-05  8:05   ` Patrik Jakobsson
2023-04-05  8:05     ` [Intel-gfx] " Patrik Jakobsson
2023-04-05  8:15     ` Thomas Zimmermann
2023-04-05  8:15       ` [Intel-gfx] " Thomas Zimmermann
2023-04-05  8:07   ` Thomas Zimmermann
2023-04-05  8:07     ` [Intel-gfx] " Thomas Zimmermann
2023-04-05  8:59     ` Daniel Vetter
2023-04-05  8:59       ` [Intel-gfx] " Daniel Vetter
2023-04-05  9:26       ` Thomas Zimmermann
2023-04-05  9:26         ` [Intel-gfx] " Thomas Zimmermann
2023-04-05  9:38         ` Daniel Vetter
2023-04-05  9:38           ` [Intel-gfx] " Daniel Vetter
2023-04-05 11:00           ` Thomas Zimmermann
2023-04-05 11:00             ` [Intel-gfx] " Thomas Zimmermann
2023-04-05 11:16             ` Javier Martinez Canillas
2023-04-05 11:16               ` [Intel-gfx] " Javier Martinez Canillas
2023-04-05 13:18               ` Daniel Vetter
2023-04-05 13:18                 ` [Intel-gfx] " Daniel Vetter
2023-04-05 14:32                 ` Thomas Zimmermann
2023-04-05 14:32                   ` [Intel-gfx] " Thomas Zimmermann
2023-04-05 16:02                   ` Daniel Vetter
2023-04-05 16:02                     ` [Intel-gfx] " Daniel Vetter
2023-04-05 16:54                     ` Javier Martinez Canillas
2023-04-05 16:54                       ` [Intel-gfx] " Javier Martinez Canillas
2023-04-05 17:14                       ` Daniel Vetter
2023-04-05 17:14                         ` [Intel-gfx] " Daniel Vetter
2023-04-05 17:43                         ` Javier Martinez Canillas
2023-04-05 17:43                           ` [Intel-gfx] " Javier Martinez Canillas
2023-04-05 17:46                         ` Patrik Jakobsson
2023-04-06  7:31                           ` Daniel Vetter
2023-04-06 11:16                             ` Patrik Jakobsson
2023-04-05  8:19 ` Thomas Zimmermann
2023-04-05  8:19   ` [Intel-gfx] " Thomas Zimmermann
2023-04-05  9:09   ` Daniel Vetter
2023-04-05  9:09     ` [Intel-gfx] " Daniel Vetter
2023-04-05 10:10 ` [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/8] " Patchwork
2023-04-06  7:14 ` [PATCH 1/8] " Thomas Zimmermann
2023-04-06  7:14   ` [Intel-gfx] " Thomas Zimmermann
2023-04-06  8:38   ` Javier Martinez Canillas
2023-04-06  8:38     ` [Intel-gfx] " Javier Martinez Canillas
2023-04-06  8:49     ` Thomas Zimmermann
2023-04-06  8:49       ` [Intel-gfx] " Thomas Zimmermann
2023-04-06  9:05       ` Javier Martinez Canillas
2023-04-06  9:05         ` [Intel-gfx] " Javier Martinez Canillas
2023-04-06  9:05 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/8] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers (rev2) Patchwork

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=20230404201842.567344-5-daniel.vetter@ffwll.ch \
    --to=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=deller@gmx.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=javierm@redhat.com \
    --cc=linux-fbdev@vger.kernel.org \
    --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.