ChanServ changed the topic of #lima to: Development channel for open source lima driver for ARM Mali4** GPUs - Kernel driver has landed in mainline, userspace driver is part of mesa - Logs at https://oftc.irclog.whitequark.org/lima/
camus1 has joined #lima
camus has quit [Ping timeout: 480 seconds]
camus has joined #lima
chewitt has joined #lima
camus1 has quit [Ping timeout: 480 seconds]
chewitt has quit [Quit: Zzz..]
chewitt has joined #lima
camus1 has joined #lima
camus has quit [Read error: Connection reset by peer]
chewitt has quit [Ping timeout: 480 seconds]
camus has joined #lima
camus1 has quit [Ping timeout: 480 seconds]
camus1 has joined #lima
camus has quit [Ping timeout: 480 seconds]
camus1 has quit [Remote host closed the connection]
camus has quit [Read error: Connection reset by peer]
adjtm has quit [Remote host closed the connection]
adjtm has joined #lima
camus has joined #lima
camus1 has quit [Ping timeout: 480 seconds]
<enunes>
anarsoul: sigh, these reports of things not working with likely broken dts/platform on less popular boards are becoming repetitive, I wonder if it would be a good idea to put something in our FAQ
<rellla>
enunes: yeah. but no howto :)
<rellla>
though i must admit, i'm not quite sure if https://pastebin.com/raw/FZRCrdNJ is really good ... the "regulator" line makes me nervous ...
camus1 has joined #lima
camus has quit [Remote host closed the connection]
drod has joined #lima
<anarsoul>
enunes: yeah, it probably makes sense
<anarsoul>
enunes: btw we don't have OPP table on majority of platforms :)
<anarsoul>
I think only H3 has it, and I saw some patches for RK3328 from tlwoerner
<anarsoul>
I can add it for A64
<jernej>
anarsoul: I added it for A64 not too long ago :)
<anarsoul>
oh, cool
<jernej>
only 2 points, though
<anarsoul>
that's fine as long as it has 432MHz
<jernej>
sure
<jernej>
should be in 5.16 iirc
<anarsoul>
jernej: looks like it's 3 points
<anarsoul>
I'm not sure if having 120MHz is a good idea though :)
<jernej>
hm.. true
<jernej>
I guess I copied points from bsp driver
<jernej>
it was long time ago...
<jernej>
well, you can submit fix, if you have a good reason :)
<anarsoul>
I'm fine with 120mhz as long as no one complains
<jernej>
I believe low point is good enough for rendering only now and then, like simple gui
<anarsoul>
jernej: if I understand correctly, we don't switch frequency in the middle of job, so if a massive job is submitted and GPU is running at 120MHz it may take a while
<anarsoul>
you can't do task switching in Utgard
<jernej>
oh, that wouldn't be too good
<jernej>
btw, do you know why lima works good with power management and panfrost often reports busy and thus doesn't allow to go to sleep?
<jernej>
it's quite annoying
<jernej>
is has something to do with task management?
<anarsoul>
jernej: sorry, no idea
<anarsoul>
well, I think I'm wrong about frequency switching
<anarsoul>
lima only reports when it's idle or busy, and it's up to devfreq to make decision
yann-kaelig has joined #lima
<yann-kaelig>
Hello. I have reported my issue with cubietruck https://gitlab.freedesktop.org/mesa/mesa/-/issues/5707 If someone is interested to participate to find and fix the issue I can find some time for this purpose. Of course there is no rush
<anarsoul>
yann-kaelig: it looks like it's an issue of particular board model
<anarsoul>
lima works fine on Allwinner A20 (e.g. in cubieboard 2)
<anarsoul>
so it's platform setup issue - something's wrong with clocks or with voltage regulators
<yann-kaelig>
I'm not the only one with this issue for this board, I found an old thread with the same symptom
<anarsoul>
you should probably report it to #linux-sunxi
<yann-kaelig>
yes, on cubieboard2 there is no such issue
<yann-kaelig>
I was week ago on linux-sunix, I have done what I could to report the issue, I can mistaken but the answer was it's a lima issue. I'm in a loop ^^
<anarsoul>
yann-kaelig: it's not lima issue, your system just isn't stable
<anarsoul>
so it's either clocks or voltage regulators
<anarsoul>
jernej: what's the status of R40 in mainline?
<yann-kaelig>
Ok, so knowing about that, is there some software that I can use to manipulate clocks and voltage regulators ?
<anarsoul>
regulators are described in dts
<jernej>
anarsoul: pretty decent I would say
<anarsoul>
jernej: what's up with dram frequency?
<anarsoul>
:)
<jernej>
I'm running LE on R40, so works well
<anarsoul>
looks like it's running at 408mhz in mainline, but 960mhz on vendor kernel/u-boot
<yann-kaelig>
which kernel configuration is missing that I do not have the /sys/kernel/debug/clk folder on the linux 3.4.61 ? and DEBUG_FS is set
<jernej>
mount it manually
<jernej>
I mean debugfs
<yann-kaelig>
it is mounted "none on sys/kernel/debug debugfs" I only miss the clk folder
<anarsoul>
jernej: yes
<anarsoul>
jernej: mali400 is really starved on memory bandwidth, so downclocking memory may have huge performance impact
<anarsoul>
I don't think that you can starve DE, so it'll get its share, and the CPU and GPU will have to deal with what's left
<jernej>
that's what mbus settings are for
<anarsoul>
on A64 with LPDDR3 overclocked to 620MHz (vs default 576) and it resulted in nice FPS boost in q3a
<anarsoul>
*624
<jernej>
well, it could really be DRAM clock then
camus has joined #lima
<anarsoul>
bus clock dividers patch also looks suspicious
camus1 has quit [Ping timeout: 480 seconds]
<yann-kaelig>
ok, so I was curious to test armbian buster with a kernel 5.10.x and xfce and for my surprise it's working and I can get XFCE DE. This is really interesting because something is done to make it work
<yann-kaelig>
Tomorrow I will test kmscube on it.
<yann-kaelig>
So armbian has some fix somewhere in some code that is not available on upstream ?
<jernej>
sure, it's full of downstream patches
<jernej>
if you find one, please tell me
<yann-kaelig>
ok, so I got the idea to copy all the /boot and kernel modules directories to my ArchLinux installation. With a little fix about the rootdev UUID, the system boot but kmscube doesn't work. I have to test it on armbian too, but right now it's really strange.
<yann-kaelig>
jernej: downstream patches from what project ?
<anarsoul>
from armbian
<yann-kaelig>
I suppose that if it was an issue from the kernel side it should work, so it's somewhere else, maybe mesa
<jernej>
I'm pretty sure Armbian doesn't mess with mesa, so it must be one of the kernel patches or a bit less likely U-Boot patch
<yann-kaelig>
I did not have tested uboot, that an idea. Let see if I can get the armbian uboot or maybe dd the armbian spl to the other sdcard
<anarsoul>
I'd bet on either dts or u-boot
drod has quit [Remote host closed the connection]
<yann-kaelig>
doesn't work, nothign has changed with the armbian spl.bin. Amazing! ^^
camus1 has joined #lima
camus has quit [Ping timeout: 480 seconds]
<anarsoul>
yann-kaelig: it's not only spl, you need to use whole u-boot image
<anarsoul>
I think SPL bring up only the hardware necessary to load secondary bootloader (i.e. u-boot proper)
<yann-kaelig>
anarsoul: well, obviously there is something I missed about uboot. What is this u-boot image you'r talking ?
<anarsoul>
in ARM world that's essentially an equivalent of BIOS on x86 platforms
<anarsoul>
on sunxi it usually lives in boot media, i.e. SD, eMMC, SPI flash