On 4/1/22 02:32, Bean Huo wrote:
Agree that the current UFS driver is messy, but I don't think there was
such a big structural change before UFS 4.0 was released, especially
the design of the UFS CQE driver. If you already have a plan for CQE,
it's best to state it in the patch. If you have made such a big change
in an environment that is now very stable, do we have to make changes
after UFS 4.0? ?
Hi Bean,
Although this patch series will make it easier to add UFSHCI 4.0
support, I think that UFSHCI 4.0 support can also be added without this
patch series.
I'm not sure what CQE stands for in this context? Did you perhaps want
to refer to MCQ?
The following changes will have to be made to add UFSHCI 4.0 support
(this list is probably incomplete):
* At driver initialization time, query how many queues are supported by
the UFS controller and set scsi_host->nr_hw_queues accordingly.
* Modify all code that submits SCSI commands to a UFS controller or that
processes completions such that it uses the UFSHCI 3.0 registers for
controllers that do not support MCQ and the UFSHCI 4.0 registers for
controllers that do support MCQ.
* In ufshcd_queuecommand(), use blk_mq_unique_tag_to_hwq() to derive the
controller queue index from the SCSI command data structure.
* In the command completion path, use scsi_host_find_tag() to convert
the (MCQ index, command ID) pair into a SCSI command pointer.
* Add a mechanism to fall back to the UFSHCI 3.0 registers (no MCQ) to
make it easy to test the UFSHCI 3.0 code paths with UFSHCI 4.0 controllers.
Thanks,
Bart.
