00:07damo22: the kernel calls the _DSM ?
00:07karolherbst: no, but _PR#
00:08karolherbst: *_PR3
00:08damo22: but then you are not using _DSM
00:08karolherbst: why would we have to?
00:09damo22: to toggle the nvidia optimus enable flag for dynamic power reduction?
00:09karolherbst: that's already done by _PR3
00:09karolherbst: _DSM is really just the way of doing it before it got standardized
00:10karolherbst: firmwares are mapping _DSM in top of _PR3 or rather _ON/_OFF functions they use internally to implement all this
00:10damo22: in my vendor bios, the _DSM does it, not _PR3
00:10karolherbst: well.. you are using coreboot, no?
00:10damo22: i disassembled the vendor bios
00:10damo22: to see how it works
00:11damo22: i admit its very old hw
00:11karolherbst: it would surprise me if you'd get more power savings using the _DSM call
00:13damo22: but isnt the point that the power is adjusted dynamically when it needs to rather than explicitly turning it on and off
00:13karolherbst: how would the firmware even know?
00:14karolherbst: there is no "dynamic" switching in firmware
00:14karolherbst: that's a kernel feature
00:14damo22: there is hardware that detects when battery is only used
00:14karolherbst: and that's related to optimis how?
00:14karolherbst: *optimus
00:15damo22: when ENA_OPT signal is enabled on my board, it routes through some detection logic and then sends a VIDEO_THERM_ALERT
00:16karolherbst: that may all be, but how is that related to any of the actual optimus stuff?
00:16damo22: im trying to figure that out
00:16karolherbst: I am sure this can be used to signal to the OS that it has to throttle the GPU or something
00:17damo22: yeah probably
00:17karolherbst: but then I don't see how the _DSM or _PR3 thing is related to that?
00:17karolherbst: or will the signal only happen when _DSM was used?
00:18damo22: i think the DGPC = One // OPTIMUS_DYNAMIC_PWR_CAP needs to be set in _DSM
00:18damo22: i thin kso
00:19damo22: i have no way to toggle the GPIO105 on the EC
00:19karolherbst: mhh... there are a few _DSM methods we don't call, which don't have much to do with actual turning things on/off
00:19karolherbst: so it might be some custom call we have to do on top
00:19damo22: 0x1a
00:19damo22: that one is used and has the dynamic power cap bit
00:22karolherbst: so 0x1a with "3 << 24 | 1" is used to power it down and "2 << 24 | 1" to power it up
00:22damo22: yeah
00:23karolherbst: but it would be weird to call _PR3 and _DSM because they both power the device down
00:23damo22: so should i remove PR3
00:23damo22: on the root PEG
00:23karolherbst: no
00:23karolherbst: _PR3 is the offical way of doing it
00:23damo22: ok maybe i can move the logic for _DSM into _PR3
00:24karolherbst: probably
00:24karolherbst: but I would be surprised if the _PR3 isn't doing the same, it might just be hidden somewhere
00:24damo22: not on my vendor bios
00:24karolherbst: strange
00:24karolherbst: the vendor firmwares I looked at they always mapped to a common function
00:25damo22: ok
00:25damo22: i can try to fix this thanks
00:25karolherbst: another theory is, that the GPIO isn't needed anymore
00:25karolherbst: because that _PR3 thing come with a new windows version
00:25damo22: what would be a good version of linux kernel to use to test?
00:25karolherbst: and maybe that signal of lower power budget came from somewhere else then
00:26karolherbst: doesn't matter on linux. What matters is how stuff works on windows
00:26karolherbst: there are probably ways of detecting things and we should wire that up in nouveau though
00:27damo22: i can share my old DSDT asl if it helps
00:27karolherbst: I doubt it would
00:27karolherbst: the information we need is all in the vbios
00:27damo22: ah
00:28damo22: thank you for your help
00:29karolherbst: did you try to map the GPIO to the GPIO type in the vbios?
00:29karolherbst: there are a few types which are relevant to this
00:29damo22: i dont know what you mean
00:29karolherbst: "76 = Power Alert, when this GPIO asserts, the on-board power supply controller needs attention." could be related for instance
00:30damo22: i dont think i can find time to disasm vbios
00:30karolherbst: we have tools for that
00:30karolherbst: just dump /sys/kernel/debug/dri/1/vbios.rom somewhere and push that through "nvbios"
00:30karolherbst: https://github.com/envytools/envytools
00:30damo22: ok
00:31karolherbst: there you'll find a table with GPIOs
00:31karolherbst: I'd just be interested in what kind of GPIOs there are
00:35damo22: 0x4, 0x5, 0x6, 0x1a, 0x73, 0x74
00:36karolherbst: mhh, only those? because they are all used for setting the core voltage
00:38damo22: oh, can i paste 10 lines or so?
00:39karolherbst: sure
00:39damo22: GPIO table at 0x578e version 4.1
00:39damo22: GPIO 0: line 0 tag 0x73 [VID_4] OUT DEF 1 gpio: normal
00:39damo22: GPIO 1: line 1 tag 0x1a [VID_3] OUT DEF 0 gpio: normal
00:39damo22: GPIO 2: line 2 tag 0x21 [PANEL_BACKLIGHT_LEVEL] OUT DEF 0 HW gpio: normal SPEC_OUT 0x80 [SOR0_PANEL_BACKLIGHT_LEVEL]
00:39damo22: GPIO 3: line 3 tag 0x01 [PANEL_POWER] OUT DEF 0 gpio: normal SPEC_OUT 0x81 [SOR0_PANEL_POWER]
00:39damo22: GPIO 4: line 4 tag 0x00 [PANEL_BACKLIGHT_ON] OUT DEF 0 gpio: normal SPEC_OUT 0x82 [SOR0_PANEL_BACKLIGHT_ON]
00:39damo22: GPIO 5: line 5 tag 0x05 [VID_1] OUT DEF 1 gpio: normal
00:39damo22: GPIO 6: line 6 tag 0x06 [VID_2] OUT DEF 0 gpio: normal
00:39damo22: GPIO 8: line 8 tag 0x23 [THERM_SHUTDOWN] IN NEG DEF 0 gpio: normal SPEC_OUT 0x58 [NVIO_THERM_SHUTDOWN]
00:39damo22: GPIO 9: line 9 tag 0x34 [THERM_ALERT] IN NEG DEF 0 gpio: normal
00:39damo22: GPIO 11: line 11 tag 0x04 [VID_0] OUT DEF 0 gpio: normal
00:39damo22: GPIO 12: line 12 tag 0x2b [HW_SLOWDOWN_ENABLE] IN NEG DEF 0 gpio: normal
00:39damo22: GPIO 13: line 13 tag 0x74 [VID_5] OUT DEF 1 gpio: normal
00:39damo22: GPIO 15: line 15 tag 0x51 [HPD_2] IN DEF 0 gpio: normal SPEC_IN 0x00 [AUXCH_HPD_0]
00:39damo22: GPIO 17: line 17 tag 0x52 [HPD_3] IN DEF 0 gpio: normal SPEC_IN 0x01 [AUXCH_HPD_1]
00:39damo22: GPIO 18: line 18 tag 0x5e [HPD_4] IN DEF 0 gpio: normal SPEC_IN 0x02 [AUXCH_HPD_2]
00:40karolherbst: okay.. THERM_SHUTDOWN is triggered when the GPU gets too hot
00:41karolherbst: THERM_ALERT is "Thermal Alert: Interrupt input from external thermal device. Indicates that the device needs to be serviced."
00:41karolherbst: whatever that is
00:41damo22: gpio12 looks interesting
00:41karolherbst: yeah
00:41karolherbst: that's the one I wanted to point out now
00:41karolherbst: "HW Slowdown Enable. On assertion HW will slowdown clocks (NVCLK, HOTCLK) using either _EXT_POWER, _EXT_ALERT or _EXT_OVERT settings (depends on GPIO configured: 12, 9 & 8 respectively). Than SW will take over, limit GPU p-state to battery level and disable slowdown. On deassertion SW will reenable slowdown and remove p-state limit. System will continue running full clocks."
00:43karolherbst: so this essentially means that the GPU says the OS, it limits it's power output, but in a wasteful way, now the kernel driver should reduce clocks so the GPU can operate within limits more efficently
00:43damo22: on my board gpio12 is not connected
00:44karolherbst: I doubt the id has antyhing to dow ith the real location... or maybe it does? no clue
00:45karolherbst: we might just have an iteratore we increase
00:46damo22: https://i2.paste.pics/ILC48.png looks legit
00:47karolherbst: indeed
00:50damo22: so if gpio12 is not even used, maybe optimus is useless except for switching mux
00:50karolherbst: why isn't it used?
00:51damo22: in the schematic, you see R22 and R23 are configured by default to not connect the gpio12 to anything useful
00:51damo22: one is a wire, one is not connected
00:52damo22: the other connection to gpio12 is just a pullup resistor
00:53karolherbst: I would be surprised if that GPIO isn't triggered if you deplug the power connector though... I am sure I saw this happening on a laptop of mine
00:55damo22: there is another way for the VIDEO_THERM_ALERT to get triggered
00:56damo22: based on logic coming from the battery
00:56damo22: /psu
00:58damo22: it looks like gpio12 feeds gpio9
00:58damo22: but on my board its disconnected
01:09damo22: it looks like the battery/psu logic is dependent on ENA_OPT which is turned on by the EC usually
01:09damo22: so optimus is not completely useless
02:46sparky4: back
07:06damo22: this is part of my kernel log from 5.19.9: https://zamaudio.com/mbox2/nouveau.fail.log im seeing these kind of warnings even without my ACPI DSDT changes
07:06damo22: https://zamaudio.com/mbox2/nouveau.fail.txt
07:07damo22: could it be a faulty vbios?
07:21damo22: i dont think it is, ive extracted many the same from different vendor images
19:34sparky4: yo