00:13 <alyssa> maz: I see an #if 0'd teardown function in your pcie patch, any chance you remember whether that's still needed?

00:30 <alyssa> kettenis_: giving you a co-authored-by credit, though it looks like your u-boot patch doesn't have a signed-off?

01:29 <chadmed> so when we say get "SMP" working, does this include proper HMP support or can we only treat the firestorm and icestorm cores identically?

01:30 <chadmed> ik linux has an ARM HMP scheduler but ive never experimented with it so idk how easy it is to get working properly

01:37 <alyssa> chadmed: Oh, er, not sure

01:38 <alyssa> chadmed: I just mean 8 penguins show up. Which is not the case if you boot linux through kettenis's u-boot since u-boot and m1n1 fight over the spintable.

02:41 <alyssa> DT bindings turn my head into mush

02:41 <alyssa> If it makes me feel any better, they'll be bikeshed so hard on the lkml it doesn't really matter what I initialize the file to in v1...

03:53 <chadmed> hm ok ive had a read of some HMP scheduling docs and its looking like quite the effort to get it working properly. schedutil is responsible for doing the actual task scheduling, which it does by polling the energy model for the device. if im reading correctly, cpufreq-dt can do this with some device tree data, but what data it requires is ambiguous

04:24 <chadmed> oh ok wow its actually very simple, theres basically two ways to do it. the easiest given the way the dt is laid out now would be to just add capacity-dmips-mhz bindings to each core, which can be scaled relatively or be absolute dmips/mhz measurements that we can just calculate using a benchmark bound to only one cpu

04:25 <chadmed> the other way is refactoring the dt core layout to be split the firestorm and icestorm cores into clusters and decribe their behaviour as clusters but we dont need to do that

04:42 <alyssa> big.little is hard but has been around a decade now.

04:42 <alyssa> iirc

04:44 <chadmed> yeah its a feat, but afaict all that the kernel needs from us at this stage to get it working is that dt binding for each core and the scheduler can sort the rest out transparently

05:42 <pipcet[m]> does that actually work though? I mean, telling the scheduler about it is one thing...

06:13 <chadmed> well thats something we'll have to test i guess. the arm manuals say that this is how you do it, and i dont think we really have a reason to doubt it

06:15 <chadmed> look at some rockchip and allwinner dts, they have operating poitns tables that presumably get read by cpufreq-dt/whatever dvfs driver they use, so the freq-voltage curve might be worth coaxing out of macos to get finer grained power management to go with the HMP scheduling, assuming of course we ever get that level of control over the chip

06:19 <chadmed> we will have to implement something like this at some point though so mobile users can get decent power management, or we'll have a situation like the A1708 macbooks and later where linux battery life is terrible and charging is spotty

06:20 <pipcet[m]> I think battery life isn't terrible with the pearl/corellium kernel, but people might disagree :-)

06:28 <kettenis_> alyssa: odd that you have issues spinning up the other cores with u-boot

06:28 <kettenis_> u-boot leaves those cores alone

06:29 <kettenis_> this must mean the memory for the spin table/code isn't properly reserved

07:46 <saintdev> I just wanted to say thanks for the dev logs, I really enjoy reading what's going on behind the scenes. Thanks for all your hard work!

08:14 <everslick> seconded!!!

08:35 <kwilczynski> kettenis_: Just FYI before someone else notices and send you to the netiquette - HTML e-mails are a no-no on the around kernel mailing lists. :) Make sure you send plain text.

11:11 <kettenis_> ah crap, i suppose i shouldn't send mail using my isp's webmail

11:12 <j_ey> jannau: do you still have the GPIO trace log?

11:14 <tophevich[m]> kettenis_: never use anything from your ISP but the internet (I'm in the industry, we (telecoms) only want to bundle you in our products in a bad way to keep you between a rock and a hard place when trying to leave for a less worse service)

11:19 <tophevich[m]> read VAS (value added services) as laying stones in the way out of the gardn to recude churn -> make it painful as possible to leave

11:20 <tophevich[m]> (no I'm not bitter)

11:29 <tophevich[m]> Third party vendors also sell this as a feature to ISPs. It's a sepcial feature that you can't take the 3rd party product/service with you. If you buy it directly, you can use it everywhere. But if you buy it OTT via your ISP, it is locked to your ISP account, and by explicit design you can't (read: are not allowed to) transfer, yay!

11:29 <tophevich[m]> sorry, that was the last of it ...

11:42 <jannau> j_ey: https://gist.github.com/jannau/a1f8f055a48b8aa9daa5f2383caa34ea looks like the best have available

11:43 <j_ey> jannau: thx

11:44 <kwilczynski> kettenis_: No worries. :)

11:50 <pipcet[m]> alyssa: so, brcmfmac works with a few changes, most of them because I'm stupid and didn't read the error messages right :-)

