similar to: [PATCH 0/7] Modernize vga_switcheroo by using device link for HDA

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

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

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 controller is forced on and off in unison with the GPU. The original code is mostly still in

Hi Peter, > [12:42] Lekensteyn: Should the video card always be powered up when a > register is read from the HDMI audio controller? Or would it be > better to leave the video card suspended and just fail the HDA > register reads? It should probably be powered up. > [12:43] Lekensteyn: I'm trying to figure out how vga_switcheroo should handle this, maybe l1k has an

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

On Sun, Feb 11, 2018 at 06:58:11PM +0000, Mike Lothian wrote: > On 11 February 2018 at 09:38, Lukas Wunner <lukas at wunner.de> wrote: > > The patches for radeon and amdgpu are compile-tested only, I only have a > > MacBook Pro with an Nvidia GK107 to test. To test the patches, add an > > "msleep(12*1000);" at the top of the driver's ->runtime_suspend

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

From: Sui Jingfeng <suijingfeng at loongson.cn> There is no function that can be used to get all PCI(e) devices in a system by matching against its the PCI base class code only, while keep the sub-class code and the programming interface ignored. Therefore, add the pci_get_base_class() function to suit the need. For example, if an application want to process all PCI(e) display devices in a

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

From: Sui Jingfeng <suijingfeng at loongson.cn> Should be no functional change Cc: Jaroslav Kysela <perex at perex.cz> Cc: Takashi Iwai <tiwai at suse.com> Cc: Fred Oh <fred.oh at linux.intel.com> Cc: Pierre-Louis Bossart <pierre-louis.bossart at linux.intel.com> Cc: Kai Vehmanen <kai.vehmanen at linux.intel.com> Cc: Bjorn Helgaas <bhelgaas at

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.

On a very specific subset of ThinkPad P50 SKUs, particularly ones that come with a Quadro M1000M chip instead of the M2000M variant, the BIOS seems to have a very nasty habit of not always resetting the secondary Nvidia GPU between full reboots if the laptop is configured in Hybrid Graphics mode. The reason for this happening is unknown, but the following steps and possibly a good bit of patience

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 +-

https://bugs.freedesktop.org/show_bug.cgi?id=75985 Priority: medium Bug ID: 75985 Assignee: nouveau at lists.freedesktop.org Summary: HDMI audio device only visible after rescan QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: jean-louis at

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

Enable GPU switching on the pre-retina MacBook Pro (2008 - 2013), v5. The main obstacle on these machines is that the panel mode in VBIOS is bogus. Fortunately gmux can switch DDC independently from the display, thereby allowing the inactive GPU to probe the panel's EDID. In short, vga_switcheroo and apple-gmux are amended with hooks to switch DDC, DRM core is amended with a

Hi developers, I met some domU issues and the log suggests missing interrupt. Details from here: http://www.gossamer-threads.com/lists/xen/users/263938#263938 In summary, this is the suspicious log: (XEN) vmsi.c:122:d32767 Unsupported delivery mode 3 I''ve checked the code in question and found that mode 3 is an ''reserved_1'' mode. I want to trace down the source of this

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

https://bugs.freedesktop.org/show_bug.cgi?id=76818 Priority: medium Bug ID: 76818 Assignee: nouveau at lists.freedesktop.org Summary: Xorg EQ overflowing lock up QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: All Reporter: max.snow at 4mation.com.au

On Sun, Feb 18, 2018 at 09:38:32AM +0100, Lukas Wunner wrote: > PCI devices not bound to a driver are supposed to stay in D0 during > runtime suspend. Doesn't "runtime suspend" mean an individual device is suspended while the rest of the system remains active? If so, maybe it would be more direct to say "PCI devices not bound to a driver cannot be runtime