marvin24 has quit [Ping timeout: 256 seconds]
marvin24 has joined #tegra
<digetx> jenneron[m]: if lp2 cpuidle doesn't work for efi, shouldn't we disable it in the device-tree? either remove nvidia,suspend-mode or set it to <3>
<jenneron[m]> ok, I will look at it
<digetx> jenneron[m]: you probably will also need to set entry point to __tegra_cpu_reset_handler in acpi_parking_protocol_cpu_boot()
<digetx> although, maybe no
<digetx> __tegra_cpu_reset_handler won't work without additional changes, but it should work as-is using the secondary_startup()
<digetx> maybe that acpi parking needs to be wrapped into firmware_ops if entry point is entry point needs to be set before each suspend
<jenneron[m]> maybe leanderglanda can look at it
<digetx> you should check first whether cpuidle works with a disabled lp2, it already could be enough that the reset vector is initialized at a boot time
gouchi has joined #tegra
<leanderglanda[m]> I'm currently debugging what's wrong with ACPI Parking Protocol. Right now it fails in `acpi_parking_protocol_cpu_boot`. (`mailbox = ioremap(cpu_entry->mailbox_addr, sizeof(*mailbox));` returns null)
<leanderglanda[m]> But to be honest I don't really get why it fails. Nothing should have changed 🤷‍♂️
<digetx> you should need to reserve that mailbox memory using reserved-memory in device-tree
<leanderglanda[m]> Kernel gets the memory map from UEFI, and that memory map already contains these addresses as reserved.
<leanderglanda[m]> I'm trying a normal linux-next kernel now, applied the patch and now I'll see if that boots. Just in case grate-linux makes the issue.
<digetx> there was a warning previously from that ioremap in your log, maybe it's less permissive now
<leanderglanda[m]> grate-linux is not the issue.
<leanderglanda[m]> ACPI Parking Protocol is really broken in the latest kernel versions.
<digetx> you should find the place in the code that rejects ioremap
<leanderglanda[m]> ```if (WARN_ON(pfn_valid(pfn) && mtype != MT_MEMORY_RW))
<leanderglanda[m]> return NULL;``` in arch/arm/mm/ioremap.c (around line 290)
<leanderglanda[m]> if (WARN_ON(pfn_valid(pfn) && mtype != MT_MEMORY_RW))
<leanderglanda[m]> return NULL;
<digetx> ah
<leanderglanda[m]> mtype is `MT_DEVICE`
<DavidHeidelberg> digetx Hey, can u read pstore stuff from ramconsole (3.4)?
<DavidHeidelberg> I recall u had patch for ramconsole ( https://gist.github.com/digetx/b24e38ed7c10dcaea0a1bda39c406c0a ) on modern kernels for compat reasons, but asking for sure
<leanderglanda[m]> <leanderglanda[m] "mtype is `MT_DEVICE`"> If I remember correctly pfn should be 82002/3/4 (debugged yesterday)
hexdump0815 has joined #tegra
<digetx> DavidHeidelberg: do you mean to read upstream pstore from older downstream kernel?
<DavidHeidelberg> digetx boot latest kernel with pstore; read pstore from ramconsole on downstream 3.4
<hexdump0815> does anyone here know if suspend ever worked properly on nyan big (acer cb5 311 chromebook with tegra k1) on mainline?
<hexdump0815> i did some debugging with CONFIG_PM_DEBUG and it looks like all the stages from /sys/power/pm_test are running fine
<hexdump0815> looks like somehow the system does not enter the low level suspend state properly in the end
<hexdump0815> similar question regarding the soc-therm driver - does anyone know if it was every properly working on mainline for this device?
<digetx> leanderglanda[m]: I remember having a similar problem with the simple-framebuffer, the ioremap was failing the same way in older kernel versions, but it got fixed in the newer kernels, maybe you should take a look what API uses simple-framebuffer for memory mapping
<hexdump0815> tagr: cyndis: maybe any idea regarding the above?
<leanderglanda[m]> digetx: OK, thank you.
<digetx> DavidHeidelberg: ramconsole and pstore are not compatible, you can't read pstore from ramconsole; you can enable the ramconsole on newer kernel using my patch and then read it from 3.4
<digetx> grate-kernel has ramconsole too, that gist patch should be outdated now for the more recent kernels
<DavidHeidelberg> digetx thank you
<digetx> hexdump0815: it's likely that soctherm was tested only on tk1
<digetx> the easiest solution could be to enable software thermal throttling
<digetx> nyan has lm90 which should be connected to cpu/soc
<digetx> lm-sensors should see it
<digetx> and temperature should be high when cpu is hot
<digetx> it also should be possible to use soctherm for sw throttling
<leanderglanda[m]> digetx: A small little progress update: CrackTheSurface got the TCover to work for the first time 🥳.
<leanderglanda[m]> Probably not ready for grate-linux yet, some details need to be worked out.
<digetx> what is TCover
<leanderglanda[m]> the keyboard you can plug into the surface RT. Until now a USB keyboard was necessary.
<digetx> nice
<digetx> hexdump0815: try https://dpaste.com/FJCDFYYE9
<leanderglanda[m]> digetx: Right now hotplug doesn't work. Would need a kernel module.
<leanderglanda[m]> i2c_check_7bit_addr_validity_strict needs to be modified. Right now a simple `if (addr == 0x00) return 0;` does the job. But I guess this fix should only exist if you build for surfaceRT.
<digetx> yes
<jenneron[m]> will of_machine_is_compatible("microsoft,surface-rt") be true in this case?
<digetx> yes
<jenneron[m]> thanks
<leanderglanda[m]> digetx: This is from simplefb.c. It uses ioremap too
<jenneron[m]> digetx: display doesn't work without `nvidia,panel = <&panel>;`
<jenneron[m]> maybe something else is missed in DT
<jenneron[m]> leanderglanda: can you confirm?
<leanderglanda[m]> display doesn't work. That's right.
<leanderglanda[m]> But what should I change exactly in dt?
<leanderglanda[m]> jenneron: I can confirm. We need this in device tree, if it isn't in there display doesn't work.
<jenneron[m]> ok, thanks
<digetx> the lvds coded powerdown B2 gpio should be active low
<digetx> *codec
<digetx> encoder
<jenneron[m]> yes, you're right
<leanderglanda[m]> Me and CrackTheSurface are working on a pull request. WIll add it to there
<leanderglanda[m]> active low doesn't work.
<jenneron[m]> works for me
<m4t> digetx: cool, glad it's not just me :)
lahvuun has joined #tegra
<digetx> leanderglanda[m]: simplefb uses ioremap_wc()
lahvuun has quit [Quit: ZNC 1.8.2 - https://znc.in]
lahvuun has joined #tegra
lahvuun has quit [Client Quit]
lahvuun has joined #tegra
lahvuun has quit [Client Quit]
lahvuun has joined #tegra
lahvuun has quit [Client Quit]
lahvuun has joined #tegra
lahvuun has quit [Quit: ZNC 1.8.2 - https://znc.in]
lahvuun has joined #tegra
lahvuun has quit [Quit: ZNC 1.8.2 - https://znc.in]
lahvuun has joined #tegra
<m4t> digetx: https://lkml.org/lkml/2021/7/3/9 will try reverting
<m4t> latest grate seems OK with that reverted, thanks
<digetx> awesome
<m4t> hmm the sensor is gone though, i have CONFIG_TEGRA30_TSENSOR=y per /proc/config.gz
<m4t> [ 0.056445] thermal_sys: Error: Thermal zone name (tsensor-channel0-thermal) too long, should be under 20 chars
<digetx> thanks, I changed the name yesterday and missed that error
<m4t> noticed this, i think it started recently:
<m4t> [ 1.088622] tps65910 1-002d: failed to register tps65910-pmic regulator
<m4t> checking syslog for the first instance of it
<m4t> seems to have started when i upgraded to 5.13.0-rc6-next-20210618
<m4t> but i do not update that frequently, so it may have started earlier
<m4t> i don't see recent commits to tps65910.c or tps65910-pmic.c
gouchi has quit [Remote host closed the connection]
<digetx> I know what's the problem, it's harmless, will add patch to silence the error message
<m4t> 5.13.0-rc2-next-20210520 was OK, 5.13.0-rc6-next-20210618, 5.13.0-rc7-next-20210625, and 5.13.0-next-20210701 show the failure
<m4t> k
<hexdump0815> digetx: it looks like your thermal patch is doing what it is supposed to:) - thanks a lot
<hexdump0815> digetx: how is the soctherm state (if it exists there) for the older tegra socs - is it working well there? iirc it did not work properly too there and you at some places also did regular opp throttling - right?
<hexdump0815> digetx: on nyan big i'm getting this on startup: https://pastebin.com/raw/JXgNdyfr and i'm not sure where it gets those wrong values from - looks a bit like wrong data type
<digetx> soctherm driver supports only T124/210
<digetx> the values are okay, they mean that thermal core disabled the low temperature threshold
<digetx> that info message is misleading, it should be a debug message, I'll add patch to silence it
<hexdump0815> digetx: thanks a lot, that might be good idea ... regarding those strange values: shouldn
<hexdump0815> digetx: shouldn't it read the trip temps etc. from the dtb and display them there instead?
<hexdump0815> digetx: oh - it looks like it actually reads the trips
<hexdump0815> digetx: is 60c the max temp the tegra124 should run at? looks a bit low to me ... but iirc it was somehow auto-shutdown when it got slightly higher - which somehow does not really fit the high trip points in the dtb
<digetx> it's not the max temp, you can set it to a higher value; passive trip won't cause the shutdown
<digetx> we should probably use the lm90 for the skin temperature
<digetx> hexdump0815: https://dpaste.com/78FZH98BD
<hexdump0815> digetx: thanks a lot - will try tomorrow