12:40 <warpme_> i'm issuing memdev2 with word (devmem2 0x3001674 w)

12:40 <warpme_> jernej: fyi: with turning-off GPU secure memory (mw.l 0x3007054 0) i see improvement. ui has sort of working animatons (i.e. white borders of pop-ups are niceely fade-in/fade-out). but that's all. rest is all black. playing with setting bit 31 at 0x3001674 gives me buss error in memdev2. i can access this loc with byte and half-word. but accessing by word gives buss error - so probably issue is incorrect mem.aligment when

12:43 <warpme_> and still gpu job timeouts. in bsp dt i see gpu has 3 clocks (bus & gpu0 & gpu1). maybe h616 has more granullar power management by capability to run each of 2 exec.unit with different clocks?

12:43 <jernej> warpme_; you can set that in U-Boot too

12:44 <warpme_> memdev2 is nicer as playing with bit not requires reboot :-)

12:45 <jernej> third clock, named gpu1 on mainline, is used to properly switch frequency

12:45 <warpme_> but when we will guess correct reg.settings - all switch to uboot (hack like this https://github.com/warpme/minimyth2/blob/b1cd7555a8301b53b00d916500f225f3cc041fb7/script/bootloaders/board-h616.tanix_tx6s/files/h616-boot.txt#L6)

12:46 <jernej> if you want to change gpu0 frequency, you switch gpu0 parent to gpu1 then change pll-gpu rate and at the end, switch gpu0 parent to pll-gpu

12:46 <jernej> don't ask me how to properly model this on mainline, I have no clue

12:48 <jernej> warpme_: didn't you say yesterday that changing secure memory doesn't help?

12:51 <warpme_> yes. yesterday feedback about secure memory was "timeouts are still present". today i accidentally discovered that doing actions on player which generates ui pop-ups is visible on screen....

12:52 <warpme_> fade-in/fade-out speed is fluent the same like on working g31 on amlogic sm1

12:52 <jernej> without secure memory change, that isn't the case?

12:53 <warpme_> i think sec bit changes - but to be 100% sure - let me chek :-)

12:53 <jernej> well, there is another possibility that there can be additional quirk hiding in userspace component

12:54 <jernej> something like that in mali450 on H5

12:56 <jernej> warpme_: you can also try with bit 0 set to 1 in gpu1 register (along with bit 31)

12:57 <jernej> apart from that, I can't help, I don't have any H616 board at hand currently

12:59 <warpme_> hmm - it looks like clearing security mem bit don't have impact. not touching it also gives those partial ui aminations

13:02 <warpme_> re: word access misalignment from devmem2 - what will be your advice? you mention b31 at 0x3001674. should i go with b7 at 0x3001677 with byte access?

13:03 <warpme_> i dont recall is arm gig or little endian...

13:03 <warpme_> gig->big

13:11 <jernej> I think I have similar alignment issues before, but it dependent on userspace

13:12 <jernej> using another rootfs helped

13:12 <jernej> arm can be run as both, big and little endian

13:12 <jernej> but more or less everyone run it as little

13:12 <jernej> bbl

13:34 <warpme_> jernej: fyi: some observations: i started to suspect issue might be related to something like gpu surfaces - de planes interop. kicking ui pop-ups with animations _not_ triggers gpu job timeouts. this tells me gpu job scheduling and then execution is ok. gpu job timeouts are happening without any user actions and are every 60s (like clock update on player ui)

14:12 <warpme_> Started to think this might be sfbd vs mfbd thing as t720 Is sfbd while g31 Is mfbd do DisplayEngine wykuł deal with this (sent from phone)

14:39 <apritzel> warpme_: wasn't it that devmem2 is broken on 64-bit?

14:40 <apritzel> warpme_: because "word" accesses mean unsigned long, which isn't exactly the 32-bit access you want ;-)

14:40 <apritzel> warpme_: and from my experiences you can access the lower bits in a 32-bit reg via bytes accesses, but not anything >= 8

14:47 <apritzel> warpme_: I wrote peekpoke (https://github.com/apritzel/peekpoke) to fix that issue and also be more useful for hackers (like you can ask it to just flip a bit)

14:47 <apritzel> $ peekpoke -b 0x3001000 s.l 0x674 31

15:43 <jernej> warpme_: try off screen GPU rendering

15:44 <jernej> not 100% sure how to do that, but anarsoul or rellla probably know

15:45 <jernej> apritzel: that looks very useful

15:46 <jernej> if only it could dump a range of memory... :P

17:08 <apritzel> jernej: I thought the same the other day ;-)

17:23 <anarsoul> jernej: https://github.com/yuq/gfx/blob/master/gbm-surface/main.c

17:42 <evadot> do I recall someone saying that hdmi phy in A64 cannot use pll video1 even if it's documented that it should work ?

17:56 <jernej> evadot: what it's documented is that HDMI controller can use pll-video1 and that works

17:57 <jernej> issue is HDMI PHY, which can't use pll-video1

17:57 <jernej> only pll-video0

17:57 <jernej> (there is no documentation about that)

17:59 <evadot> yup ok that's what I remembered then

