From: "Peter Wang (王信友)" <peter.wang@mediatek.com>
To: "beanhuo@micron.com" <beanhuo@micron.com>,
"can.guo@oss.qualcomm.com" <can.guo@oss.qualcomm.com>,
"avri.altman@wdc.com" <avri.altman@wdc.com>,
"bvanassche@acm.org" <bvanassche@acm.org>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>
Cc: "liu.song13@zte.com.cn" <liu.song13@zte.com.cn>,
"huobean@gmail.com" <huobean@gmail.com>,
"frank.li@vivo.com" <frank.li@vivo.com>,
"luhongfei@vivo.com" <luhongfei@vivo.com>,
"tanghuan@vivo.com" <tanghuan@vivo.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"zhongqiu.han@oss.qualcomm.com" <zhongqiu.han@oss.qualcomm.com>,
"quic_nguyenb@quicinc.com" <quic_nguyenb@quicinc.com>,
"alim.akhtar@samsung.com" <alim.akhtar@samsung.com>,
"keosung.park@samsung.com" <keosung.park@samsung.com>,
"chullee@google.com" <chullee@google.com>,
"adrian.hunter@intel.com" <adrian.hunter@intel.com>,
"James.Bottomley@HansenPartnership.com"
<James.Bottomley@HansenPartnership.com>,
"ram.dwivedi@oss.qualcomm.com" <ram.dwivedi@oss.qualcomm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 1/1] scsi: ufs: core: Add support to notify userspace of UniPro QoS events
Date: Fri, 6 Mar 2026 07:11:14 +0000 [thread overview]
Message-ID: <b0a7b6ecc14981295390b57e5ef18eaa5b07dbc2.camel@mediatek.com> (raw)
In-Reply-To: <20260305110856.959211-2-can.guo@oss.qualcomm.com>
On Thu, 2026-03-05 at 03:08 -0800, Can Guo wrote:
> The UniPro stack manages to repair many potential Link problems
> without the
> need to notify the Application Layer. Repair mechanisms of the stack
> include L2 re-transmission and successful handling of PA_INIT.req.
> Nevertheless, any successful repair sequence requires Link bandwidth
> that
> is no longer vailable for the Application. Therefore, it may be
> useful for
> an Application to understand how often such repair attempts are made.
>
> The DME implements Quality of Service monitoring using a simple
> counting
> scheme, counting error events and comparing them against the number
> of
> correctly received or transmitted bytes. When the error counter
> exceeds a
> programmed threshold before the byte counter overflows, a DME_QoS.ind
> is
> issued to the Application and both counters are reset. When the byte
> counter overflows before the error counter has reached the programmed
> threshold, both counters are reset without triggering a DME_QoS.ind.
>
> The DME provides Link quality monitoring for the following purposes:
> 1. Detection of re-occurring repaired fatal error conditions on the
> Link
> (PA_INIT loop). This kind of detection is useful if capabilities
> exchanged between local and peer permit a potential operation at a
> higher M-PHY Gear, but the physical interconnect between local and
> peer
> Device does not, or, after Line quality degradation, no longer
> satisfies
> channel characteristics.
> 2. Detection of degraded inbound or outbound Link quality, to allow
> an
> Application to issue an ADAPT sequence for a Link running in HS-G4
> or
> higher HS Gears. This kind of detection is used to monitor a
> slowly
> degrading Link quality, e.g., one being affected by temperature
> and
> voltage variations, against the expected M-PHY bit error rate.
>
> Userspace can configure and enable UniPro QoS via UniPro QoS
> Attributes
> (via UFS BSG) and get notified by dme_qos_notification without
> polling
> UniPro QoS Status attribute. The dme_qos_notification attribute is a
> bitfield with the following bit assignments:
>
> Bit Description
> === ======================================
> 0 DME QoS Monitor has been reset by host
> 1 QoS from TX is detected
> 2 QoS from RX is detected
> 3 QoS from PA_INIT is detected
>
> Signed-off-by: Can Guo <can.guo@oss.qualcomm.com>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
next prev parent reply other threads:[~2026-03-06 7:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260305110856.959211-1-can.guo@oss.qualcomm.com>
2026-03-05 11:08 ` Can Guo
2026-03-05 12:30 ` Bart Van Assche
2026-03-06 7:11 ` Peter Wang (王信友) [this message]
2026-03-07 16:05 ` Martin K. Petersen
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=b0a7b6ecc14981295390b57e5ef18eaa5b07dbc2.camel@mediatek.com \
--to=peter.wang@mediatek.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=adrian.hunter@intel.com \
--cc=alim.akhtar@samsung.com \
--cc=avri.altman@wdc.com \
--cc=beanhuo@micron.com \
--cc=bvanassche@acm.org \
--cc=can.guo@oss.qualcomm.com \
--cc=chullee@google.com \
--cc=frank.li@vivo.com \
--cc=huobean@gmail.com \
--cc=keosung.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=liu.song13@zte.com.cn \
--cc=luhongfei@vivo.com \
--cc=martin.petersen@oracle.com \
--cc=quic_nguyenb@quicinc.com \
--cc=ram.dwivedi@oss.qualcomm.com \
--cc=tanghuan@vivo.com \
--cc=zhongqiu.han@oss.qualcomm.com \
/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
all inboxes | Powered by JetHome®