alyssa changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - https://gitlab.freedesktop.org/panfrost - Logs https://freenode.irclog.whitequark.org/panfrost - <daniels> avoiding X is a huge feature
<hanetzer> sphalerite: ! ran into your name on an online irc log wrt kexec on what I think may be rockchip related?
stikonas has quit [Remote host closed the connection]
vstehle has quit [Ping timeout: 245 seconds]
tgall_foo has joined #panfrost
NeuroScr has quit [Quit: NeuroScr]
<chewitt> HdkR: not sure if it was a rhetorical question (reading backlog) but I have a G31 device booting mainline
<chewitt> (with Kodi of course .. via the blob)
<HdkR> chewitt: Nice :)
<HdkR> G3x != G7x though :P
<HdkR> Close enough for Panfrost not really neding to care
<chewitt> I'm sure you said "dvalin" though, which in Amlogic-speak is their G31 devices, S905X2/D2/Y2
<chewitt> we have G52 running on the Odroid N2 as well
<HdkR> Oh yea. I have two N2 devices as well :D
<chewitt> what do you have planned for them?
<HdkR> One for capture, one for working on
<tomeu> alyssa: yeah, will skip piglit for now because IME it takes ages to run
<tomeu> and as you say, there isn't that much value when compared to deqp
<alyssa> tomeu: :)
<tomeu> TheCycoONE: not sure how ready mesa-ci is for a driver such as panfrost, I would prefer to go with something quick and dirty that helps panfrost stand on solid ground, than waiting a year to have something mesa-wide
<alyssa> +1
<tomeu> so I guess some gitlab-ci.yml file in our subdir, that people have to explicitly enable in their mesa forks
<tomeu> and I'm not sure whether in the initial phases we can make it open to all, for security reasons
<tomeu> unless Arm wants to donate a mali device model for QEMU :)
<alyssa> tomeu: We know there *is* a software model internally (from kbase symbols).. :P
<alyssa> Unironically, I *am* itching to write a Mali emulator. But there's not much point to do so..
<tomeu> yeah, specially as we anyway need to test the real hw
alyssa has left #panfrost [#panfrost]
vstehle has joined #panfrost
<hanetzer> bleh.
NeuroScr has joined #panfrost
<hanetzer> urjaman: btw, thanks for figuring out the thing with the emmc thingus for IGNOREME; I thought I fried it lol
Elpaulo has joined #panfrost
<urjaman> yeah btw i was thinking about it a bit and i have an idea as to the "WTF" in that ...
<urjaman> i think the write protect is to prevent an attacker from having the boot rom boot from eMMC instead of the SPI and thus bypass the whole write protect screw
<MoeIcenowy> hi
<MoeIcenowy> could anyone try to run glmark2 test ideas on panfrost on git master of mesa?
<MoeIcenowy> I met failure during st_glsl_to_nir() when running it on lima
<sphalerite> hanetzer: quite possibly, I've fiddled with kexec a number of times
<hanetzer> sphalerite: trying to get it working on rk3399; just hangs at 'kexec_core: Starting new kernel'
<sphalerite> hanetzer: which device? I've never got anywhere with it on my gru chromebook, had slightly better luck with my nanopi
<sphalerite> hanetzer: with the nanopi, it often hangs for about 30 seconds after that message, then stuff continues happening
<hanetzer> gru kevin
<hanetzer> sphalerite: one time I killed the watchdog before it, and it didnt' hang but it did go back to coreboot/depthcharge instead of straight into the kernel
<sphalerite> oh yeah, and how are you performing the kexec? I found that (on nixos, which is systemd-based) `systemd kexec` worked a lot better than `kexec -e`
<hanetzer> gentoo, openrc, manual kexec -l and -e
<sphalerite> hm ok
<sphalerite> I don't really know, sorry
<sphalerite> would really like to have the knowledge to be able to help you :p but I don't
<hanetzer> I'll fight it more tomorrow. sleepy time
<sphalerite> good night!
<sphalerite> I'd be glad to hear about it if you get anywhere :)
NeuroScr has quit [Quit: NeuroScr]
robher has quit [Read error: Connection reset by peer]
robher has joined #panfrost
yann has quit [Ping timeout: 264 seconds]
stikonas has joined #panfrost
stikonas has quit [Remote host closed the connection]
<kszaq> Question: should structs for uapi be padded to 64 bits? I noticed that there is a pad in all structs except for drm_panfrost_create_bo https://gitlab.freedesktop.org/panfrost/linux/blob/panfrost-5.0/include/uapi/drm/panfrost_drm.h#L80-94
<bbrezillon> kszaq: yep
<bbrezillon> kszaq: it's been fixed in the version posted here https://patchwork.freedesktop.org/patch/297644/
<kszaq> bbrezillon: Good to know, thanks!
raster has joined #panfrost
<janrinze> shouldn't the padding be done by the compiler based upon attributes used to define the struct?
afaerber has joined #panfrost
<kszaq> janrinze: IIRC compilers do this but they can behave differently, so adding explicit padding gives you confidence that the padding is there.
janrinze has quit [Remote host closed the connection]
janrinze has joined #panfrost
janrinze has quit [Remote host closed the connection]
yann has joined #panfrost
janrinze has joined #panfrost
<MoeIcenowy> what's the current suggested kernel driver for panfrost?
<HdkR> Latest one you can muster since panfrost is/has dropped support for the proprietary kernel bits
<HdkR> That...should work
<MoeIcenowy> oh I think I need to PR sth for sunxi
<MoeIcenowy> for bus clock
<kszaq> This one is a bit more recent.
<HdkR> Yea, watch out for your own board's downstream patches
<MoeIcenowy> no one is considering Allwinner devices when developing panfrost ;-)
<MoeIcenowy> maybe I should ask TL Lim to send you somd Pine H64's ;-)
<HdkR> Things outside of what is mali facing is definitely low on my list of things I try to worry about :P
<MoeIcenowy> what's a good way to check whether a specific SoC has bus clk gate or not?
<MoeIcenowy> by use SoC-specific compatible string?
<MoeIcenowy> oh maybe I should check the presence of clock-names property
pH5 has joined #panfrost
fysa has joined #panfrost
<MoeIcenowy> oh weird
<MoeIcenowy> system hang when panfrost kernel module lodas
<MoeIcenowy> loads *
<MoeIcenowy> even the cursor of console stopped to blink
<MoeIcenowy> oh it seems to be the same time I met with official driver on H6...
afaerber has quit [Quit: Leaving]
alyssa has joined #panfrost
<MoeIcenowy> after adding a 10ms delay in driver after initialization of clk/power/rst
<MoeIcenowy> the module lodas
<MoeIcenowy> loads *
<MoeIcenowy> but as expected Mesa doesn't work on H6
stikonas has joined #panfrost
<alyssa> ..Module?
<alyssa> You should be building in tree..?
<MoeIcenowy> alyssa: yes, but building it as module
<MoeIcenowy> to make debug easier
<alyssa> Has anyone testd that...?
<MoeIcenowy> alyssa: I'm using the new DRM driver
<MoeIcenowy> not mali_kbase
<MoeIcenowy> isn't it intended to be built in-tree? ;-)
<alyssa> MoeIcenowy: I'm just not sure anyone has tested building the DRM driver as a module (=m rather than =y)
<MoeIcenowy> now I tested
<MoeIcenowy> but I think the H6 HW seems to have some problem
<MoeIcenowy> mali_kbase also needs the delay workaroud
<MoeIcenowy> workaround *
<MoeIcenowy> so don't worry, it's not the DRM driver's issue
<alyssa> wontfix; notabug
<alyssa> ;P
<urjaman> alyssa: i've built it as a module (in-tree, but as a module)
<urjaman> loads fine on boot
<alyssa> urjaman: Good to know, thank you
<MoeIcenowy> alyssa: you should say "not our bug"
<MoeIcenowy> not "not a bug"
<MoeIcenowy> alyssa: BTW as expected H6 T720 doesn't work
<alyssa> That one is our bug, yes..
<MoeIcenowy> ah, is fixing it a big project?
<MoeIcenowy> should I raise a bug on bugzilla?
<urjaman> we have a bugzilla? :P (i guess mesa has one actually lol...)
<MoeIcenowy> today I suggested its maintainer to add two components
<MoeIcenowy> Driver/Gallium/{Lima,Panfrost}
<MoeIcenowy> I already raised the first bug on fd.o bugzilla for lima ;-)
<anarsoul> MoeIcenowy: I think opening an issue on gitlab would be better. At least alyssa will get an email
<MoeIcenowy> on what gitlab repo?
<MoeIcenowy> https://pastebin.aosc.io/paste/BNtG2JREP4MTfeoSXE2v0A here's a log of running glmark2-es2-drm on H6
<anarsoul> MoeIcenowy: good question
<chewitt> alyssa: I have the drm driver packaged as =m .. works fine
<MoeIcenowy> totally headache
<MoeIcenowy> how is Mali T[67]xx and T8xx bound to CPU bit?
<anarsoul> MoeIcenowy: CPU bit? Do you mean endianess?
<MoeIcenowy> alyssa: could I try to make a lima_context->is_t8xx
<MoeIcenowy> s/lima/panfrost/
<MoeIcenowy> and change `#ifdef __LP64__` to `if (ctx->is_t8xx)` ?
<jernej> MoeIcenowy: only issue I had with GPU on H6 was lockup due to not enabled voltage regulator
<jernej> did you check if panfrost kernel driver supports enabling GPU power supply?
<MoeIcenowy> it supports
<jernej> then I don't know what would be wrong
<jernej> I guess you manually checked clocks, reset and power supply status?
<MoeIcenowy> oh many of the GPU data structures are also width-related
<MoeIcenowy> alyssa: so the address space of Mali T[67]xx is 32-bit, T8xx is 64-bit?
raster has quit [Remote host closed the connection]
* robher has only tested panfrost built as a module.
<robher> panfrost drm driver is merged!
<anarsoul> congrats :)
<Lyude> awesome! :D
<milloni> congrats!!
<milloni> for 5.2 i suppose?
<robher> milloni: yes
<milloni> i've got a question (possibly a n00b question)
<milloni> i finally managed to install an upstream 5.1-rc4 kernel on my rock pi 4 board
<milloni> which has an rk3399 chip with a mali gpu
<milloni> after which i installed weston and it is working
<milloni> my question is, how is it working if, to my knowledge i don't have either panfrost or the official proprietary driver in my kernel?
<anarsoul> milloni: software rendering
<robher> alyssa: looking at the job structs a bit, uintptr_t is just the tip of the iceberg. Anywhere with unions with elements of different sizes are a potential issue.
<milloni> hm ok
<milloni> anarsoul: so the gpu is literally not used for anything on my system at the moment?
<anarsoul> well, you don't have a driver for it
<anarsoul> so yes
<milloni> nice
<milloni> i'll try the panfrost tree next
<robher> I guess I should push a new branch to panfrost/linux
<robher> drm-misc/drm-misc-next should work unless you happen to have my monitor which needs a fix in drm-misc-fixes
yann has quit [Ping timeout: 246 seconds]
<alyssa> robher: Wholly congratsC!
<alyssa> robher: Yeah..
<kszaq> Moelcenowy: Are you running aarch64 userspace?
<kszaq> I have patchset for Mesa where you can set bit width of structs GPU expects by adding a CFLAG
<kszaq> I needed it for running T820 from arm userspace
<kszaq> I think your case is the other way round. :D
<kszaq> And your issue looks the same I experienced with T820.
yann has joined #panfrost
NeuroScr has joined #panfrost
hanetzer has quit [Quit: ZNC 1.7.1 - https://znc.in]
hanetzer has joined #panfrost
Elpaulo has quit [Quit: Elpaulo]
NeuroScr has quit [Quit: NeuroScr]
stikonas has quit [Remote host closed the connection]