From: Caleb Connolly <caleb.connolly@linaro.org>
To: Konrad Dybcio <konrad.dybcio@linaro.org>,
Andy Gross <agross@kernel.org>,
Bhupesh Sharma <bhupesh.linux@gmail.com>,
Bjorn Andersson <andersson@kernel.org>,
Mathieu Poirier <mathieu.poirier@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Amit Kucheria <amitk@kernel.org>, Zhang Rui <rui.zhang@intel.com>,
Sibi Sankar <quic_sibis@quicinc.com>,
Manivannan Sadhasivam <mani@kernel.org>,
Thara Gopinath <thara.gopinath@gmail.com>
Cc: linux-arm-msm@vger.kernel.org, linux-remoteproc@vger.kernel.org,
devicetree@vger.kernel.org, linux-pm@vger.kernel.org
Subject: Re: [PATCH 3/4] thermal: qcom: add qmi-cooling driver
Date: Fri, 29 Sep 2023 17:56:32 +0100 [thread overview]
Message-ID: <1765d8c7-2f7e-4cb9-9063-f78c5d29e1a4@linaro.org> (raw)
In-Reply-To: <30aa40c9-b63a-093c-954d-86e4bb232431@linaro.org>
On 29/09/2023 17:28, Konrad Dybcio wrote:
>
>
> On 9/29/23 18:16, Caleb Connolly wrote:
>> The Thermal Mitigation Device (TMD) service exposes various platform
>> specific thermal mitigations available on remote subsystems (ie the
>> modem, adsp, cdsp, and sdsp). The service is exposed via the QMI
>> messaging
>> interface, usually over the QRTR transport.
>>
>> These controls affect things like the power limits of the modem power
>> amplifier and cpu core, skin temperature mitigations, as well as rail
>> voltage restrictions under cold conditions.
>>
>> Each remote subsystem has its own TMD instance, where each child node
>> represents a single thermal control.
>>
>> Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
>> ---
> [...]
>
>> +/* Notify the remote subsystem of the requested cooling state */
>> +static int qmi_tmd_send_state_request(struct qmi_tmd *tmd)
>> +{
>> + struct tmd_set_mitigation_level_resp_msg_v01 tmd_resp;
>> + struct tmd_set_mitigation_level_req_msg_v01 req;
>> + struct qmi_tmd_client *client;
>> + struct qmi_txn txn;
>> + int ret = 0;
>> +
>> + client = tmd->client;
> You can assign it at declaration time
Is this just personal preference or is it subsystem rules? I generally
prefer to avoid non-const assignments at declaration time, it's just
easier to read this way.
>> +
>> + if (!client->connection_active)
>> + return 0;
> Is that an expected scenario?
Yes, this function is called by the cooling device set_cur_state op. The
cooling device itself is always registered, even if the remoteproc is
offline (in which case the cached state will be sent to it when it
starts up).
>
>> +
>> + memset(&req, 0, sizeof(req));
>> + memset(&tmd_resp, 0, sizeof(tmd_resp));
> Since you're declaring them above, you can do = { 0 }; instead, which
> will be faster
Thanks, will do (though fwiw the compiler almost definitely optimises
this out).
>
>> +
>> + strscpy(req.mitigation_dev_id.mitigation_dev_id, tmd->qmi_name,
>> + QMI_TMD_MITIGATION_DEV_ID_LENGTH_MAX_V01 + 1);
>> + req.mitigation_level = tmd->cur_state;
>> +
>> + mutex_lock(&client->mutex);
> Look into fancy scoped mutexes https://lwn.net/Articles/934679/
ooh nice, that actually improves things a lot :D
>
> [...]
>
>> +static int qmi_set_cur_state(struct thermal_cooling_device *cdev,
>> unsigned long state)
>> +{
>> + struct qmi_tmd *tmd = cdev->devdata;
>> +
>> + if (!tmd)
>> + return -EINVAL;
>> +
>> + if (state > tmd->max_state)
>> + return -EINVAL;Would it be useful if this threw an error in
>> dmesg?
I may be mistaken but I think the only place this will be hit is when
userspace attempts to write to it via sysfs, in that case the invalid
argument is likely enough.
>
>
>> + * When the QMI service starts up on a remote subsystem this function
>> will fetch
>> + * the list of TMDs on the subsystem, match it to the TMDs specified
>> in devicetree
>> + * and call qmi_tmd_init_control() for each
>> + */
>> +static void qmi_tmd_svc_arrive(struct work_struct *work)
>> +{
>> + struct qmi_tmd_client *client =
>> + container_of(work, struct qmi_tmd_client, svc_arrive_work);
>> +
>> + struct tmd_get_mitigation_device_list_req_msg_v01 req;
>> + struct tmd_get_mitigation_device_list_resp_msg_v01 *resp;
>> + int ret = 0, i;
>> + struct qmi_txn txn;
>> +
>> + memset(&req, 0, sizeof(req));
> = { 0 }
>
> [...]
>
>> +
>> + pr_info("QMI TMD service reset %s\n", client->name);
> Is it useful to the user? pr_debug?
Oops, forgot to remove these!
>
>> +
>> + list_for_each_entry(tmd, &client->cdev_list, node) {
>> + qmi_tmd_send_state_request(tmd);
>> + }
>> +}
>> +
>> +static void thermal_qmi_del_server(struct qmi_handle *qmi, struct
>> qmi_service *service)
>> +{
>> + struct qmi_tmd_client *client = container_of(qmi, struct
>> qmi_tmd_client, handle);
>> +
>> + pr_info("QMI TMD service stop %s\n", client->name);
> Ditto
>
>> +
>> + client->connection_active = false;
>> +}
>> +
>> +static int thermal_qmi_new_server(struct qmi_handle *qmi, struct
>> qmi_service *service)
>> +{
>> + struct qmi_tmd_client *client = container_of(qmi, struct
>> qmi_tmd_client, handle);
>> + struct sockaddr_qrtr sq = { AF_QIPCRTR, service->node,
>> service->port };
>> +
>> + pr_info("QMI TMD service start %s\n", client->name);
> Ditto
>
>> + tmd->type = devm_kasprintf(client->dev, GFP_KERNEL, "%s:%s",
>> + client->name, subnode->name);
>> + if (!tmd->type)
>> + return dev_err_probe(dev, -ENOMEM, "Cooling device name\n");
> Cooling device name-what? :D
"error -12: Cooling device name"
Maybe this shouldn't print an error at all? I usually just like to have
something to grep for so I don't have to binary search through error
paths when debugging.
>
>> +
>> + if (of_property_read_string(subnode, "label", &name)) {
>> + return dev_err_probe(client->dev, -EINVAL,
>> + "Fail to parse dev name for %s\n",
> Failed
ack
>
> [...]
>
>> +static int qmi_tmd_client_probe(struct platform_device *pdev)
>> +{
>> + struct device *dev;
>> + struct qmi_tmd_client *client;
>> + const struct qmi_instance_id *match;
>> + int ret;
>> +
>> + dev = &pdev->dev;
> Initialize at declaration
>
>> +
>> + client = devm_kzalloc(dev, sizeof(*client), GFP_KERNEL);
>> + if (!client)
>> + return -ENOMEM;
>> +
>> + client->dev = dev;
>> +
>> + match = of_device_get_match_data(dev);
>> + if (!match)
>> + return dev_err_probe(dev, -EINVAL, "No match data\n");
>> +
>> + client->id = match->id;
>> + client->name = match->name;
>> +
>> + mutex_init(&client->mutex);
>> + INIT_LIST_HEAD(&client->cdev_list);
>> + INIT_WORK(&client->svc_arrive_work, qmi_tmd_svc_arrive);
>> +
>> + ret = qmi_tmd_alloc_cdevs(client);
>> + if (ret)
>> + return ret;
>> +
>> + platform_set_drvdata(pdev, client);
>> +
>> + ret = qmi_handle_init(&client->handle,
>> +
>> TMD_GET_MITIGATION_DEVICE_LIST_RESP_MSG_V01_MAX_MSG_LEN,
>> + &thermal_qmi_event_ops, NULL);
>> + if (ret < 0)
>> + return dev_err_probe(client->dev, ret, "QMI handle init
>> failed for client %#x\n",
>> + client->id);
>> +
>> + ret = qmi_add_lookup(&client->handle, TMD_SERVICE_ID_V01,
>> TMD_SERVICE_VERS_V01,
>> + client->id);
>> + if (ret < 0) {
>> + qmi_handle_release(&client->handle);
>> + return dev_err_probe(client->dev, ret, "QMI register failed
>> for client 0x%x\n",
>> + client->id);
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int qmi_tmd_client_remove(struct platform_device *pdev)
> void + .remove_new
Ack
>
> Konrad
--
// Caleb (they/them)
next prev parent reply other threads:[~2023-09-29 16:56 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-29 16:16 [PATCH 0/4] thermal: Introduce Qualcomm Thermal Mitigation Device support Caleb Connolly
2023-09-29 16:16 ` [PATCH 1/4] remoteproc: qcom: probe all child devices Caleb Connolly
2023-09-29 16:16 ` [PATCH 2/4] dt-bindings: thermal: Add qcom,qmi-cooling yaml bindings Caleb Connolly
2023-09-29 17:15 ` Rob Herring
2023-11-07 3:55 ` Bjorn Andersson
2023-09-29 16:16 ` [PATCH 3/4] thermal: qcom: add qmi-cooling driver Caleb Connolly
2023-09-29 16:28 ` Konrad Dybcio
2023-09-29 16:56 ` Caleb Connolly [this message]
2023-10-16 21:10 ` Daniel Lezcano
2023-09-29 16:16 ` [PATCH 4/4] MAINTAINERS: Add entry for Qualcomm Cooling Driver Caleb Connolly
2023-09-29 17:17 ` [PATCH 0/4] thermal: Introduce Qualcomm Thermal Mitigation Device support Konrad Dybcio
2023-09-29 18:27 ` Caleb Connolly
2023-10-01 15:57 ` Manivannan Sadhasivam
2023-10-01 17:26 ` Caleb Connolly
2023-10-02 14:52 ` Manivannan Sadhasivam
2023-10-02 15:00 ` Dmitry Baryshkov
2023-10-02 15:14 ` Caleb Connolly
2023-10-02 15:58 ` Manivannan Sadhasivam
2023-10-02 16:00 ` Dmitry Baryshkov
2023-10-02 16:13 ` Manivannan Sadhasivam
2023-10-02 16:28 ` Neil Armstrong
2023-10-05 2:36 ` Bjorn Andersson
2023-10-10 12:24 ` Manivannan Sadhasivam
2023-10-05 2:52 ` Bjorn Andersson
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=1765d8c7-2f7e-4cb9-9063-f78c5d29e1a4@linaro.org \
--to=caleb.connolly@linaro.org \
--cc=agross@kernel.org \
--cc=amitk@kernel.org \
--cc=andersson@kernel.org \
--cc=bhupesh.linux@gmail.com \
--cc=conor+dt@kernel.org \
--cc=daniel.lezcano@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=konrad.dybcio@linaro.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=mani@kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=quic_sibis@quicinc.com \
--cc=rafael@kernel.org \
--cc=robh+dt@kernel.org \
--cc=rui.zhang@intel.com \
--cc=thara.gopinath@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).