scsi: ufs: core: Add compl_time_stamp_local_clock assignment

The compl_time_stamp_local_clock assignment seems to have been
accidentally deleted in the previous patch, so it needs to be added
again for debugging needs.

Fixes: c30d8d010b5e ("scsi: ufs: core: Prepare for completion in MCQ")
Signed-off-by: Zhe Wang <zhe.wang1@unisoc.com>
---
 drivers/ufs/core/ufshcd.c | 1 +
 1 file changed, 1 insertion(+)

On 11/1/23 00:14, Zhe Wang wrote:
> The compl_time_stamp_local_clock assignment seems to have been
> accidentally deleted in the previous patch, so it needs to be added
> again for debugging needs.
> 
> Fixes: c30d8d010b5e ("scsi: ufs: core: Prepare for completion in MCQ")
> Signed-off-by: Zhe Wang <zhe.wang1@unisoc.com>
> ---
>   drivers/ufs/core/ufshcd.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index 8382e8cfa414..b35977fa931f 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c
> @@ -5388,6 +5388,7 @@ void ufshcd_compl_one_cqe(struct ufs_hba *hba, int task_tag,
>   
>   	lrbp = &hba->lrb[task_tag];
>   	lrbp->compl_time_stamp = ktime_get();
> +	lrbp->compl_time_stamp_local_clock = local_clock();
>   	cmd = lrbp->cmd;
>   	if (cmd) {
>   		if (unlikely(ufshcd_should_inform_monitor(hba, lrbp)))

Is anyone using the data tracked in compl_time_stamp /
compl_time_stamp_local_clock? I'm wondering whether the code for
tracking command duration can be removed. Otherwise the above patch 
looks fine to me.

Thanks,

Bart.

Hi Bart

On Thu, Nov 2, 2023 at 12:43 AM Bart Van Assche <bvanassche@acm.org> wrote:
>
>
> On 11/1/23 00:14, Zhe Wang wrote:
> > The compl_time_stamp_local_clock assignment seems to have been
> > accidentally deleted in the previous patch, so it needs to be added
> > again for debugging needs.
> >
> > Fixes: c30d8d010b5e ("scsi: ufs: core: Prepare for completion in MCQ")
> > Signed-off-by: Zhe Wang <zhe.wang1@unisoc.com>
> > ---
> >   drivers/ufs/core/ufshcd.c | 1 +
> >   1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> > index 8382e8cfa414..b35977fa931f 100644
> > --- a/drivers/ufs/core/ufshcd.c
> > +++ b/drivers/ufs/core/ufshcd.c
> > @@ -5388,6 +5388,7 @@ void ufshcd_compl_one_cqe(struct ufs_hba *hba, int task_tag,
> >
> >       lrbp = &hba->lrb[task_tag];
> >       lrbp->compl_time_stamp = ktime_get();
> > +     lrbp->compl_time_stamp_local_clock = local_clock();
> >       cmd = lrbp->cmd;
> >       if (cmd) {
> >               if (unlikely(ufshcd_should_inform_monitor(hba, lrbp)))
>
> Is anyone using the data tracked in compl_time_stamp /
> compl_time_stamp_local_clock? I'm wondering whether the code for
> tracking command duration can be removed. Otherwise the above patch
> looks fine to me.
>
> Thanks,
>
> Bart.

'compl_time_stamp_local_clock' can correspond to the timestamp of
dmesg entries or other timestamps used by the UFS driver, such as
'tstamp' in 'struct ufs_event_hist'. The timestamp that can be
correlated with each other can be easily combined to record the
sequence of command execution for analyzing problem scenarios, so I
think it is quite useful.

Thanks,
Zhe.