Hi Bart
On Thu, Nov 2, 2023 at 12:43 AM Bart Van Assche <bvanassche@xxxxxxx> 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@xxxxxxxxxx>
> > ---
> > 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.
