> > 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
