On Mon, 8 Apr 2024 at 02:14, Bjorn Andersson <andersson@xxxxxxxxxx> wrote: > > On Mon, Mar 11, 2024 at 05:34:03PM +0200, Dmitry Baryshkov wrote: > > diff --git a/drivers/soc/qcom/qcom_pdm.c b/drivers/soc/qcom/qcom_pdm.c > [..] > > +int qcom_pdm_add_domains(const struct qcom_pdm_domain_data * const *data, size_t num_data) > > +{ > > + int ret; > > + int i; > > + > > + mutex_lock(&qcom_pdm_mutex); > > + > > + if (qcom_pdm_server_added) { > > + ret = qmi_del_server(&qcom_pdm_handle, SERVREG_QMI_SERVICE, > > + SERVREG_QMI_VERSION, SERVREG_QMI_INSTANCE); > > Sorry for the late reply. > > I met with the owners of the firmware side of this and we concluded that > this will unfortunately not work. > > The typical case is that when the firmware comes up, it queries the > information from the pd-mapper about itself, so this would obviously > work just fine. > > Further more, if another core causes the server to be deleted and then > re-added the firmware will wait for pd-mapper to come up. So this will > work as well - as reported by Chris. > > There is however a not too uncommon case where the firmware on one > remoteproc will inquiry about information of another remoteproc. One > example is modem coming up, inquiring about where to find audio > services. This inquiry will be performed once at firmware boot and > decisions will be made based on the responses, no retries or updates. > > As such, starting pd-mapper with an incomplete "database" is > unfortunately not supported. Ack. Thanks for the info. Xilin Wu has also reported a rare race condition seemingly between pmic-glink and the pd-mapper. I think I will rework the code to bring up the full database based on the machine compatible. > > Regards, > Bjorn -- With best wishes Dmitry