00:12 damo22: karolherbst: nv optimus is a pair of functions, switching mux and power control. But the power control part just sets a flag in ACPI to tell _PS3 to turn off the power or not based on the advertised capability
00:13 damo22: so if you dont call the _DSM it wont set the internal flag to power down
00:23 anholt: hmm. new jetson nano is booting. but too bad nouveau oopses on boot.
00:24 anholt: probe -> device_create -> nvk_device_tegra_new->iommu_detach_device null deref
00:50 anholt: regulator_enable(tdev->vdd) failing leads to the crash in error handling. (error recovery in the linux kernel: always broken?)
01:54 karolherbst: damo22: that's.... very wrong :(
01:54 karolherbst: at least microsofts specification don't say anything in this regard at all
01:56 karolherbst: why are OEMs always putting buggy shit or broken workarounds into their firmware :(
02:19 damo22: karolherbst: i dont know, but on my thinkpad fedora 36 is unusable with dual graphics set
02:19 damo22: it randomly locks up the cpu
02:20 damo22: i think ill stop try to dig into this
02:20 damo22: trying*
02:32 damo22: the only way to move forward is to get a working UART on two machines and watch the kernel log as it freezes i think
02:58 damo22: should i try upgrading mesa-* to latest version ?
03:19 anholt: tagr: Looks like as of 8c193f4714df136a6747fb66f4218134771092be we can't set jetson nano's gpu's regulator any more, it throws EINVAL about the rate returned from mul_u64_u64_div_u64(32768, 8000, 256000000000)
03:20 anholt: sigh linux at having to write 100 lines of debug printfs to chase what went wrong.
08:36 damo22: i think i figured out what is going wrong with my board, the linux pci allocator does not allocate resources to my board properly, but coreboot does!
08:38 damo22: im getting stuff like http://paste.debian.net/plain/1254166
11:29 karolherbst: damo22: huh.. "has bogus alignment" sounds bad
14:30 damo22: its a bogus "bogus alignment" as in, it is aligned fine
14:31 damo22: i managed to get it to boot if i turn off the conflicting devices in the device tree
14:31 karolherbst: ahh
14:32 damo22: but they shouldnt really be conflicting
14:32 karolherbst: in regards to the _DSM mess, I am actually curious if there is some weird handshake we have to follow but we don't.
14:35 damo22: in my vendor bios that includes 10de:0ffc built into the board, _DSM calls a method called NVOP that pokes a value into a parameter called "OMPR"... that value is checked in _PS3 and if it has the wrong value _PS3 is a noop
14:36 karolherbst: okay...
14:37 karolherbst: sadly we never recieved any docs in this regard :(
14:37 karolherbst: but that sounds like to be very nvidia specific stuff
14:37 karolherbst: but I also see referenced on the internet of not implemented NVOP
14:38 karolherbst: anyway... I guess the _DSM is key, _but_ I suspect the driver/OS queries information before doing any of that
14:38 damo22: i only know what i read in the decompiled AML
14:38 damo22: for one board
14:39 karolherbst: yeah sure, but the _DSM contains several methods
14:40 karolherbst: and some return data or flags
14:40 damo22: well NVOP has 3 cases that i know of
14:40 damo22: 0x0 advertises what functions it supports
14:40 damo22: 1 << n
14:41 damo22: means nth function is supported
14:41 damo22: and then theres 0x1a and 0x1b
14:45 CodeAgain: Hello... Did nouveau benefit from these new opensource drivers by nvidia?
14:48 damo22: 0x1a is a setter, it accepts flag = OMPR <<24 | FLCH
14:49 karolherbst: CodeAgain: not yet, but it will soonish
14:49 damo22: if FLCH is set to 1, it sets OMPR to the 2 bits in 24,25
14:49 karolherbst: damo22: mhh.. I really want proper docs on that from nvidia though.. this topic is such a mess, that if you do something wrong, you can easily break a lot of systems :(
14:50 karolherbst: I think I'd really need a higher level overview on what all those things do
14:50 damo22: yeah
14:50 damo22: youre right
14:51 damo22: but the code in nouveau_acpi.c is already doing most of it
14:51 damo22: im just not sure if its right
14:51 karolherbst: I think I'll just wait until nvidias open source driver supports all of that officially, then we just copy&paste or something
14:51 hell__: damo22: I forget, are the issues you're having with coreboot?
14:52 karolherbst: nvidia has tons of PCI related quirks in the driver
14:52 karolherbst: but I don't know how many of them are related to this here
14:52 damo22: hell__: im trying to fix optimus support
14:52 karolherbst: and we might ahve to copy all of those
14:52 hell__: damo22: in coreboot, right?
14:52 damo22: yes
14:53 CodeAgain: karolherbst, great!
14:53 CodeAgain: So, I'm considering buying a new computer, I was more inclined to buy a radeon... But now I'm thinking about one of the nvidia models supported by their open source driver...
14:53 CodeAgain: Is there a model that would also allow me to contribute to the nouveau development process (i.e. testing)?
14:53 hell__: damo22: ok, there were allocator issues recently, make sure https://review.coreboot.org/67329 and https://review.coreboot.org/67328 are in and that top-down allocation is disabled
14:54 damo22: ugh!
14:55 hell__: idk if you were told already, but I'd rather restate something you already know than leave you in the dark
14:57 damo22: hell__: thank you, it was already merged though in my tree
15:03 hell__: nice
17:45 CodeAgain: I know the current discussion is way more relevant than my silly question, but I would really appreciate any suggestions on that...
17:46 CodeAgain: I mean, is there a way you operate with testing? Somethink like a list of devices that would be appreciated for testing or anything like that?