All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Dadap <ddadap@nvidia.com>
To: "Jani Nikula" <jani.nikula@linux.intel.com>,
	"Hans de Goede" <hdegoede@redhat.com>,
	"Ben Skeggs" <bskeggs@redhat.com>,
	"Karol Herbst" <kherbst@redhat.com>, Lyude <lyude@redhat.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Tvrtko Ursulin" <tvrtko.ursulin@linux.intel.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Pan, Xinhui" <Xinhui.Pan@amd.com>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	"Mika Westerberg" <mika.westerberg@linux.intel.com>,
	"Mark Gross" <markgross@kernel.org>,
	"Andy Shevchenko" <andy@kernel.org>
Cc: nouveau@lists.freedesktop.org, Daniel Vetter <daniel@ffwll.ch>,
	David Airlie <airlied@linux.ie>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
	Len Brown <lenb@kernel.org>,
	linux-acpi@vger.kernel.org, platform-driver-x86@vger.kernel.org
Subject: Re: [PATCH 00/14] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display
Date: Wed, 25 May 2022 11:24:43 -0500	[thread overview]
Message-ID: <628007f0-22dc-c684-e530-f56a6e9186a4@nvidia.com> (raw)
In-Reply-To: <871qwrfcwr.fsf@intel.com>

On 5/18/22 03:44, Jani Nikula wrote:
> On Tue, 17 May 2022, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi All,
>>
>> As mentioned in my RFC titled "drm/kms: control display brightness through
>> drm_connector properties":
>> https://lore.kernel.org/dri-devel/0d188965-d809-81b5-74ce-7d30c49fee2d@redhat.com/
>>
>> The first step towards this is to deal with some existing technical debt
>> in backlight handling on x86/ACPI boards, specifically we need to stop
>> registering multiple /sys/class/backlight devs for a single display.
> I guess my question here is, how do you know it's for a *single*
> display?
>
> There are already designs out there with two flat panels, with
> independent brightness controls. They're still rare and I don't think we
> handle them very well. But we've got code to register multiple native
> backlight interfaces, see e.g. commit 20f85ef89d94 ("drm/i915/backlight:
> use unique backlight device names").


This is one of my concerns as well. There are a small number of (mostly 
somewhat old) designs with more than one internal panel. Since the 
intent here is to tie the new backlight UAPI to DRM connectors, I think 
it should remain possible to address each panel individually (the goal 
is to stop having multiple backlight handlers, all of which control the 
same display, not to stop having multiple backlight handlers in 
general). Where I think it might get tricky is when the same display 
might be driven by one GPU or another at different times, for example, 
with a switchable mux. Notebook designs which use the 
nvidia-wmi-ec-backlight driver will use the same backlight handler for 
the display regardless of which GPU is currently driving it, but I 
believe there are other designs where the same panel might have 
backlight controlled by either the iGPU or the dGPU, depending on the 
mux state.


> So imagine a design where one of the panels needs backlight control via
> ACPI and the other via native backlight control. Granted, I don't know
> if one exists, but I think it's very much in the realm of possible
> things the OEMs might do. For example, have an EC PWM for primary panel
> backlight, and use GPU PWM for secondary. How do you know you actually
> do need to register two interfaces?


The "how do you know" question is one I am wondering as well. I need to 
check with some of our backlight experts here at NVIDIA to figure out 
how exactly reliably we are able to make this determination.


> I'm fine with dealing with such cases as they arise to avoid
> over-engineering up front, but I also don't want us to completely paint
> ourselves in a corner either.
>
> BR,
> Jani.
>
>
>> This series implements my RFC describing my plan for these cleanups:
>> https://lore.kernel.org/dri-devel/98519ba0-7f18-201a-ea34-652f50343158@redhat.com/
>>
>> Specifically patches 1-6 implement the "Fixing kms driver unconditionally
>> register their "native" backlight dev" part.
>>
>> And patches 7-14 implement the "Fixing acpi_video0 getting registered for
>> a brief time" time.
>>
>> Note this series does not deal yet with the "Other issues" part, I plan
>> to do a follow up series for that.
>>
>> The changes in this series are good to have regardless of the further
>> "drm/kms: control display brightness through drm_connector properties"
>> plans. So I plan to push these upstream once they are ready (once
>> reviewed). Since this crosses various subsystems / touches multiple
>> kms drivers my plan is to provide an immutable branch based on say
>> 5.19-rc1 and then have that get merged into all the relevant trees.
>>
>> Please review.
>>
>> Regards,
>>
>> Hans
>>
>>
>> Hans de Goede (14):
>>    ACPI: video: Add a native function parameter to
>>      acpi_video_get_backlight_type()
>>    drm/i915: Don't register backlight when another backlight should be
>>      used
>>    drm/amdgpu: Don't register backlight when another backlight should be
>>      used
>>    drm/radeon: Don't register backlight when another backlight should be
>>      used
>>    drm/nouveau: Don't register backlight when another backlight should be
>>      used
>>    ACPI: video: Drop backlight_device_get_by_type() call from
>>      acpi_video_get_backlight_type()
>>    ACPI: video: Remove acpi_video_bus from list before tearing it down
>>    ACPI: video: Simplify acpi_video_unregister_backlight()
>>    ACPI: video: Make backlight class device registration a separate step
>>    ACPI: video: Remove code to unregister acpi_video backlight when a
>>      native backlight registers
>>    drm/i915: Call acpi_video_register_backlight()
>>    drm/nouveau: Register ACPI video backlight when nv_backlight
>>      registration fails
>>    drm/amdgpu: Register ACPI video backlight when skipping amdgpu
>>      backlight registration
>>    drm/radeon: Register ACPI video backlight when skipping radeon
>>      backlight registration
>>
>>   drivers/acpi/acpi_video.c                     | 69 ++++++++++++++-----
>>   drivers/acpi/video_detect.c                   | 53 +++-----------
>>   drivers/gpu/drm/Kconfig                       |  2 +
>>   .../gpu/drm/amd/amdgpu/atombios_encoders.c    | 14 +++-
>>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  9 +++
>>   .../gpu/drm/i915/display/intel_backlight.c    |  7 ++
>>   drivers/gpu/drm/i915/display/intel_display.c  |  1 +
>>   drivers/gpu/drm/i915/display/intel_opregion.c |  2 +-
>>   drivers/gpu/drm/nouveau/nouveau_backlight.c   | 14 ++++
>>   drivers/gpu/drm/radeon/atombios_encoders.c    |  7 ++
>>   drivers/gpu/drm/radeon/radeon_encoders.c      | 11 ++-
>>   .../gpu/drm/radeon/radeon_legacy_encoders.c   |  7 ++
>>   drivers/platform/x86/acer-wmi.c               |  2 +-
>>   drivers/platform/x86/asus-laptop.c            |  2 +-
>>   drivers/platform/x86/asus-wmi.c               |  4 +-
>>   drivers/platform/x86/compal-laptop.c          |  2 +-
>>   drivers/platform/x86/dell/dell-laptop.c       |  2 +-
>>   drivers/platform/x86/eeepc-laptop.c           |  2 +-
>>   drivers/platform/x86/fujitsu-laptop.c         |  4 +-
>>   drivers/platform/x86/ideapad-laptop.c         |  2 +-
>>   drivers/platform/x86/intel/oaktrail.c         |  2 +-
>>   drivers/platform/x86/msi-laptop.c             |  2 +-
>>   drivers/platform/x86/msi-wmi.c                |  2 +-
>>   drivers/platform/x86/samsung-laptop.c         |  2 +-
>>   drivers/platform/x86/sony-laptop.c            |  2 +-
>>   drivers/platform/x86/thinkpad_acpi.c          |  4 +-
>>   drivers/platform/x86/toshiba_acpi.c           |  2 +-
>>   include/acpi/video.h                          |  8 ++-
>>   28 files changed, 156 insertions(+), 84 deletions(-)

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Dadap <ddadap@nvidia.com>
To: "Jani Nikula" <jani.nikula@linux.intel.com>,
	"Hans de Goede" <hdegoede@redhat.com>,
	"Ben Skeggs" <bskeggs@redhat.com>,
	"Karol Herbst" <kherbst@redhat.com>, Lyude <lyude@redhat.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Tvrtko Ursulin" <tvrtko.ursulin@linux.intel.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Pan, Xinhui" <Xinhui.Pan@amd.com>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	"Mika Westerberg" <mika.westerberg@linux.intel.com>,
	"Mark Gross" <markgross@kernel.org>,
	"Andy Shevchenko" <andy@kernel.org>
Cc: David Airlie <airlied@linux.ie>,
	nouveau@lists.freedesktop.org,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	amd-gfx@lists.freedesktop.org,
	platform-driver-x86@vger.kernel.org, linux-acpi@vger.kernel.org,
	dri-devel@lists.freedesktop.org, Daniel Vetter <daniel@ffwll.ch>,
	Len Brown <lenb@kernel.org>
Subject: Re: [Nouveau] [PATCH 00/14] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display
Date: Wed, 25 May 2022 11:24:43 -0500	[thread overview]
Message-ID: <628007f0-22dc-c684-e530-f56a6e9186a4@nvidia.com> (raw)
In-Reply-To: <871qwrfcwr.fsf@intel.com>

On 5/18/22 03:44, Jani Nikula wrote:
> On Tue, 17 May 2022, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi All,
>>
>> As mentioned in my RFC titled "drm/kms: control display brightness through
>> drm_connector properties":
>> https://lore.kernel.org/dri-devel/0d188965-d809-81b5-74ce-7d30c49fee2d@redhat.com/
>>
>> The first step towards this is to deal with some existing technical debt
>> in backlight handling on x86/ACPI boards, specifically we need to stop
>> registering multiple /sys/class/backlight devs for a single display.
> I guess my question here is, how do you know it's for a *single*
> display?
>
> There are already designs out there with two flat panels, with
> independent brightness controls. They're still rare and I don't think we
> handle them very well. But we've got code to register multiple native
> backlight interfaces, see e.g. commit 20f85ef89d94 ("drm/i915/backlight:
> use unique backlight device names").


This is one of my concerns as well. There are a small number of (mostly 
somewhat old) designs with more than one internal panel. Since the 
intent here is to tie the new backlight UAPI to DRM connectors, I think 
it should remain possible to address each panel individually (the goal 
is to stop having multiple backlight handlers, all of which control the 
same display, not to stop having multiple backlight handlers in 
general). Where I think it might get tricky is when the same display 
might be driven by one GPU or another at different times, for example, 
with a switchable mux. Notebook designs which use the 
nvidia-wmi-ec-backlight driver will use the same backlight handler for 
the display regardless of which GPU is currently driving it, but I 
believe there are other designs where the same panel might have 
backlight controlled by either the iGPU or the dGPU, depending on the 
mux state.


> So imagine a design where one of the panels needs backlight control via
> ACPI and the other via native backlight control. Granted, I don't know
> if one exists, but I think it's very much in the realm of possible
> things the OEMs might do. For example, have an EC PWM for primary panel
> backlight, and use GPU PWM for secondary. How do you know you actually
> do need to register two interfaces?


The "how do you know" question is one I am wondering as well. I need to 
check with some of our backlight experts here at NVIDIA to figure out 
how exactly reliably we are able to make this determination.


> I'm fine with dealing with such cases as they arise to avoid
> over-engineering up front, but I also don't want us to completely paint
> ourselves in a corner either.
>
> BR,
> Jani.
>
>
>> This series implements my RFC describing my plan for these cleanups:
>> https://lore.kernel.org/dri-devel/98519ba0-7f18-201a-ea34-652f50343158@redhat.com/
>>
>> Specifically patches 1-6 implement the "Fixing kms driver unconditionally
>> register their "native" backlight dev" part.
>>
>> And patches 7-14 implement the "Fixing acpi_video0 getting registered for
>> a brief time" time.
>>
>> Note this series does not deal yet with the "Other issues" part, I plan
>> to do a follow up series for that.
>>
>> The changes in this series are good to have regardless of the further
>> "drm/kms: control display brightness through drm_connector properties"
>> plans. So I plan to push these upstream once they are ready (once
>> reviewed). Since this crosses various subsystems / touches multiple
>> kms drivers my plan is to provide an immutable branch based on say
>> 5.19-rc1 and then have that get merged into all the relevant trees.
>>
>> Please review.
>>
>> Regards,
>>
>> Hans
>>
>>
>> Hans de Goede (14):
>>    ACPI: video: Add a native function parameter to
>>      acpi_video_get_backlight_type()
>>    drm/i915: Don't register backlight when another backlight should be
>>      used
>>    drm/amdgpu: Don't register backlight when another backlight should be
>>      used
>>    drm/radeon: Don't register backlight when another backlight should be
>>      used
>>    drm/nouveau: Don't register backlight when another backlight should be
>>      used
>>    ACPI: video: Drop backlight_device_get_by_type() call from
>>      acpi_video_get_backlight_type()
>>    ACPI: video: Remove acpi_video_bus from list before tearing it down
>>    ACPI: video: Simplify acpi_video_unregister_backlight()
>>    ACPI: video: Make backlight class device registration a separate step
>>    ACPI: video: Remove code to unregister acpi_video backlight when a
>>      native backlight registers
>>    drm/i915: Call acpi_video_register_backlight()
>>    drm/nouveau: Register ACPI video backlight when nv_backlight
>>      registration fails
>>    drm/amdgpu: Register ACPI video backlight when skipping amdgpu
>>      backlight registration
>>    drm/radeon: Register ACPI video backlight when skipping radeon
>>      backlight registration
>>
>>   drivers/acpi/acpi_video.c                     | 69 ++++++++++++++-----
>>   drivers/acpi/video_detect.c                   | 53 +++-----------
>>   drivers/gpu/drm/Kconfig                       |  2 +
>>   .../gpu/drm/amd/amdgpu/atombios_encoders.c    | 14 +++-
>>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  9 +++
>>   .../gpu/drm/i915/display/intel_backlight.c    |  7 ++
>>   drivers/gpu/drm/i915/display/intel_display.c  |  1 +
>>   drivers/gpu/drm/i915/display/intel_opregion.c |  2 +-
>>   drivers/gpu/drm/nouveau/nouveau_backlight.c   | 14 ++++
>>   drivers/gpu/drm/radeon/atombios_encoders.c    |  7 ++
>>   drivers/gpu/drm/radeon/radeon_encoders.c      | 11 ++-
>>   .../gpu/drm/radeon/radeon_legacy_encoders.c   |  7 ++
>>   drivers/platform/x86/acer-wmi.c               |  2 +-
>>   drivers/platform/x86/asus-laptop.c            |  2 +-
>>   drivers/platform/x86/asus-wmi.c               |  4 +-
>>   drivers/platform/x86/compal-laptop.c          |  2 +-
>>   drivers/platform/x86/dell/dell-laptop.c       |  2 +-
>>   drivers/platform/x86/eeepc-laptop.c           |  2 +-
>>   drivers/platform/x86/fujitsu-laptop.c         |  4 +-
>>   drivers/platform/x86/ideapad-laptop.c         |  2 +-
>>   drivers/platform/x86/intel/oaktrail.c         |  2 +-
>>   drivers/platform/x86/msi-laptop.c             |  2 +-
>>   drivers/platform/x86/msi-wmi.c                |  2 +-
>>   drivers/platform/x86/samsung-laptop.c         |  2 +-
>>   drivers/platform/x86/sony-laptop.c            |  2 +-
>>   drivers/platform/x86/thinkpad_acpi.c          |  4 +-
>>   drivers/platform/x86/toshiba_acpi.c           |  2 +-
>>   include/acpi/video.h                          |  8 ++-
>>   28 files changed, 156 insertions(+), 84 deletions(-)

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Dadap <ddadap@nvidia.com>
To: "Jani Nikula" <jani.nikula@linux.intel.com>,
	"Hans de Goede" <hdegoede@redhat.com>,
	"Ben Skeggs" <bskeggs@redhat.com>,
	"Karol Herbst" <kherbst@redhat.com>, Lyude <lyude@redhat.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Tvrtko Ursulin" <tvrtko.ursulin@linux.intel.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Pan, Xinhui" <Xinhui.Pan@amd.com>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	"Mika Westerberg" <mika.westerberg@linux.intel.com>,
	"Mark Gross" <markgross@kernel.org>,
	"Andy Shevchenko" <andy@kernel.org>
Cc: David Airlie <airlied@linux.ie>,
	nouveau@lists.freedesktop.org,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	amd-gfx@lists.freedesktop.org,
	platform-driver-x86@vger.kernel.org, linux-acpi@vger.kernel.org,
	dri-devel@lists.freedesktop.org, Len Brown <lenb@kernel.org>
Subject: Re: [PATCH 00/14] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display
Date: Wed, 25 May 2022 11:24:43 -0500	[thread overview]
Message-ID: <628007f0-22dc-c684-e530-f56a6e9186a4@nvidia.com> (raw)
In-Reply-To: <871qwrfcwr.fsf@intel.com>

On 5/18/22 03:44, Jani Nikula wrote:
> On Tue, 17 May 2022, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi All,
>>
>> As mentioned in my RFC titled "drm/kms: control display brightness through
>> drm_connector properties":
>> https://lore.kernel.org/dri-devel/0d188965-d809-81b5-74ce-7d30c49fee2d@redhat.com/
>>
>> The first step towards this is to deal with some existing technical debt
>> in backlight handling on x86/ACPI boards, specifically we need to stop
>> registering multiple /sys/class/backlight devs for a single display.
> I guess my question here is, how do you know it's for a *single*
> display?
>
> There are already designs out there with two flat panels, with
> independent brightness controls. They're still rare and I don't think we
> handle them very well. But we've got code to register multiple native
> backlight interfaces, see e.g. commit 20f85ef89d94 ("drm/i915/backlight:
> use unique backlight device names").


This is one of my concerns as well. There are a small number of (mostly 
somewhat old) designs with more than one internal panel. Since the 
intent here is to tie the new backlight UAPI to DRM connectors, I think 
it should remain possible to address each panel individually (the goal 
is to stop having multiple backlight handlers, all of which control the 
same display, not to stop having multiple backlight handlers in 
general). Where I think it might get tricky is when the same display 
might be driven by one GPU or another at different times, for example, 
with a switchable mux. Notebook designs which use the 
nvidia-wmi-ec-backlight driver will use the same backlight handler for 
the display regardless of which GPU is currently driving it, but I 
believe there are other designs where the same panel might have 
backlight controlled by either the iGPU or the dGPU, depending on the 
mux state.


> So imagine a design where one of the panels needs backlight control via
> ACPI and the other via native backlight control. Granted, I don't know
> if one exists, but I think it's very much in the realm of possible
> things the OEMs might do. For example, have an EC PWM for primary panel
> backlight, and use GPU PWM for secondary. How do you know you actually
> do need to register two interfaces?


The "how do you know" question is one I am wondering as well. I need to 
check with some of our backlight experts here at NVIDIA to figure out 
how exactly reliably we are able to make this determination.


> I'm fine with dealing with such cases as they arise to avoid
> over-engineering up front, but I also don't want us to completely paint
> ourselves in a corner either.
>
> BR,
> Jani.
>
>
>> This series implements my RFC describing my plan for these cleanups:
>> https://lore.kernel.org/dri-devel/98519ba0-7f18-201a-ea34-652f50343158@redhat.com/
>>
>> Specifically patches 1-6 implement the "Fixing kms driver unconditionally
>> register their "native" backlight dev" part.
>>
>> And patches 7-14 implement the "Fixing acpi_video0 getting registered for
>> a brief time" time.
>>
>> Note this series does not deal yet with the "Other issues" part, I plan
>> to do a follow up series for that.
>>
>> The changes in this series are good to have regardless of the further
>> "drm/kms: control display brightness through drm_connector properties"
>> plans. So I plan to push these upstream once they are ready (once
>> reviewed). Since this crosses various subsystems / touches multiple
>> kms drivers my plan is to provide an immutable branch based on say
>> 5.19-rc1 and then have that get merged into all the relevant trees.
>>
>> Please review.
>>
>> Regards,
>>
>> Hans
>>
>>
>> Hans de Goede (14):
>>    ACPI: video: Add a native function parameter to
>>      acpi_video_get_backlight_type()
>>    drm/i915: Don't register backlight when another backlight should be
>>      used
>>    drm/amdgpu: Don't register backlight when another backlight should be
>>      used
>>    drm/radeon: Don't register backlight when another backlight should be
>>      used
>>    drm/nouveau: Don't register backlight when another backlight should be
>>      used
>>    ACPI: video: Drop backlight_device_get_by_type() call from
>>      acpi_video_get_backlight_type()
>>    ACPI: video: Remove acpi_video_bus from list before tearing it down
>>    ACPI: video: Simplify acpi_video_unregister_backlight()
>>    ACPI: video: Make backlight class device registration a separate step
>>    ACPI: video: Remove code to unregister acpi_video backlight when a
>>      native backlight registers
>>    drm/i915: Call acpi_video_register_backlight()
>>    drm/nouveau: Register ACPI video backlight when nv_backlight
>>      registration fails
>>    drm/amdgpu: Register ACPI video backlight when skipping amdgpu
>>      backlight registration
>>    drm/radeon: Register ACPI video backlight when skipping radeon
>>      backlight registration
>>
>>   drivers/acpi/acpi_video.c                     | 69 ++++++++++++++-----
>>   drivers/acpi/video_detect.c                   | 53 +++-----------
>>   drivers/gpu/drm/Kconfig                       |  2 +
>>   .../gpu/drm/amd/amdgpu/atombios_encoders.c    | 14 +++-
>>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  9 +++
>>   .../gpu/drm/i915/display/intel_backlight.c    |  7 ++
>>   drivers/gpu/drm/i915/display/intel_display.c  |  1 +
>>   drivers/gpu/drm/i915/display/intel_opregion.c |  2 +-
>>   drivers/gpu/drm/nouveau/nouveau_backlight.c   | 14 ++++
>>   drivers/gpu/drm/radeon/atombios_encoders.c    |  7 ++
>>   drivers/gpu/drm/radeon/radeon_encoders.c      | 11 ++-
>>   .../gpu/drm/radeon/radeon_legacy_encoders.c   |  7 ++
>>   drivers/platform/x86/acer-wmi.c               |  2 +-
>>   drivers/platform/x86/asus-laptop.c            |  2 +-
>>   drivers/platform/x86/asus-wmi.c               |  4 +-
>>   drivers/platform/x86/compal-laptop.c          |  2 +-
>>   drivers/platform/x86/dell/dell-laptop.c       |  2 +-
>>   drivers/platform/x86/eeepc-laptop.c           |  2 +-
>>   drivers/platform/x86/fujitsu-laptop.c         |  4 +-
>>   drivers/platform/x86/ideapad-laptop.c         |  2 +-
>>   drivers/platform/x86/intel/oaktrail.c         |  2 +-
>>   drivers/platform/x86/msi-laptop.c             |  2 +-
>>   drivers/platform/x86/msi-wmi.c                |  2 +-
>>   drivers/platform/x86/samsung-laptop.c         |  2 +-
>>   drivers/platform/x86/sony-laptop.c            |  2 +-
>>   drivers/platform/x86/thinkpad_acpi.c          |  4 +-
>>   drivers/platform/x86/toshiba_acpi.c           |  2 +-
>>   include/acpi/video.h                          |  8 ++-
>>   28 files changed, 156 insertions(+), 84 deletions(-)

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Dadap <ddadap@nvidia.com>
To: "Jani Nikula" <jani.nikula@linux.intel.com>,
	"Hans de Goede" <hdegoede@redhat.com>,
	"Ben Skeggs" <bskeggs@redhat.com>,
	"Karol Herbst" <kherbst@redhat.com>, Lyude <lyude@redhat.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Tvrtko Ursulin" <tvrtko.ursulin@linux.intel.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Pan, Xinhui" <Xinhui.Pan@amd.com>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	"Mika Westerberg" <mika.westerberg@linux.intel.com>,
	"Mark Gross" <markgross@kernel.org>,
	"Andy Shevchenko" <andy@kernel.org>
Cc: David Airlie <airlied@linux.ie>,
	nouveau@lists.freedesktop.org,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	amd-gfx@lists.freedesktop.org,
	platform-driver-x86@vger.kernel.org, linux-acpi@vger.kernel.org,
	dri-devel@lists.freedesktop.org, Daniel Vetter <daniel@ffwll.ch>,
	Len Brown <lenb@kernel.org>
Subject: Re: [PATCH 00/14] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display
Date: Wed, 25 May 2022 11:24:43 -0500	[thread overview]
Message-ID: <628007f0-22dc-c684-e530-f56a6e9186a4@nvidia.com> (raw)
In-Reply-To: <871qwrfcwr.fsf@intel.com>

On 5/18/22 03:44, Jani Nikula wrote:
> On Tue, 17 May 2022, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi All,
>>
>> As mentioned in my RFC titled "drm/kms: control display brightness through
>> drm_connector properties":
>> https://lore.kernel.org/dri-devel/0d188965-d809-81b5-74ce-7d30c49fee2d@redhat.com/
>>
>> The first step towards this is to deal with some existing technical debt
>> in backlight handling on x86/ACPI boards, specifically we need to stop
>> registering multiple /sys/class/backlight devs for a single display.
> I guess my question here is, how do you know it's for a *single*
> display?
>
> There are already designs out there with two flat panels, with
> independent brightness controls. They're still rare and I don't think we
> handle them very well. But we've got code to register multiple native
> backlight interfaces, see e.g. commit 20f85ef89d94 ("drm/i915/backlight:
> use unique backlight device names").


This is one of my concerns as well. There are a small number of (mostly 
somewhat old) designs with more than one internal panel. Since the 
intent here is to tie the new backlight UAPI to DRM connectors, I think 
it should remain possible to address each panel individually (the goal 
is to stop having multiple backlight handlers, all of which control the 
same display, not to stop having multiple backlight handlers in 
general). Where I think it might get tricky is when the same display 
might be driven by one GPU or another at different times, for example, 
with a switchable mux. Notebook designs which use the 
nvidia-wmi-ec-backlight driver will use the same backlight handler for 
the display regardless of which GPU is currently driving it, but I 
believe there are other designs where the same panel might have 
backlight controlled by either the iGPU or the dGPU, depending on the 
mux state.


> So imagine a design where one of the panels needs backlight control via
> ACPI and the other via native backlight control. Granted, I don't know
> if one exists, but I think it's very much in the realm of possible
> things the OEMs might do. For example, have an EC PWM for primary panel
> backlight, and use GPU PWM for secondary. How do you know you actually
> do need to register two interfaces?


The "how do you know" question is one I am wondering as well. I need to 
check with some of our backlight experts here at NVIDIA to figure out 
how exactly reliably we are able to make this determination.


> I'm fine with dealing with such cases as they arise to avoid
> over-engineering up front, but I also don't want us to completely paint
> ourselves in a corner either.
>
> BR,
> Jani.
>
>
>> This series implements my RFC describing my plan for these cleanups:
>> https://lore.kernel.org/dri-devel/98519ba0-7f18-201a-ea34-652f50343158@redhat.com/
>>
>> Specifically patches 1-6 implement the "Fixing kms driver unconditionally
>> register their "native" backlight dev" part.
>>
>> And patches 7-14 implement the "Fixing acpi_video0 getting registered for
>> a brief time" time.
>>
>> Note this series does not deal yet with the "Other issues" part, I plan
>> to do a follow up series for that.
>>
>> The changes in this series are good to have regardless of the further
>> "drm/kms: control display brightness through drm_connector properties"
>> plans. So I plan to push these upstream once they are ready (once
>> reviewed). Since this crosses various subsystems / touches multiple
>> kms drivers my plan is to provide an immutable branch based on say
>> 5.19-rc1 and then have that get merged into all the relevant trees.
>>
>> Please review.
>>
>> Regards,
>>
>> Hans
>>
>>
>> Hans de Goede (14):
>>    ACPI: video: Add a native function parameter to
>>      acpi_video_get_backlight_type()
>>    drm/i915: Don't register backlight when another backlight should be
>>      used
>>    drm/amdgpu: Don't register backlight when another backlight should be
>>      used
>>    drm/radeon: Don't register backlight when another backlight should be
>>      used
>>    drm/nouveau: Don't register backlight when another backlight should be
>>      used
>>    ACPI: video: Drop backlight_device_get_by_type() call from
>>      acpi_video_get_backlight_type()
>>    ACPI: video: Remove acpi_video_bus from list before tearing it down
>>    ACPI: video: Simplify acpi_video_unregister_backlight()
>>    ACPI: video: Make backlight class device registration a separate step
>>    ACPI: video: Remove code to unregister acpi_video backlight when a
>>      native backlight registers
>>    drm/i915: Call acpi_video_register_backlight()
>>    drm/nouveau: Register ACPI video backlight when nv_backlight
>>      registration fails
>>    drm/amdgpu: Register ACPI video backlight when skipping amdgpu
>>      backlight registration
>>    drm/radeon: Register ACPI video backlight when skipping radeon
>>      backlight registration
>>
>>   drivers/acpi/acpi_video.c                     | 69 ++++++++++++++-----
>>   drivers/acpi/video_detect.c                   | 53 +++-----------
>>   drivers/gpu/drm/Kconfig                       |  2 +
>>   .../gpu/drm/amd/amdgpu/atombios_encoders.c    | 14 +++-
>>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  9 +++
>>   .../gpu/drm/i915/display/intel_backlight.c    |  7 ++
>>   drivers/gpu/drm/i915/display/intel_display.c  |  1 +
>>   drivers/gpu/drm/i915/display/intel_opregion.c |  2 +-
>>   drivers/gpu/drm/nouveau/nouveau_backlight.c   | 14 ++++
>>   drivers/gpu/drm/radeon/atombios_encoders.c    |  7 ++
>>   drivers/gpu/drm/radeon/radeon_encoders.c      | 11 ++-
>>   .../gpu/drm/radeon/radeon_legacy_encoders.c   |  7 ++
>>   drivers/platform/x86/acer-wmi.c               |  2 +-
>>   drivers/platform/x86/asus-laptop.c            |  2 +-
>>   drivers/platform/x86/asus-wmi.c               |  4 +-
>>   drivers/platform/x86/compal-laptop.c          |  2 +-
>>   drivers/platform/x86/dell/dell-laptop.c       |  2 +-
>>   drivers/platform/x86/eeepc-laptop.c           |  2 +-
>>   drivers/platform/x86/fujitsu-laptop.c         |  4 +-
>>   drivers/platform/x86/ideapad-laptop.c         |  2 +-
>>   drivers/platform/x86/intel/oaktrail.c         |  2 +-
>>   drivers/platform/x86/msi-laptop.c             |  2 +-
>>   drivers/platform/x86/msi-wmi.c                |  2 +-
>>   drivers/platform/x86/samsung-laptop.c         |  2 +-
>>   drivers/platform/x86/sony-laptop.c            |  2 +-
>>   drivers/platform/x86/thinkpad_acpi.c          |  4 +-
>>   drivers/platform/x86/toshiba_acpi.c           |  2 +-
>>   include/acpi/video.h                          |  8 ++-
>>   28 files changed, 156 insertions(+), 84 deletions(-)

  parent reply	other threads:[~2022-05-25 16:25 UTC|newest]

Thread overview: 147+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-17 15:23 [PATCH 00/14] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
2022-05-17 15:23 ` Hans de Goede
2022-05-17 15:23 ` [Intel-gfx] " Hans de Goede
2022-05-17 15:23 ` Hans de Goede
2022-05-17 15:23 ` [Nouveau] " Hans de Goede
2022-05-17 15:23 ` [PATCH 01/14] ACPI: video: Add a native function parameter to acpi_video_get_backlight_type() Hans de Goede
2022-05-17 15:23   ` Hans de Goede
2022-05-17 15:23   ` [Intel-gfx] " Hans de Goede
2022-05-17 15:23   ` Hans de Goede
2022-05-17 15:23   ` [Nouveau] " Hans de Goede
2022-05-18  8:55   ` Jani Nikula
2022-05-18  8:55     ` Jani Nikula
2022-05-18  8:55     ` [Intel-gfx] " Jani Nikula
2022-05-18  8:55     ` [Nouveau] " Jani Nikula
2022-05-18  8:55     ` Jani Nikula
2022-05-18 10:06     ` [Nouveau] " Hans de Goede
2022-05-18 10:06       ` Hans de Goede
2022-05-18 10:06       ` [Intel-gfx] " Hans de Goede
2022-05-18 10:06       ` Hans de Goede
2022-05-18 10:06       ` Hans de Goede
2022-05-19  9:02       ` Jani Nikula
2022-05-19  9:02         ` Jani Nikula
2022-05-19  9:02         ` [Intel-gfx] " Jani Nikula
2022-05-19  9:02         ` Jani Nikula
2022-05-19  9:02         ` [Nouveau] " Jani Nikula
2022-06-21 10:06         ` Hans de Goede
2022-06-21 10:06           ` Hans de Goede
2022-06-21 10:06           ` [Intel-gfx] " Hans de Goede
2022-06-21 10:06           ` Hans de Goede
2022-06-21 10:06           ` [Nouveau] " Hans de Goede
2022-05-17 15:23 ` [PATCH 02/14] drm/i915: Don't register backlight when another backlight should be used Hans de Goede
2022-05-17 15:23   ` Hans de Goede
2022-05-17 15:23   ` [Intel-gfx] " Hans de Goede
2022-05-17 15:23   ` Hans de Goede
2022-05-17 15:23   ` [Nouveau] " Hans de Goede
2022-05-17 15:23 ` [PATCH 03/14] drm/amdgpu: " Hans de Goede
2022-05-17 15:23   ` Hans de Goede
2022-05-17 15:23   ` [Intel-gfx] " Hans de Goede
2022-05-17 15:23   ` Hans de Goede
2022-05-17 15:23   ` [Nouveau] " Hans de Goede
2022-05-17 15:23 ` [PATCH 04/14] drm/radeon: " Hans de Goede
2022-05-17 15:23   ` Hans de Goede
2022-05-17 15:23   ` [Intel-gfx] " Hans de Goede
2022-05-17 15:23   ` Hans de Goede
2022-05-17 15:23   ` [Nouveau] " Hans de Goede
2022-05-17 15:23 ` [PATCH 05/14] drm/nouveau: " Hans de Goede
2022-05-17 15:23   ` Hans de Goede
2022-05-17 15:23   ` [Intel-gfx] " Hans de Goede
2022-05-17 15:23   ` Hans de Goede
2022-05-17 15:23   ` [Nouveau] " Hans de Goede
2022-05-18 17:05   ` Lyude Paul
2022-05-18 17:05     ` Lyude Paul
2022-05-18 17:05     ` [Intel-gfx] " Lyude Paul
2022-05-18 17:05     ` Lyude Paul
2022-05-18 17:05     ` [Nouveau] " Lyude Paul
2022-05-17 15:23 ` [PATCH 06/14] ACPI: video: Drop backlight_device_get_by_type() call from acpi_video_get_backlight_type() Hans de Goede
2022-05-17 15:23   ` Hans de Goede
2022-05-17 15:23   ` [Intel-gfx] " Hans de Goede
2022-05-17 15:23   ` Hans de Goede
2022-05-17 15:23   ` [Nouveau] " Hans de Goede
2022-05-17 15:23 ` [PATCH 07/14] ACPI: video: Remove acpi_video_bus from list before tearing it down Hans de Goede
2022-05-17 15:23   ` Hans de Goede
2022-05-17 15:23   ` [Intel-gfx] " Hans de Goede
2022-05-17 15:23   ` Hans de Goede
2022-05-17 15:23   ` [Nouveau] " Hans de Goede
2022-05-17 15:23 ` [PATCH 08/14] ACPI: video: Simplify acpi_video_unregister_backlight() Hans de Goede
2022-05-17 15:23   ` Hans de Goede
2022-05-17 15:23   ` [Intel-gfx] " Hans de Goede
2022-05-17 15:23   ` Hans de Goede
2022-05-17 15:23   ` [Nouveau] " Hans de Goede
2022-05-17 15:23 ` [PATCH 09/14] ACPI: video: Make backlight class device registration a separate step Hans de Goede
2022-05-17 15:23   ` Hans de Goede
2022-05-17 15:23   ` [Intel-gfx] " Hans de Goede
2022-05-17 15:23   ` Hans de Goede
2022-05-17 15:23   ` [Nouveau] " Hans de Goede
2022-05-20 21:41   ` Daniel Dadap
2022-05-20 21:41     ` Daniel Dadap
2022-05-20 21:41     ` Daniel Dadap
2022-05-20 21:41     ` [Nouveau] " Daniel Dadap
2022-05-23 23:25     ` Daniel Dadap
2022-05-23 23:25       ` Daniel Dadap
2022-05-23 23:25       ` Daniel Dadap
2022-05-24  7:10       ` Hans de Goede
2022-05-24  7:10         ` Hans de Goede
2022-05-24  7:10         ` [Intel-gfx] " Hans de Goede
2022-05-24  7:10         ` [Nouveau] " Hans de Goede
2022-05-24  7:10         ` Hans de Goede
2022-05-17 15:23 ` [PATCH 10/14] ACPI: video: Remove code to unregister acpi_video backlight when a native backlight registers Hans de Goede
2022-05-17 15:23   ` Hans de Goede
2022-05-17 15:23   ` [Intel-gfx] " Hans de Goede
2022-05-17 15:23   ` Hans de Goede
2022-05-17 15:23   ` [Nouveau] " Hans de Goede
2022-05-17 15:23 ` [PATCH 11/14] drm/i915: Call acpi_video_register_backlight() Hans de Goede
2022-05-17 15:23   ` Hans de Goede
2022-05-17 15:23   ` [Intel-gfx] " Hans de Goede
2022-05-17 15:23   ` Hans de Goede
2022-05-17 15:23   ` [Nouveau] " Hans de Goede
2022-05-17 15:23 ` [PATCH 12/14] drm/nouveau: Register ACPI video backlight when nv_backlight registration fails Hans de Goede
2022-05-17 15:23   ` Hans de Goede
2022-05-17 15:23   ` [Intel-gfx] " Hans de Goede
2022-05-17 15:23   ` Hans de Goede
2022-05-17 15:23   ` [Nouveau] " Hans de Goede
2022-05-18 17:39   ` Lyude Paul
2022-05-18 17:39     ` [Intel-gfx] " Lyude Paul
2022-05-18 17:39     ` Lyude Paul
2022-05-18 17:39     ` [Nouveau] " Lyude Paul
2022-05-18 17:39     ` Lyude Paul
2022-06-03  6:55     ` Hans de Goede
2022-06-03  6:55       ` Hans de Goede
2022-06-03  6:55       ` [Intel-gfx] " Hans de Goede
2022-06-03  6:55       ` Hans de Goede
2022-06-03  6:55       ` [Nouveau] " Hans de Goede
2022-05-17 15:23 ` [PATCH 13/14] drm/amdgpu: Register ACPI video backlight when skipping amdgpu backlight registration Hans de Goede
2022-05-17 15:23   ` Hans de Goede
2022-05-17 15:23   ` [Intel-gfx] " Hans de Goede
2022-05-17 15:23   ` Hans de Goede
2022-05-17 15:23   ` [Nouveau] " Hans de Goede
2022-05-17 15:23 ` [PATCH 14/14] drm/radeon: Register ACPI video backlight when skipping radeon " Hans de Goede
2022-05-17 15:23   ` Hans de Goede
2022-05-17 15:23   ` [Intel-gfx] " Hans de Goede
2022-05-17 15:23   ` Hans de Goede
2022-05-17 15:23   ` [Nouveau] " Hans de Goede
2022-05-17 19:03 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Patchwork
2022-05-18  8:44 ` [PATCH 00/14] " Jani Nikula
2022-05-18  8:44   ` Jani Nikula
2022-05-18  8:44   ` [Intel-gfx] " Jani Nikula
2022-05-18  8:44   ` Jani Nikula
2022-05-18  8:44   ` [Nouveau] " Jani Nikula
2022-05-18 10:04   ` Hans de Goede
2022-05-18 10:04     ` Hans de Goede
2022-05-18 10:04     ` [Intel-gfx] " Hans de Goede
2022-05-18 10:04     ` Hans de Goede
2022-05-18 10:04     ` [Nouveau] " Hans de Goede
2022-05-18 10:12     ` Jani Nikula
2022-05-18 10:12       ` Jani Nikula
2022-05-18 10:12       ` [Intel-gfx] " Jani Nikula
2022-05-18 10:12       ` Jani Nikula
2022-05-18 10:12       ` Jani Nikula
2022-05-25 15:12       ` Daniel Vetter
2022-05-25 15:12         ` Daniel Vetter
2022-05-25 15:12         ` [Intel-gfx] " Daniel Vetter
2022-05-25 15:12         ` Daniel Vetter
2022-05-25 15:12         ` [Nouveau] " Daniel Vetter
2022-05-25 16:24   ` Daniel Dadap [this message]
2022-05-25 16:24     ` Daniel Dadap
2022-05-25 16:24     ` Daniel Dadap
2022-05-25 16:24     ` [Nouveau] " Daniel Dadap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=628007f0-22dc-c684-e530-f56a6e9186a4@nvidia.com \
    --to=ddadap@nvidia.com \
    --cc=Xinhui.Pan@amd.com \
    --cc=airlied@linux.ie \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=andy@kernel.org \
    --cc=bskeggs@redhat.com \
    --cc=christian.koenig@amd.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hdegoede@redhat.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=kherbst@redhat.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=lyude@redhat.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=markgross@kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=tvrtko.ursulin@linux.intel.com \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.