00:21 <m4t> not sure if it means anything but i see the low temp changing for the nct1008:

00:22 <m4t> nct1008_2: +64.5°C (low = +40.0°C, high = +70.0°C) ALARM (LOW)

00:22 <m4t> nct1008_2: +66.5°C (low = +65.0°C, high = +70.0°C)

00:22 <m4t> different zones maybe?

00:23 <m4t> yeah that must be it. seems when it hit 65.5 it changed from 40 -> 65

00:40 <digetx> that's the correct behaviour

12:09 <digetx> cyndis: are you still on vacation?

12:10 <cyndis> I just came back

13:04 <digetx> cyndis: is the host1x VM firmware API/workflow documented anywhere? if not, is it possible to write that documentation?

13:15 <cyndis> there is no firmware or api

13:15 <cyndis> the hardware itself has been designed for this kind of usecase, which can be seen e.g. in how other VM's syncpoints are readable, and indeed waitable with the mod 2^32 semantic

13:46 <digetx> is it all fully documented anywhere that syncpoints are readable and etc?

14:00 <cyndis> I don't know if any public documentation explicitly says that they are readable, but in the TRM in the virtualization sections it is several times said that inter-OS protection for syncpoint prevents syncpoint increments

14:02 <cyndis> looks like it also says "Sync points do not normally reset, but can wrap"

14:26 <digetx> can you create a todo list for the work on upgrading and improving kernel driver?

14:30 <digetx> will you give feedback about the driver reorganisation?

14:38 <digetx> the sync points don't really bother me, although it will be nice if the full workflow could be documented more cleanly; what bothers me is how this all will be integrated with the proper job scheduling and etc because it may affect UAPI a lot and it will certainly require the overhaul of the driver

14:43 <digetx> I mean that the current UAPI should be incomplete at this point and we need to continue the work on it, which requires the input from you since I don't familiar with what is needed for the newer h/w in regards to scheduling / context switching / syncing and etc

15:40 <DavidHeidelberg> digetx checkpatch PR ready, and it cries all over my commit (which is correct) :D

15:40 <digetx> is it using --strict option for checkpatch.pl?

15:44 <DavidHeidelberg> digetx experimenting with Codacy (for automated code quality review, when we have that CI :) )

15:59 <digetx> checkpatch is very nice to have too, thank you

16:00 <digetx> I'd want to use --strict option to get warnings about indentation and whitespaces

16:35 <m4t> digetx: i let it play music all night with intermittent openssl speed's and continuously calling 'sensors'. can't repro

16:38 <digetx> that's good

18:18 <p2-mate> mja, enigsinds ja

18:18 <p2-mate> https://www.forbes.com/sites/thomasbrewster/2021/07/13/revil-ransomware-hackers-disappear/

18:19 <p2-mate> lijkt het nieuws ook wel te brengen?

20:56 <DavidHeidelberg> about testing against different toolchains. I have API key for tuxsuite, which is one-click solution to do the test. One disadvantage is, it's not M$, so they have to pay for the instances I guess. Build takes circa similar time and it can be launched with one command for multiple kernels ($ tuxsuite build-set --git-repo .... etc.)

20:56 <DavidHeidelberg> digetx if you want, if you send mail to tuxsuite@linaro.org and they give you API key to run builds :) I'm currently testing first grate-driver/linux master against gcc-9;gcc-11 and clang-12

20:56 <DavidHeidelberg> 👾 Pass (15 warnings): 2bd31fcbfeb4 ("CI: implement checkpatch.pl") arm (tegra_defconfig) with clang-12 @ https://builds.tuxbuild.com/1vH6GHPtSHTbOUInST2OuJX31rq/

20:56 <DavidHeidelberg> 👾 Pass (12 warnings): 2bd31fcbfeb4 ("CI: implement checkpatch.pl") arm (tegra_defconfig) with gcc-9 @ https://builds.tuxbuild.com/1vH6GLuPFkLoLI89ooMMkuWFGjO/

20:56 <DavidHeidelberg> 👾 Pass (12 warnings): 2bd31fcbfeb4 ("CI: implement checkpatch.pl") arm (tegra_defconfig) with gcc-11 @ https://builds.tuxbuild.com/1vH6GKavqCFGbpNarg3Q5MhFGV2/

20:56 <DavidHeidelberg> seems like clang is useful, it found out misplaced ret :)

22:14 <DavidHeidelberg> I may start like Mozilla again, using SCCache on Github action at their current load reduced compilation time from approx. 20 minutes to 6.5 minute. Nice, time to implement for grate/linux

22:14 <DavidHeidelberg> Cache is about 245M for 5.10 kernel, which is also nice and acceptable, since Github offers much more

22:16 <maxim[m]> digetx: Hey, I found the correct fixes tag for the missing CONFIG_FB option:

22:16 <maxim[m]> > Fixes: f611b1e7624c ("drm: Avoid circular dependencies for CONFIG_FB")

22:51 <DavidHeidelberg> 353MB cache, cache filling 26 min for tegra-next; let's see second cached run

23:00 <DavidHeidelberg> 8 minutes w/ caches, sounds good, sending PR

23:03 <DavidHeidelberg> and 21 minutes was without caches, so filling caches add +- 5 minutes, but I hope that in longterm most of caches will be reused (we'll have to observe how it'll behave for -next which changes a lot)

23:05 <DavidHeidelberg> good night :)