From: Kishore Batta <kishore.batta@oss.qualcomm.com>
To: Manivannan Sadhasivam <mani@kernel.org>
Cc: 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>,
andersson@kernel.org, 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
Subject: Re: [PATCH v4 8/9] bus: mhi: Expose DDR training data via controller sysfs
Date: Tue, 14 Apr 2026 15:26:47 +0530 [thread overview]
Message-ID: <8f620562-2e1e-4d61-a823-767fbe51828a@oss.qualcomm.com> (raw)
In-Reply-To: <tbwahssgudfeacfj3wcg32yw5fkqorswees4gv4geypjmmdcyu@tv6qkuhyw23l>
On 4/13/2026 5:28 PM, Manivannan Sadhasivam wrote:
> On Thu, Mar 19, 2026 at 12:01:48PM +0530, Kishore Batta wrote:
>> 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.
>>
> Maybe share some steps on how the userspace is expected to use this calibration
> data.
Sure. will update the commit message with the required details in the
next version.
>> Expose the captured DDR training data via a read-only binary sysfs
>> attribute on the MHI controller device. The sysfs file is created under
>> the controller node, allowing userspace to read the training data even
>> after the sahara channel device has been removed.
>>
> So once the calibration data is read, how it can be used further?
The userspace will store the calibration data in
"mdmddr_0x<serial_no>.mbn format. In the next boot, Sahara driver loads
the real DDR calibration data and training data will be restored. No
repeated DDR training is performed at target end.
>
>> The sysfs attribute reads directly from controller-scoped storage and
>> relies on device managed resources for cleanup when the controller
>> device is destroyed. No explicit sysfs removal is required, avoiding
>> lifetime dependencies on the Sahara channel device.
>>
> Missing ABI documentation.
>
> - Mani
Currently i have added in a separate patch(9/9). I will squash it with
this patch in the next version.
>> Signed-off-by: Kishore Batta <kishore.batta@oss.qualcomm.com>
>> ---
>> drivers/bus/mhi/sahara/sahara.c | 69 +++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 69 insertions(+)
>>
>> diff --git a/drivers/bus/mhi/sahara/sahara.c b/drivers/bus/mhi/sahara/sahara.c
>> index c88f1220199ac4373d3552167870c19a0d5f23b9..b7208738df10fc3c3895acd46873412818dc1730 100644
>> --- a/drivers/bus/mhi/sahara/sahara.c
>> +++ b/drivers/bus/mhi/sahara/sahara.c
>> @@ -415,6 +415,73 @@ static struct sahara_ctrl_trng_data *sahara_ctrl_trng_get(struct device *dev)
>> 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_ctrl_trng_data *ct;
>> + size_t available;
>> +
>> + ct = sahara_ctrl_trng_get(dev);
>> + if (!ct)
>> + return -ENODEV;
>> +
>> + mutex_lock(&ct->lock);
>> +
>> + /* No data yet or offset past end */
>> + if (!ct->data || 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 const struct bin_attribute ddr_training_data_attr = {
>> + .attr = {
>> + .name = "ddr_training_data",
>> + .mode = 0444,
>> + },
>> + .read = ddr_training_data_read,
>> +};
>> +
>> +static void sahara_sysfs_devres_release(struct device *dev, void *res)
>> +{
>> + device_remove_bin_file(dev, &ddr_training_data_attr);
>> +}
>> +
>> +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, &ddr_training_data_attr);
>> + 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, &ddr_training_data_attr);
>> + return;
>> + }
>> +
>> + devres_add(dev, cookie);
>> +}
>> +
>> static int sahara_find_image(struct sahara_context *context, u32 image_id)
>> {
>> char *fw_path;
>> @@ -1272,6 +1339,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
>>
next prev parent reply other threads:[~2026-04-14 9:56 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-19 6:31 [PATCH v4 0/9] Qualcomm Sahara protocol enhancements Kishore Batta
2026-03-19 6:31 ` [PATCH v4 1/9] Add documentation for Sahara protocol Kishore Batta
2026-04-09 19:47 ` Jeff Hugo
2026-04-13 9:03 ` Kishore Batta
2026-03-19 6:31 ` [PATCH v4 2/9] bus: mhi: Move sahara protocol driver under drivers/bus/mhi Kishore Batta
2026-04-09 20:20 ` Jeff Hugo
2026-04-13 9:03 ` Kishore Batta
2026-04-13 11:04 ` Manivannan Sadhasivam
2026-04-14 9:45 ` Kishore Batta
2026-04-13 11:20 ` Manivannan Sadhasivam
2026-04-14 9:48 ` Kishore Batta
2026-03-19 6:31 ` [PATCH v4 3/9] bus: mhi: Match devices exposing the protocol on the SAHARA channel Kishore Batta
2026-04-09 20:23 ` Jeff Hugo
2026-04-13 9:03 ` Kishore Batta
2026-03-19 6:31 ` [PATCH v4 4/9] bus: mhi: Centralize firmware image table selection at probe time Kishore Batta
2026-04-09 20:52 ` Jeff Hugo
2026-04-13 9:04 ` Kishore Batta
2026-04-13 11:26 ` Manivannan Sadhasivam
2026-04-14 9:49 ` Kishore Batta
2026-03-19 6:31 ` [PATCH v4 5/9] bus: mhi: Add QDU100 variant and image_id firmware fallback Kishore Batta
2026-04-09 21:14 ` Jeff Hugo
2026-04-13 11:34 ` Manivannan Sadhasivam
2026-04-14 9:51 ` Kishore Batta
2026-03-19 6:31 ` [PATCH v4 6/9] bus: mhi: Load DDR training data using per-device serial number Kishore Batta
2026-04-09 21:23 ` Jeff Hugo
2026-03-19 6:31 ` [PATCH v4 7/9] bus: mhi: Capture DDR training data using command mode Kishore Batta
2026-03-22 17:39 ` kernel test robot
2026-04-09 21:27 ` Jeff Hugo
2026-04-13 9:05 ` Kishore Batta
2026-03-19 6:31 ` [PATCH v4 8/9] bus: mhi: Expose DDR training data via controller sysfs Kishore Batta
2026-04-13 11:58 ` Manivannan Sadhasivam
2026-04-14 9:56 ` Kishore Batta [this message]
2026-03-19 6:31 ` [PATCH v4 9/9] Documentation: ABI: Add sysfs ABI documentation for DDR training data Kishore Batta
2026-04-09 21:30 ` Jeff Hugo
2026-04-13 9:05 ` Kishore Batta
2026-04-13 11:59 ` Manivannan Sadhasivam
2026-04-14 9:57 ` Kishore Batta
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=8f620562-2e1e-4d61-a823-767fbe51828a@oss.qualcomm.com \
--to=kishore.batta@oss.qualcomm.com \
--cc=andersson@kernel.org \
--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=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