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.
Regards,
Bjorn
