* [PATCH v6 04/14] mmc: sdhci-msm: Change poor style writel/readl of registers
From: Ritesh Harjani @ 2016-11-07 11:24 UTC (permalink / raw)
To: ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
adrian.hunter-ral2JQCrhuEAvxtiuMwx3w,
shawn.lin-TNX95d0MmH7DzftRWevZcw, sboyd-sgV2jX0FEOL9JmXXK+q4OQ
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
david.brown-QSEj5FYQhm4dnm+yROfE0A,
andy.gross-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
georgi.djakov-QSEj5FYQhm4dnm+yROfE0A,
alex.lemberg-XdAiOPVOjttBDgjK7y7TUQ,
mateusz.nowak-ral2JQCrhuEAvxtiuMwx3w,
Yuliy.Izrailov-XdAiOPVOjttBDgjK7y7TUQ,
asutoshd-sgV2jX0FEOL9JmXXK+q4OQ, kdorfman-sgV2jX0FEOL9JmXXK+q4OQ,
david.griego-QSEj5FYQhm4dnm+yROfE0A,
stummala-sgV2jX0FEOL9JmXXK+q4OQ, venkatg-sgV2jX0FEOL9JmXXK+q4OQ,
rnayak-sgV2jX0FEOL9JmXXK+q4OQ,
pramod.gurav-QSEj5FYQhm4dnm+yROfE0A, Ritesh Harjani
In-Reply-To: <1478517877-23733-1-git-send-email-riteshh-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
This patch changes the poor style of writel/readl registers
into more readable format. Also to avoid mixed style format
of readl/writel in sdhci-msm driver.
Signed-off-by: Ritesh Harjani <riteshh-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Acked-by: Adrian Hunter <adrian.hunter-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
drivers/mmc/host/sdhci-msm.c | 54 ++++++++++++++++++++++++++------------------
1 file changed, 32 insertions(+), 22 deletions(-)
diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 8ef44a2a..42f42aa 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -137,8 +137,9 @@ static int msm_config_cm_dll_phase(struct sdhci_host *host, u8 phase)
writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG);
/* Set CK_OUT_EN bit of DLL_CONFIG register to 1. */
- writel_relaxed((readl_relaxed(host->ioaddr + CORE_DLL_CONFIG)
- | CORE_CK_OUT_EN), host->ioaddr + CORE_DLL_CONFIG);
+ config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG);
+ config |= CORE_CK_OUT_EN;
+ writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG);
/* Wait until CK_OUT_EN bit of DLL_CONFIG register becomes '1' */
rc = msm_dll_poll_ck_out_en(host, 1);
@@ -305,6 +306,7 @@ static int msm_init_cm_dll(struct sdhci_host *host)
struct mmc_host *mmc = host->mmc;
int wait_cnt = 50;
unsigned long flags;
+ u32 config = 0;
spin_lock_irqsave(&host->lock, flags);
@@ -313,33 +315,40 @@ static int msm_init_cm_dll(struct sdhci_host *host)
* tuning is in progress. Keeping PWRSAVE ON may
* turn off the clock.
*/
- writel_relaxed((readl_relaxed(host->ioaddr + CORE_VENDOR_SPEC)
- & ~CORE_CLK_PWRSAVE), host->ioaddr + CORE_VENDOR_SPEC);
+ config = readl_relaxed(host->ioaddr + CORE_VENDOR_SPEC);
+ config &= ~CORE_CLK_PWRSAVE;
+ writel_relaxed(config, host->ioaddr + CORE_VENDOR_SPEC);
/* Write 1 to DLL_RST bit of DLL_CONFIG register */
- writel_relaxed((readl_relaxed(host->ioaddr + CORE_DLL_CONFIG)
- | CORE_DLL_RST), host->ioaddr + CORE_DLL_CONFIG);
+ config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG);
+ config |= CORE_DLL_RST;
+ writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG);
/* Write 1 to DLL_PDN bit of DLL_CONFIG register */
- writel_relaxed((readl_relaxed(host->ioaddr + CORE_DLL_CONFIG)
- | CORE_DLL_PDN), host->ioaddr + CORE_DLL_CONFIG);
+ config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG);
+ config |= CORE_DLL_PDN;
+ writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG);
msm_cm_dll_set_freq(host);
/* Write 0 to DLL_RST bit of DLL_CONFIG register */
- writel_relaxed((readl_relaxed(host->ioaddr + CORE_DLL_CONFIG)
- & ~CORE_DLL_RST), host->ioaddr + CORE_DLL_CONFIG);
+ config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG);
+ config &= ~CORE_DLL_RST;
+ writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG);
/* Write 0 to DLL_PDN bit of DLL_CONFIG register */
- writel_relaxed((readl_relaxed(host->ioaddr + CORE_DLL_CONFIG)
- & ~CORE_DLL_PDN), host->ioaddr + CORE_DLL_CONFIG);
+ config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG);
+ config &= ~CORE_DLL_PDN;
+ writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG);
/* Set DLL_EN bit to 1. */
- writel_relaxed((readl_relaxed(host->ioaddr + CORE_DLL_CONFIG)
- | CORE_DLL_EN), host->ioaddr + CORE_DLL_CONFIG);
+ config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG);
+ config |= CORE_DLL_EN;
+ writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG);
/* Set CK_OUT_EN bit to 1. */
- writel_relaxed((readl_relaxed(host->ioaddr + CORE_DLL_CONFIG)
- | CORE_CK_OUT_EN), host->ioaddr + CORE_DLL_CONFIG);
+ config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG);
+ config |= CORE_CK_OUT_EN;
+ writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG);
/* Wait until DLL_LOCK bit of DLL_STATUS register becomes '1' */
while (!(readl_relaxed(host->ioaddr + CORE_DLL_STATUS) &
@@ -536,7 +545,7 @@ static int sdhci_msm_probe(struct platform_device *pdev)
struct resource *core_memres;
int ret;
u16 host_version, core_minor;
- u32 core_version, caps;
+ u32 core_version, config;
u8 core_major;
host = sdhci_pltfm_init(pdev, &sdhci_msm_pdata, sizeof(*msm_host));
@@ -605,8 +614,9 @@ static int sdhci_msm_probe(struct platform_device *pdev)
}
/* Reset the core and Enable SDHC mode */
- writel_relaxed(readl_relaxed(msm_host->core_mem + CORE_POWER) |
- CORE_SW_RST, msm_host->core_mem + CORE_POWER);
+ config = readl_relaxed(msm_host->core_mem + CORE_POWER);
+ config |= CORE_SW_RST;
+ writel_relaxed(config, msm_host->core_mem + CORE_POWER);
/* SW reset can take upto 10HCLK + 15MCLK cycles. (min 40us) */
usleep_range(1000, 5000);
@@ -636,9 +646,9 @@ static int sdhci_msm_probe(struct platform_device *pdev)
* controller versions and must be explicitly enabled.
*/
if (core_major >= 1 && core_minor != 0x11 && core_minor != 0x12) {
- caps = readl_relaxed(host->ioaddr + SDHCI_CAPABILITIES);
- caps |= SDHCI_CAN_VDD_300 | SDHCI_CAN_DO_8BIT;
- writel_relaxed(caps, host->ioaddr +
+ config = readl_relaxed(host->ioaddr + SDHCI_CAPABILITIES);
+ config |= SDHCI_CAN_VDD_300 | SDHCI_CAN_DO_8BIT;
+ writel_relaxed(config, host->ioaddr +
CORE_VENDOR_SPEC_CAPABILITIES0);
}
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v6 03/14] clk: qcom: Move all sdcc rcgs to use clk_rcg2_floor_ops
From: Ritesh Harjani @ 2016-11-07 11:24 UTC (permalink / raw)
To: ulf.hansson, linux-mmc, adrian.hunter, shawn.lin, sboyd
Cc: devicetree, linux-clk, david.brown, andy.gross, linux-arm-msm,
georgi.djakov, alex.lemberg, mateusz.nowak, Yuliy.Izrailov,
asutoshd, kdorfman, david.griego, stummala, venkatg, rnayak,
pramod.gurav
In-Reply-To: <1478517877-23733-1-git-send-email-riteshh@codeaurora.org>
From: Rajendra Nayak <rnayak@codeaurora.org>
The sdcc driver for msm8996/msm8916/msm8974 and apq8084
expects a clk_set_rate() on the sdcc rcg clk to set
a floor value of supported clk rate closest to the requested
rate, by looking up the frequency table.
So move all the sdcc rcgs on all these platforms to use the
newly introduced clk_rcg2_floor_ops
Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
---
drivers/clk/qcom/gcc-apq8084.c | 8 ++++----
drivers/clk/qcom/gcc-msm8916.c | 4 ++--
drivers/clk/qcom/gcc-msm8974.c | 8 ++++----
drivers/clk/qcom/gcc-msm8996.c | 8 ++++----
4 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/clk/qcom/gcc-apq8084.c b/drivers/clk/qcom/gcc-apq8084.c
index 070037a..486d961 100644
--- a/drivers/clk/qcom/gcc-apq8084.c
+++ b/drivers/clk/qcom/gcc-apq8084.c
@@ -1142,7 +1142,7 @@ enum {
.name = "sdcc1_apps_clk_src",
.parent_names = gcc_xo_gpll0_gpll4,
.num_parents = 3,
- .ops = &clk_rcg2_ops,
+ .ops = &clk_rcg2_floor_ops,
},
};
@@ -1156,7 +1156,7 @@ enum {
.name = "sdcc2_apps_clk_src",
.parent_names = gcc_xo_gpll0,
.num_parents = 2,
- .ops = &clk_rcg2_ops,
+ .ops = &clk_rcg2_floor_ops,
},
};
@@ -1170,7 +1170,7 @@ enum {
.name = "sdcc3_apps_clk_src",
.parent_names = gcc_xo_gpll0,
.num_parents = 2,
- .ops = &clk_rcg2_ops,
+ .ops = &clk_rcg2_floor_ops,
},
};
@@ -1184,7 +1184,7 @@ enum {
.name = "sdcc4_apps_clk_src",
.parent_names = gcc_xo_gpll0,
.num_parents = 2,
- .ops = &clk_rcg2_ops,
+ .ops = &clk_rcg2_floor_ops,
},
};
diff --git a/drivers/clk/qcom/gcc-msm8916.c b/drivers/clk/qcom/gcc-msm8916.c
index 5c4e193..628e6ca 100644
--- a/drivers/clk/qcom/gcc-msm8916.c
+++ b/drivers/clk/qcom/gcc-msm8916.c
@@ -1107,7 +1107,7 @@ enum {
.name = "sdcc1_apps_clk_src",
.parent_names = gcc_xo_gpll0,
.num_parents = 2,
- .ops = &clk_rcg2_ops,
+ .ops = &clk_rcg2_floor_ops,
},
};
@@ -1132,7 +1132,7 @@ enum {
.name = "sdcc2_apps_clk_src",
.parent_names = gcc_xo_gpll0,
.num_parents = 2,
- .ops = &clk_rcg2_ops,
+ .ops = &clk_rcg2_floor_ops,
},
};
diff --git a/drivers/clk/qcom/gcc-msm8974.c b/drivers/clk/qcom/gcc-msm8974.c
index 0091520..348e30d 100644
--- a/drivers/clk/qcom/gcc-msm8974.c
+++ b/drivers/clk/qcom/gcc-msm8974.c
@@ -872,7 +872,7 @@ enum {
.name = "sdcc1_apps_clk_src",
.parent_names = gcc_xo_gpll0,
.num_parents = 2,
- .ops = &clk_rcg2_ops,
+ .ops = &clk_rcg2_floor_ops,
};
static struct clk_rcg2 sdcc1_apps_clk_src = {
@@ -894,7 +894,7 @@ enum {
.name = "sdcc2_apps_clk_src",
.parent_names = gcc_xo_gpll0,
.num_parents = 2,
- .ops = &clk_rcg2_ops,
+ .ops = &clk_rcg2_floor_ops,
},
};
@@ -908,7 +908,7 @@ enum {
.name = "sdcc3_apps_clk_src",
.parent_names = gcc_xo_gpll0,
.num_parents = 2,
- .ops = &clk_rcg2_ops,
+ .ops = &clk_rcg2_floor_ops,
},
};
@@ -922,7 +922,7 @@ enum {
.name = "sdcc4_apps_clk_src",
.parent_names = gcc_xo_gpll0,
.num_parents = 2,
- .ops = &clk_rcg2_ops,
+ .ops = &clk_rcg2_floor_ops,
},
};
diff --git a/drivers/clk/qcom/gcc-msm8996.c b/drivers/clk/qcom/gcc-msm8996.c
index fe03e6f..5adb163 100644
--- a/drivers/clk/qcom/gcc-msm8996.c
+++ b/drivers/clk/qcom/gcc-msm8996.c
@@ -460,7 +460,7 @@ enum {
.name = "sdcc1_apps_clk_src",
.parent_names = gcc_xo_gpll0_gpll4_gpll0_early_div,
.num_parents = 4,
- .ops = &clk_rcg2_ops,
+ .ops = &clk_rcg2_floor_ops,
},
};
@@ -497,7 +497,7 @@ enum {
.name = "sdcc2_apps_clk_src",
.parent_names = gcc_xo_gpll0_gpll4,
.num_parents = 3,
- .ops = &clk_rcg2_ops,
+ .ops = &clk_rcg2_floor_ops,
},
};
@@ -511,7 +511,7 @@ enum {
.name = "sdcc3_apps_clk_src",
.parent_names = gcc_xo_gpll0_gpll4,
.num_parents = 3,
- .ops = &clk_rcg2_ops,
+ .ops = &clk_rcg2_floor_ops,
},
};
@@ -535,7 +535,7 @@ enum {
.name = "sdcc4_apps_clk_src",
.parent_names = gcc_xo_gpll0,
.num_parents = 2,
- .ops = &clk_rcg2_ops,
+ .ops = &clk_rcg2_floor_ops,
},
};
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH v6 01/14] clk: Add clk_hw_get_clk() helper API to be used by clk providers
From: Ritesh Harjani @ 2016-11-07 11:24 UTC (permalink / raw)
To: ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
adrian.hunter-ral2JQCrhuEAvxtiuMwx3w,
shawn.lin-TNX95d0MmH7DzftRWevZcw, sboyd-sgV2jX0FEOL9JmXXK+q4OQ
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
david.brown-QSEj5FYQhm4dnm+yROfE0A,
andy.gross-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
georgi.djakov-QSEj5FYQhm4dnm+yROfE0A,
alex.lemberg-XdAiOPVOjttBDgjK7y7TUQ,
mateusz.nowak-ral2JQCrhuEAvxtiuMwx3w,
Yuliy.Izrailov-XdAiOPVOjttBDgjK7y7TUQ,
asutoshd-sgV2jX0FEOL9JmXXK+q4OQ, kdorfman-sgV2jX0FEOL9JmXXK+q4OQ,
david.griego-QSEj5FYQhm4dnm+yROfE0A,
stummala-sgV2jX0FEOL9JmXXK+q4OQ, venkatg-sgV2jX0FEOL9JmXXK+q4OQ,
rnayak-sgV2jX0FEOL9JmXXK+q4OQ,
pramod.gurav-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <1478517877-23733-1-git-send-email-riteshh-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
From: Rajendra Nayak <rnayak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Add a helper API that will allow clk providers to turn their clk_hw
structures into struct clk pointer.
Signed-off-by: Rajendra Nayak <rnayak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
---
drivers/clk/clk.c | 6 ++++++
include/linux/clk-provider.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 0fb39fe..52ef035 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -186,6 +186,12 @@ const char *clk_hw_get_name(const struct clk_hw *hw)
}
EXPORT_SYMBOL_GPL(clk_hw_get_name);
+struct clk *clk_hw_get_clk(const struct clk_hw *hw)
+{
+ return hw->clk;
+}
+EXPORT_SYMBOL_GPL(clk_hw_get_clk);
+
struct clk_hw *__clk_get_hw(struct clk *clk)
{
return !clk ? NULL : clk->core->hw;
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index af59638..37022a9 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -729,6 +729,7 @@ struct clk_hw *clk_hw_register_gpio_mux(struct device *dev, const char *name,
/* helper functions */
const char *__clk_get_name(const struct clk *clk);
const char *clk_hw_get_name(const struct clk_hw *hw);
+struct clk *clk_hw_get_clk(const struct clk_hw *hw);
struct clk_hw *__clk_get_hw(struct clk *clk);
unsigned int clk_hw_get_num_parents(const struct clk_hw *hw);
struct clk_hw *clk_hw_get_parent(const struct clk_hw *hw);
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v5 03/12] mmc: sdhci-msm: add pltfm_data support to get clk-rates from DT
From: Ritesh Harjani @ 2016-11-07 11:21 UTC (permalink / raw)
To: Rob Herring
Cc: Ulf Hansson, linux-mmc@vger.kernel.org, Adrian Hunter, Shawn Lin,
David Brown, Andy Gross, devicetree@vger.kernel.org,
linux-arm-msm, georgi.djakov, alex.lemberg, mateusz.nowak,
Yuliy.Izrailov, asutoshd, David Griego, Sahitya Tummala, venkatg,
Stephen Boyd, Bjorn Andersson, pramod.gurav, Rajendra Nayak
In-Reply-To: <CAL_JsqJbkDX3yAf6EGOcZiN=Fk-cz-7VeQxPK7_YOMyN7Pg0zA@mail.gmail.com>
Hi Rob,
On 10/11/2016 6:01 PM, Rob Herring wrote:
> On Tue, Oct 11, 2016 at 4:06 AM, Ritesh Harjani <riteshh@codeaurora.org> wrote:
>> Hi Rob
>>
>>
>> On 10/11/2016 12:59 AM, Rob Herring wrote:
>>>
>>> On Mon, Oct 10, 2016 at 11:07 AM, Ritesh Harjani <riteshh@codeaurora.org>
>>> wrote:
>>>>
>>>> Hi Rob,
>>>>
>>>> Thanks for review.
>>>>
>>>> On 10/10/2016 6:27 PM, Rob Herring wrote:
>>>>>
>>>>>
>>>>> On Wed, Oct 05, 2016 at 08:10:31PM +0530, Ritesh Harjani wrote:
>>>>>>
>>>>>>
>>>>>> This adds support for sdhc-msm controllers to get supported
>>>>>> clk-rates from DT. sdhci-msm would need it's own set_clock
>>>>>> ops to be implemented. For this, supported clk-rates needs
>>>>>> to be populated in sdhci_msm_pltfm_data.
>>>>>>
>>>>>> Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
>>>>>> ---
>>>>>> .../devicetree/bindings/mmc/sdhci-msm.txt | 1 +
>>>>>> drivers/mmc/host/sdhci-msm.c | 48
>>>>>> ++++++++++++++++++++++
>>>>>> 2 files changed, 49 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
>>>>>> b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
>>>>>> index 485483a..6a83b38 100644
>>>>>> --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
>>>>>> +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
>>>>>> @@ -17,6 +17,7 @@ Required properties:
>>>>>> "iface" - Main peripheral bus clock (PCLK/HCLK - AHB Bus clock)
>>>>>> (required)
>>>>>> "core" - SDC MMC clock (MCLK) (required)
>>>>>> "bus" - SDCC bus voter clock (optional)
>>>>>> +- clk-rates: Array of supported GCC clock frequencies for sdhc, Units
>>>>>> -
>>>>>> Hz.
>>>>>
>>>>>
>>>>>
>>>>> Why can't some combination of assigned-clock-rates and querying the
>>>>> clock provider for rates be used here?
>>>>
>>>>
>>>> From what I understood, assigned-clock-rates would only work for setting
>>>> some default clock rates for certain clocks by calling
>>>> of_clk_set_defaults.
>>>>
>>>> Whereas the requirement here is -
>>>> That since SDHC msm directly controls the clk(core clock) at source, it's
>>>> sdhci-msm driver needs to know the supported clk-rates by the underlying
>>>> platform to configure the nearest floor value supported on this platform
>>>> (when the request arrives from the core layer to switch the clock).
>>>
>>>
>>> Why does clk_round_rate not work for you? That will round down to the
>>> nearest frequency supported.
>>
>> clk_round_rate will round off to nearest supported "ceil" frequency.
>> But we require nearest rounded off "floor" frequency.
>
> Then fix the clk framework to do what you want. This doesn't need to be in DT.
Sure. Discussed with clk driver. Will make the required changes in qcom
clk driver to fix this.
Will soon publish the new series.
>
> Rob
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH] mmc: mmc: Use 500ms as the default generic CMD6 timeout
From: Linus Walleij @ 2016-11-07 10:03 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-mmc@vger.kernel.org, Jaehoon Chung, Adrian Hunter,
Chaotian Jing, Stephen Boyd, stable
In-Reply-To: <1478280753-2482-1-git-send-email-ulf.hansson@linaro.org>
On Fri, Nov 4, 2016 at 6:32 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> In the eMMC 4.51 version of the spec, an EXT_CSD field called
> GENERIC_CMD6_TIME[248] was added. This allows cards to specify the maximum
> time it may need to move out from its busy state, when a CMD6 command has
> been sent.
>
> In cases when the card is compliant to versions < 4.51 of the eMMC spec,
> obviously the core needs to use a fall-back value for this timeout, which
> currently is set to 10 minutes. This value is completely in the wrong range
> and importantly in some cases it causes a card initialization to take more
> than 10 minute to complete.
>
> Earlier this scenario was avoided as the mmc core used CMD13 to poll the
> card, to find out when it stopped signaling busy. Commit 08573eaf1a70
> ("mmc: mmc: do not use CMD13 to get status after speed mode switch")
> changed this behavior.
>
> Instead of reverting that commit, which would cause other issues, let's
> instead start by picking a simple solution for the problem, by using a
> 500ms default generic CMD6 timeout.
>
> The reason for using exactly 500ms, comes from observations that shows it's
> quite common for cards to specify 250ms. 500ms is two times that value so
> likely it should be enough for most cards.
>
> Cc: <stable@vger.kernel.org> # v4.8+
> Fixes: 08573eaf1a70 ("mmc: mmc: do not use CMD13 to get status after speed
> mode switch")
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This fixes my rootfs issue. It still doesn't appear immediately as it did
before, but maybe before was wrong then. (Or we should hammer
a bit with CMD13 and wait for a correct CRC?)
Anyways: things are a lot better now, so:
Tested-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [GIT PULL] DWMMC controller fixes
From: Ulf Hansson @ 2016-11-07 7:56 UTC (permalink / raw)
To: Jaehoon Chung; +Cc: linux-mmc@vger.kernel.org
In-Reply-To: <587f4226-0c21-899b-b16d-3f33d092e382@samsung.com>
On 3 November 2016 at 06:25, Jaehoon Chung <jh80.chung@samsung.com> wrote:
> Dear Ulf,
>
> Could you pull these patches on your fixes branch?
>
> The following changes since commit d1f63f0c81c22ba705fcd149a1fcec37b734d818:
>
> mmc: sdhci-msm: Fix error return code in sdhci_msm_probe() (2016-10-27 09:43:01 +0200)
>
> are available in the git repository at:
>
> https://github.com/jh80chung/dw-mmc.git fixes
>
> for you to fetch changes up to 5c3d7c7ed1e676d7fa1c9222d9a46c5d09b9fe97:
>
> mmc: dw_mmc: add the "reset" as name of reset controller (2016-11-03 14:11:59 +0900)
>
> ----------------------------------------------------------------
> DWMMC core:
> - Add the "reset" as "#reset-names" property for preventing wrong operation.
>
> ----------------------------------------------------------------
> Jaehoon Chung (2):
> Documentation: synopsys-dw-mshc: add binding for reset-names
> mmc: dw_mmc: add the "reset" as name of reset controller
>
> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt | 5 +++++
> drivers/mmc/host/dw_mmc.c | 2 +-
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
>
> Best Regards,
> Jaehoon Chung
Thanks Jaehoon, pulled into fixes - and sorry for the delay!
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH] mmc: sd: Export SD Status via “ssr” device attribute
From: Ulf Hansson @ 2016-11-07 7:45 UTC (permalink / raw)
To: Uri Yanai; +Cc: linux-mmc, Alex Lemberg
In-Reply-To: <CY1PR02MB2089BA24853AFFAB693C6D17E2A50@CY1PR02MB2089.namprd02.prod.outlook.com>
On 5 November 2016 at 16:14, Uri Yanai <Uri.Yanai@sandisk.com> wrote:
> Hi Ulf
> It seems the patch isn't yet merged to kernel mainline.
> Do you know why ?
>
> Thanks
> Uri
It was in my pull request to Linus for 4.9 and I confirmed it's in
there. Please have a second look.
Kind regards
Uffe
>
> -----Original Message-----
> From: Ulf Hansson [mailto:ulf.hansson@linaro.org]
> Sent: Monday, August 22, 2016 4:40 PM
> To: Uri Yanai
> Cc: linux-mmc; Alex Lemberg
> Subject: Re: [PATCH] mmc: sd: Export SD Status via “ssr” device attribute
>
> On 14 August 2016 at 10:46, Uri Yanai <uri.yanai@sandisk.com> wrote:
>> The SD Status register contains several important fields related to
>> the SD Card proprietary features.
>> Those fields may be used by user space applications for vendor
>> specific usage.
>> None of those fields are exported today by the driver to user space.
>> In this patch, we are reading the SD Status register and exporting
>> (using MMC_DEV_ATTR) the SD Status register to the user space.
>>
>> Signed-off-by: Uri Yanai <uri.yanai@sandisk.com>
>
> Thanks, applied for next!
>
> Kind regards
> Uffe
>
>> ---
>> drivers/mmc/core/sd.c | 37 +++++++++++++++++++------------------
>> include/linux/mmc/card.h | 1 +
>> 2 files changed, 20 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c index
>> b95bd24..694d70d 100644
>> --- a/drivers/mmc/core/sd.c
>> +++ b/drivers/mmc/core/sd.c
>> @@ -223,8 +223,7 @@ static int mmc_decode_scr(struct mmc_card *card)
>> static int mmc_read_ssr(struct mmc_card *card) {
>> unsigned int au, es, et, eo;
>> - int err, i;
>> - u32 *ssr;
>> + int i;
>>
>> if (!(card->csd.cmdclass & CCC_APP_SPEC)) {
>> pr_warn("%s: card lacks mandatory SD Status
>> function\n", @@ -232,33 +231,27 @@ static int mmc_read_ssr(struct mmc_card *card)
>> return 0;
>> }
>>
>> - ssr = kmalloc(64, GFP_KERNEL);
>> - if (!ssr)
>> - return -ENOMEM;
>> -
>> - err = mmc_app_sd_status(card, ssr);
>> - if (err) {
>> + if (mmc_app_sd_status(card, card->raw_ssr)) {
>> pr_warn("%s: problem reading SD Status register\n",
>> mmc_hostname(card->host));
>> - err = 0;
>> - goto out;
>> + return 0;
>> }
>>
>> for (i = 0; i < 16; i++)
>> - ssr[i] = be32_to_cpu(ssr[i]);
>> + card->raw_ssr[i] = be32_to_cpu(card->raw_ssr[i]);
>>
>> /*
>> * UNSTUFF_BITS only works with four u32s so we have to offset the
>> * bitfield positions accordingly.
>> */
>> - au = UNSTUFF_BITS(ssr, 428 - 384, 4);
>> + au = UNSTUFF_BITS(card->raw_ssr, 428 - 384, 4);
>> if (au) {
>> if (au <= 9 || card->scr.sda_spec3) {
>> card->ssr.au = sd_au_size[au];
>> - es = UNSTUFF_BITS(ssr, 408 - 384, 16);
>> - et = UNSTUFF_BITS(ssr, 402 - 384, 6);
>> + es = UNSTUFF_BITS(card->raw_ssr, 408 - 384, 16);
>> + et = UNSTUFF_BITS(card->raw_ssr, 402 - 384,
>> + 6);
>> if (es && et) {
>> - eo = UNSTUFF_BITS(ssr, 400 - 384, 2);
>> + eo = UNSTUFF_BITS(card->raw_ssr, 400 -
>> + 384, 2);
>> card->ssr.erase_timeout = (et * 1000) / es;
>> card->ssr.erase_offset = eo * 1000;
>> }
>> @@ -267,9 +260,8 @@ static int mmc_read_ssr(struct mmc_card *card)
>> mmc_hostname(card->host));
>> }
>> }
>> -out:
>> - kfree(ssr);
>> - return err;
>> +
>> + return 0;
>> }
>>
>> /*
>> @@ -666,6 +658,14 @@ MMC_DEV_ATTR(cid, "%08x%08x%08x%08x\n",
>> card->raw_cid[0], card->raw_cid[1], MMC_DEV_ATTR(csd, "%08x%08x%08x%08x\n", card->raw_csd[0], card->raw_csd[1],
>> card->raw_csd[2], card->raw_csd[3]); MMC_DEV_ATTR(scr,
>> "%08x%08x\n", card->raw_scr[0], card->raw_scr[1]);
>> +MMC_DEV_ATTR(ssr,
>> + "%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x\n",
>> + card->raw_ssr[0], card->raw_ssr[1], card->raw_ssr[2],
>> + card->raw_ssr[3], card->raw_ssr[4], card->raw_ssr[5],
>> + card->raw_ssr[6], card->raw_ssr[7], card->raw_ssr[8],
>> + card->raw_ssr[9], card->raw_ssr[10], card->raw_ssr[11],
>> + card->raw_ssr[12], card->raw_ssr[13], card->raw_ssr[14],
>> + card->raw_ssr[15]);
>> MMC_DEV_ATTR(date, "%02d/%04d\n", card->cid.month, card->cid.year);
>> MMC_DEV_ATTR(erase_size, "%u\n", card->erase_size << 9);
>> MMC_DEV_ATTR(preferred_erase_size, "%u\n", card->pref_erase << 9); @@
>> -681,6 +681,7 @@ static struct attribute *sd_std_attrs[] = {
>> &dev_attr_cid.attr,
>> &dev_attr_csd.attr,
>> &dev_attr_scr.attr,
>> + &dev_attr_ssr.attr,
>> &dev_attr_date.attr,
>> &dev_attr_erase_size.attr,
>> &dev_attr_preferred_erase_size.attr,
>> diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h index
>> eb0151b..0968109 100644
>> --- a/include/linux/mmc/card.h
>> +++ b/include/linux/mmc/card.h
>> @@ -290,6 +290,7 @@ struct mmc_card {
>> u32 raw_cid[4]; /* raw card CID */
>> u32 raw_csd[4]; /* raw card CSD */
>> u32 raw_scr[2]; /* raw card SCR */
>> + u32 raw_ssr[16]; /* raw card SSR */
>> struct mmc_cid cid; /* card identification */
>> struct mmc_csd csd; /* card specific */
>> struct mmc_ext_csd ext_csd; /* mmc v4 extended card specific */
>> --
>> 1.9.1
>>
^ permalink raw reply
* Re: [PATCH] mmc: mmc_test: Fix "Commands during non-blocking write" tests
From: Ritesh Harjani @ 2016-11-07 6:10 UTC (permalink / raw)
To: Adrian Hunter, Ulf Hansson; +Cc: linux-mmc
In-Reply-To: <1478259665-13406-1-git-send-email-adrian.hunter@intel.com>
Hi,
On 11/4/2016 5:11 PM, Adrian Hunter wrote:
> mmc_test_check_result_async() requires that struct mmc_async_req is
> contained within struct mmc_test_async_req. Fix the "Commands during
> non-blocking write" tests so that is the case.
Tested this patch on an internal platform. Fixes the issue with mmc_test.
Tested-by: Ritesh Harjani <riteshh@codeaurora.org>
>
> Fixes: 4bbb9aac9a9a ("mmc: mmc_test: Add tests for sending commands during transfer")
> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
> ---
> drivers/mmc/card/mmc_test.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/card/mmc_test.c b/drivers/mmc/card/mmc_test.c
> index 5a8dc5a76e0d..3678220964fe 100644
> --- a/drivers/mmc/card/mmc_test.c
> +++ b/drivers/mmc/card/mmc_test.c
> @@ -2347,7 +2347,7 @@ static int mmc_test_ongoing_transfer(struct mmc_test_card *test,
> struct mmc_test_req *rq = mmc_test_req_alloc();
> struct mmc_host *host = test->card->host;
> struct mmc_test_area *t = &test->area;
> - struct mmc_async_req areq;
> + struct mmc_test_async_req test_areq = { .test = test };
> struct mmc_request *mrq;
> unsigned long timeout;
> bool expired = false;
> @@ -2363,8 +2363,8 @@ static int mmc_test_ongoing_transfer(struct mmc_test_card *test,
> mrq->sbc = &rq->sbc;
> mrq->cap_cmd_during_tfr = true;
>
> - areq.mrq = mrq;
> - areq.err_check = mmc_test_check_result_async;
> + test_areq.areq.mrq = mrq;
> + test_areq.areq.err_check = mmc_test_check_result_async;
>
> mmc_test_prepare_mrq(test, mrq, t->sg, t->sg_len, dev_addr, t->blocks,
> 512, write);
> @@ -2378,7 +2378,7 @@ static int mmc_test_ongoing_transfer(struct mmc_test_card *test,
>
> /* Start ongoing data request */
> if (use_areq) {
> - mmc_start_req(host, &areq, &ret);
> + mmc_start_req(host, &test_areq.areq, &ret);
> if (ret)
> goto out_free;
> } else {
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 10/13] ARM: dts: exynos: replace to "max-frequecy" instead of "clock-freq-min-max"
From: Jaehoon Chung @ 2016-11-07 0:38 UTC (permalink / raw)
To: Krzysztof Kozlowski, Heiko Stuebner
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc, linux-rockchip, ulf.hansson, robh+dt,
shawn.lin
In-Reply-To: <20161104150447.GA4829@kozik-lap>
On 11/05/2016 12:04 AM, Krzysztof Kozlowski wrote:
> On Fri, Nov 04, 2016 at 12:19:49PM +0100, Heiko Stuebner wrote:
>> Hi Jaehoon,
>>
>> Am Freitag, 4. November 2016, 19:21:30 CET schrieb Jaehoon Chung:
>>> On 11/04/2016 03:41 AM, Krzysztof Kozlowski wrote:
>>>> On Thu, Nov 03, 2016 at 03:21:32PM +0900, Jaehoon Chung wrote:
>>>>> In drivers/mmc/core/host.c, there is "max-frequency" property.
>>>>> It should be same behavior. So Use the "max-frequency" instead of
>>>>> "clock-freq-min-max".
>>>>>
>>>>> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
>>>>> ---
>>>>>
>>>>> arch/arm/boot/dts/exynos3250-artik5-eval.dts | 2 +-
>>>>> arch/arm/boot/dts/exynos3250-artik5.dtsi | 2 +-
>>>>> arch/arm/boot/dts/exynos3250-monk.dts | 2 +-
>>>>> arch/arm/boot/dts/exynos3250-rinato.dts | 2 +-
>>>>> 4 files changed, 4 insertions(+), 4 deletions(-)
>>>>
>>>> This looks totally independent to rest of patches so it can be applied
>>>> separately without any functional impact (except lack of minimum
>>>> frequency). Is that correct?
>>>
>>> You're right. I will split the patches. And will resend.
>>> Thanks!
>>
>> I think what Krzysztof was asking was just if he can simply pick up this patch
>> alone, as it does not require any of the previous changes.
>>
>> Same is true for the Rockchip patches I guess, so we could just take them
>> individually into samsung/rockchip dts branches.
>
> Yes, I wanted to get exactly this information. I couldn't find it in
> cover letter.
In drivers/mmc/core/host.c, there already is "max-frequency" property.
It's same functionality with "clock-freq-min-max".
Minimum clock value can be fixed to 100K. because MMC core will check clock value from 400K to 100K.
But max-frequency can be difference.
If we can use "max-frequency" property, we don't need to use "clock-freq-min-max" property anymore.
I will resend the deprecated property instead of removing "clock-freq-min-max".
If you want to pick this, it's possible to pick. Then i will resend the patches without dt patches.
Best Regards,
Jaehoon Chung
>
> Best regards,
> Krzysztof
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
^ permalink raw reply
* Re: [GIT PULL] DWMMC controller fixes
From: Jaehoon Chung @ 2016-11-07 0:33 UTC (permalink / raw)
To: linux-mmc@vger.kernel.org; +Cc: Ulf Hansson
In-Reply-To: <587f4226-0c21-899b-b16d-3f33d092e382@samsung.com>
Hi Ulf,
On 11/03/2016 02:25 PM, Jaehoon Chung wrote:
> Dear Ulf,
>
> Could you pull these patches on your fixes branch?
For Reminding..If there is a problem, let me know.
Best Regards,
Jaehoon Chung
>
> The following changes since commit d1f63f0c81c22ba705fcd149a1fcec37b734d818:
>
> mmc: sdhci-msm: Fix error return code in sdhci_msm_probe() (2016-10-27 09:43:01 +0200)
>
> are available in the git repository at:
>
> https://github.com/jh80chung/dw-mmc.git fixes
>
> for you to fetch changes up to 5c3d7c7ed1e676d7fa1c9222d9a46c5d09b9fe97:
>
> mmc: dw_mmc: add the "reset" as name of reset controller (2016-11-03 14:11:59 +0900)
>
> ----------------------------------------------------------------
> DWMMC core:
> - Add the "reset" as "#reset-names" property for preventing wrong operation.
>
> ----------------------------------------------------------------
> Jaehoon Chung (2):
> Documentation: synopsys-dw-mshc: add binding for reset-names
> mmc: dw_mmc: add the "reset" as name of reset controller
>
> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt | 5 +++++
> drivers/mmc/host/dw_mmc.c | 2 +-
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
>
> Best Regards,
> Jaehoon Chung
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
^ permalink raw reply
* [PATCH v3] mmc: mxs: Initialize the spinlock prior to using it
From: Fabio Estevam @ 2016-11-05 19:45 UTC (permalink / raw)
To: ulf.hansson; +Cc: kernel, marex, stefan.wahren, linux-mmc, Fabio Estevam
From: Fabio Estevam <fabio.estevam@nxp.com>
An interrupt may occur right after devm_request_irq() is called and
prior to the spinlock initialization, leading to a kernel oops,
as the interrupt handler uses the spinlock.
In order to prevent this problem, move the spinlock initialization
prior to requesting the interrupts.
Fixes: e4243f13d10e (mmc: mxs-mmc: add mmc host driver for i.MX23/28)
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Marek Vasut <marex@denx.de>
---
Changes since v2:
- Add a Fixes tag as suggested by Stefan
Changes since v1:
- Make it a standalone patch instead of patch series
- Cc stable as suggested by Stefan
drivers/mmc/host/mxs-mmc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/mxs-mmc.c b/drivers/mmc/host/mxs-mmc.c
index d839147..44ecebd 100644
--- a/drivers/mmc/host/mxs-mmc.c
+++ b/drivers/mmc/host/mxs-mmc.c
@@ -661,13 +661,13 @@ static int mxs_mmc_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, mmc);
+ spin_lock_init(&host->lock);
+
ret = devm_request_irq(&pdev->dev, irq_err, mxs_mmc_irq_handler, 0,
dev_name(&pdev->dev), host);
if (ret)
goto out_free_dma;
- spin_lock_init(&host->lock);
-
ret = mmc_add_host(mmc);
if (ret)
goto out_free_dma;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2] mmc: mxs: Initialize the spinlock prior to using it
From: Stefan Wahren @ 2016-11-05 19:42 UTC (permalink / raw)
To: Fabio Estevam, ulf.hansson
Cc: kernel, linux-mmc, marex, Fabio Estevam, stable
In-Reply-To: <1478373803-31815-1-git-send-email-festevam@gmail.com>
Hi Fabio,
> Fabio Estevam <festevam@gmail.com> hat am 5. November 2016 um 20:23
> geschrieben:
>
>
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> An interrupt may occur right after devm_request_irq() is called and
> prior to the spinlock initialization, leading to a kernel oops,
> as the interrupt handler uses the spinlock.
>
> In order to prevent this problem, move the spinlock initialization
> prior to requesting the interrupts.
>
> Cc: <stable@vger.kernel.org>
my intention was to add something like this:
Fixes: e4243f13d10e (mmc: mxs-mmc: add mmc host driver for i.MX23/28)
because it's a bugfix. I wasn't absolutly sure it's a stable candidate.
Thanks
Stefan
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> Reviewed-by: Marek Vasut <marex@denx.de>
> ---
> Changes since v1:
> - Make it a standalone patch instead of patch series
> - Cc stable as suggested by Stefan
>
> drivers/mmc/host/mxs-mmc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/mxs-mmc.c b/drivers/mmc/host/mxs-mmc.c
> index d839147..44ecebd 100644
> --- a/drivers/mmc/host/mxs-mmc.c
> +++ b/drivers/mmc/host/mxs-mmc.c
> @@ -661,13 +661,13 @@ static int mxs_mmc_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, mmc);
>
> + spin_lock_init(&host->lock);
> +
> ret = devm_request_irq(&pdev->dev, irq_err, mxs_mmc_irq_handler, 0,
> dev_name(&pdev->dev), host);
> if (ret)
> goto out_free_dma;
>
> - spin_lock_init(&host->lock);
> -
> ret = mmc_add_host(mmc);
> if (ret)
> goto out_free_dma;
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v2] mmc: mxs: Initialize the spinlock prior to using it
From: Fabio Estevam @ 2016-11-05 19:23 UTC (permalink / raw)
To: ulf.hansson
Cc: kernel, marex, stefan.wahren, linux-mmc, Fabio Estevam, stable
From: Fabio Estevam <fabio.estevam@nxp.com>
An interrupt may occur right after devm_request_irq() is called and
prior to the spinlock initialization, leading to a kernel oops,
as the interrupt handler uses the spinlock.
In order to prevent this problem, move the spinlock initialization
prior to requesting the interrupts.
Cc: <stable@vger.kernel.org>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Marek Vasut <marex@denx.de>
---
Changes since v1:
- Make it a standalone patch instead of patch series
- Cc stable as suggested by Stefan
drivers/mmc/host/mxs-mmc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/mxs-mmc.c b/drivers/mmc/host/mxs-mmc.c
index d839147..44ecebd 100644
--- a/drivers/mmc/host/mxs-mmc.c
+++ b/drivers/mmc/host/mxs-mmc.c
@@ -661,13 +661,13 @@ static int mxs_mmc_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, mmc);
+ spin_lock_init(&host->lock);
+
ret = devm_request_irq(&pdev->dev, irq_err, mxs_mmc_irq_handler, 0,
dev_name(&pdev->dev), host);
if (ret)
goto out_free_dma;
- spin_lock_init(&host->lock);
-
ret = mmc_add_host(mmc);
if (ret)
goto out_free_dma;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 2/2] mmc: mxs: Use the spinlock irq variants
From: Fabio Estevam @ 2016-11-05 19:19 UTC (permalink / raw)
To: Jisheng Zhang
Cc: Ulf Hansson, Sascha Hauer, linux-mmc@vger.kernel.org,
Stefan Wahren, Marek Vasut, Fabio Estevam
In-Reply-To: <CAOMZO5D3YqgB7iUuayOw8tX236Usy1S9kOH_XQZ+JdzVyCpmSQ@mail.gmail.com>
Hi Jisheng,
On Sat, Nov 5, 2016 at 4:56 PM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Jisheng,
>
> On Fri, Oct 28, 2016 at 9:49 AM, Jisheng Zhang <jszhang@marvell.com> wrote:
>
>> This is not the key. The key here is:
>>
>> compared with the non-irq version, the irq-version spin lock does one extra
>> work: disable the local interrupts. But since we are in interrupt handler,
>> the local irq is already disabled, so there's no need for the irq-versions.
>>
>> I'm not sure I understand the situation, comments are welcome.
>
> Quoting http://www.xml.com/ldd/chapter/book/ch09.html:
>
> "Many users of spinlocks stick to spin_lock and spin_unlock. If you
> are using spinlocks in interrupt handlers, however, you must use the
> IRQ-disabling versions (usually spin_lock_irqsave and
> spin_unlock_irqsave) in the noninterrupt code. To do otherwise is to
> invite a deadlock situation.
Ah, after re-reading it several times I agree with you now. It is the
noninterrupt code that needs the irq spinlock versions.
I will resend the series without this patch.
Thanks
^ permalink raw reply
* Re: [PATCH 2/2] mmc: mxs: Use the spinlock irq variants
From: Fabio Estevam @ 2016-11-05 18:56 UTC (permalink / raw)
To: Jisheng Zhang
Cc: Ulf Hansson, Sascha Hauer, linux-mmc@vger.kernel.org,
Stefan Wahren, Marek Vasut, Fabio Estevam
In-Reply-To: <20161028194947.463870ab@xhacker>
Hi Jisheng,
On Fri, Oct 28, 2016 at 9:49 AM, Jisheng Zhang <jszhang@marvell.com> wrote:
> This is not the key. The key here is:
>
> compared with the non-irq version, the irq-version spin lock does one extra
> work: disable the local interrupts. But since we are in interrupt handler,
> the local irq is already disabled, so there's no need for the irq-versions.
>
> I'm not sure I understand the situation, comments are welcome.
Quoting http://www.xml.com/ldd/chapter/book/ch09.html:
"Many users of spinlocks stick to spin_lock and spin_unlock. If you
are using spinlocks in interrupt handlers, however, you must use the
IRQ-disabling versions (usually spin_lock_irqsave and
spin_unlock_irqsave) in the noninterrupt code. To do otherwise is to
invite a deadlock situation.
It is worth considering an example here. Assume that your driver is
running in its read method, and it obtains a lock with spin_lock.
While the read method is holding the lock, your device interrupts, and
your interrupt handler is executed on the same processor. If it
attempts to use the same lock, it will go into a busy-wait loop, since
your read method already holds the lock. But, since the interrupt
routine has preempted that method, the lock will never be released and
the processor deadlocks, which is probably not what you wanted.
This problem can be avoided by using spin_lock_irqsave to disable
interrupts on the local processor while the lock is held. When in
doubt, use the _irqsave versions of the primitives and you will not
need to worry about deadlocks. Remember, though, that the flags value
from spin_lock_irqsave must not be passed to other functions."
And as I mentioned before Documentation/locking/spinlocks.txt is very
clear about the need of using spin_lock_irqsave inside interrupt
handlers.
Feel free to submit a patch to Documentation/locking/spinlocks.txt if
you think this is incorrect.
Thanks
^ permalink raw reply
* RE: [PATCH] mmc: sd: Export SD Status via “ssr” device attribute
From: Uri Yanai @ 2016-11-05 15:14 UTC (permalink / raw)
To: Ulf Hansson; +Cc: linux-mmc, Alex Lemberg
In-Reply-To: <CAPDyKFoJS-darh9D6mhmcOqw7FSMU3f6RJHYO6Z4vqMUqUQUHg@mail.gmail.com>
Hi Ulf
It seems the patch isn't yet merged to kernel mainline.
Do you know why ?
Thanks
Uri
-----Original Message-----
From: Ulf Hansson [mailto:ulf.hansson@linaro.org]
Sent: Monday, August 22, 2016 4:40 PM
To: Uri Yanai
Cc: linux-mmc; Alex Lemberg
Subject: Re: [PATCH] mmc: sd: Export SD Status via “ssr” device attribute
On 14 August 2016 at 10:46, Uri Yanai <uri.yanai@sandisk.com> wrote:
> The SD Status register contains several important fields related to
> the SD Card proprietary features.
> Those fields may be used by user space applications for vendor
> specific usage.
> None of those fields are exported today by the driver to user space.
> In this patch, we are reading the SD Status register and exporting
> (using MMC_DEV_ATTR) the SD Status register to the user space.
>
> Signed-off-by: Uri Yanai <uri.yanai@sandisk.com>
Thanks, applied for next!
Kind regards
Uffe
> ---
> drivers/mmc/core/sd.c | 37 +++++++++++++++++++------------------
> include/linux/mmc/card.h | 1 +
> 2 files changed, 20 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c index
> b95bd24..694d70d 100644
> --- a/drivers/mmc/core/sd.c
> +++ b/drivers/mmc/core/sd.c
> @@ -223,8 +223,7 @@ static int mmc_decode_scr(struct mmc_card *card)
> static int mmc_read_ssr(struct mmc_card *card) {
> unsigned int au, es, et, eo;
> - int err, i;
> - u32 *ssr;
> + int i;
>
> if (!(card->csd.cmdclass & CCC_APP_SPEC)) {
> pr_warn("%s: card lacks mandatory SD Status
> function\n", @@ -232,33 +231,27 @@ static int mmc_read_ssr(struct mmc_card *card)
> return 0;
> }
>
> - ssr = kmalloc(64, GFP_KERNEL);
> - if (!ssr)
> - return -ENOMEM;
> -
> - err = mmc_app_sd_status(card, ssr);
> - if (err) {
> + if (mmc_app_sd_status(card, card->raw_ssr)) {
> pr_warn("%s: problem reading SD Status register\n",
> mmc_hostname(card->host));
> - err = 0;
> - goto out;
> + return 0;
> }
>
> for (i = 0; i < 16; i++)
> - ssr[i] = be32_to_cpu(ssr[i]);
> + card->raw_ssr[i] = be32_to_cpu(card->raw_ssr[i]);
>
> /*
> * UNSTUFF_BITS only works with four u32s so we have to offset the
> * bitfield positions accordingly.
> */
> - au = UNSTUFF_BITS(ssr, 428 - 384, 4);
> + au = UNSTUFF_BITS(card->raw_ssr, 428 - 384, 4);
> if (au) {
> if (au <= 9 || card->scr.sda_spec3) {
> card->ssr.au = sd_au_size[au];
> - es = UNSTUFF_BITS(ssr, 408 - 384, 16);
> - et = UNSTUFF_BITS(ssr, 402 - 384, 6);
> + es = UNSTUFF_BITS(card->raw_ssr, 408 - 384, 16);
> + et = UNSTUFF_BITS(card->raw_ssr, 402 - 384,
> + 6);
> if (es && et) {
> - eo = UNSTUFF_BITS(ssr, 400 - 384, 2);
> + eo = UNSTUFF_BITS(card->raw_ssr, 400 -
> + 384, 2);
> card->ssr.erase_timeout = (et * 1000) / es;
> card->ssr.erase_offset = eo * 1000;
> }
> @@ -267,9 +260,8 @@ static int mmc_read_ssr(struct mmc_card *card)
> mmc_hostname(card->host));
> }
> }
> -out:
> - kfree(ssr);
> - return err;
> +
> + return 0;
> }
>
> /*
> @@ -666,6 +658,14 @@ MMC_DEV_ATTR(cid, "%08x%08x%08x%08x\n",
> card->raw_cid[0], card->raw_cid[1], MMC_DEV_ATTR(csd, "%08x%08x%08x%08x\n", card->raw_csd[0], card->raw_csd[1],
> card->raw_csd[2], card->raw_csd[3]); MMC_DEV_ATTR(scr,
> "%08x%08x\n", card->raw_scr[0], card->raw_scr[1]);
> +MMC_DEV_ATTR(ssr,
> + "%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x\n",
> + card->raw_ssr[0], card->raw_ssr[1], card->raw_ssr[2],
> + card->raw_ssr[3], card->raw_ssr[4], card->raw_ssr[5],
> + card->raw_ssr[6], card->raw_ssr[7], card->raw_ssr[8],
> + card->raw_ssr[9], card->raw_ssr[10], card->raw_ssr[11],
> + card->raw_ssr[12], card->raw_ssr[13], card->raw_ssr[14],
> + card->raw_ssr[15]);
> MMC_DEV_ATTR(date, "%02d/%04d\n", card->cid.month, card->cid.year);
> MMC_DEV_ATTR(erase_size, "%u\n", card->erase_size << 9);
> MMC_DEV_ATTR(preferred_erase_size, "%u\n", card->pref_erase << 9); @@
> -681,6 +681,7 @@ static struct attribute *sd_std_attrs[] = {
> &dev_attr_cid.attr,
> &dev_attr_csd.attr,
> &dev_attr_scr.attr,
> + &dev_attr_ssr.attr,
> &dev_attr_date.attr,
> &dev_attr_erase_size.attr,
> &dev_attr_preferred_erase_size.attr,
> diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h index
> eb0151b..0968109 100644
> --- a/include/linux/mmc/card.h
> +++ b/include/linux/mmc/card.h
> @@ -290,6 +290,7 @@ struct mmc_card {
> u32 raw_cid[4]; /* raw card CID */
> u32 raw_csd[4]; /* raw card CSD */
> u32 raw_scr[2]; /* raw card SCR */
> + u32 raw_ssr[16]; /* raw card SSR */
> struct mmc_cid cid; /* card identification */
> struct mmc_csd csd; /* card specific */
> struct mmc_ext_csd ext_csd; /* mmc v4 extended card specific */
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH] mmc: mmc: Use 500ms as the default generic CMD6 timeout
From: Stephen Boyd @ 2016-11-04 20:13 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-mmc, Jaehoon Chung, Adrian Hunter, Linus Walleij,
Chaotian Jing, stable
In-Reply-To: <1478280753-2482-1-git-send-email-ulf.hansson@linaro.org>
On 11/04, Ulf Hansson wrote:
> In the eMMC 4.51 version of the spec, an EXT_CSD field called
> GENERIC_CMD6_TIME[248] was added. This allows cards to specify the maximum
> time it may need to move out from its busy state, when a CMD6 command has
> been sent.
>
> In cases when the card is compliant to versions < 4.51 of the eMMC spec,
> obviously the core needs to use a fall-back value for this timeout, which
> currently is set to 10 minutes. This value is completely in the wrong range
> and importantly in some cases it causes a card initialization to take more
> than 10 minute to complete.
>
> Earlier this scenario was avoided as the mmc core used CMD13 to poll the
> card, to find out when it stopped signaling busy. Commit 08573eaf1a70
> ("mmc: mmc: do not use CMD13 to get status after speed mode switch")
> changed this behavior.
>
> Instead of reverting that commit, which would cause other issues, let's
> instead start by picking a simple solution for the problem, by using a
> 500ms default generic CMD6 timeout.
>
> The reason for using exactly 500ms, comes from observations that shows it's
> quite common for cards to specify 250ms. 500ms is two times that value so
> likely it should be enough for most cards.
>
> Cc: <stable@vger.kernel.org> # v4.8+
> Fixes: 08573eaf1a70 ("mmc: mmc: do not use CMD13 to get status after speed
> mode switch")
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The 10 minute delay goes away and I see the card almost instantly
on my msm8960-cdp. I smoke tested on a couple other platforms
that weren't experiencing the problem and they seems fine too.
Tested-by: Stephen Boyd <sboyd@codeaurora.org>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [GIT PULL] MMC fixes for v.4.9 rc4
From: Ulf Hansson @ 2016-11-04 17:45 UTC (permalink / raw)
To: Linus, linux-kernel@vger.kernel.org, linux-mmc
Cc: Jaehoon Chung, Adrian Hunter
Hi Linus,
Here are some mmc fixes intended for v4.9 rc4. They are based on v4.9-rc2.
Details are as usual found in the signed tag. Please pull this in!
Kind regards
Ulf Hansson
The following changes since commit 07d9a380680d1c0eb51ef87ff2eab5c994949e69:
Linux 4.9-rc2 (2016-10-23 17:10:14 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git tags/mmc-v4.9-rc2
for you to fetch changes up to d1f63f0c81c22ba705fcd149a1fcec37b734d818:
mmc: sdhci-msm: Fix error return code in sdhci_msm_probe()
(2016-10-27 09:43:01 +0200)
----------------------------------------------------------------
MMC host:
- sdhci-msm: Fix error path in probe
- dw_mmc-pltfm: Avoid NULL pointer dereference
----------------------------------------------------------------
Jaehoon Chung (1):
mmc: dw_mmc-pltfm: fix the potential NULL pointer dereference
Wei Yongjun (1):
mmc: sdhci-msm: Fix error return code in sdhci_msm_probe()
drivers/mmc/host/dw_mmc-pltfm.c | 5 +++--
drivers/mmc/host/sdhci-msm.c | 1 +
2 files changed, 4 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH] mmc: mmc: Use 500ms as the default generic CMD6 timeout
From: Ulf Hansson @ 2016-11-04 17:32 UTC (permalink / raw)
To: linux-mmc, Ulf Hansson
Cc: Jaehoon Chung, Adrian Hunter, Linus Walleij, Chaotian Jing,
Stephen Boyd, stable
In the eMMC 4.51 version of the spec, an EXT_CSD field called
GENERIC_CMD6_TIME[248] was added. This allows cards to specify the maximum
time it may need to move out from its busy state, when a CMD6 command has
been sent.
In cases when the card is compliant to versions < 4.51 of the eMMC spec,
obviously the core needs to use a fall-back value for this timeout, which
currently is set to 10 minutes. This value is completely in the wrong range
and importantly in some cases it causes a card initialization to take more
than 10 minute to complete.
Earlier this scenario was avoided as the mmc core used CMD13 to poll the
card, to find out when it stopped signaling busy. Commit 08573eaf1a70
("mmc: mmc: do not use CMD13 to get status after speed mode switch")
changed this behavior.
Instead of reverting that commit, which would cause other issues, let's
instead start by picking a simple solution for the problem, by using a
500ms default generic CMD6 timeout.
The reason for using exactly 500ms, comes from observations that shows it's
quite common for cards to specify 250ms. 500ms is two times that value so
likely it should be enough for most cards.
Cc: <stable@vger.kernel.org> # v4.8+
Fixes: 08573eaf1a70 ("mmc: mmc: do not use CMD13 to get status after speed
mode switch")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/mmc/core/mmc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index e811bd9..9355366 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -26,6 +26,8 @@
#include "mmc_ops.h"
#include "sd_ops.h"
+#define DEFAULT_CMD6_TIMEOUT_MS 500
+
static const unsigned int tran_exp[] = {
10000, 100000, 1000000, 10000000,
0, 0, 0, 0
@@ -571,6 +573,7 @@ static int mmc_decode_ext_csd(struct mmc_card *card, u8 *ext_csd)
card->erased_byte = 0x0;
/* eMMC v4.5 or later */
+ card->ext_csd.generic_cmd6_time = DEFAULT_CMD6_TIMEOUT_MS;
if (card->ext_csd.rev >= 6) {
card->ext_csd.feature_support |= MMC_DISCARD_FEATURE;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 10/13] ARM: dts: exynos: replace to "max-frequecy" instead of "clock-freq-min-max"
From: Krzysztof Kozlowski @ 2016-11-04 15:04 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Jaehoon Chung, Krzysztof Kozlowski, linux-mmc, devicetree,
linux-kernel, linux-arm-kernel, linux-samsung-soc, linux-rockchip,
ulf.hansson, robh+dt, shawn.lin
In-Reply-To: <4066252.a1W9ejEKHX@phil>
On Fri, Nov 04, 2016 at 12:19:49PM +0100, Heiko Stuebner wrote:
> Hi Jaehoon,
>
> Am Freitag, 4. November 2016, 19:21:30 CET schrieb Jaehoon Chung:
> > On 11/04/2016 03:41 AM, Krzysztof Kozlowski wrote:
> > > On Thu, Nov 03, 2016 at 03:21:32PM +0900, Jaehoon Chung wrote:
> > >> In drivers/mmc/core/host.c, there is "max-frequency" property.
> > >> It should be same behavior. So Use the "max-frequency" instead of
> > >> "clock-freq-min-max".
> > >>
> > >> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
> > >> ---
> > >>
> > >> arch/arm/boot/dts/exynos3250-artik5-eval.dts | 2 +-
> > >> arch/arm/boot/dts/exynos3250-artik5.dtsi | 2 +-
> > >> arch/arm/boot/dts/exynos3250-monk.dts | 2 +-
> > >> arch/arm/boot/dts/exynos3250-rinato.dts | 2 +-
> > >> 4 files changed, 4 insertions(+), 4 deletions(-)
> > >
> > > This looks totally independent to rest of patches so it can be applied
> > > separately without any functional impact (except lack of minimum
> > > frequency). Is that correct?
> >
> > You're right. I will split the patches. And will resend.
> > Thanks!
>
> I think what Krzysztof was asking was just if he can simply pick up this patch
> alone, as it does not require any of the previous changes.
>
> Same is true for the Rockchip patches I guess, so we could just take them
> individually into samsung/rockchip dts branches.
Yes, I wanted to get exactly this information. I couldn't find it in
cover letter.
Best regards,
Krzysztof
^ permalink raw reply
* Re: sd card not working on intel compute stick STK1AW32SC
From: Giacomo Comes @ 2016-11-04 13:15 UTC (permalink / raw)
To: Giacomo Comes; +Cc: linux-mmc
In-Reply-To: <20161101032259.GA12857@monopoli.naic.edu>
Hi,
apparently this in not the correct place to report the
mmc issue I'm having. Could at least anybody tell me
where I can find somebody who can investigate the problem?
Giacomo
On Mon, Oct 31, 2016 at 11:22:59PM -0400, Giacomo Comes wrote:
> I have a couple of cherryview PC.
> One is a Acer Aspire R11 and the other is a
> Intel compute stick STK1AW32SC
> On the Acer Aspire, the mmc card reader works ok,
> but on the compute stick it doesn't.
> I'm running kernel 4.9rc3 and
> when I insert a mmc card I see this message in the journal:
> mmc1: error -84 whilst initialising SD card
> whith another card instead I got this error message:
> mmc1: card never left bust state
> mmc1: error -110 whilst initialising SD card
> Both sd cards work ok on other linux PC.
>
> Can this be fixed?
>
> Giacomo
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH V6 13/25] mmc: core: Do not prepare a new request twice
From: Adrian Hunter @ 2016-11-04 12:07 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-mmc, Alex Lemberg, Mateusz Nowak, Yuliy Izrailov,
Jaehoon Chung, Dong Aisheng, Das Asutosh, Zhangfei Gao,
Dorfman Konstantin, David Griego, Sahitya Tummala, Harjani Ritesh,
Venu Byravarasu
In-Reply-To: <1477298260-5064-14-git-send-email-adrian.hunter@intel.com>
mmc_start_req() assumes it is never called with the new request already
prepared. That is true if the queue consists of only 2 requests, but is not
true for a longer queue. e.g. mmc_start_req() has a current and previous
request but still exits to queue a new request if the queue size is
greater than 2. In that case, when mmc_start_req() is called again, the
current request will have been prepared already. Fix by flagging if the
request has been prepared.
That also means ensuring that struct mmc_async_req is always initialized
to zero, which wasn't the case in mmc_test.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
---
Changes in V6:
Added mmc_test change
drivers/mmc/card/mmc_test.c | 8 ++++----
drivers/mmc/core/core.c | 12 +++++++++---
include/linux/mmc/host.h | 1 +
3 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/card/mmc_test.c b/drivers/mmc/card/mmc_test.c
index 0a2a15150360..89909772e46a 100644
--- a/drivers/mmc/card/mmc_test.c
+++ b/drivers/mmc/card/mmc_test.c
@@ -813,16 +813,16 @@ static int mmc_test_nonblock_transfer(struct mmc_test_card *test,
struct mmc_command stop2;
struct mmc_data data2;
- struct mmc_test_async_req test_areq[2];
+ struct mmc_test_async_req test_areq[2] = {
+ { .test = test },
+ { .test = test },
+ };
struct mmc_async_req *done_areq;
struct mmc_async_req *cur_areq = &test_areq[0].areq;
struct mmc_async_req *other_areq = &test_areq[1].areq;
int i;
int ret;
- test_areq[0].test = test;
- test_areq[1].test = test;
-
mmc_test_nonblock_reset(&mrq1, &cmd1, &stop1, &data1);
mmc_test_nonblock_reset(&mrq2, &cmd2, &stop2, &data2);
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 36b727feecac..8f1b42177777 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -660,8 +660,10 @@ struct mmc_async_req *mmc_start_req(struct mmc_host *host,
struct mmc_async_req *data = host->areq;
/* Prepare a new request */
- if (areq)
+ if (areq && !areq->pre_req_done) {
+ areq->pre_req_done = true;
mmc_pre_req(host, areq->mrq, !host->areq);
+ }
if (host->areq) {
err = mmc_wait_for_data_req_done(host, host->areq->mrq, areq);
@@ -697,12 +699,16 @@ struct mmc_async_req *mmc_start_req(struct mmc_host *host,
if (!err && areq)
start_err = __mmc_start_data_req(host, areq->mrq);
- if (host->areq)
+ if (host->areq) {
+ host->areq->pre_req_done = false;
mmc_post_req(host, host->areq->mrq, 0);
+ }
/* Cancel a prepared request if it was not started. */
- if ((err || start_err) && areq)
+ if ((err || start_err) && areq) {
+ areq->pre_req_done = false;
mmc_post_req(host, areq->mrq, -EINVAL);
+ }
if (err)
host->areq = NULL;
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 3386e10480f7..9fb00b7c54a1 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -174,6 +174,7 @@ struct mmc_async_req {
* Returns 0 if success otherwise non zero.
*/
int (*err_check) (struct mmc_card *, struct mmc_async_req *);
+ bool pre_req_done;
};
/**
--
1.9.1
^ permalink raw reply related
* [PATCH] mmc: mmc_test: Fix "Commands during non-blocking write" tests
From: Adrian Hunter @ 2016-11-04 11:41 UTC (permalink / raw)
To: Ulf Hansson; +Cc: linux-mmc, Harjani Ritesh
mmc_test_check_result_async() requires that struct mmc_async_req is
contained within struct mmc_test_async_req. Fix the "Commands during
non-blocking write" tests so that is the case.
Fixes: 4bbb9aac9a9a ("mmc: mmc_test: Add tests for sending commands during transfer")
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
---
drivers/mmc/card/mmc_test.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/card/mmc_test.c b/drivers/mmc/card/mmc_test.c
index 5a8dc5a76e0d..3678220964fe 100644
--- a/drivers/mmc/card/mmc_test.c
+++ b/drivers/mmc/card/mmc_test.c
@@ -2347,7 +2347,7 @@ static int mmc_test_ongoing_transfer(struct mmc_test_card *test,
struct mmc_test_req *rq = mmc_test_req_alloc();
struct mmc_host *host = test->card->host;
struct mmc_test_area *t = &test->area;
- struct mmc_async_req areq;
+ struct mmc_test_async_req test_areq = { .test = test };
struct mmc_request *mrq;
unsigned long timeout;
bool expired = false;
@@ -2363,8 +2363,8 @@ static int mmc_test_ongoing_transfer(struct mmc_test_card *test,
mrq->sbc = &rq->sbc;
mrq->cap_cmd_during_tfr = true;
- areq.mrq = mrq;
- areq.err_check = mmc_test_check_result_async;
+ test_areq.areq.mrq = mrq;
+ test_areq.areq.err_check = mmc_test_check_result_async;
mmc_test_prepare_mrq(test, mrq, t->sg, t->sg_len, dev_addr, t->blocks,
512, write);
@@ -2378,7 +2378,7 @@ static int mmc_test_ongoing_transfer(struct mmc_test_card *test,
/* Start ongoing data request */
if (use_areq) {
- mmc_start_req(host, &areq, &ret);
+ mmc_start_req(host, &test_areq.areq, &ret);
if (ret)
goto out_free;
} else {
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 0/10] mmc: Add support to Marvell Xenon SD Host Controller
From: Gregory CLEMENT @ 2016-11-04 11:20 UTC (permalink / raw)
To: Ulf Hansson
Cc: Adrian Hunter, linux-mmc-u79uwXL29TY76Z2rM5mHXA, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA, Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Ziji Hu,
Jack(SH) Zhu, Jimmy Xu, Jisheng Zhang, Nadav Haklai, Ryan Gao,
Doug Jones, Shiwu Zhang, Victor Gu, Wei(SOCP) Liu, Wilson Ding,
Xueping Liu, Hilbert Zhang <zzh>
In-Reply-To: <cover.86006f271b60cf7c0b4c5a51762a9dacca4c4718.1477911954.git-series.gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hi,
On lun., oct. 31 2016, Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Hello,
>
> This the second version of the series adding support for the SDHCI
> Xenon controller. It can be currently found on the Armada 37xx and the
> Armada 7K/8K but will be also used in more Marvell SoC (and not only
> the mvebu ones actually).
>
> Some of the remarks had been taking into account since the first
> version, according to Ziji Hu, here are the following chcanges:
> "Changes in V2:
> rebase on v4.9-rc2.
> Re-write Xenon bindings. Ajust Xenon DT property naming.
> Add a new DT property to indicate eMMC card type, instead of using
> variable card_candidate.
> Clear quirks SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 in Xenon platform data
> Add support to HS400 retuning."
>
> I think the main open point which remains is about issuing commands
> from the ->set_ios() callback (in patch 7).
> Ulf, could you comment about it?
A few comments:
- I forgot to add the v2 prefix on the series I hope it won't be too
annoying, if needed I can re-post the series with the correct title.
- I also forgot to add my Reviewed-by flag on the 7 first patches, I
will add them back on the v3.
- For the ones who want to get the series using git here is the place
you can get it here:
repository: git-9UaJU3cA/F/QT0dZR+AlfA@public.gmane.org:MISL-EBU-System-SW/mainline-public.git
branch: sdhci-xenon-v2
Thanks,
Gregory
>
> Thanks,
>
> Gregory
>
> Gregory CLEMENT (3):
> arm64: dts: marvell: add eMMC support for Armada 37xx
> arm64: dts: marvell: add sdhci support for Armada 7K/8K
> arm64: configs: enable SDHCI driver for Xenon
>
> Ziji Hu (7):
> mmc: sdhci: Export sdhci_set_ios() from sdhci.c
> mmc: sdhci: Export sdhci_start_signal_voltage_switch() in sdhci.c
> mmc: sdhci: Export sdhci_execute_tuning() in sdhci.c
> MAINTAINERS: add entry for Marvell Xenon MMC Host Controller drivers
> dt: bindings: Add bindings for Marvell Xenon SD Host Controller
> mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality
> mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC
>
> Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt | 161 +-
> MAINTAINERS | 7 +-
> arch/arm64/boot/dts/marvell/armada-3720-db.dts | 8 +-
> arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 11 +-
> arch/arm64/boot/dts/marvell/armada-7040-db.dts | 8 +-
> arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 9 +-
> arch/arm64/configs/defconfig | 1 +-
> drivers/mmc/host/Kconfig | 9 +-
> drivers/mmc/host/Makefile | 3 +-
> drivers/mmc/host/sdhci-xenon-phy.c | 1181 +++++++-
> drivers/mmc/host/sdhci-xenon-phy.h | 157 +-
> drivers/mmc/host/sdhci-xenon.c | 598 ++++-
> drivers/mmc/host/sdhci-xenon.h | 159 +-
> drivers/mmc/host/sdhci.c | 11 +-
> drivers/mmc/host/sdhci.h | 4 +-
> 15 files changed, 2323 insertions(+), 4 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
> create mode 100644 drivers/mmc/host/sdhci-xenon-phy.c
> create mode 100644 drivers/mmc/host/sdhci-xenon-phy.h
> create mode 100644 drivers/mmc/host/sdhci-xenon.c
> create mode 100644 drivers/mmc/host/sdhci-xenon.h
>
> base-commit: 9fe68cad6e74967b88d0c6aeca7d9cd6b6e91942
> --
> git-series 0.8.10
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 10/13] ARM: dts: exynos: replace to "max-frequecy" instead of "clock-freq-min-max"
From: Heiko Stuebner @ 2016-11-04 11:19 UTC (permalink / raw)
To: Jaehoon Chung
Cc: Krzysztof Kozlowski, linux-mmc, devicetree, linux-kernel,
linux-arm-kernel, linux-samsung-soc, linux-rockchip, ulf.hansson,
robh+dt, shawn.lin
In-Reply-To: <ecf4fac2-0ab7-d4c4-69e3-d498ee5b601c@samsung.com>
Hi Jaehoon,
Am Freitag, 4. November 2016, 19:21:30 CET schrieb Jaehoon Chung:
> On 11/04/2016 03:41 AM, Krzysztof Kozlowski wrote:
> > On Thu, Nov 03, 2016 at 03:21:32PM +0900, Jaehoon Chung wrote:
> >> In drivers/mmc/core/host.c, there is "max-frequency" property.
> >> It should be same behavior. So Use the "max-frequency" instead of
> >> "clock-freq-min-max".
> >>
> >> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
> >> ---
> >>
> >> arch/arm/boot/dts/exynos3250-artik5-eval.dts | 2 +-
> >> arch/arm/boot/dts/exynos3250-artik5.dtsi | 2 +-
> >> arch/arm/boot/dts/exynos3250-monk.dts | 2 +-
> >> arch/arm/boot/dts/exynos3250-rinato.dts | 2 +-
> >> 4 files changed, 4 insertions(+), 4 deletions(-)
> >
> > This looks totally independent to rest of patches so it can be applied
> > separately without any functional impact (except lack of minimum
> > frequency). Is that correct?
>
> You're right. I will split the patches. And will resend.
> Thanks!
I think what Krzysztof was asking was just if he can simply pick up this patch
alone, as it does not require any of the previous changes.
Same is true for the Rockchip patches I guess, so we could just take them
individually into samsung/rockchip dts branches.
Heiko
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox