Daanct12 has quit [Read error: Connection reset by peer]
Daanct12 has joined #linux-msm
Daaanct12 has joined #linux-msm
Daanct12 has quit [Ping timeout: 480 seconds]
Daaanct12 has quit [Remote host closed the connection]
Daaanct12 has joined #linux-msm
jhovold has joined #linux-msm
sergi has joined #linux-msm
Daanct12 has joined #linux-msm
tomf_ has quit [Read error: Network is unreachable]
Rayyan has quit [Write error: connection closed]
tomf has joined #linux-msm
Rayyan has joined #linux-msm
Daaanct12 has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Quit: Leaving]
Daanct12 has joined #linux-msm
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #linux-msm
<Marijn[m]>
aka_: isn't it just binned, maybe it has two but dsi1 is turned off? Or more likely, the IP for dispcc is likely the same as other SoCs so it's cheaper to leave it disconnected than to remove this selector from the mux entirely? It's also possible that the driver writers casually forgot this while copypasting from another SoC?
<Marijn[m]>
Only one way to find out, schematics 😬
pevik has joined #linux-msm
agross has quit [Read error: Connection reset by peer]
agross has joined #linux-msm
jhugo_ has quit [Read error: No route to host]
jhugo_ has joined #linux-msm
arnd_ has quit [Read error: Connection reset by peer]
ndec has quit [Read error: Connection reset by peer]
CosmicPenguin has quit [Read error: No route to host]
<mal>
the patch to bindings documentation was already added back then
<aka_[m]>
<Marijn[m]> "aka_: isn't it just binned..." <- we cannot exactly know unless we have flats, qcom like to skip a lot in their dts like qups so they can bin chip easier.
<aka_[m]>
Sadly it appears i only have sm6150 flat and this one has DP so at same time ship with dsi0/dsi1
<aka_[m]>
would be great to get any qcom guy who is working on qcm2290 to know what exactly supposed to work as they pushed some code and left dts part without anything
pespin has joined #linux-msm
<Marijn[m]>
aka_: iirc it's the exact same situation on sm6126
<Marijn[m]>
6125*
<aka_[m]>
but i seen Haxk? having dpu working
<Marijn[m]>
aka_: that's a quick topic switch, I thought you were just curious
<Marijn[m]>
Yes, _I_ made a dpu config for sm6125
<aka_[m]>
well it all boils for me from dpu not really showing signs of life after having dsi PLL not dying from not having lock from vco setting
<Marijn[m]>
aka_: That's on 5.19? Perhaps this is related to sdm630 "dying" just as it tries to enable MDSS and/or GPU? As discussed yesterday with Dmitry reverting all of `drm/msm` fixed it
<aka_[m]>
havent went for trying GPU yet
<aka_[m]>
but when pll was failing it gave me version of dpu and "no gpu found"
<Marijn[m]>
sdm630 is still on mdp5 btw, but it's also DSI
<Marijn[m]>
We don't have GPU on sm6125 yet either, it works with LLVMPipe
<Marijn[m]>
aka_: If I'm not dead yet by the evening, do you want me to retry rebasing sm6125 on 5.19-rc5 and see if it still lives?
<aka_[m]>
i only have cheap commits for getting A610 but not sure if gpucc is done yet.
<aka_[m]>
Marijn[m]: will try on saturday
<Marijn[m]>
After all, I need to resend pm6125 from that branch 😓
<aka_[m]>
i do have pm6125 patches too
<aka_[m]>
SPMI+RPMSMD
<aka_[m]>
not sure how much valid they are but nothing blows so far
<Marijn[m]>
I should ask Martin Botka for permission to make the branch public, too. There's nothing on it that's scary anymore :)
<bamse>
mal: not sure what happened, reply to Linus and i'm sure he'd be happy to pick it up again
<ichernev[m]>
aka_: I never got ufs to work, but because of regulators ... (at least the error was something else)
<ichernev[m]>
Marijn: I did my best to verify stuff, I even made a script to compare values of the "same" regulator type across spmi, rpm and whatnot, and I found a bunch of issues, but if you have some suggestions to fix some values I'm all ears
<ichernev[m]>
* work, but not because of
<ichernev[m]>
(I found issues in other people's code ;-) - about my addition, it has some minor differences with DS, but when I compare across other SoCs it's not all roses... this is why I submitted an RFC and never bothered to merge it. I don't want to be responsible for somebody's fried device
<Marijn[m]>
ichernev: Not saying that anything is wrong yet, just figured you might want some review on the mailing lists to (get maintainers to) push it over the finish line. That implies double-checking values :)
<ichernev[m]>
also I couldn't really run anything depending on the regulators, so other than probing I didn't do much else. After we have a few users I'd feel more safe. I don't think people in LKML review stuff for correctness
<Marijn[m]>
> I found issues in other people's code ;-)
<Marijn[m]>
That's an understatement when working with qcom/caf code isn't it...
<Marijn[m]>
* > I found issues in other people's code ;-)
<Marijn[m]>
That's an understatement when working with qcom/caf code isn't it...
<ichernev[m]>
I'm not trying to be an ass, just saying that I was expecting to find all values in sync, but they weren't. I'm not an expert in regulators, so I don't want to send angry mail when I don't know what I'm talking about
<ichernev[m]>
I even messaged angelo, and he was like, meh, stuff's broken
<ichernev[m]>
if somebody is interested in my script that checks values across drivers, ping me in DM
<ichernev[m]>
also feel free to resumbit the driver (with tweaks) to lkml, all my code is signed-off-by, so you can use it freely
<Marijn[m]>
ichernev: I've put your patch on my never-ending list, will see if I can help out at some point
<Marijn[m]>
Though unlikely, I don't seem to be able to get anything done when juggling ~6 platforms at the same time
<ichernev[m]>
i just want a few people to test on other devices, I cant get much to work on the billie so the regs are untested. Also I wouldnt push for merging this soon, I mean this is the only dangerous part, also any interested party can use the rfc (on their watch)
<Mis012[m]>
steev: eh, so it turns out I only manually decoded `12` out of the `0x12` entries :(
<aka_[m]>
<ichernev[m]> "I'm not trying to be an ass..." <- ichernev: noone makes no mistakes, even Angelo makes them and if we keep doing nothing while being scared there will be no progress at all.
<Mis012[m]>
steev: and the 13th entry is secure boot related :(
<aka_[m]>
ichernev: ah this one is fault of regulators, you can take a sneak peak at nile dts, you have to limit regulators so code won't want to jump to unsupported voltage like 3.3-3.0V
<ichernev[m]>
what I found was mismatches between min/max values (in driver, which should be across all devices), and also different steps (i.e 5mv vs 5.5mv or sth), this is across the 2 interfaces (rpm and spmi). Again, if a few people verify that the code I wrote works, I'll be more keen on pushing it. Right now the billie port is not using any regulators, so even if the whole driver is wrong (or even if I fried everything on the billie) I would not
<ichernev[m]>
know, so I'm not really pushing for my regulators to get merged at this point. After we make sure the driver works (i.e something requiring regulators actually behaves after the driver inits), then I'll feel safer
<ichernev[m]>
keep in mind that most phones nowadays come with regulators from bootloader that would make most standard things work "out of the box"
<ichernev[m]>
nobody cares about and everything continues as usual :)
<ichernev[m]>
also, if I say : I found a mismatch in driver X on device Y... I mean who is supposed to do something about this? I'm guessing nobody uses the SPMI drivers (because there is RPM), and if I don't have the devices, I don't see how to get this through. LKML is mostly concerned with style, not correctness. If something is wrong somebody might complain (because it doesn't work). So even if I found a "mistake" that nobody cares about... then
<ichernev[m]>
I haven't seen somebody open the spec of any SOC and say: "yes, this is according to spec", I don't know it feels like the spec is either never referenced (by lkml) or it's used as toilet paper at most.
<Mis012[m]>
ichernev: well... I'd say people are worried of qcom considering correctness review against HPG an NDA violation :P
<konradybcio>
the regulator ranges are not correct on at least few more pmics..
<konradybcio>
too bad the docs are not public
<ichernev[m]>
my point is that most of "the spec" is not public. If there is spec for the pmic in question (pm6125), please share and I'll make sure to submit and get it merged
<konradybcio>
yes it is proprietary
<konradybcio>
the only public ones are for pm8916 and pm/i 8994/6
<konradybcio>
i can tell others are wrong because a certain voltage works on downstream and on mainline it says it's over the limit
<minecrell>
pm8916 FTW ;D
pespin has quit [Remote host closed the connection]