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
davidinux has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
enyalios_ has joined #aarch64-laptops
enyalios has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
enyalios has joined #aarch64-laptops
enyalios_ has quit [Ping timeout: 480 seconds]
tobhe has joined #aarch64-laptops
_mike has quit [Ping timeout: 480 seconds]
tobhe_ has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
<steev>
JensGlathe[m]: yeah, msi-map gone and no iwd, and i did get the htc rx messages today :/
chrisl has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
So the picture gets a little more consistent
<JensGlathe[m]>
but how do we get to debug this
<JensGlathe[m]>
or anyone
alfredo has joined #aarch64-laptops
<steev>
i have no idea :/
ungeskriptet_ has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
ungeskriptet has quit [Ping timeout: 480 seconds]
ungeskriptet_ is now known as ungeskriptet
chrisl has quit [Ping timeout: 480 seconds]
alfredo has quit [Remote host closed the connection]
icecream95 has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<jhovold>
Here's an updated wip branch for the X13s:
<jhovold>
- enable rtc on all x1e machines using uefi offset
<jhovold>
- update blutetooth nvm config fix to v3
<icecream95>
Yay rtc, it's too easy to believe a wrong clock and accidentally think the time is hours earlier than it is...
icecream95 has quit [Ping timeout: 480 seconds]
Melody91 has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
hexdump0815 has quit [Quit: WeeChat 3.8]
hexdump0815 has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<calebccff>
jhovold: uefi provides an RTC offset?
<travmurav[m]>
iirc windows/firmware stores it in efivar in gps timestamp format
<calebccff>
hah, neat
chrisl has joined #aarch64-laptops
<maz>
maybe I should consider re-enabling EFI services...
chrisl has quit [Ping timeout: 480 seconds]
<jhovold>
maz: won't help you much, on the x13s calling the runtime service either crash the machine or return an error
<jhovold>
on x1e, they just return an error
<jhovold>
progress...
<kettenis>
jhovold: is there any evidence that frequent updates to the RTC offset variable will cause excessive wear to the flash?
<jhovold>
no, just a concern, we couldn't get any clear answers from qcom at the time
<jhovold>
but with the mitigation I added, we should be no worse off than windows which the machine was designed for
<jhovold>
I mean, we know for a fact that flash wear out, it's just a matter of not writing more often than intended
<jhovold>
and remember that this is only an issue on machines with rtc drift and tat have ntp synch enabled
<jhovold>
my t14s does not seems to drift much at all, unlike the x13s and reference designs
d0pefish has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
<d0pefish>
Hi all :) Been hacking away on a Surface Pro 11 and am in a pretty good place: booting Arch Linux ARM generic from NVMe with jhovold's kernel (today's), working USB ethernet so I can SSH in and debug. Device tree is hacked together with bits of romulus and crd; apps_rsc section regulators have been set up to match DSDT. I can't get the OLED panel
<d0pefish>
Does anyone have any ideas on where to go next? I've added my device tree and modetest output to the GitHub gist.
chrisl has quit [Ping timeout: 480 seconds]
pbsds has joined #aarch64-laptops
<JensGlathe[m]>
Have you taken a look at the x1e78100-lenovo-thinkpad-t14s.dts? It has also OLED
<Jasper[m]>
Not sure if you defined any panel parameters in panel-edp or in the dts, but those may be incorrect (according to the dpu anyway)
monkeybusiness has quit [Ping timeout: 480 seconds]
<d0pefish>
JensGlathe[m]: Yes - though using the panel section from the thinkpad dts didn't work either - the OLED in this device is a Samsung so I used compatible = "samsung,atna45af01", "samsung,atna33xc20"; a bit like the Yoga Slim 7x dts
<Jasper[m]>
@d0pefish I'm assuming it's using the timings and clocks defined by the samsung panels in that DT block
<Jasper[m]>
I'd try to find out if those line up with what's in ACPI or what Windows reports
<Jasper[m]>
Not sure which is better
chrisl has joined #aarch64-laptops
<d0pefish>
JensGlathe[m]: The mdss_dp3 / mdss_dp3_phy from that dts is now in my dts; the dmesg output is the same (drm rejecting modes)
<JensGlathe[m]>
hmm could it be that Microsoft is using a different mdss_dp?
<Jasper[m]>
JensGlathe[m]: if it reads the EDID?
<d0pefish>
I mean, to me, the dmesg is saying that the panel is on and working, it can see it's connected to dp3 and can read the EDID
<d0pefish>
I can even dump the EDID from sysfs
<JensGlathe[m]>
ok its dp3 then
<Jasper[m]>
@d0pefish are you sure the panels you listed as compatible are correct?
<Jasper[m]>
Or even have proper clock values
<d0pefish>
I actually have no idea :) So right now, I've gone back to using compatible = "edp-panel" (forgetting the Samsung stuff) - as far as I can tell the only special stuff the samsung driver does is define a non-standard power up sequence and don't define any timings - but things seem to be powering up fine with either
alfredo1 has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<d0pefish>
do timings even need to be defined when you have an EDID? I'm mainly wondering why DRM has decided the modes it got from EDID are no good
<robclark>
timings don't need to be defined.. really all the panel driver is needed for is the correct power up sequence (incl delays) so that the kernel can get far enough to actually read the edid
<robclark>
not sure why it doesn't like the timings from edid.. maybe you can dump the edid?
alfredo has quit [Ping timeout: 480 seconds]
alfredo1 is now known as alfredo
<JensGlathe[m]>
the edid for my panel had no timings... BOE 0x0c93
<tobhe>
d0pefish: the T14s OLED needs a patch to work
<d0pefish>
tobhe: Thanks - let me apply that and see if anything changes :)
<tobhe>
or rather that patch is needed with edp-panel, in theory we should be using a samsung compatible but we can't tell oled and non-oled apart based on smbios...
<JensGlathe[m]>
smoorgborg ^^^^
<d0pefish>
No change with that patch sadly
cyrinux has quit []
cyrinux has joined #aarch64-laptops
<robclark>
SDC... it is a samsung panel.. ATNA30DW01-1
<Jasper[m]>
Maybe not compatible with the panels listed?
<robclark>
that should be fine.. I think the mode is getting rejected in edp_bridge_mode_valid().. the question is why it thinks it needs such a high pixel clock
<d0pefish>
I wonder if I can somehow force DRM to use those values because the second byte (Max Link Rate) is 0x1E instead of zero (at least I think that's what it means?)
<robclark>
there is a way to override the edit.. but not sure about dpcd..
<robclark>
hmm, maybe you could use link-frequencies in dts?
alfredo has joined #aarch64-laptops
<robclark>
hmm, no
<robclark>
d0pefish: I guess you could get things to work by just hard-coding the link rate if it is zero... but probably dp helpers need a dpcd override similar to what is done for edid
<d0pefish>
robclark: It's working :D I just did a hack inside msm_dp_panel_read_dpcd() to set the second byte to 0x1E
<d0pefish>
Next up is Wi-Fi I think, but it's my birthday so I'm off to celebrate :) Will be back again soon to write stuff up or assist with getting fixes into the various kernel/distro efforts
minecrell8 has joined #aarch64-laptops
pbsds is now known as Guest6572
pbsds has joined #aarch64-laptops
calebccff_ has joined #aarch64-laptops
maz has quit [Remote host closed the connection]
maz has joined #aarch64-laptops
calebccff has quit [Read error: Connection reset by peer]
Erisa9 has joined #aarch64-laptops
Guest6572 has quit [Read error: Connection reset by peer]
Erisa has quit [Ping timeout: 480 seconds]
Erisa9 is now known as Erisa
minecrell has quit [Ping timeout: 480 seconds]
minecrell8 has quit []
minecrell has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
enyalios_ has joined #aarch64-laptops
enyalios has quit [Ping timeout: 480 seconds]
alfredo1 has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
alfredo1 is now known as alfredo
alfredo has quit [Ping timeout: 480 seconds]
hexdump0815 has quit [Quit: WeeChat 3.8]
hexdump0815 has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
SpieringsAE has joined #aarch64-laptops
<SpieringsAE>
lol my asus has the same with the same pixelclock at half the refresh rate
<SpieringsAE>
that seems very silly to me
<SpieringsAE>
1660 vback
chrisl has quit [Ping timeout: 480 seconds]
<robclark>
I'm _guessing_ that maybe you can't change the pix clk without a flicker... but if the two modes have same pix clk then you could dynamically switch between them.. my yoga 7x also has same pix clk for the two modes, now that I check it
SpieringsAE has quit [Remote host closed the connection]