<Marijn[m]>
This is XA2 Ultra (sdm630), do you want me to check other phones?
<Marijn[m]>
Still have a lot to rebase on 5.19 rc's
<konradybcio>
please check some dpu
<Marijn[m]>
That's the plan, and I'll m-ay-be (no promises!) be able to try it tonight
Daanct12 has quit [Remote host closed the connection]
pevik_ has joined #linux-msm
diederik_ has joined #linux-msm
diederik has quit [Ping timeout: 480 seconds]
diederik_ is now known as diederik
<calebccff>
sibis: it was the first call, I commented it out and the pattern seems to be that changing ownership works as long as remote is false, giving access to the modem always fails
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #linux-msm
<calebccff>
vkoul: regarding Pixel 3, GPI DMA doesn't seem to work properly for touch, it only works with i2c-gpio
<vkoul>
calebccff: not all controllers support gpi, does this one support, can you share the kernel log
<calebccff>
vkoul: https://p.calebs.dev/d5a4a8@raw maybe something funky with this downstream driver, it doesn't print the same messages I had when trying to use an upstream one
<vkoul>
I have tested i2c touch using this and yes it used GPI
<calebccff>
vkoul: removing the dma properties in DT yields "[ 7.652202] geni_i2c 888000.i2c: Failed to setup GPI DMA mode:-19 ret" which can only be hit when GENI_IF_DISABLE_RO & FIFO_IF_DISABLE
<vkoul>
i think this is downstream touch driver though which I am not sure where I got :-)
<calebccff>
vkoul: yeah that's the same driver I'm using, i think there's been a regression in GPI DMA
<vkoul>
which branch are you on, time to get my pixel out then.. I can rebase above on upstream and test again
<calebccff>
most things work except the modem won't boot, and this GPI DMA bug
<calebccff>
would appreciate it a lot if you can give it a spin :>
<calebccff>
sibis: sorry I misread your message, yes rmtfs probes successfully (and assigns memory access to the modem), it's only the MPSS region which fails
<calebccff>
I've validated against downstream and I'm fairly certain the memory region and size are correct, it's slightly bigger than default
pevik has quit [Ping timeout: 480 seconds]
<aka_[m]>
<Marijn[m]> "That's the plan, and I'll m-ay-..." <- have you managed to try?
<aka_[m]>
i have some inner hope its f for you too so it won't be my fault xd
<Marijn[m]>
aka_: It's not night yet :)
<Marijn[m]>
But you can try with 5.18 just in case?
<aka_[m]>
then means i have to rebase some patches and im lazy by design.
<Marijn[m]>
Better be lazy than overworked 😅
pespin has quit [Remote host closed the connection]
jhovold has quit [Ping timeout: 480 seconds]
<aka_[m]>
<Marijn[m]> "Better be lazy than overworked 😅" <- worse when you have to be both, but you have to work for living,unless you are 0.0000001% of population of owners.
<Marijn[m]>
Everyone has or should work for a living
<Marijn[m]>
That's why I'm not very active here ;)
<calebccff>
ichernev[m]: you could post your tool to the linux-arm-msm mailing list and point out your findings, maybe send it as a patch to add it to scripts/
<ichernev[m]>
calebccff: the current script has a lot to evolve. One of the biggest gaps is in the fact that spm driver specifies types of regs and its not clear which reg is which type (unless you have a working device). So ideally this data will be published somewhere (pref in repo) ... also the stuff it can detect can be broadened
<calebccff>
ichernev[m]: right, that makes sense, imo getting it out there would help solve some of your "lack of device" and "lack of correctness" issues
<ichernev[m]>
I did comment about the reg type in my rfc, nobody said a word
<ichernev[m]>
Also, so far I only have one other device type list (from konrad). If I get more I can make a submission to cover all PMs