07:46 <lumag> strongtz[m], sure, thank you.

11:55 <Danct12> aka_[m]: seems like pmi8950 is only used for backlight stuffs

11:56 <Danct12> only the pm8937 appears need to be ported

11:57 <Danct12> this is getting spooky

11:58 <Danct12> i did check revid, there is pm8937 there

11:59 <Danct12> but seems like there's no reference to it outside the defines

12:39 <aka_[m]> Danct12 also for fuel gauge and charger

12:39 <aka_[m]> And others

12:39 <aka_[m]> PM89XX.DTSI are mostly copy-paste

12:39 <aka_[m]> Most diffs wirh gpio/mpp holes

12:42 <aka_[m]> Danct12: https://github.com/affenull2345/linux

12:42 <aka_[m]> As you know 8917 is just cut down 8937

12:53 <Danct12> hmm, then i guess i can just cpypaste and that mostly will work

12:54 <Danct12> what about the spmi regulators?

12:54 <Danct12> that thing is a little bit confusing for me

12:58 <aka_[m]> these are used for cpu vdd i believe

12:59 <aka_[m]> you have msm8937-regulator.dtsi and something like msm8937-rpm-regulator

13:07 <Danct12> /quit

15:10 <strongtz[m]> lumag: With charger plugged in at boot, I got these:... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/CUzJnpBQeCEhLFEuUKqANyhd>)

15:13 <strongtz[m]> Without a charger at boot, there will be some failures when I plug in a type-c dongle, which doesn't seem to harm much.... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/edYWqoCJycaNknuLLAeMpgCK>)

16:06 <lumag> strongtz[m], ack, thank you. This is indeed the typical GET_PDOS issue, which should likely be fixed by the patchset that I posted. You might need to opt-in to use the workaround.

16:06 <lumag> If you have to do that, please respond to the series I've posted.

16:08 <strongtz[m]> lumag nice, thanks for your patchset. I'll reply to the series after testing.

18:55 <mal> bryanodonoghue: hi, I was looking at your named power domain patchset for camss and was wondering about ispif_reset function in camss-ispif.c which calls camss_pm_domain_on using the PM_DOMAIN_VFEX enums and I need to add third VFE power domain for SC7280 which I think would break in that case platforms with fewer power domains

18:57 <mal> should that code also somehow use named power domains or do I misunderstand how things work

19:50 <bryanodonoghue> So ispif is for the 8916/8917 SoC series

19:50 <bryanodonoghue> for sc7280 you'd want a more modern VFE/CSID and CSIPHY set

19:54 <mal> hmm, ok

19:55 <mal> so I misunderstood how the whole thing is done

19:55 <bryanodonoghue> lets have a quick look at sc7280 VFE and CSID versions

19:56 <mal> it's close to sdm845 and sm8250

19:56 <mal> now that I looking at the structs more carefully I think that ispif is not defined

19:57 <bryanodonoghue> sdm845 is vfe17x sm8250 is vfe480

19:57 <mal> this is vfe165

19:57 <mal> same registers as vfe170

20:06 <bryanodonoghue> so I think z3ntu has some stuff for sc7280/qcs6490/sm7325 already

20:07 <z3ntu> not yet, mal has been faster with starting on something ;)

20:08 <bryanodonoghue> ah right

20:08 <bryanodonoghue> if 165 is a subset of 17x where 175 is 170 with a few additional registers, then you probably can reuse vfe17x

20:09 <bryanodonoghue> you need to work out which CSID you have

20:10 <z3ntu> qcom,vfe165_160 / qcom,vfe-lite165 -> vfe0, vfe1, vfe2, vfe_lite0, vfe_lite1

20:10 <z3ntu> qcom,csid165_204 / qcom,csid-lite165 -> csid0, csid1, csid2, csid_lite0, csid_lite1

20:10 <z3ntu> qcom,csiphy-v1.2.1 -> csiphy0, csiphy1, csiphy2, csiphy3, csiphy4

20:12 <mal> bryanodonoghue: one more question, in downstream sm8250 there are csid registers but not in mainline? are those not needed? just using that as comparison for checking how things should be done

20:13 <bryanodonoghue> yeah no so that's what I mean for new major silicon versions an address space is allocated

20:13 <bryanodonoghue> it can be filled up with additional regs as the versions bump

20:14 <bryanodonoghue> but its additive

20:14 <bryanodonoghue> so, if you have support for VFE 170, you should be fine to use VFE 175, provided you don't want any of the functionality that 175 provides over 170

20:17 <bryanodonoghue> I think you should be fine with csid-gen2

20:17 <bryanodonoghue> the registers appear to line up

20:51 <mal> thanks, that is what I was using