Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Youssef Ahmed <youssefaswad@gmail.com>]

Hello Daniel,

I added the file to gdrive, and here is the link
https://drive.google.com/file/d/14JUpD78jJkXwjgJz5bY3nUzp-LFlZ6dC/view?usp=drivesdk

Let me know if you have any problem accessing the file.

Regards,

Youssef

On February 17, 2023 8:56:13 PM GMT+02:00, Daniel Dadap <ddadap@nvidia.com> wrote:
>On Fri, Feb 17, 2023 at 05:04:52PM +0200, Youssef Aly wrote:
>> Yes, I sent the data to daniel. I am currently just using an older kernel
>> (6.0) before the regression.
>
>Thanks, Youssef. I am also only seeing the test kernel module results as
>the most recent message I have from you. If you sent the ACPI table dumps
>as an attachment, there is a chance they got filtered out - this happened
>with another ACPI dump that somebody tried to send me. Perhaps posting the
>files to a file sharing site might work better - it would be interesting
>to compare your ACPI table dump to another from a different 5515 model.
>
>> On Fri, Feb 17, 2023, 2:36 PM Linux regression tracking (Thorsten Leemhuis)
>> <regressions@leemhuis.info> wrote:
>> 
>> > On 18.01.23 23:11, Daniel Dadap wrote:
>> > > On Thu, Jan 19, 2023 at 12:02:50AM +0200, Youssef Aly wrote:
>> > >> I loaded the updated module and /sys/kernel/debug/acpi/mxds_mu
>> > >> x_state contained "integrated".
>> > >>
>> > >> I ran
>> > >> echo "discrete" > /sys/kernel/debug/acpi/mxds_mux_state
>> > >> now it contained ''discrete' and the screen turned off.
>> > >> then I return it to its initial state.
>> > >>
>> > >> Tried echo '0' > /sys/kernel/debug/dri/1/eDP-1/trigger_hotplug then '1'
>> > >> but it didn't work, had to reboot, I am running gnome on wayland.
>> > >
>> > > Your system does allow you to switch the mux mode in the UEFI setup
>> > > screen, correct? If you could share your ACPI tables as well (see the
>> > > instructions in a fork of this thread) that would be helpful.
>> >
>> > I might be missing something, but it looks like this discussion stalled
>> > here.
>> >
>> > Youssef Aly, did you ever share the data Daniel asked for? Or did you
>> > stop caring? Maybe because it works / you found a workaround?
>> >
>> > Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>> > --
>> > Everything you wanna know about Linux kernel regression tracking:
>> > https://linux-regtracking.leemhuis.info/about/#tldr
>> > If I did something stupid, please tell me, as explained on that page.
>> >
>> > #regzbot poke
>> >
>> > > It sounds like your system has a functional dynamic mux, which would be
>> > > consistent with being able to choose different mux modes in UEFI setup.
>> > > The screen not coming back up isn't a big concern: triggering the
>> > > hotplug is something that's *supposed* to work (and it worked on the
>> > > AMD+NVIDIA system I tried it on), but I am not surprised if it doesn't
>> > > work everywhere.
>> > >
>> > >>
>> > >> On Wed, 18 Jan 2023 at 23:20, Iris <pawel.js@protonmail.com> wrote:
>> > >>>
>> > >>> After loading the updated module,
>> > /sys/kernel/debug/acpi/mxds_mux_state reports "integrated".
>> > >>>
>> > >>> Now, i ran the command
>> > >>> sudo sh -c "echo discrete > /sys/kernel/debug/acpi/mxds_mux_state"
>> > >>>
>> > >>> /sys/kernel/debug/acpi/mxds_mux_state now reads "discrete", but my
>> > screen didn't turn off... I changed it back to integrated, then to discrete
>> > again, it seems like nothing happened, or did i do something wrong?
>> > >>>
>> > >>>
>> > >>> ------- Original Message -------
>> > >>> On Wednesday, January 18th, 2023 at 21:41, Daniel Dadap <
>> > ddadap@nvidia.com> wrote:
>> > >>>
>> > >>>
>> > >>>> Thanks, Iris:
>> > >>>>
>> > >>>
>> > >>>> On Wed, Jan 18, 2023 at 09:33:19AM +0000, Iris wrote:
>> > >>>>
>> > >>>
>> > >>>>> I have followed Youssef's instructions to build the module, and
>> > after loading it, /sys/kernel/debug/acpi/mxdm_mux_mode reports "dynamic"
>> > >>>>
>> > >>>
>> > >>>>
>> > >>>
>> > >>>> That is unfortunate. I was hoping it would report a non-dynamic mode,
>> > which
>> > >>>> would make it easier to disambiguate between G15 5515 models which
>> > require
>> > >>>> EC backlight control and G15 5515 models which require native
>> > GPU-driven
>> > >>>> backlight control.
>> > >>>>
>> > >>>
>> > >>>> I have attached an updated version of the test module which will
>> > allow you
>> > >>>> to test if your system does have a dynamic mux. Build and load it the
>> > same
>> > >>>> way as the previous one (unload the previous one first if you haven't
>> > done
>> > >>>> so or rebooted already). This adds
>> > /sys/kernel/debug/acpi/mxds_mux_state: if
>> > >>>> you see this file, read out its contents. I expect that on your
>> > system it
>> > >>>> should report "integrated", since IIUC the amdgpu_bl backlight device
>> > is the
>> > >>>> one that works on your system. If you do not see this file, and the
>> > message
>> > >>>> "MXDS not found" appears in your kernel log, then your ACPI table
>> > doesn't
>> > >>>> expose the MXDS method, which could be a useful disambiguation test.
>> > >>>>
>> > >>>
>> > >>>> Another experiment to try would be to flip the state of the mux.
>> > Before
>> > >>>> attempting this experiment, make sure to save any work and log in
>> > remotely
>> > >>>> from another machine, since it is possible that your screen will go
>> > blank
>> > >>>> and will need a reboot in order to come back up. To change the mux
>> > state,
>> > >>>> write the target mux state to the mxds_mux_state file. Use whatever
>> > the
>> > >>>> opposite of the current value is, i.e., if it reads out as
>> > "integrated",
>> > >>>> then write "discrete", and vice versa. If the mux switch worked, your
>> > >>>> screen should go blank and reading the mxds_mux_state file again
>> > should
>> > >>>> reflect the new state. You can then flip the mux back to its original
>> > >>>> position, and you should be able to get the display back by forcing
>> > >>>> DPMS off and then on again. If you're not running X, writing a '0'
>> > then
>> > >>>> writing a '1' to /sys/kernel/debug/dri/0/eDP-1/trigger_hotplug seems
>> > to
>> > >>>> work on my AMD+NVIDIA system. (The DRI device and eDP connector ID
>> > might
>> > >>>> be enumerated differently on your system.) If neither of those work to
>> > >>>> bring your display back up, then reboot the computer.
>> > >>>>
>> > >>>
>> > >>>> The most interesting data would be to check whether MXDS is available
>> > in
>> > >>>> your system's ACPI tables, and if so, whether it is actually
>> > functional.
>> > >>>>
>> > >>>
>> > >>>>> As mentioned before, this RTX 3050 system does not have configurable
>> > GPU mode.
>> > >>>>>
>> > >>>
>> > >>>>> ------- Original Message -------
>> > >>>>> On Wednesday, January 18th, 2023 at 01:20, Daniel Dadap
>> > ddadap@nvidia.com wrote:
>> > >>>>>
>> > >>>
>> > >>>>>> On Wed, Jan 18, 2023 at 01:13:54AM +0200, Youssef Aly wrote:
>> > >>>>>
>> > >>>
>> > >>>>>>> Hello Daniel,
>> > >>>>>
>> > >>>
>> > >>>>>>> I tried building the module using the instructions you provided,
>> > but
>> > >>>>>>> ran into some problems as I didn't have the /lib/modules/$(uname
>> > >>>>>>> -r)/source directory on my end.
>> > >>>>>>> I created a Makefile in a directory containing mxdm-debugfs.c file
>> > and
>> > >>>>>>> added the following to it:
>> > >>>>>
>> > >>>
>> > >>>>>>> obj-m += mxdm-debugfs.o
>> > >>>>>
>> > >>>
>> > >>>>>>> all:
>> > >>>>>>> make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
>> > >>>>>
>> > >>>
>> > >>>>>>> clean:
>> > >>>>>>> make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
>> > >>>>>
>> > >>>
>> > >>>>>>> I then ran "make" and loaded the module.
>> > >>>>>
>> > >>>
>> > >>>>>> Ah, yes, I should have mentioned specifically that the instructions
>> > >>>>>> assumed either a split Kbuild configuration with separate source and
>> > >>>>>> output directories, or a single combined source and output
>> > directory but
>> > >>>>>> with "source" and "build" both being symlinks to the same
>> > directory. I
>> > >>>>>> forget which distros do what exactly, but some ship a combined
>> > >>>>>> source/output directory but only have one of either "source" or
>> > "build";
>> > >>>>>> yours appears to be the latter configuration. I'm glad you were
>> > able to
>> > >>>>>> get it building anyway.
>> > >>>>>
>> > >>>
>> > >>>>>>> 1) Hybrid mode set to "Enabled" from the bios settings,
>> > >>>>>>> /sys/kernel/debug/acpi/mxdm_mux_mode contained dynamic.
>> > >>>>>>> 2) Hybrid mode set to "Disabled" from the bios settings,
>> > >>>>>>> /sys/kernel/debug/acpi/mxdm_mux_mode contained discrete.
>> > >>>>>
>> > >>>
>> > >>>>>> Okay. This is consistent with my expectations. If we also find that
>> > the
>> > >>>>>> systems which require the quirk report either "discrete", "hybrid",
>> > or
>> > >>>>>> "integrated" (IIUC those systems do not have the mode configurable
>> > in the
>> > >>>>>> UEFI settings), then I think we can fix the quirk by checking the
>> > mux
>> > >>>>>> mode and only forcing to native if the system is not in hybrid mode.
>> > >>>>>
>> > >>>
>> > >>>>>> Or perhaps we should just get rid of the quirk, and unconditionally
>> > test
>> > >>>>>> the mux mode, and avoid using nvidia-wmi-ec-backlight on systems
>> > which
>> > >>>>>> are not in "dynamic" mode, regardless of whether they expose the
>> > WMI EC
>> > >>>>>> backlight interface and regardless of whether that interface reports
>> > >>>>>> that the EC backlight driver should be used. (On the systems that
>> > need
>> > >>>>>> the quirk, that interface is reporting that the backlight should be
>> > >>>>>> EC-controlled even when it shouldn't be.) I think that in theory, it
>> > >>>>>> should be possible for a system design to require EC backlight
>> > control
>> > >>>>>> even when the mux is in a non-dynamic mode, but in practice I don't
>> > know
>> > >>>>>> why anybody would do that, and am not aware of any systems which do
>> > so
>> > >>>>>> (although until the report of the broken backlight on the 3050
>> > version
>> > >>>>>> of the Dell G15 5515, I wasn't aware of any systems that reported EC
>> > >>>>>> backlight control when it was supposed to be native.)
>> > >>>>>
>> > >>>
>> > >>>>>> Hans, I think the most reasonable options are:
>> > >>>>>
>> > >>>
>> > >>>>>> 1) Remove the quirk, and check for MXDM when deciding whether a
>> > system
>> > >>>>>> should use the EC backlight driver. This has the disadvantage of
>> > adding
>> > >>>>>> a check where one isn't actually needed on some (most?) systems,
>> > and the
>> > >>>>>> advantage of most likely avoiding the need to add quirks for other
>> > >>>>>> systems where the system reports EC backlight control when native
>> > should
>> > >>>>>> be used. It also has the possibility of being wrong on a
>> > theoretically
>> > >>>>>> possible configuration, although if we ever encounter such a
>> > >>>>>> configuration we could handle it with a quirk or find some other
>> > way to
>> > >>>>>> distinguish between systems that do or do not require the EC
>> > backlight
>> > >>>>>> driver.
>> > >>>>>
>> > >>>
>> > >>>>>> 2) Keep the existing quirk, and only force to native if MXDM is
>> > missing
>> > >>>>>> or if MXDM reports that the system is in a non-dynamic mode.
>> > >>>>>
>> > >>>
>> > >>>>>> I'm inclined to go with (2), because it seems "safer", but am happy
>> > to
>> > >>>>>> implement (1) if you think that's the better option. For the MXDM
>> > check
>> > >>>>>> I think the first thing to do is to check whether the MXDM method is
>> > >>>>>> present at all: as observed on at least one system, there is no MXDM
>> > >>>>>> method when the system is in non-dynamic mode. Then if MXDM is
>> > present,
>> > >>>>>> check whether it reports that the mux is in dynamic mode. For (1),
>> > only
>> > >>>>>> query the WMI-wrapped API to determine the backlight control source
>> > if
>> > >>>>>> the mux is in dynamic mode. For (2), only force the backlight to
>> > native
>> > >>>>>> if the mux is not in dynamic mode.
>> > >>>>>
>> > >>>
>> > >>>>>> This, again, assumes that none of the systems which require the
>> > quirk
>> > >>>>>> report that the mux is in dynamic mode. If any of them do, we will
>> > need
>> > >>>>>> to find a different way to determine which systems are lying about
>> > how
>> > >>>>>> the backlight is supposed to be controlled.
>> > >>>>>
>> > >>>
>> > >>>>>>> Regards,
>> > >>>>>
>> > >>>
>> > >>>>>>> Youssef
>> > >>>>>
>> > >>>
>> > >>>>>>> On Tue, 17 Jan 2023 at 23:24, Daniel Dadap ddadap@nvidia.com
>> > wrote:
>> > >>>>>
>> > >>>
>> > >>>>>>>> Hans pointed out a crucial omission in the build instructions in a
>> > >>>>>>>> different thread where I also shared this test module:
>> > >>>>>
>> > >>>
>> > >>>>>>>> On Tue, Jan 17, 2023 at 02:56:46PM -0600, Daniel Dadap wrote:
>> > >>>>>
>> > >>>
>> > >>>>>>>>> Thanks, Hans.
>> > >>>>>
>> > >>>
>> > >>>>>>>>> On Mon, Jan 16, 2023 at 05:46:46PM +0100, Hans de Goede wrote:
>> > >>>>>
>> > >>>
>> > >>>>>>>>>> Hi All,
>> > >>>>>
>> > >>>
>> > >>>>>>>>>> On 1/11/23 10:51, Hans de Goede wrote:
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>> Hi,
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>> On 1/11/23 01:40, Daniel Dadap wrote:
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>>> On Tue, Jan 10, 2023 at 04:27:56PM +0100, Hans de Goede wrote:
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>>>> Hi,
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>>>> On 1/10/23 16:19, Youssef Aly wrote:
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>>>>> Hi Hans,
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>>>>> Yes, I added "acpi_backlight=nvidia_wmi_ec" to
>> > >>>>>>>>>>>>>> the kernel commandline for the patched kernel, it doesn't
>> > work without it.
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>>>>> I have 2 modes in the bios Hybrid on/off (hybrid /
>> > discrete). I tried
>> > >>>>>>>>>>>>>> the modes with "acpi_backlight=nvidia_wmi_ec" and
>> > >>>>>>>>>>>>>> "acpi_backlight=native" using the patched kernel (v6.1.4):
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>>>>> Hybrid:
>> > >>>>>>>>>>>>>> "acpi_backlight=native": Does not work,
>> > /sys/class/backlight contains
>> > >>>>>>>>>>>>>> amdgpu_bl1.
>> > >>>>>>>>>>>>>> "acpi_backlight=nvidia_wmi_ec": Works as expected,
>> > >>>>>>>>>>>>>> /sys/class/backlight contains nvidia_wmi_ec_backlight.
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>>>>> Discrete:
>> > >>>>>>>>>>>>>> "acpi_backlight=native": Works but when brightness from
>> > 0-10 is the
>> > >>>>>>>>>>>>>> same as 0-100, for example 10 is full brightness like 100,
>> > 8 is the
>> > >>>>>>>>>>>>>> same as 80, etc... ,
>> > >>>>>>>>>>>>>> /sys/class/backlight contains nvidia_0.
>> > >>>>>>>>>>>>>> "acpi_backlight=nvidia_wmi_ec": Does not work,
>> > /sys/class/backlight
>> > >>>>>>>>>>>>>> contains nvidia_wmi_ec_backlight.
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>>>> Thank you for testing!
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>>>> Ok so it seems there are 2 issues at play here:
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>>>> 1. Depending on the BIOS setting we need to use either
>> > native (discrete mode)
>> > >>>>>>>>>>>>> or nvidia_wmi_ec (hybrid mode)
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>>>> 2. There is a bug in the nvidia binary drivers backlight
>> > control in native
>> > >>>>>>>>>>>>> mode on this system causing the range to be wrong
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>>>> Daniel, we really need help from NVidia with fixing 1. can
>> > you see if
>> > >>>>>>>>>>>>> there is a way to check the BIOS setting/mode from inside
>> > the kernel ?
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>>> Yes, the ACPI MXDM method should be able to do this. However,
>> > querying
>> > >>>>>>>>>>>> WMI_BRIGHTNESS_METHOD_SOURCE is supposed to be the canonical
>> > way to
>> > >>>>>>>>>>>> determine whether the backlight is supposed to be EC-driven,
>> > since there
>> > >>>>>>>>>>>> are EC-driven and non-EC-driven designs, so the BIOS mode is
>> > supposed to
>> > >>>>>>>>>>>> be orthogonal to whether or not the EC driver should be used.
>> > It sounds
>> > >>>>>>>>>>>> like the BIOS is possibly reporting a wrong value for that
>> > query.
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>>> I guess we could wire up a quirk that checks MXDM and
>> > overrides the
>> > >>>>>>>>>>>> WMI_BRIGHTNESS_METHOD_SOURCE query with a value derived from
>> > the current
>> > >>>>>>>>>>>> mux operation mode. Then that quirk could be applied to this
>> > system.
>> > >>>>>>>>>>>> I can put together a patch for that.
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>> If you can write a patch for this that would be great, thank
>> > you,
>> > >>>>>>>>>>> but I think we first need to root-cause this better:
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>> Currently the Dell G15 5515 is DMI quirked inside:
>> > drivers/apci/video_detect.c
>> > >>>>>>>>>>> to always use the native backlight. So I've gone back to the
>> > original email
>> > >>>>>>>>>>> thread which lead to me adding that quirk.
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>> We (I forwarded a mail from you to the reporter this was not
>> > on the list)
>> > >>>>>>>>>>> did ask to test with different BIOS settings their to and the
>> > reporter's
>> > >>>>>>>>>>> reply was:
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>> "Daniel wanted me to check different GPU modes, but my BIOS
>> > has no options
>> > >>>>>>>>>>> for GPU. It's always in hybrid mode with PRIME render offload."
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>> And perhaps even more interesting in their case with
>> > acpi_backlight=native
>> > >>>>>>>>>>> to disable nvidia-wmi-ec they have a working amdgpu_bl#
>> > device. Where as
>> > >>>>>>>>>>> in Youssef's case when running in discrete mode there is an
>> > nvidia backlight
>> > >>>>>>>>>>> device and in Youssef's case the amdgpu_bl# device never works.
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>> The Dell G15 5515 always uses an AMD Ryzen 5 5600H or 5800H
>> > CPU (with iGPU)
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>> While the dGPU can be one of:
>> > >>>>>>>>>>> NVIDIA GeForce RTX 3060
>> > >>>>>>>>>>> NVIDIA GeForce GTX 3050 Ti
>> > >>>>>>>>>>> NVIDIA GeForce GTX 3050
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>> I'm guessing that the dynamic-mux mode / nvidia-wmi-ec code
>> > may only
>> > >>>>>>>>>>> be relevant to the model with the 3060 and that nvidia-wmi-ec
>> > should
>> > >>>>>>>>>>> maybe not load at all on the model with the 3050 versions.
>> > >>>>>
>> > >>>
>> > >>>>>>>>>> A quick status update on this.
>> > >>>>>
>> > >>>
>> > >>>>>>>>>> Iris (added to the Cc), the reporter with the Dell G15 5515
>> > which lead me
>> > >>>>>>>>>> to add the acpi_backlight=native DMI quirk for the Dell G15
>> > 5515 has
>> > >>>>>>>>>> gotten back to me with lspci output on their G15 and it indeed
>> > has
>> > >>>>>>>>>> a GTX 3050.
>> > >>>>>
>> > >>>
>> > >>>>>>>>>> So atm we have the following models which are affected one way
>> > >>>>>>>>>> or the other:
>> > >>>>>
>> > >>>
>> > >>>>>>>>>> -Acer Predator PH315-55: needs acpi_backlight=native
>> > >>>>>>>>>> -Dell G15 5515 with RTX 3050: needs acpi_backlight=native
>> > >>>>>>>>>> -Dell G15 5515 with RTX 3060: breaks with acpi_backlight=native
>> > :(
>> > >>>>>
>> > >>>
>> > >>>>>>>>>> With the models which need acpi_backlight=native being broken
>> > >>>>>>>>>> by (false positive) detection of the laptop needing
>> > nvidia-wmi-ec
>> > >>>>>>>>>> for backlight control while they actually should not be using
>> > that.
>> > >>>>>
>> > >>>
>> > >>>>>>>>>> and with the Dell G15 5515 with RTX 3060 atm being broken
>> > because
>> > >>>>>>>>>> of the DMI quirk added to fix the Dell G15 5515 with RTX 3050.
>> > >>>>>
>> > >>>
>> > >>>>>>>>> I've attached a simple kernel module which adds a debugfs file
>> > that
>> > >>>>>>>>> reports the current mux mode. As mentioned elsewhere, I suspect
>> > that the
>> > >>>>>>>>> systems which need the quirk may be in one of the non-dynamic
>> > modes, and
>> > >>>>>>>>> the systems which are broken by the quirk may be in dynamic mux
>> > mode. It
>> > >>>>>>>>> should be pretty straightforward to compile this as an
>> > out-of-tree
>> > >>>>>>>>> module using the Kbuild extmod infrastructure, as follows:
>> > >>>>>
>> > >>>
>> > >>>>>>>>> 1) Change to the directory containing the mxdm-debugfs.c file
>> > (you may
>> > >>>>>>>>> wish to create an empty directory to put it in) and create a
>> > file in
>> > >>>>>>>>> that directory containing the following line:
>> > >>>>>
>> > >>>
>> > >>>>>>>> The name of this file should be 'Kbuild'. Sorry for the noise.
>> > >>>>>
>> > >>>
>> > >>>>>>>>> obj-m += mxdm-debugfs.o
>> > >>>>>
>> > >>>
>> > >>>>>>>>> 2) Build the kernel module:
>> > >>>>>
>> > >>>
>> > >>>>>>>>> make -C /lib/modules/$(uname -r)/source O=/lib/modules/$(uname
>> > -r)/build M=$(pwd)
>> > >>>>>
>> > >>>
>> > >>>>>>>>> (The "source" and "build" paths under /lib/modules/`uname -r`
>> > should
>> > >>>>>>>>> be the correct paths in almost all cases; if your system uses
>> > >>>>>>>>> different paths, substitute those. You will need the development
>> > >>>>>>>>> headers for external kernel modules, and the relevant toolchain
>> > bits,
>> > >>>>>>>>> but if you're already using the NVIDIA proprietary driver you
>> > almost
>> > >>>>>>>>> certainly already have all of that.)
>> > >>>>>
>> > >>>
>> > >>>>>>>>> 3) Load the kernel module:
>> > >>>>>
>> > >>>
>> > >>>>>>>>> insmod ./mxdm-debugfs.ko
>> > >>>>>
>> > >>>
>> > >>>>>>>>> This should create a file at
>> > /sys/kernel/debug/acpi/mxdm_mux_mode.
>> > >>>>>>>>> Reading this file should report the current mux operation mode.
>> > >>>>>
>> > >>>
>> > >>>>>>>>> While switching mux modes on a dynamic mux system to test this
>> > kernel
>> > >>>>>>>>> module, I noticed that the ACPI tables no longer exposed the
>> > MXDM method
>> > >>>>>>>>> when the mux mode was set to discrete only on that particular
>> > system.
>> > >>>>>>>>> This contradicted the behavior I had previously observed on other
>> > >>>>>>>>> systems; i.e., that MXDM is always available regardless of the
>> > currently
>> > >>>>>>>>> set mux mode, so I tried it on another dynamic mux system and
>> > observed
>> > >>>>>>>>> that the other system does always expose MXDM regardless of the
>> > mux
>> > >>>>>>>>> mode, and the contents of the debugfs file matched the selected
>> > mode.
>> > >>>>>
>> > >>>
>> > >>>>>>>>> So if the module fails to load with ENODEV and prints the "MXDM
>> > not
>> > >>>>>>>>> found" message to the kernel log, the system is most likely
>> > configured
>> > >>>>>>>>> to a non-dynamic mux mode. My usual expectation is that it
>> > should load
>> > >>>>>>>>> and create the file on most dynamic mux systems. I do not have
>> > direct
>> > >>>>>>>>> access to any of the above listed systems at the moment, so I do
>> > not
>> > >>>>>>>>> know whether MXDM will be exposed when the system is not in
>> > dynamic mux
>> > >>>>>>>>> mode.
>> > >>>>>
>> > >>>
>> > >>>>>>>>>> Regards,
>> > >>>>>
>> > >>>
>> > >>>>>>>>>> Hans
>> > >>>>>
>> > >>>
>> > >>>>>>>>> // SPDX-License-Identifier: GPL-2.0-only
>> > >>>>>>>>> /*
>> > >>>>>>>>> * Copyright (C) 2020 NVIDIA Corporation
>> > >>>>>>>>> *
>> > >>>>>>>>> */
>> > >>>>>
>> > >>>
>> > >>>>>>>>> #include <linux/acpi.h>
>> > >>>>>>>>> #include <acpi/acoutput.h>
>> > >>>>>>>>> #include <linux/module.h>
>> > >>>>>>>>> #include <linux/pci.h>
>> > >>>>>>>>> #include <linux/debugfs.h>
>> > >>>>>
>> > >>>
>> > >>>>>>>>> extern struct dentry *acpi_debugfs_dir;
>> > >>>>>
>> > >>>
>> > >>>>>>>>> enum mux_mode {
>> > >>>>>>>>> MUX_MODE_UNKNOWN = 0,
>> > >>>>>>>>> MUX_MODE_INTEGRATED = 1, /* iGPU only /
>> > >>>>>>>>> MUX_MODE_DISCRETE = 2, / dGPU only /
>> > >>>>>>>>> MUX_MODE_HYBRID = 3, / Dual GPU, mux switched to iGPU /
>> > >>>>>>>>> MUX_MODE_DYNAMIC = 4, / Dual GPU, dynamic mux switching */
>> > >>>>>>>>> MUX_MODE_MAX
>> > >>>>>>>>> };
>> > >>>>>
>> > >>>
>> > >>>>>>>>> static char * mode_names[] = {
>> > >>>>>>>>> [MUX_MODE_UNKNOWN] = "unknown\n",
>> > >>>>>>>>> [MUX_MODE_INTEGRATED] = "integrated\n",
>> > >>>>>>>>> [MUX_MODE_DISCRETE] = "discrete\n",
>> > >>>>>>>>> [MUX_MODE_HYBRID] = "hybrid\n",
>> > >>>>>>>>> [MUX_MODE_DYNAMIC] = "dynamic\n",
>> > >>>>>>>>> };
>> > >>>>>
>> > >>>
>> > >>>>>>>>> static struct debugfs_blob_wrapper muxmode_blob;
>> > >>>>>
>> > >>>
>> > >>>>>>>>> static void store_mux_mode(acpi_handle handle)
>> > >>>>>>>>> {
>> > >>>>>>>>> union acpi_object arg = { .integer = { .type =
>> > ACPI_TYPE_INTEGER, .value = 0 } };
>> > >>>>>>>>> struct acpi_object_list in = { .count = 1, .pointer = &arg };
>> > >>>>>
>> > >>>
>> > >>>>>>>>> acpi_integer ret;
>> > >>>>>>>>> acpi_status status;
>> > >>>>>
>> > >>>
>> > >>>>>>>>> status = acpi_evaluate_integer(handle, "MXDM", &in, &ret);
>> > >>>>>
>> > >>>
>> > >>>>>>>>> if (ACPI_FAILURE(status)) {
>> > >>>>>>>>> acpi_handle_err(handle, "ACPI MXDM failed: %s\n",
>> > acpi_format_exception(status));
>> > >>>>>>>>> muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
>> > >>>>>>>>> } else if (ret < MUX_MODE_UNKNOWN || ret >= MUX_MODE_MAX) {
>> > >>>>>>>>> acpi_handle_err(handle, "Mux mode value out of range");
>> > >>>>>>>>> muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
>> > >>>>>>>>> } else {
>> > >>>>>>>>> muxmode_blob.data = mode_names[ret];
>> > >>>>>>>>> }
>> > >>>>>
>> > >>>
>> > >>>>>>>>> muxmode_blob.size = strlen(muxmode_blob.data);
>> > >>>>>>>>> }
>> > >>>>>
>> > >>>
>> > >>>>>>>>> static acpi_status find_mxdm(acpi_handle obj, u32 level, void
>> > *ctx, void **ret)
>> > >>>>>>>>> {
>> > >>>>>>>>> acpi_handle search;
>> > >>>>>
>> > >>>
>> > >>>>>>>>> if (acpi_get_handle(obj, "MXDM", &search) == 0) {
>> > >>>>>>>>> /* Found the parent object of the MXDM method; pass it back
>> > >>>>>>>>> * to the caller and stop searching. */
>> > >>>>>>>>> *ret = obj;
>> > >>>>>
>> > >>>
>> > >>>>>>>>> return AE_CTRL_TERMINATE;
>> > >>>>>>>>> }
>> > >>>>>
>> > >>>
>> > >>>>>>>>> /* No MXDM; keep looking */
>> > >>>>>>>>> return AE_OK;
>> > >>>>>>>>> }
>> > >>>>>
>> > >>>
>> > >>>>>>>>> static struct dentry *muxmode_file_dentry;
>> > >>>>>
>> > >>>
>> > >>>>>>>>> static int __init mxdm_debugfs_init(void)
>> > >>>>>>>>> {
>> > >>>>>>>>> acpi_handle mxdm_handle = NULL;
>> > >>>>>>>>> acpi_status ret;
>> > >>>>>
>> > >>>
>> > >>>>>>>>> ret = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, 5,
>> > >>>>>>>>> find_mxdm, NULL, NULL, &mxdm_handle);
>> > >>>>>
>> > >>>
>> > >>>>>>>>> if (ACPI_FAILURE(ret) || !mxdm_handle) {
>> > >>>>>>>>> pr_err("MXDM not found.\n");
>> > >>>>>>>>> return -ENODEV;
>> > >>>>>>>>> }
>> > >>>>>
>> > >>>
>> > >>>>>>>>> /* Populate the blob wrapper: the mux mode cannot change without
>> > rebooting
>> > >>>>>>>>> * so this only needs to be done once. */
>> > >>>>>>>>> store_mux_mode(mxdm_handle);
>> > >>>>>
>> > >>>
>> > >>>>>>>>> muxmode_file_dentry = debugfs_create_blob("mxdm_mux_mode", 0444,
>> > >>>>>>>>> acpi_debugfs_dir,
>> > >>>>>>>>> &muxmode_blob);
>> > >>>>>
>> > >>>
>> > >>>>>>>>> return muxmode_file_dentry ? 0 : -EIO;
>> > >>>>>>>>> }
>> > >>>>>>>>> module_init(mxdm_debugfs_init);
>> > >>>>>
>> > >>>
>> > >>>>>>>>> static void __exit mxdm_debugfs_exit(void)
>> > >>>>>>>>> {
>> > >>>>>>>>> if (muxmode_file_dentry) {
>> > >>>>>>>>> debugfs_remove(muxmode_file_dentry);
>> > >>>>>>>>> muxmode_file_dentry = NULL;
>> > >>>>>>>>> }
>> > >>>>>>>>> }
>> > >>>>>>>>> module_exit(mxdm_debugfs_exit);
>> > >>>>>
>> > >>>
>> > >>>>>>>>> MODULE_LICENSE("GPL v2");
>> > >>>>>>>>> MODULE_DESCRIPTION("MXDM mux mode test module");
>> > >>>>>>>>> MODULE_AUTHOR("Daniel Dadap ddadap@nvidia.com");
>> > >>>>>
>> > >>>
>> > >>>>>>>>> /*
>> > >>>>>>>>> * The mux doesn't have its own ACPI HID/CID, or WMI wrapper, so
>> > key off of
>> > >>>>>>>>> * the WMI wrapper for the related WMAA method for backlight
>> > control.
>> > >>>>>>>>> */
>> > >>>>>>>>> MODULE_ALIAS("wmi:603E9613-EF25-4338-A3D0-C46177516DB7");
>> > >>>>
>> > >>>
>> > >>>>
>> > >>>
>> > >>>>
>> > >
>> > >
>> >