Re: [PATCH v1 1/1] treewide: Align match_string() with sysfs_match_string()

-rcX, or in Linux Next. > > But if you think differently, tell me. Thanks, the drivers/platform/x86 bits look good to me: Acked-by: Hans de Goede Regards, Hans > arch/powerpc/xmon/xmon.c | 5 ++-- > arch/x86/kernel/cpu/mtrr/if.c | 4 +-- &g

Re: [PATCH] arch: Fix name collision with ACPI's video.o

gt; Cc: Arnd Bergmann > Cc: linux-a...@vger.kernel.org > Cc: linux-fb...@vger.kernel.org > Cc: dri-de...@lists.freedesktop.org Thanks, patch looks good to me: Reviewed-by: Hans de Goede Regards, Hans > --- > arch/sparc/video/Makefile| 2 +- > arch/spa

Re: [PATCH] ACPI: video: Fix name collision with architecture's video.o

Hi, On 5/16/24 5:11 PM, Thomas Zimmermann wrote: > Hi > > Am 16.05.24 um 17:03 schrieb Hans de Goede: >> Hi, >> >> On 5/16/24 3:04 PM, Rafael J. Wysocki wrote: >>> CC Hans who has been doing the majority of the ACPI video work. >>> >>

Re: [PATCH] ACPI: video: Fix name collision with architecture's video.o

Hi, On 5/16/24 3:04 PM, Rafael J. Wysocki wrote: > CC Hans who has been doing the majority of the ACPI video work. > > On Thu, May 16, 2024 at 2:43 PM Thomas Zimmermann wrote: >> >> Commit 2fd001cd3600 ("arch: Rename fbdev header and source files") >> renames the video source files under arch/

[Intel-gfx] [PATCH] drm/i915/dsi: Use devm_gpiod_get() for all GPIOs

soc_gpio_set_value() already uses devm_gpiod_get(), lets be consistent and use devm_gpiod_get() for all GPIOs. This allows removing the intel_dsi_vbt_gpio_cleanup() function, which only function was to put the GPIO-descriptors. Signed-off-by: Hans de Goede --- Note this applies on top of Andy's

Re: [Intel-gfx] [rft, PATCH v4 00/16] drm/i915/dsi: 4th attempt to get rid of IOSF GPIO

