Hm, let me dig out the AX3600, it's rather weird as its the schedutil still making decisions on scaling nothing has changed in that regard.
Wait, when I do static tests, it goes to the higher speed:
Maybe the previous (real) load was not lasting long enough to kick it to full speed...
It could be, as there should be a measurable delay as the update time isn't that high.
Nice reading if you have spare time:
1 Like
It's strange I think we should dump them and parse manually
Another possibility is that they are not blown at all
Not needed for low spec soc and requires only for ipq8074?
No need to manually dump them, I already did that on 301W which uses IPQ8072A, and it's correct.
Its just 3 bits out of a whole 64 bit fuse and its blown as it contains open-loop voltages as well.
Its probably currently unused as every device has the reference open loop voltages for the 4 states burned during manufacture as well and they are primarily using those along with some quotients to set the voltage
My previous picture was during gigabit DL speedtes, PPPoE is that single core load but it fluctuates quite dramatically between 50-80%. It is also interesting that at the second test all cores are pushed to max speed while only one core has large load (maybe this SoC can only to that and no per core scaling?).
As far as I know, it can only scale all cores at the same time as it uses the same clock source and voltage source for all cores.
I have tried stressing one or more cores and it pretty much instantly scales to 1382 MHz, so its probably a scheduler limitation
god damn restarting on this is hard... why tftpboot now crash.....
@robimarko had to enable earlycon
wth ?
[ 0.178230] cpuidle: using governor menu
[ 0.190607] ASID allocator initialised with 65536 entries
[ 0.239240] Unable to handle kernel paging request at virtual address 0000a00000000000
[ 0.239287] Mem abort info:
[ 0.246057] ESR = 0x96000004
[ 0.248742] EC = 0x25: DABT (current EL), IL = 32 bits
[ 0.251871] SET = 0, FnV = 0
[ 0.257341] EA = 0, S1PTW = 0
[ 0.260199] FSC = 0x04: level 0 translation fault
[ 0.263242] Data abort info:
[ 0.268104] ISV = 0, ISS = 0x00000004
[ 0.271226] CM = 0, WnR = 0
[ 0.274784] [0000a00000000000] address between user and kernel address ranges
[ 0.277920] Internal error: Oops: 96000004 [#1] SMP
[ 0.285032] Modules linked in:
[ 0.289716] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.15.31 #0
[ 0.292846] Hardware name: Xiaomi AX3600 (DT)
[ 0.299006] pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 0.303264] pc : clk_core_get_parent_by_index+0x68/0xec
[ 0.310031] lr : __clk_register+0x1d8/0x820
[ 0.315238] sp : ffffffc00a02b7d0
[ 0.319402] x29: ffffffc00a02b7d0 x28: 0000000000000000 x27: 0000000000000040
[ 0.322882] x26: 0000000000000002 x25: 0000000000000000 x24: ffffff8003783e80
[ 0.330001] x23: ffffff8003783ed0 x22: ffffff8003783f00 x21: ffffff8003783ea8
[ 0.337119] x20: 0000000000000028 x19: ffffff8003785200 x18: 0000000000000020
[ 0.344236] x17: 000000008ca698fd x16: 000000000158f0a9 x15: ffffff800375820a
[ 0.351355] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000006
[ 0.358472] x11: 0000000000000003 x10: 0101010101010101 x9 : 0000000000000000
[ 0.365591] x8 : 7f7f7f7f7f7f7f7f x7 : 6468626f5e626266 x6 : 17000a3a403c1b06
[ 0.372709] x5 : 061b3c403a0a0017 x4 : 0000000000000000 x3 : 0000000000000001
[ 0.379827] x2 : 0000a00000000000 x1 : 0000000000000001 x0 : ffffff8003785200
[ 0.386945] Call trace:
[ 0.394054] clk_core_get_parent_by_index+0x68/0xec
[ 0.396315] __clk_register+0x1d8/0x820
[ 0.401174] devm_clk_hw_register+0x5c/0xe0
[ 0.404994] devm_clk_register_regmap+0x44/0x8c
[ 0.409161] qcom_cc_really_probe+0x17c/0x1d0
[ 0.413675] gcc_ipq8074_probe+0xd4/0xf0
[ 0.418188] platform_probe+0x68/0xe0
[ 0.422180] really_probe.part.0+0x9c/0x30c
[ 0.425740] __driver_probe_device+0x98/0x144
[ 0.429733] driver_probe_device+0x44/0x11c
[ 0.434248] __device_attach_driver+0xb4/0x120
[ 0.438241] bus_for_each_drv+0x68/0xb0
[ 0.442753] __device_attach+0xb0/0x170
[ 0.446486] device_initial_probe+0x14/0x20
[ 0.450305] bus_probe_device+0x9c/0xa4
[ 0.454471] device_add+0x35c/0x834
[ 0.458291] of_device_add+0x54/0x64
[ 0.461764] of_platform_device_create_pdata+0xc0/0x100
[ 0.465585] of_platform_bus_create+0x114/0x370
[ 0.470532] of_platform_bus_create+0x15c/0x370
[ 0.475047] of_platform_populate+0x50/0xcc
[ 0.479560] of_platform_default_populate_init+0xa8/0xc8
[ 0.483730] do_one_initcall+0x50/0x1b0
[ 0.489281] kernel_init_freeable+0x234/0x29c
[ 0.492841] kernel_init+0x24/0x120
[ 0.497355] ret_from_fork+0x10/0x20
[ 0.500658] Code: d50323bf d65f03c0 f94002a2 b4000302 (f9400042)
[ 0.504485] ---[ end trace 83fb95b4111ff863 ]---
[ 0.510465] Kernel panic - not syncing: Oops: Fatal exception
[ 0.515155] SMP: stopping secondary CPUs
[ 0.520800] Rebooting in 1 seconds..
ok i'm totally missing some patch... as it looks like the error was already fixed...
Oh wow num_parents = 2 and parent_hws with only one entry... nice! (also why parent names instead of parent data???)
It was merged upstream recently and backported to 5.17, 5.16, 5.15.33, and 5.10 stable kernels.
I did use parent_data to fix this, but the upstream driver uses parent_names as it was added before parent_data was a thing
1 Like
remember me the change to do in dts to make the first nss core boot correctly?
None, fixed regulator support must be enabled in the kernel config
1 Like
just found it CONFIG_REGULATOR_FIXED_VOLTAGE=y
majestic start... well problem is that i have to go so rip any debugging...
Ahh, beatifull EINVAL errors, basically meaning that anything can be wrong
let's play a game...
if it's this i will swear...
at least it seems message are sent...
aaand it's stuck there... ath11k firmware not compatible with the current nss firmware?
(should we check if it's not caused by dma? MHHHH)
Nah, doubt it, its the same FW they use.
Can you push your WIP somewhere so I can take a peak?
sure only hack i have currently is that mac80211 compile nss support by default... had some problem with recursive dependency...
Anway the problem is that nss doesn't send the ACK after the init step. nss.c function ath11k_nss_init
Fun part is that anything can be the fault for ACK not arriving
They do the cpu steeping to consume less electricity and generate less heat, so there's always a small trade off by design, like the time it takes to change step.
I'm thinking that P=U*I, so only when CPU load increases, I (current) increases, but if you keep U lower, you consume less power and generate less heat, whatever your cpu load is.
So it makes sense for them to be in a lower step with cpu at ~83%.
If you measure power consumption with a mains power meter using performance gov, I bet you only see a very small difference in P when CPU is idle, because I (current) will be low with a idle CPU. You need to do the same with all cores load, to know the max power consumption.
Maybe comparing the iperf3 speed in real test, will show if it makes a difference in having performance or not.
As you used performance gov before, did you found any performance difference (without looking at cpu load)?
If it makes a real difference (I don't know if it does) and power consumption is not much higher (needs to be measured), I would use it, like you did. As there are no other limiting factors (you said heat is not a problem).
on the nss part no error are printed(or they are silenced)
Scared that it could be dma not functioning correctly? But in theory that should be an ""easy fix" just swap the patch.