On Thu, Mar 9, 2017 at 5:55 AM, Lukas Wunner <lukas@xxxxxxxxx> wrote: > On Wed, Mar 08, 2017 at 03:34:47PM -0500, Alex Deucher wrote: >> On Wed, Mar 8, 2017 at 12:01 AM, Lukas Wunner <lukas@xxxxxxxxx> wrote: >> > On Tue, Mar 07, 2017 at 03:30:30PM -0500, Alex Deucher wrote: >> >> On Fri, Feb 24, 2017 at 2:19 PM, Lukas Wunner <lukas@xxxxxxxxx> 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 >> >> > a lockup. >> >> >> >> I'm not necessarily opposed to this, but I'd prefer something more >> >> generic. E.g., what happens if someone uses another dGPU in a docking >> >> station or some other sort of PCIe bridge? >> > >> > Such a dGPU is only relevant to vga_switcheroo if it can either drive >> > the panel or be powered off by the platform. Does such a product exist? >> > >> > I've never heard of one, and think that's because such a product doesn't >> > make sense: A docking staton is not power-constrained, it's stationary >> > and connected to a wall outlet, so there's no need to power the dGPU off >> > when it's not in use. >> > >> > And at a docking station you're usually connected to a larger monitor, >> > so having the dGPU drive the laptop's smaller panel isn't necessary either. >> > In the rare cases where there's no larger monitor, you just use the dGPU >> > for render offloading, just as you would for contemporary ATPX laptops. >> > >> > OTOH, dGPUs in Thunderbolt enclosures *do* exist and connecting them >> > to an ATPX machine causes failure, as explained in the commit message. >> >> Whether you introduce additional dGPUs via thunderbolt or some >> proprietary interface or a pci bridge in a docking station the result >> is still the same. You end up with the potential scenario you >> described in this commit message that there may be confusion as to >> which GPU is controlled via ACPI power controls. >> >> I talked to the windows team. They special case thunderbolt as well, > > Very interesting, thanks for reaching out to them. I've already heard > that Windows 10 supports Thunderbolt eGPUs, but only with Thunderbolt 3. > I think it's desirable that we achieve feature parity with them (without > the unnecessary restriction to Thunderbolt 3). Older Windows versions as > well as macOS apparently require all sorts of awful hacks for eGPUs. > > >> so the patch is probably fine. > > Is that an ack or are there any remaining concerns? Series is: Acked-by: Alex Deucher <alexander.deucher@xxxxxxx> > > >> For pcie ports in a docking station, I >> suspect there may not actually be any docking stations supported by PX >> laptops where this could be an issue. > > If/when such products do become available, they can probably be identified > via specific ACPI methods or if all else fails, DMI quirks. > > >> For non-thunderbolt detachable >> graphics there is a new ATIF function to query the bus number of the >> supported device. I'll send a patch out for that in a bit. > > Great, thanks. > > >> Thinking about this more, long term we should probably only register >> with vga_switcheroo if we support display muxing which is a legacy >> feature these days. Most systems are mux-less so we just need to >> handle dgpu power control via runtime pm. > > Right now registering with vga_switcheroo is still necessary even for > muxless systems primarily because DRM drivers call > vga_switcheroo_set_dynamic_switch() to pause the HDA driver and update > the power state stored internally by vga_switcheroo. > > I plan to address the former by reworking vga_switcheroo audio handling > using functional device dependencies (a new PM mechanism that appeared > in v4.10, see documentation in aad800403a87), and I think the latter will > then become obsolete as well. I've got a concept in my head and am > pumped to code it up, just a little time-constrained at the moment. :-) Thanks for looking into it. Alex > > Thanks, > > Lukas > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
