All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] mmc: sunxi: Clarify new timing mode usage and implementation
@ 2018-09-06 15:31 ` Chen-Yu Tsai
  0 siblings, 0 replies; 6+ messages in thread
From: Chen-Yu Tsai @ 2018-09-06 15:31 UTC (permalink / raw)
  To: Ulf Hansson, Maxime Ripard; +Cc: Chen-Yu Tsai, linux-mmc, linux-arm-kernel

Newer sunxi mmc controller variants support what they call the "new
timing mode". Support for this was implemented in two ways, according
to the hardware that was seen at the time.

The first type retained the old timing mode, and both the clock and mmc
controllers had switches to select which mode was used. Both switches
had to be set to the same setting. This variant was denoted with the
.has_timings_switch field in the sunxi_mmc_cfg structure. This hardware
is only seen on the A83T.

The second type did away with the old timing mode. The clock controller
no longer had the mode selection or clock delay setting bits. In some
cases the mmc controller retained its mode selection bit, but this
always needed to be set to the new mode, or instabilities would occur.
In a few cases, such as the A64 and H6 eMMC controller, the mode
selection bit is gone, but the controller still behaves like the new
timing mode, requiring the module clock to be double the card clock
in DDR transfer modes. This variant is denoted with the
.needs_new_timings field.

This patch adds more comments explaining the two fields, as well as
the possibly nonexistent mode switch in the mmc controller.

The .has_timings_switch is renamed to .ccu_has_timings_switch to clarify
its meaning.

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

diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 568349e1fbc2..5f8d3ea0a0f8 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -258,11 +258,16 @@ struct sunxi_mmc_cfg {
 	/* Does DATA0 needs to be masked while the clock is updated */
 	bool mask_data0;
 
-	/* hardware only supports new timing mode */
+	/*
+	 * hardware only supports new timing mode, either due to lack of
+	 * a mode switch in the clock controller, or the mmc controller
+	 * is permanently configured in the new timing mode, without the
+	 * NTSR mode switch.
+	 */
 	bool needs_new_timings;
 
-	/* hardware can switch between old and new timing modes */
-	bool has_timings_switch;
+	/* clock hardware can switch between old and new timing modes */
+	bool ccu_has_timings_switch;
 };
 
 struct sunxi_mmc_host {
@@ -787,7 +792,7 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
 		clock <<= 1;
 	}
 
-	if (host->use_new_timings && host->cfg->has_timings_switch) {
+	if (host->use_new_timings && host->cfg->ccu_has_timings_switch) {
 		ret = sunxi_ccu_set_mmc_timing_mode(host->clk_mmc, true);
 		if (ret) {
 			dev_err(mmc_dev(mmc),
@@ -822,6 +827,12 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
 	/* update card clock rate to account for internal divider */
 	rate /= div;
 
+	/*
+	 * Configure the controller to use the new timing mode if needed.
+	 * On controllers that only support the new timing mode, such as
+	 * the eMMC controller on the A64, this register does not exist,
+	 * and any writes to it are ignored.
+	 */
 	if (host->use_new_timings) {
 		/* Don't touch the delay bits */
 		rval = mmc_readl(host, REG_SD_NTSR);
@@ -1145,7 +1156,7 @@ 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_timings_switch = true,
+	.ccu_has_timings_switch = true,
 };
 
 static const struct sunxi_mmc_cfg sun9i_a80_cfg = {
@@ -1351,7 +1362,7 @@ static int sunxi_mmc_probe(struct platform_device *pdev)
 		goto error_free_host;
 	}
 
-	if (host->cfg->has_timings_switch) {
+	if (host->cfg->ccu_has_timings_switch) {
 		/*
 		 * Supports both old and new timing modes.
 		 * Try setting the clk to new timing mode.
-- 
2.19.0.rc1

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* [PATCH] mmc: sunxi: Clarify new timing mode usage and implementation
@ 2018-09-06 15:31 ` Chen-Yu Tsai
  0 siblings, 0 replies; 6+ messages in thread
