Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1687095 > unrolled thread

[PATCH 00/11] ARM: sun8i: a83t: Add support for MMC controllers

Started byChen-Yu Tsai <wens@csie.org>
First post2017-07-14 08:50 +0200
Last post2017-07-17 11:20 +0200
Articles 20 on this page of 22 — 4 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH 00/11] ARM: sun8i: a83t: Add support for MMC controllers Chen-Yu Tsai <wens@csie.org> - 2017-07-14 08:50 +0200
    [PATCH 11/11] ARM: dts: sun8i: a83t: h8homlet: Enable micro-SD card and onboard eMMC Chen-Yu Tsai <wens@csie.org> - 2017-07-14 08:50 +0200
    [PATCH 04/11] mmc: sunxi: Keep default timing phase settings for new timing mode Chen-Yu Tsai <wens@csie.org> - 2017-07-14 08:50 +0200
      Re: [PATCH 04/11] mmc: sunxi: Keep default timing phase settings for  new timing mode Ulf Hansson <ulf.hansson@linaro.org> - 2017-07-14 11:20 +0200
        Re: [PATCH 04/11] mmc: sunxi: Keep default timing phase settings for  new timing mode Chen-Yu Tsai <wens@csie.org> - 2017-07-14 11:50 +0200
      Re: [PATCH 04/11] mmc: sunxi: Keep default timing phase settings for  new timing mode Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-07-17 11:20 +0200
      Re: [PATCH 04/11] mmc: sunxi: Keep default timing phase settings for  new timing mode Ulf Hansson <ulf.hansson@linaro.org> - 2017-07-17 12:40 +0200
    [PATCH 09/11] ARM: dts: sun8i: a83t: Add pingroup for 8-bit eMMC on mmc2 Chen-Yu Tsai <wens@csie.org> - 2017-07-14 08:50 +0200
    [PATCH 01/11] ARM: dts: sun8i: a83t: Switch to CCU device tree binding macros Chen-Yu Tsai <wens@csie.org> - 2017-07-14 08:50 +0200
      Re: [PATCH 01/11] ARM: dts: sun8i: a83t: Switch to CCU device tree  binding macros Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-07-17 11:10 +0200
    [PATCH 02/11] clk: sunxi-ng: Add interface to query or configure MMC timing modes. Chen-Yu Tsai <wens@csie.org> - 2017-07-14 08:50 +0200
      Re: [PATCH 02/11] clk: sunxi-ng: Add interface to query or configure  MMC timing modes. Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-07-17 11:20 +0200
    [PATCH 08/11] ARM: dts: sun8i: a83t: Add MMC controller device nodes Chen-Yu Tsai <wens@csie.org> - 2017-07-14 08:50 +0200
      Re: [PATCH 08/11] ARM: dts: sun8i: a83t: Add MMC controller device  nodes Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-07-17 11:30 +0200
    [PATCH 07/11] mmc: sunxi: Add support for A83T eMMC (MMC2) Chen-Yu Tsai <wens@csie.org> - 2017-07-14 08:50 +0200
      Re: [PATCH 07/11] mmc: sunxi: Add support for A83T eMMC (MMC2) Rob Herring <robh@kernel.org> - 2017-07-17 21:00 +0200
    [PATCH 05/11] mmc: sunxi: Support controllers that can use both old and new timings Chen-Yu Tsai <wens@csie.org> - 2017-07-14 08:50 +0200
      Re: [PATCH 05/11] mmc: sunxi: Support controllers that can use both  old and new timings Ulf Hansson <ulf.hansson@linaro.org> - 2017-07-14 11:30 +0200
        Re: [PATCH 05/11] mmc: sunxi: Support controllers that can use both  old and new timings Chen-Yu Tsai <wens@csie.org> - 2017-07-14 11:50 +0200
          Re: [PATCH 05/11] mmc: sunxi: Support controllers that can use both  old and new timings Ulf Hansson <ulf.hansson@linaro.org> - 2017-07-14 12:00 +0200
            Re: [PATCH 05/11] mmc: sunxi: Support controllers that can use both  old and new timings Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-07-17 11:30 +0200
      Re: [PATCH 05/11] mmc: sunxi: Support controllers that can use both  old and new timings Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-07-17 11:20 +0200

Page 1 of 2  [1] 2  Next page →


#1687095 — [PATCH 00/11] ARM: sun8i: a83t: Add support for MMC controllers

FromChen-Yu Tsai <wens@csie.org>
Date2017-07-14 08:50 +0200
Subject[PATCH 00/11] ARM: sun8i: a83t: Add support for MMC controllers
Message-ID<u32Ai-84Q-7@gated-at.bofh.it>
Hi everyone,

This series adds support for the MMC controllers on the A83T. The A83T's
MMC controller adds what they call the "new timing mode". It moves the
MMC clock delay lines into the controller itself. There are some minor
changes to how the clock rate is calculated. The new mode give better
performance and stability for eMMC applications. This mode is only
found on the eMMC facing controller (or MMC2 on this chip).

This mode is also found on the A64, but on that chip, the controller
is fixed to that mode. On the A83t, the user is free to use the old
or new mode, but the new mode is recommended. There are two switches,
one in the clock controller, the other in the MMC controller, that
must be set in tandem.

The main part of this series adds custom functions to the sunxi-ng
clk driver, allowing the MMC driver to query and configure the mode.
The MMC driver can then support timing mode switching, and thus, the
MMC2 controller on the A83t.

The other bits are some related cleanups, and the usual device tree
changes.

The first patch, while largely unrelated, converts the raw clock
indices used in the A83t device tree to properly named macros. This
should be applied for 4.13, before any other device tree additions
that reference the CCU clocks. So it is included in this series.

Please have a look.


Regards
ChenYu


Chen-Yu Tsai (11):
  ARM: dts: sun8i: a83t: Switch to CCU device tree binding macros
  clk: sunxi-ng: Add interface to query or configure MMC timing modes.
  clk: sunxi-ng: a83t: Support new timing mode for mmc2 clock
  mmc: sunxi: Keep default timing phase settings for new timing mode
  mmc: sunxi: Support controllers that can use both old and new timings
  mmc: sunxi: Support MMC DDR52 transfer mode with new timing mode
  mmc: sunxi: Add support for A83T eMMC (MMC2)
  ARM: dts: sun8i: a83t: Add MMC controller device nodes
  ARM: dts: sun8i: a83t: Add pingroup for 8-bit eMMC on mmc2
  ARM: dts: sun8i: a83t: cubietruck-plus: Enable micro-SD card and eMMC
  ARM: dts: sun8i: a83t: h8homlet: Enable micro-SD card and onboard eMMC

 .../devicetree/bindings/mmc/sunxi-mmc.txt          |  1 +
 .../boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts  | 21 ++++++
 arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts   | 27 +++++++
 arch/arm/boot/dts/sun8i-a83t.dtsi                  | 82 ++++++++++++++++++++--
 drivers/clk/sunxi-ng/Makefile                      |  1 +
 drivers/clk/sunxi-ng/ccu-sun8i-a83t.c              | 38 +++++++---
 drivers/clk/sunxi-ng/ccu_common.h                  |  2 +
 drivers/clk/sunxi-ng/ccu_mmc_timing.c              | 73 +++++++++++++++++++
 drivers/mmc/host/sunxi-mmc.c                       | 78 +++++++++++++++-----
 include/linux/clk/sunxi-ng.h                       | 20 ++++++
 10 files changed, 311 insertions(+), 32 deletions(-)
 create mode 100644 drivers/clk/sunxi-ng/ccu_mmc_timing.c
 create mode 100644 include/linux/clk/sunxi-ng.h

