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/
camus has joined #lima
megi1 has quit []
megi has joined #lima
camus1 has joined #lima
camus has quit [Read error: Connection reset by peer]
camus has joined #lima
camus1 has quit [Read error: Connection reset by peer]
camus1 has joined #lima
camus 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]
<rellla> jernej: sorry for offtopic... is it possible that the libreelec allwinner patches don't apply cleanly on LE's current kernel version? how do nightly builds succeed then?
cwabbott has quit [Ping timeout: 480 seconds]
robher_ has joined #lima
narmstrong has quit [Ping timeout: 480 seconds]
robher has quit [Ping timeout: 480 seconds]
daniels has quit [Ping timeout: 480 seconds]
jstultz has quit [Ping timeout: 480 seconds]
daniels has joined #lima
cwabbott has joined #lima
narmstrong has joined #lima
jstultz has joined #lima
camus has joined #lima
camus1 has quit [Ping timeout: 480 seconds]
camus1 has joined #lima
camus has quit [Ping timeout: 480 seconds]
yann-kaelig has joined #lima
<yann-kaelig> hello
<yann-kaelig> I wonder if I should report my HDMI issue on my cubietruck
<yann-kaelig> I'm compiling a new kernel from the 5.14.x release, maybe it could help
<enunes> yann-kaelig: hey, so based on your report from earlier, it should really not report those errors with something as simple as kmscube and a soc like the A20
<enunes> though it doesn't seem much like a problem in lima at a glance, I would suspect more of platform setup, clocks etc in the dts for that particular platform
<yann-kaelig> enunes: Hello. Well in this case building a most recent kernel could help ? Maybe there is an issue with the dts from the kernel 5.11.2
<enunes> I'm not sure if that will help, I think as for the kernel itself 5.11 should be fine for getting something like kmscube working
<enunes> it might be easier to check for changes in the kernel git history for the platform and see if it is worth it
<yann-kaelig> ok, I understand. With my knowledge as I would say an experimented user but not a dev, do you have some debug tools that I could be able to use to start debugging. I don't know how I have to proceed now
camus has joined #lima
camus1 has quit [Ping timeout: 480 seconds]
<enunes> yann-kaelig: I'm not sure there is an easy and straightforward way to debug your issue. if you dont want to do some low level debugging I would suggest to try another distribution that may have it working and compare against that to figure it out
<yann-kaelig> ok, thx. Well I'm going with my knowledge so testing weston with differents options, fbdev-backend works. With drm-backend I found that the first time it used the drm-device=card0 and now without any idea why, it's use the card1.
<enunes> honestly I think if you cant run kmscube, trying anything else is not going to be very helpful
<jernej> rellla: it is possible that patches don't apply with "git am" but they do with patch -p1. If in doubt, you can run "PROJECT=Allwinner ARCH=arm DEVICE=H3 ./tools/refresh-patches linux" to "refresh" them, so git am is happy again (DEVICE isn't important, since all kernel patches are common).
<jernej> rellla: there is #libreelec channel at libera, I suggest to discuss further there
<rellla> jernej: thanks. i temporarily went back to the kernel 5.14 commit - that worked, but i think i will try what you suggested
camus1 has joined #lima
camus has quit [Ping timeout: 480 seconds]
wwilly has joined #lima
drod has joined #lima
yann-kaelig has left #lima [#lima]
adjtm is now known as Guest6532
adjtm has joined #lima
Guest6532 has quit [Ping timeout: 480 seconds]
wwilly has quit [Quit: Leaving]
camus has joined #lima
camus1 has quit [Read error: Connection reset by peer]
<anarsoul> rellla: enunes: can you please take a look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13830 ?
camus1 has joined #lima
camus has quit [Read error: Connection reset by peer]
<rellla> anarsoul: will do tomorrow
<anarsoul> thanks
camus has joined #lima
yann-kaelig has joined #lima
<yann-kaelig> hello again. Well I have something else after I run gbm-surface https://postimg.cc/WqR0sHWt
camus1 has quit [Ping timeout: 480 seconds]
<yann-kaelig> An old issue on lima gitlab seems to be similar as mine https://gitlab.freedesktop.org/lima/linux/-/issues/22
<yann-kaelig> on cubietruck too
<anarsoul> yann-kaelig: could be an issue with clocks or power. Can you share full dmesg output?
<yann-kaelig> anarsoul: ok, 2s
<yann-kaelig> anarsoul: https://dpaste.com/97CTE5DAT
camus1 has joined #lima
camus has quit [Ping timeout: 480 seconds]
<yann-kaelig> could it be something related with this issue ? https://dpaste.com/97CTE5DAT#line-466
<enunes> yann-kaelig: [ 19.286233] WARNING: CPU: 1 PID: 214 at drivers/base/platform.c:469 platform_get_irq_byname+0xfc/0x104 [ 19.286498] 0 is an invalid IRQ number
<anarsoul> yann-kaelig: well, I don't see anything wrong with lima
<anarsoul> maybe it's another hardware bug from allwinner
<anarsoul> enunes: that's from sun4i_gpadc_probe, not related to lima
<enunes> oh well, seemed like from sun4i-drm at a glance
<enunes> anarsoul: I like the solution to mark the block as end instead of just the instruction, I think that could help with other problems I had in the past as well
<enunes> just reviewed the code, looks good to me, just posted a set of nitpicks
<anarsoul> thanks
<anarsoul> enunes: I'd prefer to keep assert(clause && text) construction, it would really help with debugging if we had it everywhere in lima
<enunes> anarsoul: sure, I'm not going to insist on that one :)
<anarsoul> yann-kaelig: can you try to get blob working on your board?
<yann-kaelig> anarsoul: how can I do that ? Do you have material that I could follow. By the way I have a linux linaro distribution installed on the nand and it's working
<anarsoul> nope, I don't have any manuals
<anarsoul> it looks like a platform issue to me, since even kmscube doesn't work for you
<anarsoul> you can try asking #linux-sunxi for help
drod has quit [Remote host closed the connection]
<anarsoul> yann-kaelig: bus clock seems a bit high to me, but I'm not sure what it should be on A20
<anarsoul> e.g. on A64 bus clock is 200MHz
<anarsoul> I doubt that A20 that uses the same 40nm process as A64 has 50% higher bus clock :)
<anarsoul> so yeah, if you can get blob working on the same setup (at least the same bootloader and kernel), you'll likely see the same issue
<anarsoul> yann-kaelig: can you also share output of "cat /sys/kernel/debug/clk/clk_summary" on your linaro distribution?
<anarsoul> and dmesg
<yann-kaelig> yes I can, no problem
<yann-kaelig> I can do whatever you want if that can help to fix the issue :)
camus has joined #lima
camus1 has quit [Ping timeout: 480 seconds]
Viciouss has quit [Ping timeout: 480 seconds]
<yann-kaelig> anarsoul: https://dpaste.com/GLB4BWARW but there is no /sys/kernel/debug/clk/clk_summary. Also I took a lot of info from /proc/files
<anarsoul> yann-kaelig: mali400 clock is set to 312mhz in vendor kernel
<anarsoul> while it's set to 384 in mainline
<anarsoul> likely that's an issue
<anarsoul> you can try patching your dts
<anarsoul> yann-kaelig: you can decompile your dtb with `dtc -I dtb -O dts sun7i-a20-cubietruck.dtb -o sun7i-a20-cubietruck.dts`, patch it (just change 384000000 to 312000000) and compile it back: `dtc -I dts -O dtb sun7i-a20-cubietruck.dts -o sun7i-a20-cubietruck.dtb`
<yann-kaelig> anarsoul: I do not have such value as 384000000.
<yann-kaelig> Not sure if its the right place, inside cpu { I have clocks = <0x02 0x14>
camus1 has joined #lima
camus has quit [Remote host closed the connection]
<anarsoul> you should have assigned-clock-rates somewhere in there
<yann-kaelig> yes > assigned-clock-rates = <0x16e36000>;
<anarsoul> which is 384000000 in decimal
<anarsoul> :)
<yann-kaelig> yes I just understand the thing
<anarsoul> change it 0x16e36000 to 312000000
<yann-kaelig> anarsoul: where did you find the clock information from dmesg, I can not find it ... want to be sure my change has been applied as expected
<anarsoul> dmesg | grep lima
<anarsoul> see lima 1c40000.gpu: mod rate = 384000000 in your original dmesg
<anarsoul> you want mod rate to be 312000000 with the change
<anarsoul> yeah, it's 312MHz now
<anarsoul> try kmscube?
<yann-kaelig> :)
<yann-kaelig> ok
Viciouss has joined #lima