ies is: Tested-by: Hans de Goede And the code of the entire series also looks good to me: Reviewed-by: Hans de Goede for the series. Regards, Hans > In v4: > - fixed compile time errors in patch 14 (Hans, LKP) > - fixed cover letter Subject > - added patch 15 (as sugg

Re: [Intel-gfx] [PATCH v3 14/15] drm/i915/dsi: Replace poking of CHV GPIOs behind the driver's back

Hi, On 11/2/23 16:12, Andy Shevchenko wrote: > It's a dirty hack in the driver that pokes GPIO registers behind > the driver's back. Moreoever it might be problematic as simultaneous > I/O may hang the system, see the commit 0bd50d719b00 ("pinctrl: > cherryview: prevent concurrent access to GPIO

Re: [Intel-gfx] [PATCH v2 6/7] drm/i915/dsi: Replace poking of CHV GPIOs behind the driver's back

Hi, On 11/2/23 15:19, Andy Shevchenko wrote: > On Wed, Nov 01, 2023 at 11:20:23AM +0100, Hans de Goede wrote: >> On 11/1/23 10:32, Andy Shevchenko wrote: >>> On Tue, Oct 31, 2023 at 10:15:52PM +0100, Hans de Goede wrote: >>>> On 10/31/23 17:07, Hans de Goede wrote:

Re: [Intel-gfx] [PATCH v2 6/7] drm/i915/dsi: Replace poking of CHV GPIOs behind the driver's back

Hi, On 11/1/23 11:20, Hans de Goede wrote: > Hi, > > On 11/1/23 10:32, Andy Shevchenko wrote: >> On Tue, Oct 31, 2023 at 10:15:52PM +0100, Hans de Goede wrote: >>> On 10/31/23 17:07, Hans de Goede wrote: >>>> On 10/24/23 18:11, Andy Shevchenko wrote: >

Re: [Intel-gfx] [PATCH v2 6/7] drm/i915/dsi: Replace poking of CHV GPIOs behind the driver's back

Hi, On 11/1/23 11:34, Ville Syrjälä wrote: > On Wed, Nov 01, 2023 at 11:20:23AM +0100, Hans de Goede wrote: >> Hi, >> >> On 11/1/23 10:32, Andy Shevchenko wrote: >>> On Tue, Oct 31, 2023 at 10:15:52PM +0100, Hans de Goede wrote: >>>> On 10/31/23 17:07, Ha

Re: [Intel-gfx] [PATCH v2 6/7] drm/i915/dsi: Replace poking of CHV GPIOs behind the driver's back

Hi, On 11/1/23 10:32, Andy Shevchenko wrote: > On Tue, Oct 31, 2023 at 10:15:52PM +0100, Hans de Goede wrote: >> On 10/31/23 17:07, Hans de Goede wrote: >>> On 10/24/23 18:11, Andy Shevchenko wrote: >>>> On Tue, Oct 24, 2023 at 06:57:38P

Re: [Intel-gfx] [PATCH v2 6/7] drm/i915/dsi: Replace poking of CHV GPIOs behind the driver's back

Hi, On 10/31/23 17:07, Hans de Goede wrote: > Hi Andy, > > On 10/24/23 18:11, Andy Shevchenko wrote: >> On Tue, Oct 24, 2023 at 06:57:38PM +0300, Andy Shevchenko wrote: >>> It's a dirty hack in the driver that pokes GPIO registers behind >>> the driver's back.

Re: [Intel-gfx] [PATCH v2 6/7] drm/i915/dsi: Replace poking of CHV GPIOs behind the driver's back

Hi Andy, On 10/24/23 18:11, Andy Shevchenko wrote: > On Tue, Oct 24, 2023 at 06:57:38PM +0300, Andy Shevchenko wrote: >> It's a dirty hack in the driver that pokes GPIO registers behind >> the driver's back. Moreoever it might be problematic as simultaneous >> I/O may hang the system, see the

Re: [Intel-gfx] [PATCH v3 1/3] pwm: make it possible to apply pwm changes in atomic context

Hi Sean, On 10/22/23 12:46, Sean Young wrote: > Hi Hans, > > On Sat, Oct 21, 2023 at 11:08:22AM +0200, Hans de Goede wrote: >> On 10/19/23 12:51, Uwe Kleine-König wrote: >>> On Wed, Oct 18, 2023 at 03:57:48PM +0200, Hans de Goede wrote: >>>> On 10/17/23

Re: [Intel-gfx] [PATCH v3 1/3] pwm: make it possible to apply pwm changes in atomic context

Hi Uwe, On 10/19/23 12:51, Uwe Kleine-König wrote: > On Wed, Oct 18, 2023 at 03:57:48PM +0200, Hans de Goede wrote: >> Hi Sean, >> >> On 10/17/23 11:17, Sean Young wrote: >>> Some drivers require sleeping, for example if the pwm device is connected >>> o

Re: [Intel-gfx] [PATCH v3 1/3] pwm: make it possible to apply pwm changes in atomic context

Hi Sean, On 10/17/23 11:17, Sean Young wrote: > Some drivers require sleeping, for example if the pwm device is connected > over i2c. The pwm-ir-tx requires precise timing, and sleeping causes havoc > with the generated IR signal when sleeping occurs. > > This patch makes it possible to use pwm

Re: [Intel-gfx] [rft, PATCH v1 0/2] drm/i915/dsi: An attempt to get rid of IOSF GPIO on VLV

Hi Andy, On 10/18/23 07:10, Andy Shevchenko wrote: > DSI code for VBT has a set of ugly GPIO hacks, one of which is direct > talking to GPIO IP behind the actual driver's back. An attempt to fix > that is here. > > If I understood correctly, my approach should work in the similar way as > the

Re: [Intel-gfx] [PATCH 0/4] drm/i915/vlv_dsi: Add quirks for x86 android tablets (v3)

Hi, On 10/11/23 15:05, Jani Nikula wrote: > On Sun, 08 Oct 2023, Hans de Goede wrote: >> Hi All, >> >> Ping what is the status of this now? This v3 addresses all review >> remarks from previous versions (specifically the request to file >> + link gitlab issue

Re: [Intel-gfx] [PATCH 0/4] drm/i915/vlv_dsi: Add quirks for x86 android tablets (v3)

, Hans On 9/20/23 21:56, Hans de Goede wrote: > Hi All, > > Some vlv/chv tablets ship with Android as factory OS. The factory OS > BSP style kernel on these tablets does not use the normal x86 hw > autodetection instead it hardcodes a whole bunch of things including > using pan

[Intel-gfx] [PATCH 2/4] drm/i915/vlv_dsi: Add DMI quirk for wrong I2C bus and panel size on Lenovo Yoga Tablet 2 series (v3)

, VBT info Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9379 Reviewed-by: Javier Martinez Canillas Signed-off-by: Hans de Goede --- drivers/gpu/drm/i915/display/vlv_dsi.c | 52 ++ 1 file changed, 52 insertions(+) diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c b/dri

[Intel-gfx] [PATCH 3/4] drm/i915/vlv_dsi: Add DMI quirk for backlight control issues on Lenovo Yoga Tab 3 (v2)

() to pick the wrong bus. 2. There is no backlight off sequence, causing the backlight to stay on. Add a DMI quirk fixing both issues. v2: - Add Closes tag to gitlab issue with drm.debug=0xe, VBT info Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9380 Signed-off-by: Hans de Goede

[Intel-gfx] [PATCH 4/4] drm/i915/dsi: Add some debug logging to mipi_exec_i2c (v2)

Add some debug logging to mipi_exec_i2c, to make debugging various issues seen with it easier. Changes in v2: - Drop unnecessary __func__ drm_dbg_kms() argument Signed-off-by: Hans de Goede --- drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

[Intel-gfx] [PATCH 1/4] drm/i915/vlv_dsi: Add DMI quirk for wrong panel modeline in BIOS on Asus TF103C (v3)

tag to gitlab issue with drm.debug=0xe, VBT info Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9381 Reviewed-by: Javier Martinez Canillas Signed-off-by: Hans de Goede --- drivers/gpu/drm/i915/display/vlv_dsi.c | 44 ++ 1 file changed, 44 insertions(+) diff --git a/

[Intel-gfx] [PATCH 0/4] drm/i915/vlv_dsi: Add quirks for x86 android tablets (v3)

affected models. Add Closes: tags with links to gitlab issues Regards, Hans Hans de Goede (4): drm/i915/vlv_dsi: Add DMI quirk for wrong panel modeline in BIOS on Asus TF103C (v3) drm/i915/vlv_dsi: Add DMI quirk for wrong I2C bus and panel size on Lenovo Yoga Tablet 2 series (v3) drm

Re: [Intel-gfx] [PATCH 0/4] drm/i915/vlv_dsi: Add quirks for x86 android tablets (v2)

Hi Ville, On 9/18/23 10:00, Ville Syrjälä wrote: > On Sat, Sep 16, 2023 at 02:54:51PM +0200, Hans de Goede wrote: >> Hi All, >> >> Some vlv/chv tablets ship with Android as factory OS. The factory OS >> BSP style kernel on these tablets does not use the normal x86

[Intel-gfx] [PATCH 4/4] drm/i915/dsi: Add some debug logging to mipi_exec_i2c (v2)

Add some debug logging to mipi_exec_i2c, to make debugging various issues seen with it easier. Changes in v2: - Drop unnecessary __func__ drm_dbg_kms() argument Reviewed-by: Javier Martinez Canillas Signed-off-by: Hans de Goede --- drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 3 +++ 1 file

[Intel-gfx] [PATCH 3/4] drm/i915/vlv_dsi: Add DMI quirk for backlight control issues on Lenovo Yoga Tab 3

() to pick the wrong bus. 2. There is no backlight off sequence, causing the backlight to stay on. Add a DMI quirk fixing both issues. Signed-off-by: Hans de Goede --- drivers/gpu/drm/i915/display/vlv_dsi.c | 32 ++ 1 file changed, 32 insertions(+) diff --git a/drivers/gpu/drm

[Intel-gfx] [PATCH 1/4] drm/i915/vlv_dsi: Add DMI quirk for wrong panel modeline in BIOS on Asus TF103C (v2)

nez Canillas Signed-off-by: Hans de Goede --- drivers/gpu/drm/i915/display/vlv_dsi.c | 42 ++ 1 file changed, 42 insertions(+) diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c b/drivers/gpu/drm/i915/display/vlv_dsi.c index a96e7d028c5c..51c4b1491fa2 100644 --- a/

[Intel-gfx] [PATCH 2/4] drm/i915/vlv_dsi: Add DMI quirk for wrong I2C bus and panel size on Lenovo Yoga Tablet 2 series (v2)

050 uses a 1920x1200 landscape screen, where as the 8" 830 uses a 1200x1920 portrait screen, so the quirk handling uses the display resolution to detect the model. Changes in v2: - Also override i2c_bus_num to fix mipi_exec_i2c() timeouts Reviewed-by: Javier Martinez Canillas Signed-off-by: Ha

[Intel-gfx] [PATCH 0/4] drm/i915/vlv_dsi: Add quirks for x86 android tablets (v2)

. This should avoid any chances of causing regressions on devices where the quirks do not apply. - New quirk for backlight control issues on Lenovo Yoga Tab 3 - Address Jani Nikula's remark about __func__ being redundant when using drm_dbg_kms() Regards, Hans Hans de Goede (4): drm/i915

[Intel-gfx] [PATCH v2] drm/i915/dsi: Use unconditional msleep() instead of intel_dsi_msleep()

ntel_dsi_msleep(panel_on_delay) call Fixes: 6fdb335f1c9c ("drm/i915/dsi: Use unconditional msleep for the panel_on_delay when there is no reset-deassert MIPI-sequence") Signed-off-by: Hans de Goede --- drivers/gpu/drm/i915/display/icl_dsi.c | 2 +- drivers/gpu/drm/i915/display/inte

Re: [Intel-gfx] [PATCH] drm/i915/dsi: Always use unconditional msleep() for the panel_on_delay

Hi Ville, On 4/24/23 20:34, Ville Syrjälä wrote: > On Sat, Apr 22, 2023 at 08:43:59PM +0200, Hans de Goede wrote: >> The intel_dsi_msleep() helper skips sleeping if the MIPI-sequences have >> a version of 3 or newer and the panel is in vid-mode. >> >> This is based on

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dsi: Always use unconditional msleep() for the panel_on_delay

Hi, On 4/22/23 22:33, Patchwork wrote: > *Patch Details* > *Series:* drm/i915/dsi: Always use unconditional msleep() for the > panel_on_delay > *URL:*https://patchwork.freedesktop.org/series/116858/ > > *State:* failure >

[Intel-gfx] [PATCH] drm/i915/dsi: Always use unconditional msleep() for the panel_on_delay

/i915/dsi: Use unconditional msleep for the panel_on_delay when there is no reset-deassert MIPI-sequence") Signed-off-by: Hans de Goede --- drivers/gpu/drm/i915/display/vlv_dsi.c | 18 +++--- 1 file changed, 3 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/i915/display/v

Re: [Intel-gfx] [PATCH v2] ACPI: Fix selecting the wrong ACPI fwnode for the iGPU on some Dell laptops

Hi, On 1/11/23 21:16, Rafael J. Wysocki wrote: > On Tue, Jan 10, 2023 at 4:30 PM Hans de Goede wrote: >> >> The Dell Latitude E6430 both with and without the optional NVidia dGPU >> has a bug in its ACPI tables which is causing Linux to assign the wrong >&

[Intel-gfx] [PATCH v2] ACPI: Fix selecting the wrong ACPI fwnode for the iGPU on some Dell laptops

gher score for children with this flag set, so that it picks the right companion-device. Co-developed-by: Rafael J. Wysocki Signed-off-by: Hans de Goede --- Changes in v2: - Switch to Rafael's suggested implementation using a type.backlight flag and only make find_child_checks() return a higher

Re: [Intel-gfx] [PATCH] ACPI: Fix selecting the wrong ACPI fwnode for the iGPU on some Dell laptops

Hi Rafael, On 1/10/23 14:33, Rafael J. Wysocki wrote: > On Monday, January 9, 2023 9:57:21 PM CET Hans de Goede wrote: >> The Dell Latitude E6430 both with and without the optional NVidia dGPU >> has a bug in its ACPI tables which is causing Linux to assign the wrong >> AC

Re: [Intel-gfx] [PATCH] ACPI: Fix selecting the wrong ACPI fwnode for the iGPU on some Dell laptops

p.s. This fixes a regression in 6.1, adding the regressions list to the Cc. Once we figure out the best way to fix this (this patch is more of a proposal how to fix this rather then a definitive fix), we should also backport the fix to 6.1.y. On 1/9/23 21:57, Hans de Goede wrote: > The D

[Intel-gfx] [PATCH] ACPI: Fix selecting the wrong ACPI fwnode for the iGPU on some Dell laptops

every time it is called. Fixes: 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()") Signed-off-by: Hans de Goede --- drivers/acpi/glue.c | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c index 204fe94c7e45.

Re: [Intel-gfx] linux-next: manual merge of the drm-intel tree with Linus' tree

Hi, On 11/14/22 11:10, Jani Nikula wrote: > On Mon, 14 Nov 2022, Hans de Goede wrote: >> Hi, >> >> On 11/14/22 00:23, Stephen Rothwell wrote: >>> Hi all, >>> >>> Today's linux-next merge of the drm-intel tree got a conflict in: >>

Re: [Intel-gfx] linux-next: manual merge of the drm-intel tree with Linus' tree

Hi, On 11/14/22 00:23, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the drm-intel tree got a conflict in: > > drivers/gpu/drm/i915/display/intel_backlight.c > > between commit: > > b1d36e73cc1c ("drm/i915: Don't register backlight when another backlight > should be

Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

Hi Matthew, Rafael, On 10/27/22 14:09, Rafael J. Wysocki wrote: > On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede wrote: >> >> Hi, >> >> On 10/27/22 11:52, Matthew Garrett wrote: >>> On Thu, Oct 27, 2022 at 11:39:38AM +0200, Hans de Goede wrote: >>> &

Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

Hi, On 10/27/22 14:09, Rafael J. Wysocki wrote: > On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede wrote: >> >> Hi, >> >> On 10/27/22 11:52, Matthew Garrett wrote: >>> On Thu, Oct 27, 2022 at 11:39:38AM +0200, Hans de Goede wrote: >>> >>

Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

Hi, On 10/27/22 11:52, Matthew Garrett wrote: > On Thu, Oct 27, 2022 at 11:39:38AM +0200, Hans de Goede wrote: > >> The *only* behavior which actually is new in 6.1 is the native GPU >> drivers now doing the equivalent of: >> >> if (acpi_video_get_backlight_t

Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

Hi Matthew, On 10/27/22 11:11, Matthew Garrett wrote: > On Thu, Oct 27, 2022 at 10:51:45AM +0200, Hans de Goede wrote: > >> In their backlight register paths and this has been present since >> circa 2015. >> >> So both before and after my 6.1 refactor vendor is only

Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

Hi, On 10/26/22 22:49, Matthew Garrett wrote: > On Wed, Oct 26, 2022 at 11:59:28AM +0200, Hans de Goede wrote: > >> Ok, so this is a local customization to what is already a custom BIOS >> for a custom motherboard. There is a lot of custom in that sentence and >> TBH at

Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

Hi, On 10/26/22 01:40, Matthew Garrett wrote: > On Wed, Oct 26, 2022 at 01:27:25AM +0200, Hans de Goede wrote: > >> this code should actually set the ACPI_VIDEO_BACKLIGHT flag: >> drivers/acpi/scan.c: >> >> static acpi_status >> acpi_backlight_cap_match

Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

Hi, On 10/25/22 22:40, Matthew Garrett wrote: > On Tue, Oct 25, 2022 at 10:25:33PM +0200, Hans de Goede wrote: > >> Having the native driver come and then go and be replaced >> with the vendor driver would also be quite inconvenient >> for these planned changes. > &

Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

Hi (again), On 10/25/22 22:25, Hans de Goede wrote: > Hi Matthew, > > On 10/25/22 21:32, Matthew Garrett wrote: >> On Tue, Oct 25, 2022 at 08:50:54PM +0200, Hans de Goede wrote: >> >>> That is a valid point, but keep in mind that this is only used on ACPI >>

Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

Hi Matthew, On 10/25/22 21:32, Matthew Garrett wrote: > On Tue, Oct 25, 2022 at 08:50:54PM +0200, Hans de Goede wrote: > >> That is a valid point, but keep in mind that this is only used on ACPI >> platforms and then only on devices with a builtin LCD panel and then >> o

Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

Hi, On 10/24/22 22:30, Matthew Garrett wrote: > On Tue, Sep 27, 2022 at 01:04:52PM +0200, Hans de Goede wrote: > >> So to fix this we need to make acpi_video_get_backlight_type() >> return native on the Acer Chromebook Spin 713. > > Isn't the issue broader than t

Re: [Intel-gfx] [PATCH 00/22] Fallback to native backlight

Hi, On 10/24/22 16:31, Akihiko Odaki wrote: > On 2022/10/24 23:06, Akihiko Odaki wrote: >> On 2022/10/24 22:21, Hans de Goede wrote: >>> Hi, >>> >>> On 10/24/22 14:58, Akihiko Odaki wrote: >>>> On 2022/10/24 20:53, Hans de Goede wrote: >>

Re: [Intel-gfx] [PATCH 00/22] Fallback to native backlight

Hi, On 10/24/22 15:14, Pali Rohár wrote: > On Monday 24 October 2022 21:58:57 Akihiko Odaki wrote: >> Regarding the second limitation, I don't even understand the difference >> between vendor and native. My guess is that a vendor backlight device uses >> vendor-specific ACPI interface, and a

Re: [Intel-gfx] [PATCH 00/22] Fallback to native backlight

Hi, On 10/24/22 14:58, Akihiko Odaki wrote: > On 2022/10/24 20:53, Hans de Goede wrote: >> Hi Akihiko, >> >> On 10/24/22 13:34, Akihiko Odaki wrote: >>> Commit 2600bfa3df99 ("ACPI: video: Add acpi_video_backlight_use_native() >>> helper") and fo

Re: [Intel-gfx] [PATCH 00/22] Fallback to native backlight

Hi, On 10/24/22 13:56, Akihiko Odaki wrote: > On 2022/10/24 20:48, Jani Nikula wrote: >> On Mon, 24 Oct 2022, Akihiko Odaki wrote: >>> Commit 2600bfa3df99 ("ACPI: video: Add acpi_video_backlight_use_native() >>> helper") and following commits made native backlight unavailable if >>>

Re: [Intel-gfx] [PATCH 00/22] Fallback to native backlight

Hi Akihiko, On 10/24/22 13:34, Akihiko Odaki wrote: > Commit 2600bfa3df99 ("ACPI: video: Add acpi_video_backlight_use_native() > helper") and following commits made native backlight unavailable if > CONFIG_ACPI_VIDEO is set and the backlight feature of ACPI video is > unavailable, which broke the

Re: [Intel-gfx] alderlake crashes (random memory corruption?) with 6.0 i915 / ucode related

Hi, On 10/17/22 15:35, Jani Nikula wrote: > On Mon, 17 Oct 2022, Hans de Goede wrote: >> Hi, >> >> On 10/17/22 13:19, Thorsten Leemhuis wrote: >>> CCing the regression mailing list, as it should be in the loop for all >>> regressions, as explained here: >

Re: [Intel-gfx] alderlake crashes (random memory corruption?) with 6.0 i915 / ucode related

, not you personally, but the auto-completion picked the wrong address-book entry (and I did not notice this). > On 17.10.22 12:48, Hans de Goede wrote: >> On 10/17/22 10:39, Jani Nikula wrote: >>> On Mon, 17 Oct 2022, Jani Nikula wrote: >>>> On Thu, 13 Oct 202

Re: [Intel-gfx] alderlake crashes (random memory corruption?) with 6.0 i915 / ucode related

Hi, On 10/17/22 10:39, Jani Nikula wrote: > On Mon, 17 Oct 2022, Jani Nikula wrote: >> On Thu, 13 Oct 2022, Hans de Goede wrote: >>> With 6.0 the following WARN triggers: >>> drivers/gpu/drm/i915/display/intel_bios.c:477: >>> >>> drm_WARN(>

Re: [Intel-gfx] alderlake crashes (random memory corruption?) with 6.0 i915 / ucode related

Hi, On 10/17/22 10:30, Jani Nikula wrote: > On Thu, 13 Oct 2022, Hans de Goede wrote: >> With 6.0 the following WARN triggers: >> drivers/gpu/drm/i915/display/intel_bios.c:477: >> >> drm_WARN(>drm, min_size == 0, >> "Block %d min_

Re: [Intel-gfx] alderlake crashes (random memory corruption?) with 6.0 i915 / ucode related

Hi, On 10/13/22 22:33, Hans de Goede wrote: > Hi All, > > Yesterday I got a new Lenovo ThinkPad X1 yoga gen 7 laptop, since I plan > to make this my new day to day laptop I have copied over the entire > rootfs, /home, etc. from my current laptop to avoid having to tweak > every

[Intel-gfx] alderlake crashes (random memory corruption?) with 6.0 i915 / ucode related

Hi All, Yesterday I got a new Lenovo ThinkPad X1 yoga gen 7 laptop, since I plan to make this my new day to day laptop I have copied over the entire rootfs, /home, etc. from my current laptop to avoid having to tweak everything to my liking again. This meant I had an initramfs generated for the

Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

Hi Dmitry, On 9/26/22 01:39, Dmitry Osipenko wrote: > 25.08.2022 17:36, Hans de Goede пишет: >> Before this commit when we want userspace to use the acpi_video backlight >> device we register both the GPU's native backlight device and acpi_video's >> firmware acpi_vi

Re: [Intel-gfx] [GIT PULL] Immutable backlight-detect-refactor branch between acpi, drm-* and pdx86

Hi, On 9/14/22 12:29, Maxime Ripard wrote: > Hi Hans, > > On Mon, Sep 05, 2022 at 10:35:47AM +0200, Hans de Goede wrote: >> Hi All, >> >> Now that all patches have been reviewed/acked here is an immutable >> backlight-detect-refactor >> branch with

[Intel-gfx] [GIT PULL] Immutable backlight-detect-refactor branch between acpi, drm-* and pdx86

x86 subsystems. ---- Hans de Goede (31): ACPI: video: Add acpi_video_backlight_use_native() helper drm/i915: Don't register backlight when another backlight should be used (v2) drm/amdgpu: Don't register backlight when anot

Re: [Intel-gfx] [PATCH v5 17/31] ACPI: video: Add Nvidia WMI EC brightness control detection (v3)

Hi, On 8/26/22 00:21, Daniel Dadap wrote: > On 8/25/22 9:37 AM, Hans de Goede wrote: >> On some new laptop designs a new Nvidia specific WMI interface is present >> which gives info about panel brightness control and may allow controlling >> the brightness through this interf

[Intel-gfx] [PATCH v5 25/31] platform/x86: asus-wmi: Move acpi_backlight=native quirks to ACPI video_detect.c

() is troublesome because it may end up getting called after other backlight drivers have already called acpi_video_get_backlight_type() resulting in the other drivers already being registered even though they should not. Acked-by: Rafael J. Wysocki Signed-off-by: Hans de Goede --- drivers/acpi

[Intel-gfx] [PATCH v5 30/31] ACPI: video: Fix indentation of video_detect_dmi_table[] entries

t wrapping. But over time some entries did not event have the single space indent in front of the ".name = ..." lines. Make things consistent by using a single space indent for these lines everywhere. Acked-by: Rafael J. Wysocki Signed-off-by: Hans de Goede --- drivers/acpi

[Intel-gfx] [PATCH v5 29/31] ACPI: video: Drop NL5x?U, PF4NU1F and PF5?U?? acpi_backlight=native quirks

bug.cgi?id=215683 Tested-by: Werner Sembach Acked-by: Rafael J. Wysocki Signed-off-by: Hans de Goede --- drivers/acpi/video_detect.c | 92 + 1 file changed, 1 insertion(+), 91 deletions(-) diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_dete

[Intel-gfx] [PATCH v5 26/31] platform/x86: samsung-laptop: Move acpi_backlight=[vendor|native] quirks to ACPI video_detect.c

] quirks from samsung-laptop to drivers/acpi/video_detect.c . Note the X360 -> acpi_backlight=native quirk is not moved because that already was present in drivers/acpi/video_detect.c . Acked-by: Rafael J. Wysocki Signed-off-by: Hans de Goede --- drivers/acpi/video_detect.c |

[Intel-gfx] [PATCH v5 28/31] ACPI: video: Drop "Samsung X360" acpi_backlight=native quirk

Wysocki Signed-off-by: Hans de Goede --- drivers/acpi/video_detect.c | 15 --- 1 file changed, 15 deletions(-) diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index 67a0211c07b4..af2833b57b8b 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video

[Intel-gfx] [PATCH v5 31/31] drm/todo: Add entry about dealing with brightness control on devices with > 1 panel

Add an entry summarizing the discussion about dealing with brightness control on devices with more then 1 internal panel. The original discussion can be found here: https://lore.kernel.org/dri-devel/20220517152331.16217-1-hdego...@redhat.com/ Reviewed-by: Lyude Paul Signed-off-by: Hans de Goede

[Intel-gfx] [PATCH v5 27/31] ACPI: video: Remove acpi_video_set_dmi_backlight_type()

Signed-off-by: Hans de Goede --- drivers/acpi/acpi_video.c | 10 -- drivers/acpi/video_detect.c | 16 include/acpi/video.h| 4 3 files changed, 30 deletions(-) diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c index d1e41f30c004

[Intel-gfx] [PATCH v5 21/31] platform/x86: toshiba_acpi: Stop using acpi_video_set_dmi_backlight_type()

add DMI quirks for those. Acked-by: Rafael J. Wysocki Signed-off-by: Hans de Goede --- drivers/acpi/video_detect.c | 19 +++ drivers/platform/x86/toshiba_acpi.c | 16 2 files changed, 19 insertions(+), 16 deletions(-) diff --git a/drivers/acpi

[Intel-gfx] [PATCH v5 24/31] platform/x86: asus-wmi: Move acpi_backlight=vendor quirks to ACPI video_detect.c

. This is because the entries using the removed wmi_backlight_power flag also use other model specific quirks from the asus-wmi quirk_entry struct. So the quirk_asus_x55u struct and the entries pointing to it cannot be dropped. Acked-by: Rafael J. Wysocki Signed-off-by: Hans de Goede --- drivers/acpi

[Intel-gfx] [PATCH v5 23/31] platform/x86: asus-wmi: Drop DMI chassis-type check from backlight handling

efore the addition of the acpi_video_get_backlight_type() != native check. Removing this should be ok now, since the ACPI video code has improved heuristics for this itself now (which includes a chassis-type check). Signed-off-by: Hans de Goede --- drivers/platform/x86/asus-wmi.c | 7 --- 1 file ch

[Intel-gfx] [PATCH v5 22/31] platform/x86: acer-wmi: Move backlight DMI quirks to acpi/video_detect.c

es. Acked-by: Rafael J. Wysocki Signed-off-by: Hans de Goede --- drivers/acpi/video_detect.c | 53 ++ drivers/platform/x86/acer-wmi.c | 66 - 2 files changed, 53 insertions(+), 66 deletions(-) diff --git a/drivers/acpi/video_detect.c b/dr

[Intel-gfx] [PATCH v5 19/31] platform/x86: nvidia-wmi-ec-backlight: Use acpi_video_get_backlight_type()

-backlight in drivers/acpi/video_detect.c already checks that the WMI advertised brightness-source is the embedded controller, this new check makes it unnecessary for nvidia_wmi_ec_backlight_probe() to check this itself. Suggested-by: Daniel Dadap Reviewed-by: Daniel Dadap Signed-off-by: Hans de Goede

[Intel-gfx] [PATCH v5 17/31] ACPI: video: Add Nvidia WMI EC brightness control detection (v3)

: - Use WMI_BRIGHTNESS_GUID define Acked-by: Rafael J. Wysocki Signed-off-by: Hans de Goede --- drivers/acpi/Kconfig | 1 + drivers/acpi/video_detect.c| 37 ++ drivers/gpu/drm/gma500/Kconfig | 2 ++ drivers/gpu/drm/i915/Kconfig | 2 ++ include/acpi

[Intel-gfx] [PATCH v5 15/31] platform/x86: nvidia-wmi-ec-backlight: Move fw interface definitions to a header (v2)

Move the WMI interface definitions to a header, so that the definitions can be shared with drivers/acpi/video_detect.c . Changes in v2: - Add missing Nvidia copyright header - Move WMI_BRIGHTNESS_GUID to nvidia-wmi-ec-backlight.h as well Suggested-by: Daniel Dadap Signed-off-by: Hans de Goede

[Intel-gfx] [PATCH v5 16/31] ACPI: video: Refactor acpi_video_get_backlight_type() a bit

. Wysocki Signed-off-by: Hans de Goede --- drivers/acpi/video_detect.c | 39 ++--- 1 file changed, 23 insertions(+), 16 deletions(-) diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index fb49b8f4523a..cc9d0d91e268 100644 --- a/drivers/acpi

[Intel-gfx] [PATCH v5 20/31] platform/x86: apple-gmux: Stop calling acpi/video.h functions

Now that acpi_video_get_backlight_type() has apple-gmux detection (using apple_gmux_present()), it is no longer necessary for the apple-gmux code to manually remove possibly conflicting drivers. So remove the handling for this from the apple-gmux driver. Signed-off-by: Hans de Goede

[Intel-gfx] [PATCH v5 12/31] drm/nouveau: Register ACPI video backlight when nv_backlight registration fails (v2)

de Goede --- drivers/gpu/drm/nouveau/nouveau_acpi.c | 5 + drivers/gpu/drm/nouveau/nouveau_acpi.h | 2 ++ drivers/gpu/drm/nouveau/nouveau_backlight.c | 7 +++ 3 files changed, 14 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c b/drivers/gpu/drm/nouveau

[Intel-gfx] [PATCH v5 18/31] ACPI: video: Add Apple GMUX brightness control detection

of: acpi_video_set_dmi_backlight_type(acpi_backlight_vendor); Inside the apple-gmux driver. Acked-by: Rafael J. Wysocki Signed-off-by: Hans de Goede --- drivers/acpi/video_detect.c | 4 include/acpi/video.h| 1 + 2 files changed, 5 insertions(+) diff --git a/drivers/acpi

[Intel-gfx] [PATCH v5 07/31] ACPI: video: Remove acpi_video_bus from list before tearing it down

Move the list_del removing an acpi_video_bus from video_bus_head on teardown to before the teardown is done, to avoid code iterating over the video_bus_head list seeing acpi_video_bus objects on there which are (partly) torn down already. Acked-by: Rafael J. Wysocki Signed-off-by: Hans de Goede

[Intel-gfx] [PATCH v5 14/31] drm/radeon: Register ACPI video backlight when skipping radeon backlight registration

backlight device because of e.g. the firmware_flags or the acpi_video_get_backlight_type() return value. This ensures that if the acpi_video backlight device should be used, it will be available before the radeon drm_device gets registered with userspace. Acked-by: Alex Deucher Signed-off-by: Hans de

[Intel-gfx] [PATCH v5 10/31] ACPI: video: Remove code to unregister acpi_video backlight when a native backlight registers

necessary to monitor for a native (BACKLIGHT_RAW) device showing up later and to then unregister the acpi_video backlight device(s). Acked-by: Rafael J. Wysocki Signed-off-by: Hans de Goede --- drivers/acpi/acpi_video.c | 2 -- drivers/acpi/video_detect.c | 36

[Intel-gfx] [PATCH v5 13/31] drm/amdgpu: Register ACPI video backlight when skipping amdgpu backlight registration

de Goede --- drivers/gpu/drm/amd/amdgpu/atombios_encoders.c| 9 +++-- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++ 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c

[Intel-gfx] [PATCH v5 11/31] drm/i915: Call acpi_video_register_backlight() (v3)

call acpi_video_register_backlight() when a panel is detected Changes in v3: -Add a new intel_acpi_video_register() helper which checks if a panel is present and then calls acpi_video_register_backlight() Signed-off-by: Hans de Goede --- drivers/gpu/drm/i915/display/intel_acpi.c| 27

[Intel-gfx] [PATCH v5 08/31] ACPI: video: Simplify acpi_video_unregister_backlight()

When acpi_video_register() has not run yet the video_bus_head will be empty, so there is no need to check the register_count flag first. Acked-by: Rafael J. Wysocki Signed-off-by: Hans de Goede --- drivers/acpi/acpi_video.c | 12 1 file changed, 4 insertions(+), 8 deletions

[Intel-gfx] [PATCH v5 06/31] ACPI: video: Drop backlight_device_get_by_type() call from acpi_video_get_backlight_type()

. Relying on the cached native_available value not only is simpler, it will also work correctly in cases where then native backlight registration was skipped because of acpi_video_backlight_use_native() returning false. Acked-by: Rafael J. Wysocki Signed-off-by: Hans de Goede --- drivers/acpi

[Intel-gfx] [PATCH v5 05/31] drm/nouveau: Don't register backlight when another backlight should be used (v2)

devices for a single display really is undesirable, don't register the GPU's native backlight device when another backlight device should be used. Changes in v2: - Add nouveau_acpi_video_backlight_use_native() wrapper to avoid unresolved symbol errors on non X86 Signed-off-by: Hans de Goede

[Intel-gfx] [PATCH v5 09/31] ACPI: video: Make backlight class device registration a separate step (v2)

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 Signed-off-by: Hans de Goede --- drivers/acpi/acpi_video.c | 50

[Intel-gfx] [PATCH v5 04/31] drm/radeon: Don't register backlight when another backlight should be used (v3)

er Signed-off-by: Hans de Goede --- drivers/gpu/drm/Kconfig | 7 +++ drivers/gpu/drm/radeon/atombios_encoders.c | 7 +++ drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 7 +++ 3 files changed, 21 insertions(+) diff --git a/drivers/gpu/drm/Kconfig b/d

[Intel-gfx] [PATCH v5 01/31] ACPI: video: Add acpi_video_backlight_use_native() helper

() with adding a new acpi_video_backlight_use_native() helper. Acked-by: Rafael J. Wysocki Signed-off-by: Hans de Goede --- drivers/acpi/video_detect.c | 24 include/acpi/video.h| 5 + 2 files changed, 25 insertions(+), 4 deletions(-) diff --git a/drivers/acpi

[Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

devices for a single display really is undesirable, don't register the GPU's native backlight device when another backlight device should be used. Changes in v2: - Use drm_info(drm_dev, ...) for log messages Reviewed-by: Jani Nikula Signed-off-by: Hans de Goede --- drivers/gpu/drm/i915

[Intel-gfx] [PATCH v5 03/31] drm/amdgpu: Don't register backlight when another backlight should be used (v3)

er Signed-off-by: Hans de Goede --- drivers/gpu/drm/Kconfig | 7 +++ drivers/gpu/drm/amd/amdgpu/atombios_encoders.c| 7 +++ drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +++ 3 files changed, 21 insertions(+) diff --git a/drivers/gpu/drm/Kconfig

[Intel-gfx] [PATCH v5 00/31] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display

send out a pull-request to all involved subsystems based on this branch soon. Regards, Hans Hans de Goede (31): ACPI: video: Add acpi_video_backlight_use_native() helper drm/i915: Don't register backlight when another backlight should be used (v2) drm/amdgpu: Don't register

Re: [Intel-gfx] [PATCH v4 02/31] drm/i915: Don't register backlight when another backlight should be used

Hi All, On 8/24/22 14:50, Jani Nikula wrote: > On Wed, 24 Aug 2022, Hans de Goede wrote: >> Before this commit when we want userspace to use the acpi_video backlight >> device we register both the GPU's native backlight device and acpi_video's >> firmware acpi_vi

Re: [Intel-gfx] [PATCH v4 05/31] drm/nouveau: Don't register backlight when another backlight should be used (v2)

Hi Lyude, Thank you for the review. On 8/24/22 19:41, Lyude Paul wrote: > Just one tiny nitpick below: > > On Wed, 2022-08-24 at 14:14 +0200, Hans de Goede wrote: >> Before this commit when we want userspace to use the acpi_video backlight >> device we register both the G

  1   2   3   4   5   6   7   8   9   10   >