13:58 <alyssa> kettenis_: I also had to add a hack (copying values from m1n1's fdt to u-boot's) to get the simple-framebuffer working in linux after enabling it in u-boot

13:58 <alyssa> So maybe there's something especially buggy with my config

13:59 <alyssa> at any rate, unless we're doing the init in u-boot spl, I'm not thrilled about depending on u-boot proper for boot. and since the hard parts are already done in m1n1 (thank you!) getting the m1n1->Linux path to have proper init seemed like a good idea.

15:33 <pipcet[m]> alyssa: which hard parts are those (not trying to be confrontational, just wondering whether m1n1 grew any new features while I wasn't looking)?

16:13 <alyssa> pipcet[m]: PCIe tunables

16:13 <alyssa> Corellium does it in their linux driver, Asahi does it in m1n1

16:13 <alyssa> kettenis_: wrote the m1n1 code

16:13 <pipcet[m]> oh, yes.

16:15 <pipcet[m]> (can you apply those without turning on the clock on the macbooks, though?)

16:16 <alyssa> Oh err

16:16 <pipcet[m]> (I still have my enable-all-clocks in place before I ever hand off control to m1n1, so...)

16:43 <kettenis_> alyssa: that's odd since simple-framebuffer works for me in openbsd

16:43 <kettenis_> i can even run X

16:47 <kettenis_> but maybe that is because the openbsd bootloader detects an EFI GOP framebuffer and creates the appropriate node in the fdt

16:51 <kettenis_> one of the issues with linux on arm is that there are too many different ways to boot a kernel ;)

16:52 <pipcet[m]> clearly someone needs to invent a new, better one, to replace all of them!

16:53 <tophevich[m]> (xkcd reference detected: https://xkcd.com/927/)

17:04 <alyssa> kettenis_: could be? 🤷

22:05 <alyssa> j_ey: I am not to be trusted around device trees, cherry picking https://github.com/kettenis/linux/commit/7b4a4e507738defcc5865cb6511f31e5341f7a7f in which obviously conflicts with your gpio/spi patch fwiw

22:08 <alyssa> currently rebasing pcie driver on top of kettenis_ 's device tree. fun time.

22:09 <alyssa> now it's not even probing. fun time!

22:13 <alyssa> what

22:24 <alyssa> -MODULE_DEVICE_TABLE(of, gen_pci_of_match);

22:24 <alyssa> +MODULE_DEVICE_TABLE(of, apple_pci_of_match);

22:24 <alyssa> this was suggested by kernel build bot

22:27 <j_ey> the gpio_ranges in that patch look "wrong" compared to my ones which work / based on what corellium did

22:43 <alyssa> j_ey: it seems to work for me

22:43 <alyssa> with some manual patching to add the clocks back in

22:43 <alyssa> Ooh, on the nub you mean

22:44 <alyssa> that.. should probably be fixed yes

22:44 <j_ey> yep, I thought you might get at least an error in dmesg

22:46 <alyssa> fixed the nub one, dunno about the aop etc

22:47 <alyssa> j_ey: i'm trying to do a messy pcie rebase, but you get a nice rebase of your own gpio series as a result, freeloader ;-P

22:50 <j_ey> heh, I already rebased it yesterday! but gitlab is still down

22:50 <alyssa> j_ey: mu-one/pcie-v2-3 has your branch (as it looked last week..) rebased on top of kettenis_ 's gpio dt

22:50 <alyssa> which was step one for rebasing on top of kettenis_ 's pcie dt which is .. much harder ...

22:51 <alyssa> onto pcie-v2-4

23:31 <alyssa> ported over to kettenis_ 's bindings 👍

23:39 <alyssa> just working through the mountain of feedback 😇

23:40 <alyssa> how could so much duct tape and gorilla glue be wrong? :P

23:41 <brentr123[m]> alyssa: Haha gorilla glue is supposed to fix anything

23:41 <alyssa> 🙈

23:43 <brentr123[m]> Reminds me of the flex tape memes with the guy that claims to fix anything with it, even repairing a sawed boat