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
