| Message ID | 20210709065711.25195-15-chanho61.park@samsung.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [01/15] scsi: ufs: add quirk to handle broken UIC command | expand |
On Fri, 2021-07-09 at 15:57 +0900, Chanho Park wrote: > We divide this M-HCI as PH(Physical Host) and VHs(Virtual Host). The > PH > > supports all UFSHCI functions(all SAPs) same as conventional UFSHCI > but > > the VH only supports data transfer function. Thus, except UTP_CMD_SAP > and > > UTP_TMPSAP, the PH should handle all the physical features. Hi Chanho park, You mentioned this in your coverletter: "There are two types of host controllers on the UFS host controller that we designed. The UFS device has a Function Arbitor that arranges commands of each host. When each host transmits a command to the Arbitor, the Arbitor transmits it to the UTP layer". where does this "Function Arbitor" exit? From your comments, seems it exists on the UFS device side? right? If this is true, where is related code in your patch?? Maybe you only submited partial of your real driver parch for this controller?? Bean
> > We divide this M-HCI as PH(Physical Host) and VHs(Virtual Host). The > > PH > > > > supports all UFSHCI functions(all SAPs) same as conventional UFSHCI > > but > > > > the VH only supports data transfer function. Thus, except UTP_CMD_SAP > > and > > > > UTP_TMPSAP, the PH should handle all the physical features. > > Hi Chanho park, > > You mentioned this in your coverletter: > > "There are two types of host controllers on the UFS host controller that > we designed. The UFS device has a Function Arbitor that arranges commands > of each host. When each host transmits a command to the Arbitor, the > Arbitor transmits it to the UTP layer". > > where does this "Function Arbitor" exit? From your comments, seems it > exists on the UFS device side? right? If this is true, where is related > code in your patch?? The "Function Arbiter" is in our ufs controller as H/W and it is responsible to arrange UTP_CMD/UTP_TM among PH and VHs. When we set MHCTL register, the controller will enable the multi-host capability and the arbiter will be automatically enabled as well. +static int exynosauto_ufs_post_hce_enable(struct exynos_ufs *ufs) +{ + struct ufs_hba *hba = ufs->hba; + + /* Enable Virtual Host #1 */ + ufshcd_rmwl(hba, MHCTRL_EN_VH_MASK, MHCTRL_EN_VH(1), MHCTRL); + /* Default VH Transfer permissions */ + hci_writel(ufs, 0x03FFE1FE, HCI_MH_ALLOWABLE_TRAN_OF_VH); + /* IID information is replaced in TASKTAG[7:5] instead of IID in UCD */ + hci_writel(ufs, 0x1, HCI_MH_IID_IN_TASK_TAG); + + return 0; +} > Maybe you only submited partial of your real driver > parch for this controller?? Yes. The series is the initial version but it contains most of multi-host capabilities. Most of things can be handled by our UFS controller so we can make driver code simpler as much as possible. Only #1 VH can be supported in this patch at the moment but I have a plan to support more VHs later. Best Regards, Chanho Park
diff --git a/drivers/scsi/ufs/ufs-exynos.c b/drivers/scsi/ufs/ufs-exynos.c index 82f915f7a447..30c12e97c665 100644 --- a/drivers/scsi/ufs/ufs-exynos.c +++ b/drivers/scsi/ufs/ufs-exynos.c @@ -83,6 +83,21 @@ #define UFS_SHARABLE (UFS_WR_SHARABLE | UFS_RD_SHARABLE) #define UFS_SHARABILITY_OFFSET 0x710 +/* Multi-host registers */ +#define MHCTRL 0xC4 +#define MHCTRL_EN_VH_MASK (0xE) +#define MHCTRL_EN_VH(vh) (vh << 1) +#define PH2VH_MBOX 0xD8 + +#define MH_MSG_MASK (0xFF) + +#define MH_MSG(id, msg) ((id << 8) | (msg & 0xFF)) +#define MH_MSG_PH_READY 0x1 +#define MH_MSG_VH_READY 0x2 + +#define HCI_MH_ALLOWABLE_TRAN_OF_VH 0x30C +#define HCI_MH_IID_IN_TASK_TAG 0X308 + enum { UNIPRO_L1_5 = 0,/* PHY Adapter */ UNIPRO_L2, /* Data Link */ @@ -173,6 +188,20 @@ static int exynosauto_ufs_drv_init(struct device *dev, struct exynos_ufs *ufs) return 0; } +static int exynosauto_ufs_post_hce_enable(struct exynos_ufs *ufs) +{ + struct ufs_hba *hba = ufs->hba; + + /* Enable Virtual Host #1 */ + ufshcd_rmwl(hba, MHCTRL_EN_VH_MASK, MHCTRL_EN_VH(1), MHCTRL); + /* Default VH Transfer permissions */ + hci_writel(ufs, 0x03FFE1FE, HCI_MH_ALLOWABLE_TRAN_OF_VH); + /* IID information is replaced in TASKTAG[7:5] instead of IID in UCD */ + hci_writel(ufs, 0x1, HCI_MH_IID_IN_TASK_TAG); + + return 0; +} + static int exynosauto_ufs_pre_link(struct exynos_ufs *ufs) { struct ufs_hba *hba = ufs->hba; @@ -231,6 +260,19 @@ static int exynosauto_ufs_pre_pwr_change(struct exynos_ufs *ufs, return 0; } +static int exynosauto_ufs_post_pwr_change(struct exynos_ufs *ufs, + struct ufs_pa_layer_attr *pwr) +{ + struct ufs_hba *hba = ufs->hba; + u32 enabled_vh; + + enabled_vh = ufshcd_readl(hba, MHCTRL) & MHCTRL_EN_VH_MASK; + + /* Send physical host ready message to virtual hosts */ + ufshcd_writel(hba, MH_MSG(enabled_vh, MH_MSG_PH_READY), PH2VH_MBOX); + + return 0; +} static int exynos7_ufs_pre_link(struct exynos_ufs *ufs) { @@ -1396,8 +1438,10 @@ static struct exynos_ufs_drv_data exynosauto_ufs_drvs = { EXYNOS_UFS_OPT_SKIP_CONFIG_PHY_ATTR | EXYNOS_UFS_OPT_BROKEN_RX_SEL_IDX, .drv_init = exynosauto_ufs_drv_init, + .post_hce_enable = exynosauto_ufs_post_hce_enable, .pre_link = exynosauto_ufs_pre_link, .pre_pwr_change = exynosauto_ufs_pre_pwr_change, + .post_pwr_change = exynosauto_ufs_post_pwr_change, }; static struct exynos_ufs_drv_data exynos_ufs_drvs = {
UFS controller of ExynosAuto v9 SoC supports multi-host interface for I/O virtualization. In general, we're using para-virtualized driver to support a block device by several virtual machines. However, it should be relayed by backend driver. Multi-host functionality extends the host controller by providing register interfaces that can be used by each VM's ufs drivers respectively. By this, we can provide direct access to the UFS device for multiple VMs. It's similar with SR-IOV of PCIe. We divide this M-HCI as PH(Physical Host) and VHs(Virtual Host). The PH supports all UFSHCI functions(all SAPs) same as conventional UFSHCI but the VH only supports data transfer function. Thus, except UTP_CMD_SAP and UTP_TMPSAP, the PH should handle all the physical features. This patch provides an initial implementation of PH part. M-HCI can support up to four interfaces but this patch initially supports only 1 PH and 1 VH. For this, we uses TASK_TAG[7:5] field so TASK_TAG[4:0] for 32 doorbel will be supported. After the PH is initiated, this will send a ready message to VHs through a mailbox register. The message handler is not fully implemented yet such as supporting reset / abort cases. Signed-off-by: Chanho Park <chanho61.park@samsung.com> --- drivers/scsi/ufs/ufs-exynos.c | 44 +++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+)