05:51 <smaeul> jernej: since D1 has a "normal" audio codec without a hub, I wrote a driver for it, and DMA seems to work fine, so H616 probably needs no DMA driver changes

05:51 <smaeul> I brought over some improvements from the BSP driver (https://github.com/smaeul/linux/commits/riscv/d1-wip/drivers/dma), but I can try audio again without them

05:52 <smaeul> to verify they aren't needed for basic functionality

06:29 <montjoie> any hint on how to create a login for getting D1 user manual ? as non-chinese it is hard

06:33 <gamiee> montjoie: I was able to register without any issues, and there is English locale for their website

06:36 <montjoie> any link with english locale ? I see only undisplayable characters

07:26 <warpme_> guys: need some help with cpufreq. I'm working on adding cpufreq on h616 and can't overcome kernel traps when i'm modprobing sun50i_cpufreq_nvmem module. Traps are like this: https://pastebin.com/hrTrRvY5 Looking on trap log i see "WARNING: CPU: 1 PID: 4709 at drivers/opp/core.c:1908 dev_pm_opp_set_prop_name+0x94/0xa0". This seems to correspond to

07:26 <warpme_> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/opp/core.c?h=v5.12.10#n1908 Module loads ok on h6 but traps on h616. I make sure h616 cpu definitions in DT are exactly the same like in working h6. Used h616 opp table also is as close as possible to working h6. Can't understand why dev_pm_opp_set_prop_name function has issue on h616 but works on h6. I added in module code some printks

07:26 <warpme_> (printk("dev_pm_opp_set_prop_name for cpu:%d name:%s\n", cpu, name) before L118; It prints exactly the same like in working h6....

07:30 <warpme_> DT with opp & cpu defs is like this: https://pastebin.com/vqE9UFZu

08:00 <gamiee> montjoie: when you browse https://open.allwinnertech.com/ , in right bottom corner, you have "field", click on it, pick some chinese words, and then again pick English

08:09 <montjoie> gamiee: but the wiki link is not allwinner site but occ.t-head.cn

08:10 <gamiee> montjoie: ohh, then I don't know. But I remember that some files are also on allwinner page

08:12 <montjoie> i need the full user manual

13:07 <smaeul> montjoie: https://www.cnx-software.com/2021/05/02/allwinner-d1-sdk-linux-risc-v-documentation/

13:08 <smaeul> which is effectively a translation of https://d1.docs.allwinnertech.com/study/study_2getsdk/

13:11 <montjoie> smaeul: seems this permits to download only SDK and not documentation

13:15 <smaeul> the documentation is on the same site, under the Documents tab

13:19 <montjoie> I successfully created an account but everything is in chinese:(

13:20 <montjoie> ok found D1 user manual draft version

13:26 <montjoie> thanks smaeul

13:26 <montjoie> anyway it seems crypto is the same without any change

13:27 <montjoie> except the remove of RSA4096 and AES XTS. thoses are not used at all anyway (sarcasm)

13:29 <montjoie> at least they keep 3DES, security is safe

13:32 <smaeul> do you think I could load sun8i-c3 with the allwinner,sun50i-h6-crypto compatible and it would probably work?

13:33 <montjoie> you could try and see what happen

13:45 <smaeul> with H6 compatible it is unhappy: https://tpaste.us/6PRZ, but if I comment out the "*_t_dlen_in_bits = true," (still using h6 to keep the mbus clock), it stops complaining: https://tpaste.us/V7ON

13:46 <smaeul> I don't have time right now to test it further, though IIRC those fallback messages mean something is still wrong?

14:38 <MoeIcenowy> montjoie: the t-head thing is CPU manual

14:38 <MoeIcenowy> not SoC one

15:06 <jernej> smaeul: wow, you enabled a lot of D1 peripherals, good work!

15:06 <jernej> smaeul: thanks for DMA bits, I'll use them once I figure what to do with audio

15:12 <jernej> smaeul: look at that, H616 and D1 have same audio codec, except that H616 doesn't have anything ADC related

15:13 <jernej> I suspect it actually has, it's just not exposed to pins

15:22 <MoeIcenowy> megi: do you consider to make gc2145-init.bin loading message less verbose?

15:28 <montjoie> smaeul: looks good, but you need to compile with CONFIG_CRYPTO_MANAGER_DISABLE_TESTS disabled to be sure

15:28 <montjoie> according to the first log it is already the case

15:29 <montjoie> let me create a patch which handle the _t_dlen_in_bits

16:49 <megi> MoeIcenowy: sure

18:05 <jernej> apritzel: what I need to do to syscon phandle in second emac node for H616?

18:08 <jernej> ah, I see, you have second emac node in your v4 series

18:11 <apritzel> yeah, it's still part of my v7 here, but beyond the point I will send ;-)

18:12 <apritzel> jernej: you probably figured that yourself, but you just say <&syscon 1>

18:13 <jernej> oh, you have v7 ready?

18:16 <apritzel> jernej: yeah, final tests ...

18:36 <montjoie> what will be the "prefix" for allwinner D1. i need to create a new compatible for sun8i-ce

18:40 <jernej> presumably "sun20i-d1"

18:45 <jernej> apritzel: guess what, reboot works fine on my very old H616 U-Boot & TF-A combo for T95 (with eth hack)

18:46 <jernej> I guess I'll do more development on T95 :)

18:56 <montjoie> smaeul (and anyone which want to test) http://dpaste.com/9EP98HAV6

19:11 <apritzel> jernej: I figured the other day that reset on my PineH64 works in U-Boot, but not from Linux

19:12 <apritzel> jernej: originally I thought that is due to my early board (with that patch wire)

19:12 <apritzel> but since it works in U-Boot ...

19:13 <apritzel> ah, wait, U-Boot on H6 doesn't use PSCI for reset, IIRC

19:23 <jernej> and for some reason I can't enable HDMI on T95

19:24 <jernej> no apparent error, regulators are ok, EDID is read ok...

19:28 <apritzel> jernej: black screen, but monitor detects signal?

19:28 <apritzel> I think I saw this when I tried HDMI on my X96 box

19:29 <apritzel> with that new patch to fix 5.13 HDMI

19:30 <jernej> I don't have it in my branch

19:31 <jernej> and if HDMI controller wouldn't work, then EDID wouldn't be read, I think

19:31 <jernej> let me test same branch with OPi again

19:38 <jernej> apritzel: I got it, U-Boot is too old and SPL doesn't have that PLL fix

20:15 <MoeIcenowy> apritzel: BTW any idea on refactoring U-Boot?

20:15 <MoeIcenowy> I think there's not any better location to place sunxi-specific code...

20:16 <MoeIcenowy> (if boards/sunxi is a bad idea

20:17 <MoeIcenowy> major problem is that we may some day move some specific board related code to board/vendor/model, like pinephone edition detection to board/pine64/pinephone

20:40 <apritzel> MoeIcenowy: I am not a fan of this board/vendor/model scheme in U-Boot, and so am quite happy that we don't have it for sunxi

20:42 <apritzel> it encourages the idea of having board specific code, decided at compile time, which should be covered by DT

20:42 <apritzel> that is for U-Boot proper, of course, the SPL is a different story

20:42 <apritzel> but we don't need that extensive scheme for those small detection functions that we have today

20:43 <apritzel> MoeIcenowy: the question is just where the D1 belongs to: can it really live under the sunxi umbrela