ChanServ changed the topic of #linux-msm to:
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
lumag_ has quit [Ping timeout: 480 seconds]
jhovold has joined #linux-msm
jhovold has quit [Ping timeout: 480 seconds]
pespin has joined #linux-msm
irungentoo has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
irungentoo has joined #linux-msm
Danct12 has quit [Remote host closed the connection]
lumag_ has joined #linux-msm
Danct12 has joined #linux-msm
<aka_[m]> srinik: should i hook this function?:
<aka_[m]> srinik: well i meant hooking it for outputing packets as you recommend me
<aka_[m]> to see what was done in downstream
<aka_[m]> this can show LPASS set sysclk packets right?
<srinik> aka_[m]: yes, in my debug patch uncomment print_hex_dump line and add something similar in the downstream code too
<aka_[m]> ah fine, then we need to compare outputs?
<aka_[m]> i wonder tho, is there a way to outout clock values on downstream for these q6afe clocks?
<aka_[m]> i see it has digital/external nodes under /debug/clk
<aka_[m]> but no ibit and so on
<srinik> aka_[m]: if dsp is master you should able to measure MCLK and LR clock supplied to the external codec. But if you are just looking for values of clock then these should be in the apr packet dump
<aka_[m]> well i know nothing about that
<aka_[m]> there are some addons for HOSTLESS so idk
<aka_[m]> its pretty weird device because it might have TFA9890+TUSB320 switch with Audio logic or something
<aka_[m]> not sure if it connects to i2s or its just connected to analog headphone output
<aka_[m]> or both
<aka_[m]> somehow
<aka_[m]> code says it has both
<aka_[m]> for digital audio swich_gpio+hph_lr is 0 vcon1/vcon2 active low
<aka_[m]> for analog it sets audio swch_gpio+hph_lr_swch_gpio to 1
<aka_[m]> wait high "!pdata->active_low"
qyousef has joined #linux-msm
<aka_[m]> srinik: hmm
<aka_[m]> i was looking around and i noticed i enable some clocks in wcd codec node
<aka_[m]> and this one is inside struct mi2s_tx_clk
<aka_[m]> which in code seems to be called for AVS 2.7
<aka_[m]> for AVS 2.6 it enable mi2s_rx_clk_v1
<aka_[m]> seems its enabled later but gonna try anyway
<aka_[m]> well it needs atribute after all
<aka_[m]> reeee
<aka_[m]> srinik: So i tried to compile downstream and obv... (full message at https://matrix.org/_matrix/media/r0/download/matrix.org/DixLVQVokXccjqqjrnblbebh)
<Mis012[m]> `uint32_t *` surely?
lumag_ has quit [Ping timeout: 480 seconds]
anholt_ has joined #linux-msm
<aka_[m]> so i have some packets
<aka_[m]> not sure if these are proper
<aka_[m]> i guess not
anholt has quit [Ping timeout: 480 seconds]
<aka_[m]> oh fuck
<aka_[m]> it spams them since start
<aka_[m]> downstream has no dmesg -Hw
<aka_[m]> damn
<aka_[m]> something is there
<aka_[m]> after unlocking it plays some sound so i think it was time when it started qdsp again
<aka_[m]> On downstream i don't see AFE_SVC_CMD_SET_PARAM maybe im too late in log to see it and assume this is clock setting from QDSP card
<aka_[m]> there are some differences in packet dump
<aka_[m]> simillar but not same
<aka_[m]> oh my
<aka_[m]> downstream sets dai which is at @33
<aka_[m]> if i understand well
<aka_[m]> ou there is some log if i start with |head -n1000
<aka_[m]> whoa its overwriting
<aka_[m]> any idea how can i make it log it from start?
<Mis012[m]> aka_: there should be a cmdline option for buffer size
<Mis012[m]> for kmsg
<vknecht[m]> `log_buf_len=15M audit_backlog_limit=8192` ?
<vknecht[m]> aka_: ^
<aka_[m]> that into cmdline of kernel right?>
<vknecht[m]> yep
<aka_[m]> will it work with 3.10
<aka_[m]> ?
<vknecht[m]> not sure, git grep for those in source tree and see if there's a match I guess
<aka_[m]> Kinda big chungus
<aka_[m]> thing is i see no 100f3 or AFE_SVC_CMD_SET_PARAM being used on downstream
<aka_[m]> well i have no printing callback implemented
<vknecht[m]> error 404... I use this one for big pastes : https://sebsauvage.net/paste/
<aka_[m]> vknecht: oh yes removed
<aka_[m]> ree
pespin has quit []
lumag_ has joined #linux-msm
<aka_[m]> this is with callback i assume
<Mis012[m]> >`CMD: NA`
<Mis012[m]> is that "Not Available"?
<aka_[m]> its not part of defines
<aka_[m]> i found these
<aka_[m]> still not all
<Mis012[m]> well, presumably "Not Available" would be a catch-all for anything that's not there :P
<aka_[m]> i was unable to find what are these:... (full message at https://matrix.org/_matrix/media/r0/download/matrix.org/KnubOOEPpYAEIhMaheTGdscA)
<Mis012[m]> if you can delineate what stuff is sent on what occasion, maybe you could compare that to mainline?
<Mis012[m]> and possibly add prints to the clock enable/disable functions
<aka_[m]> oh nice
<aka_[m]> i started seeing some pattern
<Mis012[m]> 🙃
<aka_[m]> i assume 1 on last is CAPTURE
<aka_[m]> issue is downstream have smillar packet
<Mis012[m]> how is that an issue :P
<aka_[m]> under 0x20: but last is 0x14 and here its 0xffff0014
<Mis012[m]> mhm
<Mis012[m]> can you hack it and see if it makes a difference?
<Mis012[m]> in both downstream and mainline
<Mis012[m]> to have the other one
<aka_[m]> mainline have it this way:... (full message at https://matrix.org/_matrix/media/r0/download/matrix.org/AQYFheydupqviKUXLFSkTWEn)
<aka_[m]> issue is i don't understand where port is supposed to be
<Mis012[m]> do you have the struct?
<aka_[m]> with mainline i assume its under 0x0:last one so 7f that would fit to quin dai which is @127
<aka_[m]> and mainline one seems to not carry freq
<aka_[m]> atleast from what i see?
<Mis012[m]> you did say something about @33
<Mis012[m]> but the number after @ should be hex..?
<Mis012[m]> or is that only in downstream
<aka_[m]> nah its format is in hex here in dumps
<aka_[m]> and in case of DAI bindings are in decimal
<aka_[m]> i don;t like these packets
<aka_[m]> im sure i was sending 1536000 to that dai but it failed executing
<aka_[m]> it was stuck
<aka_[m]> i should look what happens before sending these
<aka_[m]> ah right
<aka_[m]> my setting from q6dsp appears to use AFE_SVC_CMD_SET_PARAM
<Mis012[m]> and downstream doesn't use that?
<aka_[m]> nope
<Mis012[m]> might be for a good reason :P
<aka_[m]> but why it was ok on 8953
<aka_[m]> which is newer
<Mis012[m]> ¯\_(ツ)_/¯
<aka_[m]> and v2 assume its "newer"
<Mis012[m]> this is sw defined protocol
<Mis012[m]> so the quality of qcom's sw is what you're against
<aka_[m]> so i should try look and see if i can force it to output V2 packets for that
<Mis012[m]> well, it would be pretty weird to have v2 be the older version... :P
<Mis012[m]> so I'd say that's a pretty safe assumption
<Mis012[m]> I'm starting to fall asleep, but good luck ;)
<aka_[m]> hmmm
<aka_[m]> the V1 ones seems to come out of LPAIF_BIT/OSR setting
<aka_[m]> so i might need to remove them then.
<aka_[m]> that might be this because it tried to set these on interfaces which are enabled and my q6dais consist of 0x10 primary rx 0x15 tert tx and 0x7f which is quin rx
<aka_[m]> i assume i should remove OSR clock setting
<aka_[m]> and look maybe its one of LPASS v2 clocks instead
<aka_[m]> Like this cutie:
<aka_[m]> Q6AFE_CLK(LPASS_CLK_ID_QUI_MI2S_OSR),
<aka_[m]> so in short i need to read these v2 and figure out which are set and then do 8976 sequence which will set quin osr ones after applying ibitclk
<aka_[m]> i assume i was not setting proper OSR and it was failing trying to enable port after it set IBIT but after it tried to enable it decided to hang so code was unable to toggle this off again and errored again
<aka_[m]> ok im pretty exhausted i will have look tomorrow and im sorry for this pointless wall of text, yes indeed im dumb.
<Mis012[m]> debatable
<Mis012[m]> looks promising
<aka_[m]> still i have some confusion
<aka_[m]> because there is bunch of quin OSR clocks
<aka_[m]> for TDM/PCM/MI2S
<Mis012[m]> you can probably find those clocks in the FLAT :P
<aka_[m]> dayum
<aka_[m]> i might know lol
<aka_[m]> fast check
<aka_[m]> Mis012: lol
<aka_[m]> it is
<aka_[m]> its CLOCK_ID_INTERFACE
<aka_[m]> GPR_PKT:00000010: 000100ef 00201016 00000000 00000000... (full message at https://matrix.org/_matrix/media/r0/download/matrix.org/RaOdykaSNPCzxkzqRrgYccvk)
anholt__ has joined #linux-msm
anholt__ is now known as anholt
anholt_ has quit [Ping timeout: 480 seconds]