01:12 <enthdegree> Soupborsh: are you in #postmarketos-lowlevel on matrix

01:13 <enthdegree> Soupborsh: I wrote some (fairly superficial) stuff about the B288's eink driver there

10:56 <apritzel> warpme: I created a Wiki page for the X96QPro+: https://linux-sunxi.org/X96QPro%2B feel free to add infos to it, or upload better pictures

14:51 <MoeIcenowy> apritzel: currently what's the preferred behavior of getting DT into u-boot? sync to arch/arm/dts or sync to dts/upstream/ and use OF_UPSTREAM?

14:52 <MoeIcenowy> ( going to add https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/allwinner/sun8i-a33-vstar.dts to u-boot

14:53 <jakllsch> OF_UPSTREAM seems to be popular on the u-boot list these days

15:22 <apritzel> MoeIcenowy: most SoCs differ slightly between kernel and U-Boot, that's why I cannot switch them to OF_UPSTREAM easily. I did it for H616, which does not differ, but A33 is affected

15:22 <apritzel> so for now the process for new DTs is to upstream them to the kernel first, and for the A33 for instance we manually sync, into arch/arm/dts

15:24 <apritzel> and you wouldn't need to sync dts/upstream manually, that would be done by generic, regular U-Boot commits

15:25 <apritzel> for OF_UPSTREAM, if you need a patch early, you can cherry-pick that from the dt-rebasing repo, and then later the regular sync would skip that automatically

15:26 <apritzel> (cf. commit c9fbe861a2fc1ca160dc, for instance)

15:28 <apritzel> MoeIcenowy: long story short: add a commit that adds sun8i-a33-vstar.dts to arch/arm/dts in your U-Boot series, and we then take it from there

19:20 <loki666> apritzel: would it be possible that NMI is completly broken on H700 ?

19:22 <loki666> I can't find the details of reg 0x07010320 (where the nmi controller dts points to)

21:58 <macromorgan> apritzel: I think I figured out finally why adding the ID number caused the driver issue. devm_iio_channel_get() calls iio_channel_get(). If there is a valid dev_name() then it uses the device to find the ADC channel, and if there isn't a valid dev_name() it uses iio_channel_get_sys() instead.

21:59 <macromorgan> Long story short if the ID was null, the device had no name, so it used the get_sys routine which worked; when the device got an ID it got a name, which doesn't work

22:00 <macromorgan> I'm thinking if I can add a new routine of devm_iio_channel_get_sys() and mirror devm_iio_channel_get() we might be back in business

22:10 <macromorgan> yep, I cut and pasted devm_iio_channel_get() and replaced the iio_channel_get() call with iio_channel_get_sys() call and that was all it took. I'll put together a patch series. I expect IIO may want the new routine called something else to avoid confusion

22:11 <macromorgan> I'll format the patches and send v1 up in the next day or so

22:54 <macromorgan> I just posted my fixes, check them out... let me know what you think: https://lore.kernel.org/linux-pm/20241210224859.58917-1-macroalpha82@gmail.com/

23:10 <apritzel_> loki666: do you mean the hardware side of it? If you see a number > 0 in /proc/interrupts, and particularly it increasing on power key presses, I'd say it works

23:10 <apritzel_> regarding the manual: we don't have a H700 manual, and this NMI pin is one of the differences between the H313/H616/H618 and the H700

23:16 <loki666> Mmmh ok... We do get pek IRQ registered (both raising and falling)

23:18 <loki666> But still can't wake up from it... Any idea on which node I should put the wakeup-source? BSP put it on the PMIC node... But doesn't work on mainline

23:20 <loki666> I also tried to copy some regs values from BSP (that I think are related), but no luck either

23:20 <loki666> Some PMIC regs I mean