ChanServ changed the topic of #linux-msm to:
rmsilva has quit [Ping timeout: 480 seconds]
rmsilva has joined #linux-msm
Danct12 is now known as Guest1278
Danct12 has joined #linux-msm
junari has joined #linux-msm
Danct12 has quit [Quit: WeeChat 3.8]
junari has quit [Ping timeout: 480 seconds]
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
junari has joined #linux-msm
svarbanov has joined #linux-msm
junari_ has joined #linux-msm
junari has quit [Ping timeout: 480 seconds]
pespin has joined #linux-msm
junari__ has joined #linux-msm
junari_ has quit [Ping timeout: 480 seconds]
<DylanVanAssche> bamse: Is there anything missing for applying https://lore.kernel.org/linux-remoteproc/20230327183736.496170-1-me@dylanvanassche.be/ to remoteproc?
<DylanVanAssche> srinik: Would you have some time to look at this small patch to get it applied? https://lore.kernel.org/linux-arm-msm/20230511141146.30465-1-me@dylanvanassche.be/
<srinik> DylanVanAssche: thanks for the patience, I already started some disussion about this patch with qcom, I will hopefully get this sorted this week.
<DylanVanAssche> srinik: Ah thanks a lot!
<bamse> DylanVanAssche: no, doesn't look like it...i just have been slow on picking up patches the last few weeks
<DylanVanAssche> bamse: No problem 🙂 I was just wondering because Patchwork already moved it to Non Applicable (not sure why)
junari_ has joined #linux-msm
junari__ has quit [Ping timeout: 480 seconds]
<bamse> DylanVanAssche: should be superseeded, given that https://patchwork.kernel.org/project/linux-remoteproc/list/?series=735500 (v3) is New
<bamse> DylanVanAssche: but you need to look in the linux-remoteproc project, because it will be "Not Applicable" in the msm project
<DylanVanAssche> bamse: Ah yes, v3 is the latest. At that Not Applicable thing is about which project, I always wondered how that worked...
<bamse> the state is per-project...
<bamse> and is causing me issues in my tooling ;P
<bamse> so it's in the remoteproc todo-list, and i'm sorry for not having caught up on that yet
<DylanVanAssche> Ah no worries, I'm just not very fluent in mailing list patches, I am mostly used to Github/Gitlab/... pull approach so I was wondering if I did something wrong again 🙂
<DylanVanAssche> However, I'm getting better at it
svarbanov has quit [Ping timeout: 480 seconds]
bamse has quit [Remote host closed the connection]
bamse has joined #linux-msm
bamse is now known as Guest1335
Guest1335 has quit []
bamse has joined #linux-msm
junari_ has quit [Ping timeout: 480 seconds]
pespin has quit [Remote host closed the connection]
<aka_[m]> anyone can explain me nvmemcells?
<lumag> aka_[m], sure. each cell has:
<lumag> reg = <starting-offset size-in-bytes>
<lumag> bits = <starting-bit amount-of-bits>;
<aka_[m]> im lurking around qcs405 dtsi
<aka_[m]> for ring1 and ring2 it takes top 8 bits out of CORR_CALIB_ROW7_LSB_ADDR A:0xa4228
<lumag> 0x4 is wrong, it can be 1
<aka_[m]> so 31-24
<aka_[m]> for ring3 it takes 23-16
<aka_[m]> so for ring 3 it reads from bit16 to bit19?
<aka_[m]> starting from 0
<aka_[m]> with 3 size
<aka_[m]> ring1 BIT(24)-BIT(26)... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/DVCyQfrhJGrqHdvNoJdoXnlm>)
<aka_[m]> noone able to answer?
<konradybcio> 0xa4228
<konradybcio> i think these bits are bottom bits
<konradybcio> though i'm not 100% sure about the endianness
<aka_[m]> konradybcio: so when using bits 0 3 it would start from bit(31) or you mean it start from bottom of register?
<aka_[m]> that wouldnt fit with desc of vol
<konradybcio> bottom
<konradybcio> BIT(0)-BIT(3)
<aka_[m]> that wouldnt fit
<konradybcio> actually 0 1 2
<aka_[m]> its voltage cell
<aka_[m]> bottom is ro-sel
<aka_[m]> or these names are just misleading
<konradybcio> is it a description of the same soc
<aka_[m]> thats qcs405 flat
<aka_[m]> so sound same with qcs404
<konradybcio> i don't know the details but it's probably not the same
<aka_[m]> konradybcio: that would fit tsens cells
<aka_[m]> qcs403/404/405 are same family
<konradybcio> cpr is very chip-specific, it's not family-common
<aka_[m]> lower qcses just include 405 dtsi
<aka_[m]> cannot find anything regarding changes in cpr def
<aka_[m]> whatever, not like i care much if this soc has proper data anyway, just was running around stuff so it didn't hurt to ask
<aka_[m]> what is a diff between QFPROM_RAW_CALIB_ROW3_LSB and QFPROM_CORR_CALIB_ROW3_LSB
<aka_[m]> RAW vs CORR
<Leandro[m]> Corrum
<aka_[m]> uh raw ones are writable
<Leandro[m]> * Corrumn
<aka_[m]> Leandro[m]: me not understand
<Leandro[m]> Joke
<konradybcio> ecc-corrected
<konradybcio> qfprom_base+0x4000 stores the same values, except corrected
lumag_ has joined #linux-msm
flto has quit [synthon.oftc.net reflection.oftc.net]
leezu has quit [synthon.oftc.net reflection.oftc.net]
lumag has quit [synthon.oftc.net reflection.oftc.net]
sumits has quit [synthon.oftc.net reflection.oftc.net]
flto has joined #linux-msm
leezu has joined #linux-msm
sumits has joined #linux-msm