From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fhigh-b5-smtp.messagingengine.com (fhigh-b5-smtp.messagingengine.com [202.12.124.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 24BB4198E86; Thu, 31 Oct 2024 10:52:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.156 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730371941; cv=none; b=Aix0yBz/c2iBrPlDlx/CGLi/re1FXH03SJp7K9HTemgUzbT+gZHbFzOiL0jZn/sjpjiR6vU5grWsS9d7U1UCW6z9TJhA04Wf/bVEJSBAy+0OQqrgnMDx6nDYqXS4v7qbJIu+KTDaFNItg3Qv1liJElDXl64FXl1uauylWr+02Zw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730371941; c=relaxed/simple; bh=n7e+fm2mj3BWSKI8X9sa6VztXoJLs9l2p+7n4TDJKKQ=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=b+eHFeRWQCL6Ng70KBLbgLWaNbt1BhD49TCKjexfxEp6LjKCCHAWGjmddhRfP57rY8fw8JqIkwCbP/o4O24uRdXVVTz6N5DIH4Zv4DbqmlbmBUnTXO0H19rjRgVayrkmaB08S3o6+Y5g4VUI5usrcQuEn86OYQWSjS9o7tLZLqk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ljones.dev; spf=none smtp.mailfrom=ljones.dev; dkim=pass (2048-bit key) header.d=ljones.dev header.i=@ljones.dev header.b=KPafeO0p; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=ARvn1g4T; arc=none smtp.client-ip=202.12.124.156 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ljones.dev Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=ljones.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ljones.dev header.i=@ljones.dev header.b="KPafeO0p"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="ARvn1g4T" Received: from phl-compute-08.internal (phl-compute-08.phl.internal [10.202.2.48]) by mailfhigh.stl.internal (Postfix) with ESMTP id E2AB025400C4; Thu, 31 Oct 2024 06:52:16 -0400 (EDT) Received: from phl-imap-01 ([10.202.2.91]) by phl-compute-08.internal (MEProxy); Thu, 31 Oct 2024 06:52:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ljones.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1730371936; x=1730458336; bh=h1DcXwp3ose9PAVevSGggMI/uLCHuHYOrWE9mX99Mfk=; b= KPafeO0pz/TGBLYkVAPr0VS0FFHrmIIpCpB0PCuLjG6u5m3VAZaKl5JVhAHg283J nIFKqjmSyG0Y5G34A8mX/rh0U6Rs5108FxmznHJyJYpXWbmiLiQ3HWcOAHfGJXjF v85gLi2LoLgDIb1zaGx28/iiyLdJxwKOJ5hjX4Rat0qJKzFkefC0Y0+owsvklCXx ZJ58JcyZiKHi297/TS0xLRw56uHIIQlAFjSNhCbL/JI7r68VN173DbFXhW5WBett 33QXGH8S3PZfW2DUS97mCpy4CyhcxfS+PCZT/h2WC+7yN54n0x0dn1FaROj4Lrdc flxoskAljWqcngR8jHnIEA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1730371936; x= 1730458336; bh=h1DcXwp3ose9PAVevSGggMI/uLCHuHYOrWE9mX99Mfk=; b=A Rvn1g4T4qHNkrbz5VEBFZApqTbUZQo+p0DbHJxEKXH0nEqXs0UMcvt+a/6Zomacg jgn5UHtQLM5AhAyBZXrkD1rC9ai6WiHnak6N/DHq8z9bFxm6GMrCtl3AL9eTHp7I SBL9eQm3/m7t8ILhvaj+zz9DBypcJILQCTh9EeV87VdFxQcXwNJkku86KFuIWOIH Zf3RQ4RbJtkCDYJpK6lyvfTZrxAD3AAM/phUCTDJ/ADJUkaoBw7QcS7giUlpwUvW O4uHMWCUpzZTnRPCeJaP5urolKwKlv8n0gYEsTA1uWduhwuUT141VgfFyw3cZj0J IcEhtKro96BKx3Ekg7IhQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvdekhedgudelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepofggfffhvfevkfgjfhfutgfgsehtqhertdertdej necuhfhrohhmpedfnfhukhgvucflohhnvghsfdcuoehluhhkvgeslhhjohhnvghsrdguvg hvqeenucggtffrrghtthgvrhhnpeekieeftdeltdevudeukeefleejjeeitedttdfhteek jefhteduhffhjefhfeejjeenucffohhmrghinhepfhhrvggvuggvshhkthhophdrohhrgh dpghhithhlrggsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm rghilhhfrhhomheplhhukhgvsehljhhonhgvshdruggvvhdpnhgspghrtghpthhtoheple dpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoheprghlvgigrghnuggvrhdruggvuhgt hhgvrhesrghmugdrtghomhdprhgtphhtthhopehmrghrihhordhlihhmohhntghivghllh hosegrmhgurdgtohhmpdhrtghpthhtoheprghlvgiguggvuhgthhgvrhesghhmrghilhdr tghomhdprhgtphhtthhopegshhgvlhhgrggrshesghhoohhglhgvrdgtohhmpdhrtghpth htohepshhuphgvrhhmudeskhgvrhhnvghlrdhorhhgpdhrtghpthhtohepughrihdquggv vhgvlheslhhishhtshdrfhhrvggvuggvshhkthhophdrohhrghdprhgtphhtthhopehkrg hihhgvnhhgfhesnhhvihguihgrrdgtohhmpdhrtghpthhtoheplhhinhhugidqkhgvrhhn vghlsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqphgtih esvhhgvghrrdhkvghrnhgvlhdrohhrgh X-ME-Proxy: Feedback-ID: i5ec1447f:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 6F9523360079; Thu, 31 Oct 2024 06:52:16 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Date: Thu, 31 Oct 2024 11:51:56 +0100 From: "Luke Jones" To: "Kai-Heng Feng" , "Alex Deucher" Cc: "Mario Limonciello" , "Bjorn Helgaas" , "open list:PCI SUBSYSTEM" , "open list" , dri-devel@lists.freedesktop.org, "Mario Limonciello" , "Alex Deucher" Message-Id: <52d9ff04-ef07-4251-b540-e3d3cdcd4c75@app.fastmail.com> In-Reply-To: <33d7c0ca-8459-4b85-a0e6-97f2e1e8db91@nvidia.com> References: <20241014152502.1477809-1-superm1@kernel.org> <20b48c6f-7ea9-4571-a39c-f20a9cf62319@app.fastmail.com> <46b487ec-e8a6-43fb-85d5-f264618f2e5d@nvidia.com> <33d7c0ca-8459-4b85-a0e6-97f2e1e8db91@nvidia.com> Subject: Re: [PATCH] PCI/VGA: Don't assume only VGA device found is the boot VGA device Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, 31 Oct 2024, at 1:58 AM, Kai-Heng Feng wrote: > On 2024/10/25 8:55 PM, Alex Deucher wrote: >> External email: Use caution opening links or attachments >>=20 >>=20 >> On Fri, Oct 25, 2024 at 3:51=E2=80=AFAM Kai-Heng Feng wrote: >>> >>> >>> >>> On 2024/10/23 11:27 PM, Alex Deucher wrote: >>>> External email: Use caution opening links or attachments >>>> >>>> >>>> On Tue, Oct 22, 2024 at 9:27=E2=80=AFPM Kai-Heng Feng wrote: >>>>> >>>>> >>>>> >>>>> On 2024/10/22 9:04 PM, Alex Deucher wrote: >>>>>> External email: Use caution opening links or attachments >>>>>> >>>>>> >>>>>> On Tue, Oct 22, 2024 at 2:31=E2=80=AFAM Kai-Heng Feng wrote: >>>>>>> >>>>>>> Hi Luke, >>>>>>> >>>>>>> On 2024/10/15 4:04 PM, Luke Jones wrote: >>>>>>>> On Mon, 14 Oct 2024, at 5:25 PM, Mario Limonciello wrote: >>>>>>>>> From: Mario Limonciello >>>>>>>>> >>>>>>>>> The ASUS GA605W has a NVIDIA PCI VGA device and an AMD PCI dis= play device. >>>>>>>>> >>>>>>>>> ``` >>>>>>>>> 65:00.0 VGA compatible controller: NVIDIA Corporation AD106M [= GeForce >>>>>>>>> RTX 4070 Max-Q / Mobile] (rev a1) >>>>>>>>> 66:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/= ATI] >>>>>>>>> Strix [Radeon 880M / 890M] (rev c1) >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> The fallback logic in vga_is_boot_device() flags the NVIDIA dG= PU as the >>>>>>>>> boot VGA device, but really the eDP is connected to the AMD PC= I display >>>>>>>>> device. >>>>>>>>> >>>>>>>>> Drop this case to avoid marking the NVIDIA dGPU as the boot VG= A device. >>>>>>>>> >>>>>>>>> Suggested-by: Alex Deucher >>>>>>>>> Reported-by: Luke D. Jones >>>>>>>>> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3673 >>>>>>>>> Signed-off-by: Mario Limonciello >>>>>>>>> --- >>>>>>>>> drivers/pci/vgaarb.c | 7 ------- >>>>>>>>> 1 file changed, 7 deletions(-) >>>>>>>>> >>>>>>>>> diff --git a/drivers/pci/vgaarb.c b/drivers/pci/vgaarb.c >>>>>>>>> index 78748e8d2dba..05ac2b672d4b 100644 >>>>>>>>> --- a/drivers/pci/vgaarb.c >>>>>>>>> +++ b/drivers/pci/vgaarb.c >>>>>>>>> @@ -675,13 +675,6 @@ static bool vga_is_boot_device(struct vga= _device *vgadev) >>>>>>>>> return true; >>>>>>>>> } >>>>>>>>> >>>>>>>>> - /* >>>>>>>>> - * Vgadev has neither IO nor MEM enabled. If we haven't = found any >>>>>>>>> - * other VGA devices, it is the best candidate so far. >>>>>>>>> - */ >>>>>>>>> - if (!boot_vga) >>>>>>>>> - return true; >>>>>>>>> - >>>>>>>>> return false; >>>>>>>>> } >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 2.43.0 >>>>>>>> >>>>>>>> Hi Mario, >>>>>>>> >>>>>>>> I can verify that this does leave the `boot_vga` attribute set = as 0 for the NVIDIA device. >>>>>>> >>>>>>> Does the following diff work for you? >>>>>>> This variant should be less risky for most systems. >>>>>>> >>>>>>> diff --git a/drivers/pci/vgaarb.c b/drivers/pci/vgaarb.c >>>>>>> index 78748e8d2dba..3fb734cb9c1b 100644 >>>>>>> --- a/drivers/pci/vgaarb.c >>>>>>> +++ b/drivers/pci/vgaarb.c >>>>>>> @@ -675,6 +675,9 @@ static bool vga_is_boot_device(struct vga_de= vice *vgadev) >>>>>>> return true; >>>>>>> } >>>>>>> >>>>>>> + if (vga_arb_integrated_gpu(&pdev->dev)) >>>>>>> + return true; >>>>>>> + >>>>>> >>>>>> The problem is that the integrated graphics does not support VGA. >>>>> >>>>> Right, so the check has to be used much earlier. >>>>> >>>>> I wonder does the integrated GFX have _DOD/_DOS while the discrete= one doesn't? >>>>> If that's the case, vga_arb_integrated_gpu() can be used to differ= entiate which >>>>> one is the boot GFX. >>>> >>>> I think the problem is that the boot GPU is being conflated with vga >>>> arb. In this case the iGPU has no VGA so has no reason to be invol= ved >>>> in vga arb. Trying to mess with any vga related resources on it co= uld >>>> be problematic. Do higher levels of the stack look at vga arb to >>>> determine the "primary" GPU? >>> >>> Hmm, I wonder if all those heuristic are needed for EFI based system? >>> >>> Can we assume that what being used by UEFI GOP is the primary GFX de= vice? >>=20 >> Yes, I believe so. The SBIOS should use the GOP device as determined >> by the user preference. I.e.., in the bios configuration you can >> generally select iGPU or PEG for the primary display. > > UEFI spec, 10.3.3.1 ACPI _ADR Device Path > > "The _ADR device path is used to contain video output device attribute= s to=20 > support the Graphics Output Protocol. The device path can contain mult= iple _ADR=20 > entries if multiple video output devices are displaying the same outpu= t." > > Luke, can you please see what are the _ADR values of the iGPU and dGPU= ?=20 > Maybe we=20 > can find which one was used by GOP this way. I'm not sure what I'm looking at here, but initial search shows: Device (VGA) { Name (_ADR, Zero) // _ADR: Address Name (DOSA, Zero) Method (_DOS, 1, NotSerialized) // _DOS: Disable Ou= tput Switching { DOSA =3D Arg0 } Method (_DOD, 0, NotSerialized) // _DOD: Display Ou= tput Devices { M460 ("PLA-ASL-\\_SB.PCI0.GPPA.VGA._DOD\n", Zero= , Zero, Zero, Zero, Zero, Zero) Return (Package (0x07) { 0x00010110,=20 0x00010210,=20 0x00010220,=20 0x00010230,=20 0x00010240,=20 0x00031000,=20 0x00032000 }) } Device (LCD) { Name (_ADR, 0x0110) // _ADR: Address Name (BCLB, Package (0x34) { https://gitlab.com/asus-linux/reverse-engineering/-/blob/master/uncatego= rized/GA605WI/dsdt.dsl?ref_type=3Dheads#L4666 And: Method (_DOD, 0, NotSerialized) // _DOD: Display Output Dev= ices { Return (Package (0x01) { 0x8000A450 }) } Device (LCD0) { Method (_ADR, 0, Serialized) // _ADR: Address { Return (0x8000A450) } https://gitlab.com/asus-linux/reverse-engineering/-/blob/master/uncatego= rized/GA605WI/ssdt1.dsl?ref_type=3Dheads#L411 The links are direct to the lines I thought were relevant in the dumped = DSDT. Luke. > > Kai-Heng > >>=20 >> Alex >>=20 >>> >>> Kai-Heng >>> >>>> >>>> Alex >>>> >>>>> >>>>> Kai-Heng >>>>> >>>>>> >>>>>> Alex >>>>>> >>>>>>> /* >>>>>>> * Vgadev has neither IO nor MEM enabled. If we hav= en't found any >>>>>>> * other VGA devices, it is the best candidate so fa= r. >>>>>>> >>>>>>> >>>>>>> Kai-Heng >>>>>>> >>>>>>>> >>>>>>>> Tested-by: Luke D. Jones >>>>>>> >>>>> >>>