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
hexdump02 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
bibikski has quit [Read error: Connection reset by peer]
chrisl has joined #aarch64-laptops
<steev>
amstan: what you mean? they bought the radeon mobile unit ages ago (and its why adreno is an anagram of radeon)
<steev>
oh, you mean the driver itself?
<amstan>
steev: freedreno being the open source implementation of the gfx driver
<steev>
yeah i figured it out (eventually)
<steev>
i thought theyve contributed (a little) over the years to it, but robclark could probably say best :P
<robclark>
mostly on the kernel side, but more recently some small things on mesa side... expect to see more as time goes on
chrisl has quit [Ping timeout: 480 seconds]
krei-se- has joined #aarch64-laptops
bibikski has joined #aarch64-laptops
krei-se has quit [Ping timeout: 480 seconds]
<bibikski>
bamse: So I tried that and made some decent progress but it tried to run the arm binaries. But I am able to load ubuntu on the machine. I tried doing mkosi on ubuntu but I needed to install pacman. I couldn't get far in that task. Investigating ways to go from ubuntu on the arm machine now
<anthony25>
ha no sorry, I'm stupid, it's not about the same driver
icecream95 has joined #aarch64-laptops
<icecream95>
I looked at the ath12k panic bug a while ago, and I suspect it's easy enough to fix, but never got around to recompiling the kernel to test
<HdkR>
Maybe it needs a newer mesa for x1p to be enabled?
<apple-corps[m]>
I might be SOL'd until a driver is released which may never happen since it's not an x1e. I am thinking perhaps these wayland compistors don't support software rendering.
hexdump01 has joined #aarch64-laptops
<apple-corps[m]>
But gnome3 seems to be working...
<apple-corps[m]>
hard to imagine that would make a difference but I can try upgrading
<bamse>
apple-corps[m]: i'm quite certain that we're missing some required patches for the gpu to come up...
<HdkR>
I guess the gpuid probably differs for the x1p as well? Would need to be added to mesa
<bamse>
yes
tobhe_ has joined #aarch64-laptops
<robclark>
so the purwa variant on x1/x1p will need a device table entry on kernel and mesa side... not something I can easily figure out w/out android device using same SoC, but otherwise it should be trivial.. but I expect/hope for some help from qc on that soon.. until then it is sw rast
tobhe has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
<apple-corps[m]>
Do you all know if the hdmi out port will work or if usb-c (dp?) out will work. I have my doubts but just curious if I can use an external monitor
<robclark>
that, afaict, should be all dts... it works on some devices, just depends on someone figuring out the dts bits
<robclark>
should be pretty much agnostic of purwa vs hamoa since display controller appears to be the same in each
<robclark>
the cpu cluster arrangement and gpu appear to be the main differences
chrisl has quit [Ping timeout: 480 seconds]
eluks has quit [Remote host closed the connection]
<JensGlathe[m]>
„Only“ the type-c connectors work for now, with 2 lanes, only, but up to hbr3. I can attach via adapter and directly. For the hdmi port no luck yet.
mbuhl has quit [Remote host closed the connection]
mbuhl has joined #aarch64-laptops
mbuhl has quit [Remote host closed the connection]
<apple-corps[m]>
Jens Glathe: thanks. I will give my monitor a shot.
chrisl has joined #aarch64-laptops
mbuhl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
jglathe_volterra has quit [Quit: Leaving]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
ungeskriptet_ has joined #aarch64-laptops
ungeskriptet has quit [Ping timeout: 480 seconds]
eluks has joined #aarch64-laptops
ungeskriptet_ has quit [Remote host closed the connection]
ungeskriptet has joined #aarch64-laptops
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #aarch64-laptops
xbjfk has quit [Remote host closed the connection]
xbjfk has joined #aarch64-laptops
xbjfk has quit [Remote host closed the connection]
xbjfk has joined #aarch64-laptops
xbjfk has quit [Remote host closed the connection]
xbjfk has joined #aarch64-laptops
xbjfk has quit [Remote host closed the connection]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
jsmet[m] has joined #aarch64-laptops
jsmet[m] has quit [autokilled: Spambot. Mail support@oftc.net if you think this is in error. (2025-03-15 10:00:29)]
icecream95 has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
Rayyan has quit [Remote host closed the connection]
Rayyan has joined #aarch64-laptops
ungeskriptet_ has joined #aarch64-laptops
ungeskriptet__ has joined #aarch64-laptops
ungeskriptet has quit [Ping timeout: 480 seconds]
ungeskriptet_ has quit [Ping timeout: 480 seconds]
<kuruczgy[m]>
anthony25: Yep, I would appreciate that, thanks. (Though if it works I will still want to hunt down the original sources before packaging, I assume it will be a driver series from LKML + some other hacks + dts)
chrisl has joined #aarch64-laptops
<anthony25>
it's multiple series
<anthony25>
from what I understand
chrisl has quit [Ping timeout: 480 seconds]
ungeskriptet has joined #aarch64-laptops
<bryanodonoghue>
anthony25 you can take the ov02c10.c file directly as at the tip of tree and the dts for the slim7x
ungeskriptet__ has quit [Ping timeout: 480 seconds]
krei-se has joined #aarch64-laptops
<anthony25>
great, thanks!
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<bryanodonoghue>
kuruczgy[m] if you are on jhovold branch then just switch to the branch above
<bryanodonoghue>
i stack my patches on top of that branch
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<kuruczgy[m]>
Thanks, that's useful to know. Compiling now.
<kuruczgy[m]>
Btw latest firmware update (slim 7x) seems to have messed with fan curves, it's much quieter know when compiling the kernel. Wonder it there is a perf impact...
<kuruczgy[m]>
It's not overheating, and according to htop it's still running at 3.4 GHz, interesting...
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<kuruczgy[m]>
It compiled in 26m, so maybe a bit slower? I remember measuring 21m a few months ago, but this could also just be due to newer kernel having more code
<kuruczgy[m]>
bryanodonoghue: anthony25: I have the kernel, what's the required userspace stack? (It does not seem to work just out of the box.)
<anthony25>
I haven't tried it yet
<anthony25>
normally, none, if you do `cam -l` it should be listed
<anthony25>
and you need the v4l2 stack
<bryanodonoghue>
apt-install libcamera-tools
<bryanodonoghue>
yay -S libcamera-tools
<bryanodonoghue>
or similar
<bryanodonoghue>
cam -l
<bryanodonoghue>
if that works
<bryanodonoghue>
qcam
<bryanodonoghue>
if that works
<bryanodonoghue>
cheese
<bryanodonoghue>
which tests libcamera to pipewire
<bryanodonoghue>
if that works
<bryanodonoghue>
firefox -> about:config video pipewire thing true
<bryanodonoghue>
media: i2c: ov02c10: Get the OF clock rate
<bryanodonoghue>
Date: Sat Mar 15 21:47:39 2025 +0000
<bryanodonoghue>
Add support to get the mclk rate specified in dts.
<bryanodonoghue>
from the same branch
chrisl has quit [Ping timeout: 480 seconds]
<steev>
jhovold: 12 hours (as of now) of uptime here at home, and not seen the issue with your patch applied
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
icecream95 has joined #aarch64-laptops
<icecream95>
kuruczgy[m]: The frequency reported by the kernel doesn't change when thermal throttling
<icecream95>
I haven't tested this, but I think perf stat might show the true frequency, since it derives it from the cycle count
<icecream95>
But maybe throttling should be seen as a good thing, since it improves efficiency :)
<icecream95>
I often limit the CPU to clock speeds as low as 1 GHz, since it's still reasonably fast but much more efficient
<HdkR>
kuruczgy[m]: htop reads a value that doesn't change when throttling. You need to read `/sys/devices/system/cpu/cpufreq/policy*/cpuinfo_cur_freq`
<HdkR>
I hit this issue a few weeks ago, was really confusing
<kuruczgy[m]>
Thanks, will look at those when I do the next kernel compile
<kuruczgy[m]>
bryanodonoghue: Picked that commit, no change, `cam -l` still does not find any cameras. (The "supply [...] not found, using dummy regulator" messages are still present in dmesg, not sure which messages I should be looking at.)
<icecream95>
HdkR: Are you sure? cpuinfo_cur_freq doesn't change for me when throttling.