ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630)
<mothenjoyer69>
<steev> "jenneron: so you need at least..." <- I'm guessing that the version of pd-mapper shipped in the debian CD image may not be sufficient for sc8180x? that or we are still missing a piece of the puzzle
<mothenjoyer69>
I've suddenly had my Galaxy Book S refuse to boot with DT so once I figure out what's happened there i should be able to test with a newer version
<steev>
mmmm, i can't recall if there is an update or not, but that should work if you have it
<steev>
are you using grub as the bootloader?
<steev>
you can always edit the grub entry manually and add "devicetree /path/to/dtb/file/on/the/system.dtb" to it
Lucanis has quit [Quit: Leaving]
Lucanis has joined #aarch64-laptops
<mothenjoyer69>
grub, yeah. that is how I've been doing it; with a known good image its begun dumping me to a black screen
<steev>
6.1?
<steev>
try adding deferred_device_timeout=30 to your kernel commandline
<mothenjoyer69>
<steev> "try adding deferred_device_timeo..." <- my hero ;)
<steev>
not me, javierm
<steev>
he told me
<mothenjoyer69>
ah, well, in any case thank you (and javierm) :) odd that it was fine prior
<steev>
it has been something somewhat recent, i don't recall which 6.1; i can't tell with -next because i just get a pretty quick reboot, and 6.0 doesn't happen at all. so maybe some drm "fix" isn't; it also oddly seems to cause the boot to speed up
<mothenjoyer69>
hmm, weird. opposite for me, i initially thought it had had no success
<mothenjoyer69>
unrelated but I have a Galaxy Book 2 (SM-w737, SDM850) available if anyone wants a secondary unit or just wants a unit
<mothenjoyer69>
(as a donation device, of course)
swgws_ has joined #aarch64-laptops
swgws has quit [Ping timeout: 480 seconds]
<steev>
i got rid of mine somewhat recently, someone i know had their computer die and they were fine with a 2 in 1 device like that, and they are enjoying it
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
swgws has joined #aarch64-laptops
swgws_ has quit [Ping timeout: 480 seconds]
<jhovold>
steev: me neither
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
SSJ_GZ has joined #aarch64-laptops
Lucanis has quit [Ping timeout: 480 seconds]
xroumegue has quit [Ping timeout: 481 seconds]
xroumegue has joined #aarch64-laptops
aceridus has quit [Remote host closed the connection]
<Leandro[m]>
does the gb2 have some form of linux support already mothenjoyer69?
<mothenjoyer69>
Leandro[m]: it does, there were a few patches merged into 5.17 if i recall correctly, however it requires some work to be done on the DSI -> eDP bridge driver to enable support for the second DSI channel.
<Leandro[m]>
hmmm
<Leandro[m]>
damn just checked locally, thats... expensive
<Leandro[m]>
ill probably just get gbg
<Leandro[m]>
or that one acer
<Leandro[m]>
acer is more likely tho
<Leandro[m]>
but gbg would be cool so i can help
<mothenjoyer69>
how about a galaxy book s instead :P /s
<Leandro[m]>
checked, simillarly priced to gb2
<mothenjoyer69>
it is a shame, the AMOLED panel on the Galaxy Book 2 is gorgeous, but i'm not sure where to even begin with the driver...
<jenneron[m]>
are you sure you need 2 dsi and not dsc?
<javierm>
mothenjoyer69: about the deferred_device_timeout=30, that seems to be an issue since 6.0 but for some reasons 6.1 made it more easy to be triggered
<mothenjoyer69>
good point, but still, its not currently capable of working. once i finish this semester of study i might have another look at it, but the offer is still there if anyone else is more interested than me.
<jenneron[m]>
mothenjoyer69: there is a postmarketOS contributor who has some experience with bridges and may be interested, I can ask him
<jenneron[m]>
but what country are you from?
matthias_bgg has quit [Ping timeout: 480 seconds]
iivanov has quit [Quit: Leaving...]
jhovold has quit [Ping timeout: 480 seconds]
aceridus has joined #aarch64-laptops
<javierm>
robher: hi, do you have any thoughts on the thread about probe deferral timeout and optional device links?
<javierm>
robher: trying to figure out if I should just built-in the clk drivers in the fedora kernel or attempt to make the driver core to behave better
<steev>
javierm: i haven't actually tried the patch... maybe i should
<robher>
javierm: oh, is the timeout no longer a debug option? (JK)
<javierm>
robher: no, now is the default...
<steev>
i also don't understand why increasing that timeout actually makes it boot faster
<javierm>
steev: please do and provide your tested-by if solves your issue too
<javierm>
steev: yeah, that's surprising
<robher>
javierm: yeah, I know. Ultimately I think we need a way for userspace to say 'done'.
<javierm>
robher: so the timeout now enabled by default and set to 10 secs, which for distros that build a lot of stuff as a module is not enough
<javierm>
robher: exactly but until we have that I believe that we should keep the behaviour that was since forever to not expire
<robher>
javierm: I thought the timeout reset on each probe.
<javierm>
robher: it does yes, but only if hasn't expired before
<robher>
so there's a 10 gap of no driver modules loading?
<robher>
10sec
<javierm>
robher: so what happens in the fedora kernel is 1) initcalls are done and the timer starts 2) expires and -EPROBE_DEFER is not returned anymore and 3) modules are loaded and registering drivers is a no-op
<javierm>
robher: yup, may be that systemd is doing something silly, or some unit files should be disabled, I need to figure out why it takes that long
<javierm>
but I believe that's an orthogonal bug
<javierm>
robher: my thinking now is that we should deocuple relaxing the optional links to allow probing from disabling probe deferral
<steev>
javierm: hm... it doesn't seem to here
<steev>
seeing if i can ssh into the machine now
<javierm>
steev: that's with v6.1-rc4 ?
<steev>
rc5
<steev>
whatever is in torvalds as of a few minutes ago
<javierm>
steev: can you share your dmesg output ?
<steev>
let me reboot it and see if it made it that far
<robher>
javierm: Seems reasonable to me, but I've not followed the optional links part closely.
<javierm>
robher: so my understanding is that the timeout was enabled by default to allow drivers that have optional links to be probed even if the drivers providing the optional suppliers are not available
<javierm>
robher: I think then that we can have a fw_devlink_timeout=10 param or something
<javierm>
but keep the probe deferral timeout disabled
<javierm>
so that the drivers with optional links can be probed after some time but drivers with required links are deferred
<javierm>
and fw_devlink_timeout can be enabled by default with 10 or whatever while deferred_probe_timeout default remains -1 by default
<javierm>
robher: thanks. I wanted to know your thoughts to see if it was worth to keep pushing for this or just give up
matthias_bgg has joined #aarch64-laptops
<robher>
javierm: Makes sense and is aligned with my original motivation for all this (which was adding non-existent providers in DT breaking working boards).
<javierm>
robher: exactly. And that's also my motivation to add a /sys/kernel/debug/devices_deferred entry, but with the timeout that's not that usable
<javierm>
because then you have devices that failed to probe but just because the probe deferral timed out
<javierm>
so make troubleshooting / debugging harder to fix the DTB or .config to add the dependencies
<steev>
javierm: ah, it doesn't seem to reach a point that it's writing logs :(
<javierm>
steev: oh :(
<javierm>
so maybe is a regression in -rc5 ?
<javierm>
did you try without that patch?
<steev>
removing again; i *think* i did, but life has been a bit rough the past few days so memory is fuzzy
<javierm>
steev: hehe, I can relate
<javierm>
robher: and dianders just made a great remark about this, maybe the optional links should be just disabled after initcalls are done? There's no point to have a timer for this
<javierm>
we already do if (!IS_ENABLED(CONFIG_MODULES)) but probably needs to be done unconditionally
<javierm>
because my patch should set to -1 which means that would never timeout
SSJ_GZ has quit [Ping timeout: 480 seconds]
<robher>
javierm: I think people want optional links in modules.
<javierm>
robher: I see, and they just hope that 10 secs is enough for systemd/udev/kmod to register those
<javierm>
robher: Ok, I can look to add that fw_devlink_timeout= param thn
<robher>
javierm: yeah, *shrug*
<javierm>
robher: that could still be default to 10 secs or whatever and add that as a debug option to extend it
<javierm>
what I think is a regression is that we are suddently make the probe deferral to be time bound while it wasn't the case before
<javierm>
*making
<javierm>
a nice characteristic of probe deferral IMO was that it was simple and easy to reason about. The driver just keep probing until the deps are meet or remains in the probe deferred list
<javierm>
it wasn't efficient but it was quite effective
<javierm>
steev: and with my patch (but without 30 secs timeout) it doesn't boot?
<steev>
correct
<steev>
(and even adding the timeout, it seems to ignore, but i guess that is to be expected?)
<javierm>
strange, I did test on my chromebook and it had the same effect than a 30 secs timeout
<javierm>
steev: not really, because that's only the default
<javierm>
passing a deferred_probe_timeout=30 in the cmdline should overwride the -1 set by my patch
<steev>
i thought so too - then again, people are reporting theirry's patch fixes their issue (on sc8280xp even) but on the thinkpad it still freezes (but brian's patch works)
<steev>
so maybe the thinkpad is special and/or it's something different that manifests the same way