robclark 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
checkfoc_us has quit []
checkfoc_us has joined #aarch64-laptops
KREYREN_oftc has quit [Ping timeout: 480 seconds]
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
todi has quit [Remote host closed the connection]
altacus has joined #aarch64-laptops
altacus_ has quit [Ping timeout: 480 seconds]
<travmurav[m]>
robclark: yeah, to me this feels like "two iommus" fun again, having a full log would be really nice to have...
iivanov has joined #aarch64-laptops
<travmurav[m]>
robclark: actually, given you have the os running already in el1, maybe you can just add the ramoops node with console and huge ecc into the base dt, crash it in el2, then boot in el1 and get the files from pstorefs?
<travmurav[m]>
tho I guess the rebooting kernel would start writing to the same console region
<travmurav[m]>
probably can still dump the ram region with "dmem" in efi shell and massage the hexdump back into ascii with xxd, but not sure about ecc then...
iivanov has quit [Quit: Leaving...]
iivanov has joined #aarch64-laptops
iivanov has quit []
iivanov has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
<dgilmore>
of course when I am travelling my x13s decides to play up. linux is not finding the nvme drive. the bios loads everything from it
<jglathe_x13s>
it doesn't show 0002:00:01:00.0, huh... mechanical issue?
svarbanov has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
KREYREN_oftc has joined #aarch64-laptops
indy has joined #aarch64-laptops
indy_ has quit [Ping timeout: 480 seconds]
<vadikas[m]>
have possibly a stupid question -- trying to get current battery charge level from sysfs, but /sys/class/power_supply/qcom-battmgr-bat/charge_now: No data available
<vadikas[m]>
can someone advice me how can I get the current battery charge?
<travmurav[m]>
charge as in battery % (capacity)?
<travmurav[m]>
or "energy" (watts iirc)?
<vadikas[m]>
I was trying to get capacity to measure the suspend drainage -- I'm doing some research on optimising it
<travmurav[m]>
("charge" is amps version of energy)
<vadikas[m]>
yep
<travmurav[m]>
youu probably want "capacity" file then
<travmurav[m]>
but well, not sure what x13s battmgr tracks even
<vadikas[m]>
there is no capacity file
<vadikas[m]>
but I probably can calculate it manually
<travmurav[m]>
at the very least, the files for all of this should be in the sysfs
<travmurav[m]>
the energy vs charge makes sense, driver exposes both but one of the two is -enodata
<travmurav[m]>
vadikas: I guess using energy_now and calculating the diff in microwatts would be more precise anyway if the value is there and it's sane
<vadikas[m]>
yes, it does, but it doesn't )
<vadikas[m]>
according to the code it can be requested to get the data in Wh or Ah, but not together, so half of the data is missing
<travmurav[m]>
the data is the same just in different formats
<vadikas[m]>
(not really missing, it can be calculated, but ...)
<_[m]123>
weird freeze just now on x13s, I logged in, the laptop was open but at least the screen was off - 5seconds all ok then it froze 🤷
<_[m]123>
will try to do ssh next itme it happens no time atm
<robclark>
so something unhappy about nvme.. which may or may not be related to iommu..
indy_ has joined #aarch64-laptops
minecrell has quit [Ping timeout: 480 seconds]
<jglathe_x13s>
robclark you're on EL2?
<robclark>
presumably
<robclark>
I suspect working vs not may come down to probe order?
<jglathe_x13s>
what does lspci say
<robclark>
don't get to console with el2 boot.. lspci with "normal" boot has nvme on 0002
<jglathe_x13s>
do you have a dmesg when on EL2? also, a cat /proc/interropts|grep mmu ?
altacus has joined #aarch64-laptops
<robclark>
I've got that screenshot I pasted a few min ago
<robclark>
but not getting to console so don't really have anything more
<robclark>
what exactly is the issue with having both smmu and smmu-v3? I guess I should try to understand that better. Looks like iommu-ops, etc, are per-device, so that shouldn't be a problem
JoshuaAshton has joined #aarch64-laptops
altacus_ has quit [Ping timeout: 480 seconds]
<robclark>
looks like iommu is kinda assumed to be per-bus_type, but that should be ok, AFAICT all the pcie are using smmu-v3
<jglathe_x13s>
ok thanks, this looks like the iommu-map did not hold on your dtb
<jglathe_x13s>
you get these when iommu-map is wrong or not there
<jglathe_x13s>
and also the delay of 1 minute is usual then
<jglathe_x13s>
I can hack up an x13s variant of the dedicated EL2 dtb if you want to try. You only need the dtb, no dtbhack
<jglathe_x13s>
so arm-smmuv3 is active
<robclark>
sure.. or I can re-instate the patch that describes the smmuv3 and just comment out the status="reserved" line
minecrell3 has quit []
minecrell has joined #aarch64-laptops
<robclark>
oh, and comment out zap
<robclark>
nope, seems to be the same
<robclark>
fwiw, the patch I used was your "arm64: dts: qcom: sc8280xp: amend definition for arm-smmuv3, set iommu-map" .. with status line commented.. or, hmm, maybe it needs status="okay"
<jglathe_x13s>
Hmm you could try. But you need status=okay, and you can't boot to EL1 with this. ZAP shader needs to be removed, too, from the x13s dts. Therefore my offer, only changes in x13s dts with the arm-smmu v3 and iommu-map patch.
martiert has joined #aarch64-laptops
<robclark>
that is basically what I tried.. although I was still using dtbhack, just to install the config table
<robclark>
I think status="okay" is the default but will try that in a bit
<robclark>
ok, I switched back to dtb loading on kernel cmdline (skipping dtbhack.efi completely, but otherwise using the same dtb as before.. and I get to a shell
minecrell4 has joined #aarch64-laptops
<robclark>
in _theory_ the dtb should have been the same in either case, but that does not appear to be the case
<jglathe_>
to boot just load slbounce.efi and afterwards boot with the dtb
<jglathe_>
\o/
krzk_ has joined #aarch64-laptops
krzk has quit [Read error: Connection reset by peer]
<jglathe_>
arm-smmuv3 needs to be enabled, zap shader removed, that should do it
indy has joined #aarch64-laptops
<jglathe_>
do you have pcie devices functional?
<robclark>
it would be nice to know what the resulting dtb was after dtbhack.. I guess I can hack up something to write the resulting dtb back to the ESP
krzk_ has quit [charon.oftc.net helix.oftc.net]
indy_ has quit [charon.oftc.net helix.oftc.net]
pstef has quit [charon.oftc.net helix.oftc.net]
minecrell has quit [charon.oftc.net helix.oftc.net]
xroumegue has quit [charon.oftc.net helix.oftc.net]
sporos11[m] has quit [charon.oftc.net helix.oftc.net]
<travmurav[m]>
I'd also like to know why it's broken so maybe we can fix the overlays to be more robust (though I guess for now it's still a "hack" per the name since it's kinda annoying to deal with overlays when upstream has no symbols)
<travmurav[m]>
robclark: alpine has aarch64 image :>
<travmurav[m]>
jglathe_: robclark wrt remoteprocs, I've spent a couple hours today trying to understand how PAS in hyp works, seems like we have a nice "qcom_q6v5_adsp.c" driver that likely gets us most of the way there but I couldn't get it working on 7c1 today
<travmurav[m]>
hyp brings up more resources (probably clocks) that are not described in upstream lpasscc/gcc and since all I see in the decompiler are the mmio addresses, it's total pain to figure out what exactly is needed
<ungeskriptet>
Hi dianders, I have a tablet with a GT7385P touchscreen IC which seems to be very similar to GT7375P and I'm having problems with getting the driver to probe. The errors I'm getting in dmesg are:
<ungeskriptet>
[ 0.985644] i2c_hid_of_goodix 13-005d: Fetching the HID descriptor
<ungeskriptet>
[ 0.986876] i2c_hid_of_goodix 13-005d: Failed to fetch the HID Descriptor
<ungeskriptet>
[ 0.986951] i2c_hid_of_goodix 13-005d: Power on failed: -19
<ungeskriptet>
What I'm confused about is that the Android DTS defines three supplies: AVDD, VDD and VDDIO, and according the datasheet I found on the internet (if I understand it correctly), there are only 2 supplies required. Also, the almost identical 2020 version of the tablet has a AVDD_EN pin, which doesn't seem to exist on mine. Both tablets have the same
<ungeskriptet>
panel and touchscreen IC
<travmurav[m]>
probably would be very hard to get anywhere without i.e. FLATs for the soc but I'm not interested in touching leaked resources and I somehow doubt someone at qcom would make any HRD available in public xD
<robclark>
travmurav[m]: yea, I think when I get some time (maybe next weekend), I'll try to hack up something to write the dtb back to a file in the ESP so I can compare
<travmurav[m]>
robclark: yeah, just that I expect it should be equivalent to "fdtoverlay"
<jglathe_>
oh nice... that qcom_q6v5_pas module needs to be loaded in initramfs modules, or you land in adsp hell. Need to document what I've fought with
<travmurav[m]>
so maybe can make a new dtb using fdtoverlay and my overlays and if it crashes the same way, we would know the overlays are faulty...
<travmurav[m]>
jglathe_: PAS is gone in el2 since the hyp is gone, so we need to manually kick off the remoteproc cpu, for which the different ^^ driver exists
<travmurav[m]>
but one needs to know exactly the resources needed in each soc
<travmurav[m]>
I could match most of the stuff with the hyp code on 7c1 but it was not enough
<travmurav[m]>
the adsp firmware has never started
<jglathe_>
oh even nicer. So, we need to scan a little with some error handlers?
<travmurav[m]>
I'm afraid there is nothing to "scan"
<jglathe_>
too complex?
<jglathe_>
iirc you mentioned a dma channel
<travmurav[m]>
for venus we only need iommu settings since the driver is already written properly and used in prod (at least for 7c)
<travmurav[m]>
for adsp... adsp is not used on chromebooks
<travmurav[m]>
so there is a half baked driver with a few usage examples for 845 and 7c3 but not i.e. 8280xp
<travmurav[m]>
and figuring what is needed for it to work requries REing the hyp firmware most likely
<travmurav[m]>
in which case, at the very least, there is no names for clocks it uses if the clocks are not defined in the clock driver
<travmurav[m]>
could call them "John", "Bob", ... I guess xD
<jglathe_>
quite a silly game all that
<jglathe_>
Bob sounds nic
<travmurav[m]>
and so far my experience with qcom sharing documentation for things like that is: "qcom had two veery cool pdfs available for a 2014 platform but they since deleted them"
<HdkR>
(Aspyr's GL renderer is the CPU bottleneck on my desktop, not unexpected)
<_[m]123>
runs fine seems 🙂 for now
<HdkR>
Yea, early game it's great
<HdkR>
Graphics bench is quite late game
<_[m]123>
lol shatterijng my hope 😄
<HdkR>
D3D11 renderer has the best turnout. It hit 56FPS in the bench and CPU limited. Which we are going to have fixes for
<_[m]123>
still you don't need that many fps for role based
<konradybcio>
\: i'm afraid you don't know the principal rules of gaming
<_[m]123>
s/many/much/
<konradybcio>
there is never enough and never too much fps
<HdkR>
:D
<_[m]123>
can you simulate d3d12 is direct 3d dirextx 12?
<HdkR>
better FPS means you can clamp it and have btter battery life
<HdkR>
_[m]123: Running the game under Proton which translates it to Vulkan
<_[m]123>
you need some startup options for that mm
<HdkR>
It'll be a nightmare since the 2K Launcher is broken under FEX atm. Not sure why yet
<_[m]123>
I'm gaming while streaming 2k 60hz lol not even burning myself
<dianders>
ungeskriptet: I don't have any real special knowledge of goodix touchscreens. ...but I guess the fact that you managed to do an i2c transfer without the transfer itself reporting an error implies that the touchscreen is at least powered correctly? In other words you didn't trip the message `failed to fetch HID descriptor`. Any chance you just need longer delays while the touchscreen powers itself up before it reports back to
<dianders>
you?
KREYREN_ has joined #aarch64-laptops
KREYREN_oftc has quit [Remote host closed the connection]