similar to: [PATCH v4] vga_switcheroo: Add helper for deferred probing

Hi Emil, On Fri, May 20, 2016 at 12:41:04AM +0100, Emil Velikov wrote: > On 19 May 2016 at 15:39, Lukas Wunner <lukas at wunner.de> wrote: > > +bool vga_switcheroo_client_probe_defer(struct pci_dev *pdev) > > +{ > > + if ((pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA) { > Not sure if we want/need this, yet at least. This changes behaviour > which is

So far we've got one condition when DRM drivers need to defer probing on a dual GPU system and it's coded separately into each of the relevant drivers. As suggested by Daniel Vetter, deduplicate that code in the drivers and move it to a new vga_switcheroo helper. This yields better encapsulation of concepts and lets us add further checks in a central place. (The existing check pertains to

So far we've got one condition when DRM drivers need to defer probing on a dual GPU system and it's coded separately into each of the relevant drivers. As suggested by Daniel Vetter, deduplicate that code in the drivers and move it to a new vga_switcheroo helper. This yields better encapsulation of concepts and lets us add further checks in a central place. (The existing check pertains to

So far we've got one condition when DRM drivers need to defer probing on a dual GPU system and it's coded separately into each of the relevant drivers. As suggested by Daniel Vetter, deduplicate that code in the drivers and move it to a new vga_switcheroo helper. This yields better encapsulation of concepts and lets us add further checks in a central place. (The existing check pertains to

Hi Lukas, On 19 May 2016 at 15:39, Lukas Wunner <lukas at wunner.de> wrote: > +bool vga_switcheroo_client_probe_defer(struct pci_dev *pdev) > +{ > + if ((pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA) { Not sure if we want/need this, yet at least. This changes behaviour which is not what refactoring patches should be doing, right ? if needed it ought to be a separate

On Sat, May 21, 2016 at 03:59:16PM +0100, Lukas Wunner wrote: > So far we've got one condition when DRM drivers need to defer probing > on a dual GPU system and it's coded separately into each of the relevant > drivers. As suggested by Daniel Vetter, deduplicate that code in the > drivers and move it to a new vga_switcheroo helper. This yields better > encapsulation of

Daniel Vetter pointed out that vga_switcheroo_client_probe_defer() could be needed by audio clients as well. To avoid mistakes when someone adds conditions for these in the future, constrain the single existing condition to VGA clients by checking for PCI_BASE_CLASS_DISPLAY. This encompasses both PCI_CLASS_DISPLAY_VGA as well as PCI_CLASS_DISPLAY_3D, which is used by some Nvidia Optimus GPUs. Any

Another vga_switcheroo cleanup. Maintainers, is it okay to include the one-line change of each driver in here or do you want that split into separate patches? Thanks, Lukas Lukas Wunner (1): vga_switcheroo: Constify vga_switcheroo_handler drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 2 +- drivers/gpu/drm/nouveau/nouveau_acpi.c | 2 +-

On Fri, Feb 24, 2017 at 1:19 PM, Lukas Wunner <lukas at wunner.de> wrote: > An external Thunderbolt GPU can neither drive the laptop's panel nor be > powered off by the platform, so there's no point in registering it with > vga_switcheroo. > In fact, when the external GPU is runtime suspended, > vga_switcheroo will cut power to the internal discrete GPU, resulting in

On Thu, Mar 09, 2017 at 04:03:47PM +0100, Daniel Vetter wrote: > On Fri, Feb 24, 2017 at 08:19:45PM +0100, Lukas Wunner wrote: > > Fix Thunderbolt-related issues in apple-gmux and vga_switcheroo: > > > > Patch [1/5] ("Recognize Thunderbolt devices") has already been subjected > > to a fair amount of scrutiny over at linux-pci@, I've submitted it 5 times

On Tue, Mar 06, 2018 at 11:29:40AM +0100, Daniel Vetter wrote: > On Sat, Mar 03, 2018 at 10:53:24AM +0100, Lukas Wunner wrote: > > Modernize vga_switcheroo by using a device link to enforce a runtime PM > > dependency from an HDA controller to the GPU it's integrated into, v2. > > > > https://github.com/l1k/linux/commits/switcheroo_devlink_v2 > > This all

Modernize vga_switcheroo by using a "device link" to enforce a runtime PM dependency from an HDA controller to the GPU it's integrated into. Remove thereby obsoleted code and fix a bunch of bugs. Device links were introduced in v4.10. Users might see a small power saving if the discrete GPU is in use and its HDA controller is not, because the HDA controller is now allowed to runtime

On Sun, Feb 18, 2018 at 09:38:32AM +0100, Lukas Wunner wrote: > Back in 2013, runtime PM for GPUs with integrated HDA controller was > introduced with commits 0d69704ae348 ("gpu/vga_switcheroo: add driver > control power feature. (v3)") and 246efa4a072f ("snd/hda: add runtime > suspend/resume on optimus support (v4)"). > > Briefly, the idea was that the HDA

On Fri, Feb 24, 2017 at 08:19:45PM +0100, Lukas Wunner wrote: > Detect on probe whether a PCI device is part of a Thunderbolt controller. > > Intel uses a Vendor-Specific Extended Capability (VSEC) with ID 0x1234 > on such devices. Detect presence of this VSEC and cache it in a newly > added is_thunderbolt bit in struct pci_dev. Add a helper to check > whether a given PCI

The pre-retina MacBook Pro uses an LVDS panel and a gmux controller to switch the panel between its two GPUs. The panel mode in VBIOS is notoriously bogus on these machines and some models have no VBIOS at all, so the inactive GPU cannot set up its LVDS output. Extend vga_switcheroo to support switching only the DDC lines. Introduce a drm_get_edid_switcheroo() helper which uses this feature.

Allow handlers to declare their capabilities and allow clients to obtain that information. So far we have these use cases: * If the handler is able to switch DDC separately, clients need to probe EDID with drm_get_edid_switcheroo(). We should allow them to detect a capable handler to ensure this function only gets called when needed. * Likewise if the handler is unable to switch AUX

On Mon, Feb 19, 2018 at 03:05:53PM +0100, Daniel Vetter wrote: > On Mon, Feb 19, 2018 at 12:58:17PM +0100, Lukas Wunner wrote: > > On Mon, Feb 19, 2018 at 12:34:43PM +0100, Daniel Vetter wrote: > > > Well, userspace expects hotplug events, even when we runtime suspend > > > stuff. Hence waking shit up with polling. Imo ignoring hotplug events is a > > > pretty

On 01:15 am - Oct 21 2016, Lukas Wunner wrote: > On Thu, Oct 20, 2016 at 10:08:28AM +0200, Lukas Wunner wrote: > > On Wed, Oct 19, 2016 at 07:58:06PM +0200, Pierre Moreau wrote: > > > For example, my laptop (which also has an NVAC) has been triggering the > > > no-signal message on external monitors way before Ben???s patch landed, > > > but only for some

Fix Thunderbolt-related issues in apple-gmux and vga_switcheroo: Patch [1/5] ("Recognize Thunderbolt devices") has already been subjected to a fair amount of scrutiny over at linux-pci@, I've submitted it 5 times total since May 2016. With luck it may be in ack-able shape now. Patch [2/5] amends apple-gmux to handle combined DP/Thunderbolt ports properly on newer MacBook Pros.

Modernize vga_switcheroo by using a device link to enforce a runtime PM dependency from an HDA controller to the GPU it's integrated into, v2. Changes since v1: - Replace patch [1/7] to use pci_save_state() / pci_restore_state() for consistency between runtime PM code path of bound and unbound devices. (Rafael, Bjorn) - Patch [5/7]: Drop an unnecessary initialization. (Bjorn) Rephrase