04:28 gnurou: karolherbst, tobijk: feel free to revert that commit, I'm really puzzled that it causes trouble though
04:28 gnurou: it was just for cleanup anyway, so nothing essential is going to be affected by its reversal
06:57 gnurou: mupuf: btw, commit "add a LED driver for the NVIDIA logo" crashes probe on my GM206 - even though there is no led on this card, nouveau_led_init() finds the LOGO_LED_PWM GPIO, and things go south as led_resume is called right after...
06:59 gnurou: mupuf: also on tegra nouveau_led_init() crashes because there is no GPIO device - you probably want to check that in a fixup patch
07:35 mupuf: gnurou: what the heck? It is just driving an LED, how could this crash? :o
07:35 mupuf: gnurou: do you hgave a backtrace?
07:36 mupuf: ah, for tegra, I did not know this
07:36 mupuf: well, more fixes to do today
07:36 pmoreau: Ah ah ah! Not only did we had a driver for controlling the GPU's LEDs "instead of working on more important issues", but it has the unique feature of crashing your GPU if you don’t have any! :-D
07:36 pmoreau: s/had/add
07:36 mupuf: pmoreau: see, useful work!
07:36 pmoreau: Yeah!
08:19 karolherbst: mupuf: :O
08:19 karolherbst: not your awesome code :(
08:26 karolherbst: gnurou: I am also kind of puzzled, but your commit indeed changes something
08:28 karolherbst: .cpu_coherent = !IS_ENABLED(CONFIG_ARM) -> false, which means … it doens't make any sense
08:28 karolherbst: ohh wait
08:28 karolherbst: it does
08:37 karolherbst: cpu_coherent is true for me
08:37 karolherbst: so "nvbo->force_coherent = flags & TTM_PL_FLAG_UNCACHED;" was never executed
08:37 karolherbst: but with your change it is
08:38 karolherbst: maybe there is an issue within the force_coherent handling
08:39 karolherbst: uhh
08:39 karolherbst: if force_coherent
08:39 karolherbst: TTM_PL_FLAG_UNCACHED
08:39 karolherbst: else
08:39 karolherbst: .. no, nvm
08:40 karolherbst: no clue what the difference between TTM_PL_FLAG_UNCACHED and TTM_PL_MASK_CACHING is
08:41 karolherbst: okay
08:41 karolherbst: TTM_PL_MASK_CACHING means CACHED, UNCACHED and WC
08:47 karolherbst: mupuf: did you check that reverting that coherent commit also fixes your issues?
09:06 gnurou: mupuf: well my understanding is that the call to nvkm_gpio_find() should return nonzero since there is no LED on this card, yet it returns 0 and the LED device is added
09:06 gnurou: karolherbst: yes, that's what happens
09:07 gnurou: but using UNCACHED should not create coherency issues... all the contrary, actually (which is why we use it on Tegra)
09:14 karolherbst: yeah no idea, but mupuf had issues on the tk1 afaik
09:14 karolherbst: well it showed in the same way, but then again I am not exactly sure what architecture the tk1 is
09:15 karolherbst: ahh, arm too
09:31 mupuf: gnurou: ok, but why does it crash? It is just controlling a GPIO, it should be fine :s
09:31 mupuf: unless we don't have proper GPOI support for the GM206
09:31 mupuf: I have one at home, I should be able to test
09:34 karolherbst: mupuf: divide by 0?
09:34 karolherbst: div = nvif_rd32(device, 0x61c880) & 0x00ffffff;
09:34 karolherbst: return duty * LED_FULL / div;
09:34 karolherbst: if the read returns 0, fun
09:34 mupuf: karolherbst: oh, that may indeed happen
09:34 karolherbst: no idea why nouveau_led_get_brightness is called in the first place though
09:35 karolherbst: but it indeed can happen ;)
09:35 karolherbst: allthough we don't know what the subdev do, maybe it polls the value occasionally or so
09:36 mupuf: nope, registering the led class device may call the function
09:36 karolherbst: k
09:36 mupuf: yeah, definitely need to be resistant against this
09:37 mupuf: and I need to check if there is a problem with the detection function
09:37 karolherbst: silly compiler, it should have warn us! :D
09:37 mupuf: gnurou: could you send me your vbios?
09:37 karolherbst: funny though, it doesn't crash for me and I have those patches applied
09:40 karolherbst: mupuf: you also violate the interface of nvkm_gpio_find
09:40 karolherbst: it returns -ENOENT on failure
09:41 karolherbst: ohh wait
09:41 karolherbst: silly me
09:41 karolherbst: forget what I said
09:41 mupuf: ok :)
09:42 karolherbst: well yeah, I would also assume that the vbios declares an LED to be there, but the read returns 0 and things go south
09:42 mupuf: karolherbst: yes, this is very likely
09:42 karolherbst: if that dcb_gpio_match thing is broken we would have noticed before
09:45 karolherbst: mupuf: I also think that your code may behave funny on those high end maxwells, cause they got RGB leds
09:46 karolherbst: maybe there are two reg sets: one color, one brightness
10:02 mupuf: karolherbst: what the heck? No, they must have 3 PWM controlers ;)
10:02 mupuf: one per color channel
10:02 mupuf: RGB LEDs are nothing too fancy ;)
10:02 mupuf: brb
10:04 karolherbst: well, we will see :p
10:04 karolherbst: but yeah, most likely there will be three
17:35 karolherbst: k, got a nouveau crash on suspend yesterday
17:38 karolherbst: mupuf: oho!
17:38 karolherbst: mupuf: <1>IP: [<ffffffff81739ba0>] led_classdev_suspend+0x0/0x20
17:41 karolherbst: mupuf: https://gist.github.com/karolherbst/8903de3d678c8df0d9ec7f83d4731afb
17:42 karolherbst: drivers/leds/led-class.c:111
17:43 karolherbst: led_cdev->flags |= LED_SUSPENDED;
17:46 karolherbst: it does make no sense though
17:50 karolherbst: uhhh
17:50 karolherbst: mupuf: I've got the issue
17:50 karolherbst: nvkm_gpio_find(gpio, 0, DCB_GPIO_LOGO_LED_PWM, 0xff, &logo_led) returns non 0
17:50 karolherbst: means the led subdev won't be initialized
17:50 karolherbst: _but_
17:50 karolherbst: nouveau_led_suspend is called
17:51 karolherbst: and so is led_classdev_suspend
17:51 karolherbst: on drm->led->led which was never initialized
17:51 karolherbst: because there is no LED pwm
18:48 karolherbst: gnurou: does this patch fixes your LED crash? https://github.com/karolherbst/nouveau/commit/b03e9a896c642a8da7ab0532700994cd618db0b4
18:48 karolherbst: *fix
23:35 orbea: i had a full system freeze while playing a gl game, it doesn't really look nouveau related or am I missing something in the syslog? http://dpaste.com/3HH431H Corresponding github issue: https://github.com/loganmc10/GLupeN64/issues/56
23:36 imirkin: orbea: definitely nouveau-related
23:36 imirkin: do you have other GPUs in your system?
23:36 orbea: nope, my gtx 780 ti
23:36 orbea: *just
23:36 imirkin: or rather - ttm-related
23:36 imirkin: but nouveau uses ttm
23:42 orbea: so this is kernel related?
23:43 orbea: I'm kind of stuck on 4.6.7 untl r8618 compiles with newer, no ethernet otherwise...
23:56 imirkin: orbea: yes, it's kernel-related