01:58 <calebccff> bamse: the smp2p driver has a comment saying it sets it's interrupt as a wakeup source but "User space can decide enabling it depending on its use cases.", how would userspace go about doing that?

02:23 <calebccff> nvm, wakeup class, sorry for the noise

02:34 <bamse> calebccff: ahh right, downstream the remote can unconditionally wake up AP, but in a device such as a laptop you don't want e.g. a crash event to wake up AP, as it won't fall back asleep...so most likely you'll pull your laptop out of your backpack without battery in that case

02:35 <bamse> calebccff, Mis012[m]: and i remembered wrong, the glink notification is a gic interrupt

02:35 <bamse> it's the remoteproc state changes and a few other such things that uses smp2p

02:37 <calebccff> bamse: right i see how that might not be desirable right now... Shouldn't the kernel handle the crash and go back to suspend?

02:38 <calebccff> the smp2p itself uses a GIC interrupt, although I'm not able to make it wake up my device for phone calls

02:38 <calebccff> as soon as i do manually wake it up the phone call comes in

02:39 <bamse> calebccff: in a typical linux system suspend and resume are explicit operations...so you need something making the decision to take down the system again after the resume

02:39 <bamse> calebccff: in android the system suspends as soon as it's idling

02:40 <bamse> calebccff: do we flag the glink gic irq as wakeup?

02:40 <bamse> no we don't

02:41 <calebccff> bamse: if the whole IRQ -> irq reason (is it a crash?) -> handle crash process happens in kernel it can just put the device back to sleep afterwards

02:41 <bamse> calebccff: the same logic found at the end of qcom_smp2p_probe() should likely exist in qcom_glink_native_probe() as well

02:41 <calebccff> bamse: I'll give that a go, thanks

02:42 <bamse> calebccff: yes, that would be nice, but i'm not aware of any such mechanism

02:43 <calebccff> fwiw the IPA driver explicitly calls pm_wakeup_dev_event(), on a system with autosuspend enabled this would result in the device going back to suspend 500ms after the IRQ fires unless userspace takes a wake lock

02:44 <calebccff> at least, i think that's how that works based on a glance at the sources

02:45 <calebccff> without autosleep enabled though it does just wake up the device, so the remoteproc crash handler would need to explicitly put the device back into suspend, which doesn't seem like logic which should go there...

02:55 <bamse> that sounds right

03:25 <bamse> djakov: could you please consider picking up https://lore.kernel.org/linux-arm-msm/20220408214835.624494-2-bjorn.andersson@linaro.org/ for v5.19?

08:13 <djakov> bamse: sure! thanks for sending it!

08:49 <z3ntu> djakov, bamse: Do you know why rpmh interconnect drivers require a 'reg' in device tree? As far as I can tell it's not used in those drivers, and I'm having troubles modelling it for sm6350.

08:49 <z3ntu> Downstream dts has multiple nocs pointing to the same reg https://android.googlesource.com/kernel/msm-extra/devicetree/+/refs/tags/android-11.0.0_r0.81/qcom/lagoon-bus.dtsi#6 . One idea to do it like the (rpm-based, which needs reg) qcm2290 that makes some nocs child nodes of a different noc, but this feels a bit clunky when the only reason we do this is not to have conflicting regs that are not even used.

08:50 <z3ntu> My current draft is the following:

08:51 <z3ntu> But moving all this out of /soc and calling it interconnect-config-noc or whatever and removing reg might be even better and work too?

09:35 <aka_[m]> z3ntu: sounds like mmsnoc case on smd-rpm socs

09:35 <aka_[m]> On these they share same regmap

09:36 <z3ntu> The difference is that drivers/interconnect/qcom/icc-rpm.c actually uses the reg (`platform_get_resource`) but icc-rpmh.c (which sm6350 uses) doesn't

09:37 <z3ntu> So from what I can tell it's kinda useless (all my interconnects without a reg also works fine at runtime)

11:36 <djakov> z3ntu: the regs on rpmh platforms could be used for configuring QoS, in a similar way as on RPM platforms. there are also some counters and probes (debug stuff)

11:38 <z3ntu> djakov: "could be" meaning it's currently unused but might/will be used in the future?

11:38 <djakov> z3ntu: if i remember correctly, the thing here is that the hw designers for some reason have combined the registers of multiple nocs into a single address space

11:39 <djakov> z3ntu: yes, currently no rpmh drivers support this

11:40 <z3ntu> got it, thanks!

11:40 <z3ntu> I guess how I sent it above ("My current draft is the following:") is ok?

11:41 <djakov> z3ntu: the rpm drivers were also initially without qos support and it was added just recently

11:41 <z3ntu> Maybe qcom,base-offset from downstream is also somehow relevant in the regs, not sure...

11:44 <djakov> z3ntu: this should be the offset for the different registers from the base address

11:45 <djakov> e.g NoC_A and NoC_B base is 0x10000, and the qos registers for NoC_A are at offset 0x10 and for NoC_B are at 0x20 from the same base address.

11:47 <djakov> z3ntu: your draft looks ok

11:50 <z3ntu> There's a separate qcom,qos-off property downstream with (for 'lagoon') values of 0, 128 or 4096. But I guess we best sort that out when we get there

12:09 <aka_[m]> djakov: what is a difference between qnoc and noc type and how to know which one is used?

14:46 <djakov> aka_[m]: not sure that i understand what you are asking

15:05 <aka_[m]> https://github.com/torvalds/linux/commit/08c590409f303d61461b8fcaa9083438e4300448

15:08 <z3ntu> downstream defines the type in the dts

15:09 <aka_[m]> So far we had bimc/noc type

15:09 <z3ntu> qcom,bus-type it's named

15:09 <aka_[m]> And this qnoc added new property probably its related to qcom,forwarding from scuba-bus.dts

15:11 <aka_[m]> I asked once about what to do with qos nodes of there is no prio props and I was told to set them to 0 in that case.

15:13 <aka_[m]> Here is my ICC driver if anyone with enought knowledge can take a look:

15:13 <aka_[m]> djakov:

15:13 <aka_[m]> https://github.com/Kiciuk/linux/commit/b03aaeec0dbadcd7c455d72a0d4c4ed27fbfd6a2

19:45 <Mis012[m]> ok, just realized that I was probably testing with an older kernel before, and it seems that now even with UEFI in the mix, ↑ is needed to not have Linux reboot in a random spot

19:46 <Mis012[m]> could also be that this is only manifesting with maxcpus=1?

19:47 <Mis012[m]> resp. that it was manifesting in the other case solely because not all CPUs were running

23:10 <calebccff> are there any public docs that explain the huge puddle of acronyms that make up the sound hardware on qualcomm platforms?