path: root/drivers/ssbi
diff options
authorDavid Brown <davidb@codeaurora.org>2013-03-12 11:41:51 -0700
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2013-03-25 10:39:40 -0700
commit3f7a73b57c2f57aa25342ebdb7312f78c68502eb (patch)
tree068b9fcf5ffe224ab011c633cf83219282497c72 /drivers/ssbi
parent97f00f7120fe3396302693cdc4b1d11bbacad963 (diff)
ssbi: Comment the use of udelay()
The ssbi driver uses a busywait loop to read its status register. Add a comment explaining the timing of the device itself so that future developers can better understand this delay, and possibly diagnose any problems. Signed-off-by: David Brown <davidb@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'drivers/ssbi')
1 files changed, 13 insertions, 0 deletions
diff --git a/drivers/ssbi/ssbi.c b/drivers/ssbi/ssbi.c
index 6fbcb25907f..7ae892590c7 100644
--- a/drivers/ssbi/ssbi.c
+++ b/drivers/ssbi/ssbi.c
@@ -87,6 +87,15 @@ static inline void ssbi_writel(struct msm_ssbi *ssbi, u32 val, u32 reg)
writel(val, ssbi->base + reg);
+ * Via private exchange with one of the original authors, the hardware
+ * should generally finish a transaction in about 5us. The worst
+ * case, is when using the arbiter and both other CPUs have just
+ * started trying to use the SSBI bus will result in a time of about
+ * 20us. It should never take longer than this.
+ *
+ * As such, this wait merely spins, with a udelay.
+ */
static int ssbi_wait_mask(struct msm_ssbi *ssbi, u32 set_mask, u32 clr_mask)
u32 timeout = SSBI_TIMEOUT_US;
@@ -161,6 +170,10 @@ err:
return ret;
+ * See ssbi_wait_mask for an explanation of the time and the
+ * busywait.
+ */
static inline int
msm_ssbi_pa_transfer(struct msm_ssbi *ssbi, u32 cmd, u8 *data)