<pak0>
yeah, I have no idea what Qualcomm's Little Kernel is or should be
<travmurav[m]>
pak0: it's a bootloader, you don't need this file
<pak0>
toh, cool!
<pak0>
Thanks!
Caterpillar has quit [Ping timeout: 480 seconds]
Caterpillar has joined #linux-msm
pespin has quit [Remote host closed the connection]
pespin has joined #linux-msm
srinik has quit [Killed (NickServ (Too many failed password attempts.))]
srinik has joined #linux-msm
Caterpillar has quit [Quit: Konversation terminated!]
<Daanct12>
pak0: in case if you did not know, QCOM uses Little Kernel on old SoCs, for the new SoCs they're now using EDK2/EFI
<Daanct12>
that's a fact :)
<Daanct12>
but i believe some newer socs based on older ones are still using LK
<pak0>
Thanks, Danct! I can't believe the 845 is considered old now - it feels like a beast in the G7 Thinq but it is old indeed (5 years already?). The 765G in the Velvet is plenty for me as well (but the Pixel 4a 5G is just... way worse than the spec would suggest)
<pak0>
ehh... lets see if can I figure out how to use pmbootstrap to compile the kernel (and see how I've messed up the panel naming in kconfig)
<Daanct12>
haha yes! on the mobile world things tend to get obsolete very quickly..
<Daanct12>
if you look at the pinephone it's not very different from a computer from 2008 or something i guess :P
<pak0>
The A64 in the PinePhone is showing its age for sure
<pak0>
this is odd - I've added SW49410 entry but I can't enable it in menuconfig 😕 `Symbol: DRM_PANEL_SW49410 [=n]`
<pak0>
oh... I need to find OF
<pak0>
eh, I get the same for SOFEF00 so I take it either that my env is borked or that it's expected
Daanct12 has quit [Quit: WeeChat 4.1.2]
mripard has joined #linux-msm
<z3ntu1>
lumag: seems aux-hpd-bridge.c driver continously probes and unprobes in linux-next on my FP5, probably because pmic-glink and the rest are all kind of in limbo until adsp has started which only happens quite a bit later
<lumag>
z3ntu1, but pmic-glink provides altmode from the beginning.
<lumag>
So it is other way around.
<z3ntu1>
originally I was seeing some refcount/dev_put warning from drm_aux_hpd_bridge_unregister_adev but just adding some prints to the register and unregister functions shows it's just called many many times per second (and because of the logging everything slows down :D)
<z3ntu1>
lumag: with an extra `#include <linux/of.h>` in aux-bridge.c to compile, the warnings appear to be gone, but seems device is still not really booting. Might be caused by my tree though maybe..
<lumag>
z3ntu1, What errors out now?
<lumag>
Still aux-hpd-bridge?
<z3ntu1>
right now I see no errors weirdly, last message is from ufs but it's just staying there and not doing anything
<z3ntu1>
okay so without pmic-glink added it boots up fine, will try and find out which part of it blocks boot
<lumag>
ack
<z3ntu1>
so pmic-glink itself is okay (for just charger, fuel gauge, etc), just hooking up dp causes this behavior. I'll enabled CONFIG_DEBUG_DRIVER, maybe that'll say something interesting
<lumag>
z3ntu1, yes, please
<z3ntu1>
yeah something seems to be stuck in a loop there but the log scrolling by on the phone screen doesn't work for reading what's on there, need to grab the serial console to tell you more
<z3ntu1>
just based on non-verbose logs it looks the same, still stuck
<pak0>
has someone seen this error when compiling the kernel? `drivers/input/rmi4/rmi_driver.c:1223:46: error: passing argument 1 of 'rmi_driver_of_probe' from incompatible pointer type`
<calebccff>
ah, i changed the link rate in the sensor driver but im guessing that's probably backwards
andrey-konovalov has joined #linux-msm
<calebccff>
bryanodonoghue: \o/ i got data from the TPG
<bryanodonoghue>
good so everything pretty much works
<bryanodonoghue>
sensor config
<calebccff>
bryanodonoghue: the driver on the lists only supports 2 lane, but on the op6 it's 4-lane, it should work in 2-lane mode with the upstream driver right?
<bryanodonoghue>
should
<bryanodonoghue>
if you could extract the init sequence from downstream for 4 lane though..
<calebccff>
i did pull the downstream init sequence, that's what I've been trying to use anyway
<calebccff>
but i'll give 2-lane a shot
<calebccff>
huh should data-lanes start at 0 or 1?
<bryanodonoghue>
doesn't matter as I recal
<bryanodonoghue>
it counts the number of entries
<calebccff>
ah nice
<bryanodonoghue>
ah buggy
<bryanodonoghue>
ah "do what my bitmap says" :)
<calebccff>
lol
<calebccff>
db845c uses it inconsistently
<bryanodonoghue>
yeah its pants, needs fxing
<calebccff>
hm, kinda hard to debug this when the only feedback is "it hangs"
gpiccoli has joined #linux-msm
gpiccoli_ has quit [Read error: Connection reset by peer]
gpiccoli_ has joined #linux-msm
gpiccoli has quit [Ping timeout: 480 seconds]
_whitelogger has joined #linux-msm
pak0 has quit [Remote host closed the connection]
<calebccff>
bryanodonoghue: well i went poking around some more, turns out the sensor registers prooobably follow the MIPI CCI spec (at least most of them), and would you believe it it's only using 3 lanes
<calebccff>
even though the schematics clearly indicate that 4 lanes are hooked up -_-
<calebccff>
and not a difference does it make... :/
<lumag>
z3ntu1, could you please upload preprocessed DTS source somewhere?
pespin has quit [Remote host closed the connection]