ChanServ changed the topic of #linux-msm to:
<flamingradian[m]> steev: oh btw, readdir is performed on /etc/qcom/sensors.d and /var/lib/qcom/sensors so no errors will come out of missing files in them
Daanct12 has joined #linux-msm
Daaanct12 has quit [Ping timeout: 480 seconds]
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
<steev> i don't think i have anything in /var/lib/qcom/sensors yet at all, so that explains that :)
jhovold has joined #linux-msm
<aka_[m]> Marijn: we got EL2 on msm8976
telent has quit [Quit: The Lounge - https://thelounge.chat]
svarbanov_ has quit [Ping timeout: 480 seconds]
svarbanov has joined #linux-msm
telent has joined #linux-msm
telent has quit [Quit: The Lounge - https://thelounge.chat]
Daaanct12 has joined #linux-msm
Daanct12 has quit [Ping timeout: 480 seconds]
telent has joined #linux-msm
telent has quit [Quit: The Lounge - https://thelounge.chat]
telent has joined #linux-msm
telent has quit [Quit: The Lounge - https://thelounge.chat]
telent has joined #linux-msm
telent has quit []
<Marijn[m]> aka_: what are you working on now for msm8976, so that we don't do the same? I tried looking at your git repo a while ago but... :)
telent has joined #linux-msm
<aka_[m]> Marijn[m]: now pretty much nothing, i have icc awaiting Konrad patches
<aka_[m]> some low quality clk-hfpll reworks and cpu freq scalling with apcs-msm8916.c, maybe remoteprocs?
telent has quit [Quit: The Lounge - https://thelounge.chat]
telent has joined #linux-msm
<Marijn[m]> Cool, no overlap them
<Marijn[m]> then*
<Marijn[m]> I'd like to complete all the current DPU issues/series and then move straight back to 8976 iommu and mdp5 :)
<Marijn[m]> https://lore.kernel.org/linux-arm-msm/20230507153004.3461eccd@jic23-huawei/T/#t any "qcom people (bamse, konradybcio, lumag) that'd like to take a look?
<lumag> Marijn[m], please remind me, how do we cope with the possible duplicate labels?
<Marijn[m]> Something that makes the difference obvious to userspace?
<lumag> or we don't need to, since they end up in the file contents rather than file names?
<Marijn[m]> Yes and no
<lumag> ?
<Marijn[m]> Only vadc. In adc5 things still end up in the filename because of extend_name, and dropping that legacy broken-ness is an ABI break hence isn't allowed
<lumag> ack
<lumag> Marijn[m], next dumb question, is label a part of the generic dt bindings?
<Marijn[m]> What do you mean by "generic"
<lumag> Not quite, but it is good enough, thanks
<lumag> Marijn[m], done
<Marijn[m]> lumag: saw it, thanks!
<aka_[m]> fun 665/662 also contains HYP firmware
<aka_[m]> wonder if these are vulnerable too
Daaanct12 is now known as Danct12
rmsilva has joined #linux-msm
rmsilva has quit [Quit: WeeChat 3.8]
rmsilva has joined #linux-msm
Danct12 has quit [Quit: How would you be so reckless with someone's heart!?]
Danct12 has joined #linux-msm
<aka_[m]> lumag: any chance you have access to msm8996 trm?
<lumag> aka_[m], no
<aka_[m]> sad, would be easier to figure boot remaper address
<lumag> I wish I had access :-)
<aka_[m]> lumag: sadly i have 8998 -everything less and then everything above
<aka_[m]> maybe not everything
<aka_[m]> but still something
<aka_[m]> would be cool to reach EL2 on 8996 ngl
<flamingradian[m]> steev: btw, if you can't find registry files for /var/lib/qcom/sensors, they can be generated with a program in sensh.git/tools/
<steev> oh, that's good to know
Daanct12 has joined #linux-msm
Danct12 has quit [Ping timeout: 480 seconds]
<z3ntu> bamse: I guess we currently don't have a driver that handles the mpp thingy on PMICs? Seems on one of my devices there's leds connected to this mpp @a300 (color green) and @a500 (color amber) on pm8226.
<z3ntu> Also seems to have pwm functionality on there so wondering if it's a fit for lpg driver
<aka_[m]> ?
<z3ntu> oh we already seem to have qcom,spmi-mpp (and even defined in upstream qcom-pm8226.dtsi)
<bamse> what aka_[m] said :)
<bamse> aka_[m]: thanks
<z3ntu> not sure if this currently can be used for more than just pinctrl though?
<z3ntu> or is the whole thing just weird downstream for "we actually get a pwm out of lpg block but define it in mpp one?"
<z3ntu> there's properties such as "qcom,pwm-channel = <5>;" for this led defined
<lumag> z3ntu, in case of LPG, we can use mpp to set it to the proper output. Let me check, on which board we had that.
<lumag> Ah, obvious. On db410c (apq8016-sbc), we set the mpp to digital to let LPG drive those outputs
<lumag> Hmm, it's not lpg
<lumag> (on 8916)
<z3ntu> so assuming qcom,pwm-channel = <5>; in mpp node uses the pwm channel defined with qcom,channel-id = <5>; (pwm@b600), does this mean this pwm comes out of one of the MPP pins on the pmic?
<z3ntu> and it's on the mpp side just instructing the pinctrl to select the correct function?
<z3ntu> and then getting a pwm signal out that an led is connected to?
<lumag> I think so
<z3ntu> I have datasheet for pm8941 but this doesn't clear up anything for my mind tbh regarding this
<lumag> z3ntu, note that drivers/leds/leds-qpnp.c makes a difference between PWM_MODE and LPG_MODE
<aka_[m]> isnt there some mode registers for pins?
<lumag> registers are at 0xaN00 if I'm not mistaken
<lumag> And LPG/PWM is at 0xbN00
<z3ntu> actually on pm8941 seems the pwm/lpg output is on some GPIOs while there are separate MPP pins. Maybe it's different on pm8226 or it's something else from what I'm thinking
<aka_[m]> i guess LPG hardware is hardwired to MPP4 MUX and you just setup which block you want to utilize with that pin
<lumag> aka_[m], this is for pm8916 IIRC
<aka_[m]> the one i posted is 8953
<aka_[m]> PM8953
<lumag> If I remember correctly, the basic idea for MPP is simple: it can be either a gpio, or it can be driven by other function. So to utilise it you have to add pinctrl-0 to your lpg node
<lumag> Again, basing on my understanding, some (earlier?) PMICs had a single pwm channel routed to mpp, so that one can control backlight (wled) using that pwm output
<z3ntu> On this there's an LED defined on @a100, @a300 and @a500 , so 3 out of the 8 mpps
<z3ntu> Feels like this means those MPPs have pwm routed to them that it can be switched to
<lumag> z3ntu, ok, you tricked me into looking at the leds on 8074 :-) Right when I wanted to declare that board done for today!
<z3ntu> ;)
<z3ntu> For mine, I should probably just dump the registers downstream and figure out what it's doing based on that. Downstream driver is super convoluted
<lumag> Ugh
<lumag> z3ntu, ok, in my case it was not that interesting, I have a triled, so no mpp configuration.
<z3ntu> 8974 seems to always use triled for rgb led (except some devices where manufacturers added an extra IC to drive the led like OnePlus)
<lumag> z3ntu, in your case, if I'm not mistaken, all mpp pinctlr should have { function = "sink"; output-low; }
<lumag> And then there should be a dtest config, IIUC
<lumag> mpp2 is plain gpio, no pwm
<mal> I tried to boot my msm8226 device with 6.4-rc1 but it fails, I see some early boot messages on screen but then display turns blue and device powers off