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)
<bamse>
qzed: i see the things i would expect, but i can double check on my side...i had mp usb working at one point on the sc8180x as well
<bamse>
steev: yeah it's looking quite good, doing some final cleanup to the dts patches...just got caught in 1.5 weeks of travel
<qzed>
got the phys described based on the windows driver (correctly, I hope)
<qzed>
the controller is still a work-in-progress though
<bamse>
the ss controller?
<bamse>
qmp...
<bamse>
have you managed to get it working using hs-only?
<qzed>
the dwc3 thing
<qzed>
not yet
<qzed>
I have both hs and qmp/ss described
<bamse>
ahh, yeah that's the "controller"...
<qzed>
also I'm not sure if the ACPI interrupt mapping thing is nonlinear or if the DT interrupts may be wrong... works with either the ones you put in DT or the ones I derived from acpi
<bamse>
i just gave up trying to understand how to read interrupts and gpios in the acpi tables
<qzed>
yeah... that seems a bit abstracted away through 10 layers of code or so...
<qzed>
but as far as I can tell DT = ACPI - 32
<bamse>
but i saw that qualcomm kept iterating the dwc3 multi-port support...so if you have a chance, please take a look at that
<bamse>
unless they are pdc interrupts
<qzed>
yeah
<bamse>
but yes, in general the GIC_SPI interrupts are offset 32
<qzed>
I'll try, in theory I should be able to get it working since IIRC with ACPI boot the thing worked...
<qzed>
also the windows driver is written quite silly... which makes reverse-engineering the memory addresses fairly easy
<qzed>
essentially they just hard-coded everything
<qzed>
and not in the "we have 2 instances of this controller, so let's use `ctrl_base_addr + offset` for indexing"-way
<qzed>
they just added one method for mp0, another copy for mp1 with everything hardcoded and just mapped the absolute base address
<qzed>
anyway, got the phys described today, will look at the controller tomorrow
<Dylanger>
Is there somewhere I can petition to get either Google or Acer to mainline Tomato? Lol 🤦♂️
iivanov has joined #aarch64-laptops
flowriser has quit [Quit: Konversation terminated!]
matthias_bgg has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
vsp has joined #aarch64-laptops
vsp_ has joined #aarch64-laptops
vsp_ has quit [Remote host closed the connection]
<leezu>
robclark: I checked with https://github.com/ascent12/drm_info. GAMMA_LUT is not exposed as CRTC Property on sc7180. Do you have an idea about what's going wrong here?
<robclark>
leezu: yes, that is correct.. GAMMA_LUT is not supported, CTM (color transform matrix) is the way to achieve color transform
<leezu>
Thank you. Sorry for the misunderstanding before.
<robclark>
np
<leezu>
robclark: Do you know if this lack of GAMMA_LUT support is a hardware limitation or a missing feature in the driver?
<robclark>
not supported in hw.. CTM is a more general purpose feature
<hexdump0815>
Dylanger: could you maybe please do a "modprobe configs ; zcat /proc/config.gz > /tmp/some-file.txt" on your mt8195 device and paste/upload the result somewhere?
<hexdump0815>
leezu: regarding color prfiles not working - i so far have not seen any arm system where this actually works - someone with a mt8173 elm mentioned that it works for him with alpine - still have to check this out
<robclark>
GAMMA_LUT is kinda the legacy way, CTM is the new hotness ;-)
flowriser has joined #aarch64-laptops
flowriser has quit []
vsp has quit []
derzahl has joined #aarch64-laptops
matthias_bgg has quit [Ping timeout: 480 seconds]
jhovold has quit [Ping timeout: 480 seconds]
djakov has quit [reticulum.oftc.net liquid.oftc.net]
javierm has joined #aarch64-laptops
ungeskriptet[m] has joined #aarch64-laptops
jonasbits has joined #aarch64-laptops
djakov has joined #aarch64-laptops
ajhalaney[m] has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
<bamse>
anyone can point me to some details about how to create a live-cd/usb of arch for arm64?
iivanov has joined #aarch64-laptops
<bamse>
apparetly archiso depends on haskell...which we don't seem to have
<qzed>
hmm, not sure about a proper live-cd... last time I needed anything like that I just installed arch to a USB
<qzed>
not a nice automated solution though...
<qzed>
arch-install-scripts is the package for that if you want to go that route
<bamse>
right, i have a usb stick where i've just unpacked the "generic arm64" tar ball and use that as root...
<hexdump0815>
bamse: maybe https://calamares.io/ might be interesting? it is supposed to be distribution agnostic - i think the apple m1 asahi linux is using it for its installer - might be worth to have a look at their stuff
<steev>
alternatively, join us in debian-land :D
<bamse>
steev: i'm staying over here in arch land...the less time i can spend paying attention to userspace the better :)
<bamse>
steev: but naturally the plan is to update the aarc64-laptops debian installer
<steev>
but if you use debian stable, you only have to pay attention to userspace once every 6 years
<bamse>
how convenient :)
<steev>
yeah, i was thinking of doing that too
<steev>
since i restored the flex 5g yesterday
<bamse>
got my production-x13s this morning...so was just thinking that perhaps i shold try to do this in a reproducible way
<steev>
oh nice
<steev>
mine shows up tomorrow
<steev>
my best friend gets his today :(
<steev>
but he is doing windows arm stuff *sigh*
<bamse>
silly
<steev>
in his defense, he does the windows swift port
<steev>
which... is even sillier?
<bamse>
steev: but, there's a wip/sc8280xp-v5.19-rc1-crd branch in my tree...has most of the goodies for you
<steev>
i saw that
<qzed>
bamse: re usb-mp: do we need some modification in XHCI or some other things? I'm currently stuck at `Error while assigning device slot ID`...
<qzed>
some xhci command seems to be timing out
<steev>
best friend got his x13s, he says, packaging was 2/10, build is 8/10, look & feel is 9/10, feels premium looks very MBA like)