Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
From: Frank Oltmanns <frank@oltmanns.dev>
To: Bjorn Andersson <andersson@kernel.org>,
	 Konrad Dybcio <konradybcio@kernel.org>,
	 Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	 Chris Lew <quic_clew@quicinc.com>
Cc: linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
	 Stephan Gerhold <stephan.gerhold@linaro.org>,
	 Johan Hovold <johan+linaro@kernel.org>,
	 Caleb Connolly <caleb.connolly@linaro.org>,
	 Joel Selvaraj <joelselvaraj.oss@gmail.com>,
	 Alexey Minnekhanov <alexeymin@postmarketos.org>,
	stable@vger.kernel.org,  Frank Oltmanns <frank@oltmanns.dev>
Subject: [PATCH] soc: qcom: pd-mapper: defer probing on sdm845
Date: Wed, 05 Feb 2025 22:57:11 +0100	[thread overview]
Message-ID: <20250205-qcom_pdm_defer-v1-1-a2e9a39ea9b9@oltmanns.dev> (raw)

On xiaomi-beryllium and oneplus-enchilada audio does not work reliably
with the in-kernel pd-mapper. Deferring the probe solves these issues.
Specifically, audio only works reliably with the in-kernel pd-mapper, if
the probe succeeds when remoteproc3 triggers the first successful probe.
I.e., probes from remoteproc0, 1, and 2 need to be deferred until
remoteproc3 has been probed.

Introduce a device specific quirk that lists the first auxdev for which
the probe must be executed. Until then, defer probes from other auxdevs.

Fixes: 1ebcde047c54 ("soc: qcom: add pd-mapper implementation")
Cc: stable@vger.kernel.org
Signed-off-by: Frank Oltmanns <frank@oltmanns.dev>
---
The in-kernel pd-mapper has been causing audio issues on sdm845
devices (specifically, xiaomi-beryllium and oneplus-enchilada). I
observed that Stephan’s approach [1] - which defers module probing by
blocklisting the module and triggering a later probe - works reliably.

Inspired by this, I experimented with delaying the probe within the
module itself by returning -EPROBE_DEFER in qcom_pdm_probe() until a
certain time (13.9 seconds after boot, based on ktime_get()) had
elapsed. This method also restored audio functionality.

Further logging of auxdev->id in qcom_pdm_probe() led to an interesting
discovery: audio only works reliably with the in-kernel pd-mapper when
the first successful probe is triggered by remoteproc3. In other words,
probes from remoteproc0, 1, and 2 must be deferred until remoteproc3 has
been probed.

To address this, I propose introducing a quirk table (which currently
only contains sdm845) to defer probing until the correct auxiliary
device (remoteproc3) initiates the probe.

I look forward to your feedback.

Thanks,
  Frank

[1]: https://lore.kernel.org/linux-arm-msm/Zwj3jDhc9fRoCCn6@linaro.org/
---
 drivers/soc/qcom/qcom_pd_mapper.c | 43 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/drivers/soc/qcom/qcom_pd_mapper.c b/drivers/soc/qcom/qcom_pd_mapper.c
index 154ca5beb47160cc404a46a27840818fe3187420..34b26df665a888ac4872f56e948e73b561ae3b6b 100644
--- a/drivers/soc/qcom/qcom_pd_mapper.c
+++ b/drivers/soc/qcom/qcom_pd_mapper.c
@@ -46,6 +46,11 @@ struct qcom_pdm_data {
 	struct list_head services;
 };
 
+struct qcom_pdm_probe_first_dev_quirk {
+	const char *name;
+	u32 id;
+};
+
 static DEFINE_MUTEX(qcom_pdm_mutex); /* protects __qcom_pdm_data */
 static struct qcom_pdm_data *__qcom_pdm_data;
 
@@ -526,6 +531,11 @@ static const struct qcom_pdm_domain_data *x1e80100_domains[] = {
 	NULL,
 };
 
