All of lore.kernel.org
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javierm@redhat.com>
To: Daniel Vetter <daniel@ffwll.ch>, Thomas Zimmermann <tzimmermann@suse.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	DRI Development <dri-devel@lists.freedesktop.org>,
	Daniel Vetter <daniel@ffwll.ch>,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [Intel-gfx] [PATCH 1/8] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers
Date: Wed, 05 Apr 2023 18:54:33 +0200	[thread overview]
Message-ID: <87bkk29smu.fsf@minerva.mail-host-address-is-not-set> (raw)
In-Reply-To: <ZC2beu/9inolwIlr@phenom.ffwll.local>

Daniel Vetter <daniel@ffwll.ch> writes:

> On Wed, Apr 05, 2023 at 04:32:19PM +0200, Thomas Zimmermann wrote:

[...]

>> > > > 	/*
>> > > > 	 * WARNING: Apparently we must kick fbdev drivers before vgacon,
>> > > > 	 * otherwise the vga fbdev driver falls over.
>> > > > 	 */
>> > > > 	ret = vga_remove_vgacon(pdev);
>> > 
>> > This isn't enough, we also nuke stuff that's mapping the vga fb range.

Ah, also need aperture_detach_devices(VGA_FB_PHYS_BASE, VGA_FB_PHYS_SIZE) then.

[...]

>> int aperture_remove_legacy_vga_devices(struct pci_dev *pdev)
>> {
>> 	aperture_detach_devices(VGA_FB_PHYS_BASE, VGA_FB_PHYS_SIZE);
>> 
>> 	return vga_remove_vgacon(pdev);
>> }
>> 
>> And that can be called from gma500 and the pci aperture helper.
>
> But you still pass a pci_dev to that helper. Which just doesn't make any
> sense to me (assuming your entire point is that this isn't just a normal
> pci device but some special legacy vga thing), but if we go with (void)
> then there's more refactoring to do because the vga_remove_vgacon also
> wants a pdev.
>
> All so that we don't call aperture_detach_devices() on a bunch of pci
> bars, which apparently is not problem for any other driver, but absolutely
> is a huge problem for gma500 somehow.
>
> I don't understand why.
>

Yeah, agreed that if vga_remove_vgacon() isn't enough and another helper
is needed then starts to get a little silly. Maybe one option is to add a
3rd param to aperture_remove_conflicting_pci_devices() and skip the logic
to iterate over PCI bars and call aperture_remove_conflicting_devices() ?

> Consider this me throwing in the towel. If you&Javier are convinced this
> makes sense please type it up and merge it, but I'm not going to type
> something that just doesn't make sense to me.

Honestly, I would just go with the double drm_aperture_remove_*() helper
calls (your original patch) unless that causes real issues. There is no
point on blocking all your series just for this IMO.

Then latter if Thomas has strong opinions can send a follow-up patch for
the gma500 driver and the aperture helpers.

> -Daniel
>

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat


WARNING: multiple messages have this Message-ID (diff)
From: Javier Martinez Canillas <javierm@redhat.com>
To: Daniel Vetter <daniel@ffwll.ch>, Thomas Zimmermann <tzimmermann@suse.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	DRI Development <dri-devel@lists.freedesktop.org>,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH 1/8] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers
Date: Wed, 05 Apr 2023 18:54:33 +0200	[thread overview]
Message-ID: <87bkk29smu.fsf@minerva.mail-host-address-is-not-set> (raw)
In-Reply-To: <ZC2beu/9inolwIlr@phenom.ffwll.local>

Daniel Vetter <daniel@ffwll.ch> writes:

> On Wed, Apr 05, 2023 at 04:32:19PM +0200, Thomas Zimmermann wrote:

[...]

>> > > > 	/*
>> > > > 	 * WARNING: Apparently we must kick fbdev drivers before vgacon,
>> > > > 	 * otherwise the vga fbdev driver falls over.
>> > > > 	 */
>> > > > 	ret = vga_remove_vgacon(pdev);
>> > 
>> > This isn't enough, we also nuke stuff that's mapping the vga fb range.

