Re: [PATCH v6 2/3] mfd: qcom-rpm: Driver for the Qualcomm RPM
On Mon, 25 Aug 2014, Bjorn Andersson wrote: Driver for the Resource Power Manager (RPM) found in Qualcomm 8660, 8960 and 8064 based devices. The driver exposes resources that child drivers can operate on; to implementing regulator, clock and bus frequency drivers. Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com --- drivers/mfd/Kconfig | 14 + drivers/mfd/Makefile |1 + drivers/mfd/qcom_rpm.c | 580 ++ include/linux/mfd/qcom_rpm.h | 10 + 4 files changed, 605 insertions(+) create mode 100644 drivers/mfd/qcom_rpm.c create mode 100644 include/linux/mfd/qcom_rpm.h I'd like to take this in with the other MFD patch. Is the regulator one okay to go in on it's own? Acked-by: Lee Jones lee.jo...@linaro.org -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 4/4] clk: Use ww_mutexes for clk_prepare_{lock/unlock}
Hi Stephen,
On Wednesday, September 3, 2014 9:01pm, Stephen Boyd sb...@codeaurora.org
said:
Changing the rate of a slow clock can take 10s of milliseconds
while changing the rate of a fast clock can be done in a few
snip
-static void clk_prepare_lock(void)
+static void __clk_unlock(struct list_head *list)
+{
+ struct clk *entry, *temp;
+
+ list_for_each_entry_safe (entry, temp, list, ww_list) {
Checkpatch warning for above line,
WARNING: space prohibited between function name and open parenthesis '('
+ list_del_init(entry-ww_list);
+ ww_mutex_unlock(entry-lock);
+ }
+}
+
+static void clk_unlock(struct list_head *list, struct ww_acquire_ctx *ctx)
+{
snip
+ ww_acquire_init(ctx, prepare_ww_class);
+ do {
+ ret = __clk_prepare_lock(clk, list, ctx);
+ } while (ret == -EDEADLK);
+ ww_acquire_done(ctx);
+}
+
+static int __clk_unprepare_lock(struct clk *clk, struct list_head *list,
+ struct ww_acquire_ctx *ctx)
Checkpatch error for above line,
ERROR: code indent should use tabs where possible
Best Regards,
Kiran Padwal
+{
+ int ret;
+
+ do {
+ ret = clk_lock_one(clk, list, ctx);
+ if (ret == -EDEADLK)
+ return ret;
+
+ if (clk-prepare_count 1)
+ break;
+ } while ((clk = clk-parent));
+
+ return 0;
+}
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: sdhci-msm: Make tuning block table endian agnostic
On 4 September 2014 07:06, Jaehoon Chung jh80.ch...@samsung.com wrote:
Hi, Stephen.
On 09/03/2014 10:57 PM, Stephen Boyd wrote:
If we're tuning on a big-endian CPU we'll never determine we properly
tuned the device because we compare the data we received from the
controller with a table that assumes the CPU is little-endian.
Change the table to be an array of bytes instead of 32-bit words
so we can use memcmp() without needing to byte-swap every word
depending on the endianess of the CPU.
Cc: Asutosh Das asuto...@codeaurora.org
Cc: Venkat Gopalakrishnan venk...@codeaurora.org
Reviewed-by: Georgi Djakov gdja...@mm-sol.com
Fixes: 415b5a75da43 mmc: sdhci-msm: Add platform_execute_tuning
implementation
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
drivers/mmc/host/sdhci-msm.c | 42 +++---
1 file changed, 27 insertions(+), 15 deletions(-)
diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 40573a58486a..5aabffc15ae8 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -47,22 +47,34 @@
#define CMUX_SHIFT_PHASE_SHIFT 24
#define CMUX_SHIFT_PHASE_MASK(7 CMUX_SHIFT_PHASE_SHIFT)
-static const u32 tuning_block_64[] = {
- 0x00ff0fff, 0xccc3ccff, 0xffcc3cc3, 0xeffefffe,
- 0xddffdfff, 0xfbfffbff, 0xff7fffbf, 0xefbdf777,
- 0xf0fff0ff, 0x3cccfc0f, 0xcfcc33cc, 0xeeffefff,
- 0xfdfffdff, 0xffbfffdf, 0xfff7ffbb, 0xde7b7ff7
+static const u8 tuning_block_64[] = {
+ 0xff, 0x0f, 0xff, 0x00, 0xff, 0xcc, 0xc3, 0xcc,
+ 0xc3, 0x3c, 0xcc, 0xff, 0xfe, 0xff, 0xfe, 0xef,
+ 0xff, 0xdf, 0xff, 0xdd, 0xff, 0xfb, 0xff, 0xfb,
+ 0xbf, 0xff, 0x7f, 0xff, 0x77, 0xf7, 0xbd, 0xef,
+ 0xff, 0xf0, 0xff, 0xf0, 0x0f, 0xfc, 0xcc, 0x3c,
+ 0xcc, 0x33, 0xcc, 0xcf, 0xff, 0xef, 0xff, 0xee,
+ 0xff, 0xfd, 0xff, 0xfd, 0xdf, 0xff, 0xbf, 0xff,
+ 0xbb, 0xff, 0xf7, 0xff, 0xf7, 0x7f, 0x7b, 0xde,
};
-static const u32 tuning_block_128[] = {
- 0xff00, 0x, 0x, 0x33cc,
- 0xcccc, 0x, 0xeeff, 0xffff,
- 0xffdd, 0x, 0xbbff, 0xbbff,
- 0xffbb, 0xff77, 0x77ff, 0xffeeddbb,
- 0x00ff, 0x00ff, 0xcc00, 0xcc33,
- 0x, 0xffcc, 0xffee, 0x,
- 0xddff, 0xddff, 0xffdd, 0xffbb,
- 0x, 0x77ff, 0xffff, 0xeeddbb77
+static const u8 tuning_block_128[] = {
+ 0xff, 0xff, 0x00, 0xff, 0xff, 0xff, 0x00, 0x00,
+ 0xff, 0xff, 0xcc, 0xcc, 0xcc, 0x33, 0xcc, 0xcc,
+ 0xcc, 0x33, 0x33, 0xcc, 0xcc, 0xcc, 0xff, 0xff,
+ 0xff, 0xee, 0xff, 0xff, 0xff, 0xee, 0xee, 0xff,
+ 0xff, 0xff, 0xdd, 0xff, 0xff, 0xff, 0xdd, 0xdd,
+ 0xff, 0xff, 0xff, 0xbb, 0xff, 0xff, 0xff, 0xbb,
+ 0xbb, 0xff, 0xff, 0xff, 0x77, 0xff, 0xff, 0xff,
+ 0x77, 0x77, 0xff, 0x77, 0xbb, 0xdd, 0xee, 0xff,
+ 0xff, 0xff, 0xff, 0x00, 0xff, 0xff, 0xff, 0x00,
+ 0x00, 0xff, 0xff, 0xcc, 0xcc, 0xcc, 0x33, 0xcc,
+ 0xcc, 0xcc, 0x33, 0x33, 0xcc, 0xcc, 0xcc, 0xff,
+ 0xff, 0xff, 0xee, 0xff, 0xff, 0xff, 0xee, 0xee,
+ 0xff, 0xff, 0xff, 0xdd, 0xff, 0xff, 0xff, 0xdd,
+ 0xdd, 0xff, 0xff, 0xff, 0xbb, 0xff, 0xff, 0xff,
+ 0xbb, 0xbb, 0xff, 0xff, 0xff, 0x77, 0xff, 0xff,
+ 0xff, 0x77, 0x77, 0xff, 0x77, 0xbb, 0xdd, 0xee,
};
In dw-mmc.c, tuning_block values are same.
So I think we can move these value into generic header. how about?
Actually, I believe these values comes from the eMMC specification?
Shouldn't they be moved to the mmc core instead?
Kind regards
Uffe
Best Regards,
Jaehoon Chung
struct sdhci_msm_host {
@@ -359,7 +371,7 @@ static int sdhci_msm_execute_tuning(struct sdhci_host
*host, u32 opcode)
{
int tuning_seq_cnt = 3;
u8 phase, *data_buf, tuned_phases[16], tuned_phase_cnt = 0;
- const u32 *tuning_block_pattern = tuning_block_64;
+ const u8 *tuning_block_pattern = tuning_block_64;
int size = sizeof(tuning_block_64); /* Pattern size in bytes */
int rc;
struct mmc_host *mmc = host-mmc;
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Status of chipidea msm USB reset patch
On Fri, Aug 15, 2014 at 12:08 AM, Ivan T. Ivanov iiva...@mm-sol.com wrote:
On Fri, 2014-08-15 at 08:23 +0800, Peter Chen wrote:
On Thu, Aug 14, 2014 at 11:54:02AM -0500, Felipe Balbi wrote:
Hi,
On Thu, Aug 14, 2014 at 09:53:10AM -0700, Tim Bird wrote:
Ping. Anybody know the status of this patch? Is it queued in someone's
tree?
Without it the USB driver for the Qualcomm 8974 (hsusb phy) doesn't
work (at least for me).
It looks like it got dropped from Ivan's original patch series, back in
May.
I don't maintain chipidea, Peter's the guy you want
Below patch was not at msm chipidea patchset Ivan sent me.
http://markmail.org/search/?q=%5BPATCH+v4+0%2F3%5D+usb%3A+chipidea%3A+msm%3A+Clean+and+fix+#query:%5BPATCH%20v4%200%2F3%5D%20usb%3A%20chipidea%3A%20msm%3A%20Clean%20and%20fix%20from%3A%22Ivan%20T.%20Ivanov%22+page:1+mid:mt7hgr7yamyzegg3+state:results
My fault. I have waiting PHY patches to be accepted to send this one.
Will rebase and resend.
Peter,
There appears to be no progress on this.
Can we just add the existing patch, get it into Linus' tree asap as
a bugfix (preferably in this RC cycle)? Then ask Ivan to rebase his
patches on top of this, instead of rebasing this patch as part of a
larger effort with an unclear delivery date?
Note that without this patch, the driver in mainline doesn't work at all,
so adding it couldn't possibly make mainline worse.
IMHO this should be CC:'ed to stable for the 3.16 kernel as well. No
other files are affected, and it applies and builds on 3.16 without problems.
Please let me know.
-- Tim Bird
Senior Software Engineer, Sony Mobile
Architecture Group Chair, CE Workgroup, Linux Foundation
Patch follows for reference:
Subject: [PATCH] usb: chipidea: msm: Use USB PHY API to control PHY state
PHY drivers keep track of the current state of the hardware,
so don't change PHY settings under it.
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
---
drivers/usb/chipidea/ci_hdrc_msm.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
b/drivers/usb/chipidea/ci_hdrc_msm.c
index d72b9d2..81de834 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -20,13 +20,11 @@
static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
{
struct device *dev = ci-gadget.dev.parent;
- int val;
switch (event) {
case CI_HDRC_CONTROLLER_RESET_EVENT:
dev_dbg(dev, CI_HDRC_CONTROLLER_RESET_EVENT received\n);
- writel(0, USB_AHBBURST);
- writel(0, USB_AHBMODE);
+ usb_phy_init(ci-transceiver);
break;
case CI_HDRC_CONTROLLER_STOPPED_EVENT:
dev_dbg(dev, CI_HDRC_CONTROLLER_STOPPED_EVENT received\n);
@@ -34,10 +32,7 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc
*ci, unsigned event)
* Put the transceiver in non-driving mode. Otherwise host
* may not detect soft-disconnection.
*/
- val = usb_phy_io_read(ci-transceiver, ULPI_FUNC_CTRL);
- val = ~ULPI_FUNC_CTRL_OPMODE_MASK;
- val |= ULPI_FUNC_CTRL_OPMODE_NONDRIVING;
- usb_phy_io_write(ci-transceiver, val, ULPI_FUNC_CTRL);
+ usb_phy_notify_disconnect(ci-transceiver, USB_SPEED_UNKNOWN);
break;
default:
dev_dbg(dev, unknown ci_hdrc event\n);
--
1.8.2.2
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/4] pinctrl: qcom: Add APQ8084 pinctrl support
On Wed, Sep 3, 2014 at 6:28 PM, Georgi Djakov gdja...@mm-sol.com wrote: This patchset adds pinctrl support for the Qualcomm APQ8084 platform. Reviewed-by: Andy Gross agr...@codeaurora.org Acked-by: Bjorn Andersson bjorn.anders...@sonymobile.com Signed-off-by: Georgi Djakov gdja...@mm-sol.com Patch applied, after taking the liberty to copy the changelog into the commit message. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/4] dt: Document Qualcomm APQ8084 pinctrl binding
On Wed, Sep 3, 2014 at 6:28 PM, Georgi Djakov gdja...@mm-sol.com wrote: Define a new binding for the Qualcomm TLMM (Top-Level Mode Mux) based pin controller inside the APQ8084. Acked-by: Bjorn Andersson bjorn.anders...@sonymobile.com Signed-off-by: Georgi Djakov gdja...@mm-sol.com Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/4] pinctrl: qcom: Make the target processor value configurable
On Wed, Sep 3, 2014 at 6:28 PM, Georgi Djakov gdja...@mm-sol.com wrote: Currently the value used to specify that interrupts from the gpio should be routed to the application processor is hardcoded for all Qualcomm SoCs. But the new APQ8084 SoC uses a different value. To resolve this, we make this value configurable for each SoC. For all existing SoCs we continue to use the current value, and only for APQ8084 we use the new value. Suggested-by: Bjorn Andersson bjorn.anders...@sonymobile.com Acked-by: Bjorn Andersson bjorn.anders...@sonymobile.com Signed-off-by: Georgi Djakov gdja...@mm-sol.com Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] clk: qcom: Consolidate frequency finding logic
There are two find_freq() functions in clk-rcg.c and clk-rcg2.c
that are almost exactly the same. Consolidate them into one
function to save on some code space.
Cc: Mike Turquette mturque...@linaro.org
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
I'll queue this for v3.18 if there are no objections.
drivers/clk/qcom/clk-rcg.c | 20
drivers/clk/qcom/clk-rcg2.c | 19 +++
drivers/clk/qcom/common.c | 16
drivers/clk/qcom/common.h | 4
4 files changed, 27 insertions(+), 32 deletions(-)
diff --git a/drivers/clk/qcom/clk-rcg.c b/drivers/clk/qcom/clk-rcg.c
index 59f118cc4c8b..710a869fc24c 100644
--- a/drivers/clk/qcom/clk-rcg.c
+++ b/drivers/clk/qcom/clk-rcg.c
@@ -21,6 +21,7 @@
#include asm/div64.h
#include clk-rcg.h
+#include common.h
static u32 ns_to_src(struct src_sel *s, u32 ns)
{
@@ -360,26 +361,13 @@ clk_dyn_rcg_recalc_rate(struct clk_hw *hw, unsigned long
parent_rate)
}
}
-static const
-struct freq_tbl *find_freq(const struct freq_tbl *f, unsigned long rate)
-{
- if (!f)
- return NULL;
-
- for (; f-freq; f++)
- if (rate = f-freq)
- return f;
-
- return NULL;
-}
-
static long _freq_tbl_determine_rate(struct clk_hw *hw,
const struct freq_tbl *f, unsigned long rate,
unsigned long *p_rate, struct clk_core **p)
{
unsigned long clk_flags;
- f = find_freq(f, rate);
+ f = qcom_find_freq(f, rate);
if (!f)
return -EINVAL;
@@ -477,7 +465,7 @@ static int clk_rcg_set_rate(struct clk_hw *hw, unsigned
long rate,
struct clk_rcg *rcg = to_clk_rcg(hw);
const struct freq_tbl *f;
- f = find_freq(rcg-freq_tbl, rate);
+ f = qcom_find_freq(rcg-freq_tbl, rate);
if (!f)
return -EINVAL;
@@ -497,7 +485,7 @@ static int __clk_dyn_rcg_set_rate(struct clk_hw *hw,
unsigned long rate)
struct clk_dyn_rcg *rcg = to_clk_dyn_rcg(hw);
const struct freq_tbl *f;
- f = find_freq(rcg-freq_tbl, rate);
+ f = qcom_find_freq(rcg-freq_tbl, rate);
if (!f)
return -EINVAL;
diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
index 6aac1ec0777c..0d2759b814ff 100644
--- a/drivers/clk/qcom/clk-rcg2.c
+++ b/drivers/clk/qcom/clk-rcg2.c
@@ -24,6 +24,7 @@
#include asm/div64.h
#include clk-rcg.h
+#include common.h
#define CMD_REG0x0
#define CMD_UPDATE BIT(0)
@@ -172,27 +173,13 @@ clk_rcg2_recalc_rate(struct clk_hw *hw, unsigned long
parent_rate)
return calc_rate(parent_rate, m, n, mode, hid_div);
}
-static const
-struct freq_tbl *find_freq(const struct freq_tbl *f, unsigned long rate)
-{
- if (!f)
- return NULL;
-
- for (; f-freq; f++)
- if (rate = f-freq)
- return f;
-
- /* Default to our fastest rate */
- return f - 1;
-}
-
static long _freq_tbl_determine_rate(struct clk_hw *hw,
const struct freq_tbl *f, unsigned long rate,
unsigned long *p_rate, struct clk_core **p)
{
unsigned long clk_flags;
- f = find_freq(f, rate);
+ f = qcom_find_freq(f, rate);
if (!f)
return -EINVAL;
@@ -268,7 +255,7 @@ static int __clk_rcg2_set_rate(struct clk_hw *hw, unsigned
long rate)
struct clk_rcg2 *rcg = to_clk_rcg2(hw);
const struct freq_tbl *f;
- f = find_freq(rcg-freq_tbl, rate);
+ f = qcom_find_freq(rcg-freq_tbl, rate);
if (!f)
return -EINVAL;
diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c
index afd40ea50887..dd8335b8522b 100644
--- a/drivers/clk/qcom/common.c
+++ b/drivers/clk/qcom/common.c
@@ -18,6 +18,7 @@
#include linux/reset-controller.h
#include common.h
+#include clk-rcg.h
#include clk-regmap.h
#include reset.h
@@ -27,6 +28,21 @@ struct qcom_cc {
struct clk_core *clks[];
};
+const
+struct freq_tbl *qcom_find_freq(const struct freq_tbl *f, unsigned long rate)
+{
+ if (!f)
+ return NULL;
+
+ for (; f-freq; f++)
+ if (rate = f-freq)
+ return f;
+
+ /* Default to our fastest rate */
+ return f - 1;
+}
+EXPORT_SYMBOL_GPL(qcom_find_freq);
+
struct regmap *
qcom_cc_map(struct platform_device *pdev, const struct qcom_cc_desc *desc)
{
diff --git a/drivers/clk/qcom/common.h b/drivers/clk/qcom/common.h
index 2765e9d3da97..f519322acdf3 100644
--- a/drivers/clk/qcom/common.h
+++ b/drivers/clk/qcom/common.h
@@ -18,6 +18,7 @@ struct regmap_config;
struct clk_regmap;
struct qcom_reset_map;
struct regmap;
+struct freq_tbl;
struct qcom_cc_desc {
const struct regmap_config *config;
@@ -27,6 +28,9 @@ struct qcom_cc_desc {
size_t num_resets;
};
+extern const struct freq_tbl *qcom_find_freq(const struct freq_tbl *f,
+
Re: [PATCH] mmc: sdhci-msm: Make tuning block table endian agnostic
On 09/04/14 03:53, Ulf Hansson wrote: On 4 September 2014 07:06, Jaehoon Chung jh80.ch...@samsung.com wrote: In dw-mmc.c, tuning_block values are same. So I think we can move these value into generic header. how about? Actually, I believe these values comes from the eMMC specification? Shouldn't they be moved to the mmc core instead? That sounds like good consolidation, but can we do that in a follow-up patch? This fixes the driver for me and I was hoping to make something minimal to go back to stable trees. -- 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-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: sdhci-msm: Make tuning block table endian agnostic
On 09/05/2014 06:22 AM, Stephen Boyd wrote: On 09/04/14 03:53, Ulf Hansson wrote: On 4 September 2014 07:06, Jaehoon Chung jh80.ch...@samsung.com wrote: In dw-mmc.c, tuning_block values are same. So I think we can move these value into generic header. how about? Actually, I believe these values comes from the eMMC specification? Shouldn't they be moved to the mmc core instead? That sounds like good consolidation, but can we do that in a follow-up patch? This fixes the driver for me and I was hoping to make something minimal to go back to stable trees. Sure, if my opinion is ok, i will do it after apply your patches. Best Regards, Jaehoon Chung -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: sdhci-msm: Make tuning block table endian agnostic
On 09/05, Jaehoon Chung wrote:
On 09/05/2014 06:22 AM, Stephen Boyd wrote:
On 09/04/14 03:53, Ulf Hansson wrote:
On 4 September 2014 07:06, Jaehoon Chung jh80.ch...@samsung.com wrote:
In dw-mmc.c, tuning_block values are same.
So I think we can move these value into generic header. how about?
Actually, I believe these values comes from the eMMC specification?
Shouldn't they be moved to the mmc core instead?
That sounds like good consolidation, but can we do that in a follow-up
patch? This fixes the driver for me and I was hoping to make something
minimal to go back to stable trees.
Sure, if my opinion is ok, i will do it after apply your patches.
Here's the patch
8
From: Stephen Boyd sb...@codeaurora.org
Subject: [PATCH] mmc: Consolidate emmc tuning blocks
The same tuning block array exists in the dw_mmc h.c and sdhci-msm.c
files. Move these into mmc.c so that they can be shared across
drivers.
Reported-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
drivers/mmc/core/mmc.c | 32
drivers/mmc/host/dw_mmc.c| 30 --
drivers/mmc/host/sdhci-msm.c | 38 --
include/linux/mmc/mmc.h | 5 +
4 files changed, 41 insertions(+), 64 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 793c6f7ddb04..9608cc8a1f65 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1135,6 +1135,38 @@ bus_speed:
return err;
}
+const u8 tuning_blk_pattern_4bit[MMC_TUNING_BLK_PATTERN_4BIT_SIZE] = {
+ 0xff, 0x0f, 0xff, 0x00, 0xff, 0xcc, 0xc3, 0xcc,
+ 0xc3, 0x3c, 0xcc, 0xff, 0xfe, 0xff, 0xfe, 0xef,
+ 0xff, 0xdf, 0xff, 0xdd, 0xff, 0xfb, 0xff, 0xfb,
+ 0xbf, 0xff, 0x7f, 0xff, 0x77, 0xf7, 0xbd, 0xef,
+ 0xff, 0xf0, 0xff, 0xf0, 0x0f, 0xfc, 0xcc, 0x3c,
+ 0xcc, 0x33, 0xcc, 0xcf, 0xff, 0xef, 0xff, 0xee,
+ 0xff, 0xfd, 0xff, 0xfd, 0xdf, 0xff, 0xbf, 0xff,
+ 0xbb, 0xff, 0xf7, 0xff, 0xf7, 0x7f, 0x7b, 0xde,
+};
+EXPORT_SYMBOL(tuning_blk_pattern_4bit);
+
+const u8 tuning_blk_pattern_8bit[MMC_TUNING_BLK_PATTERN_8BIT_SIZE] = {
+ 0xff, 0xff, 0x00, 0xff, 0xff, 0xff, 0x00, 0x00,
+ 0xff, 0xff, 0xcc, 0xcc, 0xcc, 0x33, 0xcc, 0xcc,
+ 0xcc, 0x33, 0x33, 0xcc, 0xcc, 0xcc, 0xff, 0xff,
+ 0xff, 0xee, 0xff, 0xff, 0xff, 0xee, 0xee, 0xff,
+ 0xff, 0xff, 0xdd, 0xff, 0xff, 0xff, 0xdd, 0xdd,
+ 0xff, 0xff, 0xff, 0xbb, 0xff, 0xff, 0xff, 0xbb,
+ 0xbb, 0xff, 0xff, 0xff, 0x77, 0xff, 0xff, 0xff,
+ 0x77, 0x77, 0xff, 0x77, 0xbb, 0xdd, 0xee, 0xff,
+ 0xff, 0xff, 0xff, 0x00, 0xff, 0xff, 0xff, 0x00,
+ 0x00, 0xff, 0xff, 0xcc, 0xcc, 0xcc, 0x33, 0xcc,
+ 0xcc, 0xcc, 0x33, 0x33, 0xcc, 0xcc, 0xcc, 0xff,
+ 0xff, 0xff, 0xee, 0xff, 0xff, 0xff, 0xee, 0xee,
+ 0xff, 0xff, 0xff, 0xdd, 0xff, 0xff, 0xff, 0xdd,
+ 0xdd, 0xff, 0xff, 0xff, 0xbb, 0xff, 0xff, 0xff,
+ 0xbb, 0xbb, 0xff, 0xff, 0xff, 0x77, 0xff, 0xff,
+ 0xff, 0x77, 0x77, 0xff, 0x77, 0xbb, 0xdd, 0xee,
+};
+EXPORT_SYMBOL(tuning_blk_pattern_8bit);
+
/*
* Execute tuning sequence to seek the proper bus operating
* conditions for HS200 and HS400, which sends CMD21 to the device.
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 1ac227c603b7..f1cefdf5e2d0 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -81,36 +81,6 @@ struct idmac_desc {
};
#endif /* CONFIG_MMC_DW_IDMAC */
-static const u8 tuning_blk_pattern_4bit[] = {
- 0xff, 0x0f, 0xff, 0x00, 0xff, 0xcc, 0xc3, 0xcc,
- 0xc3, 0x3c, 0xcc, 0xff, 0xfe, 0xff, 0xfe, 0xef,
- 0xff, 0xdf, 0xff, 0xdd, 0xff, 0xfb, 0xff, 0xfb,
- 0xbf, 0xff, 0x7f, 0xff, 0x77, 0xf7, 0xbd, 0xef,
- 0xff, 0xf0, 0xff, 0xf0, 0x0f, 0xfc, 0xcc, 0x3c,
- 0xcc, 0x33, 0xcc, 0xcf, 0xff, 0xef, 0xff, 0xee,
- 0xff, 0xfd, 0xff, 0xfd, 0xdf, 0xff, 0xbf, 0xff,
- 0xbb, 0xff, 0xf7, 0xff, 0xf7, 0x7f, 0x7b, 0xde,
-};
-
-static const u8 tuning_blk_pattern_8bit[] = {
- 0xff, 0xff, 0x00, 0xff, 0xff, 0xff, 0x00, 0x00,
- 0xff, 0xff, 0xcc, 0xcc, 0xcc, 0x33, 0xcc, 0xcc,
- 0xcc, 0x33, 0x33, 0xcc, 0xcc, 0xcc, 0xff, 0xff,
- 0xff, 0xee, 0xff, 0xff, 0xff, 0xee, 0xee, 0xff,
- 0xff, 0xff, 0xdd, 0xff, 0xff, 0xff, 0xdd, 0xdd,
- 0xff, 0xff, 0xff, 0xbb, 0xff, 0xff, 0xff, 0xbb,
- 0xbb, 0xff, 0xff, 0xff, 0x77, 0xff, 0xff, 0xff,
- 0x77, 0x77, 0xff, 0x77, 0xbb, 0xdd, 0xee, 0xff,
- 0xff, 0xff, 0xff, 0x00, 0xff, 0xff, 0xff, 0x00,
- 0x00, 0xff, 0xff, 0xcc, 0xcc, 0xcc, 0x33, 0xcc,
- 0xcc, 0xcc, 0x33, 0x33, 0xcc, 0xcc, 0xcc, 0xff,
- 0xff, 0xff, 0xee, 0xff, 0xff, 0xff, 0xee, 0xee,
- 0xff, 0xff, 0xff, 0xdd, 0xff, 0xff, 0xff, 0xdd,
- 0xdd, 0xff, 0xff, 0xff, 0xbb, 0xff, 0xff, 0xff,
- 0xbb, 0xbb, 0xff, 0xff, 0xff, 0x77, 0xff, 0xff,
- 0xff, 0x77, 0x77, 0xff, 0x77, 0xbb, 0xdd, 0xee,
-};
-
static
[PATCH v5 0/7] QCOM 8074 cpuidle driver
Changes since v4:
[ https://www.mail-archive.com/linux-arm-msm@vger.kernel.org/msg10327.html ]
- Update to the v8 of ARM generic idle states patches
- Use platform device model for cpuidle-qcom
- Clean up msm-pm.c to remove unnecessary include files and functions
- Update commit text and documentation for all idle states
- Remove scm-boot relocate patch from this series, submitted earlier
[ https://www.mail-archive.com/linux-arm-msm@vger.kernel.org/msg10518.html ]
Changes since v3:
[ https://www.mail-archive.com/linux-arm-msm@vger.kernel.org/msg10288.html ]
- Fix CONFIG_QCOM_PM Kconfig as bool
- More clean ups in spm.c and spm-devices.c
- Removed and re-organized data structures to make initialization simple
- Remove export of sequence flush functions
- Updated commit text
- Comments for use of barriers.
- Rebase on top of 3.17-rc1
Changes since v2:
[ https://www.mail-archive.com/linux-arm-msm@vger.kernel.org/msg10148.html ]
- Prune all the drivers to support basic WFI and power down cpuidle
functionality. Remove debug code.
- Integrate KConfig changes into the drivers' patches.
- Use Lorenzo's ARM idle-states patches as the basis for reading cpuidle
c-states from DT.
[ http://marc.info/?l=linux-pmm=140794514812383w=2 ]
- Incorporate review comments
- Rebase on top of 3.16
Changes since v1/RFC:
[ https://www.mail-archive.com/linux-arm-msm@vger.kernel.org/msg10065.html ]
- Remove hotplug from the patch series. Will submit it separately.
- Fix SPM drivers per the review comments
- Modify patch sequence to compile SPM drivers independent of msm-pm, so as to
allow wfi() calls to use SPM even without SoC interface driver.
8074 like any ARM SoC can do architectural clock gating, that helps save on
power, but not enough of leakage power. Leakage power of the SoC can be
further reduced by turning off power to the core. To aid this, every core (cpu
and L2) is accompanied by a Sub-system Power Manager (SPM), that can be
configured to indicate the low power mode, the core would be put into and the
SPM programs the peripheral h/w accordingly to enter low power and turn off the
power rail to the core.
The idle invocation hierarchy -
CPUIDLE
|
cpuidle-qcom.c [CPUIdle driver]
|
-- msm-pm.c [SoC Interface layer for QCOM chipsets]
|
-- spm-devices.c [SPM devices manager]
| |
| -- spm.c [SPM h/w driver]
|
-- scm-boot.c [SCM interface layer]
|
|--
(EL)Secure Monitor Code
|
|
wfi();
|--
(HW)[CPU] {clock gate}
|
- [SPM] {statemachine}
The patchset does the following -
- Add new Secure Monitor flags to support warmboot of a quad core system.
- Introduce the SPM driver to control power to the core. The SPM h/w IP works
in conjunction with the Krait CPU/L2. When the core executes WFI instruction,
the core is clockgated and the SPM state machine takes over and powers the core
down. An interrupt from GIC, resumes the SPM state machine which brings the cpu
out of the low power mode.
- Add a SPM device manager to configure multiple SPM devices.
- Add the device tree configuration for each of the SPM nodes. There is one for
each cpu. There is one for each cpu.
- Introduce the SoC driver interface layer to configure SPM per the core's idle
state. To power down the cpu core, the SPM h/w needs to be set up correctly
to power down the core, when the core executes WFI. Linux is expected to call
into Secure Monitor to power down the core. At reset, the core will start in
seure mode and will be returned back to Linux.
- Add CPUIDLE driver for QCOM cpus. The cpuidle driver uses the SoC interface
layer to configure the SPM to allow Krait to be powered down. The cpuidle driver
is based on ARM idle-state framework for cpuidle drivers.
- Provide device configuration for 8074 SoC. Current support is for WFI and
standalone power collapse, which powers only the core independent of the
other cores and caches.
Thanks,
Lina
Lina Iyer (7):
msm: scm: Add SCM warmboot flags for quad core targets.
qcom: spm: Add Subsystem Power Manager driver (SAW2)
qcom: spm-devices: Add SPM device manager for the SoC
arm: dts: qcom: Add SPM device bindings for 8974
qcom: msm-pm: Add cpu low power mode functions
qcom: cpuidle: Add cpuidle driver for QCOM cpus
arm: dts: qcom: Add idle states device nodes for 8974
.../bindings/arm/msm/qcom,idle-state.txt | 72
Documentation/devicetree/bindings/arm/msm/spm.txt | 47 +
arch/arm/boot/dts/qcom-msm8974-pm.dtsi | 69 +++
[PATCH v5 1/7] msm: scm: Add SCM warmboot flags for quad core targets.
Quad core targets like APQ8074, APQ8064, APQ8084 need SCM support set up warm boot addresses in the Secure Monitor. Extend the SCM flags to support warmboot addresses for secondary cores. Signed-off-by: Lina Iyer lina.i...@linaro.org --- include/soc/qcom/scm-boot.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/soc/qcom/scm-boot.h b/include/soc/qcom/scm-boot.h index 6aabb24..02b445c 100644 --- a/include/soc/qcom/scm-boot.h +++ b/include/soc/qcom/scm-boot.h @@ -18,6 +18,8 @@ #define SCM_FLAG_COLDBOOT_CPU3 0x20 #define SCM_FLAG_WARMBOOT_CPU0 0x04 #define SCM_FLAG_WARMBOOT_CPU1 0x02 +#define SCM_FLAG_WARMBOOT_CPU2 0x10 +#define SCM_FLAG_WARMBOOT_CPU3 0x40 int scm_set_boot_addr(phys_addr_t addr, int flags); -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 2/7] qcom: spm: Add Subsystem Power Manager driver (SAW2)
Based on work by many authors, available at codeaurora.org
SPM is a hardware block that controls the peripheral logic surrounding
the application cores (cpu/l$). When the core executes WFI instruction,
the SPM takes over the putting the core in low power state as
configured. The wake up for the SPM is an interrupt at the GIC, which
then completes the rest of low power mode sequence and brings the core
out of low power mode.
The SPM has a set of control registers that configure the SPMs
individually based on the type of the core and the runtime conditions.
SPM is a finite state machine block to which a sequence is provided and
it interprets the bytes and executes them in sequence. Each low power
mode that the core can enter into is provided to the SPM as a sequence.
Configure the SPM to set the core (cpu or L2) into its low power mode,
the index of the first command in the sequence is set in the SPM_CTL
register. When the core executes ARM wfi instruction, it triggers the
SPM state machine to start executing from that index. The SPM state
machine waits until the interrupt occurs and starts executing the rest
of the sequence until it hits the end of the sequence. The end of the
sequence jumps the core out of its low power mode.
Signed-off-by: Lina Iyer lina.i...@linaro.org
[lina: simplify the driver for initial submission, clean up and update
commit text]
---
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/spm-drv.h | 69
drivers/soc/qcom/spm.c | 192 +
3 files changed, 262 insertions(+)
create mode 100644 drivers/soc/qcom/spm-drv.h
create mode 100644 drivers/soc/qcom/spm.c
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 70d52ed..20b329f 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_QCOM_GSBI)+= qcom_gsbi.o
+obj-$(CONFIG_QCOM_PM) += spm.o
CFLAGS_scm.o :=$(call as-instr,.arch_extension sec,-DREQUIRES_SEC=1)
obj-$(CONFIG_QCOM_SCM) += scm.o scm-boot.o
diff --git a/drivers/soc/qcom/spm-drv.h b/drivers/soc/qcom/spm-drv.h
new file mode 100644
index 000..e91df44
--- /dev/null
+++ b/drivers/soc/qcom/spm-drv.h
@@ -0,0 +1,69 @@
+/* Copyright (c) 2011-2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#ifndef __QCOM_SPM_DRIVER_H
+#define __QCOM_SPM_DRIVER_H
+
+enum {
+ MSM_SPM_REG_SAW2_CFG,
+ MSM_SPM_REG_SAW2_AVS_CTL,
+ MSM_SPM_REG_SAW2_AVS_HYSTERESIS,
+ MSM_SPM_REG_SAW2_SPM_CTL,
+ MSM_SPM_REG_SAW2_PMIC_DLY,
+ MSM_SPM_REG_SAW2_AVS_LIMIT,
+ MSM_SPM_REG_SAW2_AVS_DLY,
+ MSM_SPM_REG_SAW2_SPM_DLY,
+ MSM_SPM_REG_SAW2_PMIC_DATA_0,
+ MSM_SPM_REG_SAW2_PMIC_DATA_1,
+ MSM_SPM_REG_SAW2_PMIC_DATA_2,
+ MSM_SPM_REG_SAW2_PMIC_DATA_3,
+ MSM_SPM_REG_SAW2_PMIC_DATA_4,
+ MSM_SPM_REG_SAW2_PMIC_DATA_5,
+ MSM_SPM_REG_SAW2_PMIC_DATA_6,
+ MSM_SPM_REG_SAW2_PMIC_DATA_7,
+ MSM_SPM_REG_SAW2_RST,
+
+ MSM_SPM_REG_NR_INITIALIZE = MSM_SPM_REG_SAW2_RST,
+
+ MSM_SPM_REG_SAW2_ID,
+ MSM_SPM_REG_SAW2_SECURE,
+ MSM_SPM_REG_SAW2_STS0,
+ MSM_SPM_REG_SAW2_STS1,
+ MSM_SPM_REG_SAW2_STS2,
+ MSM_SPM_REG_SAW2_VCTL,
+ MSM_SPM_REG_SAW2_SEQ_ENTRY,
+ MSM_SPM_REG_SAW2_SPM_STS,
+ MSM_SPM_REG_SAW2_AVS_STS,
+ MSM_SPM_REG_SAW2_PMIC_STS,
+ MSM_SPM_REG_SAW2_VERSION,
+
+ MSM_SPM_REG_NR,
+};
+
+struct msm_spm_mode {
+ u32 mode;
+ u8 *cmd;
+ u32 start_addr;
+};
+
+struct msm_spm_driver_data {
+ void __iomem *reg_base_addr;
+ u32 reg_shadow[MSM_SPM_REG_NR];
+ u32 *reg_offsets;
+ struct msm_spm_mode *modes;
+ u32 num_modes;
+};
+
+int msm_spm_drv_init(struct msm_spm_driver_data *dev);
+int msm_spm_drv_set_low_power_mode(struct msm_spm_driver_data *dev, u32 addr);
+int msm_spm_drv_set_spm_enable(struct msm_spm_driver_data *dev, bool enable);
+
+#endif /* __QCOM_SPM_DRIVER_H */
diff --git a/drivers/soc/qcom/spm.c b/drivers/soc/qcom/spm.c
new file mode 100644
index 000..81e578c
--- /dev/null
+++ b/drivers/soc/qcom/spm.c
@@ -0,0 +1,192 @@
+/* Copyright (c) 2011-2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY
[PATCH v5 3/7] qcom: spm-devices: Add SPM device manager for the SoC
Based on work by many authors, available at codeaurora.org
Each cpu or an L2$ has an SPM device. They are identical instances of
the same SPM block. This allows for multiple instances be grouped and
managed collectively. spm-devices.c is the SPM device manager managing
multiple SPM devices on top of the driver layer.
Device configuration of each SPM is picked up from the DTS. The hardware
configuration of each of the SPM is handled by the driver (spm.c).
Signed-off-by: Lina Iyer lina.i...@linaro.org
[lina: simplify the driver for initial submission, clean up and update
commit text]
---
Documentation/devicetree/bindings/arm/msm/spm.txt | 47 +
drivers/soc/qcom/Kconfig | 8 +
drivers/soc/qcom/Makefile | 2 +-
drivers/soc/qcom/spm-devices.c| 198 ++
include/soc/qcom/spm.h| 38 +
5 files changed, 292 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/arm/msm/spm.txt
create mode 100644 drivers/soc/qcom/spm-devices.c
create mode 100644 include/soc/qcom/spm.h
diff --git a/Documentation/devicetree/bindings/arm/msm/spm.txt
b/Documentation/devicetree/bindings/arm/msm/spm.txt
new file mode 100644
index 000..30623b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/spm.txt
@@ -0,0 +1,47 @@
+* Subsystem Power Manager (SAW2)
+
+S4 generation of MSMs have SPM hardware blocks to control the Application
+Processor Sub-System power. These SPM blocks run individual state machine
+to determine what the core (L2 or Krait/Scorpion) would do when the WFI
+instruction is executed by the core.
+
+The devicetree representation of the SPM block should be:
+
+Required properties
+
+- compatible: Could be one of -
+ qcom,spm-v2.1
+- reg: The physical address and the size of the SPM's memory mapped registers
+- qcom,cpu: phandle for the CPU that the SPM block is attached to.
+ This field is required on only for SPMs that control the CPU.
+- qcom,saw2-clk-div: SAW2 configuration register to program the SPM runtime
+ clocks.
+- qcom,saw2-delays: The SPM delay values that SPM sequences would refer to.
+- qcom,saw2-enable: The SPM control register to enable/disable the sleep state
+ machine.
+
+Optional properties
+
+- qcom,saw2-spm-cmd-wfi: The WFI command sequence
+- qcom,saw2-spm-cmd-ret: The Retention command sequence
+- qcom,saw2-spm-cmd-spc: The Standalone PC command sequence
+- qcom,saw2-spm-cmd-pc: The Power Collapse command sequence. This sequence may
+ turn off other SoC components.
+- qcom,saw2-spm-cmd-gdhs: GDHS (Globally Distributed Head Switch) command
+ sequence. This sequence will retain the memory but turn off the logic.
+-
+Example:
+ spm@f9089000 {
+ compatible = qcom,spm-v2.1;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0xf9089000 0x1000;
+ qcom,cpu = CPU0;
+ qcom,saw2-clk-div = 0x1;
+ qcom,saw2-delays = 0x2400;
+ qcom,saw2-enable = 0x1;
+ qcom,saw2-spm-cmd-wfi = [03 0b 0f];
+ qcom,saw2-spm-cmd-spc = [00 20 50 80 60 70 10 92
+ a0 b0 03 68 70 3b 92 a0 b0
+ 82 2b 50 10 30 02 22 30 0f];
+ };
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 7dcd554..cd249c4 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -11,3 +11,11 @@ config QCOM_GSBI
config QCOM_SCM
bool
+
+config QCOM_PM
+ bool Qualcomm Power Management
+ depends on PM ARCH_QCOM
+ help
+ QCOM Platform specific power driver to manage cores and L2 low power
+ modes. It interface with various system drivers to put the cores in
+ low power modes.
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 20b329f..9457b2a 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -1,4 +1,4 @@
obj-$(CONFIG_QCOM_GSBI)+= qcom_gsbi.o
-obj-$(CONFIG_QCOM_PM) += spm.o
+obj-$(CONFIG_QCOM_PM) += spm.o spm-devices.o
CFLAGS_scm.o :=$(call as-instr,.arch_extension sec,-DREQUIRES_SEC=1)
obj-$(CONFIG_QCOM_SCM) += scm.o scm-boot.o
diff --git a/drivers/soc/qcom/spm-devices.c b/drivers/soc/qcom/spm-devices.c
new file mode 100644
index 000..776c0af
--- /dev/null
+++ b/drivers/soc/qcom/spm-devices.c
@@ -0,0 +1,198 @@
+/* Copyright (c) 2011-2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[PATCH v5 5/7] qcom: msm-pm: Add cpu low power mode functions
Based on work by many authors, available at codeaurora.org
Add interface layer to abstract and handle hardware specific
functionality for executing various cpu low power modes in QCOM
chipsets.
QCOM cpus support multiple low power modes. The C-States are defined as -
* WFI (clock gating)
* Retention (clock gating at lower power)
* Standalone Power Collapse (Standalone PC or SPC) - The power to
the cpu is lost and the cpu warmboots.
* Power Collapse (PC) - Same as SPC, but is a cognizant of the fact
that the SoC may do deeper sleep modes.
Signed-off-by: Lina Iyer lina.i...@linaro.org
[lina: simplify the driver for an initial submission, add commit text
description of idle states]
---
drivers/soc/qcom/Makefile | 2 +-
drivers/soc/qcom/msm-pm.c | 106 ++
include/soc/qcom/pm.h | 31 ++
3 files changed, 138 insertions(+), 1 deletion(-)
create mode 100644 drivers/soc/qcom/msm-pm.c
create mode 100644 include/soc/qcom/pm.h
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 9457b2a..acdd6fa 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -1,4 +1,4 @@
obj-$(CONFIG_QCOM_GSBI)+= qcom_gsbi.o
-obj-$(CONFIG_QCOM_PM) += spm.o spm-devices.o
+obj-$(CONFIG_QCOM_PM) += spm.o spm-devices.o msm-pm.o
CFLAGS_scm.o :=$(call as-instr,.arch_extension sec,-DREQUIRES_SEC=1)
obj-$(CONFIG_QCOM_SCM) += scm.o scm-boot.o
diff --git a/drivers/soc/qcom/msm-pm.c b/drivers/soc/qcom/msm-pm.c
new file mode 100644
index 000..8926c71
--- /dev/null
+++ b/drivers/soc/qcom/msm-pm.c
@@ -0,0 +1,106 @@
+/* Copyright (c) 2010-2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+
+#include asm/proc-fns.h
+#include asm/suspend.h
+
+#include soc/qcom/pm.h
+#include soc/qcom/scm.h
+#include soc/qcom/scm-boot.h
+#include soc/qcom/spm.h
+
+#define SCM_CMD_TERMINATE_PC (0x2)
+#define SCM_FLUSH_FLAG_MASK(0x3)
+
+static int set_up_boot_address(void *entry, int cpu)
+{
+ static int flags[NR_CPUS] = {
+ SCM_FLAG_WARMBOOT_CPU0,
+ SCM_FLAG_WARMBOOT_CPU1,
+ SCM_FLAG_WARMBOOT_CPU2,
+ SCM_FLAG_WARMBOOT_CPU3,
+ };
+ static DEFINE_PER_CPU(void *, last_known_entry);
+
+ if (entry == per_cpu(last_known_entry, cpu))
+ return 0;
+
+ per_cpu(last_known_entry, cpu) = entry;
+ return scm_set_boot_addr(virt_to_phys(entry), flags[cpu]);
+}
+
+static int msm_pm_collapse(unsigned long int unused)
+{
+ int ret;
+ enum msm_pm_l2_scm_flag flag;
+
+ ret = set_up_boot_address(cpu_resume, raw_smp_processor_id());
+ if (ret) {
+ pr_err(Failed to set warm boot address for cpu %d\n,
+ raw_smp_processor_id());
+ return ret;
+ }
+
+ flag = MSM_SCM_L2_ON SCM_FLUSH_FLAG_MASK;
+ scm_call_atomic1(SCM_SVC_BOOT, SCM_CMD_TERMINATE_PC, flag);
+
+ return 0;
+}
+
+/**
+ * msm_cpu_pm_enter_sleep(): Enter a low power mode on current cpu
+ *
+ * @mode - sleep mode to enter
+ *
+ * The code should be called with interrupts disabled and on the core on
+ * which the low power mode is to be executed.
+ *
+ */
+static int msm_cpu_pm_enter_sleep(enum msm_pm_sleep_mode mode)
+{
+ int ret;
+
+ switch (mode) {
+ case MSM_PM_SLEEP_MODE_SPC:
+ msm_spm_set_low_power_mode(MSM_SPM_MODE_POWER_COLLAPSE);
+ ret = cpu_suspend(0, msm_pm_collapse);
+ break;
+ default:
+ case MSM_PM_SLEEP_MODE_WFI:
+ msm_spm_set_low_power_mode(MSM_SPM_MODE_CLOCK_GATING);
+ ret = cpu_do_idle();
+ break;
+ }
+
+ local_irq_enable();
+
+ return ret;
+}
+
+static struct platform_device qcom_cpuidle_device = {
+ .name = qcom_cpuidle,
+ .id= -1,
+ .dev.platform_data = msm_cpu_pm_enter_sleep,
+};
+
+static int __init msm_pm_device_init(void)
+{
+ platform_device_register(qcom_cpuidle_device);
+
+ return 0;
+}
+device_initcall(msm_pm_device_init);
diff --git a/include/soc/qcom/pm.h b/include/soc/qcom/pm.h
new file mode 100644
index 000..c2f006b
--- /dev/null
+++ b/include/soc/qcom/pm.h
@@ -0,0 +1,31 @@
+/*
+ * Copyright (c) 2009-2014, The Linux Foundation. All rights reserved.
+ *
+ * This software is licensed under the
[PATCH v5 7/7] arm: dts: qcom: Add idle states device nodes for 8974
Add allowable C-States for each cpu using the cpu-idle-states node.
ARM spec dictates WFI as the default idle state at 0. Support standalone
power collapse (power down that does not affect any SoC idle states) for
each cpu.
Signed-off-by: Lina Iyer lina.i...@linaro.org
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 0580bc2..041c8b6 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -21,6 +21,7 @@
reg = 0;
next-level-cache = L2;
qcom,acc = acc0;
+ cpu-idle-states = CPU_WFI CPU_SPC;
};
CPU1: cpu@1 {
@@ -30,6 +31,7 @@
reg = 1;
next-level-cache = L2;
qcom,acc = acc1;
+ cpu-idle-states = CPU_WFI CPU_SPC;
};
CPU2: cpu@2 {
@@ -39,6 +41,7 @@
reg = 2;
next-level-cache = L2;
qcom,acc = acc2;
+ cpu-idle-states = CPU_WFI CPU_SPC;
};
CPU3: cpu@3 {
@@ -48,6 +51,7 @@
reg = 3;
next-level-cache = L2;
qcom,acc = acc3;
+ cpu-idle-states = CPU_WFI CPU_SPC;
};
L2: l2-cache {
@@ -55,6 +59,22 @@
cache-level = 2;
qcom,saw = saw_l2;
};
+
+ idle-states {
+ CPU_WFI: cpu-idle-state-0 {
+ compatible = qcom,idle-state-wfi,
arm,idle-state;
+ entry-latency-us = 1;
+ exit-latency-us = 1;
+ min-residency-us = 2;
+ };
+
+ CPU_SPC: cpu-idle-state-1 {
+ compatible = qcom,idle-state-spc,
arm,idle-state;
+ entry-latency-us = 150;
+ exit-latency-us = 200;
+ min-residency-us = 2000;
+ };
+ };
};
cpu-pmu {
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 6/7] qcom: cpuidle: Add cpuidle driver for QCOM cpus
Add cpuidle driver interface to allow cpus to go into C-States. Use the cpuidle DT interface common across ARM architectures to provide the C-State information to the cpuidle framework. Supported modes at this time are clock gating (wfi) and cpu power down (Standalone PC or spc). Signed-off-by: Lina Iyer lina.i...@linaro.org --- .../bindings/arm/msm/qcom,idle-state.txt | 72 ++ drivers/cpuidle/Kconfig.arm| 7 ++ drivers/cpuidle/Makefile | 1 + drivers/cpuidle/cpuidle-qcom.c | 87 ++ 4 files changed, 167 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt create mode 100644 drivers/cpuidle/cpuidle-qcom.c diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt b/Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt new file mode 100644 index 000..47095b9 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt @@ -0,0 +1,72 @@ +QCOM Idle States for cpuidle driver + +ARM provides idle-state node to define the cpuidle states, as defined in [1]. +cpuidle-qcom is the cpuidle driver for Qualcomm SoCs and uses these idle +states. Idle states have different enter/exit latency and residency values. +The idle states supported by the QCOM SoC are defined as - + +* WFI +* Retention +* Standalone Power Collapse (Standalone PC or SPC) +* Power Collapse (PC) + +WFI: WFI does a little more in addition to architectural clock gating. ARM +processors when execute the wfi instruction will gate their internal clocks. +QCOM cpus use this instruction as a trigger for the SPM state machine. Usually +with a cpu entering WFI, the SPM is configured to do clock-gating as well. The +SPM state machine waits for the interrrupt to trigger the core back in to +active. When all CPUs in the SoC, clock gate using the ARM wfi instruction, the +second level cache usually can also clock gate sensing no cpu activity. When a +cpu is ready to run, it needs the cache to be active before starting execution. +Allowing the SPM to execute the clock gating statemachine and waiting for +interrupt on behalf of the processor has a benefit of guaranteeing that the +system state is conducive for the core to resume execution. + +Retention: Retention is a low power state where the core is clockgated and the +memory and the registers associated with the core are retained. The voltage +may be reduced to the minimum value needed to keep the processor registers +active. Retention is triggered when the core executes wfi instruction. The SPM +should be configured to execute the retention sequence and would wait for +interrupt, before restoring the cpu to execution state. Retention may have a +slightly higher latency than WFI. + +Standalone PC: A cpu can power down and warmboot if there is a sufficient time +between now and the next know wake up. SPC mode is used to indicate a core +entering a power down state without consulting any other cpu or the system +resources. This helps save power only on that core. Like WFI and Retention, the +core executes wfi and the SPM programmed to do SPC would use the cpu control +logic to power down the core's supply and restore it back when woken up by an +interrupt. Applying power and reseting the core causes the core to warmboot +back into secure mode which trampolines the control back to the kernel. To +enter a power down state the kernel needs to call into the secure layer which +would then execute the ARM wfi instruction. Failing to do so, would result in a +crash enforced by the warm boot code in the secure layer. On a SoC with +write-back L1 cache, the cache would need to be flushed. + +Power Collapse: This state is similiar to the SPC mode, but distinguishes +itself in the fact that the cpu acknowledges and permits the SoC to enter +deeper sleep modes. In a hierarchical power domain SoC, this means L2 and other +caches can be flushed, system bus, clocks - lowered, and SoC main XO turned off +and voltages reduced, provided all cpus enter this state. In other words, it is +a coupled idle state. Since the span of low power modes possible at this state +is vast, the exit latency and the residency of this low power mode would be +considered high even though at a cpu level, this essentially is cpu power down. +The SPM in this state also may handshake with the Resource power manager +processor in the SoC to indicate a complete subsystem shut down. + +The idle-state for QCOM SoCs are distinguished by the compatible property of +the node. They indicate to the cpuidle driver the entry point to use for +cpuidle. The devicetree representation of the idle state should be - + +Required properties: + +- compatible: Must be arm,idle-state + and one of - + qcom,idle-state-wfi, + qcom,idle-state-ret, + qcom,idle-state-spc,
[PATCH v5 4/7] arm: dts: qcom: Add SPM device bindings for 8974
Add SPM device bindings for QCOM 8974 based cpus. SPM is the sub-system
power manager and controls the logic around the cores (cpu and L2).
Each core has an instance of SPM and controls only that core. Each cpu
SPM is configured to support WFI and SPC (standalone-power collapse).
Signed-off-by: Lina Iyer lina.i...@linaro.org
---
arch/arm/boot/dts/qcom-msm8974-pm.dtsi | 69 ++
arch/arm/boot/dts/qcom-msm8974.dtsi| 10 +++--
2 files changed, 75 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/boot/dts/qcom-msm8974-pm.dtsi
diff --git a/arch/arm/boot/dts/qcom-msm8974-pm.dtsi
b/arch/arm/boot/dts/qcom-msm8974-pm.dtsi
new file mode 100644
index 000..bbfb1d5
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-msm8974-pm.dtsi
@@ -0,0 +1,69 @@
+/* Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+soc {
+ spm@f9089000 {
+ compatible = qcom,spm-v2.1;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0xf9089000 0x1000;
+ qcom,cpu = CPU0;
+ qcom,saw2-clk-div = 0x01;
+ qcom,saw2-delays = 0x3C102800;
+ qcom,saw2-enable = 0x01;
+ qcom,saw2-spm-cmd-wfi = [03 0b 0f];
+ qcom,saw2-spm-cmd-spc = [00 20 80 10 E8 5B 03 3B E8 5B 82 10 0B
+ 30 06 26 30 0F];
+ };
+
+ spm@f9099000 {
+ compatible = qcom,spm-v2.1;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0xf9099000 0x1000;
+ qcom,cpu = CPU1;
+ qcom,saw2-clk-div = 0x01;
+ qcom,saw2-delays = 0x3C102800;
+ qcom,saw2-enable = 0x01;
+ qcom,saw2-spm-cmd-wfi = [03 0b 0f];
+ qcom,saw2-spm-cmd-spc = [00 20 80 10 E8 5B 03 3B E8 5B 82 10 0B
+ 30 06 26 30 0F];
+ };
+
+ spm@f90a9000 {
+ compatible = qcom,spm-v2.1;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0xf90a9000 0x1000;
+ qcom,cpu = CPU2;
+ qcom,saw2-clk-div = 0x01;
+ qcom,saw2-delays = 0x3C102800;
+ qcom,saw2-enable = 0x01;
+ qcom,saw2-spm-cmd-wfi = [03 0b 0f];
+ qcom,saw2-spm-cmd-spc = [00 20 80 10 E8 5B 03 3B E8 5B 82 10 0B
+ 30 06 26 30 0F];
+ };
+
+ spm@f90b9000 {
+ compatible = qcom,spm-v2.1;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0xf90b9000 0x1000;
+ qcom,cpu = CPU3;
+ qcom,saw2-clk-div = 0x01;
+ qcom,saw2-delays = 0x3C102800;
+ qcom,saw2-enable = 0x01;
+ qcom,saw2-spm-cmd-wfi = [03 0b 0f];
+ qcom,saw2-spm-cmd-spc = [00 20 80 10 E8 5B 03 3B E8 5B 82 10 0B
+ 30 06 26 30 0F];
+ };
+};
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 69dca2a..0580bc2 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -14,7 +14,7 @@
#size-cells = 0;
interrupts = 1 9 0xf04;
- cpu@0 {
+ CPU0: cpu@0 {
compatible = qcom,krait;
enable-method = qcom,kpss-acc-v2;
device_type = cpu;
@@ -23,7 +23,7 @@
qcom,acc = acc0;
};
- cpu@1 {
+ CPU1: cpu@1 {
compatible = qcom,krait;
enable-method = qcom,kpss-acc-v2;
device_type = cpu;
@@ -32,7 +32,7 @@
qcom,acc = acc1;
};
- cpu@2 {
+ CPU2: cpu@2 {
compatible = qcom,krait;
enable-method = qcom,kpss-acc-v2;
device_type = cpu;
@@ -41,7 +41,7 @@
qcom,acc = acc2;
};
- cpu@3 {
+ CPU3: cpu@3 {
compatible = qcom,krait;
enable-method = qcom,kpss-acc-v2;
device_type = cpu;
@@ -238,3 +238,5 @@
};
};
};
+
+#include qcom-msm8974-pm.dtsi
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to
Re: [PATCH v2] ARM: msm: Update the references to DEBUG_MSM_UARTx
On Thu, 2014-06-19 at 10:16 +0200, Paul Bolle wrote:
On Mon, 2014-05-26 at 19:37 +0300, Georgi Djakov wrote:
The Kconfig options DEBUG_MSM_UART1, DEBUG_MSM_UART2, DEBUG_MSM_UART3,
MSM_DEBUG_UART1, MSM_DEBUG_UART2 and MSM_DEBUG_UART3 are removed, but
they are still referenced in the following files:
arch/arm/mach-msm/io.c,
arch/arm/mach-msm/board-trout.c
arch/arm/mach-msm/board-trout-gpio.c
Fix this by updating the reference to the new Kconfig option.
Reported-by: Paul Bolle pebo...@tiscali.nl
Signed-off-by: Georgi Djakov gdja...@mm-sol.com
---
This patch is included neither in v3.16-rc1 nor in next-20140619.
Still true for v3.17-rc3 and next-20140904.
Did it run into problems or is it already queued somewhere?
This issue was reported three months ago but is still present. Should I
perhaps submit the trivial patch that removes the checks for these
macros and the code they now hide?
Changes since v1:
- Fixed similar issue in board-trout.c and board-trout-gpio.c
Applies to next-20140526.
arch/arm/mach-msm/board-trout-gpio.c |2 +-
arch/arm/mach-msm/board-trout.c |2 +-
arch/arm/mach-msm/io.c |6 ++
3 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-msm/board-trout-gpio.c
b/arch/arm/mach-msm/board-trout-gpio.c
index 87e1d01..e24930e 100644
--- a/arch/arm/mach-msm/board-trout-gpio.c
+++ b/arch/arm/mach-msm/board-trout-gpio.c
@@ -94,7 +94,7 @@ static int trout_gpio_to_irq(struct gpio_chip *chip,
unsigned offset)
}
static struct msm_gpio_chip msm_gpio_banks[] = {
-#if defined(CONFIG_MSM_DEBUG_UART1)
+#if defined(CONFIG_DEBUG_MSM_UART) (CONFIG_DEBUG_UART_PHYS ==
0xa9a0)
/* H2W pins - UART1 */
TROUT_GPIO_BANK(MISC2, 0x00, TROUT_GPIO_MISC2_BASE, 0x40),
#else
diff --git a/arch/arm/mach-msm/board-trout.c
b/arch/arm/mach-msm/board-trout.c
index 015d544..8369dfd 100644
--- a/arch/arm/mach-msm/board-trout.c
+++ b/arch/arm/mach-msm/board-trout.c
@@ -90,7 +90,7 @@ static void __init trout_map_io(void)
msm_map_common_io();
iotable_init(trout_io_desc, ARRAY_SIZE(trout_io_desc));
-#ifdef CONFIG_MSM_DEBUG_UART3
+#if defined(CONFIG_DEBUG_MSM_UART) (CONFIG_DEBUG_UART_PHYS ==
0xa9c0)
/* route UART3 to the H2W extended usb connector */
writeb(0x80, TROUT_CPLD_BASE + 0x00);
#endif
diff --git a/arch/arm/mach-msm/io.c b/arch/arm/mach-msm/io.c
index 34e0947..b042dca 100644
--- a/arch/arm/mach-msm/io.c
+++ b/arch/arm/mach-msm/io.c
@@ -57,8 +57,7 @@ static struct map_desc msm_io_desc[] __initdata = {
.length = MSM_SHARED_RAM_SIZE,
.type = MT_DEVICE,
},
-#if defined(CONFIG_DEBUG_MSM_UART1) || defined(CONFIG_DEBUG_MSM_UART2) || \
- defined(CONFIG_DEBUG_MSM_UART3)
+#if defined(CONFIG_DEBUG_MSM_UART)
{
/* Must be last: virtual and pfn filled in by debug_ll_addr() */
.length = SZ_4K,
@@ -76,8 +75,7 @@ void __init msm_map_common_io(void)
* pages are peripheral interface or not.
*/
asm(mcr p15, 0, %0, c15, c2, 4 : : r (0));
-#if defined(CONFIG_DEBUG_MSM_UART1) || defined(CONFIG_DEBUG_MSM_UART2) || \
- defined(CONFIG_DEBUG_MSM_UART3)
+#if defined(CONFIG_DEBUG_MSM_UART)
#ifdef CONFIG_MMU
debug_ll_addr(msm_io_desc[size - 1].pfn,
msm_io_desc[size - 1].virtual);
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] genirq: Introduce irq_read_line()
On Tue, Aug 19, 2014 at 1:23 PM, Bjorn Andersson bjorn.anders...@sonymobile.com wrote: Introduce the irq_read_line() function to allow device drivers to read the current logical state of an input when the hardware only exposes this through status bits in the interrupt controller. The new function is backed by a new callback function in the irq_chip - irq_read_line() - that can be implemented by irq_chips that owns such status bits. Based on rfc patch from April 2011 by Abhijeet. Cc: Abhijeet Dharmapurikar adhar...@codeaurora.org Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com ping? -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Status of chipidea msm USB reset patch
On Thu, Sep 04, 2014 at 07:47:40AM -0700, Tim Bird wrote:
On Fri, Aug 15, 2014 at 12:08 AM, Ivan T. Ivanov iiva...@mm-sol.com wrote:
On Fri, 2014-08-15 at 08:23 +0800, Peter Chen wrote:
On Thu, Aug 14, 2014 at 11:54:02AM -0500, Felipe Balbi wrote:
Hi,
On Thu, Aug 14, 2014 at 09:53:10AM -0700, Tim Bird wrote:
Ping. Anybody know the status of this patch? Is it queued in
someone's tree?
Without it the USB driver for the Qualcomm 8974 (hsusb phy) doesn't
work (at least for me).
It looks like it got dropped from Ivan's original patch series, back
in May.
I don't maintain chipidea, Peter's the guy you want
Below patch was not at msm chipidea patchset Ivan sent me.
http://markmail.org/search/?q=%5BPATCH+v4+0%2F3%5D+usb%3A+chipidea%3A+msm%3A+Clean+and+fix+#query:%5BPATCH%20v4%200%2F3%5D%20usb%3A%20chipidea%3A%20msm%3A%20Clean%20and%20fix%20from%3A%22Ivan%20T.%20Ivanov%22+page:1+mid:mt7hgr7yamyzegg3+state:results
My fault. I have waiting PHY patches to be accepted to send this one.
Will rebase and resend.
Peter,
There appears to be no progress on this.
Can we just add the existing patch, get it into Linus' tree asap as
a bugfix (preferably in this RC cycle)? Then ask Ivan to rebase his
patches on top of this, instead of rebasing this patch as part of a
larger effort with an unclear delivery date?
Note that without this patch, the driver in mainline doesn't work at all,
so adding it couldn't possibly make mainline worse.
IMHO this should be CC:'ed to stable for the 3.16 kernel as well. No
other files are affected, and it applies and builds on 3.16 without problems.
Please let me know.
OK, in fact, this patch is in my next chipidea next tree, and will be in
3.18-rc1.
(From the commit log, it doesn't show it is a bugfix:))
If it is a bugfix for you, I will send it go Greg.
Peter
-- Tim Bird
Senior Software Engineer, Sony Mobile
Architecture Group Chair, CE Workgroup, Linux Foundation
Patch follows for reference:
Subject: [PATCH] usb: chipidea: msm: Use USB PHY API to control PHY state
PHY drivers keep track of the current state of the hardware,
so don't change PHY settings under it.
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
---
drivers/usb/chipidea/ci_hdrc_msm.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
b/drivers/usb/chipidea/ci_hdrc_msm.c
index d72b9d2..81de834 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -20,13 +20,11 @@
static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
{
struct device *dev = ci-gadget.dev.parent;
- int val;
switch (event) {
case CI_HDRC_CONTROLLER_RESET_EVENT:
dev_dbg(dev, CI_HDRC_CONTROLLER_RESET_EVENT received\n);
- writel(0, USB_AHBBURST);
- writel(0, USB_AHBMODE);
+ usb_phy_init(ci-transceiver);
break;
case CI_HDRC_CONTROLLER_STOPPED_EVENT:
dev_dbg(dev, CI_HDRC_CONTROLLER_STOPPED_EVENT received\n);
@@ -34,10 +32,7 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc
*ci, unsigned event)
* Put the transceiver in non-driving mode. Otherwise host
* may not detect soft-disconnection.
*/
- val = usb_phy_io_read(ci-transceiver, ULPI_FUNC_CTRL);
- val = ~ULPI_FUNC_CTRL_OPMODE_MASK;
- val |= ULPI_FUNC_CTRL_OPMODE_NONDRIVING;
- usb_phy_io_write(ci-transceiver, val, ULPI_FUNC_CTRL);
+ usb_phy_notify_disconnect(ci-transceiver, USB_SPEED_UNKNOWN);
break;
default:
dev_dbg(dev, unknown ci_hdrc event\n);
--
1.8.2.2
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Status of chipidea msm USB reset patch
On Thu, Sep 04, 2014 at 07:47:40AM -0700, Tim Bird wrote:
On Fri, Aug 15, 2014 at 12:08 AM, Ivan T. Ivanov iiva...@mm-sol.com wrote:
On Fri, 2014-08-15 at 08:23 +0800, Peter Chen wrote:
On Thu, Aug 14, 2014 at 11:54:02AM -0500, Felipe Balbi wrote:
Hi,
On Thu, Aug 14, 2014 at 09:53:10AM -0700, Tim Bird wrote:
Ping. Anybody know the status of this patch? Is it queued in
someone's tree?
Without it the USB driver for the Qualcomm 8974 (hsusb phy) doesn't
work (at least for me).
It looks like it got dropped from Ivan's original patch series, back
in May.
I don't maintain chipidea, Peter's the guy you want
Below patch was not at msm chipidea patchset Ivan sent me.
http://markmail.org/search/?q=%5BPATCH+v4+0%2F3%5D+usb%3A+chipidea%3A+msm%3A+Clean+and+fix+#query:%5BPATCH%20v4%200%2F3%5D%20usb%3A%20chipidea%3A%20msm%3A%20Clean%20and%20fix%20from%3A%22Ivan%20T.%20Ivanov%22+page:1+mid:mt7hgr7yamyzegg3+state:results
My fault. I have waiting PHY patches to be accepted to send this one.
Will rebase and resend.
Peter,
There appears to be no progress on this.
Can we just add the existing patch, get it into Linus' tree asap as
a bugfix (preferably in this RC cycle)? Then ask Ivan to rebase his
patches on top of this, instead of rebasing this patch as part of a
larger effort with an unclear delivery date?
Note that without this patch, the driver in mainline doesn't work at all,
so adding it couldn't possibly make mainline worse.
IMHO this should be CC:'ed to stable for the 3.16 kernel as well. No
other files are affected, and it applies and builds on 3.16 without problems.
Wait, the below patch was not exactly the Ivan sent to me, it has no below
change at Ivan's recent patch
- writel(0, USB_AHBBURST);
- writel(0, USB_AHBMODE);
https://github.com/hzpeterchen/linux-usb/commit/be3473c05639dc84696c5e66e524ca22180cbe88
https://github.com/hzpeterchen/linux-usb/commit/b59838118bcc14a6a4ea1efec85c3452a705bfe0
Peter
-- Tim Bird
Senior Software Engineer, Sony Mobile
Architecture Group Chair, CE Workgroup, Linux Foundation
Patch follows for reference:
Subject: [PATCH] usb: chipidea: msm: Use USB PHY API to control PHY state
PHY drivers keep track of the current state of the hardware,
so don't change PHY settings under it.
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
---
drivers/usb/chipidea/ci_hdrc_msm.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
b/drivers/usb/chipidea/ci_hdrc_msm.c
index d72b9d2..81de834 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -20,13 +20,11 @@
static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
{
struct device *dev = ci-gadget.dev.parent;
- int val;
switch (event) {
case CI_HDRC_CONTROLLER_RESET_EVENT:
dev_dbg(dev, CI_HDRC_CONTROLLER_RESET_EVENT received\n);
- writel(0, USB_AHBBURST);
- writel(0, USB_AHBMODE);
+ usb_phy_init(ci-transceiver);
break;
case CI_HDRC_CONTROLLER_STOPPED_EVENT:
dev_dbg(dev, CI_HDRC_CONTROLLER_STOPPED_EVENT received\n);
@@ -34,10 +32,7 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc
*ci, unsigned event)
* Put the transceiver in non-driving mode. Otherwise host
* may not detect soft-disconnection.
*/
- val = usb_phy_io_read(ci-transceiver, ULPI_FUNC_CTRL);
- val = ~ULPI_FUNC_CTRL_OPMODE_MASK;
- val |= ULPI_FUNC_CTRL_OPMODE_NONDRIVING;
- usb_phy_io_write(ci-transceiver, val, ULPI_FUNC_CTRL);
+ usb_phy_notify_disconnect(ci-transceiver, USB_SPEED_UNKNOWN);
break;
default:
dev_dbg(dev, unknown ci_hdrc event\n);
--
1.8.2.2
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