+static const struct qcom_pdm_probe_first_dev_quirk first_dev_remoteproc3 = {
+	.id = 3,
+	.name = "pd-mapper"
+};
+
 static const struct of_device_id qcom_pdm_domains[] __maybe_unused = {
 	{ .compatible = "qcom,apq8016", .data = NULL, },
 	{ .compatible = "qcom,apq8064", .data = NULL, },
@@ -566,6 +576,10 @@ static const struct of_device_id qcom_pdm_domains[] __maybe_unused = {
 	{},
 };
 
+static const struct of_device_id qcom_pdm_defer[] __maybe_unused = {
+	{ .compatible = "qcom,sdm845", .data = &first_dev_remoteproc3, },
+	{},
+};
 static void qcom_pdm_stop(struct qcom_pdm_data *data)
 {
 	qcom_pdm_free_domains(data);
@@ -637,6 +651,25 @@ static struct qcom_pdm_data *qcom_pdm_start(void)
 	return ERR_PTR(ret);
 }
 
+static bool qcom_pdm_ready(struct auxiliary_device *auxdev)
+{
+	const struct of_device_id *match;
+	struct device_node *root;
+	struct qcom_pdm_probe_first_dev_quirk *first_dev;
+
+	root = of_find_node_by_path("/");
+	if (!root)
+		return true;
+
+	match = of_match_node(qcom_pdm_defer, root);
+	of_node_put(root);
+	if (!match)
+		return true;
+
+	first_dev = (struct qcom_pdm_probe_first_dev_quirk *) match->data;
+	return (auxdev->id == first_dev->id) && !strcmp(auxdev->name, first_dev->name);
+}
+
 static int qcom_pdm_probe(struct auxiliary_device *auxdev,
 			  const struct auxiliary_device_id *id)
 
@@ -647,6 +680,15 @@ static int qcom_pdm_probe(struct auxiliary_device *auxdev,
 	mutex_lock(&qcom_pdm_mutex);
 
 	if (!__qcom_pdm_data) {
+		if (!qcom_pdm_ready(auxdev)) {
+			pr_debug("%s: Deferring probe for device %s (id: %u)\n",
+				__func__, auxdev->name, auxdev->id);
+			ret = -EPROBE_DEFER;
+			goto probe_stop;
+		}
+		pr_debug("%s: Probing for device %s (id: %u), starting pdm\n",
+			__func__, auxdev->name, auxdev->id);
+
 		data = qcom_pdm_start();
 
 		if (IS_ERR(data))
@@ -659,6 +701,7 @@ static int qcom_pdm_probe(struct auxiliary_device *auxdev,
 
 	auxiliary_set_drvdata(auxdev, __qcom_pdm_data);
 
+probe_stop:
 	mutex_unlock(&qcom_pdm_mutex);
 
 	return ret;

---
base-commit: 7f048b202333b967782a98aa21bb3354dc379bbf
change-id: 20250205-qcom_pdm_defer-3dc1271d74d9

Best regards,
-- 
Frank Oltmanns <frank@oltmanns.dev>


             reply	other threads:[~2025-02-05 22:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-05 21:57 Frank Oltmanns [this message]
2025-02-06  0:44 ` [PATCH] soc: qcom: pd-mapper: defer probing on sdm845 Dmitry Baryshkov
2025-02-06  2:54 ` Bjorn Andersson
2025-02-06  5:57   ` Frank Oltmanns
2025-02-06  6:44     ` Frank Oltmanns
2025-02-06 18:25       ` Steev Klimaszewski
2025-02-09 12:07         ` Frank Oltmanns
2025-02-10  5:26           ` Steev Klimaszewski
2025-02-09 11:57       ` Frank Oltmanns
2025-02-12  2:48         ` Bjorn Andersson
2025-02-15  7:24           ` Frank Oltmanns
2025-02-12  5:45 ` Krzysztof Kozlowski
2025-02-12  6:26   ` Frank Oltmanns

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=20250205-qcom_pdm_defer-v1-1-a2e9a39ea9b9@oltmanns.dev \
    --to=frank@oltmanns.dev \
    --cc=alexeymin@postmarketos.org \
    --cc=andersson@kernel.org \
    --cc=caleb.connolly@linaro.org \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=joelselvaraj.oss@gmail.com \
    --cc=johan+linaro@kernel.org \
    --cc=konradybcio@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quic_clew@quicinc.com \
    --cc=stable@vger.kernel.org \
    --cc=stephan.gerhold@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