Thread (7 messages) 7 messages, 2 authors, 2015-10-25

Re: [PATCH v3 6/8] scsi: ufs: make the UFS variant a platform device

From: <hidden>
Date: 2015-08-30 08:43:55
Also in: linux-arm-msm, linux-scsi, lkml

On Sun, Aug 23, 2015 at 8:09 AM, Yaniv Gardi [off-list ref]
wrote:
quoted
This change turns the UFS variant (SCSI_UFS_QCOM) into a UFS
a platform device.
In order to do so a few additional changes are required:
1. The ufshcd-pltfrm is no longer serves as a platform device.
   Now it only serves as a group of platform APIs such as PM APIs
   (runtime suspend/resume, system suspend/resume etc), parsers of
   clocks, regulators and pm_levels from DT.
2. What used to be the old platform "probe" is now "only"
   a pltfrm_init() routine, that does exactly the same, but only
   being called by the new probe function of the UFS variant.

Signed-off-by: Yaniv Gardi <redacted>

---
 .../devicetree/bindings/ufs/ufshcd-pltfrm.txt      |  2 +-
 drivers/scsi/ufs/ufs-qcom.c                        | 78
+++++++++++++++++-
 drivers/scsi/ufs/ufshcd-pltfrm.c                   | 92
++++++----------------
 drivers/scsi/ufs/ufshcd-pltfrm.h                   | 41 ++++++++++
 drivers/scsi/ufs/ufshcd.c                          | 10 +++
 drivers/scsi/ufs/ufshcd.h                          |  1 +
 6 files changed, 152 insertions(+), 72 deletions(-)
 create mode 100644 drivers/scsi/ufs/ufshcd-pltfrm.h
diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
index 5357919..b39e765 100644
--- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
+++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
@@ -4,7 +4,7 @@ UFSHC nodes are defined to describe on-chip UFS host
controllers.
 Each UFS controller instance should have its own node.

 Required properties:
-- compatible        : compatible list, contains "jedec,ufs-1.1"
+- compatible        : compatible list, contains "jedec,ufs-1.1" or
"qcom,ufshc"
Replying again as I inadvertently dropped everyone.

This should also have a more specific compatible string with the SOC
name/number in it. It may be "the same in all SOCs", but there is
always the possibility for bugs/limitations to be found that are
specific to an SOC even if all RTL versions are identical (e.g.
different max clock speeds). It is about making the dtb future proof,
not about what exactly you need today. You can keep qcom,ufshc for
driver matching if you want.
I see your point.
I just would like to make sure, syntactically speaking, if what you mean
should look like:

compatible        : compatible list, contains "jedec,ufs-1.1" or
                    "qcom,ufshc" for msm8994, msm8996 SOCs.


quoted
 - interrupts        : <interrupt mapping for UFS host controller IRQ>
 - reg               : <registers mapping>
What about phy properties? No Unipro PHY block that requires setup?
yes, i will add another documentation file for it.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help