From: Kishore Batta <kishore.batta@oss.qualcomm.com>
To: Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Jeff Hugo <jeff.hugo@oss.qualcomm.com>,
Carl Vanderlip <carl.vanderlip@oss.qualcomm.com>,
Oded Gabbay <ogabbay@kernel.org>,
Manivannan Sadhasivam <mani@kernel.org>,
Randy Dunlap <rdunlap@infradead.org>
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org,
mhi@lists.linux.dev,
Kishore Batta <kishore.batta@oss.qualcomm.com>
Subject: [PATCH v8 7/7] bus: mhi: Expose DDR training data via controller sysfs
Date: Mon, 12 Oct 2026 23:48:05 +0530 [thread overview]
Message-ID: <20261012-sahara_protocol_new_v2-v8-7-e12939d229a1@oss.qualcomm.com> (raw)
In-Reply-To: <20261012-sahara_protocol_new_v2-v8-0-e12939d229a1@oss.qualcomm.com>
DDR training data captured during Sahara command mode needs to be
accessible to userspace so it can be persisted and reused on subsequent
boots. Currently, the training data is stored internally in the driver
but has no external visibility once the Sahara channel is torn down.
Expose the captured DDR training data via a read-only binary sysfs
attribute on the MHI controller device:
/sys/bus/mhi/devices/<mhi_cntrl>/ddr_training_data
The sysfs read callback serves data directly from controller scoped storage
and protects access with the controller training data lock. The attribute
lifetime is tied to the controller device via devres, allowing the data to
remain readable after Sahara channel teardown and ensuring automatic
cleanup when controller device is removed.
Userspace flow:
1. For each controller device, userspace reads the ddr_training_data sysfs
attribute.
2. If the read returns non-zero data, userspace persists it using a
serial specific filename (for example, mdmddr_0x<serial_no>.mbn).
3. On subsequent boots, the Sahara driver attempts to load this serial
specific DDR training image before falling back to the default
training image, restoring DDR calibration data and avoiding retraining.
Add ABI documentation for the DDR training data sysfs attribute exposed by
Sahara MHI driver.
Signed-off-by: Kishore Batta <kishore.batta@oss.qualcomm.com>
---
.../ABI/testing/sysfs-bus-mhi-ddr_training_data | 19 +++++++
drivers/bus/mhi/host/clients/sahara/sahara.c | 63 ++++++++++++++++++++++
2 files changed, 82 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-mhi-ddr_training_data b/Documentation/ABI/testing/sysfs-bus-mhi-ddr_training_data
new file mode 100644
index 0000000000000000000000000000000000000000..810b487b5a5fdba133d81255f9879844e3938a10
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-mhi-ddr_training_data
@@ -0,0 +1,19 @@
+What: /sys/bus/mhi/devices/<mhi-cntrl>/ddr_training_data
+
+Date: March 2026
+
+Contact: Kishore Batta <kishore.batta@oss.qualcomm.com>
+
+Description: Contains the DDR training data for the Qualcomm device
+ connected. MHI driver populates different controller
+ nodes for each device. The DDR training data is exposed
+ to userspace to read and save the training data file to
+ the filesystem. In the subsequent boot up of the device,
+ the training data is restored from host to device
+ optimizing the boot up time of the device.
+
+Usage: Example for reading DDR training data:
+ cat /sys/bus/mhi/devices/mhi0/ddr_training_data
+
+Permissions: The file permissions are set to 0444 allowing read
+ access.
diff --git a/drivers/bus/mhi/host/clients/sahara/sahara.c b/drivers/bus/mhi/host/clients/sahara/sahara.c
index e7a6289b11a72d5dda008d6107eff6b4f9b67519..db6fb966fd93c9fef82e5599b7133299e1a4c337 100644
--- a/drivers/bus/mhi/host/clients/sahara/sahara.c
+++ b/drivers/bus/mhi/host/clients/sahara/sahara.c
@@ -273,6 +273,67 @@ static struct sahara_cntrl_training_data *sahara_cntrl_training_get(struct devic
return ct;
}
+static ssize_t ddr_training_data_read(struct file *filp, struct kobject *kobj,
+ const struct bin_attribute *attr, char *buf,
+ loff_t offset, size_t count)
+{
+ struct device *dev = kobj_to_dev(kobj);
+ struct sahara_cntrl_training_data *ct;
+ size_t available;
+
+ ct = sahara_cntrl_training_get(dev);
+ if (!ct)
+ return -ENODEV;
+
+ mutex_lock(&ct->lock);
+
+ /* No complete data yet or offset past end */
+ if (!ct->data || ct->receiving || ct->copied != ct->size ||
+ offset >= ct->size) {
+ mutex_unlock(&ct->lock);
+ return 0;
+ }
+
+ available = ct->size - offset;
+ count = min(count, available);
+ memcpy(buf, (u8 *)ct->data + offset, count);
+
+ mutex_unlock(&ct->lock);
+
+ return count;
+}
+static BIN_ATTR_RO(ddr_training_data, 0);
+
+static void sahara_sysfs_devres_release(struct device *dev, void *res)
+{
+ device_remove_bin_file(dev, &bin_attr_ddr_training_data);
+}
+
+static void sahara_sysfs_create(struct mhi_device *mhi_dev)
+{
+ struct device *dev = &mhi_dev->mhi_cntrl->mhi_dev->dev;
+ void *cookie;
+ int ret;
+
+ if (devres_find(dev, sahara_sysfs_devres_release, NULL, NULL))
+ return;
+
+ ret = device_create_bin_file(dev, &bin_attr_ddr_training_data);
+ if (ret) {
+ dev_warn(&mhi_dev->dev,
+ "Failed to create DDR training sysfs node (%d)\n", ret);
+ return;
+ }
+
+ cookie = devres_alloc(sahara_sysfs_devres_release, 1, GFP_KERNEL);
+ if (!cookie) {
+ device_remove_bin_file(dev, &bin_attr_ddr_training_data);
+ return;
+ }
+
+ devres_add(dev, cookie);
+}
+
static int sahara_find_image(struct sahara_context *context, u32 image_id)
{
char *fw_path;
@@ -1130,6 +1191,8 @@ static int sahara_mhi_probe(struct mhi_device *mhi_dev, const struct mhi_device_
return ret;
}
+ sahara_sysfs_create(mhi_dev);
+
return 0;
}
--
2.34.1
prev parent reply other threads:[~2026-10-12 18:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 18:17 [PATCH v8 0/7] Qualcomm Sahara protocol enhancements Kishore Batta
2026-10-12 18:17 ` [PATCH v8 1/7] Add documentation for Sahara protocol Kishore Batta
2026-10-12 18:18 ` [PATCH v8 2/7] bus: mhi: Move Sahara protocol driver under MHI host client drivers Kishore Batta
2026-10-12 20:43 ` Uwe Kleine-König
2026-10-12 21:35 ` Trilok Soni
2026-10-12 18:18 ` [PATCH v8 3/7] bus: mhi: Centralize Sahara firmware image table selection at probe time Kishore Batta
2026-10-12 18:18 ` [PATCH v8 4/7] bus: mhi: Add QDU100 Sahara variant and firmware fallback Kishore Batta
2026-10-12 18:18 ` [PATCH v8 5/7] bus: mhi: Load DDR training data using device serial number Kishore Batta
2026-10-12 18:18 ` [PATCH v8 6/7] bus: mhi: Capture DDR training data via command mode Kishore Batta
2026-10-12 18:18 ` Kishore Batta [this message]
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=20261012-sahara_protocol_new_v2-v8-7-e12939d229a1@oss.qualcomm.com \
--to=kishore.batta@oss.qualcomm.com \
--cc=carl.vanderlip@oss.qualcomm.com \
--cc=corbet@lwn.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=jeff.hugo@oss.qualcomm.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mani@kernel.org \
--cc=mhi@lists.linux.dev \
--cc=ogabbay@kernel.org \
--cc=rdunlap@infradead.org \
--cc=skhan@linuxfoundation.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
all inboxes | Powered by JetHome®