robclark changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Chrome OS Trogdor Devices - Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630 - Lenovo ThinkPad X13s - and various other snapdragon laptops) - https://oftc.irclog.whitequark.org/aarch64-laptops
KREYREN_oftc has quit [Remote host closed the connection]
enyalios has quit [Remote host closed the connection]
enyalios has joined #aarch64-laptops
<steev> broonie: this is a bit of a... stretch, but how many subsystems would you say make up the linux kernel? not just the core 5 but... everything?
<steev> i can't figure out how to parse the maintainers to come up with one
<konradybcio> pretty much every subdir of drivers/ is its own subsystem
<konradybcio> same for arch/
<bamse> steev: i guess it's a question of definition...but there are 369 branches merged into linux-next...
<steev> that's a good point too
<bamse> steev: ^^ for the reset during boot (at least)
<steev> oh spiffy
KREYREN_oftc has joined #aarch64-laptops
jglathe_sdbox2 has quit [Quit: Leaving]
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
<steev> bamse: i've only rebooted once, but it didn't reset that time :P
iivanov has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
minecrell2 has quit []
minecrell2 has joined #aarch64-laptops
bluerise_ has quit [Quit: brb]
bluerise has joined #aarch64-laptops
<broonie> steev: Hrm?
<broonie> steev: -ENOCONTEXT
<broonie> steev: You could get close by looking at every directory directly under drivers/ but there's a bunch of other things.
hightower2 has joined #aarch64-laptops
<bamse> steev: let's ship it! ;)
todi has quit [Ping timeout: 480 seconds]
todi has joined #aarch64-laptops
<dgilmore> after reading aboveI booted my x13s without "clk_ignore_unused pd_ignore_unused" just "arm64.nopauth" everything came up, the only obvious thing not working was the 5g modem was not visible. do we know what else would be missing?
<bamse> dgilmore: booting a modular kernel without *_ignore_unused is not deterministic, so issues will not manifest themselves as some specific functions being present or not
<dgilmore> bamse: okay fair
<bamse> dgilmore: most common problem seen without clk_ignore_used is that the display clock controller goes to shit...
<javierm> bamse: I really wish gregkh could had taken my series https://lore.kernel.org/lkml/20221116115348.517599-1-javierm@redhat.com/
<javierm> it helped a lot on my testing, the 10 sec timeout is too short IME
hightower3 has joined #aarch64-laptops
<bamse> dgilmore: it's been a while since i measured, but i don't think we gain much currently...but with some additional changes it's a clearly measurable difference, so we need to get there soon
<bamse> javierm: hmm, isn't that 10 seconds after last probing thing? in other words if your dm-crypt password takes > 10 seconds to type things goes bad?
<javierm> bamse: it's 10 secs after deferred_probe_initcall() which is a late_initcall()
hightower2 has quit [Ping timeout: 480 seconds]
<javierm> so if you spend 10 secs in plymouth typing your pass, and your display driver is as a module in the rootfs, I think that it won't work
<javierm> bamse: but I posted that series almost 2 years ago, so I don't remember the details anymore :)
<javierm> it's just a pity for me that the probe deferral mechanism timeouts now instead of keep trying as it was always the case
<javierm> because you never really know when the kernel is "done" probing devices...
<dgilmore> bamse: that is fair, mostly I was curious, and was somewhat surprised it got as far as it did
<javierm> unless we add some interface exposed to user-space where systemd or whatever can tell the kernel that is done loading modules and can start timing out from now on
<bamse> javierm: much points to us needing such interface if we're going to be able to handle the plymouth case
<javierm> bamse: yeah, but that wouldn't help with the 10 secs default
<bamse> javierm: we have another similar case, in if you build remoteproc drivers into the kernel, but you don't have firmware in the ramdisk...i have no way to know when rootfs is there to allow me attempting to load the firmware
<javierm> bamse: yeah
<javierm> bamse: so my series tried to disable driver deferred probe timeout by default, but unfortunately was told that it would break other people's workflow that were already relying on the 10 secs
<javierm> bamse: https://xkcd.com/1172/ basically
<javierm> it's funny that someone could break other people workflows but reverting is not OK anymore because someone may rely on the new behaviour
<bamse> javierm: yeah, much of these timeouts comes from the idea that you should be able to boot a distro which might not have all the drivers built for what is mentioned in the devicetree
<javierm> bamse: yeah
<bamse> javierm: but when that means we skip waiting for power-domains, and continue to attempt to touch hardware that hasn't been powered on...it's not funny anymore
<javierm> bamse: or clocks...
<javierm> bamse: I may try to re-send that series. On a re-read it seems that Jon just wanted more information? https://lore.kernel.org/lkml/CANDhNCr7ZwbCDK1ftigLK_S2qASj1yfenUG1WPaiYbjr5M9x3w@mail.gmail.com/#t
<javierm> but I remmeber he being against it... maybe it was a discussion on irc or v1...
<javierm> at least https://lore.kernel.org/lkml/20221116120043.519614-1-javierm@redhat.com/ should not be controversial. I think
janrinze1 has joined #aarch64-laptops
<janrinze1> jenneron[m]: I have reinstalled debian 12 on my laptop. Typing on it now. Hope to be more helpful on solving the audio issues with this new setup.
<jenneron[m]> janrinze1: there should be a new dts for your board soon
<jenneron[m]> since using tomato-r1 is wrong
<jenneron[m]> janrinze1: btw if you're okay with being more involved in pmOS testing you could add yourself to https://wiki.postmarketos.org/wiki/Testing_Team
<janrinze1> jenneron[m]: tomato-r1 at least works 90% ;-)
<janrinze1> speaking of tomatoes, I'll make some dinner now. brb.
<craftyguy> I can't wait to see someone in the wild using a (forward facing) screen protector on one of those
<craftyguy> ("privacy" protector, I mean)
hightower4 has joined #aarch64-laptops
janrinze1 has quit [Remote host closed the connection]
hightower3 has quit [Ping timeout: 480 seconds]
iivanov has quit [Quit: Leaving...]
hightower3 has joined #aarch64-laptops
jglathe_sdbox2 has joined #aarch64-laptops
hightower4 has quit [Ping timeout: 480 seconds]
jglathe_volterra has quit [Remote host closed the connection]
<steev> te
<steev> true*
<steev> e
janrinze1 has joined #aarch64-laptops
<janrinze> jenneron[m]: I was able to run the chromeos kernel (self built) and use the dojo dtb that comes with it. It initialises all hardware correctly. Also the nvme is more than twice as fast as on the 6.8 kernels.
janrinze1 has quit [Remote host closed the connection]
<jenneron[m]> janrinze: we're not using downstream kernels
alpernebbi has quit [Ping timeout: 480 seconds]
<janrinze> jenneron[m]: yes, you don't. but it's initeresting to see a huge difference in performance. 500MB/s vs 1600MB/s
<jenneron[m]> well it means there is a problem
<janrinze> could be. We only enabled it a while ago and we have no info on similar devices.
janrinze1 has joined #aarch64-laptops
janrinze1 has quit [Remote host closed the connection]