| Message ID | 1477772534-14170-5-git-send-email-vivek.gautam@codeaurora.org (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | Andy Gross |
| Headers | show |
On 2016-10-29 13:22, Vivek Gautam wrote: > Add a new compatible string for 14nm ufs phy present on msm8996 > chipset. This phy is bit different from the legacy 14nm ufs phy > in terms of the clocks that are needed to be handled in the driver. > > Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org> > --- > > New patch in v3 of this cleanup series. > > Documentation/devicetree/bindings/ufs/ufs-qcom.txt | 7 +++++-- > drivers/phy/phy-qcom-ufs-qmp-14nm.c | 1 + > 2 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/ufs/ufs-qcom.txt > b/Documentation/devicetree/bindings/ufs/ufs-qcom.txt > index 070baf4..b6b5130 100644 > --- a/Documentation/devicetree/bindings/ufs/ufs-qcom.txt > +++ b/Documentation/devicetree/bindings/ufs/ufs-qcom.txt > @@ -7,8 +7,11 @@ 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-phy-qmp-20nm" > - or "qcom,ufs-phy-qmp-14nm" according to the relevant phy in > use. > +- compatible : compatible list, contains one of the following - > + "qcom,ufs-phy-qmp-20nm" for 20nm ufs phy, > + "qcom,ufs-phy-qmp-14nm" for legacy 14nm ufs phy, > + "qcom,msm8996-ufs-phy-qmp-14nm" for 14nm ufs phy > + present on MSM8996 chipset. For future chipsets (after MSM8996), we have to use this same compatible strings? If yes, "msm8996" in compatible string name may cause confusions? may be we should start following v1/v2/... terminologies for this? something like "qcom,ufs-phy-qmp-v2" to start with? > - reg : should contain PHY register address space > (mandatory), > - reg-names : indicates various resources passed to driver > (via reg proptery) by name. > Required "reg-names" is "phy_mem". > diff --git a/drivers/phy/phy-qcom-ufs-qmp-14nm.c > b/drivers/phy/phy-qcom-ufs-qmp-14nm.c > index e3bede7..b3d2612 100644 > --- a/drivers/phy/phy-qcom-ufs-qmp-14nm.c > +++ b/drivers/phy/phy-qcom-ufs-qmp-14nm.c > @@ -180,6 +180,7 @@ static int ufs_qcom_phy_qmp_14nm_remove(struct > platform_device *pdev) > > static const struct of_device_id ufs_qcom_phy_qmp_14nm_of_match[] = { > {.compatible = "qcom,ufs-phy-qmp-14nm"}, > + {.compatible = "qcom,msm8996-ufs-phy-qmp-14nm"}, > {}, > }; > MODULE_DEVICE_TABLE(of, ufs_qcom_phy_qmp_14nm_of_match);
Hi, On Tue, Nov 1, 2016 at 2:41 AM, Subhash Jadavani <subhashj@codeaurora.org> wrote: > On 2016-10-29 13:22, Vivek Gautam wrote: >> >> Add a new compatible string for 14nm ufs phy present on msm8996 >> chipset. This phy is bit different from the legacy 14nm ufs phy >> in terms of the clocks that are needed to be handled in the driver. >> >> Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org> >> --- >> >> New patch in v3 of this cleanup series. >> >> Documentation/devicetree/bindings/ufs/ufs-qcom.txt | 7 +++++-- >> drivers/phy/phy-qcom-ufs-qmp-14nm.c | 1 + >> 2 files changed, 6 insertions(+), 2 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/ufs/ufs-qcom.txt >> b/Documentation/devicetree/bindings/ufs/ufs-qcom.txt >> index 070baf4..b6b5130 100644 >> --- a/Documentation/devicetree/bindings/ufs/ufs-qcom.txt >> +++ b/Documentation/devicetree/bindings/ufs/ufs-qcom.txt >> @@ -7,8 +7,11 @@ 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-phy-qmp-20nm" >> - or "qcom,ufs-phy-qmp-14nm" according to the relevant >> phy in use. >> +- compatible : compatible list, contains one of the following - >> + "qcom,ufs-phy-qmp-20nm" for 20nm ufs phy, >> + "qcom,ufs-phy-qmp-14nm" for legacy 14nm ufs phy, >> + "qcom,msm8996-ufs-phy-qmp-14nm" for 14nm ufs phy >> + present on MSM8996 chipset. > > For future chipsets (after MSM8996), we have to use this same compatible > strings? If yes, "msm8996" in compatible string name may cause confusions? > may be we should start following v1/v2/... terminologies for this? > something like "qcom,ufs-phy-qmp-v2" to start with? Are we trying to complement the actual IP hardware versioning with this ? Isn't it possible that we will end up using v2 for more than a couple of actual IP hardware versions ? I have seen cases wherein the IP versions are preceded by the SOC names, the IPs appeared first in. And if the same IP is used in subsequent SOCs, we use same compatible string. This, rather, makes things easier to comprehend - it's the same IP that was used on older SoC. I am fine with adding versions to the compatible string as well. But like i asked earlier - are we just creating versions for our own understanding, or are we also complementing the actual IP hardware versions ? Thanks Vivek
On 2016-11-03 10:07, Vivek Gautam wrote: > Hi, > > > On Tue, Nov 1, 2016 at 2:41 AM, Subhash Jadavani > <subhashj@codeaurora.org> wrote: >> On 2016-10-29 13:22, Vivek Gautam wrote: >>> >>> Add a new compatible string for 14nm ufs phy present on msm8996 >>> chipset. This phy is bit different from the legacy 14nm ufs phy >>> in terms of the clocks that are needed to be handled in the driver. >>> >>> Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org> >>> --- >>> >>> New patch in v3 of this cleanup series. >>> >>> Documentation/devicetree/bindings/ufs/ufs-qcom.txt | 7 +++++-- >>> drivers/phy/phy-qcom-ufs-qmp-14nm.c | 1 + >>> 2 files changed, 6 insertions(+), 2 deletions(-) >>> >>> diff --git a/Documentation/devicetree/bindings/ufs/ufs-qcom.txt >>> b/Documentation/devicetree/bindings/ufs/ufs-qcom.txt >>> index 070baf4..b6b5130 100644 >>> --- a/Documentation/devicetree/bindings/ufs/ufs-qcom.txt >>> +++ b/Documentation/devicetree/bindings/ufs/ufs-qcom.txt >>> @@ -7,8 +7,11 @@ 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-phy-qmp-20nm" >>> - or "qcom,ufs-phy-qmp-14nm" according to the >>> relevant >>> phy in use. >>> +- compatible : compatible list, contains one of the following >>> - >>> + "qcom,ufs-phy-qmp-20nm" for 20nm ufs phy, >>> + "qcom,ufs-phy-qmp-14nm" for legacy 14nm ufs >>> phy, >>> + "qcom,msm8996-ufs-phy-qmp-14nm" for 14nm ufs >>> phy >>> + present on MSM8996 chipset. >> >> For future chipsets (after MSM8996), we have to use this same >> compatible >> strings? If yes, "msm8996" in compatible string name may cause >> confusions? >> may be we should start following v1/v2/... terminologies for this? >> something like "qcom,ufs-phy-qmp-v2" to start with? > > Are we trying to complement the actual IP hardware versioning with this > ? > Isn't it possible that we will end up using v2 for more than a couple > of > actual IP hardware versions ? > > I have seen cases wherein the IP versions are preceded by the > SOC names, the IPs appeared first in. And if the same IP is used in > subsequent SOCs, we use same compatible string. This, rather, > makes things easier to comprehend - it's the same IP that was > used on older SoC. Ok, if this is the standard practice across the board then we should be fine with this. You may add my Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org> > > I am fine with adding versions to the compatible string as well. > But like i asked earlier - are we just creating versions for our > own understanding, or are we also complementing the actual > IP hardware versions ? > > > Thanks > Vivek
diff --git a/Documentation/devicetree/bindings/ufs/ufs-qcom.txt b/Documentation/devicetree/bindings/ufs/ufs-qcom.txt index 070baf4..b6b5130 100644 --- a/Documentation/devicetree/bindings/ufs/ufs-qcom.txt +++ b/Documentation/devicetree/bindings/ufs/ufs-qcom.txt @@ -7,8 +7,11 @@ 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-phy-qmp-20nm" - or "qcom,ufs-phy-qmp-14nm" according to the relevant phy in use. +- compatible : compatible list, contains one of the following - + "qcom,ufs-phy-qmp-20nm" for 20nm ufs phy, + "qcom,ufs-phy-qmp-14nm" for legacy 14nm ufs phy, + "qcom,msm8996-ufs-phy-qmp-14nm" for 14nm ufs phy + present on MSM8996 chipset. - reg : should contain PHY register address space (mandatory), - reg-names : indicates various resources passed to driver (via reg proptery) by name. Required "reg-names" is "phy_mem". diff --git a/drivers/phy/phy-qcom-ufs-qmp-14nm.c b/drivers/phy/phy-qcom-ufs-qmp-14nm.c index e3bede7..b3d2612 100644 --- a/drivers/phy/phy-qcom-ufs-qmp-14nm.c +++ b/drivers/phy/phy-qcom-ufs-qmp-14nm.c @@ -180,6 +180,7 @@ static int ufs_qcom_phy_qmp_14nm_remove(struct platform_device *pdev) static const struct of_device_id ufs_qcom_phy_qmp_14nm_of_match[] = { {.compatible = "qcom,ufs-phy-qmp-14nm"}, + {.compatible = "qcom,msm8996-ufs-phy-qmp-14nm"}, {}, }; MODULE_DEVICE_TABLE(of, ufs_qcom_phy_qmp_14nm_of_match);
Add a new compatible string for 14nm ufs phy present on msm8996 chipset. This phy is bit different from the legacy 14nm ufs phy in terms of the clocks that are needed to be handled in the driver. Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org> --- New patch in v3 of this cleanup series. Documentation/devicetree/bindings/ufs/ufs-qcom.txt | 7 +++++-- drivers/phy/phy-qcom-ufs-qmp-14nm.c | 1 + 2 files changed, 6 insertions(+), 2 deletions(-)