06:36 <narmstrong> tolszak: list the possible frequencies from cpufreq, it should be there

09:49 <tolszak> narmstrong: Is it possible to overclock odroidc2 clock using meta-meson and mailnline kernel/u-boot?

09:49 <tolszak> narmstrong: xdarklight helped me to enable cpufreq but as you said it is limited to 1536. I just didn't get that the limit is set by u-boot...

09:50 <narmstrong> tolszak: the limit isn't set by u-boot

09:50 <tolszak> narmstrong: So I misunderstood it even more :) Is there a way to overclock it?

09:50 <narmstrong> tolszak: the tables are in the firmware loaded in the SCP co-processor bundled with u-boot, then used via the SCPI protocol

09:51 <narmstrong> tolszak: can you list the possible frequencies listed by cpufreq

09:51 <narmstrong> the fw I use in meta-meson may have the correct frequencies, so you'll probably need to import the "bad" ones with tables up to 2GHz in amlogic-boot-fip

09:53 <tolszak> narmstrong: I need to reflash the sd card, but yeah they look like the ones from https://wiki.odroid.com/odroid-c2/application_note/software/set_cpu_freq up to 1536

09:56 <narmstrong> seems they have tricked the scpi table to allow going higher https://github.com/hardkernel/u-boot/commit/205c7b3259559283161703a1a200b787c2c445a5

10:00 <tolszak> Ok so the frequencies I see are: 100000 250000 500000 1000000 1296000 1536000

10:00 <tolszak> narmstrong: Device has custom 20W power adapter and fan, hence it could work stable with 1752

10:01 <narmstrong> tolszak: a trick must be done in the scpi driver to use the "alternate" table

10:01 <narmstrong> https://github.com/hardkernel/u-boot_firmware/commit/b7b90c1099b057d35ebae886b7846b5d9bfb4143 is the firmware change, now we must find how to use that from linux

10:02 <narmstrong> I found it: https://github.com/hardkernel/linux/commit/2e620611646d7145db7026f38c68d5b4aedd5aa7

10:04 <narmstrong> tolszak: add https://termbin.com/pk9x

10:05 <narmstrong> tolszak: but you'll perhaps need to update the amlogic-boot-fip odroidc2 firmwares with https://github.com/hardkernel/u-boot/tree/odroidc2-v2015.01/fip/gxb as built by recipes-bsp/trusted-firmware-a/amlogic-boot-fip.bb

10:06 <narmstrong> or not, test before with this patch

10:08 <tolszak> narmstrong: building updated kernel

10:08 <tolszak> amlogic-boot-fip from librelec you use seems like using hardkernel blobs

10:11 <narmstrong> yep, but I don't know if they contain this trick

10:11 <narmstrong> it should they they were added in 2019

10:26 <tolszak> narmstrong: http://dpaste.com//9W2YKEXTN kernel null pointer

10:28 <narmstrong> :-/

10:30 <tolszak> narmstrong: I copied the files from fip/gxp to amlogic-boot-fip/odroid-c2 they are exactly the same

10:38 <tolszak> narmstrong: I think I know what's wrong

10:39 <tolszak> Do I understand correctly that adding 0x80 informs firmware to use different table, but it is only between kernel and firwmare communication. So we should only add 0x80 in scpi_send_message. And use initial domain value in scpi_info->dvfs[domain] = info;

10:39 <narmstrong> oh yeah indeed

10:40 <narmstrong> we should make a copy of the domain we pass to sent_message

10:40 <tolszak> narmstrong: Testing it now

10:41 <tolszak> I mean building then testing

11:27 <tolszak> narmstrong: Still crashing, shouldn

11:28 <tolszak> shouldn't we replace any scpi_send_message with domain | 0x80?

11:30 <tolszak> e,.g. in scpi_dvfs_get_idx, scpi_dvfs_set_idx

12:11 <tolszak> narmstrong: Hmm should it should still work with modern boot right?

13:17 <narmstrong> tolszak: I don't understand

14:48 <tomeu> narmstrong: do you happen to know off the top of your head to which dtsi I should add a node for the vivante npu on the vim3?

14:49 <tomeu> I leaning towards meson-g12b-a311d.dtsi, but I don't know if other socs based on g12b also have that IP

14:49 <narmstrong> tomeu: A311d and S905D3 uses this ip

14:50 <narmstrong> I tried once and got the etnaviv kernel driver probe, let me search if I find the change

14:50 <tomeu> narmstrong: oh, I was actually having some problems with the power domain

14:50 <tomeu> we got it to run quite a few opencl CTS tests, btw

14:51 <tomeu> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18986

14:51 <narmstrong> oh you got it working ??? great

14:51 <tomeu> I'm now cleaning up the kernel changes, they are quite small

14:52 <tomeu> this is what I ended up doing out of desperation, when trying to get it to probe: https://gitlab.freedesktop.org/tomeu/linux/-/commit/af365186ab305d2fa3e91145ac79d2569b9df2a5

14:52 <narmstrong> add the node to g12-commont but enable it only into a311d

14:53 <narmstrong> for SM1 it's not clear which socs has the ip

14:55 <narmstrong> tomeu: ok, the G12B power domain must be missing, it's present for SM1 (PWRC_SM1_NNA_ID)

14:57 <narmstrong> I think you should only enable it on known boards we are sure the IP is enabled in the fuses like the vim3 & vim3l

14:58 <tomeu> narmstrong: ok

14:58 <tomeu> if you find the patch that gets it to probe properly, it could save me quite some time :)

15:00 <narmstrong> seems I lost it when leaving baylibre :-/

15:01 <tomeu> oh, didn't know that happened

15:01 <tomeu> do you remember anything about the power domains? I suspect that is what I was missing

15:20 <tomeu> narmstrong: guess I should be adding a PWRC_G12A_NNA_ID power domain similar to that in SM1?

15:21 <narmstrong> tomeu: yes

15:34 <narmstrong> tolszak: is it the same crash as before ? what was your change >