08:23 <marex> lynxeye: either its the bus interface, or the GPU just needs the rising edge of the reset signal, which isn't generated by the PGC anymore (as it was on the MX6)

08:23 <marex> lynxeye: the question is, should the GPCv2 driver toggle the reset or the GPU ? I would bank toward the GPCv2, since the reset is shared and that would just be easier

08:24 <marex> lynxeye: btw there seem to be the same problem with VPU

08:26 <lynxeye> marex: How did you find out that the rising edge isn't generated anymore?

08:27 <lynxeye> marex: And yep, triggering the reset from the GPCv2 driver seems to be the right thing to do then.

08:27 <marex> lynxeye: I obviously didn't, that's pure speculation as I don't have the RTL

08:28 <marex> lynxeye: so we are back to the dumb behavior like ATF has :(

08:28 <lynxeye> I didn't yet try the VPUs as we are still missing the BLKCTRL drivers there. The VPUs have their reset controller located inside the vpumix domain

08:28 <lynxeye> yes, this is very unfortunate

08:28 <marex> lynxeye: I looked at the ATF code, it does the very same thing

08:28 <marex> for VPU that is

08:29 <marex> lynxeye: I tried asking NXP about the PGC details , but got no reply this far (paging _daniel_ too :) )

08:30 <marex> lynxeye: obviously someone must have access to the RTL and be able to tell what is exactly going on and why is ATF toggling the entire GPUMIX domain

08:30 <marex> lynxeye: there I am rather sure it's some hidden bug of the hardware

08:32 <lynxeye> marex: Yea, you might be right. My first assumption was that it's just down to the fact that they smash both GPUs in a single platform device in the downstream driver, so it's easier to have a single PD. But maybe there is some hidden bug there. After all clock glitches with the GPC isn't really something unheard of. On i.MX6QP you can't power down the PU domain, as the transition glitches the PRE (or PRG, don't remember) unit, that are

08:32 <lynxeye> n't even located in this domain...

08:35 <marex> lynxeye: power islands are gonna be glitchy, that's expected

08:35 <marex> it's physics

08:36 <marex> but then, the logic should be implemented such that either A) there is proper and full reset implementation for each block or B) there is deglitch logic all around

08:36 <marex> but this must be very hard to implement in hardware, so bugs are to be expected

08:39 <lynxeye> sure, power gating isn't a total walk in the park, it's just that the GPC controller was implemented specifically to handle all the uglyness required ;)

08:39 <marex> lynxeye: was there always this ADB400 bus unit too ?

08:40 <lynxeye> marex: it wasn't in the i.MX7 where the GPCv2 was first implemented. All the i.MX8M have at least some ADB400.

08:43 <marex> lynxeye: maybe integration of that is bugged

08:44 <marex> lynxeye: that would explain why reading out the GPU2D registers returns funny values sometimes

08:44 <marex> lynxeye: that there is some glitch on the AHB when the ADB400 connects the GPU to the bus

08:45 <marex> I wonder whether the ADB400 has some finer control over the bus resets, gotta check that

14:35 <cengiz_io> hello there! :D

14:35 <pcercuei> hi

14:36 <cengiz_io> I have 4.20 of Freescale community kernel that has etnaviv enabled. however whenever we try to run "modetest" or "kmstest" we're getting a NULL ptr dereferece at the same function. "restore_fbdev_mode"

14:36 <cengiz_io> my google-fu didn't return any meaningful results. can someone shine some light on this?

14:37 <marex> cengiz_io: pastebin the boot log (all of it, from power on ...) and the backtrace please

14:37 <pcercuei> that's not really related to etnaviv, the error is in the KMS driver

14:40 <austriancoder> cengiz_io: what's the freescale community kernel? Does mainline work? What target platform?

14:40 <marex> austriancoder: probably linux-fslc on imx6

14:40 <marex> dual iirc

14:41 <cengiz_io> hello marex: here you go https://gist.github.com/cengizIO/7646f615f18881364d4d09a85cc1f636

14:42 <cengiz_io> austriancoder hello. it's the community maintained fork of linux-imx kernel that is slightly better with keeping in sync with mainline

14:42 <cengiz_io> austriancoder Automotive Grade Linux ships with it by default

14:42 <marex> linux 4.20-rc6 seems quite outdated, it can't be that well maintained if they didn't even update to final release :)

14:43 <cengiz_io> https://github.com/Freescale/linux-fslc/tree/4.20.x+fslc

14:43 <marex> cengiz_io: just switch to linux 5.4.y LTS or 5.8.y , should be fine

14:43 <marex> cengiz_io: or is there anything in the downstream FSL stuff that you need ?

14:44 <marex> cengiz_io: or at least test mainline and then you can spend time backporting the fix , it should be easier to find the fix once you validate you at least some working setup

14:44 <cengiz_io> unfortunately yes. not FSL oddities but i have some closed source drivers that can only run with 4.20

14:44 <cengiz_io> vendor's are evil..

14:45 <cengiz_io> what can I be missing? how do I enable KMS?

14:45 <cengiz_io> I just added my panel description to panel-simple.c and enabled lcd RGB from devicetree

14:45 <marex> cengiz_io: the crash is in DRM fbdev emulation

14:46 <marex> so it's likely something which is either due to extra NXP patches or something which was fixed upstream since

14:46 <marex> that's why, test upstream (e.g. 5.4 or 4.19, maybe the later is closer) and then look for the difference

14:46 <marex> it's easier to find the difference if you have a known-working solution without extra cruft on top

14:47 <cengiz_io> you are absolutely right. I might give it a try with mainline. but as I said, I will suffer later with closed source wifi module drivers and etc...

14:52 <marex> cengiz_io: maybe you can just cherry-pick/revert the bugfix

14:52 <cengiz_io> if only I could find that sweet spot to cherry pick :D

14:53 <cengiz_io> what I'm actually trying to know is, is this something common when someone is using DRM/KMS to emulate fbdev? maybe I'm just missing a simple config option or alike

14:58 <pcercuei> as you can imagine, NULL pointer deferences are never supposed to happen

15:04 <marex> cengiz_io: well, git log v4.19..v4.20 -- drivers/gpu/drm ... that should give you some basic list of ideas

15:07 <cengiz_io> pcercuei exactly

15:07 <cengiz_io> marex I'll try it right now