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)
matthias_bgg has quit [Ping timeout: 480 seconds]
matthias_bgg has joined #aarch64-laptops
FizzBuzz has joined #aarch64-laptops
FizzBuzz has quit []
derzahl has quit [Remote host closed the connection]
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
derzahl has joined #aarch64-laptops
derzahl has quit [Remote host closed the connection]
derzahl has joined #aarch64-laptops
derzahl has quit [Remote host closed the connection]
derzahl has joined #aarch64-laptops
derzahl has quit [Remote host closed the connection]
derzahl has joined #aarch64-laptops
flowriser has quit [Ping timeout: 480 seconds]
iivanov has quit []
<Dylanger>
Hey all, I plan on buying the Acer Spin 513 as soon as possible, this device runs the MediaTek Kompanio 1380, what should be the first steps in trying to get Mainline Linux working on this device?
<Dylanger>
<travmurav[m]> "the device I'm looking at is an..." <- Honestly, I'd recommend Chromebooks, much more open
derzahl has quit [Ping timeout: 480 seconds]
travmurav[m] has quit []
travmurav[m] has joined #aarch64-laptops
travmurav[m] has quit [Quit: Reconnecting]
travmurav[m] has joined #aarch64-laptops
flowriser has joined #aarch64-laptops
<travmurav[m]>
hm, seems like I was (or still are) silenced on the irc side because I messed up talking with the nickserv, this is awkward...
<travmurav[m]>
But I was wondering on how much can I expect out of a snap 7c based WOA laptop (acer aspire 1) considering I can write a DT for it
flowriser has quit [Ping timeout: 480 seconds]
<bamse>
travmurav[m]: i expect that you would be able to get it booting and somewhat functional, with a few code additions/modifications you should be able to get it usable
<travmurav[m]>
Cool, thanks!
<travmurav[m]>
Is there any resources I could look at to know how those things usually boot? Though only considering getting one for now, would be nice to know what I can potentially get myself into
derzahl has joined #aarch64-laptops
<qzed>
bamse: I've tried to log regulator, power-domain, and clock changes
<qzed>
does it look like anything is off that should be on?
<qzed>
I'm also not sure if this shows everything or if I should try again at a lower level (gcc, dispcc, pinctrl, ...)
<qzed>
I've also tried to compare things with ACPI tables and a couple of things could be missing
flowriser has joined #aarch64-laptops
jhovold has quit [Ping timeout: 480 seconds]
flowriser has quit [Ping timeout: 480 seconds]
jhovold has joined #aarch64-laptops
jhovold has quit [Ping timeout: 480 seconds]
<bamse>
qzed: which problem are you looking at?
<qzed>
display being black after loading msm/gpu stuff
<bamse>
how come you're running with only 2 data-lanes?
<bamse>
logs and dt looks good to me, not sure what might be the problem :/
<bamse>
most dp issues shows up in the log in one way or another
<qzed>
I've changed that after I noticed in debugfs that it's only using two lanes
<qzed>
setting that to two makes the link training warnings go away
<qzed>
ie link training doesn't fail the first couple of times and seems to succeed directly
<bamse>
i'm puzzled about that, because i think the flex5g is 4 lane as well...but now that i did the sc8280xp edp i realized that i'm disabling the second lane pair
<bamse>
i.e. with the upstream driver link training will fail if you decide to go 4 lanes with the current edp driver...got a patch coming for that ;)
<qzed>
ah nice
<qzed>
I still get the `disp_cc_mdss_edp_pixel_clk_src: rcg didn't update its configuration`
<bamse>
finally figured out the last pieces yesterday, so now i have display on all 6 DP-connectors on my devboard :)
<qzed>
but that only seems to happen the first time it tries to update that clock
<bamse>
yeah, that's by design
<qzed>
ah okay
<qzed>
awesome!
<bamse>
design is wrong...just to clarify
<bamse>
i tell the clock framework about the new rate, then we turn on the pll
<qzed>
okay, thanks
<bamse>
but the rate update triggers the clock framework to reparent the downstream clock (iiuc), which gives you that warning, because the pll isn't yet on
<bamse>
so making the clock state reflect the actual clock should solve that
<qzed>
ah i see
<qzed>
I've also tried to compare before and after in debugfs and the only thing that seems to get disabled is `gpu_cc_cxo_clk`
<qzed>
I assume that's not relevant for basic tty output?
<bamse>
no
hightower2 has joined #aarch64-laptops
<qzed>
any ideas what I could try short from dumping registers?
hightower2 has quit [Ping timeout: 480 seconds]
<qzed>
hmm, I can't even read regulator states from some registers, can I?
<bamse>
no :/
<bamse>
but if your regulators are off (or wrong) you should have problems with the link training
<qzed>
right... also reading edid I guess, and there's a gpio that's pulled up if the panel vreg is on (which is up...)
<qzed>
so I'm fairly sure that the panel itself is on... but other stuff?
<qzed>
the schematics I have shows some vdd_gfx being supplied from s6a...s10a, but I guess that's some power rail
hightower2 has joined #aarch64-laptops
systwi_ has quit [Ping timeout: 480 seconds]
<qzed>
also should there be some pattern visible during (what I assume is) link training when the backlight is active?
<qzed>
one sec, there's a merge issue when cherry-picking the first commit, I'm trying to resolve that
iivanov has quit [Ping timeout: 480 seconds]
<qzed>
I do have the second patch
<qzed>
and the resets = ... is also set
<qzed>
bamse: is something supposed to happen when I write 1 to that? I still get a black screen
<qzed>
is it possible that I'm just missing some config optioN?
systwi has joined #aarch64-laptops
<bamse>
qzed: black, or that striped black that you shared above?
<qzed>
total black
<bamse>
what's the picture you shared then?
<qzed>
that flashes briefly (sub-second) when I assume link training is going on
<qzed>
but could be something else around that time
<bamse>
qzed: why does the backlight turn off after that?
<bamse>
who tells it to turn off?
<qzed>
I don't think it does turn off
<bamse>
ok
<qzed>
I can control it and it seems like the panel shows black but the backlight is on
<bamse>
yeah, it should show you a colorful checkboard pattern over the entire screen
<bamse>
so it seems likely that your phy settings are off...
<qzed>
whelp, it's not doing that...
<bamse>
or maybe something missing in the dp controller settings, although the test thing should do most things for you
<qzed>
any tips on how I could check that?
<qzed>
I'm trying to check the external right now... maybe that could give us any clue.
<qzed>
(if I can manage to make the usb stuff load in the init kernel at some point...)
<bamse>
isn't the prox resolution rather high?
<bamse>
seems reasonable that it would be 4 lane for that, so getting that working seems like a good idea
<qzed>
2880x1920
<qzed>
alright, I'll see if I can figure something out
<bamse>
if only i made a comment about that change, i think it might have been that tx1 + TXn_TRANSCEIVER_BIAS_EN should be 3 and edp + DP_PHY_CFG_1 should be 0xf...
<bamse>
instead of 0 and 3, in qcom_edp_phy_power_on()
<qzed>
I can give that a try in a bit... as soon as my kernel boots again (currently trying to figure out what I need to build in for the usb/dp changes)