Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1567199 > unrolled thread
| Started by | Maxime Ripard <maxime.ripard@free-electrons.com> |
|---|---|
| First post | 2017-01-26 10:10 +0100 |
| Last post | 2017-01-27 22:40 +0100 |
| Articles | 11 — 2 participants |
Back to article view | Back to linux.kernel
[PATCH v4 0/13] arm64: allwinner: a64: Enable MMC support Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-01-26 10:10 +0100
[PATCH v4 2/13] mmc: sunxi: Gate the clock when rate is 0 Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-01-26 10:10 +0100
[PATCH v4 3/13] mmc: sunxi: Always set signal delay to 0 for A64 Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-01-26 10:10 +0100
[PATCH v4 12/13] arm64: allwinner: a64: add UART1 pin nodes Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-01-26 10:20 +0100
[PATCH v4 10/13] arm64: allwinner: a64: Increase the MMC max frequency Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-01-26 10:20 +0100
Re: [PATCH v4 10/13] arm64: allwinner: a64: Increase the MMC max frequency Florian Vaussard <florian.vaussard@heig-vd.ch> - 2017-01-27 11:50 +0100
Re: [PATCH v4 10/13] arm64: allwinner: a64: Increase the MMC max frequency Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-01-27 22:40 +0100
[PATCH v4 1/13] mmc: sunxi: Fix clock frequency change sequence Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-01-26 10:20 +0100
[PATCH v4 11/13] arm64: allwinner: pine64: add MMC support Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-01-26 10:20 +0100
Re: [PATCH v4 0/13] arm64: allwinner: a64: Enable MMC support Florian Vaussard <florian.vaussard@heig-vd.ch> - 2017-01-27 11:50 +0100
Re: [PATCH v4 0/13] arm64: allwinner: a64: Enable MMC support Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-01-27 22:40 +0100
| From | Maxime Ripard <maxime.ripard@free-electrons.com> |
|---|---|
| Date | 2017-01-26 10:10 +0100 |
| Subject | [PATCH v4 0/13] arm64: allwinner: a64: Enable MMC support |
| Message-ID | <t3Oe5-5t5-3@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 v3:
- Reordered the MMC nodes
- Added the specification section the first commit log
- Supported mmc->actual_rate
- Clarified a bit what we (don't) know about DATA0
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 informations
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 | 114 ++++---
5 files changed, 289 insertions(+), 43 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-26 10:10 +0100 |
| Subject | [PATCH v4 2/13] mmc: sunxi: Gate the clock when rate is 0 |
| Message-ID | <t3Oe6-5t5-27@gated-at.bofh.it> |
| In reply to | #1567199 |
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 | Maxime Ripard <maxime.ripard@free-electrons.com> |
|---|---|
| Date | 2017-01-26 10:10 +0100 |
| Subject | [PATCH v4 3/13] mmc: sunxi: Always set signal delay to 0 for A64 |
| Message-ID | <t3Oe7-5t5-31@gated-at.bofh.it> |
| In reply to | #1567199 |
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 | Maxime Ripard <maxime.ripard@free-electrons.com> |
|---|---|
| Date | 2017-01-26 10:20 +0100 |
| Subject | [PATCH v4 12/13] arm64: allwinner: a64: add UART1 pin nodes |
| Message-ID | <t3OnM-5wh-3@gated-at.bofh.it> |
| In reply to | #1567199 |
From: Andre Przywara <andre.przywara@arm.com>
On many boards UART1 connects to a Bluetooth chip, so add the pinctrl
nodes for the only pins providing access to that UART. That includes
those pins for hardware flow control (RTS/CTS).
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 | 10 ++++++++++
1 file changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index cb3e0cf2191a..d27b17f807d0 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -276,6 +276,16 @@
pins = "PB8", "PB9";
function = "uart0";
};
+
+ uart1_pins: uart1_pins {
+ pins = "PG6", "PG7";
+ function = "uart1";
+ };
+
+ uart1_rts_cts_pins: uart1_rts_cts_pins {
+ pins = "PG8", "PG9";
+ function = "uart1";
+ };
};
uart0: serial@1c28000 {
--
git-series 0.8.11
[toc] | [prev] | [next] | [standalone]
| From | Maxime Ripard <maxime.ripard@free-electrons.com> |
|---|---|
| Date | 2017-01-26 10:20 +0100 |
| Subject | [PATCH v4 10/13] arm64: allwinner: a64: Increase the MMC max frequency |
| Message-ID | <t3OnN-5wh-37@gated-at.bofh.it> |
| In reply to | #1567199 |
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 7b79c319ad3c..cb3e0cf2191a 100644 --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi @@ -130,6 +130,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>; @@ -143,6 +144,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>; @@ -156,6 +158,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 | Florian Vaussard <florian.vaussard@heig-vd.ch> |
|---|---|
| Date | 2017-01-27 11:50 +0100 |
| Subject | Re: [PATCH v4 10/13] arm64: allwinner: a64: Increase the MMC max frequency |
| Message-ID | <t4cgq-2YU-17@gated-at.bofh.it> |
| In reply to | #1567209 |
Hi Maxime, On 01/26/2017 10:06 AM, Maxime Ripard wrote: > 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> I suspect that you are trying to increase your number of Signed-off-by tags by using unfair means :) Otherwise the squashed commit message is probably worth some cleaning. Best, Florian > --- > 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 7b79c319ad3c..cb3e0cf2191a 100644 > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi > @@ -130,6 +130,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>; > @@ -143,6 +144,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>; > @@ -156,6 +158,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>; >
[toc] | [prev] | [next] | [standalone]
| From | Maxime Ripard <maxime.ripard@free-electrons.com> |
|---|---|
| Date | 2017-01-27 22:40 +0100 |
| Subject | Re: [PATCH v4 10/13] arm64: allwinner: a64: Increase the MMC max frequency |
| Message-ID | <t4mpr-Y4-5@gated-at.bofh.it> |
| In reply to | #1568038 |
[Multipart message — attachments visible in raw view] — view raw
On Fri, Jan 27, 2017 at 11:29:53AM +0100, Florian Vaussard wrote: > Hi Maxime, > > On 01/26/2017 10:06 AM, Maxime Ripard wrote: > > 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> > > I suspect that you are trying to increase your number of Signed-off-by tags by > using unfair means :) Otherwise the squashed commit message is probably worth > some cleaning. /me hides in a corner... The first commit log is the right one, I'll remove the second. 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-26 10:20 +0100 |
| Subject | [PATCH v4 1/13] mmc: sunxi: Fix clock frequency change sequence |
| Message-ID | <t3OnN-5wh-29@gated-at.bofh.it> |
| In reply to | #1567199 |
The SD specification documents that the clock frequency should only be changed once gated (Section 3.2.3 - SD Clock Frequency Change Sequence). 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 | Maxime Ripard <maxime.ripard@free-electrons.com> |
|---|---|
| Date | 2017-01-26 10:20 +0100 |
| Subject | [PATCH v4 11/13] arm64: allwinner: pine64: add MMC support |
| Message-ID | <t3OnN-5wh-35@gated-at.bofh.it> |
| In reply to | #1567199 |
From: Andre Przywara <andre.przywara@arm.com>
All Pine64 boards connect an micro-SD card slot to the first MMC
controller.
Enable the respective DT node and specify the (always-on) regulator
and card-detect pin.
As a micro-SD slot does not feature a write-protect switch, we disable
this feature.
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-pine64.dts | 20 ++++++++++++++-
1 file changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index cf9105179bcb..c680ed385da3 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -44,6 +44,8 @@
#include "sun50i-a64.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+
/ {
model = "Pine64";
compatible = "pine64,pine64", "allwinner,sun50i-a64";
@@ -55,6 +57,13 @@
chosen {
stdout-path = "serial0:115200n8";
};
+
+ reg_vcc3v3: vcc3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
};
&ehci1 {
@@ -71,6 +80,17 @@
bias-pull-up;
};
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins>;
+ vmmc-supply = <®_vcc3v3>;
+ cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
+ cd-inverted;
+ disable-wp;
+ bus-width = <4>;
+ status = "okay";
+};
+
&ohci1 {
status = "okay";
};
--
git-series 0.8.11
[toc] | [prev] | [next] | [standalone]
| From | Florian Vaussard <florian.vaussard@heig-vd.ch> |
|---|---|
| Date | 2017-01-27 11:50 +0100 |
| Message-ID | <t4cgq-2YU-23@gated-at.bofh.it> |
| In reply to | #1567199 |
Hi Maxime, On 01/26/2017 10:05 AM, 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. > > Let me know what you think, > Maxime > FWIW I tested this series and got decent throughput (190 Mbps in UDP) with a Marvell SDIO Wifi chip. The board becomes unresponsive between 30 to 60 minutes of iperf torture, but I strongly suspect a hardware issue underneath. Feel free to add my Tested-by on the MMC patches if you need it. Thank you for your work. Best, Florian > Changes from v3: > - Reordered the MMC nodes > - Added the specification section the first commit log > - Supported mmc->actual_rate > - Clarified a bit what we (don't) know about DATA0 > > 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 informations > 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 | 114 ++++--- > 5 files changed, 289 insertions(+), 43 deletions(-) > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts > > base-commit: bc34c1af0a280e27eafe3f86b9ad87fe0c9ea715 >
[toc] | [prev] | [next] | [standalone]
| From | Maxime Ripard <maxime.ripard@free-electrons.com> |
|---|---|
| Date | 2017-01-27 22:40 +0100 |
| Message-ID | <t4mps-Y4-31@gated-at.bofh.it> |
| In reply to | #1568039 |
[Multipart message — attachments visible in raw view] — view raw
Hi Florian, On Fri, Jan 27, 2017 at 11:37:27AM +0100, Florian Vaussard wrote: > Hi Maxime, > > On 01/26/2017 10:05 AM, 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. > > > > Let me know what you think, > > Maxime > > > > FWIW I tested this series and got decent throughput (190 Mbps in UDP) with a > Marvell SDIO Wifi chip. The board becomes unresponsive between 30 to 60 minutes > of iperf torture, but I strongly suspect a hardware issue underneath. Feel free > to add my Tested-by on the MMC patches if you need it. Thanks for testing! 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