Ah, also need aperture_detach_devices(VGA_FB_PHYS_BASE, VGA_FB_PHYS_SIZE) then.

[...]

>> int aperture_remove_legacy_vga_devices(struct pci_dev *pdev)
>> {
>> 	aperture_detach_devices(VGA_FB_PHYS_BASE, VGA_FB_PHYS_SIZE);
>> 
>> 	return vga_remove_vgacon(pdev);
>> }
>> 
>> And that can be called from gma500 and the pci aperture helper.
>
> But you still pass a pci_dev to that helper. Which just doesn't make any
> sense to me (assuming your entire point is that this isn't just a normal
> pci device but some special legacy vga thing), but if we go with (void)
> then there's more refactoring to do because the vga_remove_vgacon also
> wants a pdev.
>
> All so that we don't call aperture_detach_devices() on a bunch of pci
> bars, which apparently is not problem for any other driver, but absolutely
> is a huge problem for gma500 somehow.
>
> I don't understand why.
>

Yeah, agreed that if vga_remove_vgacon() isn't enough and another helper
is needed then starts to get a little silly. Maybe one option is to add a
3rd param to aperture_remove_conflicting_pci_devices() and skip the logic
to iterate over PCI bars and call aperture_remove_conflicting_devices() ?

> Consider this me throwing in the towel. If you&Javier are convinced this
> makes sense please type it up and merge it, but I'm not going to type
> something that just doesn't make sense to me.

Honestly, I would just go with the double drm_aperture_remove_*() helper
calls (your original patch) unless that causes real issues. There is no
point on blocking all your series just for this IMO.

Then latter if Thomas has strong opinions can send a follow-up patch for
the gma500 driver and the aperture helpers.

> -Daniel
>

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat


  reply	other threads:[~2023-04-05 16:54 UTC|newest]

