05:55 <Mis012[m]> actually, the suspend is a noop as well...

05:56 <Mis012[m]> it enables overriding suspend value from SW, but it doesn't touch the control bit, which is set to not suespend

05:56 <Mis012[m]> *suspend

05:56 <Mis012[m]> so maaybe if it was in suspend, it's turning it on and then off?

13:46 <alexeymin> Marijn[m]: hi, sorry again, what was the verdict for https://patchwork.kernel.org/project/linux-arm-msm/list/?series=635149 ? Is the patch itself correct (the DTS additions) and the IRQ problem is with the driver itself, or is something wrong in the patch?

13:47 <Marijn[m]> alexeymin: The verdict is that I'm not fully sure myself either

13:47 <Marijn[m]> On msm8956 for example I see a ton of "OVP START something something" in the logs as soon as the panel turns off, and I think a similar stacktrace shows up as soon as the panel is turned on again

13:48 <Marijn[m]> But I'll have to re-check that. I can also test on an sdm630 device for good measure

13:48 <Mis012[m]> that patch looks way too simple to be the culprit...

13:48 <alexeymin> In my tests this warning showed only once during the first attempt to change brightness

13:49 <Marijn[m]> Mis012: It's very well possible if the current limit is set too low in DT

13:50 <Mis012[m]> Marijn[m]: current limit for the LED? would the pmic even know if it's too low?

13:50 <Mis012[m]> eh, used a reply again

13:50 <Mis012[m]> dammit

13:51 <Marijn[m]> The PMIC would trigger an overcurrent error sooner, if it's set lower than what the WLEDs normally pull

13:51 <Marijn[m]> But anyway, this is an overVoltage interrupt

13:51 <Marijn[m]> So I may have been mistaken

13:51 <Marijn[m]> That could mean a short on one of the unconnected LED strings

13:51 <Marijn[m]> (IIRC that's how the autodetection works)

13:52 <Mis012[m]> well, either that or someone shorted it just 'cause? :P

14:50 <alexeymin> Marijn[m]: but the warning says only "Unbalanced enable for IRQ" and nothing more?

14:52 <alexeymin> as far as I can see the brightness setting works fine :)

15:05 <Mis012[m]> >Unbalanced enable for IRQ

15:05 <Mis012[m]> that hardly sounds like a dts issue :P

15:05 <Mis012[m]> bamse: sorry, who did you say has the qcs40x board again?

15:08 <Marijn[m]> alexeymin: I think you just uncovered the quality of my short-term memory

15:08 <Marijn[m]> In any case, the reason I remember it this way is because afaik the enable_irq is triggered from the handler for OVP

15:08 <Marijn[m]> [ 500.078190] wled_ovp_work+0x14/0x20

15:08 <Marijn[m]> [ 500.062686] enable_irq+0x48/0xa0

15:09 <Marijn[m]> If I'm not mistaken, that second function should only be entered if the OVP IRQ has previously triggered (and this re-registers it, since it should be oneshot?)

15:09 <Marijn[m]> (Disclaimer: I'm not looking at the code and haven't seen it for ~0.5 year)