Dragon-Hatcher has left #linux-sunxi [#linux-sunxi]
Dragon-Hatcher has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
Daanct12 has joined #linux-sunxi
Dragon-Hatcher has quit [Remote host closed the connection]
vagrantc has quit [Quit: leaving]
digetx has quit [Ping timeout: 480 seconds]
ftg has quit [Read error: Connection reset by peer]
digetx has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
<tokyovigilante>
I'm working on v6 of the DE33 patch set, and looking at Dmitry's feedback about the color/encoding state being stored in sunxi_engine. I had thought about putting it in the mixer config (since it is mixer configuration after all) but this struct is const, should I just add the two flags (color format and encoding) to the mixer object directly?
JohnDoe_71Rus has joined #linux-sunxi
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
hentai has quit [Quit: SIGTERM]
smaeul has quit [Ping timeout: 480 seconds]
smaeul has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
hazardchem has quit [Read error: Connection reset by peer]
hazardchem has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
bauen1 has quit [Ping timeout: 480 seconds]
bauen1 has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
<apritzel>
Jookia: did you do any work lately on U-Boot video support, for new SoCs? I am about to rework the existing DE2 support to be proper DT driven, starting with the clocks
<apritzel>
that should then automatically cover quite some differences between the A64 generation and newer SoCs, including the H6 and T113
<Jookia>
apritzel: No work lately, though I'll be rebasing my work on U-Boot 2025.04 soon and trying to fix the USB. The patches are basically the same as on the list
<Jookia>
Today I'm setting the goal of submitting the thermal patch
<Jookia>
(for the kernel)
<Jookia>
I have some patches in the kernel mailing list I haven't followed up on which is super bad of me so I have to get those done sometime soon :)
<Jookia>
But IIRC yes the most painful part of the DE2 support was clocking I think
<Jookia>
The most intrusive code was for the HDMI output which had to bypass a lot of existing clocking code
<Jookia>
But I haven't actually tested the HDMI out, only written it
<Jookia>
The code currently mixes in logic to set a set of clocks with different related rates each which isn't great
<apritzel>
ah, thanks. And yeah, I was looking at this series, and saw that the clocks were quite some part of it
<Jookia>
moving the clocking out to some soc-specific functions would really help IMHO
<apritzel>
the mux/tcon decision should be derived from the DT as well. I don't see existing code (DT graph traversal) in U-Boot for that, but we can short-cut it, I think, by explicitly following phandles and stuff
<apritzel>
yes, I introduced proper clock_set_rate() support now. It's in its beginning, but looks nice, and is not that big, since we just need a few video clocks
<Jookia>
Oh nice
apritzel has quit [Ping timeout: 480 seconds]
naoki has quit [Ping timeout: 480 seconds]
naoki has joined #linux-sunxi
BroderTuck has joined #linux-sunxi
BroderTuck has left #linux-sunxi [#linux-sunxi]
BroderTuck has joined #linux-sunxi
<BroderTuck>
Am I seeing this right? Schematics 4 opi 4a now available
BroderTuck has quit [Remote host closed the connection]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
bauen1 has joined #linux-sunxi
Daanct12 has quit [Quit: WeeChat 4.5.1]
digetx has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
<apritzel>
BroderTuck: ah, yes indeed, thanks for the heads up!
digetx has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 480 seconds]
ftg has joined #linux-sunxi
naoki has quit []
BroderTuck has joined #linux-sunxi
<BroderTuck>
apritzel: Now we just need someone with "HK1 RBOX H8X" or "R69 Plus", altho those boxes are less useful at the moment without working USB3 support (they both only have one USB2 port)
bauen1 has quit [Ping timeout: 480 seconds]
<apritzel>
I just see that there is some USB 2.0 PHY embedded in the USB3.0 register frame, which means we might be able to use that port in USB2.0 mode only
<apritzel>
still would need to use an xHCI driver, as the USB 2.0 controller is embedded in there, but maybe we can skip the whole USB3.0 PHY and mux part
<apritzel>
that's probably not really worthwhile on most of those boards, but might become interesting for the Radxa board, where we might be able to use that USB3.0 port in 2.0 mode, even alongside PCIe
<apritzel>
gamiee: I just see that the T527 manual describe two separate GMACs: GMAC0 is the traditional GMAC, probably still compatible, but GMAC1 is a "GMAC200", which uses a completely different DMA descriptor format
<apritzel>
that's a ring buffer, where the descriptors seem to be consecutive in memory, so no linked list like chaining anymore
<apritzel>
does that sound familiar to anyone? Maybe this kind of DWMAC is already supported by the kernel?
<apritzel>
sorry, this ^^^ was meant for warpme
<BroderTuck>
Couldn't see a single join/leave message for warpme though all of february...
<BroderTuck>
*through
<wens>
apritzel: IIRC actual DWMAC supports both chained and ring descriptors, just that the sun8i variant only did one
<wens>
at least that's my impression based on the driver
<gamiee>
hm
<gamiee>
:D
<loki666>
apritzel: do you have a branch for the modified bl31.bin for a133p ? Would be easier for me to use.
<loki666>
Or a patches series
bauen1 has joined #linux-sunxi
wingrime-ww has joined #linux-sunxi
dsimic is now known as Guest9226
dsimic has joined #linux-sunxi
Guest9226 has quit [Ping timeout: 480 seconds]
<apritzel>
loki666: there is not much useful in there: it detects and reports the A133, which is purely cosmetic, and it deals with the PMIC, which is optional and unrelated to the SMP issue
apritzel has quit [Ping timeout: 480 seconds]
<loki666>
ok... I was wondering, do we need the CPU regulator in u-boot ?
aggi has quit [Remote host closed the connection]
aggi has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Quasar 5.2.6, revision: 5.2.6+git-7609-afed1336e, build type: debug, sources date: 20160102, built on: 2024-12-18 20:43:05 UTC 5.2.6+git-7609-]
apritzel has joined #linux-sunxi
<apritzel>
loki666: typically we do, because we increase the CPU frequency, which often requires to increase the voltage
<apritzel>
loki666: but that depends on the default voltage the regulator is providing initially, and the CPU frequency that you request
<apritzel>
so you could pick a frequency that works fine with the voltage on reset, and use that
<loki666>
Where is that config set ? In u-boot config ? So far it seems to works fine, but probably because u-boot doesn't try to change the default freq
<apritzel>
loki666: CONFIG_SYS_CLK_FREQ sets the CPU frequency, it defaults to 1008 MHz for the H616, but you can override this in your defconfig
<loki666>
Ah ok thanks
<apritzel>
ah, wait, that's A133 you are talking about, right?
<loki666>
Yes
<apritzel>
it's the same 1008 MHz (in my branch)
<apritzel>
for the three already defined speed bins, that requires between 950 and 1020 mV
<apritzel>
loki666: do you know what the voltage at reset is, for that regulator? That's some discrete I2C controlled regulator, just for the CPU voltage in your case, right? Or do I mix this up?
<loki666>
looks like it's not define in my u-boot config, so I guess it default to something in u-boot code
<loki666>
yes there is a dedicated regulator for cpus (a TCS4838) which seems compatible with silergy,syr827
<loki666>
at least in kernel, don't know if that driver exist for u-boot
<loki666>
I'm not sure yet what's the voltage at reset
bauen1 has quit [Ping timeout: 480 seconds]
<apritzel>
it must be at least 900mV, that seems to be the lowest voltage supported by the core. 816MHz should work then, set that in your defconfig
<loki666>
ok thanks
<apritzel>
there is fan53555.c in U-Boot, but would not work in the SPL, where we need it
<apritzel>
if you have DVFS support in the kernel, that's probably enough, it would run at 816MHz till DVFS kicks in
<loki666>
that's the idea yes
<apritzel>
if not, then copy drivers/power/axp152.c and adjust it
<apritzel>
but not sure that's worth it, 816 MHz doesn't sound too bad for boot
<apritzel>
from staring at your dump and the code I'd guess it's 0b001, so indeed a new bin
<apritzel>
yes, for instance
<apritzel>
looks like it's ((0x10a9 >> 12) & 0xf), which would be 0x1
<loki666>
ok thanks
<loki666>
and it looks like the cpu reset frequency is 1008MhZ
<loki666>
[ 17.281815] cpufreq: cpufreq_online: CPU0: Running at unlisted initial frequency: 1008000 kHz, changing to: 1200000 kHz
<apritzel>
and you would need ranges, since tailoring them to the constraints of that particular regulator would break abstraction: we want to support the SoC on any regulator
<loki666>
should I use that in uboot too ?
<apritzel>
if you don't touch the regulator in the SPL, you should use 816 MHz, everything is asking for trouble
<apritzel>
everything *else* ...
<loki666>
ok, which tolerance do I allow around BSP values ? for the ranges ?
<apritzel>
look at the H6 CPU OPPs, they use the "three entries" version, which the binding defines as: <target min max>
<apritzel>
where max is effectively always the same max voltage, and target and min are the same value
<apritzel>
if you use that, the code should automatically choose the next voltage fitting in there (I think)
<loki666>
ok I see
<apritzel>
and for frequencies that only a few bins support, check the H616 OPPs, the key here is opp-supported-hw, which is a mask for speed bins
<apritzel>
so all four would be 0xf, just the A133P 0x8, for instance
<apritzel>
so you need to combine the ranges from H6 and opp-supported-hw from H616, but the good news is that the code should be all there already, it's just "configuration" in the driver
<loki666>
ok, so target = min = bsp value, max = max value of max BSP freq
<apritzel>
exactly
<loki666>
ok I'll patch that, thanks for the help
<apritzel>
that was added for boards without an adjustable regulator, so that even a single fixed voltage would allow changing at least the frequency
<apritzel>
it's less power saving, since "P ~ V^2 * f", but better than nothing, and allows to reach the highest frequency
<loki666>
bsp max freq max voltage is 1187500, should I round that up to 1.2v ?
<apritzel>
never round voltages up, please
<loki666>
ok
<apritzel>
is there a datasheet for the A133P, specifically? That should list the maximum CPU core voltage
<loki666>
there is one, I'll dig
<loki666>
well there is one for A133
digetx has quit [Ping timeout: 480 seconds]
digetx has joined #linux-sunxi
<apritzel>
this one says 1200mV, but I wonder if the A133P is different here, since it can go to higher frequencies
<apritzel>
so I think it's safe to put 1.2V in then, and also please the regulator to that voltage
digetx has quit [Quit: No Ping reply in 180 seconds.]
digetx has joined #linux-sunxi
<Jookia>
can someone give me some motivation to update my kernel and re-submit or re-do some patches i've sent :)
<apritzel>
if you don't do it, no one will. And if no one does it, the situation will not improve
<apritzel>
not very good pep talk, admittedly
<loki666>
lol
<apritzel>
if people in the past wouldn't have done it, we wouldn't have all the mainline code to build on now