02:03 <Lyude> narmstrong: poke, you around? I'm wondering if anyone's tried making sure GPU resets work with mali_kbase/vim2

02:26 <chewitt> He's GMT+2 so won't be around for another 3-4 hours

02:26 <Lyude> that's fine

02:26 <Lyude> chewitt: to answer the question you asked in #panfrost: basically what I'm seeing is when an invalid job gets sent to mali_kbase and it 'resets' the gpu, mali_kbase actually just hangs and I have to restart the system to get things working again

02:27 <Lyude> or at least to get it to show more job faults

02:27 <Lyude> it looks like something might be missing in the platform code you guys have for mali_kbase/meson

02:27 <Lyude> would like to fix this since getting much further with panfrost is going to be a pain otherwise

02:29 <chewitt> current code will be oriented towards the utgard chips because those are the only ones testable

02:29 <chewitt> will be = may be

02:30 <Lyude> hm, i'd think if there's enough code to get the GPU running for this it shouldn't be too much more work to get it to shut down

02:30 <Lyude> i'm taking a look at it as well btw, not sure how far I will get

03:51 <chewitt> xdarklight: the arm_scpi.c patch isn't required, only the device-tree nodes

05:54 <xdarklight> narmstrong: instead of getting the PHY patches, use net-next instead (patches were queued last night): https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/ - with that you only need the .dts patch :)

06:25 <narmstrong> xdarklight: ok thx

06:25 <narmstrong> Lyude: indeed we cannot really try the Midgard driver on the kvim2 so it was all guesses

06:25 <narmstrong> Lyude: but here is the amlogic messy code https://github.com/superna9999/meson_gx_mali_t820/tree/TX011-SW-99002-r12p0-04rel0_amlogic?files=1

06:26 <narmstrong> And the messy changeset against the original release https://github.com/superna9999/meson_gx_mali_t820/commit/3c7b8bb4fc93bc68176bfa902ebd2fd5a63c84c2

06:26 <narmstrong> Maybe you will find something interesting !

09:42 <ldevulder> narmstrong, hi! regarding my boot issue on kvim2: it seems to be partially due to my change with clock/regmap

09:43 <ldevulder> with "standard" u-boot I' still not able to boot my opensuse tumbleweed but I can go further in the boot process, but I can see clock issue on some module, so seems to be related to clock...

09:44 <ldevulder> but I was able to boot an ubuntu with kernel 4.19 and standard u-boot on it, so something is missing on opensuse for kvim2

09:44 <ldevulder> and my patch need some improvement it seems :D

17:47 <narmstrong> Good the know, can you diff the kernel configs ?

17:47 <narmstrong> ldevulder_: i can have a look at your clk changes if you want

17:51 <ldevulder_> narmstrong, I will try to check the kernel configs

17:52 <ldevulder> narmstrong, I sent an email on u-boot ML with the patches, as a RFC

17:52 <ldevulder> 2 or 3 weeks ago, don't remember exactly

18:04 <narmstrong> You should cc the Linux amlogic ML and me otherwise I’ll miss them...

18:04 <narmstrong> Oh I didn’t see them

18:08 <ldevulder> narmstrong, yes I forget to add the linux-amlogic ML, sorry, I will do this next time :)

18:09 <ldevulder> narmstrong, here the title: "[RFC PATCH 0/3] ARM: meson: Use syscon/regmap for clock driver", or if needed I can resend them to you as well as linux-amlogic ML