17:59 <evadot> thanks

19:29 <tuxd3v> hello any proper way to define i2c in device tree for alwinner h3?

19:30 <tuxd3v> I am geting tons of:

19:30 <tuxd3v> 'i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0' in dmesg

19:33 <tuxd3v> the bus is stuck, or blocked.

19:35 <megi> is the device powered on?

19:35 <tuxd3v> this are the ones detected: https://paste.debian.net/hidden/61a12a8d/

19:35 <tuxd3v> the Soc is the i2c, I don't know :/

19:36 <megi> I mean the device you're trying to comm with

19:37 <megi> and it's io bus voltage regulator

19:37 <tuxd3v> I have no devices on it yet, I was just probing if it was working ok :)

19:38 <megi> you need to have pullup resistors on bus lines and the bus needs to be powered

19:38 <megi> then it may work

19:38 <megi> bus locked usualy means that SCL or SDA is constantly in a low state

19:41 <tuxd3v> the sun8i-h3.dtsi doesn't have i2c there :/

19:42 <megi> there's a combined dtsi for h3/h5

19:42 <megi> it's in that one

19:42 <tuxd3v> megi, thanks :)

19:47 <tuxd3v> marvell,mv64xxx-i2c.yaml, its a marvel ip :)

19:52 <tuxd3v> allwinner H3 is sun8i right?

19:52 <tuxd3v> or is sun6i

19:53 <vagrantc> sun8i

19:53 <tuxd3v> I have 2 options for spi

19:54 <tuxd3v> CONFIG_SPI_SUN4I=y

19:54 <tuxd3v> CONFIG_SPI_SUN6I=y

19:54 <tuxd3v> don't know what to use :)

19:54 <tuxd3v> maybe 6i?

19:57 <tuxd3v> allwinner h5 is sun50i right?

19:57 <tuxd3v> they share a lot of IP between them..

19:59 <vagrantc> just because a platform is sun8i, doesn't mean it doesn't use some other sun*i drivers :)

20:08 <tuxd3v> indeed :)

20:09 <tuxd3v> but it turn things dificult to configure, some options you are afraid to disable..

20:31 <smaeul> when in doubt, `git grep <compatible-string> drivers` will tell you which one to use. generally it's sun8i, sun6i, sun4i in order of most to least likely

20:31 <smaeul> though it doesn't hurt to enable all of them

20:35 <smaeul> D1 will make this even more confusing: the same die is sun8iw20p1 (R528, with dual Cortex-A7) and sun20iw1p1 (D1, with Xuantie C906). but the most-similar older SoC (for fallback compatibles) is R329 == sun50iw11p1

20:48 <vagrantc> the risc-v boards are using the same drivers? whee.

21:00 <apritzel> this sun<x>i naming is some AW blunder: they decided at some point to start naming the SoC after the Cortex cores they put in

21:01 <apritzel> so every SoC with A53s is sun50i, and the sun8i are A7s

21:02 <apritzel> but this wasn't always the case, so the earlier numbers (4i. 5i. 6i. 7i) indeed showed the generations of devices

21:04 <smaeul> it also doesn't help that they release the same die under 3+ different names, like R40/A40i/V40 or R528/D1/T1033

21:07 <smaeul> and that they can't number their families/generations sequentially. there's "v1" which covers everything from A31 (sun6i/sun8iw1) to A64/H5/A63, then "NCAT" which is H6 through H616, and then "NCAT v2" which is the D1

21:23 <apritzel> yeah, but that's marketing, and it's similar elsewhere

21:23 <tuxd3v> its madness :)

21:23 <apritzel> it just means that one shouldn't interpret too much into the names of the drivers

21:27 <apritzel> smaeul: you mention A63 being related to A64/H5, but I think it's the actual first NCAT device: a lot is very similar to the H6

21:32 <apritzel> tuxd3v: btw: the H3 and H5 are pin-compatible, and they share most (but not all) of the devices (MMC being the exception)

21:34 <smaeul> apritzel: oh, yes you are correct. but yet in mainline everything has H6 as the base compatible because nobody did bringup for the A63

21:35 <apritzel> smaeul: I know :-(

21:35 <apritzel> I actually bought a tablet a while ago, and got FEL working, but then got stuck with DRAM, and didn't find the time to come back to this

21:35 <smaeul> this will be the same situation for R329 and D1: R329 is the "first" NCATv2 device, but I cannot find any hardware to test with

21:36 <apritzel> so both are a step up from even H616?

21:39 <smaeul> yes, H616 memory map is similar to A63/H6/A50/A100; whereas R329 and D1 have a similar, rearranged memory map

21:41 <apritzel> so they put every device in their own 64K page, eventually?

21:41 <apritzel> just kidding, I know it's AW ;-)

21:42 <smaeul> no :) but presumably they had to adjust their bus structure to add the RISC-V core and its giant PLIC MMIO area at 0x10000000

21:53 <apritzel> 256MB?

21:54 <apritzel> I mean TBH honest they have plenty of address space left below 1GB (given the number of devices and their MMIO footprint), but I wonder why they didn't use that for ECAM then on the H6