Thread overview: 112+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-04 20:18 [Intel-gfx] [PATCH 1/8] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers Daniel Vetter
2023-04-04 20:18 ` Daniel Vetter
2023-04-04 20:18 ` [Intel-gfx] [PATCH 2/8] video/aperture: use generic code to figure out the vga default device Daniel Vetter
2023-04-04 20:18   ` Daniel Vetter
2023-04-04 20:18   ` Daniel Vetter
2023-04-05 11:27   ` [Intel-gfx] " Javier Martinez Canillas
2023-04-05 11:27     ` Javier Martinez Canillas
2023-04-05 11:27     ` Javier Martinez Canillas
2023-04-04 20:18 ` [Intel-gfx] [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   ` Daniel Vetter
2023-04-04 20:18   ` Daniel Vetter
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-04 21:20     ` Martin Blumenstingl
2023-04-05  9:25   ` [Intel-gfx] " 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     ` Thierry Reding
2023-04-05 11:30   ` [Intel-gfx] " 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 ` [Intel-gfx] [PATCH 4/8] video/aperture: Only kick vgacon when the pdev is decoding vga Daniel Vetter
2023-04-04 20:18   ` Daniel Vetter
2023-04-04 20:18   ` Daniel Vetter
2023-04-05 11:31   ` [Intel-gfx] " Javier Martinez Canillas
2023-04-05 11:31     ` Javier Martinez Canillas
2023-04-05 11:31     ` Javier Martinez Canillas
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-04 20:18   ` Daniel Vetter
2023-04-05 11:34   ` [Intel-gfx] " Javier Martinez Canillas
2023-04-05 11:34     ` Javier Martinez Canillas
2023-04-05 11:34     ` Javier Martinez Canillas
2023-04-04 20:18 ` [Intel-gfx] [PATCH 6/8] video/aperture: Drop primary argument Daniel Vetter
2023-04-04 20:18   ` Daniel Vetter
2023-04-04 20:18   ` Daniel Vetter
2023-04-05 11:36   ` [Intel-gfx] " Javier Martinez Canillas
2023-04-05 11:36     ` Javier Martinez Canillas
2023-04-05 11:36     ` Javier Martinez Canillas
2023-04-04 20:18 ` [Intel-gfx] [PATCH 7/8] video/aperture: Only remove sysfb on the default vga pci device Daniel Vetter
2023-04-04 20:18   ` Daniel Vetter
2023-04-04 20:18   ` Daniel Vetter
2023-04-04 20:59   ` [Intel-gfx] " Aaron Plattner
2023-04-04 20:59     ` Aaron Plattner
2023-04-04 20:59     ` Aaron Plattner
2023-04-05  8:48     ` [Intel-gfx] " Daniel Vetter
2023-04-05  8:48       ` Daniel Vetter
2023-04-05  8:48       ` Daniel Vetter
2023-04-05 11:37   ` [Intel-gfx] " Javier Martinez Canillas
2023-04-05 11:37     ` Javier Martinez Canillas
2023-04-05 11:37     ` Javier Martinez Canillas
2023-04-04 20:18 ` [Intel-gfx] [PATCH 8/8] fbdev: Simplify fb_is_primary_device for x86 Daniel Vetter
2023-04-04 20:18   ` Daniel Vetter
2023-04-05 11:40   ` [Intel-gfx] " Javier Martinez Canillas
2023-04-05 11:40     ` 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 ` [Intel-gfx] [PATCH 1/8] " Thomas Zimmermann
2023-04-05  7:49   ` Thomas Zimmermann
2023-04-05  8:05   ` [Intel-gfx] " Patrik Jakobsson
2023-04-05  8:05     ` Patrik Jakobsson
2023-04-05  8:15     ` [Intel-gfx] " Thomas Zimmermann
2023-04-05  8:15       ` Thomas Zimmermann
2023-04-05  8:07   ` [Intel-gfx] " Thomas Zimmermann
2023-04-05  8:07     ` Thomas Zimmermann
2023-04-05  8:59     ` [Intel-gfx] " Daniel Vetter
2023-04-05  8:59       ` Daniel Vetter
2023-04-05  9:26       ` [Intel-gfx] " Thomas Zimmermann
2023-04-05  9:26         ` Thomas Zimmermann
2023-04-05  9:38         ` [Intel-gfx] " Daniel Vetter
2023-04-05  9:38           ` Daniel Vetter
2023-04-05 11:00           ` [Intel-gfx] " Thomas Zimmermann
2023-04-05 11:00             ` Thomas Zimmermann
2023-04-05 11:16             ` [Intel-gfx] " Javier Martinez Canillas
2023-04-05 11:16               ` Javier Martinez Canillas
2023-04-05 13:18               ` [Intel-gfx] " Daniel Vetter
2023-04-05 13:18                 ` Daniel Vetter
2023-04-05 14:32                 ` [Intel-gfx] " Thomas Zimmermann
2023-04-05 14:32                   ` Thomas Zimmermann
2023-04-05 16:02                   ` [Intel-gfx] " Daniel Vetter
2023-04-05 16:02                     ` Daniel Vetter
2023-04-05 16:54                     ` Javier Martinez Canillas [this message]
2023-04-05 16:54                       ` Javier Martinez Canillas
2023-04-05 17:14                       ` [Intel-gfx] " Daniel Vetter
2023-04-05 17:14                         ` Daniel Vetter
2023-04-05 17:43                         ` [Intel-gfx] " Javier Martinez Canillas
2023-04-05 17:43                           ` Javier Martinez Canillas
2023-04-05 17:46                         ` [Intel-gfx] " 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   ` Thomas Zimmermann
2023-04-05  9:09   ` [Intel-gfx] " Daniel Vetter
2023-04-05  9:09     ` 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 ` [Intel-gfx] [PATCH 1/8] " Thomas Zimmermann
2023-04-06  7:14   ` Thomas Zimmermann
2023-04-06  8:38   ` [Intel-gfx] " Javier Martinez Canillas
2023-04-06  8:38     ` Javier Martinez Canillas
2023-04-06  8:49     ` [Intel-gfx] " Thomas Zimmermann
2023-04-06  8:49       ` Thomas Zimmermann
2023-04-06  9:05       ` [Intel-gfx] " Javier Martinez Canillas
2023-04-06  9:05         ` 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=87bkk29smu.fsf@minerva.mail-host-address-is-not-set \
    --to=javierm@redhat.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.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.