From: Chen-Yu Tsai @ 2018-09-06 15:31 UTC (permalink / raw)
  To: linux-arm-kernel

Newer sunxi mmc controller variants support what they call the "new
timing mode". Support for this was implemented in two ways, according
to the hardware that was seen at the time.

The first type retained the old timing mode, and both the clock and mmc
controllers had switches to select which mode was used. Both switches
had to be set to the same setting. This variant was denoted with the
.has_timings_switch field in the sunxi_mmc_cfg structure. This hardware
is only seen on the A83T.

The second type did away with the old timing mode. The clock controller
no longer had the mode selection or clock delay setting bits. In some
cases the mmc controller retained its mode selection bit, but this
always needed to be set to the new mode, or instabilities would occur.
In a few cases, such as the A64 and H6 eMMC controller, the mode
selection bit is gone, but the controller still behaves like the new
timing mode, requiring the module clock to be double the card clock
in DDR transfer modes. This variant is denoted with the
.needs_new_timings field.

This patch adds more comments explaining the two fields, as well as
the possibly nonexistent mode switch in the mmc controller.

The .has_timings_switch is renamed to .ccu_has_timings_switch to clarify
its meaning.

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

diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 568349e1fbc2..5f8d3ea0a0f8 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -258,11 +258,16 @@ struct sunxi_mmc_cfg {
 	/* Does DATA0 needs to be masked while the clock is updated */
 	bool mask_data0;
 
-	/* hardware only supports new timing mode */
+	/*
+	 * hardware only supports new timing mode, either due to lack of
+	 * a mode switch in the clock controller, or the mmc controller
+	 * is permanently configured in the new timing mode, without the
+	 * NTSR mode switch.
+	 */
 	bool needs_new_timings;
 
-	/* hardware can switch between old and new timing modes */
-	bool has_timings_switch;
+	/* clock hardware can switch between old and new timing modes */
+	bool ccu_has_timings_switch;
 };
 
 struct sunxi_mmc_host {
@@ -787,7 +792,7 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
 		clock <<= 1;
 	}
 
