From: Daniel Dadap <ddadap@nvidia.com>
To: "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>,
"Jani Nikula" <jani.nikula@linux.intel.com>,
"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>,
Xinhui <Xinhui.Pan@amd.com>,
"Rafael J . Wysocki" <rafael@kernel.org>,
"Mika Westerberg" <mika.westerberg@linux.intel.com>,
"Lukas Wunner" <lukas@wunner.de>,
"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>,
"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
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: [Intel-gfx] [PATCH v3 09/31] ACPI: video: Make backlight class device registration a separate step (v2)
Date: Thu, 18 Aug 2022 15:07:46 -0500 [thread overview]
Message-ID: <b177636d-bc68-cd25-4a28-8131ef4625fe@nvidia.com> (raw)
In-Reply-To: <20220818184302.10051-10-hdegoede@redhat.com>
On 8/18/22 1:42 PM, Hans de Goede wrote:
> On x86/ACPI boards the acpi_video driver will usually initialize before
> the kms driver (except i915). This causes /sys/class/backlight/acpi_video0
> to show up and then the kms driver registers its own native backlight
> device after which the drivers/acpi/video_detect.c code unregisters
> the acpi_video0 device (when acpi_video_get_backlight_type()==native).
>
> This means that userspace briefly sees 2 devices and the disappearing of
> acpi_video0 after a brief time confuses the systemd backlight level
> save/restore code, see e.g.:
> https://bbs.archlinux.org/viewtopic.php?id=269920
>
> To fix this make backlight class device registration a separate step
> done by a new acpi_video_register_backlight() function. The intend is for
> this to be called by the drm/kms driver *after* it is done setting up its
> own native backlight device. So that acpi_video_get_backlight_type() knows
> if a native backlight will be available or not at acpi_video backlight
> registration time, avoiding the add + remove dance.
>
> Note the new acpi_video_register_backlight() function is also called from
> a delayed work to ensure that the acpi_video backlight devices does get
> registered if necessary even if there is no drm/kms driver or when it is
> disabled.
>
> Changes in v2:
> - Make register_backlight_delay a module parameter, mainly so that it can
> be disabled by Nvidia binary driver users
>
> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/acpi/acpi_video.c | 50 ++++++++++++++++++++++++++++++++++++---
> include/acpi/video.h | 2 ++
> 2 files changed, 49 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
> index 8545bf94866f..09dd86f86cf3 100644
> --- a/drivers/acpi/acpi_video.c
> +++ b/drivers/acpi/acpi_video.c
> @@ -73,6 +73,16 @@ module_param(device_id_scheme, bool, 0444);
> static int only_lcd = -1;
> module_param(only_lcd, int, 0444);
>
> +/*
> + * Display probing is known to take up to 5 seconds, so delay the fallback
> + * backlight registration by 5 seconds + 3 seconds for some extra margin.
> + */
> +static int register_backlight_delay = 8;
> +module_param(register_backlight_delay, int, 0444);
Would it make sense to make this parameter writable from userspace, e.g.
so that it can be set by a udev rule rather than relying on a riskier
kernel command line edit? Then again, that probably makes things more
complicated, since you'd have to check the parameter again when the
worker fires, and changing the parameter to a non-zero value from either
zero or a different non-zero value would be too weird. And making a
separate writable parameter to allow userspace to turn the worker into a
noop despite it being enabled when the kernel was initially loaded seems
wrong, too.
> +MODULE_PARM_DESC(register_backlight_delay,
> + "Delay in seconds before doing fallback (non GPU driver triggered) "
> + "backlight registration, set to 0 to disable.");
> +
> static bool may_report_brightness_keys;
> static int register_count;
> static DEFINE_MUTEX(register_count_mutex);
> @@ -81,6 +91,9 @@ static LIST_HEAD(video_bus_head);
> static int acpi_video_bus_add(struct acpi_device *device);
> static int acpi_video_bus_remove(struct acpi_device *device);
> static void acpi_video_bus_notify(struct acpi_device *device, u32 event);
> +static void acpi_video_bus_register_backlight_work(struct work_struct *ignored);
> +static DECLARE_DELAYED_WORK(video_bus_register_backlight_work,
> + acpi_video_bus_register_backlight_work);
> void acpi_video_detect_exit(void);
>
> /*
> @@ -1859,8 +1872,6 @@ static int acpi_video_bus_register_backlight(struct acpi_video_bus *video)
> if (video->backlight_registered)
> return 0;
>
> - acpi_video_run_bcl_for_osi(video);
> -
> if (acpi_video_get_backlight_type() != acpi_backlight_video)
> return 0;
>
> @@ -2086,7 +2097,11 @@ static int acpi_video_bus_add(struct acpi_device *device)
> list_add_tail(&video->entry, &video_bus_head);
> mutex_unlock(&video_list_lock);
>
> - acpi_video_bus_register_backlight(video);
> + /*
> + * The userspace visible backlight_device gets registered separately
> + * from acpi_video_register_backlight().
> + */
> + acpi_video_run_bcl_for_osi(video);
> acpi_video_bus_add_notify_handler(video);
>
> return 0;
> @@ -2125,6 +2140,11 @@ static int acpi_video_bus_remove(struct acpi_device *device)
> return 0;
> }
>
> +static void acpi_video_bus_register_backlight_work(struct work_struct *ignored)
> +{
> + acpi_video_register_backlight();
> +}
> +
> static int __init is_i740(struct pci_dev *dev)
> {
> if (dev->device == 0x00D1)
> @@ -2235,6 +2255,18 @@ int acpi_video_register(void)
> */
> register_count = 1;
>
> + /*
> + * acpi_video_bus_add() skips registering the userspace visible
> + * backlight_device. The intend is for this to be registered by the
> + * drm/kms driver calling acpi_video_register_backlight() *after* it is
> + * done setting up its own native backlight device. The delayed work
> + * ensures that acpi_video_register_backlight() always gets called
> + * eventually, in case there is no drm/kms driver or it is disabled.
> + */
> + if (register_backlight_delay)
> + schedule_delayed_work(&video_bus_register_backlight_work,
> + register_backlight_delay * HZ);
> +
> leave:
> mutex_unlock(®ister_count_mutex);
> return ret;
> @@ -2245,6 +2277,7 @@ void acpi_video_unregister(void)
> {
> mutex_lock(®ister_count_mutex);
> if (register_count) {
> + cancel_delayed_work_sync(&video_bus_register_backlight_work);
> acpi_bus_unregister_driver(&acpi_video_bus);
> register_count = 0;
> may_report_brightness_keys = false;
> @@ -2253,6 +2286,17 @@ void acpi_video_unregister(void)
> }
> EXPORT_SYMBOL(acpi_video_unregister);
>
> +void acpi_video_register_backlight(void)
> +{
> + struct acpi_video_bus *video;
> +
> + mutex_lock(&video_list_lock);
> + list_for_each_entry(video, &video_bus_head, entry)
> + acpi_video_bus_register_backlight(video);
> + mutex_unlock(&video_list_lock);
> +}
> +EXPORT_SYMBOL(acpi_video_register_backlight);
> +
> void acpi_video_unregister_backlight(void)
> {
> struct acpi_video_bus *video;
> diff --git a/include/acpi/video.h b/include/acpi/video.h
> index 4705e339c252..0625806d3bbd 100644
> --- a/include/acpi/video.h
> +++ b/include/acpi/video.h
> @@ -53,6 +53,7 @@ enum acpi_backlight_type {
> #if IS_ENABLED(CONFIG_ACPI_VIDEO)
> extern int acpi_video_register(void);
> extern void acpi_video_unregister(void);
> +extern void acpi_video_register_backlight(void);
> extern int acpi_video_get_edid(struct acpi_device *device, int type,
> int device_id, void **edid);
> extern enum acpi_backlight_type acpi_video_get_backlight_type(void);
> @@ -69,6 +70,7 @@ extern int acpi_video_get_levels(struct acpi_device *device,
> #else
> static inline int acpi_video_register(void) { return -ENODEV; }
> static inline void acpi_video_unregister(void) { return; }
> +static inline void acpi_video_register_backlight(void) { return; }
> static inline int acpi_video_get_edid(struct acpi_device *device, int type,
> int device_id, void **edid)
> {
next prev parent reply other threads:[~2022-08-19 12:23 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-18 18:42 [Intel-gfx] [PATCH v3 00/31] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
2022-08-18 18:42 ` [Intel-gfx] [PATCH v3 01/31] ACPI: video: Add acpi_video_backlight_use_native() helper Hans de Goede
2022-08-18 18:42 ` [Intel-gfx] [PATCH v3 02/31] drm/i915: Don't register backlight when another backlight should be used Hans de Goede
2022-08-18 18:42 ` [Intel-gfx] [PATCH v3 03/31] drm/amdgpu: Don't register backlight when another backlight should be used (v3) Hans de Goede
2022-08-18 18:42 ` [Intel-gfx] [PATCH v3 04/31] drm/radeon: " Hans de Goede
2022-08-18 18:42 ` [Intel-gfx] [PATCH v3 05/31] drm/nouveau: Don't register backlight when another backlight should be used Hans de Goede
2022-08-18 18:42 ` [Intel-gfx] [PATCH v3 06/31] ACPI: video: Drop backlight_device_get_by_type() call from acpi_video_get_backlight_type() Hans de Goede
2022-08-18 18:42 ` [Intel-gfx] [PATCH v3 07/31] ACPI: video: Remove acpi_video_bus from list before tearing it down Hans de Goede
2022-08-18 18:42 ` [Intel-gfx] [PATCH v3 08/31] ACPI: video: Simplify acpi_video_unregister_backlight() Hans de Goede
2022-08-18 18:42 ` [Intel-gfx] [PATCH v3 09/31] ACPI: video: Make backlight class device registration a separate step (v2) Hans de Goede
2022-08-18 20:07 ` Daniel Dadap [this message]
2022-08-19 8:50 ` Hans de Goede
2022-08-18 18:42 ` [Intel-gfx] [PATCH v3 10/31] ACPI: video: Remove code to unregister acpi_video backlight when a native backlight registers Hans de Goede
2022-08-18 18:42 ` [Intel-gfx] [PATCH v3 11/31] drm/i915: Call acpi_video_register_backlight() (v2) Hans de Goede
2022-08-18 18:42 ` [Intel-gfx] [PATCH v3 12/31] drm/nouveau: Register ACPI video backlight when nv_backlight registration fails Hans de Goede
2022-08-18 18:42 ` [Intel-gfx] [PATCH v3 13/31] drm/amdgpu: Register ACPI video backlight when skipping amdgpu backlight registration Hans de Goede
2022-08-18 18:42 ` [Intel-gfx] [PATCH v3 14/31] drm/radeon: Register ACPI video backlight when skipping radeon " Hans de Goede
2022-08-18 18:42 ` [Intel-gfx] [PATCH v3 15/31] platform/x86: nvidia-wmi-ec-backlight: Move fw interface definitions to a header Hans de Goede
2022-08-18 19:38 ` Daniel Dadap
2022-08-19 10:05 ` Hans de Goede
2022-08-18 18:42 ` [Intel-gfx] [PATCH v3 16/31] ACPI: video: Refactor acpi_video_get_backlight_type() a bit Hans de Goede
2022-08-18 18:42 ` [Intel-gfx] [PATCH v3 17/31] ACPI: video: Add Nvidia WMI EC brightness control detection (v2) Hans de Goede
2022-08-18 19:44 ` Daniel Dadap
2022-08-18 18:42 ` [Intel-gfx] [PATCH v3 18/31] ACPI: video: Add Apple GMUX brightness control detection Hans de Goede
2022-08-18 18:42 ` [Intel-gfx] [PATCH v3 19/31] platform/x86: nvidia-wmi-ec-backlight: Use acpi_video_get_backlight_type() Hans de Goede
2022-08-18 19:46 ` Daniel Dadap
2022-08-18 18:42 ` [Intel-gfx] [PATCH v3 20/31] platform/x86: apple-gmux: Stop calling acpi/video.h functions Hans de Goede
2022-08-18 18:42 ` [Intel-gfx] [PATCH v3 21/31] platform/x86: toshiba_acpi: Stop using acpi_video_set_dmi_backlight_type() Hans de Goede
2022-08-18 18:42 ` [Intel-gfx] [PATCH v3 22/31] platform/x86: acer-wmi: Move backlight DMI quirks to acpi/video_detect.c Hans de Goede
2022-08-18 18:42 ` [Intel-gfx] [PATCH v3 23/31] platform/x86: asus-wmi: Drop DMI chassis-type check from backlight handling Hans de Goede
2022-08-18 18:42 ` [Intel-gfx] [PATCH v3 24/31] platform/x86: asus-wmi: Move acpi_backlight=vendor quirks to ACPI video_detect.c Hans de Goede
2022-08-18 18:42 ` [Intel-gfx] [PATCH v3 25/31] platform/x86: asus-wmi: Move acpi_backlight=native " Hans de Goede
2022-08-18 18:42 ` [Intel-gfx] [PATCH v3 26/31] platform/x86: samsung-laptop: Move acpi_backlight=[vendor|native] " Hans de Goede
2022-08-18 18:42 ` [Intel-gfx] [PATCH v3 27/31] ACPI: video: Remove acpi_video_set_dmi_backlight_type() Hans de Goede
2022-08-18 18:42 ` [Intel-gfx] [PATCH v3 28/31] ACPI: video: Drop "Samsung X360" acpi_backlight=native quirk Hans de Goede
2022-08-18 18:43 ` [Intel-gfx] [PATCH v3 29/31] ACPI: video: Drop NL5x?U, PF4NU1F and PF5?U?? acpi_backlight=native quirks Hans de Goede
2022-08-18 18:43 ` [Intel-gfx] [PATCH v3 30/31] ACPI: video: Fix indentation of video_detect_dmi_table[] entries Hans de Goede
2022-08-18 18:43 ` [Intel-gfx] [PATCH v3 31/31] drm/todo: Add entry about dealing with brightness control on devices with > 1 panel Hans de Goede
2022-08-24 19:33 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Patchwork
2022-08-24 19:33 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-08-24 20:03 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
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=b177636d-bc68-cd25-4a28-8131ef4625fe@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=lukas@wunner.de \
--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.j.wysocki@intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox