Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp2226280ybh; Fri, 17 Jul 2020 12:21:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyqj2adztyHCjdqEoeiFQRNDZ7LU9Zb0vm0VHvtVtVXq6pAoDNXrS4sufyt8UPyCcUn+xSw X-Received: by 2002:a17:906:700f:: with SMTP id n15mr10544233ejj.390.1595013663540; Fri, 17 Jul 2020 12:21:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595013663; cv=none; d=google.com; s=arc-20160816; b=cqxEPGzDfAT94bdc+pwmP0Xg4DrJgzASb5PdGe/ChTw97wGIJYV1G4cNlkHla1CIz1 b7WXL8kMvoGSLNQ1JaevAmrhbY3arYF4Cdj7PWlTeEovouPU7yT/T+tSaWReApLZqTMv c6TkE2QNWAFk07SnxzsEi/VArEFH8JT0wJlYuLxc+I4b/CVdsMEHBCxRRXueHz0AqSOJ N/acD/gdGJzYkl0IbKm6TsF+E/2En6S1d/sk/xOsAysCBD3DpCZU8IP5mbblmPB9DSOr 5prOoDxnMn1wfkW2lRiaSKi+Z0KfQwcicDCu1li7/9+OZhYytqVAhMvg4Fq3sUShmGtD ikIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:organization:references:in-reply-to:date:cc:to:reply-to :from:subject:message-id:dkim-signature; bh=Du0bkJJuZiGwcsmmaS0iHcsLc6G/grfEoCnxuV98a2A=; b=sUIte/nOso6xW9r8VVhuPjYXurqRVumwNkDHgcybo0QJQGfhqiMz0Qq6ebUHPg1eu5 UigDc2hfqAnYKVBD8cOpJAjzr55zOLX+yMvof14psTqFknbrrKTASjda07AzkXXJv3fo U2vOEjAC+GcRV31Xv1H9O7qruZxihfiHWrBWFl/YFKmgFPVFbOux3OChZpCZ6lrUKWnM Bk2qQW7U8Bj6T4IiHUg6opkDCa79b/PDB5hGGVDi+xL/TR6Mks+FxaRvbUoCzAMz626V 0ptFRi9P2treZvFph0Hs4xLVUDUJhiB/FzyojlyZSeZ/cwoyAm+mn3FyAG3YPHmA7HrK 0EzQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=cVMA9O9q; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v21si6388682ejg.127.2020.07.17.12.20.40; Fri, 17 Jul 2020 12:21:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=cVMA9O9q; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728312AbgGQTTz (ORCPT + 99 others); Fri, 17 Jul 2020 15:19:55 -0400 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:59494 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728103AbgGQTTy (ORCPT ); Fri, 17 Jul 2020 15:19:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1595013592; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Du0bkJJuZiGwcsmmaS0iHcsLc6G/grfEoCnxuV98a2A=; b=cVMA9O9qwqHTlXzQDlGJVKukO12bNaB5vECaAfRW4BNVIHX0N8cAgWEl5BKQkqQAmo4liZ rLDoLycslYMZVjyzIf6hRsrjvz5T2B2ocYZote11NIK1OVuGCHuBLVNlV2uD1wUQRjQpy2 Fl/ba4KSQZ+rb6V9eYAfH+Zzv1E/Iiw= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-380-Y3avddQfMs2FNuvtipfgOg-1; Fri, 17 Jul 2020 15:19:49 -0400 X-MC-Unique: Y3avddQfMs2FNuvtipfgOg-1 Received: by mail-qv1-f69.google.com with SMTP id l12so6103569qvu.21 for ; Fri, 17 Jul 2020 12:19:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:reply-to:to:cc:date :in-reply-to:references:organization:user-agent:mime-version :content-transfer-encoding; bh=Du0bkJJuZiGwcsmmaS0iHcsLc6G/grfEoCnxuV98a2A=; b=UKyd+icAPd31VoH5xA58YZrum5K/d4JjZVf/9JVeCs+IhigemtLHYNgg7xowREY+si WM7oZeedH95jXSNIuC+gj+tFRR1f2Wc9sn3E3dmdwxmwMofN+3gp9DhIzgXcwjen97QX 3lbHqFZVwOjx3MgHsHtPBWZrdlnCBib22ze2ufCTpEVheNwqPEjsP23zz9PQ106qQR18 LrotXymH+/TK9S22dQs95r5PZMmayKHfs/ABpJA53GZ8ayILUcIbqdwX7YddtWpromcE KDgF7fDI0JZ9qpHdnTUHyWKaJuH19braUGkU2ZAujEscMKLc0Z6lnbyY5qkTYftbOucE g6Qg== X-Gm-Message-State: AOAM532+btHhbdDsdzIcK/IBWsquZjzbb2O+twP2MJuAHZnvPlZ+Sw7T 8zL0lAYBBLdPvgPnS45OVOM8sjMhttSzBOLXMCGEMc8QpNI3SHbKvIDeY9wM79cSDWYBx1fRM4H 1rLgmuf5YRrzRsnPqIMLPGPUm X-Received: by 2002:ac8:2a3d:: with SMTP id k58mr11996370qtk.265.1595013589360; Fri, 17 Jul 2020 12:19:49 -0700 (PDT) X-Received: by 2002:ac8:2a3d:: with SMTP id k58mr11996348qtk.265.1595013589062; Fri, 17 Jul 2020 12:19:49 -0700 (PDT) Received: from Whitewolf.lyude.net (pool-108-49-102-102.bstnma.fios.verizon.net. [108.49.102.102]) by smtp.gmail.com with ESMTPSA id f41sm12423841qtk.55.2020.07.17.12.19.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Jul 2020 12:19:48 -0700 (PDT) Message-ID: <7bc7287b5cbac6535765b3490bd55da1e1cb4d07.camel@redhat.com> Subject: Re: [PATCH] RFC: ACPI / OSI: remove workarounds for hybrid graphics laptops From: Lyude Paul Reply-To: lyude@redhat.com To: Karol Herbst , linux-acpi@vger.kernel.org Cc: Alex Hung , "Rafael J. Wysocki" , Len Brown , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org Date: Fri, 17 Jul 2020 15:19:47 -0400 In-Reply-To: <20200717190547.648604-1-kherbst@redhat.com> References: <20200717190547.648604-1-kherbst@redhat.com> Organization: Red Hat Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.3 (3.36.3-1.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hey-just wanted to give some additional context I think Karol missed here. It should be noted that since the last time me and Karol looked at reverting these, we've already fixed all of the nasty runtime PM (e.g. runtime D3) issues we could find. This includes the infamous one that was affecting nearly all of the nvidia pascal (+ some maxwell 2 and turing, it ended up being that the intel PCI bridge was the culprit) machines on the market. Right now I'm only aware of one major issue we have, which is the result of a recent PCI core change that we're already in the process of getting reverted: https://lkml.org/lkml/2020/7/16/1288 [if you do any testing of runtime PM, you may need to temporarily revert this patch to make things work] So, really-runtime D3 is very much supported with nouveau. And we've put a _lot_ of effort into making sure of that, and are happy to fix any issues you're still finding. It also works just fine in AMD, but if you're finding systems it doesn't work with amd on then please let the amdgpu folks know upstream so they can properly fix it. Otherwise, these ACPI workarounds are likely making the power consumption on these systems (for nouveau, amdgpu, and radeon) dramatically higher then it needs to be. On Fri, 2020-07-17 at 21:05 +0200, Karol Herbst wrote: > It's hard to figure out what systems are actually affected and right now I > don't see a good way of removing those... > > But I'd like to see thos getting removed and drivers fixed instead (which > happened at least for nouveau). > > And as mentioned before, I prefer people working on fixing issues instead > of spending time to add firmware level workarounds which are hard to know > to which systems they apply to, hard to remove and basically a big huge > pain to work with. > In the end I have no idea how to even figure out what systems are affected > and which not by this, so I have no idea how to even verify we can safely > remove this (which just means those are impossible to remove unless we risk > breaking systems, which again makes those supper annoying to deal with). > > Also from the comments it's hard to get what those bits really do. Are they > just preventing runtime pm or do the devices are powered down when booting? > I am sure it's the former, still... > > Please, don't do this again. > > For now, those workaround prevent power savings on systems those workaround > applies to, which might be any so those should get removed asap and if > new issues arrise removing those please do a proper bug report and we can > look into it and come up with a proper fix (and keep this patch out until > we resolve all of those). > > Signed-off-by: Karol Herbst > CC: Alex Hung > CC: "Rafael J. Wysocki" > CC: Len Brown > CC: Lyude Paul > CC: linux-kernel@vger.kernel.org > CC: dri-devel@lists.freedesktop.org > CC: nouveau@lists.freedesktop.org > --- > drivers/acpi/osi.c | 24 ------------------------ > 1 file changed, 24 deletions(-) > > diff --git a/drivers/acpi/osi.c b/drivers/acpi/osi.c > index 9f68538091384..d4405e1ca9b97 100644 > --- a/drivers/acpi/osi.c > +++ b/drivers/acpi/osi.c > @@ -44,30 +44,6 @@ osi_setup_entries[OSI_STRING_ENTRIES_MAX] __initdata = { > {"Processor Device", true}, > {"3.0 _SCP Extensions", true}, > {"Processor Aggregator Device", true}, > - /* > - * Linux-Dell-Video is used by BIOS to disable RTD3 for NVidia graphics > - * cards as RTD3 is not supported by drivers now. Systems with NVidia > - * cards will hang without RTD3 disabled. > - * > - * Once NVidia drivers officially support RTD3, this _OSI strings can > - * be removed if both new and old graphics cards are supported. > - */ > - {"Linux-Dell-Video", true}, > - /* > - * Linux-Lenovo-NV-HDMI-Audio is used by BIOS to power on NVidia's HDMI > - * audio device which is turned off for power-saving in Windows OS. > - * This power management feature observed on some Lenovo Thinkpad > - * systems which will not be able to output audio via HDMI without > - * a BIOS workaround. > - */ > - {"Linux-Lenovo-NV-HDMI-Audio", true}, > - /* > - * Linux-HPI-Hybrid-Graphics is used by BIOS to enable dGPU to > - * output video directly to external monitors on HP Inc. mobile > - * workstations as Nvidia and AMD VGA drivers provide limited > - * hybrid graphics supports. > - */ > - {"Linux-HPI-Hybrid-Graphics", true}, > }; > > static u32 acpi_osi_handler(acpi_string interface, u32 supported)