02:10 <Dylanger> Hey all, does anyone know what I should do to try and boot Cherry (Acer Chromebook Spin 513), I'm guessing the first step is to cherry-pick the DTBs from Chromium's kernel?

02:17 <steev> that's lazor no?

02:17 <steev> according to https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/ it's just trogdor?

02:47 <bamse> Dylanger: upstream should be pretty much up to date, except that display apparently broke in v5.19-rc1

02:55 <robclark> no, cherry is a different spin-513

02:55 <robclark> confusingly enough

02:56 <bamse> oh my

02:56 <robclark> it is mtk.. not quite sure what the upstream state is.. apparently they eventually got some things working upstream, but somewhat ever the first mt8192 (?) things shipped

02:56 <robclark> s/ever/after/

02:57 <robclark> (and for those following along at home w/ lazor/homestar, there is a patch to make things work on -rc1.. `arm64: dts: qcom: Remove duplicate sc7180-trogdor include on lazor/homestar`)

03:08 <bamse> robclark: installed sway to do some more testing on my sc8280xp...seems to work ok...but i don't have any cursor...

03:08 <bamse> robclark: did i screw up my dpu catalog? or how does the cursor come into play?

03:09 <bamse> i don't have gpu support yet...

03:10 <Dylanger> <robclark> "no, cherry is a different spin-5..." <- It's MTK Kompanio 1380

03:10 <Dylanger> Brand new baseboard iirc

03:10 <robclark> gpu shouldn't (in theory) matter for cursor.. pastebin output of modetest w/out sway running when you get a chance?

03:10 <bamse> "modetest -s 32:1920x1080 -C" does show a somewhat transparent square bouncing over the screen

03:10 <robclark> (modetest w/ no args, where it just prints everything out)

03:14 <bamse> robclark: https://www.toptal.com/developers/hastebin/wutadeyeno.yaml

03:16 <bamse> sway complains about "Failed to pick cursor format" and "Failed to render cursor buffer"...

03:16 <bamse> right after complaining about me not having EGL

03:16 <robclark> hmm, you have the right # of primary and cursor planes, so that looks ok (assuming only internal display supported at this point, otherwise I guess I'd expect more primary adn cursor planes

03:18 <robclark> try weston, perhaps? I guess this is a sway bug, or at least I'd have to look at how it is failing to pick a plane for cursor.. there seems to be plenty of overlay and cursor planes to pick from

03:21 <bamse> found an open bug report, and a suggestion to disable hardware cursor...so now i can see the cursor at least :)

03:21 <bamse> on sway that is

03:22 <bamse> robclark: but do you know if i'm supposed to expect anything beyond a semi-transparent square bouncing around in modetest when running with -C (test hw cursor)?

03:28 <robclark> hmm, that sounds plausibly right

05:31 <Dylanger> It's Tomato!

05:31 <Dylanger> Not Cherry

05:35 <Dylanger> Or actually cherry might be the baseboard codename

05:35 <Dylanger> And tomato is the overlay?

09:57 <HdkR> I see that msm hangcheck timeout is set to a constant 500ms. Anyway that can be changed to a debugfs for easier changing for debugging? I had a game today that was heavier than A660 could handle in 500ms and needed a timeout increase

09:57 <HdkR> robclark: ^

10:12 <HdkR> https://gist.github.com/Sonicadvance1/671d35e46c785af507b92e960aad4010 Although I don't know if AHB bus errors mean anything

11:14 <xnox> was ThinkPad X13s ever available for sale?

11:14 <xnox> cause for me it is always out of stock / unavailable

11:41 <Dylanger> <xnox> "was ThinkPad X13s ever available..." <- It doesn't actually exist

11:42 <Dylanger> I think we all had collective hallucinations

11:43 <HdkR> If it is anything like the last generation, it's going to take 6-9 months before it ends up being available

11:53 <Dylanger> AMD 6000 is also vaporware

14:20 <qzed> steev, bamse: does the Flex need clk_ignore_unused to boot?

14:21 <qzed> on the Pro X I currently need either that or I have to build gcc-sc8180x as module...

14:30 <bamse> qzed: yes, all platforms with kernel modules need clk_ignore_unused

14:30 <qzed> bamse: what do you mean "with kernel modules"?

14:30 <bamse> okay, that's too generic

14:30 <qzed> if I build gcc-sc8180x as module I don't seem to need that

14:31 <bamse> all platforms where the clock state set up by the bootloader somehow relates to clients built as modules, needs clk_ignore_unused...because "unused" is determined before any kernel modules have had a chance to probe

14:32 <bamse> in the event that you make gcc a module then disabling unused clocks will be a nop, because there are no clocks at late_initcall()

14:32 <qzed> ahhh okay

14:32 <bamse> and if you build gcc as a module you don't have a working debug uart in most cases

14:32 <qzed> yeah

14:34 <bamse> and initcalls_done in drivers/base/dd.c will be true, so probe deferral of a few different resource types stops working

14:35 <qzed> shouldn't it still be possible to somehow determine which clocks need to be kept on and tell the controller about it via the DT?

14:35 <bamse> yes

14:35 <qzed> or something along those lines?

14:35 <qzed> okay

14:35 <bamse> there's a "new" mechanism called "sync_state", in which a provider is informed when all devices referencing it in dt has been probed

14:36 <bamse> so we should be able to implement a sync_state callback in each provider and when that happens disable any then unused clocks

14:36 <qzed> yeah, that'd make sense

14:37 <bamse> problem with that is that traditionally clocks wasn't probed by dt references, so you still have the possibility of some clocks just being resolved based on their global name

14:37 <qzed> hmm, right

14:38 <bamse> we still have a few of those left...but it's getting there

14:39 <qzed> okay, so the commonly accepted thing to do is just using clk_ignore_unused for now?

14:39 <steev> bamse answered but yet

14:39 <steev> s

14:39 <steev> yes*

14:39 <bamse> qzed: for now, yes

14:40 <qzed> thanks!

14:51 <qzed> so this looks like what you were talking about: https://lore.kernel.org/all/162466065014.3259633.8331957079895473498@swboyd.mtv.corp.google.com/t/#u

14:52 <qzed> unfortunately I didn't find any follow-up discussion and I don't think this or something similar has been merged

14:53 <bamse> yes

14:54 <qzed> anyway, I'll keep an eye out for this, thanks again!

15:01 <steev> robclark: actually that msm_gem_vma_inuse thing... it's not from the display turning off - i just ran into it again when simply launching vscode

15:05 <robclark> hmm.. well I haven't had a chance to try and figure out what is going on there, but some semi-reliable way to reproduce would certainly be helpful when I do get to it

15:06 <steev> i wouldn't say it's "reliable" - it doesn't occur every time i launch vscode, i just happened to notice it because i launched vscode and it didn't finish loading in what i was working on (and now i have to switch to a different kernel to get some work done)

15:07 <steev> but the basic gist is, gnome+wayland+vscode