-- 
2.13.2

[toc] | [next] | [standalone]


#1687096 — [PATCH 11/11] ARM: dts: sun8i: a83t: h8homlet: Enable micro-SD card and onboard eMMC

FromChen-Yu Tsai <wens@csie.org>
Date2017-07-14 08:50 +0200
Subject[PATCH 11/11] ARM: dts: sun8i: a83t: h8homlet: Enable micro-SD card and onboard eMMC
Message-ID<u32Ai-84Q-17@gated-at.bofh.it>
In reply to#1687095
The H8 homlet has a micro-SD card slot connected to mmc0,
and onboard eMMC from FORESEE, connected to mmc2.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 .../boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts   | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts b/arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts
index aecdeeb368ed..7afbaa4eea8d 100644
--- a/arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts
@@ -43,6 +43,7 @@
 
 /dts-v1/;
 #include "sun8i-a83t.dtsi"
+#include "sunxi-common-regulators.dtsi"
 
 / {
 	model = "Allwinner A83T H8Homlet Proto Dev Board v2.0";
@@ -57,6 +58,26 @@
 	};
 };
 
+&mmc0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc0_pins>;
+	vmmc-supply = <&reg_vcc3v0>;
+	cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
+	bus-width = <4>;
+	cd-inverted;
+	status = "okay";
+};
+
+&mmc2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc2_8bit_emmc_pins>;
+	vmmc-supply = <&reg_vcc3v0>;
+	bus-width = <8>;
+	non-removable;
+	cap-mmc-hw-reset;
+	status = "okay";
+};
+
 &uart0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart0_pb_pins>;
-- 
2.13.2

[toc] | [prev] | [next] | [standalone]


#1687098 — [PATCH 04/11] mmc: sunxi: Keep default timing phase settings for new timing mode

FromChen-Yu Tsai <wens@csie.org>
Date2017-07-14 08:50 +0200
Subject[PATCH 04/11] mmc: sunxi: Keep default timing phase settings for new timing mode
Message-ID<u32Ai-84Q-19@gated-at.bofh.it>
In reply to#1687095
The register for the "new timing mode" also has bit fields for setting
output and sample timing phases. According to comments in Allwinner's
BSP kernel, the default values are good enough.

Keep the default values already in the hardware when setting new timing
mode, instead of overwriting the whole register.

Fixes: 9a37e53e451e ("mmc: sunxi: Enable the new timings for the A64 MMC
		      controllers")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 drivers/mmc/host/sunxi-mmc.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index d6fa2214aaae..0fb4e4c119e1 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -793,8 +793,12 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
 	}
 	mmc_writel(host, REG_CLKCR, rval);
 
-	if (host->cfg->needs_new_timings)
-		mmc_writel(host, REG_SD_NTSR, SDXC_2X_TIMING_MODE);
+	if (host->cfg->needs_new_timings) {
+		/* Don't touch the delay bits */
+		rval = mmc_readl(host, REG_SD_NTSR);
+		rval |= SDXC_2X_TIMING_MODE;
+		mmc_writel(host, REG_SD_NTSR, rval);
+	}
 
 	ret = sunxi_mmc_clk_set_phase(host, ios, rate);
 	if (ret)
-- 
2.13.2

[toc] | [prev] | [next] | [standalone]


#1687177 — Re: [PATCH 04/11] mmc: sunxi: Keep default timing phase settings for new timing mode

FromUlf Hansson <ulf.hansson@linaro.org>
Date2017-07-14 11:20 +0200
SubjectRe: [PATCH 04/11] mmc: sunxi: Keep default timing phase settings for new timing mode
Message-ID<u34Vt-1k8-15@gated-at.bofh.it>
In reply to#1687098
On 14 July 2017 at 08:42, Chen-Yu Tsai <wens@csie.org> wrote:
> The register for the "new timing mode" also has bit fields for setting
> output and sample timing phases. According to comments in Allwinner's
> BSP kernel, the default values are good enough.
>
> Keep the default values already in the hardware when setting new timing
> mode, instead of overwriting the whole register.
>
> Fixes: 9a37e53e451e ("mmc: sunxi: Enable the new timings for the A64 MMC
>                       controllers")
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>

It looks like this change doesn't depend on anything else? Do you want
me to pick it up for fixes and adding stable tag?

Kind regards
Uffe

> ---
>  drivers/mmc/host/sunxi-mmc.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index d6fa2214aaae..0fb4e4c119e1 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -793,8 +793,12 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
>         }
>         mmc_writel(host, REG_CLKCR, rval);
>
> -       if (host->cfg->needs_new_timings)
> -               mmc_writel(host, REG_SD_NTSR, SDXC_2X_TIMING_MODE);
> +       if (host->cfg->needs_new_timings) {
> +               /* Don't touch the delay bits */
> +               rval = mmc_readl(host, REG_SD_NTSR);
> +               rval |= SDXC_2X_TIMING_MODE;
> +               mmc_writel(host, REG_SD_NTSR, rval);
> +       }
>
>         ret = sunxi_mmc_clk_set_phase(host, ios, rate);
>         if (ret)
> --
> 2.13.2
>

[toc] | [prev] | [next] | [standalone]


#1687203 — Re: [PATCH 04/11] mmc: sunxi: Keep default timing phase settings for new timing mode

FromChen-Yu Tsai <wens@csie.org>
Date2017-07-14 11:50 +0200
SubjectRe: [PATCH 04/11] mmc: sunxi: Keep default timing phase settings for new timing mode
Message-ID<u35ot-1yc-1@gated-at.bofh.it>
In reply to#1687177
On Fri, Jul 14, 2017 at 5:16 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On 14 July 2017 at 08:42, Chen-Yu Tsai <wens@csie.org> wrote:
>> The register for the "new timing mode" also has bit fields for setting
>> output and sample timing phases. According to comments in Allwinner's
>> BSP kernel, the default values are good enough.
>>
>> Keep the default values already in the hardware when setting new timing
>> mode, instead of overwriting the whole register.
>>
>> Fixes: 9a37e53e451e ("mmc: sunxi: Enable the new timings for the A64 MMC
>>                       controllers")
>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>
> It looks like this change doesn't depend on anything else? Do you want
> me to pick it up for fixes and adding stable tag?

Yes, please.

ChenYu

>
> Kind regards
> Uffe
>
>> ---
>>  drivers/mmc/host/sunxi-mmc.c | 8 ++++++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
>> index d6fa2214aaae..0fb4e4c119e1 100644
>> --- a/drivers/mmc/host/sunxi-mmc.c
>> +++ b/drivers/mmc/host/sunxi-mmc.c
>> @@ -793,8 +793,12 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
>>         }
>>         mmc_writel(host, REG_CLKCR, rval);
>>
>> -       if (host->cfg->needs_new_timings)
>> -               mmc_writel(host, REG_SD_NTSR, SDXC_2X_TIMING_MODE);
>> +       if (host->cfg->needs_new_timings) {
>> +               /* Don't touch the delay bits */
>> +               rval = mmc_readl(host, REG_SD_NTSR);
>> +               rval |= SDXC_2X_TIMING_MODE;
>> +               mmc_writel(host, REG_SD_NTSR, rval);
>> +       }
>>
>>         ret = sunxi_mmc_clk_set_phase(host, ios, rate);
>>         if (ret)
>> --
>> 2.13.2
>>

