From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 CA5671ACEDD; Fri, 18 Jul 2025 17:44:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752860656; cv=none; b=XA0m8cUtk/cudo9FqiTICRqhuP0lRotEF0L5Bk7nfHya6lugjQcteQxRPVTxqgJbFD0+EKcQhYTk8/2Wh4AWefysWos5B0FH+5k+sc0OxnuvAWIP3nYkm496lqUBPwoaF7G9Jnpsq8kSJ8PRyPfSwVBurwhArG69129/JBOQmQQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752860656; c=relaxed/simple; bh=r7jzzhhlqvE5ku5kcAd5OqB3Um/2DvWTLMCOzwioi2M=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=nKu6GW/qBWAvOpBL/bgMq14INw0+7Xbfq6p8mEOlilhH+PGjI2RsSiAvAFd2KAd433tYaIdKZsTkH/x4AZmejOMZIG7samsLuiQhrQlS9y1xx/gFoBnxEQF2w79N97gb0C/ur7b6auUJAg8RX1Zog5SPjxy/SsK9rRuJLgOldNo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Z245fCB9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Z245fCB9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BD085C4CEEB; Fri, 18 Jul 2025 17:44:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1752860655; bh=r7jzzhhlqvE5ku5kcAd5OqB3Um/2DvWTLMCOzwioi2M=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Z245fCB9/rRmVPyLP3CMTiyxp/kG4PUS/3ZaQvUeMnPl90TQbxHR9ZNMC9q2nF9V0 +h0ytwAO4Ap8NxHPSh1gEmY5tK9vY0pmmKZFkzFyp0EuCx3ZhhSHPfNo89NV16949g EZ3ZaEEKCQ/nYQ7pvRhJZBe4AhYIfX38YVClKddAmxi+k23nvQ6li+93+BHGh3ADsl 4S1dslmUTDXqJ5gGTNmFT0/e3y8hKxPUiQ4T0+aWiy9TXJkDivZq/G7HMeef8cPPG5 ENBTaAtIZQ3xxgwwWPSDdzVN+EQIFkgCmJQurv/GU6ZzB3mByqkYwOHbgvERWMxm4W dxVhSgHUVmFkA== Message-ID: Date: Fri, 18 Jul 2025 12:44:11 -0500 Precedence: bulk X-Mailing-List: linux-pci@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 9/9] PCI: Add a new 'boot_display' attribute To: Bjorn Helgaas Cc: David Airlie , Bjorn Helgaas , Alex Deucher , =?UTF-8?Q?Christian_K=C3=B6nig?= , Simona Vetter , Lukas Wunner , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Woodhouse , Lu Baolu , Joerg Roedel , Will Deacon , Robin Murphy , Alex Williamson , Jaroslav Kysela , Takashi Iwai , "open list:DRM DRIVERS" , open list , "open list:INTEL IOMMU (VT-d)" , "open list:PCI SUBSYSTEM" , "open list:VFIO DRIVER" , "open list:SOUND" , Daniel Dadap , Mario Limonciello References: <20250718173648.GA2704349@bhelgaas> Content-Language: en-US From: Mario Limonciello In-Reply-To: <20250718173648.GA2704349@bhelgaas> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 7/18/2025 12:36 PM, Bjorn Helgaas wrote: > On Fri, Jul 18, 2025 at 12:29:05PM -0500, Mario Limonciello wrote: >> On 7/18/2025 12:25 PM, Bjorn Helgaas wrote: >>> On Thu, Jul 17, 2025 at 12:38:12PM -0500, Mario Limonciello wrote: >>>> From: Mario Limonciello >>>> >>>> On systems with multiple GPUs there can be uncertainty which GPU is the >>>> primary one used to drive the display at bootup. In some desktop >>>> environments this can lead to increased power consumption because >>>> secondary GPUs may be used for rendering and never go to a low power >>>> state. In order to disambiguate this add a new sysfs attribute >>>> 'boot_display' that uses the output of video_is_primary_device() to >>>> populate whether a PCI device was used for driving the display. >>> >>>> +What: /sys/bus/pci/devices/.../boot_display >>>> +Date: October 2025 >>>> +Contact: Linux PCI developers >>>> +Description: >>>> + This file indicates that displays connected to the device were >>>> + used to display the boot sequence. If a display connected to >>>> + the device was used to display the boot sequence the file will >>>> + be present and contain "1". >>> >>>> int __must_check pci_create_sysfs_dev_files(struct pci_dev *pdev) >>>> { >>>> + int retval; >>>> + >>>> if (!sysfs_initialized) >>>> return -EACCES; >>>> + retval = pci_create_boot_display_file(pdev); >>> >>> In addition to Mani's question about whether /sys/bus/pci/ is the >>> right place for this (which is a very good question), it's also been >>> pointed out to me that we've been trying to get rid of >>> pci_create_sysfs_dev_files() for years. >>> >>> If it's possible to make this a static attribute that would be much, >>> much cleaner. >> >> Right - I tried to do this, but the problem is at the time the PCI device is >> created the information needed to make the judgement isn't ready. The >> options end up being: >> * a sysfs file for every display device with 0/1 >> * a sysfs file that is not accurate until later in the boot > > What's missing? The specifics might be helpful if someone has another > crack at getting rid of pci_create_sysfs_dev_files() in the future. The underlying SCREEN_INFO code tries to walk through all the PCI devices in a loop, but at the time all the devices are walked the memory regions associated with the device weren't populated. So my earlier hack was to re-run the screen info check, and it was awful. > >> So IMO it /needs/ to come later. >> >>> >>>> + if (retval) >>>> + return retval; >>>> + >>>> return pci_create_resource_files(pdev); >>>> } >>>> @@ -1671,6 +1716,7 @@ void pci_remove_sysfs_dev_files(struct pci_dev *pdev) >>>> if (!sysfs_initialized) >>>> return; >>>> + pci_remove_boot_display_file(pdev); >>>> pci_remove_resource_files(pdev); >>>> } >>>> -- >>>> 2.43.0 >>>> >>