13:22 <z3ntu> bamse: I've noticed that for the qcom,pdc driver most dts only provide one reg, but some newer SoCs provide a second reg that's not used in the driver. Apparently the downstream driver uses it and calls it "pdc_cfg_base". Should this be documented in the dt-bindings document or removed from the dts'es? (background: I've converted the bindings to yaml but I don't know what to do about this property, whether to allow two regs or not)

14:47 <bamse> z3ntu: there was a discussion about this at some point and the conclusion was that "even though linux doesn't use it, it should be in the binding"

14:50 <z3ntu> bamse: ok, then I'll just set "maxItems: 2" for reg

14:52 <bamse> isn't that implicitly saying minItems: 2?

14:52 <bamse> i.e. don't you need to list your two items and then say minItems: 1

14:53 <z3ntu> both minItems: 1 and maxItems: 2

14:54 <z3ntu> but yes, just maxItems: 2 also seems to set minItems to 2 so both are needed

14:58 <z3ntu> If you can tell me what those two regs mean, I can add a proper description to both items but I honestly have no clue

14:58 <bamse> i've seen items: -, -, minItems: 1...which would imply that items lists all possible items and minItems allow you to specify less

14:58 <z3ntu> I mean I can write "PDC base register region" and "PDC cfg register region" I guess

14:59 <bamse> as i said, there was a discussion which highlighted its purpose...but i'm not able to find it right now :/

14:59 <z3ntu> downstream commit introducing it is titled "drivers: irqchip: pdc: additionally set type in SPI config registers"

15:01 <z3ntu> the message also calls it "interface registers" it seems: https://source.codeaurora.org/quic/la/kernel/msm-4.19/commit/?id=cdefb63745e051a5bcf69663ac9d084d7da1eeec

15:11 <z3ntu> bamse: So "PDC base register region" for the first reg is probably ok but should I use "PDC SPI config register region" or "PDC interface register region" for the second? Alternatively I can leave the description out completely and it can be written by someone else who knows the hardware better.

15:12 <bamse> z3ntu: i think you should take a swing at it, Marc will help you if you're wrong

15:13 <bamse> well, help as in...he will tell you that you're wrong if you are, but others would be able to pitch in then

15:15 <z3ntu> he, so Cunningham's Law "the best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer." :P

15:15 <z3ntu> thanks!

15:15 <bamse> this sounds like an excellent application of that law :)

16:12 <minecrell> bamse: Could you reply to these two mails when you find time? https://lore.kernel.org/linux-arm-msm/Yac7rvxHhWld1%2Fs3@gerhold.net/ and https://lore.kernel.org/linux-arm-msm/YZd0zzzuxgk2+x2b@gerhold.net/

16:12 <minecrell> bamse: AFAICT you marked these two as "changes requested" on patchwork but I'm not sure what changes to make yet :)

16:21 <bamse> minecrell: ouch, i was affraid that there would be such a reason for making it a child of the remoteproc...i believe that currently there's not much consequences of putting it a child - beyond presumably screwing up the pm_runtime state...

16:22 <minecrell> bamse: qcom_q6v5_mss doesn't use runtime PM, does it? Also not sure if that would make any sense :)

16:22 <bamse> minecrell: re the dts change, we generally put the tlmm node last, but not the regulators...i'm fine with it being consistent though...

16:23 <bamse> minecrell: right, we only use it to turn on the power-domains, but we don't actually enable if for the device itself

16:28 <minecrell> bamse: I can limit the of_platform_populate() to the "qcom,bam-dmux" compatible if you would prefer not having everything possible below the mpss node

19:59 <DavidHeidelberg[m]> srinik: hey, are u around?

20:02 <DavidHeidelberg[m]> I noticed with commit "soc: qcom: apr: make code more reuseable" you defined `qcom,domain`, but in DTS it remained as `qcom,apr-domain`, can I send patch or you have some patch in queue waiting to get send/merged?