Re: [PATCH v3] scsi: ufs-msm: add UFS controller support for Qualcomm MSM chips

[subhashj]

>> On Aug 14, 2014, at 9:22 AM, Yaniv Gardi <ygardi@xxxxxxxxxxxxxx> wrote:
>>> The files in this change implement the UFS HW (controller & PHY) specific
>>> behavior in Qualcomm MSM chips.
>>> Signed-off-by: Yaniv Gardi <ygardi@xxxxxxxxxxxxxx>
>>> ---
>>> Documentation/devicetree/bindings/ufs/ufs-msm.txt  |   37 +
>>> .../devicetree/bindings/ufs/ufshcd-pltfrm.txt      |    4 +
>>> drivers/scsi/ufs/Kconfig                           |   12 +
>>> drivers/scsi/ufs/Makefile                          |    4 +
>>> drivers/scsi/ufs/ufs-msm-phy-qmp-20nm.c            |  254 +++++
drivers/scsi/ufs/ufs-msm-phy-qmp-20nm.h            |  216 ++++
drivers/scsi/ufs/ufs-msm-phy-qmp-28nm.c            |  368 +++++++
drivers/scsi/ufs/ufs-msm-phy-qmp-28nm.h            |  735
+++++++++++++
>>> drivers/scsi/ufs/ufs-msm-phy.c                     |  646 ++++++++++++
drivers/scsi/ufs/ufs-msm-phy.h                     |  193 ++++
>> Any reason not to put the phy driver in drivers/phy ?
> Yes. Phy driver introduces a generic phy framework.
> And as a framework it provides with API's, callbacks,
> And data structures.
> I think the right place to have the >implementation< of the ufs-msm-phy
code
> Is under drivers/scsi/ufs as it's more related to ufs than it's related
to
> the framework itself.

I would agree with Kumar that PHY specific platform driver (which uses the
generic PHY framwork) can actually go under drivers/phy/*, if i look at
the 3.17-rc1, there are many platform specific phy drivers under
drivers/phy/.

>>> drivers/scsi/ufs/ufs-msm.c                         | 1105
>>> ++++++++++++++++++++
>>> drivers/scsi/ufs/ufs-msm.h                         |  158 +++
>>> 12 files changed, 3732 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/ufs/ufs-msm.txt
create mode 100644 drivers/scsi/ufs/ufs-msm-phy-qmp-20nm.c
>>> create mode 100644 drivers/scsi/ufs/ufs-msm-phy-qmp-20nm.h
>>> create mode 100644 drivers/scsi/ufs/ufs-msm-phy-qmp-28nm.c
>>> create mode 100644 drivers/scsi/ufs/ufs-msm-phy-qmp-28nm.h
>>> create mode 100644 drivers/scsi/ufs/ufs-msm-phy.c
>>> create mode 100644 drivers/scsi/ufs/ufs-msm-phy.h
>>> create mode 100644 drivers/scsi/ufs/ufs-msm.c
>>> create mode 100644 drivers/scsi/ufs/ufs-msm.h
>> Seems like we should spit this into two patches, one for the phy and
one
>> for the UFS driver itself.  Maybe even three, one for the 20nm phy, one
for the 28nm phy, and one for ufs-msm.c,h.
> we could try to split it, but since we didn't split this change into
functional sub-changes, we decided to upload this change as a whole, as
one change without the other wouldn't work anyhow, and they are both
needed for proper functionality.
>>> diff --git a/Documentation/devicetree/bindings/ufs/ufs-msm.txt
b/Documentation/devicetree/bindings/ufs/ufs-msm.txt
>>> new file mode 100644
>>> index 0000000..b5caace
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/ufs/ufs-msm.txt
>> This should probably be bindings/phy/qcom-ufs-phy.txt

If Yaniv also agrees that Qualcomm UFS MSM PHY specific driver should move
under drivers/phy then yes, "ufs-msm.txt" should also move under
bindings/phy/.

Btw, regarding using "qcom-ufs-phy.txt" instead "ufs-msm.txt", i would
agree that we need to add "phy" in file name but not sure we would like to
replace "msm" with "qcom" because we used "msm" prefix/postfix almost
everywhere.



>>> @@ -0,0 +1,37 @@
>>> +* MSM Universal Flash Storage (UFS) PHY
>>> +
>>> +UFSPHY nodes are defined to describe on-chip UFS PHY hardware macro.
+Each UFS PHY node should have its own node.
>>> +
>>> +To bind UFS PHY with UFS host controller, the controller node should
+contain a phandle reference to UFS PHY node.
>>> +
>>> +Required properties:
>>> +- compatible        : compatible list, contains
>>> "qcom,ufs-msm-phy-qmp-28nm"
>>> +                      or "qcom,ufs-msm-phy-qmp-20nm" according to the
relevant
>>> +                      phy in use
>> Do we really need ?-msm? in the compat name?

That's the convention we followed for all file names and hence carry
forwarded to compatible name as well. Any specific issues with it?

>>> +- reg               : <registers mapping>
>>> +- #phy-cells         : This property shall be set to 0
>>> +- vdda-phy-supply   : phandle to main PHY supply for analog domain +-
vdda-pll-supply   : phandle to PHY PLL and Power-Gen block power
supply
>>> +
>>> +Optional properties:
>>> +- vdda-phy-max-microamp : specifies max. load that can be drawn from
phy supply
>>> +- vdda-pll-max-microamp : specifies max. load that can be drawn from
pll supply
>>> +
>>> +Example:
>>> +
>>> +	ufsphy1: ufsphy@0xfc597000 {
>>> +		compatible = "qcom,ufs-msm-phy-qmp-28nm";
>>> +		reg = <0xfc597000 0x800>;
>>> +		#phy-cells = <0>;
>>> +		vdda-phy-supply = <&pma8084_l4>;
>>> +		vdda-pll-supply = <&pma8084_l12>;
>>> +		vdda-phy-max-microamp = <50000>;
>>> +		vdda-pll-max-microamp = <1000>;
>>> +	};
>>> +
>>> +	ufshc@0xfc598000 {
>>> +		...
>>> +		phys = <&ufsphy1>;
>>> +	};
>>> diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>>> index e73a619..378585c 100644
>>> --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>>> +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>>> @@ -9,6 +9,9 @@ Required properties:
>>> - reg               : <registers mapping>
>>> Optional properties:
>>> +- phys			: phandle to UFS PHY node
>>> +- phy-names		: the string "ufs_msm_phy" when is found in a node,
along
>>> +			  with "phys" attribute, provides phandle to UFS PHY node
>> seems like the phy-names should be more generic like ?ufsphy"

Agreed, in facts this "phy-names" property is no longer required. Yaniv,
can you please remove this.

>>> - vcc-supply            : phandle to VCC supply regulator node -
vccq-supply           : phandle to VCCQ supply regulator node -
vccq2-supply          : phandle to VCCQ2 supply regulator node @@
-39,6 +42,7 @@ Example:
>>> 		reg = <0xfc598000 0x800>;
>>> 		interrupts = <0 28 0>;
>>> +		ufs-phy = <&ufsphy>;
>>> 		vcc-supply = <&xxx_reg1>;
>>> 		vcc-supply-1p8;
>>> 		vccq-supply = <&xxx_reg2>;
>>> diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig index
6e07b2a..a8259e0 100644
>>> --- a/drivers/scsi/ufs/Kconfig
>>> +++ b/drivers/scsi/ufs/Kconfig
>>> @@ -70,3 +70,15 @@ config SCSI_UFSHCD_PLATFORM
>>> 	If you have a controller with this interface, say Y or M here.
>>> 	  If unsure, say N.
>>> +
>>> +config SCSI_UFS_MSM
>>> +	bool "MSM specific hooks to UFS controller platform driver"
>>> +	depends on SCSI_UFSHCD_PLATFORM && ARCH_MSM
>> This should probably be ARCH_QCOM instead of ARCH_MSM

ok. will check this. Thanks.

>>> +	help
>>> +	  This selects the MSM specific additions to UFSHCD platform driver.
+	  UFS host on MSM needs some vendor specific configuration before +	
 accessing the hardware which includes PHY configuration and vendor +	
 specific registers.
>>> +
>>> +	  Select this if you have UFS controller on MSM chipset.
>>> +	  If unsure, say N.
>> [ snip ]
>> - k
>> --
>> Employee of Qualcomm Innovation Center, Inc.
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
>> by The Linux Foundation
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/