<z3ntu>
bamse: just noticed that you applied my patch "arm64: dts: qcom: sm7225-fairphone-fp4: Add AW8695 haptics" even though dt-bindings and driver patch hasn't been accepted yet - and it's possible the dt-bindings will need to change based on feedback there. What should we do here?
Daaanct12 is now known as Daanct12
abelvesa has quit [Read error: No route to host]
abelvesa has joined #linux-msm
pespin has joined #linux-msm
abelvesa has quit [Quit: Lost terminal]
<srinik>
aka_[m]: Is Q6AFE_LPASS_OSR_CLK_12_P288_MHZ, Equal to LPAIF_OSR_CLK ? Yes, Its OSR clk with 12.288KHz rate.
<srinik>
aka_[m]:Q:where it does set it has MODE_CLK1_VALID? AFE_PARAM_ID_LPAIF_CLK_CONFIG (0x00010238) comand take two clk values clk_value1 and clk_value2.
<srinik>
Normally clk_value1 is used for setting BIT CLK and clk_value2 is for OSR clk for the AFE port.
<srinik>
As per the ADSP 2.6 documentation I see supported values for clk_value1 are I2S bit clock for an MI2S port, or PCM bit clock for a PCM port
<srinik>
and for clk_value2 supported values are I2S OSR for an MI2S port
<srinik>
aka_[m]: upstream code has been abstracted to set OSR rate via value2 and BIT CLK via value1
calebccff_ has quit []
calebccff has joined #linux-msm
<aka_[m]>
Ah so it's this way
<aka_[m]>
Downstream have .val2=
<aka_[m]>
Anyway I give up I'm just too dumb to figure this thing.
<aka_[m]>
I see 8976 seems to use clk AFE v1 so I used lpaif_ibit/osr but it's still nope
<aka_[m]>
It just cry around multimedia dais for not having backend,
<aka_[m]>
I also noticed pkt_size on downstream can be like fff0000014 and on mainline it does 0x14
<aka_[m]>
Not mentioning AFE start port with 7f as last parameter in first row of packet and downstream 33
Daanct12 has quit [Ping timeout: 480 seconds]
jn has quit [Ping timeout: 480 seconds]
lumag_ has joined #linux-msm
jn has joined #linux-msm
pevik__ has joined #linux-msm
pevik has quit [Ping timeout: 480 seconds]
<bamse>
z3ntu: i presume that the new driver just won't work with the snippet i merged then?
<bamse>
z3ntu: if so, then let's just keep it in there...agree on the binding and patch up what we got
<bamse>
z3ntu: if you expect it to crash and burn, then please send me a revert
<z3ntu>
bamse: I think some small changes will be needed but nothing too major
<z3ntu>
It will probably on hold for some weeks, while I figure out how to address the review comments
<z3ntu>
Fun stuff like downstream driver writing some register with some value but no clue what the register or the value means :)
<bamse>
z3ntu: okay, let's go with plan A then :)
<z3ntu>
And I reproduced something similar in my driver but of course magic value in magic registers are not well-received in mainline
<bamse>
z3ntu: no, but if you don't have any way to figure it out, then one can hope the maintainer is pragmatic about it
<bamse>
that said, send me an email and i can take a look as well...perhaps it's something known after all, or something i can look into getting disclosed
<z3ntu>
I do have some path I will attempt to get this info from but it's not a fast one - hence my expected delay in getting any useful information about it
<z3ntu>
(Un)fortunately not Qualcomm but a component from Awinic
<z3ntu>
I guess you don't have any insider information there that's not on the data sheets they give out
<bamse>
z3ntu: ahh, yeah, then i'm not of much use :(
<z3ntu>
Thanks for the offer though!
Guest252 has quit []
abelvesa has joined #linux-msm
<calebccff>
lumag: I've been hitting an issue on AOSP since ~rc1 (just getting around to it, sorry!) where the panel fails to come up when exiting suspend: https://p.calebs.dev/9c0390
<Mis012[m]>
if it doesn't happen on normal Linux, does that not mean it's android's problem?
<Mis012[m]>
we already have >0 (too many) concessions for android doing broken stuff which somehow makes the broken behavior an ABI
<Mis012[m]>
maaaybe I'm a little biased
<calebccff>
it doesn't happen under regular Linux, it seems like some changes to the DSI init sequence caused it. I guess Android is calling an ioctl before the device is ready
<Mis012[m]>
fun, can we have that fixed in AOSP without anyone trying to argue that it's now an ABI because it worked before?
<Mis012[m]>
I wonder if the reason that all ugly ABI concessions come from android is that they care about their legacy broken shit working, while we rather care about clean code -_-
<vknecht[m]>
calebccff: just in case, perhaps try with msm as module, and panel built-in ?
<vknecht[m]>
hitting the same problem here (panel generally not coming back), with same backtrace two weeks ago, and now more along this : https://pastebin.com/gxmnGXUa
jhovold has quit [Ping timeout: 480 seconds]
anholt has joined #linux-msm
Daanct12 has joined #linux-msm
pevik_ has quit [Ping timeout: 480 seconds]
pespin_ has joined #linux-msm
pespin has quit [Ping timeout: 480 seconds]
pespin_ has quit [Remote host closed the connection]