Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1559910 > unrolled thread
| Started by | Maxime Ripard <maxime.ripard@free-electrons.com> |
|---|---|
| First post | 2017-01-16 18:10 +0100 |
| Last post | 2017-01-23 12:00 +0100 |
| Articles | 18 — 4 participants |
Back to article view | Back to linux.kernel
[PATCH v3 0/13] arm64: allwinner: a64: Enable MMC support Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-01-16 18:10 +0100
[PATCH v3 1/13] mmc: sunxi: Fix clock frequency change sequence Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-01-16 18:10 +0100
Re: [PATCH v3 1/13] mmc: sunxi: Fix clock frequency change sequence Ulf Hansson <ulf.hansson@linaro.org> - 2017-01-24 09:20 +0100
Re: [PATCH v3 1/13] mmc: sunxi: Fix clock frequency change sequence Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-01-25 09:30 +0100
[PATCH v3 3/13] mmc: sunxi: Always set signal delay to 0 for A64 Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-01-16 18:10 +0100
Re: [PATCH v3 3/13] mmc: sunxi: Always set signal delay to 0 for A64 Ulf Hansson <ulf.hansson@linaro.org> - 2017-01-24 09:20 +0100
Re: [PATCH v3 3/13] mmc: sunxi: Always set signal delay to 0 for A64 Andre Przywara <andre.przywara@arm.com> - 2017-01-24 10:20 +0100
Re: [PATCH v3 3/13] mmc: sunxi: Always set signal delay to 0 for A64 Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-01-25 10:20 +0100
[PATCH v3 8/13] arm64: allwinner: a64: Add MMC nodes Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-01-16 18:10 +0100
Re: [PATCH v3 8/13] arm64: allwinner: a64: Add MMC nodes Corentin Labbe <clabbe.montjoie@gmail.com> - 2017-01-16 20:40 +0100
Re: [PATCH v3 8/13] arm64: allwinner: a64: Add MMC nodes Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-01-25 10:20 +0100
[PATCH v3 6/13] mmc: sunxi: Add EMMC (MMC2) controller compatible Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-01-16 18:10 +0100
[PATCH v3 10/13] arm64: allwinner: a64: Increase the MMC max frequency Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-01-16 18:10 +0100
[PATCH v3 9/13] arm64: allwinner: a64: Add MMC pinctrl nodes Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-01-16 18:10 +0100
[PATCH v3 4/13] mmc: sunxi: Enable the new timings for the A64 MMC controllers Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-01-16 18:10 +0100
[PATCH v3 2/13] mmc: sunxi: Gate the clock when rate is 0 Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-01-16 18:10 +0100
Re: [PATCH v3 2/13] mmc: sunxi: Gate the clock when rate is 0 Ulf Hansson <ulf.hansson@linaro.org> - 2017-01-24 09:20 +0100
Re: [PATCH v3 0/13] arm64: allwinner: a64: Enable MMC support Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-01-23 12:00 +0100
| From | Maxime Ripard <maxime.ripard@free-electrons.com> |
|---|---|
| Date | 2017-01-16 18:10 +0100 |
| Subject | [PATCH v3 0/13] arm64: allwinner: a64: Enable MMC support |
| Message-ID | <t0iNr-34Q-9@gated-at.bofh.it> |
Hi,
Here is a new attempt at getting the MMC controllers running, following the
work done by Andre.
This has been tested on a board with one SDIO device (a Marvell WiFi chip)
and a Kingston eMMC with 1.8V IOs.
For SDIO, the HS DDR mode works just fine. That serie also enables the
SDR104 mode to work on the devices that are capable of this.
For the eMMC, HS200 with the voltage switch works. HS400 doesn't at the
moment, but since it's significantly more complex, and at the same time
Allwinner recommends to limit its frequency to 100MHz, this doesn't have
any benefits. If there's any at some point, this can be added later.
Let me know what you think,
Maxime
Changes from v2:
- Enabled SDR104, limited the frequency to 150MHz. 200MHz was too high.
- Added more fixes to the gating and frequency rate change sequence
- Added one more patch to mask DATA0 when updating the clock that was
needed to get SDR104 to run
- Added the patches to enable it on a few boards done by Andre
- Amended the comments as suggested by Andre.
- Added some tags
Andre Przywara (4):
arm64: allwinner: a64: Add MMC nodes
arm64: allwinner: pine64: add MMC support
arm64: allwinner: a64: add UART1 pin nodes
arm64: allwinner: add BananaPi-M64 support
Maxime Ripard (9):
mmc: sunxi: Fix clock frequency change sequence
mmc: sunxi: Gate the clock when rate is 0
mmc: sunxi: Always set signal delay to 0 for A64
mmc: sunxi: Enable the new timings for the A64 MMC controllers
mmc: sunxi: Mask DATA0 when updating the clock
mmc: sunxi: Add EMMC (MMC2) controller compatible
mmc: sunxi: Add more debug messages
arm64: allwinner: a64: Add MMC pinctrl nodes
arm64: allwinner: a64: Increase the MMC max frequency
arch/arm64/boot/dts/allwinner/Makefile | 1 +-
arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 120 +++++++-
arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 20 +-
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 77 ++++-
drivers/mmc/host/sunxi-mmc.c | 101 +++---
5 files changed, 278 insertions(+), 41 deletions(-)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
base-commit: bc34c1af0a280e27eafe3f86b9ad87fe0c9ea715
--
git-series 0.8.11
[toc] | [next] | [standalone]
| From | Maxime Ripard <maxime.ripard@free-electrons.com> |
|---|---|
| Date | 2017-01-16 18:10 +0100 |
| Subject | [PATCH v3 1/13] mmc: sunxi: Fix clock frequency change sequence |
| Message-ID | <t0iX8-3o3-23@gated-at.bofh.it> |
| In reply to | #1559910 |
The MMC and SD specifications documents that the clock frequency should only be changed once gated. The current code first modifies the parent clock, gates it and then modifies the internal divider. This means that since the parent clock rate might be changed, the bus clock might be changed as well before it is gated, which breaks the specification. Move the gating before the parent rate modification. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> --- drivers/mmc/host/sunxi-mmc.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c index b1d1303389a7..ab4324e6eb74 100644 --- a/drivers/mmc/host/sunxi-mmc.c +++ b/drivers/mmc/host/sunxi-mmc.c @@ -761,6 +761,10 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host, u32 rval, clock = ios->clock; int ret; + ret = sunxi_mmc_oclk_onoff(host, 0); + if (ret) + return ret; + /* 8 bit DDR requires a higher module clock */ if (ios->timing == MMC_TIMING_MMC_DDR52 && ios->bus_width == MMC_BUS_WIDTH_8) @@ -783,10 +787,6 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host, return ret; } - ret = sunxi_mmc_oclk_onoff(host, 0); - if (ret) - return ret; - /* clear internal divider */ rval = mmc_readl(host, REG_CLKCR); rval &= ~0xff; -- git-series 0.8.11
[toc] | [prev] | [next] | [standalone]
| From | Ulf Hansson <ulf.hansson@linaro.org> |
|---|---|
| Date | 2017-01-24 09:20 +0100 |
| Subject | Re: [PATCH v3 1/13] mmc: sunxi: Fix clock frequency change sequence |
| Message-ID | <t34uE-1Q8-55@gated-at.bofh.it> |
| In reply to | #1559918 |
On 16 January 2017 at 17:56, Maxime Ripard <maxime.ripard@free-electrons.com> wrote: > The MMC and SD specifications documents that the clock frequency should > only be changed once gated. Where? > > The current code first modifies the parent clock, gates it and then > modifies the internal divider. This means that since the parent clock rate > might be changed, the bus clock might be changed as well before it is > gated, which breaks the specification. > > Move the gating before the parent rate modification. This all makes perfect sense to me, however I am not sure you need to refer to the spec to justify these changes. Kind regards Uffe > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > --- > drivers/mmc/host/sunxi-mmc.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c > index b1d1303389a7..ab4324e6eb74 100644 > --- a/drivers/mmc/host/sunxi-mmc.c > +++ b/drivers/mmc/host/sunxi-mmc.c > @@ -761,6 +761,10 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host, > u32 rval, clock = ios->clock; > int ret; > > + ret = sunxi_mmc_oclk_onoff(host, 0); > + if (ret) > + return ret; > + > /* 8 bit DDR requires a higher module clock */ > if (ios->timing == MMC_TIMING_MMC_DDR52 && > ios->bus_width == MMC_BUS_WIDTH_8) > @@ -783,10 +787,6 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host, > return ret; > } > > - ret = sunxi_mmc_oclk_onoff(host, 0); > - if (ret) > - return ret; > - > /* clear internal divider */ > rval = mmc_readl(host, REG_CLKCR); > rval &= ~0xff; > -- > git-series 0.8.11
[toc] | [prev] | [next] | [standalone]
| From | Maxime Ripard <maxime.ripard@free-electrons.com> |
|---|---|
| Date | 2017-01-25 09:30 +0100 |
| Subject | Re: [PATCH v3 1/13] mmc: sunxi: Fix clock frequency change sequence |
| Message-ID | <t3r7Q-7Nl-11@gated-at.bofh.it> |
| In reply to | #1565636 |
[Multipart message — attachments visible in raw view] — view raw
Hi Ulf, On Tue, Jan 24, 2017 at 09:12:07AM +0100, Ulf Hansson wrote: > On 16 January 2017 at 17:56, Maxime Ripard > <maxime.ripard@free-electrons.com> wrote: > > The MMC and SD specifications documents that the clock frequency should > > only be changed once gated. > > Where? > > > > > The current code first modifies the parent clock, gates it and then > > modifies the internal divider. This means that since the parent clock rate > > might be changed, the bus clock might be changed as well before it is > > gated, which breaks the specification. > > > > Move the gating before the parent rate modification. > > This all makes perfect sense to me, however I am not sure you need to > refer to the spec to justify these changes. I can't find it anymore :/ I'll resend that patch reworking the commit log. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
[toc] | [prev] | [next] | [standalone]
| From | Maxime Ripard <maxime.ripard@free-electrons.com> |
|---|---|
| Date | 2017-01-16 18:10 +0100 |
| Subject | [PATCH v3 3/13] mmc: sunxi: Always set signal delay to 0 for A64 |
| Message-ID | <t0iX9-3o3-33@gated-at.bofh.it> |
| In reply to | #1559910 |
Experience have shown that the using the autocalibration could severely
degrade the performances of the MMC bus.
Allwinner is using in its BSP a delay set to 0 for all the modes but HS400.
Remove the calibration code for now, and add comments to document our
findings.
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/mmc/host/sunxi-mmc.c | 50 ++++++++++++-------------------------
1 file changed, 17 insertions(+), 33 deletions(-)
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 019f95e8e7c5..b9c8a62bc212 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -683,41 +683,19 @@ static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host *host, u32 oclk_en)
static int sunxi_mmc_calibrate(struct sunxi_mmc_host *host, int reg_off)
{
- u32 reg = readl(host->reg_base + reg_off);
- u32 delay;
- unsigned long timeout;
-
if (!host->cfg->can_calibrate)
return 0;
- reg &= ~(SDXC_CAL_DL_MASK << SDXC_CAL_DL_SW_SHIFT);
- reg &= ~SDXC_CAL_DL_SW_EN;
-
- writel(reg | SDXC_CAL_START, host->reg_base + reg_off);
-
- dev_dbg(mmc_dev(host->mmc), "calibration started\n");
-
- timeout = jiffies + HZ * SDXC_CAL_TIMEOUT;
-
- while (!((reg = readl(host->reg_base + reg_off)) & SDXC_CAL_DONE)) {
- if (time_before(jiffies, timeout))
- cpu_relax();
- else {
- reg &= ~SDXC_CAL_START;
- writel(reg, host->reg_base + reg_off);
-
- return -ETIMEDOUT;
- }
- }
-
- delay = (reg >> SDXC_CAL_DL_SHIFT) & SDXC_CAL_DL_MASK;
-
- reg &= ~SDXC_CAL_START;
- reg |= (delay << SDXC_CAL_DL_SW_SHIFT) | SDXC_CAL_DL_SW_EN;
-
- writel(reg, host->reg_base + reg_off);
-
- dev_dbg(mmc_dev(host->mmc), "calibration ended, reg is 0x%x\n", reg);
+ /*
+ * FIXME:
+ * This is not clear how the calibration is supposed to work
+ * yet. The best rate have been obtained by simply setting the
+ * delay to 0, as Allwinner does in its BSP.
+ *
+ * The only mode that doesn't have such a delay is HS400, that
+ * is in itself a TODO.
+ */
+ writel(SDXC_CAL_DL_SW_EN, host->reg_base + reg_off);
return 0;
}
@@ -809,7 +787,13 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
if (ret)
return ret;
- /* TODO: enable calibrate on sdc2 SDXC_REG_DS_DL_REG of A64 */
+ /*
+ * FIXME:
+ *
+ * In HS400 we'll also need to calibrate the data strobe
+ * signal. This should only happen on the MMC2 controller (at
+ * least on the A64).
+ */
return sunxi_mmc_oclk_onoff(host, 1);
}
--
git-series 0.8.11
[toc] | [prev] | [next] | [standalone]
| From | Ulf Hansson <ulf.hansson@linaro.org> |
|---|---|
| Date | 2017-01-24 09:20 +0100 |
| Subject | Re: [PATCH v3 3/13] mmc: sunxi: Always set signal delay to 0 for A64 |
| Message-ID | <t34uF-1Q8-67@gated-at.bofh.it> |
| In reply to | #1559919 |
On 16 January 2017 at 17:56, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Experience have shown that the using the autocalibration could severely
> degrade the performances of the MMC bus.
>
> Allwinner is using in its BSP a delay set to 0 for all the modes but HS400.
> Remove the calibration code for now, and add comments to document our
> findings.
So doesn't this break some platforms using HS400? Or are you saying
those are already broken?
Kind regards
Uffe
>
> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> drivers/mmc/host/sunxi-mmc.c | 50 ++++++++++++-------------------------
> 1 file changed, 17 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index 019f95e8e7c5..b9c8a62bc212 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -683,41 +683,19 @@ static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host *host, u32 oclk_en)
>
> static int sunxi_mmc_calibrate(struct sunxi_mmc_host *host, int reg_off)
> {
> - u32 reg = readl(host->reg_base + reg_off);
> - u32 delay;
> - unsigned long timeout;
> -
> if (!host->cfg->can_calibrate)
> return 0;
>
> - reg &= ~(SDXC_CAL_DL_MASK << SDXC_CAL_DL_SW_SHIFT);
> - reg &= ~SDXC_CAL_DL_SW_EN;
> -
> - writel(reg | SDXC_CAL_START, host->reg_base + reg_off);
> -
> - dev_dbg(mmc_dev(host->mmc), "calibration started\n");
> -
> - timeout = jiffies + HZ * SDXC_CAL_TIMEOUT;
> -
> - while (!((reg = readl(host->reg_base + reg_off)) & SDXC_CAL_DONE)) {
> - if (time_before(jiffies, timeout))
> - cpu_relax();
> - else {
> - reg &= ~SDXC_CAL_START;
> - writel(reg, host->reg_base + reg_off);
> -
> - return -ETIMEDOUT;
> - }
> - }
> -
> - delay = (reg >> SDXC_CAL_DL_SHIFT) & SDXC_CAL_DL_MASK;
> -
> - reg &= ~SDXC_CAL_START;
> - reg |= (delay << SDXC_CAL_DL_SW_SHIFT) | SDXC_CAL_DL_SW_EN;
> -
> - writel(reg, host->reg_base + reg_off);
> -
> - dev_dbg(mmc_dev(host->mmc), "calibration ended, reg is 0x%x\n", reg);
> + /*
> + * FIXME:
> + * This is not clear how the calibration is supposed to work
> + * yet. The best rate have been obtained by simply setting the
> + * delay to 0, as Allwinner does in its BSP.
> + *
> + * The only mode that doesn't have such a delay is HS400, that
> + * is in itself a TODO.
> + */
> + writel(SDXC_CAL_DL_SW_EN, host->reg_base + reg_off);
>
> return 0;
> }
> @@ -809,7 +787,13 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
> if (ret)
> return ret;
>
> - /* TODO: enable calibrate on sdc2 SDXC_REG_DS_DL_REG of A64 */
> + /*
> + * FIXME:
> + *
> + * In HS400 we'll also need to calibrate the data strobe
> + * signal. This should only happen on the MMC2 controller (at
> + * least on the A64).
> + */
>
> return sunxi_mmc_oclk_onoff(host, 1);
> }
> --
> git-series 0.8.11
[toc] | [prev] | [next] | [standalone]
| From | Andre Przywara <andre.przywara@arm.com> |
|---|---|
| Date | 2017-01-24 10:20 +0100 |
| Subject | Re: [PATCH v3 3/13] mmc: sunxi: Always set signal delay to 0 for A64 |
| Message-ID | <t35qF-2qR-13@gated-at.bofh.it> |
| In reply to | #1565643 |
Hi Ulf,
On 24/01/17 08:16, Ulf Hansson wrote:
> On 16 January 2017 at 17:56, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
>> Experience have shown that the using the autocalibration could severely
>> degrade the performances of the MMC bus.
>>
>> Allwinner is using in its BSP a delay set to 0 for all the modes but HS400.
>> Remove the calibration code for now, and add comments to document our
>> findings.
>
> So doesn't this break some platforms using HS400? Or are you saying
> those are already broken?
This is a sunxi specific calibration routine, which was introduced
lately (e1b8dfd1b1c6) to be used by the Allwinner's enhanced MMC
controller. This is only used by devices using the sun50i-a64-mmc
compatible, of which this series introduces the first user.
So there is no way this can regress in any way, since the code wasn't
actually used before.
Cheers,
Andre.
>
>>
>> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
>> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>> ---
>> drivers/mmc/host/sunxi-mmc.c | 50 ++++++++++++-------------------------
>> 1 file changed, 17 insertions(+), 33 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
>> index 019f95e8e7c5..b9c8a62bc212 100644
>> --- a/drivers/mmc/host/sunxi-mmc.c
>> +++ b/drivers/mmc/host/sunxi-mmc.c
>> @@ -683,41 +683,19 @@ static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host *host, u32 oclk_en)
>>
>> static int sunxi_mmc_calibrate(struct sunxi_mmc_host *host, int reg_off)
>> {
>> - u32 reg = readl(host->reg_base + reg_off);
>> - u32 delay;
>> - unsigned long timeout;
>> -
>> if (!host->cfg->can_calibrate)
>> return 0;
>>
>> - reg &= ~(SDXC_CAL_DL_MASK << SDXC_CAL_DL_SW_SHIFT);
>> - reg &= ~SDXC_CAL_DL_SW_EN;
>> -
>> - writel(reg | SDXC_CAL_START, host->reg_base + reg_off);
>> -
>> - dev_dbg(mmc_dev(host->mmc), "calibration started\n");
>> -
>> - timeout = jiffies + HZ * SDXC_CAL_TIMEOUT;
>> -
>> - while (!((reg = readl(host->reg_base + reg_off)) & SDXC_CAL_DONE)) {
>> - if (time_before(jiffies, timeout))
>> - cpu_relax();
>> - else {
>> - reg &= ~SDXC_CAL_START;
>> - writel(reg, host->reg_base + reg_off);
>> -
>> - return -ETIMEDOUT;
>> - }
>> - }
>> -
>> - delay = (reg >> SDXC_CAL_DL_SHIFT) & SDXC_CAL_DL_MASK;
>> -
>> - reg &= ~SDXC_CAL_START;
>> - reg |= (delay << SDXC_CAL_DL_SW_SHIFT) | SDXC_CAL_DL_SW_EN;
>> -
>> - writel(reg, host->reg_base + reg_off);
>> -
>> - dev_dbg(mmc_dev(host->mmc), "calibration ended, reg is 0x%x\n", reg);
>> + /*
>> + * FIXME:
>> + * This is not clear how the calibration is supposed to work
>> + * yet. The best rate have been obtained by simply setting the
>> + * delay to 0, as Allwinner does in its BSP.
>> + *
>> + * The only mode that doesn't have such a delay is HS400, that
>> + * is in itself a TODO.
>> + */
>> + writel(SDXC_CAL_DL_SW_EN, host->reg_base + reg_off);
>>
>> return 0;
>> }
>> @@ -809,7 +787,13 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
>> if (ret)
>> return ret;
>>
>> - /* TODO: enable calibrate on sdc2 SDXC_REG_DS_DL_REG of A64 */
>> + /*
>> + * FIXME:
>> + *
>> + * In HS400 we'll also need to calibrate the data strobe
>> + * signal. This should only happen on the MMC2 controller (at
>> + * least on the A64).
>> + */
>>
>> return sunxi_mmc_oclk_onoff(host, 1);
>> }
>> --
>> git-series 0.8.11
[toc] | [prev] | [next] | [standalone]
| From | Maxime Ripard <maxime.ripard@free-electrons.com> |
|---|---|
| Date | 2017-01-25 10:20 +0100 |
| Subject | Re: [PATCH v3 3/13] mmc: sunxi: Always set signal delay to 0 for A64 |
| Message-ID | <t3rUd-8k5-17@gated-at.bofh.it> |
| In reply to | #1565643 |
[Multipart message — attachments visible in raw view] — view raw
Hi Ulf, On Tue, Jan 24, 2017 at 09:16:12AM +0100, Ulf Hansson wrote: > On 16 January 2017 at 17:56, Maxime Ripard > <maxime.ripard@free-electrons.com> wrote: > > Experience have shown that the using the autocalibration could severely > > degrade the performances of the MMC bus. > > > > Allwinner is using in its BSP a delay set to 0 for all the modes but HS400. > > Remove the calibration code for now, and add comments to document our > > findings. > > So doesn't this break some platforms using HS400? Or are you saying > those are already broken? Like Andre said, HS400 isn't supported at all, so there's no regression or brokenness involved :) Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
[toc] | [prev] | [next] | [standalone]
| From | Maxime Ripard <maxime.ripard@free-electrons.com> |
|---|---|
| Date | 2017-01-16 18:10 +0100 |
| Subject | [PATCH v3 8/13] arm64: allwinner: a64: Add MMC nodes |
| Message-ID | <t0iX9-3o3-35@gated-at.bofh.it> |
| In reply to | #1559910 |
From: Andre Przywara <andre.przywara@arm.com>
The A64 has 3 MMC controllers, one of them being especially targeted to
eMMC. Among other things, it has a data strobe signal and a 8 bits data
width.
The two other are more usual controllers that will have a 4 bits width at
most and no data strobe signal, which limits it to more usual SD or MMC
peripherals.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 39 ++++++++++++++++++++-
1 file changed, 39 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 99b6bb1e141c..143e9706438f 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -299,6 +299,45 @@
#size-cells = <0>;
};
+ mmc0: mmc@1c0f000 {
+ compatible = "allwinner,sun50i-a64-mmc";
+ reg = <0x01c0f000 0x1000>;
+ clocks = <&ccu CLK_BUS_MMC0>, <&ccu CLK_MMC0>;
+ clock-names = "ahb", "mmc";
+ 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,sun50i-a64-mmc";
+ reg = <0x01c10000 0x1000>;
+ clocks = <&ccu CLK_BUS_MMC1>, <&ccu CLK_MMC1>;
+ clock-names = "ahb", "mmc";
+ 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,sun50i-a64-emmc";
+ reg = <0x01c11000 0x1000>;
+ clocks = <&ccu CLK_BUS_MMC2>, <&ccu CLK_MMC2>;
+ clock-names = "ahb", "mmc";
+ resets = <&ccu RST_BUS_MMC2>;
+ reset-names = "ahb";
+ interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
gic: interrupt-controller@1c81000 {
compatible = "arm,gic-400";
reg = <0x01c81000 0x1000>,
--
git-series 0.8.11
[toc] | [prev] | [next] | [standalone]
| From | Corentin Labbe <clabbe.montjoie@gmail.com> |
|---|---|
| Date | 2017-01-16 20:40 +0100 |
| Subject | Re: [PATCH v3 8/13] arm64: allwinner: a64: Add MMC nodes |
| Message-ID | <t0lii-54V-19@gated-at.bofh.it> |
| In reply to | #1559920 |
On Mon, Jan 16, 2017 at 05:56:58PM +0100, Maxime Ripard wrote:
> From: Andre Przywara <andre.przywara@arm.com>
>
> The A64 has 3 MMC controllers, one of them being especially targeted to
> eMMC. Among other things, it has a data strobe signal and a 8 bits data
> width.
>
> The two other are more usual controllers that will have a 4 bits width at
> most and no data strobe signal, which limits it to more usual SD or MMC
> peripherals.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 39 ++++++++++++++++++++-
> 1 file changed, 39 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index 99b6bb1e141c..143e9706438f 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -299,6 +299,45 @@
> #size-cells = <0>;
> };
>
> + mmc0: mmc@1c0f000 {
> + compatible = "allwinner,sun50i-a64-mmc";
> + reg = <0x01c0f000 0x1000>;
> + clocks = <&ccu CLK_BUS_MMC0>, <&ccu CLK_MMC0>;
> + clock-names = "ahb", "mmc";
> + 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,sun50i-a64-mmc";
> + reg = <0x01c10000 0x1000>;
> + clocks = <&ccu CLK_BUS_MMC1>, <&ccu CLK_MMC1>;
> + clock-names = "ahb", "mmc";
> + 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,sun50i-a64-emmc";
> + reg = <0x01c11000 0x1000>;
> + clocks = <&ccu CLK_BUS_MMC2>, <&ccu CLK_MMC2>;
> + clock-names = "ahb", "mmc";
> + resets = <&ccu RST_BUS_MMC2>;
> + reset-names = "ahb";
> + interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> gic: interrupt-controller@1c81000 {
> compatible = "arm,gic-400";
> reg = <0x01c81000 0x1000>,
Hello
It seems that mmc node is after i2c@1c2b400 so not in address order.
Regards
Corentin Labbe
[toc] | [prev] | [next] | [standalone]
| From | Maxime Ripard <maxime.ripard@free-electrons.com> |
|---|---|
| Date | 2017-01-25 10:20 +0100 |
| Subject | Re: [PATCH v3 8/13] arm64: allwinner: a64: Add MMC nodes |
| Message-ID | <t3rUd-8k5-15@gated-at.bofh.it> |
| In reply to | #1560014 |
[Multipart message — attachments visible in raw view] — view raw
Hi Corentin,
On Mon, Jan 16, 2017 at 08:16:41PM +0100, Corentin Labbe wrote:
> On Mon, Jan 16, 2017 at 05:56:58PM +0100, Maxime Ripard wrote:
> > From: Andre Przywara <andre.przywara@arm.com>
> >
> > The A64 has 3 MMC controllers, one of them being especially targeted to
> > eMMC. Among other things, it has a data strobe signal and a 8 bits data
> > width.
> >
> > The two other are more usual controllers that will have a 4 bits width at
> > most and no data strobe signal, which limits it to more usual SD or MMC
> > peripherals.
> >
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > ---
> > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 39 ++++++++++++++++++++-
> > 1 file changed, 39 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > index 99b6bb1e141c..143e9706438f 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > @@ -299,6 +299,45 @@
> > #size-cells = <0>;
> > };
> >
> > + mmc0: mmc@1c0f000 {
> > + compatible = "allwinner,sun50i-a64-mmc";
> > + reg = <0x01c0f000 0x1000>;
> > + clocks = <&ccu CLK_BUS_MMC0>, <&ccu CLK_MMC0>;
> > + clock-names = "ahb", "mmc";
> > + 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,sun50i-a64-mmc";
> > + reg = <0x01c10000 0x1000>;
> > + clocks = <&ccu CLK_BUS_MMC1>, <&ccu CLK_MMC1>;
> > + clock-names = "ahb", "mmc";
> > + 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,sun50i-a64-emmc";
> > + reg = <0x01c11000 0x1000>;
> > + clocks = <&ccu CLK_BUS_MMC2>, <&ccu CLK_MMC2>;
> > + clock-names = "ahb", "mmc";
> > + resets = <&ccu RST_BUS_MMC2>;
> > + reset-names = "ahb";
> > + interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > gic: interrupt-controller@1c81000 {
> > compatible = "arm,gic-400";
> > reg = <0x01c81000 0x1000>,
>
> Hello
>
> It seems that mmc node is after i2c@1c2b400 so not in address order.
You're right, I'll fix this in the v3.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[toc] | [prev] | [next] | [standalone]
| From | Maxime Ripard <maxime.ripard@free-electrons.com> |
|---|---|
| Date | 2017-01-16 18:10 +0100 |
| Subject | [PATCH v3 6/13] mmc: sunxi: Add EMMC (MMC2) controller compatible |
| Message-ID | <t0iX8-3o3-27@gated-at.bofh.it> |
| In reply to | #1559910 |
The MMC2 controller on the A64 is kind of a special beast.
While the general controller design is the same than the other MMC
controllers in the SoC, it also has a bunch of features and changes that
prevent it to be driven in the same way.
It has for example a different bus width limit, a different maximum
frequency, and, for some reason, the maximum buffer size of a DMA
descriptor.
Add a new compatible specifically for this controller.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/mmc/host/sunxi-mmc.c | 8 ++++++++
1 file changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 6bbe61397b7c..f0f6922bca8a 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -5,6 +5,7 @@
* (C) Copyright 2013-2014 O2S GmbH <www.o2s.ch>
* (C) Copyright 2013-2014 David Lanzend�rfer <david.lanzendoerfer@o2s.ch>
* (C) Copyright 2013-2014 Hans de Goede <hdegoede@redhat.com>
+ * (C) Copyright 2017 Sootech SA
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
@@ -1096,12 +1097,19 @@ static const struct sunxi_mmc_cfg sun50i_a64_cfg = {
.needs_new_timings = true,
};
+static const struct sunxi_mmc_cfg sun50i_a64_emmc_cfg = {
+ .idma_des_size_bits = 13,
+ .clk_delays = NULL,
+ .can_calibrate = true,
+};
+
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,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 },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, sunxi_mmc_of_match);
--
git-series 0.8.11
[toc] | [prev] | [next] | [standalone]
| From | Maxime Ripard <maxime.ripard@free-electrons.com> |
|---|---|
| Date | 2017-01-16 18:10 +0100 |
| Subject | [PATCH v3 10/13] arm64: allwinner: a64: Increase the MMC max frequency |
| Message-ID | <t0iX9-3o3-47@gated-at.bofh.it> |
| In reply to | #1559910 |
The eMMC controller seem to have a maximum frequency of 200MHz, while the regular MMC controllers are capped at 150MHz. Since older SoCs cannot go that high, we cannot change the default maximum frequency, but fortunately for us we have a property for that in the DT. This also has the side effect of allowing to use the MMC HS200 and SD SDR104 modes for the boards that support it (with either 1.2v or 1.8v IOs). Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> arm64: allwinner: a64: Limit MMC0 and MMC1 rates to 150MHz Trying to set the bus to 200MHz on MMC1 when doing SDIO is failing. Allwinner sets the maximum for this bus to 150MHz, so enforce that limit. This hasn't been tested with MMC0, but the documented limit is the same, and I expect the behaviour to be the same. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> --- arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 3 +++ 1 file changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi index 8e149498e096..b371fccc234b 100644 --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi @@ -332,6 +332,7 @@ resets = <&ccu RST_BUS_MMC0>; reset-names = "ahb"; interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>; + max-frequency = <150000000>; status = "disabled"; #address-cells = <1>; #size-cells = <0>; @@ -345,6 +346,7 @@ resets = <&ccu RST_BUS_MMC1>; reset-names = "ahb"; interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>; + max-frequency = <150000000>; status = "disabled"; #address-cells = <1>; #size-cells = <0>; @@ -358,6 +360,7 @@ resets = <&ccu RST_BUS_MMC2>; reset-names = "ahb"; interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>; + max-frequency = <200000000>; status = "disabled"; #address-cells = <1>; #size-cells = <0>; -- git-series 0.8.11
[toc] | [prev] | [next] | [standalone]
| From | Maxime Ripard <maxime.ripard@free-electrons.com> |
|---|---|
| Date | 2017-01-16 18:10 +0100 |
| Subject | [PATCH v3 9/13] arm64: allwinner: a64: Add MMC pinctrl nodes |
| Message-ID | <t0iX9-3o3-37@gated-at.bofh.it> |
| In reply to | #1559910 |
The A64 only has a single set of pins for each MMC controller. Since we
already have boards that require all of them, let's add them to the DTSI.
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 25 ++++++++++++++++++++-
1 file changed, 25 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 143e9706438f..8e149498e096 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -205,6 +205,31 @@
function = "i2c1";
};
+ mmc0_pins: mmc0-pins {
+ pins = "PF0", "PF1", "PF2", "PF3",
+ "PF4", "PF5";
+ function = "mmc0";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+
+ mmc1_pins: mmc1-pins {
+ pins = "PG0", "PG1", "PG2", "PG3",
+ "PG4", "PG5";
+ function = "mmc1";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+
+ mmc2_pins: mmc2-pins {
+ pins = "PC1", "PC5", "PC6", "PC8", "PC9",
+ "PC10","PC11", "PC12", "PC13",
+ "PC14", "PC15", "PC16";
+ function = "mmc2";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+
uart0_pins_a: uart0@0 {
pins = "PB8", "PB9";
function = "uart0";
--
git-series 0.8.11
[toc] | [prev] | [next] | [standalone]
| From | Maxime Ripard <maxime.ripard@free-electrons.com> |
|---|---|
| Date | 2017-01-16 18:10 +0100 |
| Subject | [PATCH v3 4/13] mmc: sunxi: Enable the new timings for the A64 MMC controllers |
| Message-ID | <t0iX9-3o3-43@gated-at.bofh.it> |
| In reply to | #1559910 |
The A64 MMC controllers need to set a "new timings" bit when a new rate is
set.
The actual meaning of that bit is not clear yet, but not setting it leads
to some corner-case issues, like the CMD53 failing, which is used to
implement SDIO packet aggregation.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/mmc/host/sunxi-mmc.c | 6 ++++++
1 file changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index b9c8a62bc212..51d6388a194e 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -253,6 +253,8 @@ struct sunxi_mmc_cfg {
/* does the IP block support autocalibration? */
bool can_calibrate;
+
+ bool needs_new_timings;
};
struct sunxi_mmc_host {
@@ -779,6 +781,9 @@ 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);
+
ret = sunxi_mmc_clk_set_phase(host, ios, rate);
if (ret)
return ret;
@@ -1076,6 +1081,7 @@ static const struct sunxi_mmc_cfg sun50i_a64_cfg = {
.idma_des_size_bits = 16,
.clk_delays = NULL,
.can_calibrate = true,
+ .needs_new_timings = true,
};
static const struct of_device_id sunxi_mmc_of_match[] = {
--
git-series 0.8.11
[toc] | [prev] | [next] | [standalone]
| From | Maxime Ripard <maxime.ripard@free-electrons.com> |
|---|---|
| Date | 2017-01-16 18:10 +0100 |
| Subject | [PATCH v3 2/13] mmc: sunxi: Gate the clock when rate is 0 |
| Message-ID | <t0iX9-3o3-49@gated-at.bofh.it> |
| In reply to | #1559910 |
The MMC core assumes that the code will gate the clock when the bus
frequency is set to 0, which we've been ignoring so far.
Handle that.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/mmc/host/sunxi-mmc.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index ab4324e6eb74..019f95e8e7c5 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -765,6 +765,9 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
if (ret)
return ret;
+ if (!ios->clock)
+ return 0;
+
/* 8 bit DDR requires a higher module clock */
if (ios->timing == MMC_TIMING_MMC_DDR52 &&
ios->bus_width == MMC_BUS_WIDTH_8)
@@ -882,7 +885,7 @@ static void sunxi_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
mmc_writel(host, REG_GCTRL, rval);
/* set up clock */
- if (ios->clock && ios->power_mode) {
+ if (ios->power_mode) {
host->ferror = sunxi_mmc_clk_set_rate(host, ios);
/* Android code had a usleep_range(50000, 55000); here */
}
--
git-series 0.8.11
[toc] | [prev] | [next] | [standalone]
| From | Ulf Hansson <ulf.hansson@linaro.org> |
|---|---|
| Date | 2017-01-24 09:20 +0100 |
| Subject | Re: [PATCH v3 2/13] mmc: sunxi: Gate the clock when rate is 0 |
| Message-ID | <t34uD-1Q8-37@gated-at.bofh.it> |
| In reply to | #1559926 |
On 16 January 2017 at 17:56, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The MMC core assumes that the code will gate the clock when the bus
> frequency is set to 0, which we've been ignoring so far.
>
> Handle that.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Looks good!
Kind regards
Uffe
> ---
> drivers/mmc/host/sunxi-mmc.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index ab4324e6eb74..019f95e8e7c5 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -765,6 +765,9 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
> if (ret)
> return ret;
>
> + if (!ios->clock)
> + return 0;
> +
> /* 8 bit DDR requires a higher module clock */
> if (ios->timing == MMC_TIMING_MMC_DDR52 &&
> ios->bus_width == MMC_BUS_WIDTH_8)
> @@ -882,7 +885,7 @@ static void sunxi_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
> mmc_writel(host, REG_GCTRL, rval);
>
> /* set up clock */
> - if (ios->clock && ios->power_mode) {
> + if (ios->power_mode) {
> host->ferror = sunxi_mmc_clk_set_rate(host, ios);
> /* Android code had a usleep_range(50000, 55000); here */
> }
> --
> git-series 0.8.11
[toc] | [prev] | [next] | [standalone]
| From | Maxime Ripard <maxime.ripard@free-electrons.com> |
|---|---|
| Date | 2017-01-23 12:00 +0100 |
| Message-ID | <t2KvZ-5ob-9@gated-at.bofh.it> |
| In reply to | #1559910 |
[Multipart message — attachments visible in raw view] — view raw
Hi Ulf, On Mon, Jan 16, 2017 at 05:56:50PM +0100, Maxime Ripard wrote: > Hi, > > Here is a new attempt at getting the MMC controllers running, following the > work done by Andre. > > This has been tested on a board with one SDIO device (a Marvell WiFi chip) > and a Kingston eMMC with 1.8V IOs. > > For SDIO, the HS DDR mode works just fine. That serie also enables the > SDR104 mode to work on the devices that are capable of this. > > For the eMMC, HS200 with the voltage switch works. HS400 doesn't at the > moment, but since it's significantly more complex, and at the same time > Allwinner recommends to limit its frequency to 100MHz, this doesn't have > any benefits. If there's any at some point, this can be added later. Unless you have objections, I'd really like this to be in 4.11. There's a bunch of things where I'm not entirely sure (especially the clock gating part), it would be great if you could have a look. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web