[toc] | [prev] | [next] | [standalone]


#1688803 — Re: [PATCH 04/11] mmc: sunxi: Keep default timing phase settings for new timing mode

FromMaxime Ripard <maxime.ripard@free-electrons.com>
Date2017-07-17 11:20 +0200
SubjectRe: [PATCH 04/11] mmc: sunxi: Keep default timing phase settings for new timing mode
Message-ID<u4am7-37p-39@gated-at.bofh.it>
In reply to#1687098

[Multipart message — attachments visible in raw view] — view raw

On Fri, Jul 14, 2017 at 02:42:55PM +0800, Chen-Yu Tsai wrote:
> The register for the "new timing mode" also has bit fields for setting
> output and sample timing phases. According to comments in Allwinner's
> BSP kernel, the default values are good enough.
> 
> Keep the default values already in the hardware when setting new timing
> mode, instead of overwriting the whole register.
> 
> Fixes: 9a37e53e451e ("mmc: sunxi: Enable the new timings for the A64 MMC
> 		      controllers")
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>

Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]


#1688871 — Re: [PATCH 04/11] mmc: sunxi: Keep default timing phase settings for new timing mode

FromUlf Hansson <ulf.hansson@linaro.org>
Date2017-07-17 12:40 +0200
SubjectRe: [PATCH 04/11] mmc: sunxi: Keep default timing phase settings for new timing mode
Message-ID<u4bBx-3PU-39@gated-at.bofh.it>
In reply to#1687098
+stable

On 14 July 2017 at 08:42, Chen-Yu Tsai <wens@csie.org> wrote:
> The register for the "new timing mode" also has bit fields for setting
> output and sample timing phases. According to comments in Allwinner's
> BSP kernel, the default values are good enough.
>
> Keep the default values already in the hardware when setting new timing
> mode, instead of overwriting the whole register.
>
> Fixes: 9a37e53e451e ("mmc: sunxi: Enable the new timings for the A64 MMC
>                       controllers")
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>

Thanks, applied for fixes and added a stable tag.

Kind regards
Uffe

> ---
>  drivers/mmc/host/sunxi-mmc.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index d6fa2214aaae..0fb4e4c119e1 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -793,8 +793,12 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
>         }
>         mmc_writel(host, REG_CLKCR, rval);
>
> -       if (host->cfg->needs_new_timings)
> -               mmc_writel(host, REG_SD_NTSR, SDXC_2X_TIMING_MODE);
> +       if (host->cfg->needs_new_timings) {
> +               /* Don't touch the delay bits */
> +               rval = mmc_readl(host, REG_SD_NTSR);
> +               rval |= SDXC_2X_TIMING_MODE;
> +               mmc_writel(host, REG_SD_NTSR, rval);
> +       }
>
>         ret = sunxi_mmc_clk_set_phase(host, ios, rate);
>         if (ret)
> --
> 2.13.2
>

[toc] | [prev] | [next] | [standalone]


#1687099 — [PATCH 09/11] ARM: dts: sun8i: a83t: Add pingroup for 8-bit eMMC on mmc2

FromChen-Yu Tsai <wens@csie.org>
Date2017-07-14 08:50 +0200
Subject[PATCH 09/11] ARM: dts: sun8i: a83t: Add pingroup for 8-bit eMMC on mmc2
Message-ID<u32Ai-84Q-21@gated-at.bofh.it>
In reply to#1687095
mmc2 can support 8-bit eMMC chips, with a dedicated reset line.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 085312d0c521..b1198d80873e 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -269,6 +269,15 @@
 				bias-pull-up;
 			};
 
+			mmc2_8bit_emmc_pins: mmc2-8bit-emmc-pins {
+				pins = "PC5", "PC6", "PC8", "PC9",
+				       "PC10", "PC11", "PC12", "PC13",
+				       "PC14", "PC15", "PC16";
+				function = "mmc2";
+				drive-strength = <30>;
+				bias-pull-up;
+			};
+
 			spdif_tx_pin: spdif-tx-pin {
 				pins = "PE18";
 				function = "spdif";
-- 
2.13.2

[toc] | [prev] | [next] | [standalone]


#1687101 — [PATCH 01/11] ARM: dts: sun8i: a83t: Switch to CCU device tree binding macros

FromChen-Yu Tsai <wens@csie.org>
Date2017-07-14 08:50 +0200
Subject[PATCH 01/11] ARM: dts: sun8i: a83t: Switch to CCU device tree binding macros
Message-ID<u32Ai-84Q-27@gated-at.bofh.it>
In reply to#1687095
Now that the CCU device tree binding headers have been merged, we can
use the properly named macros in the device tree, instead of raw
numbers.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---

This patch is included as it is a pre-requisite to the other device
tree changes in this series. It is however independent, and should
be applied as a fix for 4.13-rc, not for -next, and preferably sooner
than later.

---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 21439d0aa55d..beed05e10a3b 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -44,7 +44,9 @@
 
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 
+#include <dt-bindings/clock/sun8i-a83t-ccu.h>
 #include <dt-bindings/clock/sun8i-r-ccu.h>
+#include <dt-bindings/reset/sun8i-a83t-ccu.h>
 
 / {
 	interrupt-parent = <&gic>;
@@ -175,8 +177,8 @@
 			compatible = "allwinner,sun8i-a83t-dma";
 			reg = <0x01c02000 0x1000>;
 			interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&ccu 21>;
-			resets = <&ccu 7>;
+			clocks = <&ccu CLK_BUS_DMA>;
+			resets = <&ccu RST_BUS_DMA>;
 			#dma-cells = <1>;
 		};
 
@@ -195,7 +197,7 @@
 				     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
 			reg = <0x01c20800 0x400>;
-			clocks = <&ccu 45>, <&osc24M>, <&osc16Md512>;
+			clocks = <&ccu CLK_BUS_PIO>, <&osc24M>, <&osc16Md512>;
 			clock-names = "apb", "hosc", "losc";
 			gpio-controller;
 			interrupt-controller;
@@ -247,8 +249,8 @@
 				     "allwinner,sun8i-h3-spdif";
 			reg = <0x01c21000 0x400>;
 			interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&ccu 44>, <&ccu 76>;
-			resets = <&ccu 32>;
+			clocks = <&ccu CLK_BUS_SPDIF>, <&ccu CLK_SPDIF>;
+			resets = <&ccu RST_BUS_SPDIF>;
 			clock-names = "apb", "spdif";
 			dmas = <&dma 2>;
 			dma-names = "tx";
@@ -263,8 +265,8 @@
 			interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
 			reg-shift = <2>;
 			reg-io-width = <4>;
-			clocks = <&ccu 53>;
-			resets = <&ccu 40>;
+			clocks = <&ccu CLK_BUS_UART0>;
+			resets = <&ccu RST_BUS_UART0>;
 			status = "disabled";
 		};
 
-- 
2.13.2

[toc] | [prev] | [next] | [standalone]


#1688788 — Re: [PATCH 01/11] ARM: dts: sun8i: a83t: Switch to CCU device tree binding macros

FromMaxime Ripard <maxime.ripard@free-electrons.com>
Date2017-07-17 11:10 +0200
SubjectRe: [PATCH 01/11] ARM: dts: sun8i: a83t: Switch to CCU device tree binding macros
Message-ID<u4acr-32J-15@gated-at.bofh.it>
In reply to#1687101

[Multipart message — attachments visible in raw view] — view raw

On Fri, Jul 14, 2017 at 02:42:52PM +0800, Chen-Yu Tsai wrote:
> Now that the CCU device tree binding headers have been merged, we can
> use the properly named macros in the device tree, instead of raw
> numbers.
> 
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
> 
> This patch is included as it is a pre-requisite to the other device
> tree changes in this series. It is however independent, and should
> be applied as a fix for 4.13-rc, not for -next, and preferably sooner
> than later.

Applied as a fix for 4.13, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]


#1687102 — [PATCH 02/11] clk: sunxi-ng: Add interface to query or configure MMC timing modes.

FromChen-Yu Tsai <wens@csie.org>
Date2017-07-14 08:50 +0200
Subject[PATCH 02/11] clk: sunxi-ng: Add interface to query or configure MMC timing modes.
Message-ID<u32Aj-84Q-29@gated-at.bofh.it>
In reply to#1687095
Starting with the A83T SoC, Allwinner introduced a new timing mode for
its MMC clocks. The new mode changes how the MMC controller sample and
output clocks are delayed to match chip and board specifics. There are
two controls for this, one on the CCU side controlling how the clocks
behave, and one in the MMC controller controlling what inputs to take
and how to route them.

In the old mode, the MMC clock had 2 child clocks providing the output
and sample clocks, which could be delayed by a number of clock cycles
measured from the MMC clock's parent.

With the new mode, the 2 delay clocks are no longer active. Instead,
the delays and associated controls are moved into the MMC controller.
The output of the MMC clock is also halved.

The difference in how things are wired between the modes means that the
clock controls and the MMC controls must match. To achieve this in a
clear, explicit way, we introduce two functions for the MMC driver to
use: one queries the hardware for the current mode set, and the other
allows the MMC driver to request a mode.

With newer SoCs such as the A64, the old mode is all but removed. Hence
we support two variations, one where the mode can be toggled, and the
other where the clock is fixed in the new mode.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 drivers/clk/sunxi-ng/Makefile         |  1 +
 drivers/clk/sunxi-ng/ccu_common.h     |  2 +
 drivers/clk/sunxi-ng/ccu_mmc_timing.c | 73 +++++++++++++++++++++++++++++++++++
 include/linux/clk/sunxi-ng.h          | 20 ++++++++++
 4 files changed, 96 insertions(+)
 create mode 100644 drivers/clk/sunxi-ng/ccu_mmc_timing.c
 create mode 100644 include/linux/clk/sunxi-ng.h

diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
index 0c45fa50283d..45a5910379a5 100644
--- a/drivers/clk/sunxi-ng/Makefile
+++ b/drivers/clk/sunxi-ng/Makefile
@@ -1,5 +1,6 @@
 # Common objects
 lib-$(CONFIG_SUNXI_CCU)		+= ccu_common.o
+lib-$(CONFIG_SUNXI_CCU)		+= ccu_mmc_timing.o
 lib-$(CONFIG_SUNXI_CCU)		+= ccu_reset.o
 
 # Base clock types
diff --git a/drivers/clk/sunxi-ng/ccu_common.h b/drivers/clk/sunxi-ng/ccu_common.h
index d6fdd7a789aa..88981e7fd978 100644
--- a/drivers/clk/sunxi-ng/ccu_common.h
+++ b/drivers/clk/sunxi-ng/ccu_common.h
@@ -23,6 +23,8 @@
 #define CCU_FEATURE_FIXED_POSTDIV	BIT(3)
 #define CCU_FEATURE_ALL_PREDIV		BIT(4)
 #define CCU_FEATURE_LOCK_REG		BIT(5)
+#define CCU_FEATURE_MMC_TIMING_SWITCH	BIT(6)
+#define CCU_FEATURE_MMC_ALWAYS_NEW	BIT(7)
 
 struct device_node;
 
diff --git a/drivers/clk/sunxi-ng/ccu_mmc_timing.c b/drivers/clk/sunxi-ng/ccu_mmc_timing.c
new file mode 100644
index 000000000000..f236a56abf48
--- /dev/null
+++ b/drivers/clk/sunxi-ng/ccu_mmc_timing.c
@@ -0,0 +1,73 @@
+/*
+ * Copyright (c) 2017 Chen-Yu Tsai. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/clk/sunxi-ng.h>
+
+#include "ccu_common.h"
+
+#define CCU_MMC_NEW_TIMING_MODE		BIT(30)
+
+/**
+ * sunxi_ccu_set_mmc_timing_mode: Configure the MMC clock timing mode
+ * @clk: clock to be configured
+ * @new_mode: true for new timing mode introduced in A83T and later
+ *
+ * Returns 0 on success, -ENOTSUPP if the clock does not support
+ * switching modes.
+ */
+int sunxi_ccu_set_mmc_timing_mode(struct clk *clk, bool new_mode)
+{
+	struct clk_hw *hw = __clk_get_hw(clk);
+	struct ccu_common *cm = hw_to_ccu_common(hw);
+	unsigned long flags;
+	u32 val;
+
+	if (!(cm->features & CCU_FEATURE_MMC_TIMING_SWITCH))
+		return -ENOTSUPP;
+
+	spin_lock_irqsave(cm->lock, flags);
+
+	val = readl(cm->base + cm->reg);
+	if (new_mode)
+		val |= CCU_MMC_NEW_TIMING_MODE;
+	else
+		val &= ~CCU_MMC_NEW_TIMING_MODE;
+	writel(val, cm->base + cm->reg);
+
+	spin_unlock_irqrestore(cm->lock, flags);
+
+	return 0;
+}
+
+/**
+ * sunxi_ccu_set_mmc_timing_mode: Get the current MMC clock timing mode
+ * @clk: clock to query
+ *
+ * Returns 0 if the clock is in old timing mode, > 0 if it is in
+ * new timing mode, and -ENOTSUPP if the clock does not support
+ * this function.
+ */
+int sunxi_ccu_get_mmc_timing_mode(struct clk *clk)
+{
+	struct clk_hw *hw = __clk_get_hw(clk);
+	struct ccu_common *cm = hw_to_ccu_common(hw);
+
+	if (cm->features & CCU_FEATURE_MMC_ALWAYS_NEW)
+		return 1;
+
+	if (!(cm->features & CCU_FEATURE_MMC_TIMING_SWITCH))
+		return -ENOTSUPP;
+
+	return !!(readl(cm->base + cm->reg) & CCU_MMC_NEW_TIMING_MODE);
+}
diff --git a/include/linux/clk/sunxi-ng.h b/include/linux/clk/sunxi-ng.h
new file mode 100644
index 000000000000..f1bd321fc264
--- /dev/null
+++ b/include/linux/clk/sunxi-ng.h
@@ -0,0 +1,20 @@
+/*
+ * Copyright (c) 2017 Chen-Yu Tsai. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _LINUX_CLK_SUNXI_NG_H_
+#define _LINUX_CLK_SUNXI_NG_H_
+
+int sunxi_ccu_set_mmc_timing_mode(struct clk *clk, bool new_mode);
+int sunxi_ccu_get_mmc_timing_mode(struct clk *clk);
+
+#endif
-- 
2.13.2

[toc] | [prev] | [next] | [standalone]


#1688804 — Re: [PATCH 02/11] clk: sunxi-ng: Add interface to query or configure MMC timing modes.

FromMaxime Ripard <maxime.ripard@free-electrons.com>
Date2017-07-17 11:20 +0200
SubjectRe: [PATCH 02/11] clk: sunxi-ng: Add interface to query or configure MMC timing modes.
Message-ID<u4am7-37p-43@gated-at.bofh.it>
In reply to#1687102

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Fri, Jul 14, 2017 at 02:42:53PM +0800, Chen-Yu Tsai wrote:
> Starting with the A83T SoC, Allwinner introduced a new timing mode for
> its MMC clocks. The new mode changes how the MMC controller sample and
> output clocks are delayed to match chip and board specifics. There are
> two controls for this, one on the CCU side controlling how the clocks
> behave, and one in the MMC controller controlling what inputs to take
> and how to route them.
> 
> In the old mode, the MMC clock had 2 child clocks providing the output
> and sample clocks, which could be delayed by a number of clock cycles
> measured from the MMC clock's parent.
> 
> With the new mode, the 2 delay clocks are no longer active. Instead,
> the delays and associated controls are moved into the MMC controller.
> The output of the MMC clock is also halved.
> 
> The difference in how things are wired between the modes means that the
> clock controls and the MMC controls must match. To achieve this in a
> clear, explicit way, we introduce two functions for the MMC driver to
> use: one queries the hardware for the current mode set, and the other
> allows the MMC driver to request a mode.
> 
> With newer SoCs such as the A64, the old mode is all but removed. Hence
> we support two variations, one where the mode can be toggled, and the
> other where the clock is fixed in the new mode.
> 
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
>  drivers/clk/sunxi-ng/Makefile         |  1 +
>  drivers/clk/sunxi-ng/ccu_common.h     |  2 +
>  drivers/clk/sunxi-ng/ccu_mmc_timing.c | 73 +++++++++++++++++++++++++++++++++++
>  include/linux/clk/sunxi-ng.h          | 20 ++++++++++
>  4 files changed, 96 insertions(+)
>  create mode 100644 drivers/clk/sunxi-ng/ccu_mmc_timing.c
>  create mode 100644 include/linux/clk/sunxi-ng.h
> 
> diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
> index 0c45fa50283d..45a5910379a5 100644
> --- a/drivers/clk/sunxi-ng/Makefile
> +++ b/drivers/clk/sunxi-ng/Makefile
> @@ -1,5 +1,6 @@
>  # Common objects
>  lib-$(CONFIG_SUNXI_CCU)		+= ccu_common.o
> +lib-$(CONFIG_SUNXI_CCU)		+= ccu_mmc_timing.o
>  lib-$(CONFIG_SUNXI_CCU)		+= ccu_reset.o
>  
>  # Base clock types
> diff --git a/drivers/clk/sunxi-ng/ccu_common.h b/drivers/clk/sunxi-ng/ccu_common.h
> index d6fdd7a789aa..88981e7fd978 100644
> --- a/drivers/clk/sunxi-ng/ccu_common.h
> +++ b/drivers/clk/sunxi-ng/ccu_common.h
> @@ -23,6 +23,8 @@
>  #define CCU_FEATURE_FIXED_POSTDIV	BIT(3)
>  #define CCU_FEATURE_ALL_PREDIV		BIT(4)
>  #define CCU_FEATURE_LOCK_REG		BIT(5)
> +#define CCU_FEATURE_MMC_TIMING_SWITCH	BIT(6)
> +#define CCU_FEATURE_MMC_ALWAYS_NEW	BIT(7)

I'm not really sure we need the ALWAYS_NEW bit here. In the case where
the clocks cannot operate in the old mode any more, we won't even
query the clocks, since we know that it's not needed at all.

Pretty much just like what we're doing for old-mode-only clocks at the
moment.

I guess the only thing we should indentify is whether the clock can
switch between the two, or not, and the MMC_TIMING_SWITCH bit is
already perfect for that.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]


#1687104 — [PATCH 08/11] ARM: dts: sun8i: a83t: Add MMC controller device nodes

FromChen-Yu Tsai <wens@csie.org>
Date2017-07-14 08:50 +0200
Subject[PATCH 08/11] ARM: dts: sun8i: a83t: Add MMC controller device nodes
Message-ID<u32Aj-84Q-37@gated-at.bofh.it>
In reply to#1687095
The A83T has 3 MMC controllers. The third one is a bit special, as it
supports a wider 8-bit bus, and a "new timing mode".

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 57 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 57 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index beed05e10a3b..085312d0c521 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -182,6 +182,63 @@
 			#dma-cells = <1>;
 		};
 
+		mmc0: mmc@1c0f000 {
+			compatible = "allwinner,sun7i-a20-mmc";
+			reg = <0x01c0f000 0x1000>;
+			clocks = <&ccu CLK_BUS_MMC0>,
+				 <&ccu CLK_MMC0>,
+				 <&ccu CLK_MMC0_OUTPUT>,
+				 <&ccu CLK_MMC0_SAMPLE>;
+			clock-names = "ahb",
+				      "mmc",
+				      "output",
+				      "sample";
+			resets = <&ccu RST_BUS_MMC0>;
+			reset-names = "ahb";
+			interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		mmc1: mmc@1c10000 {
+			compatible = "allwinner,sun7i-a20-mmc";
+			reg = <0x01c10000 0x1000>;
+			clocks = <&ccu CLK_BUS_MMC1>,
+				 <&ccu CLK_MMC1>,
+				 <&ccu CLK_MMC1_OUTPUT>,
+				 <&ccu CLK_MMC1_SAMPLE>;
+			clock-names = "ahb",
+				      "mmc",
+				      "output",
+				      "sample";
+			resets = <&ccu RST_BUS_MMC1>;
+			reset-names = "ahb";
+			interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		mmc2: mmc@1c11000 {
+			compatible = "allwinner,sun8i-a83t-emmc";
+			reg = <0x01c11000 0x1000>;
+			clocks = <&ccu CLK_BUS_MMC2>,
+				 <&ccu CLK_MMC2>,
+				 <&ccu CLK_MMC2_OUTPUT>,
+				 <&ccu CLK_MMC2_SAMPLE>;
+			clock-names = "ahb",
+				      "mmc",
+				      "output",
+				      "sample";
+			resets = <&ccu RST_BUS_MMC2>;
+			reset-names = "ahb";
+			interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
 		ccu: clock@1c20000 {
 			compatible = "allwinner,sun8i-a83t-ccu";
 			reg = <0x01c20000 0x400>;
-- 
2.13.2

[toc] | [prev] | [next] | [standalone]


#1688817 — Re: [PATCH 08/11] ARM: dts: sun8i: a83t: Add MMC controller device nodes

FromMaxime Ripard <maxime.ripard@free-electrons.com>
Date2017-07-17 11:30 +0200
SubjectRe: [PATCH 08/11] ARM: dts: sun8i: a83t: Add MMC controller device nodes
Message-ID<u4avM-3bA-17@gated-at.bofh.it>
In reply to#1687104

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Fri, Jul 14, 2017 at 02:42:59PM +0800, Chen-Yu Tsai wrote:
> The A83T has 3 MMC controllers. The third one is a bit special, as it
> supports a wider 8-bit bus, and a "new timing mode".
> 
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
>  arch/arm/boot/dts/sun8i-a83t.dtsi | 57 +++++++++++++++++++++++++++++++++++++++
>  1 file changed, 57 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
> index beed05e10a3b..085312d0c521 100644
> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
> @@ -182,6 +182,63 @@
>  			#dma-cells = <1>;
>  		};
>  
> +		mmc0: mmc@1c0f000 {
> +			compatible = "allwinner,sun7i-a20-mmc";

Ideally, we should have an A83T compatible here too, just in case.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]


#1687106 — [PATCH 07/11] mmc: sunxi: Add support for A83T eMMC (MMC2)

FromChen-Yu Tsai <wens@csie.org>
Date2017-07-14 08:50 +0200
Subject[PATCH 07/11] mmc: sunxi: Add support for A83T eMMC (MMC2)
Message-ID<u32Aj-84Q-35@gated-at.bofh.it>
In reply to#1687095
The third MMC controller (MMC2) on the Allwinner A83T SoC is slightly
different. It supports a wider 8-bit bus, has a dedicated controllable
reset pin for eMMC, and a "new timing mode" which is supposed to deliver
better signals and thus better performance.

Add a compatible for this one to use the new timing mode not found in the
other controllers.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 Documentation/devicetree/bindings/mmc/sunxi-mmc.txt | 1 +
 drivers/mmc/host/sunxi-mmc.c                        | 8 ++++++++
 2 files changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
index 7d53a799f140..63b57e2a10fb 100644
--- a/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
@@ -12,6 +12,7 @@ Required properties:
    * "allwinner,sun4i-a10-mmc"
    * "allwinner,sun5i-a13-mmc"
    * "allwinner,sun7i-a20-mmc"
+   * "allwinner,sun8i-a83t-emmc"
    * "allwinner,sun9i-a80-mmc"
    * "allwinner,sun50i-a64-emmc"
    * "allwinner,sun50i-a64-mmc"
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 7b6f5f49620e..e70065dbd50e 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -1113,6 +1113,13 @@ static const struct sunxi_mmc_cfg sun7i_a20_cfg = {
 	.can_calibrate = false,
 };
 
+static const struct sunxi_mmc_cfg sun8i_a83t_emmc_cfg = {
+	.idma_des_size_bits = 16,
+	.clk_delays = sunxi_mmc_clk_delays,
+	.can_calibrate = false,
+	.has_new_timings = true,
+};
+
 static const struct sunxi_mmc_cfg sun9i_a80_cfg = {
 	.idma_des_size_bits = 16,
 	.clk_delays = sun9i_mmc_clk_delays,
@@ -1137,6 +1144,7 @@ static const struct of_device_id sunxi_mmc_of_match[] = {
 	{ .compatible = "allwinner,sun4i-a10-mmc", .data = &sun4i_a10_cfg },
 	{ .compatible = "allwinner,sun5i-a13-mmc", .data = &sun5i_a13_cfg },
 	{ .compatible = "allwinner,sun7i-a20-mmc", .data = &sun7i_a20_cfg },
+	{ .compatible = "allwinner,sun8i-a83t-emmc", .data = &sun8i_a83t_emmc_cfg },
 	{ .compatible = "allwinner,sun9i-a80-mmc", .data = &sun9i_a80_cfg },
 	{ .compatible = "allwinner,sun50i-a64-mmc", .data = &sun50i_a64_cfg },
 	{ .compatible = "allwinner,sun50i-a64-emmc", .data = &sun50i_a64_emmc_cfg },
-- 
2.13.2

[toc] | [prev] | [next] | [standalone]


#1689353 — Re: [PATCH 07/11] mmc: sunxi: Add support for A83T eMMC (MMC2)

FromRob Herring <robh@kernel.org>
Date2017-07-17 21:00 +0200
SubjectRe: [PATCH 07/11] mmc: sunxi: Add support for A83T eMMC (MMC2)
Message-ID<u4jpo-hn-27@gated-at.bofh.it>
In reply to#1687106
On Fri, Jul 14, 2017 at 02:42:58PM +0800, Chen-Yu Tsai wrote:
> The third MMC controller (MMC2) on the Allwinner A83T SoC is slightly
> different. It supports a wider 8-bit bus, has a dedicated controllable
> reset pin for eMMC, and a "new timing mode" which is supposed to deliver
> better signals and thus better performance.
> 
> Add a compatible for this one to use the new timing mode not found in the
> other controllers.
> 
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
>  Documentation/devicetree/bindings/mmc/sunxi-mmc.txt | 1 +

Acked-by: Rob Herring <robh@kernel.org>

>  drivers/mmc/host/sunxi-mmc.c                        | 8 ++++++++
>  2 files changed, 9 insertions(+)

[toc] | [prev] | [next] | [standalone]


#1687110 — [PATCH 05/11] mmc: sunxi: Support controllers that can use both old and new timings

FromChen-Yu Tsai <wens@csie.org>
Date2017-07-14 08:50 +0200
Subject[PATCH 05/11] mmc: sunxi: Support controllers that can use both old and new timings
Message-ID<u32Aj-84Q-47@gated-at.bofh.it>
In reply to#1687095
On the SoCs that introduced the new timing mode for MMC controllers,
both the old (where the clock delays are set in the CCU) and new
(where the clock delays are set in the MMC controller) timing modes
are available, and we have to support them both. However there are
two bits that control which mode is active. One is in the CCU, the
other is in the MMC controller. The settings on both sides must be
the same, or nothing will work.

The CCU's get/set_phase callbacks return -ENOTSUPP when the new
timing mode is active. This provides a way to know which mode is
active on that side, and we can set the bit on the MMC controller
side accordingly.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 drivers/mmc/host/sunxi-mmc.c | 34 ++++++++++++++++++++++++++++++----
 1 file changed, 30 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 0fb4e4c119e1..56e45c65b52d 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -22,6 +22,7 @@
 #include <linux/err.h>
 
 #include <linux/clk.h>
+#include <linux/clk/sunxi-ng.h>
 #include <linux/gpio.h>
 #include <linux/platform_device.h>
 #include <linux/spinlock.h>
@@ -259,7 +260,7 @@ struct sunxi_mmc_cfg {
 	/* Does DATA0 needs to be masked while the clock is updated */
 	bool mask_data0;
 
-	bool needs_new_timings;
+	bool has_new_timings;
 };
 
 struct sunxi_mmc_host {
@@ -293,6 +294,9 @@ struct sunxi_mmc_host {
 
 	/* vqmmc */
 	bool		vqmmc_enabled;
+
+	/* timings */
+	bool		use_new_timings;
 };
 
 static int sunxi_mmc_reset_host(struct sunxi_mmc_host *host)
@@ -714,7 +718,7 @@ static int sunxi_mmc_clk_set_phase(struct sunxi_mmc_host *host,
 {
 	int index;
 
-	if (!host->cfg->clk_delays)
+	if (host->use_new_timings)
 		return 0;
 
 	/* determine delays */
@@ -765,6 +769,15 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
 	    ios->bus_width == MMC_BUS_WIDTH_8)
 		clock <<= 1;
 
+	if (host->use_new_timings) {
+		ret = sunxi_ccu_set_mmc_timing_mode(host->clk_mmc, true);
+		if (ret) {
+			dev_err(mmc_dev(mmc),
+				"error setting new timing mode\n");
+			return ret;
+		}
+	}
+
 	rate = clk_round_rate(host->clk_mmc, clock);
 	if (rate < 0) {
 		dev_err(mmc_dev(mmc), "error rounding clk to %d: %ld\n",
@@ -793,7 +806,7 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
 	}
 	mmc_writel(host, REG_CLKCR, rval);
 
-	if (host->cfg->needs_new_timings) {
+	if (host->use_new_timings) {
 		/* Don't touch the delay bits */
 		rval = mmc_readl(host, REG_SD_NTSR);
 		rval |= SDXC_2X_TIMING_MODE;
@@ -1105,7 +1118,7 @@ static const struct sunxi_mmc_cfg sun50i_a64_cfg = {
 	.clk_delays = NULL,
 	.can_calibrate = true,
 	.mask_data0 = true,
-	.needs_new_timings = true,
+	.has_new_timings = true,
 };
 
 static const struct sunxi_mmc_cfg sun50i_a64_emmc_cfg = {
@@ -1262,6 +1275,19 @@ static int sunxi_mmc_probe(struct platform_device *pdev)
 		goto error_free_host;
 	}
 
+	if (host->cfg->clk_delays && host->cfg->has_new_timings) {
+		/*
+		 * Supports both old and new timing modes.
+		 * Try setting the clk to new timing mode.
+		 */
+		ret = sunxi_ccu_set_mmc_timing_mode(host->clk_mmc, true);
+		if (!ret)
+			host->use_new_timings = true;
+	} else if (host->cfg->has_new_timings) {
+		/* Supports new timing mode only */
+		host->use_new_timings = true;
+	}
+
 	mmc->ops		= &sunxi_mmc_ops;
 	mmc->max_blk_count	= 8192;
 	mmc->max_blk_size	= 4096;
-- 
2.13.2

[toc] | [prev] | [next] | [standalone]


#1687180 — Re: [PATCH 05/11] mmc: sunxi: Support controllers that can use both old and new timings

FromUlf Hansson <ulf.hansson@linaro.org>
Date2017-07-14 11:30 +0200
SubjectRe: [PATCH 05/11] mmc: sunxi: Support controllers that can use both old and new timings
Message-ID<u3558-1oP-5@gated-at.bofh.it>
In reply to#1687110
On 14 July 2017 at 08:42, Chen-Yu Tsai <wens@csie.org> wrote:
> On the SoCs that introduced the new timing mode for MMC controllers,
> both the old (where the clock delays are set in the CCU) and new
> (where the clock delays are set in the MMC controller) timing modes
> are available, and we have to support them both. However there are
> two bits that control which mode is active. One is in the CCU, the
> other is in the MMC controller. The settings on both sides must be
> the same, or nothing will work.
>
> The CCU's get/set_phase callbacks return -ENOTSUPP when the new
> timing mode is active. This provides a way to know which mode is
> active on that side, and we can set the bit on the MMC controller
> side accordingly.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
>  drivers/mmc/host/sunxi-mmc.c | 34 ++++++++++++++++++++++++++++++----
>  1 file changed, 30 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index 0fb4e4c119e1..56e45c65b52d 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -22,6 +22,7 @@
>  #include <linux/err.h>
>
>  #include <linux/clk.h>
> +#include <linux/clk/sunxi-ng.h>

I don't like this. This looks like an SoC specific hack.

>  #include <linux/gpio.h>
>  #include <linux/platform_device.h>
>  #include <linux/spinlock.h>
> @@ -259,7 +260,7 @@ struct sunxi_mmc_cfg {
>         /* Does DATA0 needs to be masked while the clock is updated */
>         bool mask_data0;
>
> -       bool needs_new_timings;
> +       bool has_new_timings;
>  };
>
>  struct sunxi_mmc_host {
> @@ -293,6 +294,9 @@ struct sunxi_mmc_host {
>
>         /* vqmmc */
>         bool            vqmmc_enabled;
> +
> +       /* timings */
> +       bool            use_new_timings;
>  };
>
>  static int sunxi_mmc_reset_host(struct sunxi_mmc_host *host)
> @@ -714,7 +718,7 @@ static int sunxi_mmc_clk_set_phase(struct sunxi_mmc_host *host,
>  {
>         int index;
>
> -       if (!host->cfg->clk_delays)
> +       if (host->use_new_timings)
>                 return 0;
>
>         /* determine delays */
> @@ -765,6 +769,15 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
>             ios->bus_width == MMC_BUS_WIDTH_8)
>                 clock <<= 1;
>
> +       if (host->use_new_timings) {
> +               ret = sunxi_ccu_set_mmc_timing_mode(host->clk_mmc, true);

Can't this be solved through some other generic API/interface?

> +               if (ret) {
> +                       dev_err(mmc_dev(mmc),
> +                               "error setting new timing mode\n");
> +                       return ret;
> +               }
> +       }
> +

[...]

Kind regards
Uffe

[toc] | [prev] | [next] | [standalone]


#1687205 — Re: [PATCH 05/11] mmc: sunxi: Support controllers that can use both old and new timings

FromChen-Yu Tsai <wens@csie.org>
Date2017-07-14 11:50 +0200
SubjectRe: [PATCH 05/11] mmc: sunxi: Support controllers that can use both old and new timings
Message-ID<u35ot-1yc-13@gated-at.bofh.it>
In reply to#1687180
On Fri, Jul 14, 2017 at 5:26 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On 14 July 2017 at 08:42, Chen-Yu Tsai <wens@csie.org> wrote:
>> On the SoCs that introduced the new timing mode for MMC controllers,
>> both the old (where the clock delays are set in the CCU) and new
>> (where the clock delays are set in the MMC controller) timing modes
>> are available, and we have to support them both. However there are
>> two bits that control which mode is active. One is in the CCU, the
>> other is in the MMC controller. The settings on both sides must be
>> the same, or nothing will work.
>>
>> The CCU's get/set_phase callbacks return -ENOTSUPP when the new
>> timing mode is active. This provides a way to know which mode is
>> active on that side, and we can set the bit on the MMC controller
>> side accordingly.

Argh... I forgot to update the commit log... :(

>>
>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>> ---
>>  drivers/mmc/host/sunxi-mmc.c | 34 ++++++++++++++++++++++++++++++----
>>  1 file changed, 30 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
>> index 0fb4e4c119e1..56e45c65b52d 100644
>> --- a/drivers/mmc/host/sunxi-mmc.c
>> +++ b/drivers/mmc/host/sunxi-mmc.c
>> @@ -22,6 +22,7 @@
>>  #include <linux/err.h>
>>
>>  #include <linux/clk.h>
>> +#include <linux/clk/sunxi-ng.h>
>
> I don't like this. This looks like an SoC specific hack.
>
>>  #include <linux/gpio.h>
>>  #include <linux/platform_device.h>
>>  #include <linux/spinlock.h>
>> @@ -259,7 +260,7 @@ struct sunxi_mmc_cfg {
>>         /* Does DATA0 needs to be masked while the clock is updated */
>>         bool mask_data0;
>>
>> -       bool needs_new_timings;
>> +       bool has_new_timings;
>>  };
>>
>>  struct sunxi_mmc_host {
>> @@ -293,6 +294,9 @@ struct sunxi_mmc_host {
>>
>>         /* vqmmc */
>>         bool            vqmmc_enabled;
>> +
>> +       /* timings */
>> +       bool            use_new_timings;
>>  };
>>
>>  static int sunxi_mmc_reset_host(struct sunxi_mmc_host *host)
>> @@ -714,7 +718,7 @@ static int sunxi_mmc_clk_set_phase(struct sunxi_mmc_host *host,
>>  {
>>         int index;
>>
>> -       if (!host->cfg->clk_delays)
>> +       if (host->use_new_timings)
>>                 return 0;
>>
>>         /* determine delays */
>> @@ -765,6 +769,15 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
>>             ios->bus_width == MMC_BUS_WIDTH_8)
>>                 clock <<= 1;
>>
>> +       if (host->use_new_timings) {
>> +               ret = sunxi_ccu_set_mmc_timing_mode(host->clk_mmc, true);
>
> Can't this be solved through some other generic API/interface?

The old discussion is here: https://lkml.org/lkml/2017/5/5/77

It is possible to piggy back on existing API, but as Maxime mentioned
back in the discussion, it is confusing.

IIRC Mike said (via Maxime) an SoC specific call was the easy way
to handle this. I don't think there's anything generic about this.
Even if you could have a _set_mode callback for the clks, the modes
would be SoC specific anyway.

ChenYu

>
>> +               if (ret) {
>> +                       dev_err(mmc_dev(mmc),
>> +                               "error setting new timing mode\n");
>> +                       return ret;
>> +               }
>> +       }
>> +
>
> [...]
>
> Kind regards
> Uffe

[toc] | [prev] | [next] | [standalone]


#1687211 — Re: [PATCH 05/11] mmc: sunxi: Support controllers that can use both old and new timings

FromUlf Hansson <ulf.hansson@linaro.org>
Date2017-07-14 12:00 +0200
SubjectRe: [PATCH 05/11] mmc: sunxi: Support controllers that can use both old and new timings
Message-ID<u35y9-1D9-1@gated-at.bofh.it>
In reply to#1687205
On 14 July 2017 at 11:40, Chen-Yu Tsai <wens@csie.org> wrote:
> On Fri, Jul 14, 2017 at 5:26 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>> On 14 July 2017 at 08:42, Chen-Yu Tsai <wens@csie.org> wrote:
>>> On the SoCs that introduced the new timing mode for MMC controllers,
>>> both the old (where the clock delays are set in the CCU) and new
>>> (where the clock delays are set in the MMC controller) timing modes
>>> are available, and we have to support them both. However there are
>>> two bits that control which mode is active. One is in the CCU, the
>>> other is in the MMC controller. The settings on both sides must be
>>> the same, or nothing will work.
>>>
>>> The CCU's get/set_phase callbacks return -ENOTSUPP when the new
>>> timing mode is active. This provides a way to know which mode is
>>> active on that side, and we can set the bit on the MMC controller
>>> side accordingly.
>
> Argh... I forgot to update the commit log... :(
>
>>>
>>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>>> ---
>>>  drivers/mmc/host/sunxi-mmc.c | 34 ++++++++++++++++++++++++++++++----
>>>  1 file changed, 30 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
>>> index 0fb4e4c119e1..56e45c65b52d 100644
>>> --- a/drivers/mmc/host/sunxi-mmc.c
>>> +++ b/drivers/mmc/host/sunxi-mmc.c
>>> @@ -22,6 +22,7 @@
>>>  #include <linux/err.h>
>>>
>>>  #include <linux/clk.h>
>>> +#include <linux/clk/sunxi-ng.h>
>>
>> I don't like this. This looks like an SoC specific hack.
>>
>>>  #include <linux/gpio.h>
>>>  #include <linux/platform_device.h>
>>>  #include <linux/spinlock.h>
>>> @@ -259,7 +260,7 @@ struct sunxi_mmc_cfg {
>>>         /* Does DATA0 needs to be masked while the clock is updated */
>>>         bool mask_data0;
>>>
>>> -       bool needs_new_timings;
>>> +       bool has_new_timings;
>>>  };
>>>
>>>  struct sunxi_mmc_host {
>>> @@ -293,6 +294,9 @@ struct sunxi_mmc_host {
>>>
>>>         /* vqmmc */
>>>         bool            vqmmc_enabled;
>>> +
>>> +       /* timings */
>>> +       bool            use_new_timings;
>>>  };
>>>
>>>  static int sunxi_mmc_reset_host(struct sunxi_mmc_host *host)
>>> @@ -714,7 +718,7 @@ static int sunxi_mmc_clk_set_phase(struct sunxi_mmc_host *host,
>>>  {
>>>         int index;
>>>
>>> -       if (!host->cfg->clk_delays)
>>> +       if (host->use_new_timings)
>>>                 return 0;
>>>
>>>         /* determine delays */
>>> @@ -765,6 +769,15 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
>>>             ios->bus_width == MMC_BUS_WIDTH_8)
>>>                 clock <<= 1;
>>>
>>> +       if (host->use_new_timings) {
>>> +               ret = sunxi_ccu_set_mmc_timing_mode(host->clk_mmc, true);
>>
>> Can't this be solved through some other generic API/interface?
>
> The old discussion is here: https://lkml.org/lkml/2017/5/5/77
>
> It is possible to piggy back on existing API, but as Maxime mentioned
> back in the discussion, it is confusing.
>
> IIRC Mike said (via Maxime) an SoC specific call was the easy way
> to handle this. I don't think there's anything generic about this.
> Even if you could have a _set_mode callback for the clks, the modes
> would be SoC specific anyway.

Right. But it would benefit that we can keep drivers generic, as they
are using generic APIs/interfaces. I prefer that.

Anyway, let me try to dig up the earlier discussion.

Kind regards
Uffe

[toc] | [prev] | [next] | [standalone]


Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel


csiph-web