public inbox for linux-doc@vger.kernel.org
 help / color / mirror / Atom feed
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
>>

  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