From: Chris Lew <quic_clew@quicinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konrad.dybcio@linaro.org>,
Mathieu Poirier <mathieu.poirier@linaro.org>,
<linux-arm-msm@vger.kernel.org>,
<linux-remoteproc@vger.kernel.org>,
Johan Hovold <johan+linaro@kernel.org>
Subject: Re: [PATCH v4 3/7] soc: qcom: add pd-mapper implementation
Date: Thu, 14 Mar 2024 17:57:38 -0700 [thread overview]
Message-ID: <f4e2c00e-b669-9827-a480-5670ef9711c0@quicinc.com> (raw)
In-Reply-To: <CAA8EJpokFA=s5uhrb-OxH=BigfAP7jZ_K5z1FXJ0p1h3h3_CLQ@mail.gmail.com>
On 3/14/2024 2:30 PM, Dmitry Baryshkov wrote:
> On Thu, 14 Mar 2024 at 21:44, Chris Lew <quic_clew@quicinc.com> wrote:
>>
>>
>>
>> On 3/11/2024 8:34 AM, Dmitry Baryshkov wrote:
>>> +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);
>>> + if (ret)
>>> + goto err_out;
>>> + }
>>> +
>>> + for (i = 0; i < num_data; i++) {
>>> + ret = qcom_pdm_add_domain_locked(data[i]);
>>> + if (ret)
>>> + goto err;
>>> + }
>>> +
>>> + ret = qmi_add_server(&qcom_pdm_handle, SERVREG_QMI_SERVICE,
>>> + SERVREG_QMI_VERSION, SERVREG_QMI_INSTANCE);
>>> + if (ret) {
>>> + pr_err("PDM: error adding server %d\n", ret);
>>> + goto err;
>>> + }
>>> +
>>> + qcom_pdm_server_added = true;
>>> +
>>> + mutex_unlock(&qcom_pdm_mutex);
>>> +
>>> + return 0;
>>> +
>>> +err:
>>> + while (--i >= 0)
>>> + qcom_pdm_del_domain_locked(data[i]);
>>> +
>>> + qmi_add_server(&qcom_pdm_handle, SERVREG_QMI_SERVICE,
>>> + SERVREG_QMI_VERSION, SERVREG_QMI_INSTANCE);
>>> +
>>> +err_out:
>>> + mutex_unlock(&qcom_pdm_mutex);
>>> +
>>> + return ret;
>>> +}
>>> +EXPORT_SYMBOL_GPL(qcom_pdm_add_domains);
>>> +
>>> +void qcom_pdm_del_domains(const struct qcom_pdm_domain_data * const *data, size_t num_data)
>>> +{
>>> + int i;
>>> +
>>> + mutex_lock(&qcom_pdm_mutex);
>>> +
>>> + if (qcom_pdm_server_added) {
>>> + qmi_del_server(&qcom_pdm_handle, SERVREG_QMI_SERVICE,
>>> + SERVREG_QMI_VERSION, SERVREG_QMI_INSTANCE);
>>> + }
>>
>> I am confused as to why we need to reset the qmi handle anytime
>> qcom_pdm_del_domains or qcom_pdm_add_domains is called. Is this to
>> trigger some kind of re-broadcast type notification to clients because
>> the service list has been updated?
>
> Yes. Otherwise clients like pmic-glink will miss new domains.
>
>>
>> My concern would be that this causes some kind of unintended side-effect
>> on the rprocs that are not restarting.
>
> Well, an alternative is to match machine compatible strings and to
> build a full list of domains right from the beginning.
>
Ok, thanks for clarifying. I spoke to some of the firmware developers
and a quick scan seems to indicate their handling is robust enough to
handle this. It is a change in expected behavior but I think the current
approach is reasonable.
>>
>>> +
>>> + for (i = 0; i < num_data; i++)
>>> + qcom_pdm_del_domain_locked(data[i]);
>>> +
>>> + qmi_add_server(&qcom_pdm_handle, SERVREG_QMI_SERVICE,
>>> + SERVREG_QMI_VERSION, SERVREG_QMI_INSTANCE);
>>> + qcom_pdm_server_added = true;
>>> +
>>> + mutex_unlock(&qcom_pdm_mutex);
>>> +}
>>> +EXPORT_SYMBOL_GPL(qcom_pdm_del_domains);
>>> +
>>> +static void qcom_pdm_get_domain_list(struct qmi_handle *qmi,
>>> + struct sockaddr_qrtr *sq,
>>> + struct qmi_txn *txn,
>>> + const void *decoded)
>>> +{
>>> + const struct servreg_loc_get_domain_list_req *req = decoded;
>>> + struct servreg_loc_get_domain_list_resp *rsp = kzalloc(sizeof(*rsp), GFP_KERNEL);
>>> + struct qcom_pdm_service *service;
>>> + u32 offset;
>>> + int ret;
>>> +
>>> + offset = req->offset_valid ? req->offset : 0;
>>> +
>>> + rsp->rsp.result = QMI_RESULT_SUCCESS_V01;
>>> + rsp->rsp.error = QMI_ERR_NONE_V01;
>>> +
>>> + rsp->db_revision_valid = true;
>>> + rsp->db_revision = 1;
>>> +
>>> + rsp->total_domains_valid = true;
>>> + rsp->total_domains = 0;
>>> +
>>> + mutex_lock(&qcom_pdm_mutex);
>>> +
>>> + service = qcom_pdm_find_locked(req->name);
>>> + if (service) {
>>> + struct qcom_pdm_domain *domain;
>>> +
>>> + rsp->domain_list_valid = true;
>>> + rsp->domain_list_len = 0;
>>> +
>>> + list_for_each_entry(domain, &service->domains, list) {
>>> + u32 i = rsp->total_domains++;
>>> +
>>> + if (i >= offset && i < SERVREG_LOC_MAX_DOMAINS) {
>>> + u32 j = rsp->domain_list_len++;
>>> +
>>> + strscpy(rsp->domain_list[j].name, domain->name,
>>> + sizeof(rsp->domain_list[i].name));
>>> + rsp->domain_list[j].instance_id = domain->instance_id;
>>> +
>>> + pr_debug("PDM: found %s / %d\n", domain->name,
>>> + domain->instance_id);
>>> + }
>>> + }
>>> +
>>> + }
>>> +
>>> + mutex_unlock(&qcom_pdm_mutex);
>>> +
>>> + pr_debug("PDM: service '%s' offset %d returning %d domains (of %d)\n", req->name,
>>> + req->offset_valid ? req->offset : -1, rsp->domain_list_len, rsp->total_domains);
>>> +
>>> + ret = qmi_send_response(qmi, sq, txn, SERVREG_LOC_GET_DOMAIN_LIST,
>>> + 2658,
>>> + servreg_loc_get_domain_list_resp_ei, rsp);
>>
>> Other QMI clients like pdr_interface have macros for the message size.
>> Can we considering adding one instead of using 2658 directly?
>
>
> Ack
>
>>
>>> + if (ret)
>>> + pr_err("Error sending servreg response: %d\n", ret);
>>> +
>>> + kfree(rsp);
>>> +}
>>> +
>>> +static void qcom_pdm_pfr(struct qmi_handle *qmi,
>>> + struct sockaddr_qrtr *sq,
>>> + struct qmi_txn *txn,
>>> + const void *decoded)
>>> +{
>>> + const struct servreg_loc_pfr_req *req = decoded;
>>> + struct servreg_loc_pfr_resp rsp = {};
>>> + int ret;
>>> +
>>> + pr_warn_ratelimited("PDM: service '%s' crash: '%s'\n", req->service, req->reason);
>>> +
>>> + rsp.rsp.result = QMI_RESULT_SUCCESS_V01;
>>> + rsp.rsp.error = QMI_ERR_NONE_V01;
>>> +
>>> + ret = qmi_send_response(qmi, sq, txn, SERVREG_LOC_PFR,
>>> + SERVREG_LOC_PFR_RESP_MSG_SIZE,
>>> + servreg_loc_pfr_resp_ei, &rsp);
>>> + if (ret)
>>> + pr_err("Error sending servreg response: %d\n", ret);
>>> +}
>>> +
>>> diff --git a/drivers/soc/qcom/qcom_pdm_msg.h b/drivers/soc/qcom/qcom_pdm_msg.h
>>> new file mode 100644
>>> index 000000000000..e576b87c67c0
>>> --- /dev/null
>>> +++ b/drivers/soc/qcom/qcom_pdm_msg.h
>>> @@ -0,0 +1,66 @@
>>> +// SPDX-License-Identifier: BSD-3-Clause
>>> +/*
>>> + * Copyright (c) 2018, Linaro Ltd.
>>> + * Copyright (c) 2016, Bjorn Andersson
>>> + */
>>> +
>>> +#ifndef __QMI_SERVREG_LOC_H__
>>> +#define __QMI_SERVREG_LOC_H__
>>> +
>>
>> Should we update the header guards to reflect the new file name?
>
> Ack
>
>>
>>> +#include <linux/types.h>
>>> +#include <linux/soc/qcom/qmi.h>
>>> +
>>> +#define SERVREG_QMI_SERVICE 64
>>> +#define SERVREG_QMI_VERSION 257
>>> +#define SERVREG_QMI_INSTANCE 0
>>> +#define QMI_RESULT_SUCCESS 0
>>> +#define QMI_RESULT_FAILURE 1
>>> +#define QMI_ERR_NONE 0
>>> +#define QMI_ERR_INTERNAL 1
>>> +#define QMI_ERR_MALFORMED_MSG 2
>>
>> I think these common QMI macro definitions are wrong. They should match
>> what is defined in <soc/qcom/qmi.h>. This is a bug in the userspace
>> pd-mapper header as well.
>
> Ack
>
>>
>>> +#endif
>>> diff --git a/include/linux/soc/qcom/pd_mapper.h b/include/linux/soc/qcom/pd_mapper.h
>>> new file mode 100644
>>> index 000000000000..86438b7ca6fe
>>> --- /dev/null
>>> +++ b/include/linux/soc/qcom/pd_mapper.h
>>> @@ -0,0 +1,39 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +/*
>>> + * Qualcomm Protection Domain mapper
>>> + *
>>> + * Copyright (c) 2023 Linaro Ltd.
>>> + */
>>> +#ifndef __QCOM_PD_MAPPER__
>>> +#define __QCOM_PD_MAPPER__
>>> +
>>> +struct qcom_pdm_domain_data {
>>> + const char *domain;
>>> + u32 instance_id;
>>> + /* NULL-terminated array */
>>> + const char * services[];
>>
>> s/char * services[]/char *services[]/
>
>
>
next prev parent reply other threads:[~2024-03-15 0:57 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-11 15:34 [PATCH v4 0/7] soc: qcom: add in-kernel pd-mapper implementation Dmitry Baryshkov
2024-03-11 15:34 ` [PATCH v4 1/7] soc: qcom: pdr: protect locator_addr with the main mutex Dmitry Baryshkov
2024-03-13 23:35 ` Chris Lew
2024-03-14 0:07 ` Dmitry Baryshkov
2024-03-11 15:34 ` [PATCH v4 2/7] soc: qcom: qmi: add a way to remove running service Dmitry Baryshkov
2024-03-12 0:53 ` Konrad Dybcio
2024-03-12 1:03 ` Dmitry Baryshkov
2024-03-14 0:03 ` Chris Lew
2024-03-14 0:09 ` Dmitry Baryshkov
2024-03-14 17:15 ` Chris Lew
2024-03-11 15:34 ` [PATCH v4 3/7] soc: qcom: add pd-mapper implementation Dmitry Baryshkov
2024-03-12 0:55 ` Konrad Dybcio
2024-03-12 9:43 ` Johan Hovold
2024-03-12 9:36 ` Johan Hovold
2024-03-14 19:44 ` Chris Lew
2024-03-14 21:30 ` Dmitry Baryshkov
2024-03-15 0:57 ` Chris Lew [this message]
2024-04-07 23:14 ` Bjorn Andersson
2024-04-07 23:20 ` Dmitry Baryshkov
2024-03-11 15:34 ` [PATCH v4 4/7] remoteproc: qcom: pas: correct data indentation Dmitry Baryshkov
2024-03-11 15:34 ` [PATCH v4 5/7] remoteproc: qcom: adsp: add configuration for in-kernel pdm Dmitry Baryshkov
2024-03-16 18:15 ` Bjorn Andersson
2024-03-11 15:34 ` [PATCH v4 6/7] remoteproc: qcom: mss: " Dmitry Baryshkov
2024-03-11 15:34 ` [PATCH v4 7/7] remoteproc: qcom: pas: " Dmitry Baryshkov
2024-03-11 16:58 ` neil.armstrong
2024-03-11 17:18 ` [PATCH v4 0/7] soc: qcom: add in-kernel pd-mapper implementation neil.armstrong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f4e2c00e-b669-9827-a480-5670ef9711c0@quicinc.com \
--to=quic_clew@quicinc.com \
--cc=andersson@kernel.org \
--cc=dmitry.baryshkov@linaro.org \
--cc=johan+linaro@kernel.org \
--cc=konrad.dybcio@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox