* Re: [PATCH v7 11/14] mmc: sdhci-msm: Add HS400 platform support
From: Ulf Hansson @ 2016-11-14 15:44 UTC (permalink / raw)
To: kbuild test robot
Cc: Ritesh Harjani, kbuild-all@01.org, linux-mmc, Adrian Hunter,
Shawn Lin, Stephen Boyd, Andy Gross, devicetree@vger.kernel.org,
linux-clk, david.brown, linux-arm-msm@vger.kernel.org,
Georgi Djakov, Alex Lemberg, Mateusz Nowak, Yuliy Izrailov,
Asutosh Das, kdorfman@codeaurora.org, David Griego
In-Reply-To: <201611142112.EdLY7cAN%fengguang.wu@intel.com>
Hi,
On 14 November 2016 at 14:53, kbuild test robot <lkp@intel.com> wrote:
> Hi Venkat,
>
> [auto build test ERROR on ulf.hansson-mmc/next]
> [also build test ERROR on v4.9-rc5]
> [cannot apply to next-20161114]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
Here we go...
>
> url: https://github.com/0day-ci/linux/commits/Ritesh-Harjani/mmc-sdhci-msm-Add-clk-rates-DDR-HS400-support/20161114-142815
> base: https://git.linaro.org/people/ulf.hansson/mmc next
This above is the old tree, here's the new:
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git
Could you please update the path in the build system?
[...]
Kind regards
Ulf Hansson
^ permalink raw reply
* Re: [PATCH v7 08/14] mmc: sdhci-msm: Implement set_clock callback for sdhci-msm
From: Stephen Boyd @ 2016-11-14 19:37 UTC (permalink / raw)
To: Ritesh Harjani
Cc: ulf.hansson, linux-mmc, adrian.hunter, shawn.lin, andy.gross,
devicetree, linux-clk, david.brown, linux-arm-msm, georgi.djakov,
alex.lemberg, mateusz.nowak, Yuliy.Izrailov, asutoshd, kdorfman,
david.griego, stummala, venkatg, rnayak, pramod.gurav
In-Reply-To: <1479103248-9491-9-git-send-email-riteshh@codeaurora.org>
On 11/14, Ritesh Harjani wrote:
> @@ -577,6 +578,90 @@ static unsigned int sdhci_msm_get_min_clock(struct sdhci_host *host)
> return SDHCI_MSM_MIN_CLOCK;
> }
>
> +/**
> + * __sdhci_msm_set_clock - sdhci_msm clock control.
> + *
> + * Description:
> + * Implement MSM version of sdhci_set_clock.
> + * This is required since MSM controller does not
> + * use internal divider and instead directly control
> + * the GCC clock as per HW recommendation.
> + **/
> +void __sdhci_msm_set_clock(struct sdhci_host *host, unsigned int clock)
> +{
> + u16 clk;
> + unsigned long timeout;
> +
> + /*
> + * Keep actual_clock as zero -
> + * - since there is no divider used so no need of having actual_clock.
> + * - MSM controller uses SDCLK for data timeout calculation. If
> + * actual_clock is zero, host->clock is taken for calculation.
> + */
> + host->mmc->actual_clock = 0;
> +
> + sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL);
> +
> + if (clock == 0)
> + return;
> +
> + /*
> + * MSM controller do not use clock divider.
> + * Thus read SDHCI_CLOCK_CONTROL and only enable
> + * clock with no divider value programmed.
> + */
> + clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL);
> +
> + clk |= SDHCI_CLOCK_INT_EN;
> + sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
> +
> + /* Wait max 20 ms */
> + timeout = 20;
> + while (!((clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL))
> + & SDHCI_CLOCK_INT_STABLE)) {
> + if (timeout == 0) {
> + pr_err("%s: Internal clock never stabilised\n",
> + mmc_hostname(host->mmc));
> + return;
> + }
> + timeout--;
> + mdelay(1);
> + }
> +
> + clk |= SDHCI_CLOCK_CARD_EN;
> + sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
This is almost a copy/paste of sdhci_set_clock(). Can we make
sdhci_set_clock() call a __sdhci_set_clock() function that takes
unsigned int clock, and also a flag indicating if we want to set
the internal clock divider or not? Then we can call
__sdhci_set_clock() from sdhci_set_clock() with (clock, true) as
arguments and (clock, false).
> +}
> +
> +/* sdhci_msm_set_clock - Called with (host->lock) spinlock held. */
> +static void sdhci_msm_set_clock(struct sdhci_host *host, unsigned int clock)
> +{
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
> + int rc;
> +
> + if (!clock) {
> + msm_host->clk_rate = clock;
> + goto out;
> + }
> +
> + spin_unlock_irq(&host->lock);
> + if (clock != msm_host->clk_rate) {
Why do we need to check here? Can't we call clk_set_rate()
Unconditionally?
> + rc = clk_set_rate(msm_host->clk, clock);
> + if (rc) {
> + pr_err("%s: Failed to set clock at rate %u\n",
> + mmc_hostname(host->mmc), clock);
> + spin_lock_irq(&host->lock);
> + goto out;
Or replace the above two lines with goto err;
> + }
> + msm_host->clk_rate = clock;
> + pr_debug("%s: Setting clock at rate %lu\n",
> + mmc_hostname(host->mmc), clk_get_rate(msm_host->clk));
> + }
And put an err label here.
> + spin_lock_irq(&host->lock);
> +out:
> + __sdhci_msm_set_clock(host, clock);
> +}
> +
> static const struct of_device_id sdhci_msm_dt_match[] = {
> { .compatible = "qcom,sdhci-msm-v4" },
> {},
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v7 14/14] sdhci: sdhci-msm: update dll configuration
From: Stephen Boyd @ 2016-11-14 19:57 UTC (permalink / raw)
To: Ritesh Harjani
Cc: ulf.hansson, linux-mmc, adrian.hunter, shawn.lin, andy.gross,
devicetree, linux-clk, david.brown, linux-arm-msm, georgi.djakov,
alex.lemberg, mateusz.nowak, Yuliy.Izrailov, asutoshd, kdorfman,
david.griego, stummala, venkatg, rnayak, pramod.gurav,
Krishna Konda
In-Reply-To: <1479103248-9491-15-git-send-email-riteshh@codeaurora.org>
On 11/14, Ritesh Harjani wrote:
> @@ -903,7 +998,33 @@ static void sdhci_msm_set_clock(struct sdhci_host *host, unsigned int clock)
> config |= CORE_HC_SELECT_IN_EN;
> writel_relaxed(config, host->ioaddr + CORE_VENDOR_SPEC);
> }
> + if (!msm_host->clk_rate && !msm_host->use_cdclp533) {
> + /*
> + * Poll on DLL_LOCK or DDR_DLL_LOCK bits in
> + * CORE_DLL_STATUS to be set. This should get set
> + * within 15 us at 200 MHz.
> + */
> + rc = readl_relaxed_poll_timeout(host->ioaddr +
> + CORE_DLL_STATUS,
> + dll_lock,
> + (dll_lock &
> + (CORE_DLL_LOCK |
> + CORE_DDR_DLL_LOCK)), 10,
> + 1000);
> + if (rc == -ETIMEDOUT)
> + pr_err("%s: Unable to get DLL_LOCK/DDR_DLL_LOCK, dll_status: 0x%08x\n",
> + mmc_hostname(host->mmc), dll_lock);
> + }
> } else {
> + if (!msm_host->use_cdclp533) {
> + /* set CORE_PWRSAVE_DLL bit in CORE_VENDOR_SPEC3 */
These types of comments are totally useless. The code says
exactly what is being done, and the comment is actually wrong in
this case. Please remove all these "set/clear bit X in register
Y" comments.
> + config = readl_relaxed(host->ioaddr +
> + CORE_VENDOR_SPEC3);
> + config &= ~CORE_PWRSAVE_DLL;
> + writel_relaxed(config, host->ioaddr +
> + CORE_VENDOR_SPEC3);
> + }
> +
> /* Select the default clock (free running MCLK) */
> config = readl_relaxed(host->ioaddr + CORE_VENDOR_SPEC);
> config &= ~CORE_HC_MCLK_SEL_MASK;
> @@ -1100,6 +1221,13 @@ static int sdhci_msm_probe(struct platform_device *pdev)
> msm_host->use_14lpp_dll_reset = true;
>
> /*
> + * SDCC 5 controller with major version 1, minor version 0x34 and later
> + * with HS 400 mode support will use CM DLL instead of CDC LP 533 DLL.
> + */
> + if ((core_major == 1) && (core_minor < 0x34))
Drop useless parenthesis please.
> + msm_host->use_cdclp533 = true;
> +
> + /*
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v7 13/14] mmc: sdhci-msm: Add calibration tuning for CDCLP533 circuit
From: Stephen Boyd @ 2016-11-14 19:59 UTC (permalink / raw)
To: Ritesh Harjani
Cc: ulf.hansson, linux-mmc, adrian.hunter, shawn.lin, andy.gross,
devicetree, linux-clk, david.brown, linux-arm-msm, georgi.djakov,
alex.lemberg, mateusz.nowak, Yuliy.Izrailov, asutoshd, kdorfman,
david.griego, stummala, venkatg, rnayak, pramod.gurav
In-Reply-To: <1479103248-9491-14-git-send-email-riteshh@codeaurora.org>
On 11/14, Ritesh Harjani wrote:
> @@ -575,6 +729,15 @@ static void sdhci_msm_set_uhs_signaling(struct sdhci_host *host,
> dev_dbg(mmc_dev(mmc), "%s: clock=%u uhs=%u ctrl_2=0x%x\n",
> mmc_hostname(host->mmc), host->clock, uhs, ctrl_2);
> sdhci_writew(host, ctrl_2, SDHCI_HOST_CONTROL2);
> +
> + spin_unlock_irq(&host->lock);
> + /* CDCLP533 HW calibration is only required for HS400 mode*/
> + if (host->clock > CORE_FREQ_100MHZ &&
> + msm_host->tuning_done && !msm_host->calibration_done &&
> + (mmc->ios.timing == MMC_TIMING_MMC_HS400))
Drop useless parenthesis.
> + if (!sdhci_msm_cdclp533_calibration(host))
> + msm_host->calibration_done = true;
> + spin_lock_irq(&host->lock);
> }
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v7 04/14] ARM: dts: Add xo_clock to sdhc nodes on qcom platforms
From: Stephen Boyd @ 2016-11-14 20:01 UTC (permalink / raw)
To: Ritesh Harjani
Cc: ulf.hansson, linux-mmc, adrian.hunter, shawn.lin, andy.gross,
devicetree, linux-clk, david.brown, linux-arm-msm, georgi.djakov,
alex.lemberg, mateusz.nowak, Yuliy.Izrailov, asutoshd, kdorfman,
david.griego, stummala, venkatg, rnayak, pramod.gurav
In-Reply-To: <1479103248-9491-5-git-send-email-riteshh@codeaurora.org>
On 11/14, Ritesh Harjani wrote:
> Add xo_clock to sdhc clock node on all qcom platforms.
>
> Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
> ---
> arch/arm/boot/dts/qcom-apq8084.dtsi | 14 ++++++++------
> arch/arm/boot/dts/qcom-msm8974.dtsi | 14 ++++++++------
> arch/arm64/boot/dts/qcom/msm8916.dtsi | 10 ++++++----
> arch/arm64/boot/dts/qcom/msm8996.dtsi | 9 +++++----
> 4 files changed, 27 insertions(+), 20 deletions(-)
>
Is there an update to
Documentation/devicetree/bindings/mmc/sdhci-msm.txt as well?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v2 01/10] dt-bindings: rockchip-dw-mshc: add RK1108 dw-mshc description
From: Heiko Stuebner @ 2016-11-14 23:09 UTC (permalink / raw)
To: Andy Yan
Cc: shawn.lin, robh+dt, linux-rockchip, devicetree, ulf.hansson,
linux-mmc, linux-kernel, mark.rutland
In-Reply-To: <1479124865-24109-1-git-send-email-andy.yan@rock-chips.com>
Am Montag, 14. November 2016, 20:01:05 CET schrieb Andy Yan:
> From: Shawn Lin <shawn.lin@rock-chips.com>
>
> Add "rockchip,rk1108-dw-mshc", "rockchip,rk3288-dw-mshc" for
> dwmmc on rk1108 platform.
>
> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
applied to my dts32 branch with Rob's Ack taken from the unchanged v1.
Heiko
^ permalink raw reply
* Re: [PATCH v7 02/14] clk: qcom: Move all sdcc rcgs to use clk_rcg2_floor_ops
From: Jeremy McNicoll @ 2016-11-15 0:06 UTC (permalink / raw)
To: Ritesh Harjani, ulf.hansson, linux-mmc, adrian.hunter, shawn.lin,
sboyd, andy.gross
Cc: devicetree, linux-clk, david.brown, linux-arm-msm, georgi.djakov,
alex.lemberg, mateusz.nowak, Yuliy.Izrailov, asutoshd, kdorfman,
david.griego, stummala, venkatg, rnayak, pramod.gurav
In-Reply-To: <1479103248-9491-3-git-send-email-riteshh@codeaurora.org>
On 2016-11-13 10:00 PM, Ritesh Harjani wrote:
> 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>
> Signed-off-by: Ritesh Harjani <riteshh@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 ++++----
Can you please include the same changes for gcc-msm8994.c as it should
be in sboyd's tree?
If not I will send a patch directly, either way works for me.
-jeremy
^ permalink raw reply
* Re: [PATCH v7 00/14] mmc: sdhci-msm: Add clk-rates, DDR, HS400 support
From: Jeremy McNicoll @ 2016-11-15 0:06 UTC (permalink / raw)
To: Ritesh Harjani, ulf.hansson, linux-mmc, adrian.hunter, shawn.lin,
sboyd, andy.gross
Cc: devicetree, linux-clk, david.brown, linux-arm-msm, georgi.djakov,
alex.lemberg, mateusz.nowak, Yuliy.Izrailov, asutoshd, kdorfman,
david.griego, stummala, venkatg, rnayak, pramod.gurav
In-Reply-To: <1479103248-9491-1-git-send-email-riteshh@codeaurora.org>
On 2016-11-13 10:00 PM, Ritesh Harjani wrote:
> Hi,
>
> This is v7 version of the patch series which adds support for MSM8996.
> Adds HS400 driver support as well.
> These are tested on internal msm8996 & db410c HW.
>
> Below are the changes in v7.
>
After adding the associated changes to
drivers/clk/qcom/gcc-msm8994.c (2/14) this version of the series work fine
on my Nexus 5X (msm8992). All partitions have been found and can be
mounted as expected. Reading files seems to work as well, I didn't
try writing anything as I didn't want to mess up my phone at this
point.
So,
Tested-by: Jeremy McNicoll <jeremymc@redhat.com>
-jeremy
^ permalink raw reply
* Re: [PATCH v5 1/5] mmc: dt-bindings: add ZTE ZX296718 MMC bindings
From: Shawn Lin @ 2016-11-15 0:48 UTC (permalink / raw)
To: Jaehoon Chung, Jun Nie
Cc: shawn.lin, Shawn Guo, xie.baoyou, Ulf Hansson, Jason Liu,
linux-mmc
In-Reply-To: <cfd86f7e-71b1-a878-3486-7ce6e0fa5222@samsung.com>
On 2016/11/14 18:04, Jaehoon Chung wrote:
> On 11/14/2016 07:00 PM, Jun Nie wrote:
>> 2016-11-14 15:58 GMT+08:00 Shawn Lin <shawn.lin@rock-chips.com>:
>>> On 2016/11/8 9:24, Jun Nie wrote:
>>>>
>>>> Document the device-tree binding of ZTE MMC host on
>>>> ZX296718 SoC.
>>>>
>>>> Signed-off-by: Jun Nie <jun.nie@linaro.org>
>>>> ---
>>>> .../devicetree/bindings/mmc/zx-dw-mshc.txt | 35
>>>> ++++++++++++++++++++++
>>>> 1 file changed, 35 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt
>>>> b/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt
>>>> new file mode 100644
>>>> index 0000000..c175c4b
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt
>>>> @@ -0,0 +1,35 @@
>>>> +* ZTE specific extensions to the Synopsys Designware Mobile Storage
>>>> + Host Controller
>>>> +
>>>> +The Synopsys designware mobile storage host controller is used to
>>>> interface
>>>> +a SoC with storage medium such as eMMC or SD/MMC cards. This file
>>>> documents
>>>> +differences between the core Synopsys dw mshc controller properties
>>>> described
>>>> +by synopsys-dw-mshc.txt and the properties used by the ZTE specific
>>>> +extensions to the Synopsys Designware Mobile Storage Host Controller.
>>>> +
>>>> +Required Properties:
>>>> +
>>>> +* compatible: should be
>>>> + - "zte,zx296718-dw-mshc": for ZX SoCs
>>>> +
>>>> +Example:
>>>> +
>>>> + mmc1: mmc@1110000 {
>>>> + compatible = "zte,zx296718-dw-mshc";
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + reg = <0x01110000 0x1000>;
>>>> + interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
>>>> + fifo-depth = <32>;
>>>> + data-addr = <0x200>;
>>>> + fifo-watermark-aligned;
>>>> + bus-width = <4>;
>>>> + clock-frequency = <50000000>;
>>>
>>>
>>> do you need both clock-frequency and max-frequency here?
>>
>> According to dts document, clock-frequency is for clock configuration
>> when dw core probe. max-frequency is for mmc core to limit max
>> frequency for any cards at any time. Do you have any suggestion? Thank
>> you for your time!
>
> As i know, Jun's comment is right. :)
> clock-frequency should be used with clk_set_rate().
yup, I was thinking that should we reuse max-frequency instead of
clock-frequency in the future? I saw most of the DT(I didn't check all
of them) assign clock-frequency to the same value as max of clock-
freq-min-max. I think it's pointless if the clock-frequency is different
from max-frequency as both of them will be setted via dw_mmc and finally
we only take min(clock-frequency, max-frquency). Was I missing
something?
What is your opinion, Jaehoon and Jun? :)
>
>>
>>>
>>>> + clocks = <&topcrm SD0_AHB>, <&topcrm SD0_WCLK>;
>>>> + clock-names = "biu", "ciu";
>>>> + num-slots = <1>;
>>>> + max-frequency = <50000000>;
>>>> + cap-sdio-irq;
>>>> + cap-sd-highspeed;
>>>> + status = "disabled";
>>>> + };
>>>>
>>>
>>>
>>> --
>>> Best Regards
>>> Shawn Lin
>>>
>>
>>
>>
>
> --
> 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
>
--
Best Regards
Shawn Lin
^ permalink raw reply
* Re: [PATCH v7 11/14] mmc: sdhci-msm: Add HS400 platform support
From: Fengguang Wu @ 2016-11-15 0:53 UTC (permalink / raw)
To: Ulf Hansson
Cc: Ritesh Harjani, kbuild-all-JC7UmRfGjtg@public.gmane.org,
linux-mmc, Adrian Hunter, Shawn Lin, Stephen Boyd, Andy Gross,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-clk,
david.brown-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Georgi Djakov, Alex Lemberg, Mateusz Nowak, Yuliy Izrailov,
Asutosh Das, kdorfman-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
David Griego
In-Reply-To: <CAPDyKFoUiGgXhLtW9-+iAxdV6sy4+wgQfW8P5+VwsqHc3QwkqA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Nov 14, 2016 at 04:44:19PM +0100, Ulf Hansson wrote:
>Hi,
>
>On 14 November 2016 at 14:53, kbuild test robot <lkp-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>> Hi Venkat,
>>
>> [auto build test ERROR on ulf.hansson-mmc/next]
>> [also build test ERROR on v4.9-rc5]
>> [cannot apply to next-20161114]
>> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
>Here we go...
>
>>
>> url: https://github.com/0day-ci/linux/commits/Ritesh-Harjani/mmc-sdhci-msm-Add-clk-rates-DDR-HS400-support/20161114-142815
>> base: https://git.linaro.org/people/ulf.hansson/mmc next
>
>This above is the old tree, here's the new:
>git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git
>
>Could you please update the path in the build system?
OK, done.
Regards,
Fengguang
--
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 v7 14/14] sdhci: sdhci-msm: update dll configuration
From: Ritesh Harjani @ 2016-11-15 4:23 UTC (permalink / raw)
To: Stephen Boyd
Cc: ulf.hansson, linux-mmc, adrian.hunter, shawn.lin, andy.gross,
devicetree, linux-clk, david.brown, linux-arm-msm, georgi.djakov,
alex.lemberg, mateusz.nowak, Yuliy.Izrailov, asutoshd, kdorfman,
david.griego, stummala, venkatg, rnayak, pramod.gurav,
Krishna Konda
In-Reply-To: <20161114195749.GJ5177@codeaurora.org>
On 11/15/2016 1:27 AM, Stephen Boyd wrote:
> On 11/14, Ritesh Harjani wrote:
>> @@ -903,7 +998,33 @@ static void sdhci_msm_set_clock(struct sdhci_host *host, unsigned int clock)
>> config |= CORE_HC_SELECT_IN_EN;
>> writel_relaxed(config, host->ioaddr + CORE_VENDOR_SPEC);
>> }
>> + if (!msm_host->clk_rate && !msm_host->use_cdclp533) {
>> + /*
>> + * Poll on DLL_LOCK or DDR_DLL_LOCK bits in
>> + * CORE_DLL_STATUS to be set. This should get set
>> + * within 15 us at 200 MHz.
>> + */
>> + rc = readl_relaxed_poll_timeout(host->ioaddr +
>> + CORE_DLL_STATUS,
>> + dll_lock,
>> + (dll_lock &
>> + (CORE_DLL_LOCK |
>> + CORE_DDR_DLL_LOCK)), 10,
>> + 1000);
>> + if (rc == -ETIMEDOUT)
>> + pr_err("%s: Unable to get DLL_LOCK/DDR_DLL_LOCK, dll_status: 0x%08x\n",
>> + mmc_hostname(host->mmc), dll_lock);
>> + }
>> } else {
>> + if (!msm_host->use_cdclp533) {
>> + /* set CORE_PWRSAVE_DLL bit in CORE_VENDOR_SPEC3 */
>
> These types of comments are totally useless. The code says
> exactly what is being done, and the comment is actually wrong in
> this case. Please remove all these "set/clear bit X in register
> Y" comments.
Ok, done.
>
>> + config = readl_relaxed(host->ioaddr +
>> + CORE_VENDOR_SPEC3);
>> + config &= ~CORE_PWRSAVE_DLL;
>> + writel_relaxed(config, host->ioaddr +
>> + CORE_VENDOR_SPEC3);
>> + }
>> +
>> /* Select the default clock (free running MCLK) */
>> config = readl_relaxed(host->ioaddr + CORE_VENDOR_SPEC);
>> config &= ~CORE_HC_MCLK_SEL_MASK;
>> @@ -1100,6 +1221,13 @@ static int sdhci_msm_probe(struct platform_device *pdev)
>> msm_host->use_14lpp_dll_reset = true;
>>
>> /*
>> + * SDCC 5 controller with major version 1, minor version 0x34 and later
>> + * with HS 400 mode support will use CM DLL instead of CDC LP 533 DLL.
>> + */
>> + if ((core_major == 1) && (core_minor < 0x34))
>
> Drop useless parenthesis please.
Done.
>
>> + msm_host->use_cdclp533 = true;
>> +
>> + /*
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v7 13/14] mmc: sdhci-msm: Add calibration tuning for CDCLP533 circuit
From: Ritesh Harjani @ 2016-11-15 4:24 UTC (permalink / raw)
To: Stephen Boyd
Cc: ulf.hansson, linux-mmc, adrian.hunter, shawn.lin, andy.gross,
devicetree, linux-clk, david.brown, linux-arm-msm, georgi.djakov,
alex.lemberg, mateusz.nowak, Yuliy.Izrailov, asutoshd, kdorfman,
david.griego, stummala, venkatg, rnayak, pramod.gurav
In-Reply-To: <20161114195928.GK5177@codeaurora.org>
On 11/15/2016 1:29 AM, Stephen Boyd wrote:
> On 11/14, Ritesh Harjani wrote:
>> @@ -575,6 +729,15 @@ static void sdhci_msm_set_uhs_signaling(struct sdhci_host *host,
>> dev_dbg(mmc_dev(mmc), "%s: clock=%u uhs=%u ctrl_2=0x%x\n",
>> mmc_hostname(host->mmc), host->clock, uhs, ctrl_2);
>> sdhci_writew(host, ctrl_2, SDHCI_HOST_CONTROL2);
>> +
>> + spin_unlock_irq(&host->lock);
>> + /* CDCLP533 HW calibration is only required for HS400 mode*/
>> + if (host->clock > CORE_FREQ_100MHZ &&
>> + msm_host->tuning_done && !msm_host->calibration_done &&
>> + (mmc->ios.timing == MMC_TIMING_MMC_HS400))
>
> Drop useless parenthesis.
Ok, sure.
>
>> + if (!sdhci_msm_cdclp533_calibration(host))
>> + msm_host->calibration_done = true;
>> + spin_lock_irq(&host->lock);
>> }
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v7 08/14] mmc: sdhci-msm: Implement set_clock callback for sdhci-msm
From: Ritesh Harjani @ 2016-11-15 5:10 UTC (permalink / raw)
To: Stephen Boyd, adrian.hunter
Cc: ulf.hansson, linux-mmc, shawn.lin, andy.gross, devicetree,
linux-clk, david.brown, linux-arm-msm, georgi.djakov,
alex.lemberg, mateusz.nowak, Yuliy.Izrailov, asutoshd, kdorfman,
david.griego, stummala, venkatg, rnayak, pramod.gurav
In-Reply-To: <20161114193004.GI5177@codeaurora.org>
Hi Stephen/Adrian,
On 11/15/2016 1:07 AM, Stephen Boyd wrote:
> On 11/14, Ritesh Harjani wrote:
>> @@ -577,6 +578,90 @@ static unsigned int sdhci_msm_get_min_clock(struct sdhci_host *host)
>> return SDHCI_MSM_MIN_CLOCK;
>> }
>>
>> +/**
>> + * __sdhci_msm_set_clock - sdhci_msm clock control.
>> + *
>> + * Description:
>> + * Implement MSM version of sdhci_set_clock.
>> + * This is required since MSM controller does not
>> + * use internal divider and instead directly control
>> + * the GCC clock as per HW recommendation.
>> + **/
>> +void __sdhci_msm_set_clock(struct sdhci_host *host, unsigned int clock)
>> +{
>> + u16 clk;
>> + unsigned long timeout;
>> +
>> + /*
>> + * Keep actual_clock as zero -
>> + * - since there is no divider used so no need of having actual_clock.
>> + * - MSM controller uses SDCLK for data timeout calculation. If
>> + * actual_clock is zero, host->clock is taken for calculation.
>> + */
>> + host->mmc->actual_clock = 0;
>> +
>> + sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL);
>> +
>> + if (clock == 0)
>> + return;
>> +
>> + /*
>> + * MSM controller do not use clock divider.
>> + * Thus read SDHCI_CLOCK_CONTROL and only enable
>> + * clock with no divider value programmed.
>> + */
>> + clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL);
>> +
>> + clk |= SDHCI_CLOCK_INT_EN;
>> + sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
>> +
>> + /* Wait max 20 ms */
>> + timeout = 20;
>> + while (!((clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL))
>> + & SDHCI_CLOCK_INT_STABLE)) {
>> + if (timeout == 0) {
>> + pr_err("%s: Internal clock never stabilised\n",
>> + mmc_hostname(host->mmc));
>> + return;
>> + }
>> + timeout--;
>> + mdelay(1);
>> + }
>> +
>> + clk |= SDHCI_CLOCK_CARD_EN;
>> + sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
>
> This is almost a copy/paste of sdhci_set_clock(). Can we make
> sdhci_set_clock() call a __sdhci_set_clock() function that takes
> unsigned int clock, and also a flag indicating if we want to set
> the internal clock divider or not? Then we can call
> __sdhci_set_clock() from sdhci_set_clock() with (clock, true) as
> arguments and (clock, false).
Adrian,
Could you please comment here ?
>
>> +}
>> +
>> +/* sdhci_msm_set_clock - Called with (host->lock) spinlock held. */
>> +static void sdhci_msm_set_clock(struct sdhci_host *host, unsigned int clock)
>> +{
>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>> + struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
>> + int rc;
>> +
>> + if (!clock) {
>> + msm_host->clk_rate = clock;
>> + goto out;
>> + }
>> +
>> + spin_unlock_irq(&host->lock);
>> + if (clock != msm_host->clk_rate) {
>
> Why do we need to check here? Can't we call clk_set_rate()
> Unconditionally?
Since it may so happen that above layers may call for ->set_clock
function with same requested clock more than once, hence we cache the
host->clock here.
Also, since requested clock (host->clock) can be say 400Mhz but the
actual pltfm supported clock would be say 384MHz.
>
>> + rc = clk_set_rate(msm_host->clk, clock);
>> + if (rc) {
>> + pr_err("%s: Failed to set clock at rate %u\n",
>> + mmc_hostname(host->mmc), clock);
>> + spin_lock_irq(&host->lock);
>> + goto out;
>
> Or replace the above two lines with goto err;
Ok, I will have another label out_lock instead of err.
>
>> + }
>> + msm_host->clk_rate = clock;
>> + pr_debug("%s: Setting clock at rate %lu\n",
>> + mmc_hostname(host->mmc), clk_get_rate(msm_host->clk));
>> + }
>
> And put an err label here.
will put the label here as out_lock;
>
>> + spin_lock_irq(&host->lock);
>> +out:
>> + __sdhci_msm_set_clock(host, clock);
>> +}
>> +
>> static const struct of_device_id sdhci_msm_dt_match[] = {
>> { .compatible = "qcom,sdhci-msm-v4" },
>> {},
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v7 04/14] ARM: dts: Add xo_clock to sdhc nodes on qcom platforms
From: Ritesh Harjani @ 2016-11-15 5:10 UTC (permalink / raw)
To: Stephen Boyd, adrian.hunter-ral2JQCrhuEAvxtiuMwx3w,
andy.gross-QSEj5FYQhm4dnm+yROfE0A
Cc: ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
shawn.lin-TNX95d0MmH7DzftRWevZcw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
david.brown-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: <20161114200115.GL5177-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On 11/15/2016 1:31 AM, Stephen Boyd wrote:
> On 11/14, Ritesh Harjani wrote:
>> Add xo_clock to sdhc clock node on all qcom platforms.
>>
>> Signed-off-by: Ritesh Harjani <riteshh-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> ---
>> arch/arm/boot/dts/qcom-apq8084.dtsi | 14 ++++++++------
>> arch/arm/boot/dts/qcom-msm8974.dtsi | 14 ++++++++------
>> arch/arm64/boot/dts/qcom/msm8916.dtsi | 10 ++++++----
>> arch/arm64/boot/dts/qcom/msm8996.dtsi | 9 +++++----
>> 4 files changed, 27 insertions(+), 20 deletions(-)
>>
>
> Is there an update to
> Documentation/devicetree/bindings/mmc/sdhci-msm.txt as well?
Sure, I will update.
>
--
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
* Re: [PATCH v5 1/5] mmc: dt-bindings: add ZTE ZX296718 MMC bindings
From: Jaehoon Chung @ 2016-11-15 5:21 UTC (permalink / raw)
To: Shawn Lin, Jun Nie
Cc: Shawn Guo, xie.baoyou, Ulf Hansson, Jason Liu, linux-mmc
In-Reply-To: <935402c2-c0be-252b-89b8-c69e250c58d3@rock-chips.com>
On 11/15/2016 09:48 AM, Shawn Lin wrote:
> On 2016/11/14 18:04, Jaehoon Chung wrote:
>> On 11/14/2016 07:00 PM, Jun Nie wrote:
>>> 2016-11-14 15:58 GMT+08:00 Shawn Lin <shawn.lin@rock-chips.com>:
>>>> On 2016/11/8 9:24, Jun Nie wrote:
>>>>>
>>>>> Document the device-tree binding of ZTE MMC host on
>>>>> ZX296718 SoC.
>>>>>
>>>>> Signed-off-by: Jun Nie <jun.nie@linaro.org>
>>>>> ---
>>>>> .../devicetree/bindings/mmc/zx-dw-mshc.txt | 35
>>>>> ++++++++++++++++++++++
>>>>> 1 file changed, 35 insertions(+)
>>>>> create mode 100644 Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt
>>>>> b/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt
>>>>> new file mode 100644
>>>>> index 0000000..c175c4b
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt
>>>>> @@ -0,0 +1,35 @@
>>>>> +* ZTE specific extensions to the Synopsys Designware Mobile Storage
>>>>> + Host Controller
>>>>> +
>>>>> +The Synopsys designware mobile storage host controller is used to
>>>>> interface
>>>>> +a SoC with storage medium such as eMMC or SD/MMC cards. This file
>>>>> documents
>>>>> +differences between the core Synopsys dw mshc controller properties
>>>>> described
>>>>> +by synopsys-dw-mshc.txt and the properties used by the ZTE specific
>>>>> +extensions to the Synopsys Designware Mobile Storage Host Controller.
>>>>> +
>>>>> +Required Properties:
>>>>> +
>>>>> +* compatible: should be
>>>>> + - "zte,zx296718-dw-mshc": for ZX SoCs
>>>>> +
>>>>> +Example:
>>>>> +
>>>>> + mmc1: mmc@1110000 {
>>>>> + compatible = "zte,zx296718-dw-mshc";
>>>>> + #address-cells = <1>;
>>>>> + #size-cells = <0>;
>>>>> + reg = <0x01110000 0x1000>;
>>>>> + interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
>>>>> + fifo-depth = <32>;
>>>>> + data-addr = <0x200>;
>>>>> + fifo-watermark-aligned;
>>>>> + bus-width = <4>;
>>>>> + clock-frequency = <50000000>;
>>>>
>>>>
>>>> do you need both clock-frequency and max-frequency here?
>>>
>>> According to dts document, clock-frequency is for clock configuration
>>> when dw core probe. max-frequency is for mmc core to limit max
>>> frequency for any cards at any time. Do you have any suggestion? Thank
>>> you for your time!
>>
>> As i know, Jun's comment is right. :)
>> clock-frequency should be used with clk_set_rate().
>
> yup, I was thinking that should we reuse max-frequency instead of
> clock-frequency in the future? I saw most of the DT(I didn't check all
> of them) assign clock-frequency to the same value as max of clock-
> freq-min-max. I think it's pointless if the clock-frequency is different
> from max-frequency as both of them will be setted via dw_mmc and finally
> we only take min(clock-frequency, max-frquency). Was I missing
> something?
Well, clock-frequency is for setting CMU. but max-frequency is not really used for CMU.
For example, clock-frequency is 100MHz. Max-frequency is 50MHz.
It's possible to use. then dwmmc controller should divide to 2 for max-frequency.
There are too many cases. Source clock can be 400MHz or 200MHz..etc..
but maximum clock is decided according to busmode.
I'm not sure because i didn't have HW knowledge..
but in my experience,
1) 400MHz/2 = 200MHz,
2) 800MHz/4 = 200MHz.
1) and 2) are same value as 200MHz. but those clock phase might be a little difference.
So i want to keep the clock-frequency for setting the initial CMU value.
What your opinion? :)
Best Regards,
Jaehoon Chung
>
> What is your opinion, Jaehoon and Jun? :)
>
>>
>>>
>>>>
>>>>> + clocks = <&topcrm SD0_AHB>, <&topcrm SD0_WCLK>;
>>>>> + clock-names = "biu", "ciu";
>>>>> + num-slots = <1>;
>>>>> + max-frequency = <50000000>;
>>>>> + cap-sdio-irq;
>>>>> + cap-sd-highspeed;
>>>>> + status = "disabled";
>>>>> + };
>>>>>
>>>>
>>>>
>>>> --
>>>> Best Regards
>>>> Shawn Lin
>>>>
>>>
>>>
>>>
>>
>> --
>> 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: [PATCH v3] mmc: sdhci-of-esdhc: fixup PRESENT_STATE read
From: Y.B. Lu @ 2016-11-15 6:12 UTC (permalink / raw)
To: Michael Walle, linux-kernel@vger.kernel.org
Cc: linux-mmc@vger.kernel.org, Ulf Hansson, Adrian Hunter, yangbo lu
In-Reply-To: <1479136348-30706-1-git-send-email-michael@walle.cc>
> -----Original Message-----
> From: Michael Walle [mailto:michael@walle.cc]
> Sent: Monday, November 14, 2016 11:12 PM
> To: linux-kernel@vger.kernel.org
> Cc: linux-mmc@vger.kernel.org; Ulf Hansson; Adrian Hunter; yangbo lu;
> Michael Walle
> Subject: [PATCH v3] mmc: sdhci-of-esdhc: fixup PRESENT_STATE read
>
> Since commit 87a18a6a5652 ("mmc: mmc: Use ->card_busy() to detect busy
> cards in __mmc_switch()") the ESDHC driver is broken:
> mmc0: Card stuck in programming state! __mmc_switch
> mmc0: error -110 whilst initialising MMC card
>
> Since this commit __mmc_switch() uses ->card_busy(), which is
> sdhci_card_busy() for the esdhc driver. sdhci_card_busy() uses the
> PRESENT_STATE register, specifically the DAT0 signal level bit. But the
> ESDHC uses a non-conformant PRESENT_STATE register, thus a read fixup is
> required to make the driver work again.
>
> Signed-off-by: Michael Walle <michael@walle.cc>
> Fixes: 87a18a6a5652 ("mmc: mmc: Use ->card_busy() to detect busy cards in
> __mmc_switch()")
> ---
> v3:
> - explain the bits in the comments
> - use bits[19:0] from the original value, all other will be taken from
> the
> fixup value.
>
> v2:
> - use lower bits of the original value (that was actually a typo)
> - add fixes tag
> - fix typo
>
> drivers/mmc/host/sdhci-of-esdhc.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-
> of-esdhc.c
> index fb71c86..74cf3b1 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -66,6 +66,19 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
> return ret;
> }
> }
> + /*
> + * The DAT[3:0] line signal levels and the CMD line signal level
> are
> + * not compatible with standard SDHC register. The line signal
> levels
> + * DAT[7:0] are at bits 31:24 and the line signal level is at bit
> 23.
> + * All other bits are the same as in the standard SDHC register.
> + */
> + if (spec_reg == SDHCI_PRESENT_STATE) {
> + ret = value & 0x000fffff;
> + ret |= (value >> 4) & SDHCI_DATA_LVL_MASK;
> + ret |= (value << 1) & 0x01000000;
> + return ret;
> + }
> +
[Lu Yangbo-B47093] This is the proper fix.
Acked-by: Yangbo Lu <yangbo.lu@nxp.com>
> ret = value;
> return ret;
> }
> --
> 2.1.4
^ permalink raw reply
* [PATCH 1/2] mmc: sdhci-pci: Let devices define their own private data
From: Shyam Sundar S K @ 2016-11-15 6:33 UTC (permalink / raw)
To: Adrian Hunter, Ulf Hansson, linux-mmc, Sen, Pankaj,
Shah, Nehal-bakulchandra, Agrawal, Nitesh-kumar
From: Adrian Hunter <adrian.hunter@intel.com>
Let devices define their own private data to facilitate device-specific
operations. The size of the private structure is specified in the
sdhci_pci_fixes structure,then sdhci_pci_probe_slot() will allocate extra
space for it, and sdhci_pci_priv() can be used to get a reference to it.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
---
drivers/mmc/host/sdhci-pci-core.c | 3 ++-
drivers/mmc/host/sdhci-pci.h | 7 +++++++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-pci-core.c b/drivers/mmc/host/sdhci-pci-core.c
index 1d9e00a..782c8d2 100644
--- a/drivers/mmc/host/sdhci-pci-core.c
+++ b/drivers/mmc/host/sdhci-pci-core.c
@@ -1646,6 +1646,7 @@ static struct sdhci_pci_slot *sdhci_pci_probe_slot(
struct sdhci_pci_slot *slot;
struct sdhci_host *host;
int ret, bar = first_bar + slotno;
+ size_t priv_size = chip->fixes ? chip->fixes->priv_size : 0;
if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM)) {
dev_err(&pdev->dev, "BAR %d is not iomem. Aborting.\n", bar);
@@ -1667,7 +1668,7 @@ static struct sdhci_pci_slot *sdhci_pci_probe_slot(
return ERR_PTR(-ENODEV);
}
- host = sdhci_alloc_host(&pdev->dev, sizeof(struct sdhci_pci_slot));
+ host = sdhci_alloc_host(&pdev->dev, sizeof(*slot) + priv_size);
if (IS_ERR(host)) {
dev_err(&pdev->dev, "cannot allocate host\n");
return ERR_CAST(host);
diff --git a/drivers/mmc/host/sdhci-pci.h b/drivers/mmc/host/sdhci-pci.h
index 6bccf56..0bfd568 100644
--- a/drivers/mmc/host/sdhci-pci.h
+++ b/drivers/mmc/host/sdhci-pci.h
@@ -67,6 +67,7 @@ struct sdhci_pci_fixes {
int (*resume) (struct sdhci_pci_chip *);
const struct sdhci_ops *ops;
+ size_t priv_size;
};
struct sdhci_pci_slot {
@@ -87,6 +88,7 @@ struct sdhci_pci_slot {
struct mmc_card *card,
unsigned int max_dtr, int host_drv,
int card_drv, int *drv_type);
+ unsigned long private[0] ____cacheline_aligned;
};
struct sdhci_pci_chip {
@@ -101,4 +103,9 @@ struct sdhci_pci_chip {
struct sdhci_pci_slot *slots[MAX_SLOTS]; /* Pointers to host slots */
};
+static inline void *sdhci_pci_priv(struct sdhci_pci_slot *slot)
+{
+ return (void *)slot->private;
+}
+
#endif /* __SDHCI_PCI_H */
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] mmc: sdhci-pci: Add support for HS200 tuning mode on AMD eMMC-4.5.1
From: Shyam Sundar S K @ 2016-11-15 6:57 UTC (permalink / raw)
To: Adrian Hunter, Ulf Hansson, linux-mmc, Sen, Pankaj,
Shah, Nehal-bakulchandra, Agrawal, Nitesh-kumar
This patch adds support for HS200 tuning mode on AMD eMMC-4.5.1
Reviewed-by: Sen, Pankaj <Pankaj.Sen@amd.com>
Reviewed-by: Shah, Nehal-bakulchandra <Nehal-bakulchandra.Shah@amd.com>
Signed-off-by: S-k, Shyam-sundar <Shyam-sundar.S-k@amd.com>
---
drivers/mmc/host/sdhci-pci-core.c | 177 +++++++++++++++++++++++++++++++++++++-
1 file changed, 176 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-pci-core.c b/drivers/mmc/host/sdhci-pci-core.c
index 782c8d2..1a31bdf 100644
--- a/drivers/mmc/host/sdhci-pci-core.c
+++ b/drivers/mmc/host/sdhci-pci-core.c
@@ -817,6 +817,170 @@ enum amd_chipset_gen {
AMD_CHIPSET_UNKNOWN,
};
+static const struct sdhci_ops amd_sdhci_pci_ops;
+
+struct amd_tuning_descriptor {
+ u8 tune_around;
+ bool this_tune_ok;
+ bool last_tune_ok;
+ u8 valid_front;
+ u8 valid_window_max;
+ u8 tune_low_max;
+ u8 tune_low;
+ u8 valid_window;
+ u8 tune_result;
+};
+
+static int amd_tuning_reset(struct sdhci_host *host)
+{
+ unsigned int val;
+ unsigned long flags;
+
+ spin_lock_irqsave(&host->lock, flags);
+
+ val = sdhci_readw(host, SDHCI_HOST_CONTROL2);
+ val |= SDHCI_CTRL_PRESET_VAL_ENABLE | SDHCI_CTRL_EXEC_TUNING;
+ sdhci_writew(host, val, SDHCI_HOST_CONTROL2);
+
+ val = sdhci_readw(host, SDHCI_HOST_CONTROL2);
+ val &= ~SDHCI_CTRL_EXEC_TUNING;
+ sdhci_writew(host, val, SDHCI_HOST_CONTROL2);
+
+ spin_unlock_irqrestore(&host->lock, flags);
+
+ return 0;
+}
+
+static int amd_config_tuning_phase(struct sdhci_host *host, u8 phase)
+{
+ struct sdhci_pci_slot *slot = sdhci_priv(host);
+ struct pci_dev *pdev = slot->chip->pdev;
+ unsigned int val;
+ unsigned long flags;
+
+ spin_lock_irqsave(&host->lock, flags);
+
+ pci_read_config_dword(pdev, 0xb8, &val);
+ val &= ~0x1f;
+ val |= (0x10800 | (phase << 1));
+ pci_write_config_dword(pdev, 0xb8, val);
+
+ spin_unlock_irqrestore(&host->lock, flags);
+
+ return 0;
+}
+
+static int amd_find_good_phase(struct sdhci_host *host)
+{
+ struct sdhci_pci_slot *slot = sdhci_priv(host);
+ struct pci_dev *pdev = slot->chip->pdev;
+ struct amd_tuning_descriptor *td = sdhci_pci_priv(slot);
+
+ unsigned int val;
+ unsigned long flags;
+
+ spin_lock_irqsave(&host->lock, flags);
+
+ if (td->this_tune_ok)
+ td->valid_front += 1;
+ if ((!td->this_tune_ok && td->last_tune_ok) ||
+ (td->tune_around == 11)) {
+ if (td->valid_window > td->valid_window_max) {
+ td->valid_window_max = td->valid_window;
+ td->tune_low_max = td->tune_low;
+ }
+ }
+ if (td->this_tune_ok && (!td->last_tune_ok))
+ td->tune_low = td->tune_around;
+ if (!td->this_tune_ok && td->last_tune_ok)
+ td->valid_window = 0;
+ else if (td->this_tune_ok)
+ td->valid_window += 1;
+
+ td->last_tune_ok = td->this_tune_ok;
+
+ if (td->tune_around == 11) {
+ if ((td->valid_front + td->valid_window) >
+ td->valid_window_max) {
+ if (td->valid_front > td->valid_window)
+ td->tune_result = ((td->valid_front -
+ td->valid_window) >> 1);
+ else
+ td->tune_result = td->tune_low +
+ ((td->valid_window + td->valid_front) >> 1);
+ } else {
+ td->tune_result = td->tune_low_max +
+ (td->valid_window_max >> 1);
+ }
+
+ if (td->tune_result > 0x0b)
+ td->tune_result = 0x0b;
+
+ pci_read_config_dword(pdev, 0xb8, &val);
+ val &= ~0x1f;
+ val |= (0x10800 | (td->tune_result << 1));
+ pci_write_config_dword(pdev, 0xb8, val);
+ }
+
+ spin_unlock_irqrestore(&host->lock, flags);
+
+ return 0;
+}
+
+static int amd_enable_manual_tuning(struct sdhci_pci_slot *slot)
+{
+ struct pci_dev *pdev = slot->chip->pdev;
+ unsigned int val;
+
+ pci_read_config_dword(pdev, 0xd0, &val);
+ val &= 0xffffffcf;
+ val |= 0x30;
+ pci_write_config_dword(pdev, 0xd0, val);
+
+ return 0;
+}
+
+static int amd_execute_tuning(struct sdhci_host *host, u32 opcode)
+{
+ struct sdhci_pci_slot *slot = sdhci_priv(host);
+ struct amd_tuning_descriptor *td = sdhci_pci_priv(slot);
+ u8 ctrl;
+
+ amd_tuning_reset(host);
+
+ /*********************************************************************/
+ /* Enabling Software Tuning */
+ /********************************************************************/
+ /* 1. First switch the eMMC to HS200 Mode
+ * 2. Prepare the registers by using the sampling clock select
+ * 3. Send the CMD21 12 times with block length of 64 bytes
+ * 4. Everytime change the clk phase and check for CRC error
+ * (CMD and DATA),if error, soft reset the CMD and DATA line
+ * 5. Calculate the window and set the clock phase.
+ */
+
+ for (td->tune_around = 0; td->tune_around < 12; td->tune_around++) {
+ amd_config_tuning_phase(host, td->tune_around);
+
+ if (mmc_send_tuning(host->mmc, opcode, NULL)) {
+ td->this_tune_ok = false;
+ host->mmc->need_retune = 0;
+ mdelay(4);
+ ctrl = SDHCI_RESET_CMD | SDHCI_RESET_DATA;
+ sdhci_writeb(host, ctrl, SDHCI_SOFTWARE_RESET);
+ } else {
+ td->this_tune_ok = true;
+ }
+
+ amd_find_good_phase(host);
+ }
+
+ host->mmc->retune_period = 0;
+
+ amd_enable_manual_tuning(slot);
+ return 0;
+}
+
static int amd_probe(struct sdhci_pci_chip *chip)
{
struct pci_dev *smbus_dev;
@@ -841,7 +1005,6 @@ static int amd_probe(struct sdhci_pci_chip *chip)
if ((gen == AMD_CHIPSET_BEFORE_ML) || (gen == AMD_CHIPSET_CZ)) {
chip->quirks2 |= SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD;
- chip->quirks2 |= SDHCI_QUIRK2_BROKEN_HS200;
}
return 0;
@@ -849,6 +1012,7 @@ static int amd_probe(struct sdhci_pci_chip *chip)
static const struct sdhci_pci_fixes sdhci_amd = {
.probe = amd_probe,
+ .ops = &amd_sdhci_pci_ops,
};
static const struct pci_device_id pci_ids[] = {
@@ -1469,6 +1633,17 @@ static const struct sdhci_ops sdhci_pci_ops = {
.select_drive_strength = sdhci_pci_select_drive_strength,
};
+static const struct sdhci_ops amd_sdhci_pci_ops = {
+ .set_clock = sdhci_set_clock,
+ .enable_dma = sdhci_pci_enable_dma,
+ .set_bus_width = sdhci_pci_set_bus_width,
+ .reset = sdhci_reset,
+ .set_uhs_signaling = sdhci_set_uhs_signaling,
+ .hw_reset = sdhci_pci_hw_reset,
+ .select_drive_strength = sdhci_pci_select_drive_strength,
+ .platform_execute_tuning = amd_execute_tuning,
+};
+
/*****************************************************************************\
* *
* Suspend/resume *
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3] mmc: sdhci-of-esdhc: fixup PRESENT_STATE read
From: Adrian Hunter @ 2016-11-15 7:11 UTC (permalink / raw)
To: Michael Walle, linux-kernel; +Cc: linux-mmc, Ulf Hansson, yangbo lu
In-Reply-To: <1479136348-30706-1-git-send-email-michael@walle.cc>
On 14/11/16 17:12, Michael Walle wrote:
> Since commit 87a18a6a5652 ("mmc: mmc: Use ->card_busy() to detect busy
> cards in __mmc_switch()") the ESDHC driver is broken:
> mmc0: Card stuck in programming state! __mmc_switch
> mmc0: error -110 whilst initialising MMC card
>
> Since this commit __mmc_switch() uses ->card_busy(), which is
> sdhci_card_busy() for the esdhc driver. sdhci_card_busy() uses the
> PRESENT_STATE register, specifically the DAT0 signal level bit. But the
> ESDHC uses a non-conformant PRESENT_STATE register, thus a read fixup is
> required to make the driver work again.
>
> Signed-off-by: Michael Walle <michael@walle.cc>
> Fixes: 87a18a6a5652 ("mmc: mmc: Use ->card_busy() to detect busy cards in __mmc_switch()")
> ---
> v3:
> - explain the bits in the comments
> - use bits[19:0] from the original value, all other will be taken from the
> fixup value.
>
> v2:
> - use lower bits of the original value (that was actually a typo)
> - add fixes tag
> - fix typo
>
> drivers/mmc/host/sdhci-of-esdhc.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
> index fb71c86..74cf3b1 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -66,6 +66,19 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
> return ret;
> }
> }
> + /*
> + * The DAT[3:0] line signal levels and the CMD line signal level are
> + * not compatible with standard SDHC register. The line signal levels
> + * DAT[7:0] are at bits 31:24 and the line signal level is at bit 23.
> + * All other bits are the same as in the standard SDHC register.
> + */
> + if (spec_reg == SDHCI_PRESENT_STATE) {
> + ret = value & 0x000fffff;
> + ret |= (value >> 4) & SDHCI_DATA_LVL_MASK;
> + ret |= (value << 1) & 0x01000000;
Please define the command line level bit in sdhci.h and use that here.
e.g.
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 766df17fb7eb..2570455b219a 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -73,6 +73,7 @@
#define SDHCI_DATA_LVL_MASK 0x00F00000
#define SDHCI_DATA_LVL_SHIFT 20
#define SDHCI_DATA_0_LVL_MASK 0x00100000
+#define SDHCI_CMD_LVL 0x01000000
#define SDHCI_HOST_CONTROL 0x28
#define SDHCI_CTRL_LED 0x01
> + return ret;
> + }
> +
> ret = value;
> return ret;
> }
>
^ permalink raw reply related
* Re: [PATCH v3] mmc: sdhci-of-esdhc: fixup PRESENT_STATE read
From: Alexander Stein @ 2016-11-15 7:28 UTC (permalink / raw)
To: linux-kernel
Cc: Michael Walle, linux-mmc, Ulf Hansson, Adrian Hunter, yangbo lu
In-Reply-To: <1479136348-30706-1-git-send-email-michael@walle.cc>
On Monday 14 November 2016 16:12:27, Michael Walle wrote:
> Since commit 87a18a6a5652 ("mmc: mmc: Use ->card_busy() to detect busy
> cards in __mmc_switch()") the ESDHC driver is broken:
> mmc0: Card stuck in programming state! __mmc_switch
> mmc0: error -110 whilst initialising MMC card
>
> Since this commit __mmc_switch() uses ->card_busy(), which is
> sdhci_card_busy() for the esdhc driver. sdhci_card_busy() uses the
> PRESENT_STATE register, specifically the DAT0 signal level bit. But the
> ESDHC uses a non-conformant PRESENT_STATE register, thus a read fixup is
> required to make the driver work again.
>
> Signed-off-by: Michael Walle <michael@walle.cc>
> Fixes: 87a18a6a5652 ("mmc: mmc: Use ->card_busy() to detect busy cards in
> __mmc_switch()") ---
> v3:
> - explain the bits in the comments
> - use bits[19:0] from the original value, all other will be taken from the
> fixup value.
>
> v2:
> - use lower bits of the original value (that was actually a typo)
> - add fixes tag
> - fix typo
>
> drivers/mmc/host/sdhci-of-esdhc.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c
> b/drivers/mmc/host/sdhci-of-esdhc.c index fb71c86..74cf3b1 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -66,6 +66,19 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
> return ret;
> }
> }
> + /*
> + * The DAT[3:0] line signal levels and the CMD line signal level are
> + * not compatible with standard SDHC register. The line signal levels
> + * DAT[7:0] are at bits 31:24 and the line signal level is at bit 23.
^
I guess there is a "command" missing, no?
Best regards,
Alexander
^ permalink raw reply
* Re: [PATCH v5 1/5] mmc: dt-bindings: add ZTE ZX296718 MMC bindings
From: Shawn Lin @ 2016-11-15 7:49 UTC (permalink / raw)
To: Jaehoon Chung, Jun Nie
Cc: shawn.lin, Shawn Guo, xie.baoyou, Ulf Hansson, Jason Liu,
linux-mmc
In-Reply-To: <983fdc91-5487-3d71-b55c-88edc7b579e7@samsung.com>
On 2016/11/15 13:21, Jaehoon Chung wrote:
> On 11/15/2016 09:48 AM, Shawn Lin wrote:
>> On 2016/11/14 18:04, Jaehoon Chung wrote:
>>> On 11/14/2016 07:00 PM, Jun Nie wrote:
>>>> 2016-11-14 15:58 GMT+08:00 Shawn Lin <shawn.lin@rock-chips.com>:
>>>>> On 2016/11/8 9:24, Jun Nie wrote:
>>>>>>
>>>>>> Document the device-tree binding of ZTE MMC host on
>>>>>> ZX296718 SoC.
>>>>>>
>>>>>> Signed-off-by: Jun Nie <jun.nie@linaro.org>
>>>>>> ---
>>>>>> .../devicetree/bindings/mmc/zx-dw-mshc.txt | 35
>>>>>> ++++++++++++++++++++++
>>>>>> 1 file changed, 35 insertions(+)
>>>>>> create mode 100644 Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt
>>>>>> b/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..c175c4b
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt
>>>>>> @@ -0,0 +1,35 @@
>>>>>> +* ZTE specific extensions to the Synopsys Designware Mobile Storage
>>>>>> + Host Controller
>>>>>> +
>>>>>> +The Synopsys designware mobile storage host controller is used to
>>>>>> interface
>>>>>> +a SoC with storage medium such as eMMC or SD/MMC cards. This file
>>>>>> documents
>>>>>> +differences between the core Synopsys dw mshc controller properties
>>>>>> described
>>>>>> +by synopsys-dw-mshc.txt and the properties used by the ZTE specific
>>>>>> +extensions to the Synopsys Designware Mobile Storage Host Controller.
>>>>>> +
>>>>>> +Required Properties:
>>>>>> +
>>>>>> +* compatible: should be
>>>>>> + - "zte,zx296718-dw-mshc": for ZX SoCs
>>>>>> +
>>>>>> +Example:
>>>>>> +
>>>>>> + mmc1: mmc@1110000 {
>>>>>> + compatible = "zte,zx296718-dw-mshc";
>>>>>> + #address-cells = <1>;
>>>>>> + #size-cells = <0>;
>>>>>> + reg = <0x01110000 0x1000>;
>>>>>> + interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> + fifo-depth = <32>;
>>>>>> + data-addr = <0x200>;
>>>>>> + fifo-watermark-aligned;
>>>>>> + bus-width = <4>;
>>>>>> + clock-frequency = <50000000>;
>>>>>
>>>>>
>>>>> do you need both clock-frequency and max-frequency here?
>>>>
>>>> According to dts document, clock-frequency is for clock configuration
>>>> when dw core probe. max-frequency is for mmc core to limit max
>>>> frequency for any cards at any time. Do you have any suggestion? Thank
>>>> you for your time!
>>>
>>> As i know, Jun's comment is right. :)
>>> clock-frequency should be used with clk_set_rate().
>>
>> yup, I was thinking that should we reuse max-frequency instead of
>> clock-frequency in the future? I saw most of the DT(I didn't check all
>> of them) assign clock-frequency to the same value as max of clock-
>> freq-min-max. I think it's pointless if the clock-frequency is different
>> from max-frequency as both of them will be setted via dw_mmc and finally
>> we only take min(clock-frequency, max-frquency). Was I missing
>> something?
>
> Well, clock-frequency is for setting CMU. but max-frequency is not really used for CMU.
> For example, clock-frequency is 100MHz. Max-frequency is 50MHz.
> It's possible to use. then dwmmc controller should divide to 2 for max-frequency.
yes, but why shouldn't we ask clock unit to generate max-frequency, so
we don't need to divide 2 here?
>
> There are too many cases. Source clock can be 400MHz or 200MHz..etc..
> but maximum clock is decided according to busmode.
>
> I'm not sure because i didn't have HW knowledge..
> but in my experience,
> 1) 400MHz/2 = 200MHz,
> 2) 800MHz/4 = 200MHz.
>
> 1) and 2) are same value as 200MHz. but those clock phase might be a little difference.
clock rate shouldn't be problem but the clock phase maybe according to
the different clock design.
>
> So i want to keep the clock-frequency for setting the initial CMU value.
> What your opinion? :)
it' okay and I was just think that
(1) most of the host drivers direct use max-frequenct(f_max) for
setting clock source rate and use internal divider to generate other
different rate. Also you can look at mmc_set_clock function.
That impiles they doesn't care the phase or any differences at all.
(2) If clock-frequency may be a little different with max-frequency,
but I now check all the DT using clock-frequency with clock-freq-min-max
before your cleanup and comfirm that all of the clock-frequency(s) are
the same as the max of clock-freq-min-max, namely max-frequency after
your cleanup. That implies that there are no difference between
setting source rate with clock-frequency and with max-frequency.
Anyway, that is just some random thoughts and shouldn't block this
patchset. We could disscuss this topic later. :)
>
> Best Regards,
> Jaehoon Chung
>
>>
>> What is your opinion, Jaehoon and Jun? :)
>>
>>>
>>>>
>>>>>
>>>>>> + clocks = <&topcrm SD0_AHB>, <&topcrm SD0_WCLK>;
>>>>>> + clock-names = "biu", "ciu";
>>>>>> + num-slots = <1>;
>>>>>> + max-frequency = <50000000>;
>>>>>> + cap-sdio-irq;
>>>>>> + cap-sd-highspeed;
>>>>>> + status = "disabled";
>>>>>> + };
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best Regards
>>>>> Shawn Lin
>>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> 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
>>>
>>
>>
>
> --
> 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
>
--
Best Regards
Shawn Lin
^ permalink raw reply
* [PATCHv2 01/10] mmc: dw_mmc: display the real register value on debugfs
From: Jaehoon Chung @ 2016-11-15 10:12 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, heiko-4mtYJXux2i+zQB+pC5nmwQ,
shawn.lin-TNX95d0MmH7DzftRWevZcw, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
Jaehoon Chung
In-Reply-To: <20161115101232.3854-1-jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Developer wants to see the real register value, not register offset.
This patch fixed to display the real value of register.
Signed-off-by: Jaehoon Chung <jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Tested-by: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
---
drivers/mmc/host/dw_mmc.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index a16c537..e53899e 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -165,12 +165,14 @@ static const struct file_operations dw_mci_req_fops = {
static int dw_mci_regs_show(struct seq_file *s, void *v)
{
- seq_printf(s, "STATUS:\t0x%08x\n", SDMMC_STATUS);
- seq_printf(s, "RINTSTS:\t0x%08x\n", SDMMC_RINTSTS);
- seq_printf(s, "CMD:\t0x%08x\n", SDMMC_CMD);
- seq_printf(s, "CTRL:\t0x%08x\n", SDMMC_CTRL);
- seq_printf(s, "INTMASK:\t0x%08x\n", SDMMC_INTMASK);
- seq_printf(s, "CLKENA:\t0x%08x\n", SDMMC_CLKENA);
+ struct dw_mci *host = s->private;
+
+ seq_printf(s, "STATUS:\t0x%08x\n", mci_readl(host, STATUS));
+ seq_printf(s, "RINTSTS:\t0x%08x\n", mci_readl(host, RINTSTS));
+ seq_printf(s, "CMD:\t0x%08x\n", mci_readl(host, CMD));
+ seq_printf(s, "CTRL:\t0x%08x\n", mci_readl(host, CTRL));
+ seq_printf(s, "INTMASK:\t0x%08x\n", mci_readl(host, INTMASK));
+ seq_printf(s, "CLKENA:\t0x%08x\n", mci_readl(host, CLKENA));
return 0;
}
--
2.10.1
--
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
* [PATCHv2 06/10] mmc: core: move the cookie's enum values from sdhci.h to mmc.h
From: Jaehoon Chung @ 2016-11-15 10:12 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, heiko-4mtYJXux2i+zQB+pC5nmwQ,
shawn.lin-TNX95d0MmH7DzftRWevZcw, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
Jaehoon Chung
In-Reply-To: <20161115101232.3854-1-jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
It's not for only sdhci controller.
So it can be moved from sdhci.h to mmc.h. And renamed from sdhci_cookie
to mmc_cookie.
Signed-off-by: Jaehoon Chung <jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Tested-by: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
---
drivers/mmc/host/sdhci.h | 6 ------
include/linux/mmc/core.h | 6 ++++++
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 766df17..325663b 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -321,12 +321,6 @@ struct sdhci_adma2_64_desc {
/* Allow for a a command request and a data request at the same time */
#define SDHCI_MAX_MRQS 2
-enum sdhci_cookie {
- COOKIE_UNMAPPED,
- COOKIE_PRE_MAPPED, /* mapped by sdhci_pre_req() */
- COOKIE_MAPPED, /* mapped by sdhci_prepare_data() */
-};
-
struct sdhci_host {
/* Data set by hardware interface driver */
const char *hw_name; /* Hardware bus name */
diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h
index 0ce928b..82d707f 100644
--- a/include/linux/mmc/core.h
+++ b/include/linux/mmc/core.h
@@ -118,6 +118,12 @@ struct mmc_command {
struct mmc_request *mrq; /* associated request */
};
+enum mmc_cookie {
+ COOKIE_UNMAPPED,
+ COOKIE_PRE_MAPPED, /* mapped by pre_req() of controller */
+ COOKIE_MAPPED, /* mapped by prepare_data() of controller */
+};
+
struct mmc_data {
unsigned int timeout_ns; /* data timeout (in ns, max 80ms) */
unsigned int timeout_clks; /* data timeout (in clocks) */
--
2.10.1
--
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
* [PATCHv2 08/10] mmc: dw_mmc: remove the unnecessary mmc_data structure
From: Jaehoon Chung @ 2016-11-15 10:12 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, heiko-4mtYJXux2i+zQB+pC5nmwQ,
shawn.lin-TNX95d0MmH7DzftRWevZcw, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
Jaehoon Chung
In-Reply-To: <20161115101232.3854-1-jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Remove the unnecessary mmc_data structure.
Instead, cmd->data can be used.
Signed-off-by: Jaehoon Chung <jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Tested-by: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
---
drivers/mmc/host/dw_mmc.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index e912de6..ec0ba79 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -236,7 +236,6 @@ static void mci_send_cmd(struct dw_mci_slot *slot, u32 cmd, u32 arg);
static u32 dw_mci_prepare_command(struct mmc_host *mmc, struct mmc_command *cmd)
{
- struct mmc_data *data;
struct dw_mci_slot *slot = mmc_priv(mmc);
struct dw_mci *host = slot->host;
u32 cmdr;
@@ -291,10 +290,9 @@ static u32 dw_mci_prepare_command(struct mmc_host *mmc, struct mmc_command *cmd)
if (cmd->flags & MMC_RSP_CRC)
cmdr |= SDMMC_CMD_RESP_CRC;
- data = cmd->data;
- if (data) {
+ if (cmd->data) {
cmdr |= SDMMC_CMD_DAT_EXP;
- if (data->flags & MMC_DATA_WRITE)
+ if (cmd->data->flags & MMC_DATA_WRITE)
cmdr |= SDMMC_CMD_DAT_WR;
}
--
2.10.1
--
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
* [PATCHv2 09/10] mmc: dw_mmc: The "clock-freq-min-max" property was deprecated
From: Jaehoon Chung @ 2016-11-15 10:12 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, heiko-4mtYJXux2i+zQB+pC5nmwQ,
shawn.lin-TNX95d0MmH7DzftRWevZcw, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
Jaehoon Chung
In-Reply-To: <20161115101232.3854-1-jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
The "clock-freq-min-max" property was deprecated.
There is "max-frequency" property in drivers/mmc/core/host.c
"max-frequency" can be replaced with "clock-freq-min-max".
Minimum clock value might be set to 100K by default.
Then MMC core should try to find the correct value from 400K to 100K.
So it just needs to set Maximum clock value.
Signed-off-by: Jaehoon Chung <jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
---
Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt | 3 ++-
drivers/mmc/host/dw_mmc.c | 2 ++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
index bfa461a..1279a22 100644
--- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
@@ -59,8 +59,9 @@ Optional properties:
is specified and the ciu clock is specified then we'll try to set the ciu
clock to this at probe time.
-* clock-freq-min-max: Minimum and Maximum clock frequency for card output
+* clock-freq-min-max (DEPRECATED): Minimum and Maximum clock frequency for card output
clock(cclk_out). If it's not specified, max is 200MHZ and min is 400KHz by default.
+ (Use the "max-frequency" instead of "clock-freq-min-max".)
* num-slots: specifies the number of slots supported by the controller.
The number of physical slots actually used could be equal or less than the
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index ec0ba79..48e968a 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2608,6 +2608,8 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned int id)
mmc->f_min = DW_MCI_FREQ_MIN;
mmc->f_max = DW_MCI_FREQ_MAX;
} else {
+ dev_info(host->dev,
+ "'clock-freq-min-max' property was deprecated.\n");
mmc->f_min = freq[0];
mmc->f_max = freq[1];
}
--
2.10.1
--
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
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