ChanServ 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
BlueCrayon has joined #aarch64-laptops
phire_ has joined #aarch64-laptops
phire is now known as Guest304
phire_ is now known as phire
Guest304 has quit [Ping timeout: 480 seconds]
bluerise has quit [Ping timeout: 480 seconds]
<bamse>
steev: the series i posted yesterday, or the old one?
<bamse>
well, the old one doesn't apply...so i should assume the new one...
<bamse>
steev: so you booted, the apple dongle didn't show up, without reboot you then connected the hub and that showed up?
<steev>
it was on the 30th
<steev>
but yes
<bamse>
ohh, read to quickly...so i failed to spot the "mp" part :)
<steev>
i did not attempt to boot with it plugged in
<bamse>
steev: and we're on flex 5g?
<steev>
yessir
<steev>
tried both orientations
<steev>
and both ports
<bamse>
that series shouldn't affect the two visible usb ports
<steev>
ah, okay
<bamse>
it should only provide you with the webcam
<steev>
oh
<bamse>
but that does not mean that it doesn't cause issues for your primary or secondary port...
<steev>
no device :(
<bamse>
but just to confirm (again), without reboot apple didn't show up, pinebook hub does?
<steev>
correct
<steev>
actually, this time it did
<steev>
what the heck
<bamse>
okay, please do continue to test it...i'll have to check the regulators etc to see that we're not doing anything funky
<bamse>
so, do you have a picture of yourself in /dev/video0 (or whatever it is)?
<steev>
but that could be related to the dvfs patchset i pulled in just a little bit before your power key, i haven't backed it out to test
powpingdone has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
<travmurav[m]>
bamse: yeah, even on aspire1 reading EC could allow me to set correct mac addresses, so I was thinking to eventually implement an example of that, I think also things like touchpad type selection can be done like this (or by parsing ACPI since afaiu uefi code updates it on boot from the same ec registers, at least on aspire1)
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
<travmurav[m]>
kettenis_: yeah I'm wondering about something like that, on some old qcom platforms partial-goods (missing cores) are implemented by having a efuse bit that says "you have less cores" then i.e. last two cores are nopped out of the dt
<travmurav[m]>
(I think it's always last cores that are "broken" on the platforms I saw it on so I'm assuming the core ids are handled by "magic" in that case, so in a simplest case could just kill last two with a dtsi, but it gets complicated as soon as there is same-hardware-different-soc-devices)
<travmurav[m]>
but if we end up with devices that could have soc variants, being able to just set status="failed" for two x1p cores on boot would really simplify things I think
<travmurav[m]>
(and assuming that the rule of "last two cores missing" holds, there are probably many simple ways to implement this, even just reading the cpu name from smbios)
<travmurav[m]>
but doesn't seem we have anyone with access to some x1p devices here yet, so can't really know :D
akaWolf has quit [Ping timeout: 480 seconds]
akaWolf has joined #aarch64-laptops
iivanov_ has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
iivanov_ has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
broonie has quit [Remote host closed the connection]
Ariadne has quit [Read error: Connection reset by peer]
broonie has joined #aarch64-laptops
<Nios34[m]>
bamse steev Hello, fellow flex users! How is the support status of flex5g now? And btw, is the flex 5g having two charging ports or one?
<Molyuu[m]>
Is sc8180x missing dsi clocks in vanilla kernel?
<Molyuu[m]>
NULL Pointer error occurred when initializing dsi panel.
ema_ has quit []
ema has joined #aarch64-laptops
tobhe has quit [Remote host closed the connection]
tobhe has joined #aarch64-laptops
<bamse>
steev: looks like we need to figure out the pcie suspend story...as with both x13s and x1e devices...
<bamse>
travmurav[m]: interesting, i should double check the flex acpi tables...on later targets it's stored in spi nor, so we need to figure out how to read that...
<bamse>
Nios34[m]: not sure if i can call myself a "user" anymore, i just boot the flex 5g occasionally these days :/
<travmurav[m]>
bamse: fwiw on aspire1 I figured out that macs are stored there only because there were some helpfully labeled WMI functions in the acpi blobs I had to decode in some weird way
<travmurav[m]>
but from that I've learned that they basically use EC as nvram
<travmurav[m]>
and those functions helpfully named all the "slots" for data in there xD
<travmurav[m]>
since there was a getter/setter for each value
<bamse>
Nios34[m]: i do have primus (the reference sc8180x reference laptop) in kernelci...and it tells me that we have a problem with the machines not always booting...did some debugging and it seems to be related to us dropping mmcx (multimedia power rail) momentarily during boot...but i don't see why that would happen on sc8180x...
<travmurav[m]>
(and thankfully nothing else at all in the wmi part)
<bamse>
Nios34[m]: once it boots, as i reported yesterday, it seems we have a regression in the battery/usb pmic_glink driver, so that's not happy...
<bamse>
Nios34[m]: but it seems reasonably happy other than that...
<bamse>
Nios34[m]: lumag reported that external display doesn't work, so there must be some piece that never got upstreamed...so need to take a look at that
<bamse>
Nios34[m]: but in general, i used the flex5g as my main workstation for 1.5 years or so, until we got the x13s in decent enough shape...so it should be within reach
<Nios34[m]>
basme: I only booted aarch-laptops image once. All my attempts to deboostrap and compile the kernel by myself it fails to boot. It just went blank and then black then Qualcomm Crashdump
<bamse>
travmurav[m]: good to know, will check...but it's not like decompiled dsdt is the easiest to follow
<Nios34[m]>
I don't know if there is an specific kernel parameter I need to add or something
<travmurav[m]>
bamse: yeah for sure, I've spent quite a while figuring it out
<bamse>
Nios34[m]: yeah, that may or may not be the mmcx issue that you're hitting...
<Nios34[m]>
It's not strictly speaking a flex 5g. It's an ES yoga 5g. I think that might be the problem. I booted from USB
<bamse>
Nios34[m]: i believe clk_ignore_unused pd_ignore_unused are the only ones you _need_ on flex5g...but i might be wrong
<bamse>
Nios34[m]: cool would like to see that running as well...
<bamse>
Nios34[m]: but the boot crash seems to be common to all sc8180*
<Nios34[m]>
ah... any workaround?
iivanov_ has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
<bamse>
Nios34[m]: if you just hack rpmhpd to put a minimum vote of 5 on mmcx it seems to survive...
<bamse>
Nios34[m]: but the more useful thing would be to figure out why sync_state happens at a time where there are no votes from clients on this platform, when we don't see that same problem on e.g. sc8280xp
<Nios34[m]>
don't really know about that
<bamse>
i should know...
<bryanodonoghue>
steev CMA size I remember increasing on x13s but I'm not sure why TBH
<bryanodonoghue>
I'm not sure if I documented it
<bryanodonoghue>
5 megapixels * 4 frames should fit in 32 megabytes
<bryanodonoghue>
git log isn't elucidating
<bryanodonoghue>
smaller might work
<bryanodonoghue>
actually steev that just reminds me, UDMABUF on its own without a CMA heap should work
<bamse>
bryanodonoghue: that would be because as nvme and wifi comes up they allocate a bunch of dma memory...which would fail with the default 32mb
<bamse>
bryanodonoghue: and if you further allocates from that for camera (if that's what you're saying) the you're eating up our precious cma memory
<bryanodonoghue>
yep I had a memory of a commit from you for CMA in that dts
<bryanodonoghue>
discussion with distro maintainers was a NAK for DMABUF / udev and groups to allow CMA access for camera
<bryanodonoghue>
so its UDMABUF instead
<bamse>
without having seen the details, it sounds wise to not allow the user to eat up the buffer space we need for e.g. nvme later
iivanov_ has quit [Read error: Connection reset by peer]
iivanov has joined #aarch64-laptops
<JensGlathe[m]>
Hmm CMA_SIZE_MBYTES is it, with it to 128 I get no bsod with 4k@60 on DP-3
<JensGlathe[m]>
It was the single change I isolated that makes the display wake up from sleep and not turn up blue (irrevocably, box is slow afterwards and you need to reboot) across 6.7..6.11rc2
<JensGlathe[m]>
@bamse @robclark how do you count the first 16 lines on a 4k screen
<robclark>
I guess the question was more whether you get the first part of the image before it underflows.. but it looks like fullscreen underflow
<bamse>
JensGlathe[m]: if you would have said "it looks more like 27"...then i would have said "yes, that's what i meant"
<JensGlathe[m]>
that's 32"
<bamse>
JensGlathe[m]: but as far as i can see, you have 0 rows of data on your screen
<bamse>
JensGlathe[m]: clicked some more of your links...so does this coincide with the clock warning?
<JensGlathe[m]>
it always looks that way when it happens. Just came back to the suspended display and... it came up @4k. with CMA_SIZE_MBYTES=128. Linux volterra 6.11.0-rc2+ #29 SMP PREEMPT_DYNAMIC Tue Aug 13 15:51:35 CEST 2024 aarch64 aarch64 aarch64 GNU/Linux
<bamse>
JensGlathe[m]: how close to upstream is your tree?
<JensGlathe[m]>
The clock warning is what you get in dmesg when you're ssh'ed in and the display wakes up to bsod. And tested with 2 different 4k displays, 2 different volterra boxes, consistent behaviour. This doesn't happen when you limit resolution to 2560x1440
<JensGlathe[m]>
just a sec
<bamse>
JensGlathe[m]: okay, so to conclude...with 4k@60 you get that clock splat and a blue screen...
<bamse>
JensGlathe[m]: unless you set cma to 128mb?
<JensGlathe[m]>
yes, consistently. since 6.6ish. And yes.
<bamse>
didn't think we could do 4k@60 all the way back in 6.6...
<JensGlathe[m]>
I did this since 6.4ish I guess, was quite wowed
<bamse>
nice, i had problems with external displays (after tricking it into 4-lanes), because without dual sspp i didn't have sufficient juice to draw all them pixels
<JensGlathe[m]>
77 commits
<JensGlathe[m]>
on mainline 6.11-rc2, but mustly johan / steev collection
<JensGlathe[m]>
Hmm this is volterra box, with a minidp on mdss0-dp3
<bamse>
i run x13s with 0 patches, so please consider sending the volterra specifics upstream
<JensGlathe[m]>
same tree is also for x13s
<bamse>
well, you shouldn't need 77 patches, and i would be happy to see the volterra support upstream - even though i failed to get my hands on the hardware
<JensGlathe[m]>
I would love to, but I'm blocked by initial work from Merck Hung. konradybcio encouraged / assisted to bring it upstream, but it apparently stalled with Merck Hung (the original author).
<JensGlathe[m]>
you can condense it to maybe 3 patches for the kernel. One is dtb for blackrock, one is arm-smmuv3 wired up for EL2 use but still reserved (no side effects known), one is dedicated dtb for EL2 use.
<bamse>
JensGlathe[m]: do you have a branch somewhere?
<bamse>
JensGlathe[m]: doesn't smmu-v3 patch just sit in my inbox waiting for someone to say "yes i want this!"?
<JensGlathe[m]>
yep
<JensGlathe[m]>
maybe it is, konradybcio prepared one. Mine builds on his
<travmurav[m]>
fwiw with slbounce overlays I provide whatever Konrad submitted and no one complained so far, so I'd say it's good to go in with status=reserved
<bamse>
i'm conceptually not against merging it...but i don't think i got a clear cut answer from konrad when i asked if it worked and was tested (or he answered and i still hesitated?)
<bamse>
travmurav[m]: thanks
<travmurav[m]>
(fwiw also pushed similar thign for x1e if anyone wants to test)
<bamse>
and i merged the cmd-db fix somewhere as well...
<travmurav[m]>
bamse: yeah cmd-db is needed for 7c el2, thanks for getting it in
<JensGlathe[m]>
running a box (and knowing some other users) since ~Feb 2024
<bamse>
so, i presume the only problem then is lacking remoteproc support on those platforms?
<travmurav[m]>
yes
<konradybcio>
and then fuel gauge / charger drivers ;)
<bamse>
konradybcio: not just pmic_glink?
<konradybcio>
or i guess.. remoteprocs work too..
<travmurav[m]>
I almost got adsp booting on 7c with the cros driver a while back - boot fsm reported that it kicked it but hexagon never fetched code
<travmurav[m]>
but afaiu hyp code has mostly same code as that driver: it kicks some clocks then does those same register writes
<bamse>
no comment...
<Jasper[m]>
certified nda moment
<travmurav[m]>
and since I restrain myself from using any leaked things and only decompiled what I could dump from my device, it's a bit of extra pain to figure out what it wants
agl has quit [Ping timeout: 480 seconds]
<konradybcio>
did the cros folks even end up booting the dsps after all?
<calebccff>
travmurav[m]: konradybcio: I think there are also quite a lot of fuse and tz differences between WoA and cros hw
<calebccff>
DSP bootflow might be subtly different
<calebccff>
XPUs are probably configured differently as well
<travmurav[m]>
I think modem is yes but adsp/cdsp is a bit simpler and protection is mostly based on hyp/iommu per my understanding
<travmurav[m]>
at least that's my current impression
<travmurav[m]>
so I think it /should/ be possible to bring them up, and I believe there is not much work required beyond /knowledge/ of which resources has to be kicked for a particular hexagon
<travmurav[m]>
on 7c I've certainly gotten venus and modem up (venus exactly same as cros, modem exactly same as el1 woa + assigning memory to vmid in el1 uefi before switching since tz has different api)
<travmurav[m]>
(actually now I second guess myself on if I ended up implementing the assigning memory hack or not since I didn't seem to push it to gh, might have only researched it)
<travmurav[m]>
though I think I recall having wifi in el2 so I probably did something
<steev>
Nios34[m]: still a few patches outside the kernel, but they're getting there.
<Nios34[m]>
can you give a pointer to that tree? 👀
<Nios34[m]>
I'd really want to test that out (since my machine won't boot on mainline :-/
<steev>
sure let me push it somewhere
<steev>
a couple of these aren't *strictly* needed, but i do like to test things
<steev>
but they're all things that (should) eventually end up upstream
<FarchordSteveCossette[m]>
Have you guys gotten sound to work?
<steev>
on which
<steev>
i don't think sound ever worked on the flex
<steev>
Nios34[m]: fwiw, i'm already installed, not booted, command line is overkill that isn't fully needed but i've been too lazy to clear it out and is
<steev>
bamse: one other thing i notice... it takes ~10 seconds for bottom ( https://github.com/ClementTsang/bottom ) to get data when launchin on the flex5g, but there is no such delay with the x13s or c630
<steev>
and not like, the first time, but every time
<bamse>
steev: iirc it's ath driver that's querying the hardware and waiting for some timeout
<steev>
ohhh
<steev>
thats right
<bamse>
haven't checked with kalle why that is, but it seems consistently broken
<steev>
[ 2487.554195] ath10k_snoc 18800000.wifi: failed to synchronize thermal read
<steev>
yep
<steev>
interestingly enough, it does end up in there though
<bamse>
you do get a valid temperature out of it?
<bamse>
i was under the impression that the read fails and btm skips the sensor
<steev>
it claims it is thermal_zone17 (wlan_thermal) and 29C
<konradybcio>
wlan-thermal comes from tsens on the soc
<konradybcio>
the ath10k thermal device could be called ath10k_thermal
<konradybcio>
it would also come with hwmon called ath10k_hwmon
<bamse>
phy0 (ath11k_hwmon) on x13s...so quite likely ath10k_hwmon
colemickens has quit []
z3ntu has quit []
MrCatfood[m] has quit [Quit: Bridge terminating on SIGTERM]
KieranBingham[m] has quit [Quit: Bridge terminating on SIGTERM]
go4godvin has quit [Quit: Bridge terminating on SIGTERM]
FarchordSteveCossette[m] has quit [Quit: Bridge terminating on SIGTERM]
\[m] has quit []
freekurt[m] has quit [Quit: Bridge terminating on SIGTERM]
JensGlathe[m] has quit [Quit: Bridge terminating on SIGTERM]
LucasTreffenstdt[m] has quit [Quit: Bridge terminating on SIGTERM]
bumble[m] has quit [Quit: Bridge terminating on SIGTERM]
sera[m] has quit [Quit: Bridge terminating on SIGTERM]
valentine has quit [Quit: Bridge terminating on SIGTERM]
lollaritits[m] has quit [Quit: Bridge terminating on SIGTERM]
danielt has quit [Quit: Bridge terminating on SIGTERM]
MarcoZiebell[m] has quit [Quit: Bridge terminating on SIGTERM]
konradybcio has quit [Quit: Bridge terminating on SIGTERM]
Dylanger[m] has quit [Quit: Bridge terminating on SIGTERM]
jenneron[m] has quit []
clover[m] has quit [Quit: Bridge terminating on SIGTERM]
Segfault[m] has quit []
Eighth_Doctor has quit []
Jasper[m] has quit [Quit: Bridge terminating on SIGTERM]
steveej[m] has quit [Quit: Bridge terminating on SIGTERM]
nscnt[m] has quit [Quit: Bridge terminating on SIGTERM]
qzed has quit [Quit: Bridge terminating on SIGTERM]
zeph[m] has quit [Quit: Bridge terminating on SIGTERM]
amstan has quit [Quit: Bridge terminating on SIGTERM]
Nios34[m] has quit [Quit: Bridge terminating on SIGTERM]
anonymix007[m] has quit [Quit: Bridge terminating on SIGTERM]
smedir[m] has quit [Quit: Bridge terminating on SIGTERM]
louist103[m] has quit [Quit: Bridge terminating on SIGTERM]
nirik has quit [Quit: Bridge terminating on SIGTERM]
frozen_cheese[m] has quit [Quit: Bridge terminating on SIGTERM]
Integral[m] has quit [Quit: Bridge terminating on SIGTERM]
vk6[m] has quit [Quit: Bridge terminating on SIGTERM]
Sayatomoki[m] has quit [Quit: Bridge terminating on SIGTERM]
Painkiller995[m] has quit [Quit: Bridge terminating on SIGTERM]
Adam[m] has quit [Remote host closed the connection]
anarsoul[m] has quit [Write error: connection closed]
mahmoudajawad[m] has quit [Remote host closed the connection]
jakepi[m] has quit [Remote host closed the connection]
DocGalaxyBlock[m] has quit [Remote host closed the connection]
strongtz[m] has quit [Quit: Bridge terminating on SIGTERM]
ndi_heise[m] has quit [Read error: Connection reset by peer]
noferrets[m] has quit [Read error: Connection reset by peer]
TSIN[m] has quit [Remote host closed the connection]
DeepGaurav[m] has quit [Remote host closed the connection]
Molyuu[m] has quit [Remote host closed the connection]
JosDehaes[m] has quit [Remote host closed the connection]
travmurav[m] has quit [Remote host closed the connection]
DanielSchfer[m] has quit [Remote host closed the connection]
Molyuu[m] has joined #aarch64-laptops
Molyuu[m] has quit [Remote host closed the connection]