eballetbo has quit [Quit: Connection closed for inactivity]
vagrantc has quit [Quit: leaving]
matthias_bgg has quit [Ping timeout: 268 seconds]
matthias_bgg has joined #linux-rockchip
clarity has quit [Ping timeout: 260 seconds]
clarity has joined #linux-rockchip
vagrantc has joined #linux-rockchip
vagrantc has quit [Quit: leaving]
lorenzb has quit [Ping timeout: 256 seconds]
naoki1 has joined #linux-rockchip
naoki has quit [Ping timeout: 264 seconds]
naoki1 is now known as naoki
matthias_bgg has quit [Ping timeout: 255 seconds]
matthias_bgg has joined #linux-rockchip
naoki has quit [Quit: naoki]
naoki has joined #linux-rockchip
dliviu has quit [Ping timeout: 268 seconds]
dliviu has joined #linux-rockchip
raster has joined #linux-rockchip
eballetbo has joined #linux-rockchip
warpme has joined #linux-rockchip
ldevulder has quit [Quit: Leaving]
ldevulder has joined #linux-rockchip
stikonas has quit [Ping timeout: 255 seconds]
naoki has quit [Ping timeout: 246 seconds]
naoki has joined #linux-rockchip
naoki has quit [Remote host closed the connection]
naoki has joined #linux-rockchip
naoki has quit [Quit: naoki]
naoki has joined #linux-rockchip
naoki has quit [Client Quit]
lorenzb has joined #linux-rockchip
dsimic has quit [Ping timeout: 272 seconds]
dsimic has joined #linux-rockchip
psydroid has joined #linux-rockchip
mps has quit [Ping timeout: 260 seconds]
mps has joined #linux-rockchip
<linkmauve>
I’ve been testing Weston on the rk3568, but I get a weird bug where surfaces often are partially displayed, per-frame, as if only the top of the surface would get displayed and the bottom keeps the contents of the buffer below.
<linkmauve>
It happens even for surfaces which can and are scanned out, in which case they quickly alternate between being composited in a half-finished state, and being scanned out.
<linkmauve>
I’ve been testing Gstreamer, Alacritty, Epiphany, all of them exhibit this bug.
<linkmauve>
I’m not too sure where the bug happens, maybe something like Panfrost not doing the right synchronisation in its dmabuf export or import?
<linkmauve>
Is this something you see on other Rockchip platforms, or maybe on other Panfrost GPUs?
<linkmauve>
I also found that gst-play-1.0 uses a non-opaque format even though its contents are fully opaque…
Stat_headcrabed has joined #linux-rockchip
<diederik>
do you get the same issue(s) when using sway?
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<linkmauve>
I believe Sway doesn’t support scanout of windowed surfaces.
warpme has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Stat_headcrabed has quit [Quit: Stat_headcrabed]
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
ungeskriptet has joined #linux-rockchip
ungeskriptet6 has joined #linux-rockchip
Stat_headcrabed has joined #linux-rockchip
warpme has joined #linux-rockchip
ungeskriptet has quit [Ping timeout: 260 seconds]
ungeskriptet6 is now known as ungeskriptet
Stat_headcrabed has quit [Quit: Stat_headcrabed]
jakllsch has quit [Ping timeout: 260 seconds]
jakllsch has joined #linux-rockchip
Stat_headcrabed has joined #linux-rockchip
Stat_headcrabed has quit [Quit: Stat_headcrabed]
raster has quit [Quit: Gettin' stinky!]
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
ungeskriptet has joined #linux-rockchip
<macromorgan>
Kwiboo: I can't test the 12GB device anymore... I bricked it last night trying to define all the GPIOs without schematics :-(
<macromorgan>
Kwiboo: For dram_init_banksize() should we instead be using the values from the atags to create our RAM banks instead of simply hard coding it as 0x200000 to 0xeffffff (whatever) and then a second bank for the rest?
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Stat_headcrabed has joined #linux-rockchip
ungeskriptet9 has joined #linux-rockchip
ungeskriptet has quit [Ping timeout: 240 seconds]
ungeskriptet9 is now known as ungeskriptet
<qschulz>
macromorgan: that's what I would do yes
<qschulz>
we probably need the fallback if for some reason the atags is non-existent or malformed
<macromorgan>
hmm... is there anything special about that 8GB device that we can take into account? Older RAM init code perhaps?
<macromorgan>
it looks like we always need to start at 0x200000 instead of 0 no matter what the ATAGS say, and we also always need a hole at 0xeffffff to 0x10000000 (or whatever the addresses are) no matter what the atags say. Would that work for a workflow?
<Kwiboo>
this was with latest ddr blob and same on two different devices, rk3566 and rk3588, so not anything special of identifiable
<macromorgan>
damn
<macromorgan>
maybe add atag parsing and guard it with a CONFIG option selected by the board?
<qschulz>
are we sure this one single bank on 8gb device is not working?
<Kwiboo>
I guess technically it is correct, for the 4gb there is a gap in addressable memory, and on 8gb the soc can only address memory up to 8gb, and a resarvation should be added for the hw reg range
<qschulz>
and if the atags are really incorrect, does downstream u-boot do something about it?
<qschulz>
if not, then we "just" need to tell Rockchip to fix their blob
<macromorgan>
or open source the blob and let us do it...
<Kwiboo>
downstream u-boot will add following banks for linux on a 8gb rk3566 board (odroid-m1s): bank: 0x00200000 - 0x08400000 (size: 0x08200000), 0x09400000 - 0xf0000000 (size: 0xe6c00000) and 0x100000000 - 0x200000000 (size: 0x100000000)
Stat_headcrabed has joined #linux-rockchip
Stat_headcrabed has quit [Client Quit]
<qschulz>
Kwiboo: and I assume this is the same board that has this one single bank reported by atags?
<macromorgan>
hmm... I guess why does it need that hole if ATAGs don't say you need that hole.
<macromorgan>
I'm not questioning you, just curious
vagrantc has joined #linux-rockchip
nashpa has joined #linux-rockchip
<Kwiboo>
qschulz: it should be, those ranges are same on multiple boot log pastes, but let me double check on an actual odroid-m1s
dliviu has quit [Ping timeout: 255 seconds]
<Kwiboo>
macromorgan: the hole at 0x08400000 - 0x09400000 is because of rk optee, and 0xf0000000 - 0x100000000 is used to access hw regs
<macromorgan>
okay... so in theory if you have no Optee you don't need the hole?
<macromorgan>
(not that you can get Optee working with upstream U-Boot anyway... can you?)
<Kwiboo>
the 0xf0000000 - 0x100000000 hole I expect is always needed as those addresses goes to hw regs and not memory
ungeskriptet6 has joined #linux-rockchip
ungeskriptet has quit [Ping timeout: 268 seconds]
<Kwiboo>
you can get optee loaded on mainline u-boot, binman just expects the blob in elf format, binman will be happy and TF-A will happily load/run it if you first objcopy the optee blob into an elf
<Kwiboo>
macromorgan: that should probably work fine, there is also an optee tag that should report the memory rk optee would use if we care about that at all ;-)
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #linux-rockchip
<macromorgan>
so I guess getting back to a way to logically describe the behavior... could we create the banks then in such a manner where: if atags present and magic good and there is a hole between 0xF0000000 and 0x100000000 then use the atags else use old logic; if using atags and bank0 < 0x200000 make it start at 0x200000
<macromorgan>
or should we instead copy the atags verbatum (if it starts at 0 for bank0) and mark the memory with a reserved node?
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #linux-rockchip
stikonas has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #linux-rockchip
dlg has quit [Ping timeout: 240 seconds]
dlg has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
eballetbo has quit [Quit: Connection closed for inactivity]
psydroid has quit [Remote host closed the connection]