Re: [PATCHv5 RFC 12/15] hwspinlock/core: add OF helper to parse reserved locks
On Mon, May 05, 2014 at 04:44:25PM -0500, Suman Anna wrote: Hi Rob, On 04/30/2014 07:34 PM, Suman Anna wrote: The property 'hwlock-reserved-locks' will be used to represent the number of locks to be reserved for clients that would need to request/operate on specific locks. A new OF helper function, of_hwspin_lock_get_num_reserved_locks(), is added to minimize duplication in different platform implementations. The function will return a value of 0 if the property is not defined, so as to support a default behavior of marking all locks as unused and open for anonymous allocations. Signed-off-by: Suman Anna s-a...@ti.com --- .../devicetree/bindings/hwlock/hwlock.txt | 3 +++ drivers/hwspinlock/hwspinlock_core.c | 25 ++ include/linux/hwspinlock.h | 1 + 3 files changed, 29 insertions(+) diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt index d538a9b..88d16d2 100644 --- a/Documentation/devicetree/bindings/hwlock/hwlock.txt +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt @@ -18,6 +18,9 @@ Common properties: property is needed on hwlock devices, where the number of supported locks within a hwlock device cannot be read from a register. +- hwlock-reserved-locks: Number of locks to reserve for clients requiring + specific locks. This value cannot exceed the value of + hwlock-num-locks. Any suggestions here on the approach? This property falls into a gray area as well, as the current approach is somewhat limiting (it doesn't support sparse reserved locks, and expects them at the beginning of the lock range). Is it possible to implement a pinctrl-like hogging approach, whereby the specific locks that need to be reserved are consumed by the controller itself? Josh -- 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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 4/7] hwspinlock/core: add common OF helpers
On Fri, Mar 14, 2014 at 03:12:26PM +0200, Ohad Ben-Cohen wrote: On Sun, Mar 2, 2014 at 10:19 PM, Bjorn Andersson bj...@kryo.se wrote: When introducing the ability to reference a hwspin lock via a phandle in device tree it makes a big difference to be able to differ between the case of initialization failed or device not yet probed; so that the client knows if it should fail or retry later. I'm not convinced. The only advantage this brings is to avoid retrying in case a fatal error has occurred. Such fatal errors are extremely rare, and when they show up - extremely painful, and I suspect that optimizing them wouldn't be a big win. So, are you suggesting that because fatal errors should be extremely rare, a consuming driver should just assume that if NULL is returned from a hwspin_lock_request*() function that it was the device not yet probed case that was hit? Note that having the consumer/hwspinlock device relationship modeled in devicetree introduces more potential failure cases... -- 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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 4/7] hwspinlock/core: add common OF helpers
On Tue, Mar 04, 2014 at 11:38:23AM -0600, Suman Anna wrote: Hi Ohad, On 03/02/2014 02:19 PM, Bjorn Andersson wrote: On Sat, Mar 1, 2014 at 9:14 PM, Ohad Ben-Cohen o...@wizery.com wrote: On Mon, Feb 10, 2014 at 9:14 PM, Suman Anna s-a...@ti.com wrote: On 02/07/2014 04:49 PM, Bjorn Andersson wrote: Ohad, Do you have any objections to the return code convention change? Unless strictly needed, I prefer we don't switch to the ERR_PTR code convention, as it reduces code readability and increases chances of user bugs. In our case, switching to ERR_PTR and friends seems only to optimize a few error paths, and I'm not sure it's a big win over simplicity. When introducing the ability to reference a hwspin lock via a phandle in device tree it makes a big difference to be able to differ between the case of initialization failed or device not yet probed; so that the client knows if it should fail or retry later. Can you confirm the changes you want me to make, so that I can refresh and post a v5 for 3.15? What's the status on this? I'm assuming this is going to miss 3.15? Having DT support in the core will be useful to move the Qualcomm hwspinlock driver forward as well. -- 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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/3] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core
On Wed, Aug 14, 2013 at 03:59:42PM +0300, Ivan T. Ivanov wrote:
From: Ivan T. Ivanov iiva...@mm-sol.com
These drivers handles control and configuration of the HS
and SS USB PHY transceivers. They are part of the driver
which manage Synopsys DesignWare USB3 controller stack
inside Qualcomm SoC's.
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
---
[..]
diff --git a/drivers/usb/phy/phy-msm-dwc3-hs.c
b/drivers/usb/phy/phy-msm-dwc3-hs.c
new file mode 100644
index 000..465a8f5
--- /dev/null
+++ b/drivers/usb/phy/phy-msm-dwc3-hs.c
[..]
+
+struct msm_dwc3_hs_phy {
+ struct usb_phy phy;
+ void __iomem*base;
+ struct device *dev;
+
+ struct clk *xo_clk;
+ struct clk *sleep_a_clk;
+
+ struct regulator*v3p3;
+ struct regulator*v1p8;
+ struct regulator*vddcx;
+ struct regulator*vbus;
+};
+
+#define phy_to_dwc3_phy(x) container_of((x), struct
msm_dwc3_hs_phy, phy)
+
+
+/**
+ *
+ * Write register with debug info.
what debug info?
+ *
+ * @base - DWC3 base virtual address.
+ * @offset - register offset.
+ * @val - value to write.
+ *
+ */
+static inline void msm_dwc3_hs_write(void *base, u32 offset, u32 val)
You've dropped __iomem here; have you run through sparse?
+{
+ iowrite32(val, base + offset);
+}
+
+/**
+ * Write register and read back masked value to confirm it is written
+ *
+ * @base - DWC3 base virtual address.
+ * @offset - register offset.
+ * @mask - register bitmask specifying what should be updated
+ * @val - value to write.
+ *
+ */
+static inline void msm_dwc3_hs_write_readback(void *base, u32 offset,
+ const u32 mask, u32 val)
+{
Same comment here.
--
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-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
