ChanServ changed the topic of #linux-msm to:
deathmist2 has quit [Read error: Connection reset by peer]
deathmist has joined #linux-msm
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
<aka_[m]> <lumag> "aka_, Marijn[m] could you please..." <- sorry to question that but did you mean... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/ICbdemjarlreiOzELyWIXYzs>)
<lumag> aka_[m], Yes, thanks a lot!
<lumag> summed 0x1000 with 0x4000 and got 0x4000 :D
<lumag> just to confirm, this is sm6115?
<aka_[m]> yes
<lumag> ack, thanks a lot!
<lumag> (yet another fix for the hw catalog)
<swdefrgthfgjhk> mal: any progress of your iommu for msm8974 patch? i can help you if you need someone to test it
<mal> I haven't had time to fix the final things in it, the last cleanup I did broke something, need to find what
<mal> I should try to find some time to continue it
<konradybcio> "if it ain't broken, I'll fix it till it is"
<konradybcio> :D
jrole_8tst-j[m] has joined #linux-msm
<konradybcio> lumag: thanks for prompt review, ill resend on monday
jhovold has quit [Quit: WeeChat 3.7.1]
<lumag> konradybcio thanks.
<lumag> konradybcio, as for the DPU changes, I really hope to land the hw catalog rework first (hope it will take less than two months for it to be reviewed).
<lumag> It will be a nightmare to rebase it
<lumag> krzk, a random thought regarding dt schemas. It's now frequent that we have the top-level 'clocks' / 'clock-names' specification binding just the min/maxItems and then we have proper specification under if conditions. It is quite easy to miss one of the compats in such conditions, which can be left unnoticed, because top-level definition makes unevaluatedProperties happy. Do you think it would make sense then to add something
<lumag> like 'underspecified' property. It would mean that this schema part should be enforced, but it is not enough to mark the property as evaluated?
<lumag> konradybcio, just a note: freedreno's patchwork doesn't show 'incomplete' series on the main page (and your series are marked as incomplete, as PW didn't get all patches). Could you please next time make sure that all patches are CC'd to freedreno@
jhovold has joined #linux-msm
<z3ntu> Anybody have an idea why my qcom,hfpll works correctly with rate 2112000000 but with 2150400000 goes to the lowest one 537600000? This feels to be too close to INT_MAX = 2147483647 to be a coincidence...
<z3ntu> I see this both in debugfs clk_summary but I'm quite sure it's actually at that rate then since cpu performance goes down the drain
<z3ntu> (hfpll is used for cpu clock frequency on at least msm8974)
<z3ntu> set_rate ops uses "unsigned long" so that should have plenty space really...
<z3ntu> hm I'm noticing `.config_val = 0x430405d,` is different downstream, there it's `qcom,hfpll-config-val = <0x04D0405D>;` , that's with the comment "Configure PLL parameters for integer mode."
<z3ntu> no clue how PLLs work but this seems sorta relevant
<z3ntu> this config_val value didn't change
<z3ntu> But seems krait_div2_round_rate is ultimately responsible, also found a good hint now here: https://lore.kernel.org/lkml/20210702225145.2643303-2-martin.blumenstingl@googlemail.com/
<z3ntu> "the maximum value on 32-bit systems increases from 2^31 (or approx. 2.14GHz) to 2^32 (or approx. 4.29GHz)."
<z3ntu> ugh 2150400000*2 (=4300800000) is bigger than unsigned 32-bit (4,294,967,295)
<z3ntu> hfpll0 2 2 0 2265600000 0 0 50000 Y
<z3ntu> got it to ~2.27GHz now finally