On 6/1/23 03:25, Powen Kao (高伯文) wrote:
According to spec, driver is free to assign any SQ to CQ mapping. I am
not sure if it's ideal to constrain mapping to specific kind.
As has been made clear several times recently during discussions around
LSF/MM topics, implementing all features of a standard is *not* one of the
goals of the Linux kernel. Whether a feature is defined in the NVMe, a SCSI
or the UFS standard, we (Linux kernel community) only support those features
that we consider useful and that can be implemented with a reasonable effort.
An example of a feature that probably will never be supported by the Linux
kernel is the "domains and realms" functionality from ZBC-2.
Yes, please refer to
"[PATCH v2 3/3] scsi: ufs: ufs-mediatek: Add MCQ support for MTK
platform"
+static int ufs_mtk_config_cqid(struct ufs_hba *hba)
+{
+ struct ufs_hw_queue *hwq;
+ int i;
+
+ for (i = 0; i < hba->nr_hw_queues; i++) {
+ hwq = &hba->uhq[i];
+ hwq->cqid = 3;
+ }
+
+ return 0;
+}
Thanks, I had overlooked this. Do you agree that the above shows that the
flag I proposed in my previous email (UFSHCD_CAP_SINGLE_CQ) is sufficient
to support the MediaTek use case? I want to keep the SQ-CQ association code
in the UFS driver core because the next step will probably to switch from
one CQ per SQ to one CQ per CPU core for UFS controllers that support
multiple completion interrupts.
Thanks,
Bart.
