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
altacus has quit [Read error: Connection reset by peer]
altacus has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
jglathe_volterra has joined #aarch64-laptops
checkfoc_us has quit []
checkfoc_us has joined #aarch64-laptops
jglathe_volterra has quit [Remote host closed the connection]
jglathe_volterra has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
rz has quit [Remote host closed the connection]
rz has joined #aarch64-laptops
f_ has joined #aarch64-laptops
rz has quit [Remote host closed the connection]
rz has joined #aarch64-laptops
mcbridematt has quit [Read error: Connection reset by peer]
jglathe_ has joined #aarch64-laptops
jglathe__ has joined #aarch64-laptops
jglathe_sdbox2 has quit [Ping timeout: 480 seconds]
<vadikas[m]>
jhovoldwill it need to implement the EL2 things to make it?
xroumegue has joined #aarch64-laptops
travmurav[m] has joined #aarch64-laptops
* travmurav[m]
wonders if safe hibernation is at all possible on a system that has like 10 extra cpus not under the os control that probably need to retain the state across hibernation and power off
<jhovold>
vadikas[m]: not necessarily, but as travmurav[m] alluded to it is going to be a bit of a challenge, if it can be done at all
<\[m]>
yeah I guess I just wanted to not have the suspend issues lol, should just turn the laptop off really hehe
<\[m]>
there's not like some rom to offload the state too?
<jhovold>
\[m]: suspend is working fine (for most people), but the power consumption is too high to leave to be able to leave it suspended for more than a day
<jhovold>
\[m]: is there any particular issue you're hitting wrt to suspend?
<\[m]>
usually it's the internal display being off and external being primary
<\[m]>
that might be userland though?
<jhovold>
which kernel are you using?
<travmurav[m]>
I think gnome (nicely) disables internal display if one docks the device and closes the lid, maybe something with lid state when going out of suspend?
<travmurav[m]>
but lid is gpio on x13s I guess
<jhovold>
and there are some known bugs in the display subsystem related to the external display:
<jhovold>
before 6.8 all display were gone if you suspended with an external display connected
<jhovold>
with 6.8, you can suspend, but better make sure not to disconnect the display while suspended...
<jhovold>
qcom is working on fixing their broken hotplug implementation, but it's not going to be done before 6.11
<\[m]>
<jhovold> "which kernel are you using?" <- 6.9rc1? just latest
<\[m]>
I use KDE too
<\[m]>
oh ok, the keep it connected while suspending is interesting - I do turn off my external screen before I suspend but leave it connected đ¤
<\[m]>
and then it does a bunch of dunno retraining / refreshing, the internal screen flickers and resize glitches couple of times
<jhovold>
yeah, turning off the display also triggers a disconnect event, it's a bit of a mess
<\[m]>
I guess we can be happy it's on the roadmap right? is this also affecting windows or it's purely for us linux users the redev
<\[m]>
problem is that this samsung crap screen (high end though) has some sort of "keep external devices on" setting, I found one setting that I turned off, but if I remember it still had the same behavior
<jhovold>
haven't noticed and internal screen flickers/resize, so maybe that's your user space indeed
<\[m]>
it's harder to verify on x13s, on my macbook air m1 it was very apparent
<\[m]>
those glitches are minimal though - might try to testdrive new KDE though I read it has default silent failing on a bunch of stuff âšī¸
<jhovold>
it's the hotplug implementation in the the linux qcom drm driver that is broken, so should just be an issue on linux
<\[m]>
so they care about our userbase đ
<\[m]>
done in 9 months-care but still đ
<jhovold>
yeah, things seems to be improving on that front, but this is a general issue that affects many qcom machines so it's not just the x13s
<jhovold>
most of the remaining issues are general qcom issues, in fact
f_ has joined #aarch64-laptops
f_ has quit []
f_ has joined #aarch64-laptops
f_ has quit [Remote host closed the connection]
f_ has joined #aarch64-laptops
KREYREN_oftc has joined #aarch64-laptops
f_ has quit [Remote host closed the connection]
f_ has joined #aarch64-laptops
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
altacus_ has joined #aarch64-laptops
altacus has quit [Read error: Connection reset by peer]
f_ has quit [Quit: WeeChat 4.2.1]
f_ has joined #aarch64-laptops
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
<\[m]>
let's play the waiting game then đ
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
hightower3 has joined #aarch64-laptops
hightower2 has quit [Remote host closed the connection]
hightower2 has joined #aarch64-laptops
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
ungeskriptet is now known as Guest725
ungeskriptet has joined #aarch64-laptops
Guest725 has quit [Ping timeout: 480 seconds]
KREYREN_oftc has quit [Remote host closed the connection]
jglathe_ has quit [Remote host closed the connection]
<pstef_>
2x the price
<pstef_>
but jokes aside, regardless of wheter I buy it or not, I welcome this development of events
jglathe_sdbox2 has joined #aarch64-laptops
<\[m]>
prolly t14s?
<\[m]>
though the s was something already before?
<\[m]>
what refers to AARCH64, the big X
<travmurav[m]>
wasn't "normal" X13 x86 and X13s "snapdragon"?
<travmurav[m]>
ah they put s on other things too
<robclark>
right.. and I don't think the s or X refer to arch
* travmurav[m]
has no guesses then
<\[m]>
never was very clear what that s meant, slim or speedy lol
<robclark>
arch == implementation detail that we probably care more about than most of their customers
<\[m]>
so yolo naming â
<robclark>
yup
<robclark>
I'm _guessing_ it will be called x13s again, but idk... does look like it should be fun at any rate.. and sounds like there are a bunch of "snapdragon X" laptops in the works from different vendors
<travmurav[m]>
robclark: I was recently thinking why dtbhack won't work for you, did you have the iommu definition with status=reserved in your kernel?
<robclark>
at one point I tried that combo, but then reverted it
<travmurav[m]>
mhm, I think in that case the overlay won't remove status=reserved for that iommu
<travmurav[m]>
but I guess it wasn't it
<robclark>
(well, assuming I copied the correct dtb to the usb-c that I've been booting from for el2... the setup is a bit awkward/manual atm)
<clover[m]>
I'll probably buy it. For work I use a lot of heavy sites that x13s is just a tad slow for but the m1 pro crushes
<travmurav[m]>
robclark: since the overlay for 8280 is actually very simple and (right now) doesn't even need symbols actually - it doesn't use any external phandles so should just apply cleanly...
<travmurav[m]>
when I was trying to bring up adsp on 7c I've spent quite a while fighting with overlays since dtb without symbols has no phandles on nodes that don't need them, so had to add the phandle values myself... xD
<robclark>
having a debug option to dump the resulting dtb back to file would be useful
jglathe_sdbox2 has quit [Remote host closed the connection]
<robclark>
heh
* travmurav[m]
hopes that if anything we can get those overlays upstream at some point so we can actually use symbols there
jglathe_sdbox2 has joined #aarch64-laptops
<travmurav[m]>
robclark: I still think you should be able to just "fdtoverlay" those in linux and check the resulting dtb, the code is more or less the same call to fdt_overlay_apply()
<travmurav[m]>
it's part of the dtc package
<travmurav[m]>
I guess if after applying the same overlays to the same dtb in linux, the resulting one works, and the one left by dtbhack still doesn't, then it would be veeeery sad...
<robclark>
yeah, but when things don't boot it is nice to be able to rule possible causes out ;-)
konradybcio has joined #aarch64-laptops
<konradybcio>
too bad we can't just ship tcblaunch.exe in linux-firmware ;)
<travmurav[m]>
well, presumably if someone cooperative has correct driver(?) signing keys, we could reimplement it but yeah
<konradybcio>
ms is not entirely known for holding onto its keys very well
<travmurav[m]>
it would probably be fun to craft a compatible PE if I ever get my hands onto an sb-off thing but there are much more issues to figure out right now I guess xD
* travmurav[m]
is still annoyed that even though he could kick off the adsp boot fsm and it reported the core has booted, he couldnt' confirm that it actually started fetching from ram
<travmurav[m]>
I also found delight in learning that modem cpu bypasses iommu and actually "just boots" via pas -_-
<konradybcio>
wait, what?
<travmurav[m]>
(but rmtfs needs extra magic to register in tz so it's still useless)
<travmurav[m]>
yeah
<travmurav[m]>
though hm
<konradybcio>
so unless booted through PIL, the smmu is in bypass!?
<travmurav[m]>
no, I think modem is not wired via iommu at all
<travmurav[m]>
but wait
<travmurav[m]>
let me sanity check myself on this
<travmurav[m]>
too bold of a claim so one mo xD
<robclark>
does it use XPU stuff instead to firewall itself? AFAIU the CrOS folks went thru all this w/ qc (since yolo, the modem can access all memory is somewhat not ok for CrOS)
<travmurav[m]>
afaik it's possible that xpus can be configured to block modem from accessing ap memory, yes, which is likely why it crashes without being able to read rmtfs region
<travmurav[m]>
but i.e. on very old things the modem was also /controlling/ some xpus and those things are something qcom doesn't want to share much about afaik so who knows how it works
<travmurav[m]>
it's definitely not mapped on iommu :P
<travmurav[m]>
I had to reconfirm because by default qcom's quirk iommu driver reads all programmed sids on boot and sets them to bypass, and when we boot after hyp, everything is set to bypass due to this -_-
<travmurav[m]>
but also weirdly I can't see /any/ iommu faults whatsoever on my thing, even if I i.e. set venus to map to wrong sids so this is an extra annoying bonus on figuring out whether adsp booted with pil or not...
<konradybcio>
i think non-cros tz has baked in security stuff
<konradybcio>
definitely about adreno
<konradybcio>
(around smmus)
<travmurav[m]>
the smmu should be fully in linux hands after SL though I think (tho iirc there was something about secure bits so maybe tz can get notifications from it)
<travmurav[m]>
I guess thinking of it, there was some special state where I could get venus with wrong iommu settings to crash reboot the system but never from trying to pil boot adsp, even after I asked it to boot from tz imem xD
<travmurav[m]>
idk if I need some extra lpass_john_the_clock, I think there is one left after I found definitions for few more
<konradybcio>
so, the current cros setup isnt enough?
<travmurav[m]>
cros doesn't use adsp at all
<konradybcio>
ugh
<travmurav[m]>
there is a PIL driver for 7c3 but i.e. the dt binding for it is wrong-ish
<travmurav[m]>
cros uses lpass hw directly on 7c1
<travmurav[m]>
which I could too, but the fun of the excercise is adsp/cdsp on i.e. x13s that are used for the battery mess
<konradybcio>
another q is whether the adsp will be able to access those without additional setup
<travmurav[m]>
would definitely need to set up iommu mappings for it
<travmurav[m]>
probably would need to carry some table in the driver since right now it expects the table to be in .elf and, obviously, it's not there for our firmware
<travmurav[m]>
otherwise I don't see hyp doing much work to kick it off, seems mostly similar to the driver I was trying to use
<travmurav[m]>
remoteproc/qcom_q6v5_adsp.c that is
<travmurav[m]>
I'm getting as far as "start timed out" with it
<travmurav[m]>
ah and i guess would need more of the "qcom,adsp-pil-mode" for clock drivers to make sure linux doesn't touch adsp's clocks
fogous has joined #aarch64-laptops
fogous has left #aarch64-laptops [#aarch64-laptops]
<robclark>
iirc amstan was playing with adsp at some point (I thought on sc7180 but might have been sc7280)
f_ has quit [Remote host closed the connection]
f_ has joined #aarch64-laptops
altacus has joined #aarch64-laptops
altacus_ has quit [Ping timeout: 480 seconds]
f_ has quit []
rz has quit [Remote host closed the connection]
rz has joined #aarch64-laptops
jhovold has quit [Ping timeout: 480 seconds]
KREYREN_oftc has joined #aarch64-laptops
jglathe_volterra has quit [Remote host closed the connection]
mcbridematt has joined #aarch64-laptops
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
hightower3 has quit []
KREYREN_oftc has quit [Remote host closed the connection]
altacus_ has joined #aarch64-laptops
altacus has quit [Ping timeout: 480 seconds]
Nios34[m] has joined #aarch64-laptops
<Nios34[m]>
travmurav hexdump01 after changing the dt a littlte while, I didn't managed to get backlight working. I don't how to define a backlight on pmic. Is it pwm-backlight? or what about its regulator? Thanks!
<Nios34[m]>
Also, I really hope I could help with the devicetree cleanup but I don't know where to start.
<bamse>
Nios34[m]: the pwm-backlight represents the backlight, power-supply provides the power to drive the backlight, the brightness is controlled by the low-level signal defined by the pwms property
<bamse>
Nios34[m]: the pwm signal comes out of a gpio, but is fed from the lpg or pwm block internally in the pmic
<bamse>
Nios34[m]: so you typically need a regulator, an enable gpio (typically), a pwm channel and the pwm's associated gpio configured
<Nios34[m]>
ah, any tricks on finding these?
<Nios34[m]>
I have no idea about the regulators. Maybe I should try them one by onr or there is a shortcut