RE: [PATCH v6 03/10] scsi: ufshpb: Add region's reads counter

From: Avri Altman
Date: Sat Mar 27 2021 - 04:05:49 EST


> > > @@ -596,12 +615,43 @@ int ufshpb_prep(struct ufs_hba *hba, struct
> > > ufshcd_lrb *lrbp)
> > > ufshpb_set_ppn_dirty(hpb, rgn_idx, srgn_idx, srgn_offset,
> > > transfer_len);
> > > spin_unlock_irqrestore(&hpb->rgn_state_lock, flags);
> > > +
> > > + if (hpb->is_hcm) {
> > > + spin_lock(&rgn->rgn_lock);
> > > + rgn->reads = 0;
> > > + spin_unlock(&rgn->rgn_lock);
> Here also.
>
> > > + }
> > > +
> > > return 0;
> > > }
> > >
> > > if (!ufshpb_is_support_chunk(hpb, transfer_len))
> > > return 0;
> > >
> > > + if (hpb->is_hcm) {
> > > + bool activate = false;
> > > + /*
> > > + * in host control mode, reads are the main source for
> > > + * activation trials.
> > > + */
> > > + spin_lock(&rgn->rgn_lock);
> > > + rgn->reads++;
> > > + if (rgn->reads == ACTIVATION_THRESHOLD)
> > > + activate = true;
> > > + spin_unlock(&rgn->rgn_lock);
> > > + if (activate) {
> > > + spin_lock_irqsave(&hpb->rsp_list_lock, flags);
> > > + ufshpb_update_active_info(hpb, rgn_idx, srgn_idx);
> >
> > If a transfer_len (possible with HPB2.0) sits accross two
> > regions/sub-regions,
> > here it only updates active info of the first region/sub-region.
> Yes. Will fix.
Giving it another look, I noticed that the current design only support a single subregion per region.
As activation is done per subregion, we need to count reads per subregion and make those activation decisions accordingly.
Still, the read counter per region needs to stay, as well as its spinlock for the inactivation decision.

Will fix it in my next version. Waiting for v32.

Thanks,
Avri

>
> Thanks,
> Avri
>
> >
> > Thanks,
> > Can Guo.
> >