junari has quit [Remote host closed the connection]
jhovold has joined #linux-msm
zstas has joined #linux-msm
pespin has joined #linux-msm
<konradybcio>
aka_: QC SPMI PMICs were designed in a way such that you can theoretically detect everything dynamically
<aka_[m]>
i know there are rev registers
<konradybcio>
yet that idea didn't go super far because you still need to e.g. describe the thermistors connected to the adc somewhere
<travmurav[m]>
last time I tried to enumerate spmi pmics based on block offsets and id fields, I learned that while on i.e. 8916 you can expect to see stable "empty" values in "unmapped" address space, on i.e. 8226 it returns last read value/garbage so I somehow feel like all that old qpnp stuff was kinda broken :(
<aka_[m]>
Ouch
<aka_[m]>
About last read issues I seen some presentation about it and with examples of qcom ds pmic code
<travmurav[m]>
so i.e. even though you can know that each block start is aligned to x, you can't really just try every i*x unless you know exactly what happens for absent blocks xD
<aka_[m]>
It was probably about memory barriers and way relaxed writes works
<aka_[m]>
Tho pmic probably uses spmi right?
<aka_[m]>
Not raw writes
<travmurav[m]>
I think it was more like the spmi_arbiter returning garbage and not me accidentally hitting cache, since I'd get like regulator@1 regulator@2 charger@3 bms@4 bms@5 bms@6 but 2,5,6 are actually "empty" and hw just returned the previous read value
<travmurav[m]>
so that stuff was very possibly even somewhere inside hardware, either in soc (the spmi arb) or even in the pmic itself (whatever spmi->addr space thing it has)
<konradybcio>
have you tried doing this in linux? maybe there's a bug in lk code
<Danct12>
for qrb4210?-rb2, is pm6125_l9a is connected to vbat?
<aka_[m]>
why would it
<konradybcio>
if you're exploring supply maps, they don't matter
<konradybcio>
rpm handles that internally (i think?)
<konradybcio>
it's more of a hw documentation in dt
<travmurav[m]>
konradybcio: don't think I tried but well, back then I decided that this curiosity isn't worth the work, given that with same lk code different pmics/socs behave differently
<konradybcio>
travmurav: there were some funny workarounds for older pmics in msm-3.10
<konradybcio>
specific to models
<travmurav[m]>
As in, it still dumps the IDs but need to manually ignore the 200 garbage entries xD
<travmurav[m]>
And not like there is any good public database of IDs beyond 8916 trm so that was kinda sad thing from the beginning
<konradybcio>
socinfo.c in linux
<konradybcio>
for pmic ids
<travmurav[m]>
No
<travmurav[m]>
Pmic peripheral ids
<konradybcio>
then every downstream driver has these
<travmurav[m]>
Like Id=charger/sub=lbc
<travmurav[m]>
Well then need to scavange for them xD
<aka_[m]>
aaaa
<aka_[m]>
konradybcio: im melting, passing data via of_device_get_match_data all cool but how tf im supposed to iterate over array pointer
<aka_[m]>
ok i have weird idea
<konradybcio>
either a struct with .xxx and .xxx_num or null-terminate
<aka_[m]>
yea
<aka_[m]>
thats what i had as idea
<konradybcio>
but generally the former is better because xxx_num ends up being smaller than sizeof(another_member)
<aka_[m]>
new struct with sizeof
<konradybcio>
you're likely looking for ARRAY_SIZE though
<konradybcio>
sizeof returns the # of bytes occupied
<aka_[m]>
struct reg_default *seq; thats pointer to an array and i guess assigning array to it is not good idea
<konradybcio>
wcd_reg_defaults_2_0 points to the first item in the array
<aka_[m]>
i don't fully trust bing chat but it tries to tell me its okish
<konradybcio>
please also take the creative freedom to use lowercase hex ;)
<aka_[m]>
konradybcio: thats snippet from already existing code
<aka_[m]>
eh
<aka_[m]>
brain roting so badly
<aka_[m]>
warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
<konradybcio>
you need const in the struct definition
<konradybcio>
there's a difference between a const pointer (the address it points to can't change) and a pointer to const data (ptr points at data that can't change)
<konradybcio>
you can also have a const pointer to const data
<aka_[m]>
wait in definition of struct or .h?
<konradybcio>
well struct reg_default since you're passing const data
<konradybcio>
sorry
<konradybcio>
struct wcd_reg_seq
<aka_[m]>
konradybcio: so const make it not being able to modify from runtime?
<Marijn[m]>
Should we create a "programming help 101" channel for Linux? None of these questions are very relevant to linux-msm and they've been ongoing for months.
<Marijn[m]>
It's quite annoying for those trying to keep up with MSM-related development and deeper technical questions. And I hope I'm not the only one finding this channel less and less useful for that.
<aka_[m]>
true
<aka_[m]>
its dead now, pretty much state during summer
<Marijn[m]>
It's not exactly dead in the slightest with all the questions that are flowing in
<konradybcio>
yes, }s are usually placed below the ifs where they're opened
marc|gonzalez has joined #linux-msm
tmerciai has quit [Remote host closed the connection]
<Danct12>
konradybcio, regarding display supplies. i guess for the ones required i can just add a dummy fixed regulator?
<Danct12>
required by dtbindings*
ungeskriptet is now known as Guest1581
ungeskriptet has joined #linux-msm
Guest1581 has quit [Ping timeout: 480 seconds]
<marc|gonzalez>
konradybcio: what email should I use for kernel stuff?
ungeskriptet is now known as Guest1585
ungeskriptet has joined #linux-msm
ungeskriptet is now known as Guest1586
ungeskriptet has joined #linux-msm
Guest1585 has quit [Ping timeout: 480 seconds]
Guest1586 has quit [Ping timeout: 480 seconds]
<konradybcio>
Danct12: yes
<konradybcio>
marc|gonzalez: ?
<konradybcio>
Danct12: why would you not have one though
<aka_[m]>
konradybcio: wasn't L9 powerdomain
ungeskriptet is now known as Guest1588
ungeskriptet has joined #linux-msm
<Danct12>
konradybcio: cause it doesnt exist on downstream device tree
Guest1588 has quit [Ping timeout: 480 seconds]
<lumag>
Marijn[m], as usual on any other channel: tag necessary people to get some sensible response
<Marijn[m]>
lumag: no question was asked and no response was asked from my side, if that's what you're asking
<lumag>
(well, this applies to other people)
<aka_[m]>
krzk: so your sbc dt-bindings got accepted now if i want to resend v3 do i need it in dependencies?
<aka_[m]>
trying to get things done with b4 and already have added your patch as dependency
<krzk>
aka_[m]: if by accepted you mean applied, then you do not need to mention it, because your patch will go to the same maintainer / branch
<aka_[m]>
okay and question, i had it defined in cover before but it was wrong, can i remove mentions of it?
zstas has quit [Ping timeout: 480 seconds]
<aka_[m]>
i mean [1] - URL
<aka_[m]>
and later mention of "rebased on top of Krzysztof's patch[1]" (i mean removing [1] alone)
<krzk>
aka_[m]: wasn't that changelog?
<aka_[m]>
it was
<aka_[m]>
i wonder if i can remove it if it was not even properly specified
<krzk>
old changelog entries do not change, usually
<aka_[m]>
so even if its wrong i suppose to keep it
<aka_[m]>
okay, and for bindings i did like i was told to but for top definition of regs when i added maxItems checker said its bloat so i removed it.