ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #linux-sunxi
diego71 has joined #linux-sunxi
aggi_ has joined #linux-sunxi
aggi_ has quit []
aggi_ has joined #linux-sunxi
aggi_ has quit []
<loki666>
jernej not on 6.12/6.13 with H700 (installed on about 650 units)
aggi has quit [Ping timeout: 480 seconds]
<jernej>
well, you would only see it if you have kasan enabled, which is not by default, because it's meant as debugging tool and would slow down operations
kepstin has quit [Remote host closed the connection]
aggi has joined #linux-sunxi
gsz has joined #linux-sunxi
<jernej>
ah, no wonder, DT size says value is 2 bytes, driver size uses 4 bytes
kepstin has joined #linux-sunxi
<jernej>
so, did anyone has issues with speed grade and DVFS on H616? :)
<jernej>
loki666: this fixes issue on H616 for me, but I'm not sure if it's general enough fix to be included upstream: https://paste.c-net.org/MeasuredUsing
Schimsalabim has quit [Read error: Connection reset by peer]
<loki666>
Well no know issues with speedgrade, I can test your patch
Schimsalabim has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
jernej: haven't seen that, but then I typically don't have KASAN enabled
diego71_ has joined #linux-sunxi
diego71 has quit [Ping timeout: 480 seconds]
<apritzel>
IIRC in general the size of MMIO area is not very strictly enforced, at least not on that granularity (more on a page level)
<apritzel>
nvmem_cell_read() returns an optional length field, we should use that to set the limit, maybe using a union? But that would break endianess
<apritzel>
jernej: anyway good catch, should probably enable more checking features in my config
<apritzel>
on the H6 the DT says 4 bytes, though the info we want is in bits [7:5], A100 needs bits [15:12], so technically 16 bits would suffice
diego71 has joined #linux-sunxi
diego71_ has quit [Ping timeout: 480 seconds]
<loki666>
apritzel: btw I still have a patch for the A133P speed bin and OPPs, but I guess without a board device tree, it will not be accepted
<loki666>
my zero28 device tree is still a big mess
<apritzel>
loki666: yeah, a proper A100/A133 DT is indeed missing from the tree. I have something for my Liontron board, though I need to double check some PMIC rails first
<apritzel>
but hopefully I can post something soon, and then we can push for the remaining A133 patches
<jernej>
apritzel: yeah, using length would be best. I also noticed that it relies on little endian CPU. I guess using le32_to_cpu() or le16_to_cpu() would make sense.
<jernej>
apritzel: is it possible for my H616 U-Boot fixes to be merged for v2025.04?
<apritzel>
jernej: you mean both eMMC and DRAM? I was internally debating that, as it's technically not a regression (those things never worked before properly)
<apritzel>
jernej: are you relying on U-Boot release tags?
<apritzel>
There is the U-Boot next branch, and I wanted to push it in there in the next days
<jernej>
Yes, I mean DRAM and MMC.
<apritzel>
the release is in about three weeks from now, and I am a bit afraid of last minute regressions
<jernej>
I understand that for MMC, but DRAM worked, just not stable?
<jernej>
anyway, just asking as I never fully understood what's acceptable for -rc and what not.
<jernej>
It's said, that U-Boot isn't as strict Linux, right?
<apritzel>
yes, but the code changes quite a bit, so there is the theoretical chance of things getting worse
<apritzel>
yes, but ...
<apritzel>
getting changes into early -rcs still is fairly easy, but we are at -rc4 already, so there will an -rc5 and then the release, I think
<apritzel>
so technically it should only be regression fixes at this point, I think
<apritzel>
jernej: are you using tagged releases for LibreELEC images?
<apritzel>
the code would be in master in about a month regardless, so that wouldn't make a big difference
<jernej>
apritzel: please don't misunderstand, I don't mind waiting one more cycle
<apritzel>
but I can surely be talked into pushing it into 2025.04, still. Especially the DRAM fixes would have a point
<jernej>
I'm just trying to understand decisions
<apritzel>
actually I was debating this myself internally ;-)
<jernej>
LE uses tagged releases, yes, but we can easily add extra patches
<jernej>
besides, H616 release was never done due to DE3.3 issues
<apritzel>
I might ask on the list for guidance
<jernej>
but I've noticed that H6 needs same DRAM patches :)
<jernej>
I've already added it to LE
<jernej>
so ideally, in next cycle, I would extract common routines and shared them between H6, H616 and later with A523
<apritzel>
jernej: that would indeed be very welcome!
<apritzel>
and with next cycle you mean v2025.07? The cut-off date for that would be around Easter
<jernej>
yes
<apritzel>
so there are no official H616 releases for LibreELEC, due to the missing upstream Linux HDMI support? So it's all a bit of Wild West anyway?
<jernej>
eh, we never shy away from large patchsets :)
<jernej>
(as long as there is someone who takes care for them and tries to upstream them)
<loki666>
tokyovigilante said he'd work on hdmi after de33 initial patch
<jernej>
loki666: HDMI is trivial in comparsion to DE3.3
<apritzel>
as I have only H616 devices with HDMI, but none with LCD, I'd appreciate that ;-)
<jernej>
apritzel: main issue why there is no H616 support is non-working YUV scaling support
<apritzel>
so if a posted patchset would contain HDMI support, I could actually test that
<apritzel>
that's the DE3.3 issue you mentioned before that blocks the current patchset from being merged easily?
<jernej>
no, this is second issue, but it can be addressed later
<jernej>
since it's internal to the driver and needs some aspects to be redesigned
<jernej>
YUV scaler is a bit picky when registers are written, but other units are sensitive too, just much less
<jernej>
so all mixer units must have shadow registers which get applied at vblank
<jernej>
apritzel: yeah, I consider need to split, writing commit messaged, DT bindings and overall compatible string check to be WIP
<apritzel>
loki666: I have proper PMIC support and general enablement ready, so it's just CPU bring up that's missing
<apritzel>
jernej: btw: I reworked the PMIC support in TF-A, it should be child's play to use that for another SoC, and even a different PMIC
<loki666>
apritzel: you have a branch patch for that ?
<apritzel>
loki666: not yet, but will hopefully post something later today. For now you can ignore the PMIC, that's just needed for power-off, really, and the "general enablement" is like trivial reporting that it's an A133
<apritzel>
loki666: so if you just get it to work for now by hacking the H6 code that would be very much appreciated
<loki666>
h6 is the sunxi_cpucfg_has_per_cluster_regs() == true branch ? right
<apritzel>
loki666: yes
<jernej>
apritzel: please include me in cc for that
<apritzel>
jernej: sure, I need to rely on your +1 for that anyway, I guess ;-)
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
warpme has quit []
ftg has joined #linux-sunxi
arti has quit []
arti has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
gsz has quit [Ping timeout: 480 seconds]
psydroid|2 has joined #linux-sunxi
psydroid has quit [Ping timeout: 480 seconds]
cnxsoft has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<wens>
seems that my first PR hasn't been taken yet
<wens>
apritzel: regarding nvmem, doesn't the binding also allow specifying which bits and bit length of the nvmem cell?
apritzel has joined #linux-sunxi
<apritzel>
wens: you mean this "bits" property? Didn't know about it, but I guess putting that in DTs now would break older kernels, since the sun50i driver would then mask again?
apritzel has quit [Ping timeout: 480 seconds]
<wens>
apritzel: yeah, but you can probably do it for the newer SoCs, and adjust (skip shift & mask) in the driver accordingly
aggi has quit [Remote host closed the connection]
aggi has joined #linux-sunxi
hazardchem has quit [Read error: Connection reset by peer]