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
jelly has quit [Ping timeout: 480 seconds]
<bamse> steev: on c630 you can do "systemctl restart rmtfs" to get wifi up again (although it will disconnect your lte connection...)
<bamse> qzed: there are two typical reasons for "error without message", one is that your reserved-memory region is wrong, the other is that rmtfs isn't running
<bamse> qzed: in the first case the remoteproc crashes immediately, in the second case the remoteproc crashes after exactly 40 seconds
<qzed> okay, then it's the first one
<qzed> any chance that me essentially preventing the smmu from loading could cause this?
<qzed> bamse: with memory region you do mean "wlan_mem" right?
<bamse> mpss_mem and rmtfs_mem
<bamse> then once the modem is up, it will check with pd-mapper to see if it's supposed to run the wifi firmware on the modem, and if we tell it that it is, then it will download the wifi firmware using a variant of tftp over qrtr (which is handled by the tqftpserv tool)
<qzed> hmm okay, I have set rmtfs_mem like on the Flex and Primus, but in the Windows device manager it's at a different address...
<qzed> problem is when I use that address things don't work as well
<qzed> or rather, things go wrong earlier
<bamse> so how early does it break now? just a few seconds after or the 40 seconds after?
<qzed> give me a sec, I don't remember the specifics but way before I tried starting any services
<qzed> fails probing of qcom_rmtfs_mem with
<qzed> qcom_scm firmware:scm: Assign memory protection call failed -22
<qzed> also I'm not sure about my mpss memory definition
<qzed> I've taken that from some windows inf file
<bamse> i remember that being a complete pain on the primus...because it didn't match the documentation i had...
<qzed> 0x8d800000 with 150MB size
<qzed> seems a bit large to me
<bamse> let me double check the documentation...
<bamse> the base and size matches the latest software memory map for the platform...
<qzed> hmm, okay
<qzed> there are some comments above on how I got all that
<qzed> also it seems like some parts for the remote procs are flexible (in a certain range)?
<bamse> that looks reasonable...
<bamse> on some platforms it definitely seems that the only limitation is that all the remoteproc falls in a specific memory region...
<bamse> but on the yoga c630 it just started crashing on me when i moved things around to facilitate the larger than documented ipa_fw_mem region
<qzed> hmm, interesting
<qzed> from the inf files/registry it seems that memory regions have at minimum a length and alignment requirement, base address is optional
<qzed> so I think the PIL driver on windows just packs stuff together based on that
<qzed> also that seems to work for the adsp and cdsp, which sucessfully boot
<qzed> bluetooth is also working, so I assume regulators are set up correctly
<bamse> there might be additional limitations enforced by the security configuration as well...
<bamse> nice, sounds like i should take another look at it again then :)
<qzed> ah, guess that makes sense
<qzed> sadly the regions for the remoteproc aren't visible in the windows device manager... and I'm also not sure if that just takes definitions straight out of ACPI or if it also adds other regions
<bamse> i was not able to figure that out when i was trying to get the modem working on the c630...
<bamse> suspecting that it's hard coded in the qcsubsys driver
<qzed> just a theory though, I haven't had a look at the driver yet how it actually uses the registry entries
<steev> bamse: ah, let me try that
<steev> bamse: that didn't work for me, i'm assuming there was a kernel panic because the c630 rebooted
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
<steev> bamse: my kern.log shows... https://paste.debian.net/1241116/ - lines 1-3 are when i unbind, 4-19 are when i run bind (and the wifi device comes back, though oddly at wlan1(??), 20-27 are systemctl restart rmtfs.. and then of course 28 is when it starts back up
iivanov has joined #aarch64-laptops
iivanov__ has joined #aarch64-laptops
iivanov_ has joined #aarch64-laptops
iivanov_ has quit []
iivanov has quit [Ping timeout: 480 seconds]
iivanov__ has quit [Ping timeout: 480 seconds]
systwi_ has quit [Read error: Connection reset by peer]
systwi has joined #aarch64-laptops
Solarbaby has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
Solarbaby has quit [Read error: Connection reset by peer]
jelly has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
iivanov__ has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
iivanov_ has joined #aarch64-laptops
iivanov__ has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
iivanov__ has joined #aarch64-laptops
iivano___ has joined #aarch64-laptops
iivanov_ has quit [Ping timeout: 480 seconds]
iivanov has quit [Ping timeout: 480 seconds]
iivanov__ has quit [Ping timeout: 480 seconds]
iivano___ has quit [Ping timeout: 480 seconds]
iivanov__ has joined #aarch64-laptops
iivanov__ has quit []
iivanov has joined #aarch64-laptops
iivanov__ has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
iivanov_ has joined #aarch64-laptops
iivano___ has joined #aarch64-laptops
iivanov__ has quit [Ping timeout: 480 seconds]
iivanov has quit [Ping timeout: 480 seconds]
iivanov_ has quit [Ping timeout: 480 seconds]
SallyAhaj has joined #aarch64-laptops
iivanov__ has joined #aarch64-laptops
iivanov_ has joined #aarch64-laptops
iivano___ has quit [Ping timeout: 480 seconds]
iivanov__ has quit [Ping timeout: 480 seconds]
Lucanis0 has joined #aarch64-laptops
arnd_ has joined #aarch64-laptops
steev_ has joined #aarch64-laptops
broonie_ has joined #aarch64-laptops
samueldr_ has joined #aarch64-laptops
Lucanis has quit [synthon.oftc.net reflection.oftc.net]
broonie has quit [synthon.oftc.net reflection.oftc.net]
bamse has quit [synthon.oftc.net reflection.oftc.net]
vkoul has quit [synthon.oftc.net reflection.oftc.net]
steev has quit [synthon.oftc.net reflection.oftc.net]
samueldr has quit [synthon.oftc.net reflection.oftc.net]
arnd has quit [synthon.oftc.net reflection.oftc.net]
gwolf has quit [synthon.oftc.net reflection.oftc.net]
steev_ is now known as steev
vkoul has joined #aarch64-laptops
bamse has joined #aarch64-laptops
bamse is now known as Guest671
broonie_ is now known as broonie
gwolf has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
iivanov_ has quit [Ping timeout: 480 seconds]
<qzed> bamse: do you happen to know if PMIC numbers can vary from device to device?
<qzed> I'm trying to figure out how to configure the GPIOs for the pmc8180-e
<qzed> according to ACPI, that should be PMIC number 4
<qzed> but in pmc8180c.dtsi, number 4 is pmc8180c
<qzed> which according to ACPI should be number 2, if I'm not mistaken
<qzed> ah, I think it looks like the PMIC number is different from the actual address
<qzed> seems like pmic_number = address / 2
<qzed> that would then fit with the dt
<qzed> so pmc8180-e GPIOs should be on pmic@8 and subnode gpio@c000, does that look correct?
Guest671 is now known as bamse
<bamse> qzed: /sys/kernel/debug/qcom_socinfo/pmic_model_array is your friend
<bamse> qzed: and typically the numbering is a, c, e, g...so 'e' should probably be the third pmic
<bamse> qzed: most of the time each pmic takes up two addresses, but not always
<qzed> okay, so that gives me
<qzed> PM8150 3.0
<qzed> PM8150C 2.0
<qzed> PMK8002 2.0
<qzed> PM8150 3.0
<qzed> bamse: so that's the (for lack of a better word) linear alignment of the PMICs?
<qzed> so assuming each takes up 2 addresses that means
<qzed> pmc8180-a at address 0
<qzed> no wait...
<qzed> PMK8002 is definitely something different
<qzed> so assuming a base address "n" we'd have
<qzed> pmc8180-a at n
<qzed> pmc8180c at n+2
<qzed> pmc8180-e at n+6
SallyAhaj_ has joined #aarch64-laptops
<qzed> will do, thanks!
<bamse> qzed: then add a whole bunch of empty pmic nodes in your dts, the addresses that has a valid pmic will print a line in the log
SallyAhaj has quit [Ping timeout: 480 seconds]
<qzed> huh, so that prints
<qzed> pmic-spmi 0-00: 1e: qcom,pm8150 v3.0
<qzed> pmic-spmi 0-01: 1e: qcom,pm8150 v3.0
<qzed> and then crashes the kernel with
<qzed> spmi spmi-0: pmic_arb_wait_for_done: 0x2 0x104: transaction failed (0x3)
SallyAhaj_ has quit [Ping timeout: 480 seconds]
<qzed> ah no, just a warning
<qzed> neat, so we have
<qzed> pmc8180-a at address 0
<qzed> * and 1
<qzed> pmc8180c at address 4 and 5
<qzed> pmk8002 at address 6
<qzed> pmc8180-e at address 8 and 9
<qzed> and that seems to match ACPI perfectly (when multiplying the ID by 2)
<qzed> bamse: thanks again!
<qzed> kinda weird though: 0x02 and 0x0a cause transaction failures whereas 0x03 and 0x0b work
<qzed> but don't print anything
<bamse> that /win40
<bamse> bleh
jhovold has quit [Ping timeout: 480 seconds]
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
matthias_bgg has quit [Ping timeout: 480 seconds]
<qzed> neat, I now have a working keyboard, touchpad, battery stats, and single-touch input on the touchscreen
<qzed> on to the GPU/panel next before I go back to the wifi thing...
<bamse> qzed: so the microsoft thingie does battery management as well?
<bamse> qzed: what kernel version are you on? do you get "failed to parse dt" or something from the dp driver?
<qzed> yeah, via some TI BQ25713 PD controller if I can see that right
<qzed> I haven't tried anything with dp yet
<qzed> I've based everything so far on your wip/sc8180x-next-20220502 branch
<qzed> so 5.18-rc something
<qzed> currently still trying to work out some kinks in the HID-over-SPI driver that the touchscreen uses
<qzed> can receive input reports just fine, but something fails with feature reports (which is required for multi-touch)