<konradybcio>
here it's rb5 messing with my plans again :P
addcninblue has joined #linux-msm
addcninblue has quit [Remote host closed the connection]
<bamse>
konradybcio: perst et al?
<konradybcio>
yep
<konradybcio>
i managed to commonize it, say for a difference or two in rb5
<bamse>
i think it's best to push them out to the board, that way we don't get surprises when people change the common thing
<konradybcio>
well, if you say so, i might just do that
<konradybcio>
though rb5 only adds output-low on top of the common thing
<bamse>
which should be unecessary to do...
<konradybcio>
do you have this abomination of a pcb perhaps?
<bamse>
which pcb? rb5?
<konradybcio>
yep
<bamse>
of course
<konradybcio>
would you mind checking if all of that works without output-low on perst pins?
<konradybcio>
also, would you mind if I kept gpio.h include in soc tree and rid it from board ones? it's just useless duplication as (almost) every board that boots to anything needs to set some kind of gpios
<bamse>
gpio.h in the dtsi sounds good
<konradybcio>
great, and the sdhci sleep patch seems like a perfect excuse to slap it in there
<konradybcio>
or should i make it separate..?
<bamse>
regarding perst, we request that "asserted", so as long as it's ACTIVE_LOW in DT the only thing output-low does is gives us slightly more time in the asserted state - if the bootloader for some reason left it HIGH
<bamse>
does the sleep state have anything to do with the gpio include?
<konradybcio>
well, there goes the anser
<konradybcio>
answer*
<konradybcio>
separate it is
<bamse>
:)
<bamse>
i picked up most of your patches btw
<konradybcio>
thanks :)
<konradybcio>
this time i'm doing everything so that we don't get 660 all over again..
<konradybcio>
..which is shelved until we fix smmu, really, apart from some smaller patches that i should post later this week
<konradybcio>
do you think this output-low thing could be applied globally?
<konradybcio>
pulling the pin low is a soc-specific, anyway
goepsilongo has joined #linux-msm
goepsilongo has quit [Remote host closed the connection]
<bamse>
i don't think we need to output-low anywhere
<bamse>
and it's not really soc specific, because RST# is an active-low line per the pcie specification
<bamse>
but as it's just a gpio there's nothing preventing someone from moving it...
<konradybcio>
but I do wonder whether the half-a-second or so between tlmm and pcie probe is mission critical
<konradybcio>
but then what would it be mission critical for.. pcie devices have to wait to be discovered anyway..
<bamse>
the output-low would be applied as the pcie controller is being probed
<konradybcio>
oh right because the pins have to be assigned, the definitions alone don't do anything
<bamse>
so it's a fraction of a second and if we're in need of that, then we're too close anyways
<konradybcio>
so do I get the green light to yank output-low out?
<bamse>
yes
<bamse>
and i picked up the 4 patches you just posted
<konradybcio>
great, rest of the team will be positively surprised when they wake up :)
<minecrell>
bamse: Do you know anything about the difference between all the DIAG channels provided by the modem? On msm8916 there is DIAG, DIAG_CMD, DIAG_CNTL, DIAG_2 and DIAG_2_CMD
<minecrell>
bamse: I was thinking about adding the diag port to my WWAN rpmsg control driver but to be honest I have no idea (a) which one of the channels is the right one (b) how to use diag or even (c) what to do with it :D
<bamse>
minecrell: from our point of view diag is all about routing messages between some PC tool and firmware running on the various remote processors (in particular modem)
<bamse>
minecrell: qualcomm does this with the in-kernel diag driver, but there's github.com/andersson/diag that implements this in userspace
<bamse>
minecrell: unfortunately i don't remember the exact details of the channels, but there's router/peripheral-rpmsg.c that deals with the interaction with those channels
<minecrell>
bamse: Ah you use both DIAG_CNTL/DIAG_CMD, so it doesn't seem to map to a single channel (somehow it does for MHI, strange)
<bamse>
right, there's data, control signals and some other set of control signals passed over the 3 channels
<minecrell>
I guess I'll just leave that as-is then, it's not really priority to have that through the WWAN subsystem
<bamse>
and what you can do with diag...the answer is pretty much "nothing"...it just tunnels data between the qualcomm's proprietary tools and the firmware
<bamse>
there's some potential changes to that in the pipe, but right now that's what you have
<minecrell>
bamse: Ah I see so your tool also just allows then using the proprietary tools via USB? :D
<bamse>
well, my tool allows connecting to the pc using usb, serial or sockets...i typically just use the last one
<bamse>
and then there's "send_data", which i use on the device itself for sending short messages
<bamse>
e.g. you can invoke "send_data 123 0 1 2 3", which will send a "ping" to the modem and if things works you get "123 0 1 2 3" back
<minecrell>
bamse: Is there anything useful (other than a ping) that can be done with that, or is the useful stuff only possible with the proprietary tools?
<bamse>
yes, i have similar sequences for invoking the various types of crashes on all the remoteprocs
<bamse>
and we've used it to do nv read and writes
<bamse>
but my efforts to get permission to bundle that up in a nice tool has yet to pay off :(
<bamse>
that said, there are some progress in that space, so we might see some changes there soon
<minecrell>
bamse:There is a sequence to make the remoteproc crash for testing?
<bamse>
yes
<minecrell>
bamse: Hmm, I've been looking for some way to crash the modem remoteproc for testing my bam-dmux driver, would be really helpful if you could share that at some point :)
<bamse>
sounds like motivation enough for me, i will kick the thread
<bamse>
minecrell: what's the status of the bam dmux, is it heading upstream?
<minecrell>
bamse: (If you have some time I'm looking for some feedback on the rpmsg parts for this one ^ btw :) )
<bamse>
i saw it, haven't had time to look at it yet
<bamse>
really nice to see the progress though!
<minecrell>
bamse: Generally the bam-dmux driver seems to work just fine, didn't get many complaints and it has been in postmarketOS for a while already
<bamse>
i read the code a while ago and liked what i saw
<minecrell>
Perhaps it's not too resilient yet to edge cases like the remoteproc crashing, but I'm probably going to try to address that in some follow-up patches later