-	if (host->use_new_timings && host->cfg->has_timings_switch) {
+	if (host->use_new_timings && host->cfg->ccu_has_timings_switch) {
 		ret = sunxi_ccu_set_mmc_timing_mode(host->clk_mmc, true);
 		if (ret) {
 			dev_err(mmc_dev(mmc),
@@ -822,6 +827,12 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
 	/* update card clock rate to account for internal divider */
 	rate /= div;
 
+	/*
+	 * Configure the controller to use the new timing mode if needed.
+	 * On controllers that only support the new timing mode, such as
+	 * the eMMC controller on the A64, this register does not exist,
+	 * and any writes to it are ignored.
+	 */
 	if (host->use_new_timings) {
 		/* Don't touch the delay bits */
 		rval = mmc_readl(host, REG_SD_NTSR);
@@ -1145,7 +1156,7 @@ 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_timings_switch = true,
+	.ccu_has_timings_switch = true,
 };
 
 static const struct sunxi_mmc_cfg sun9i_a80_cfg = {
@@ -1351,7 +1362,7 @@ static int sunxi_mmc_probe(struct platform_device *pdev)
 		goto error_free_host;
 	}
 
-	if (host->cfg->has_timings_switch) {
+	if (host->cfg->ccu_has_timings_switch) {
 		/*
 		 * Supports both old and new timing modes.
 		 * Try setting the clk to new timing mode.
-- 
2.19.0.rc1

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] mmc: sunxi: Clarify new timing mode usage and implementation
  2018-09-06 15:31 ` Chen-Yu Tsai
@ 2018-09-07  8:14   ` Maxime Ripard
  -1 siblings, 0 replies; 6+ messages in thread
From: Maxime Ripard @ 2018-09-07  8:14 UTC (permalink / raw)
  To: Chen-Yu Tsai; +Cc: Ulf Hansson, linux-mmc, linux-arm-kernel


[-- Attachment #1.1: Type: text/plain, Size: 1626 bytes --]

On Thu, Sep 06, 2018 at 11:31:07PM +0800, Chen-Yu Tsai wrote:
> Newer sunxi mmc controller variants support what they call the "new
> timing mode". Support for this was implemented in two ways, according
> to the hardware that was seen at the time.
> 
> The first type retained the old timing mode, and both the clock and mmc
> controllers had switches to select which mode was used. Both switches
> had to be set to the same setting. This variant was denoted with the
> .has_timings_switch field in the sunxi_mmc_cfg structure. This hardware
> is only seen on the A83T.
> 
> The second type did away with the old timing mode. The clock controller
> no longer had the mode selection or clock delay setting bits. In some
> cases the mmc controller retained its mode selection bit, but this
> always needed to be set to the new mode, or instabilities would occur.
> In a few cases, such as the A64 and H6 eMMC controller, the mode
> selection bit is gone, but the controller still behaves like the new
> timing mode, requiring the module clock to be double the card clock
> in DDR transfer modes. This variant is denoted with the
> .needs_new_timings field.
> 
> This patch adds more comments explaining the two fields, as well as
> the possibly nonexistent mode switch in the mmc controller.
> 
> The .has_timings_switch is renamed to .ccu_has_timings_switch to clarify
> its meaning.
> 
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>

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

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [PATCH] mmc: sunxi: Clarify new timing mode usage and implementation
@ 2018-09-07  8:14   ` Maxime Ripard
  0 siblings, 0 replies; 6+ messages in thread
From: Maxime Ripard @ 2018-09-07  8:14 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Sep 06, 2018 at 11:31:07PM +0800, Chen-Yu Tsai wrote:
> Newer sunxi mmc controller variants support what they call the "new
> timing mode". Support for this was implemented in two ways, according
> to the hardware that was seen at the time.
> 
> The first type retained the old timing mode, and both the clock and mmc
> controllers had switches to select which mode was used. Both switches
> had to be set to the same setting. This variant was denoted with the
> .has_timings_switch field in the sunxi_mmc_cfg structure. This hardware
> is only seen on the A83T.
> 
> The second type did away with the old timing mode. The clock controller
> no longer had the mode selection or clock delay setting bits. In some
> cases the mmc controller retained its mode selection bit, but this
> always needed to be set to the new mode, or instabilities would occur.
> In a few cases, such as the A64 and H6 eMMC controller, the mode
> selection bit is gone, but the controller still behaves like the new
> timing mode, requiring the module clock to be double the card clock
> in DDR transfer modes. This variant is denoted with the
> .needs_new_timings field.
> 
> This patch adds more comments explaining the two fields, as well as
> the possibly nonexistent mode switch in the mmc controller.
> 
> The .has_timings_switch is renamed to .ccu_has_timings_switch to clarify
> its meaning.
> 
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>

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

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180907/24241561/attachment.sig>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] mmc: sunxi: Clarify new timing mode usage and implementation
  2018-09-06 15:31 ` Chen-Yu Tsai
@ 2018-09-07  8:51   ` Ulf Hansson
  -1 siblings, 0 replies; 6+ messages in thread
From: Ulf Hansson @ 2018-09-07  8:51 UTC (permalink / raw)
  To: Chen-Yu Tsai; +Cc: Maxime Ripard, linux-mmc, Linux ARM

On 6 September 2018 at 17:31, Chen-Yu Tsai <wens@csie.org> wrote:
> Newer sunxi mmc controller variants support what they call the "new
> timing mode". Support for this was implemented in two ways, according
> to the hardware that was seen at the time.
>
> The first type retained the old timing mode, and both the clock and mmc
> controllers had switches to select which mode was used. Both switches
> had to be set to the same setting. This variant was denoted with the
> .has_timings_switch field in the sunxi_mmc_cfg structure. This hardware
> is only seen on the A83T.
>
> The second type did away with the old timing mode. The clock controller
> no longer had the mode selection or clock delay setting bits. In some
> cases the mmc controller retained its mode selection bit, but this
> always needed to be set to the new mode, or instabilities would occur.
> In a few cases, such as the A64 and H6 eMMC controller, the mode
> selection bit is gone, but the controller still behaves like the new
> timing mode, requiring the module clock to be double the card clock
> in DDR transfer modes. This variant is denoted with the
> .needs_new_timings field.
>
> This patch adds more comments explaining the two fields, as well as
> the possibly nonexistent mode switch in the mmc controller.
>
> The .has_timings_switch is renamed to .ccu_has_timings_switch to clarify
> its meaning.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>

Applied for next, thanks!

Kind regards
Uffe

> ---
>  drivers/mmc/host/sunxi-mmc.c | 23 +++++++++++++++++------
>  1 file changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index 568349e1fbc2..5f8d3ea0a0f8 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -258,11 +258,16 @@ struct sunxi_mmc_cfg {
>         /* Does DATA0 needs to be masked while the clock is updated */
>         bool mask_data0;
>
> -       /* hardware only supports new timing mode */
> +       /*
> +        * hardware only supports new timing mode, either due to lack of
> +        * a mode switch in the clock controller, or the mmc controller
> +        * is permanently configured in the new timing mode, without the
> +        * NTSR mode switch.
> +        */
>         bool needs_new_timings;
>
> -       /* hardware can switch between old and new timing modes */
> -       bool has_timings_switch;
> +       /* clock hardware can switch between old and new timing modes */
> +       bool ccu_has_timings_switch;
>  };
>
>  struct sunxi_mmc_host {
> @@ -787,7 +792,7 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
>                 clock <<= 1;
>         }
>
> -       if (host->use_new_timings && host->cfg->has_timings_switch) {
> +       if (host->use_new_timings && host->cfg->ccu_has_timings_switch) {
>                 ret = sunxi_ccu_set_mmc_timing_mode(host->clk_mmc, true);
>                 if (ret) {
>                         dev_err(mmc_dev(mmc),
> @@ -822,6 +827,12 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
>         /* update card clock rate to account for internal divider */
>         rate /= div;
>
> +       /*
> +        * Configure the controller to use the new timing mode if needed.
> +        * On controllers that only support the new timing mode, such as
> +        * the eMMC controller on the A64, this register does not exist,
> +        * and any writes to it are ignored.
> +        */
>         if (host->use_new_timings) {
>                 /* Don't touch the delay bits */
>                 rval = mmc_readl(host, REG_SD_NTSR);
> @@ -1145,7 +1156,7 @@ 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_timings_switch = true,
> +       .ccu_has_timings_switch = true,
>  };
>
>  static const struct sunxi_mmc_cfg sun9i_a80_cfg = {
> @@ -1351,7 +1362,7 @@ static int sunxi_mmc_probe(struct platform_device *pdev)
>                 goto error_free_host;
>         }
>
> -       if (host->cfg->has_timings_switch) {
> +       if (host->cfg->ccu_has_timings_switch) {
>                 /*
>                  * Supports both old and new timing modes.
>                  * Try setting the clk to new timing mode.
> --
> 2.19.0.rc1
>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [PATCH] mmc: sunxi: Clarify new timing mode usage and implementation
@ 2018-09-07  8:51   ` Ulf Hansson
  0 siblings, 0 replies; 6+ messages in thread
From: Ulf Hansson @ 2018-09-07  8:51 UTC (permalink / raw)
  To: linux-arm-kernel

On 6 September 2018 at 17:31, Chen-Yu Tsai <wens@csie.org> wrote:
> Newer sunxi mmc controller variants support what they call the "new
> timing mode". Support for this was implemented in two ways, according
> to the hardware that was seen at the time.
>
> The first type retained the old timing mode, and both the clock and mmc
> controllers had switches to select which mode was used. Both switches
> had to be set to the same setting. This variant was denoted with the
> .has_timings_switch field in the sunxi_mmc_cfg structure. This hardware
> is only seen on the A83T.
>
> The second type did away with the old timing mode. The clock controller
> no longer had the mode selection or clock delay setting bits. In some
> cases the mmc controller retained its mode selection bit, but this
> always needed to be set to the new mode, or instabilities would occur.
> In a few cases, such as the A64 and H6 eMMC controller, the mode
> selection bit is gone, but the controller still behaves like the new
> timing mode, requiring the module clock to be double the card clock
> in DDR transfer modes. This variant is denoted with the
> .needs_new_timings field.
>
> This patch adds more comments explaining the two fields, as well as
> the possibly nonexistent mode switch in the mmc controller.
>
> The .has_timings_switch is renamed to .ccu_has_timings_switch to clarify
> its meaning.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>

Applied for next, thanks!

Kind regards
Uffe

> ---
>  drivers/mmc/host/sunxi-mmc.c | 23 +++++++++++++++++------
>  1 file changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index 568349e1fbc2..5f8d3ea0a0f8 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -258,11 +258,16 @@ struct sunxi_mmc_cfg {
>         /* Does DATA0 needs to be masked while the clock is updated */
>         bool mask_data0;
>
> -       /* hardware only supports new timing mode */
> +       /*
> +        * hardware only supports new timing mode, either due to lack of
> +        * a mode switch in the clock controller, or the mmc controller
> +        * is permanently configured in the new timing mode, without the
> +        * NTSR mode switch.
> +        */
>         bool needs_new_timings;
>
> -       /* hardware can switch between old and new timing modes */
> -       bool has_timings_switch;
> +       /* clock hardware can switch between old and new timing modes */
> +       bool ccu_has_timings_switch;
>  };
>
>  struct sunxi_mmc_host {
> @@ -787,7 +792,7 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
>                 clock <<= 1;
>         }
>
> -       if (host->use_new_timings && host->cfg->has_timings_switch) {
> +       if (host->use_new_timings && host->cfg->ccu_has_timings_switch) {
>                 ret = sunxi_ccu_set_mmc_timing_mode(host->clk_mmc, true);
>                 if (ret) {
>                         dev_err(mmc_dev(mmc),
> @@ -822,6 +827,12 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
>         /* update card clock rate to account for internal divider */
>         rate /= div;
>
> +       /*
> +        * Configure the controller to use the new timing mode if needed.
> +        * On controllers that only support the new timing mode, such as
> +        * the eMMC controller on the A64, this register does not exist,
> +        * and any writes to it are ignored.
> +        */
>         if (host->use_new_timings) {
>                 /* Don't touch the delay bits */
>                 rval = mmc_readl(host, REG_SD_NTSR);
> @@ -1145,7 +1156,7 @@ 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_timings_switch = true,
> +       .ccu_has_timings_switch = true,
>  };
>
>  static const struct sunxi_mmc_cfg sun9i_a80_cfg = {
> @@ -1351,7 +1362,7 @@ static int sunxi_mmc_probe(struct platform_device *pdev)
>                 goto error_free_host;
>         }
>
> -       if (host->cfg->has_timings_switch) {
> +       if (host->cfg->ccu_has_timings_switch) {
>                 /*
>                  * Supports both old and new timing modes.
>                  * Try setting the clk to new timing mode.
> --
> 2.19.0.rc1
>

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2018-09-07  8:51 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-09-06 15:31 [PATCH] mmc: sunxi: Clarify new timing mode usage and implementation Chen-Yu Tsai
2018-09-06 15:31 ` Chen-Yu Tsai
2018-09-07  8:14 ` Maxime Ripard
2018-09-07  8:14   ` Maxime Ripard
2018-09-07  8:51 ` Ulf Hansson
2018-09-07  8:51   ` Ulf Hansson

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.