[U-Boot] [PATCH v2 0/7] mmc: sunxi: Enable DM_MMC

[U-Boot] [PATCH v2 0/7] mmc: sunxi: Enable DM_MMC

[Jagan Teki]

V2 for previous version[1] changes, for enabling DM_MMC
on Allwinner platform.

Changes for v2:
- update the 'reset enablement' logic to do
  required SoC's

Note: All changes available at u-boot-sunxi/next	

[1] https://patchwork.ozlabs.org/cover/1023710/

Any comments?
Jagan.

Jagan Teki (7):
  mmc: sunxi: Configure reset support for DM_MMC
  mmc: sunxi: Add A83T emmc compatible
  mmc: sunxi: Add mmc, emmc H5/A64 compatible
  mmc: sunxi: Add DM_MMC support for H6
  mmc: sunxi: Add DM_MMC support for A80
  arm: sunxi: Enable DM_MMC
  arm: dts: sunxi: Enumerate MMC2 as MMC1

 arch/arm/Kconfig                              |  1 +
 arch/arm/dts/sunxi-u-boot.dtsi                |  4 +
 .../include/asm/arch-sunxi/clock_sun50i_h6.h  |  3 +
 arch/arm/mach-sunxi/Kconfig                   |  1 -
 configs/Linksprite_pcDuino3_defconfig         |  1 -
 drivers/mmc/sunxi_mmc.c                       | 73 ++++++++++++++++++-
 6 files changed, 79 insertions(+), 4 deletions(-)

-- 
2.18.0.321.gffc6fa0e3

[U-Boot] [PATCH v2 1/7] mmc: sunxi: Configure reset support for DM_MMC

[Jagan Teki]

Start with Allwinner A31, mmc controllers do support reset
control bit. This code add support to enable the reset control
start from SUN6I even though it share same compatible between
SUN4I and SUN6I.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/mmc/sunxi_mmc.c | 21 +++++++++++++++++++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 302332bf97..0e53701c5b 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -21,8 +21,11 @@
 
 #ifdef CONFIG_DM_MMC
 struct sunxi_mmc_variant {
+	bool has_reset;
 	u16 gate_offset;
 	u16 mclk_offset;
+	u16 reset_offset;
+	u8 reset_start_bit;
 };
 #endif
 
@@ -609,7 +612,7 @@ static int sunxi_mmc_probe(struct udevice *dev)
 	struct sunxi_mmc_priv *priv = dev_get_priv(dev);
 	struct mmc_config *cfg = &plat->cfg;
 	struct ofnode_phandle_args args;
-	u32 *gate_reg, *ccu_reg;
+	u32 *gate_reg, *reset_reg, *ccu_reg;
 	int bus_width, ret;
 
 	cfg->name = dev->name;
@@ -644,6 +647,12 @@ static int sunxi_mmc_probe(struct udevice *dev)
 	gate_reg = (void *)ccu_reg + priv->variant->gate_offset;
 	setbits_le32(gate_reg, BIT(AHB_GATE_OFFSET_MMC(priv->mmc_no)));
 
+	if ((!IS_ENABLED(CONFIG_MACH_SUN7I)) && priv->variant->has_reset) {
+		reset_reg = (void *)ccu_reg + priv->variant->reset_offset;
+		setbits_le32(reset_reg, BIT(priv->mmc_no +
+			     priv->variant->reset_start_bit));
+	}
+
 	ret = mmc_set_mod_clk(priv, 24000000);
 	if (ret)
 		return ret;
@@ -680,6 +689,14 @@ static const struct sunxi_mmc_variant sun4i_a10_variant = {
 	.mclk_offset = 0x88,
 };
 
+static const struct sunxi_mmc_variant sun7i_a20_variant = {
+	.has_reset = true,
+	.gate_offset = 0x60,
+	.mclk_offset = 0x88,
+	.reset_offset = 0x2c0,
+	.reset_start_bit = 8,
+};
+
 static const struct udevice_id sunxi_mmc_ids[] = {
 	{
 	  .compatible = "allwinner,sun4i-a10-mmc",
@@ -691,7 +708,7 @@ static const struct udevice_id sunxi_mmc_ids[] = {
 	},
 	{
 	  .compatible = "allwinner,sun7i-a20-mmc",
-	  .data = (ulong)&sun4i_a10_variant,
+	  .data = (ulong)&sun7i_a20_variant,
 	},
 	{ /* sentinel */ }
 };
-- 
2.18.0.321.gffc6fa0e3

[U-Boot] [PATCH v2 2/7] mmc: sunxi: Add A83T emmc compatible

[Jagan Teki]

Add emmc compatible for A83T SoC.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/mmc/sunxi_mmc.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 0e53701c5b..c25967afd1 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -710,6 +710,10 @@ static const struct udevice_id sunxi_mmc_ids[] = {
 	  .compatible = "allwinner,sun7i-a20-mmc",
 	  .data = (ulong)&sun7i_a20_variant,
 	},
+	{
+	  .compatible = "allwinner,sun8i-a83t-emmc",
+	  .data = (ulong)&sun7i_a20_variant,
+	},
 	{ /* sentinel */ }
 };
 
-- 
2.18.0.321.gffc6fa0e3

[U-Boot] [PATCH v2 3/7] mmc: sunxi: Add mmc, emmc H5/A64 compatible

[Jagan Teki]

Added H5, A64 compatible for mmc and emmc.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/mmc/sunxi_mmc.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index c25967afd1..b1c177bba3 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -714,6 +714,14 @@ static const struct udevice_id sunxi_mmc_ids[] = {
 	  .compatible = "allwinner,sun8i-a83t-emmc",
 	  .data = (ulong)&sun7i_a20_variant,
 	},
+	{
+	  .compatible = "allwinner,sun50i-a64-mmc",
+	  .data = (ulong)&sun7i_a20_variant,
+	},
+	{
+	  .compatible = "allwinner,sun50i-a64-emmc",
+	  .data = (ulong)&sun7i_a20_variant,
+	},
 	{ /* sentinel */ }
 };
 
-- 
2.18.0.321.gffc6fa0e3

[U-Boot] [PATCH v2 4/7] mmc: sunxi: Add DM_MMC support for H6

[Jagan Teki]

Unlike other Allwinner SoC's, H6 comes with different
clock and reset control offset values. So support them
via driver data.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 .../arm/include/asm/arch-sunxi/clock_sun50i_h6.h |  3 +++
 drivers/mmc/sunxi_mmc.c                          | 16 ++++++++++++++++
 2 files changed, 19 insertions(+)

diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
index e36937059b..baf9b2e6e2 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
@@ -301,6 +301,9 @@ struct sunxi_ccm_reg {
 #define DRAM_CLK_SRC_PLL5		(0 << 24)
 #define DRAM_CLK_M(m)			(((m)-1) << 0)
 
+/* MMC ahb clock bit field */
+#define AHB_GATE_OFFSET_MMC(n)		((n))
+
 /* MMC clock bit field */
 #define CCM_MMC_CTRL_M(x)		((x) - 1)
 #define CCM_MMC_CTRL_N(x)		((x) << 8)
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index b1c177bba3..5b9ac5f82c 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -697,6 +697,14 @@ static const struct sunxi_mmc_variant sun7i_a20_variant = {
 	.reset_start_bit = 8,
 };
 
+static const struct sunxi_mmc_variant sun50i_h6_variant = {
+	.has_reset = true,
+	.gate_offset = 0x84c,
+	.mclk_offset = 0x830,
+	.reset_offset = 0x84c,
+	.reset_start_bit = 16,
+};
+
 static const struct udevice_id sunxi_mmc_ids[] = {
 	{
 	  .compatible = "allwinner,sun4i-a10-mmc",
@@ -722,6 +730,14 @@ static const struct udevice_id sunxi_mmc_ids[] = {
 	  .compatible = "allwinner,sun50i-a64-emmc",
 	  .data = (ulong)&sun7i_a20_variant,
 	},
+	{
+	  .compatible = "allwinner,sun50i-h6-mmc",
+	  .data = (ulong)&sun50i_h6_variant,
+	},
+	{
+	  .compatible = "allwinner,sun50i-h6-emmc",
+	  .data = (ulong)&sun50i_h6_variant,
+	},
 	{ /* sentinel */ }
 };
 
-- 
2.18.0.321.gffc6fa0e3

[U-Boot] [PATCH v2 5/7] mmc: sunxi: Add DM_MMC support for A80

[Jagan Teki]

Unlike other Allwinner SoC's, A80 comes with different ahb
gate clock offset values and also has mmc common controller.
So support them via driver data.

Cc: Rask Ingemann Lambertsen <rask@formelder.dk>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/mmc/sunxi_mmc.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 5b9ac5f82c..7fab88c47f 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -22,6 +22,7 @@
 #ifdef CONFIG_DM_MMC
 struct sunxi_mmc_variant {
 	bool has_reset;
+	bool has_mmc_common;
 	u16 gate_offset;
 	u16 mclk_offset;
 	u16 reset_offset;
@@ -653,6 +654,19 @@ static int sunxi_mmc_probe(struct udevice *dev)
 			     priv->variant->reset_start_bit));
 	}
 
+	if (priv->variant->has_mmc_common) {
+		u32 *mmc_config_clk, *mmc_common_base;
+
+		ret = dev_read_phandle_with_args(dev, "clocks", "#clock-cells", 0,
+					  0, &args);
+		if (ret)
+			return ret;
+		mmc_config_clk = (u32 *)ofnode_get_addr(args.node);
+
+		mmc_common_base = (void *)mmc_config_clk + (priv->mmc_no * 4);
+		setbits_le32(mmc_common_base, BIT(18) | BIT(16));
+	}
+
 	ret = mmc_set_mod_clk(priv, 24000000);
 	if (ret)
 		return ret;
@@ -697,6 +711,12 @@ static const struct sunxi_mmc_variant sun7i_a20_variant = {
 	.reset_start_bit = 8,
 };
 
+static const struct sunxi_mmc_variant sun9i_a80_variant = {
+	.has_mmc_common = true,
+	.gate_offset = 0x580,
+	.mclk_offset = 0x410,
+};
+
 static const struct sunxi_mmc_variant sun50i_h6_variant = {
 	.has_reset = true,
 	.gate_offset = 0x84c,
@@ -722,6 +742,10 @@ static const struct udevice_id sunxi_mmc_ids[] = {
 	  .compatible = "allwinner,sun8i-a83t-emmc",
 	  .data = (ulong)&sun7i_a20_variant,
 	},
+	{
+	  .compatible = "allwinner,sun9i-a80-mmc",
+	  .data = (ulong)&sun9i_a80_variant,
+	},
 	{
 	  .compatible = "allwinner,sun50i-a64-mmc",
 	  .data = (ulong)&sun7i_a20_variant,
-- 
2.18.0.321.gffc6fa0e3

[U-Boot] [PATCH v2 6/7] arm: sunxi: Enable DM_MMC

[Jagan Teki]

Enable DM_MMC for all Allwinner SoCs, this will eventually
enable BLK.

Also removed DM_MMC enablement in few parts of sunxi
configurations.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 arch/arm/Kconfig                      | 1 +
 arch/arm/mach-sunxi/Kconfig           | 1 -
 configs/Linksprite_pcDuino3_defconfig | 1 -
 3 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a23cbd5719..075c3dfe81 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -851,6 +851,7 @@ config ARCH_SUNXI
 	select DM_ETH
 	select DM_GPIO
 	select DM_KEYBOARD
+	select DM_MMC if MMC
 	select DM_SERIAL
 	select DM_USB if DISTRO_DEFAULTS
 	select OF_BOARD_SETUP
diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 3c54f5106d..74e234cded 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -154,7 +154,6 @@ config MACH_SUN4I
 	bool "sun4i (Allwinner A10)"
 	select CPU_V7A
 	select ARM_CORTEX_CPU_IS_UP
-	select DM_MMC if MMC
 	select DM_SCSI if SCSI
 	select PHY_SUN4I_USB
 	select DRAM_SUN4I
diff --git a/configs/Linksprite_pcDuino3_defconfig b/configs/Linksprite_pcDuino3_defconfig
index 9156f132d1..18f658e96b 100644
--- a/configs/Linksprite_pcDuino3_defconfig
+++ b/configs/Linksprite_pcDuino3_defconfig
@@ -14,7 +14,6 @@ CONFIG_SPL_I2C_SUPPORT=y
 # CONFIG_SPL_EFI_PARTITION is not set
 CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-pcduino3"
 CONFIG_SCSI_AHCI=y
-CONFIG_DM_MMC=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_MII=y
 CONFIG_SUN7I_GMAC=y
-- 
2.18.0.321.gffc6fa0e3

[U-Boot] [PATCH v2 7/7] arm: dts: sunxi: Enumerate MMC2 as MMC1

[Jagan Teki]

Environment and fastboot MMC devices are configured based number
of mmc slots defined on particular board in sunxi platform.

If number of slots are not more than 1, it assigns 0 which usually mmc
device on SD slot. With DM_MMC it is detected as 0 since mmc0 node always
be an mmc device.

If number of slots are more than 1, it assigns 1 which assumes 0 is mmc
device and 1 is emmc device. But with DM_MMC there is chance of detecting
emmc as device 2 since mmc1 is SDIO as per devicetree definition.

So override mmc2 to mmc1 in sunxi dtsi, this will eventually detect mmc2
as mmc 1 device even if the board dts has mmc0, mmc1, mmc2.

Some platforms like A20 has mmc0...mmc3, but there is no usecases now for
enabling all mmc controllers in any of A20 board dts files.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 arch/arm/dts/sunxi-u-boot.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/sunxi-u-boot.dtsi b/arch/arm/dts/sunxi-u-boot.dtsi
index 8a9f2a6417..fdd4c80aa4 100644
--- a/arch/arm/dts/sunxi-u-boot.dtsi
+++ b/arch/arm/dts/sunxi-u-boot.dtsi
@@ -1,6 +1,10 @@
 #include <config.h>
 
 / {
+	aliases {
+		mmc1 = &mmc2;
+	};
+
 	binman {
 		filename = "u-boot-sunxi-with-spl.bin";
 		pad-byte = <0xff>;
-- 
2.18.0.321.gffc6fa0e3

[U-Boot] [PATCH v2 0/7] mmc: sunxi: Enable DM_MMC

[Andre Przywara]

On Thu, 17 Jan 2019 22:39:44 +0530
Jagan Teki <jagan@amarulasolutions.com> wrote:

> V2 for previous version[1] changes, for enabling DM_MMC
> on Allwinner platform.

So this is a neat and simple solution to the DM_MMC problem, to the
point where I am wondering why we actually need all those DT driven
clock and reset drivers in the first place.
But as I understand using plat data in this way is somewhat frowned
upon and considered deprecated (although it makes a lot of sense in
this context).

Also, isn't this series independent from the clock gates/reset
patches? So why do you pile them on top of each other in sunxi/next?

If we really want to have the full featured DT driven clock and reset
support, why not use it together:
We keep the current mod clock support in the MMC driver, but use the
newly introduced clock gates and reset support via the new clock
driver, mostly replacing this series. This would give us some test
coverage of the new clock driver, while still avoiding to rush the MMC
mod clock implementation.

Does that make sense? Happy to bake some patches for that on the
weekend.

Btw: After talking to Tom on IRC, the DM_MMC deadline is actually
_after_ the 2019.04 release, so we don't need to have DM_MMC support in
this merge window.

Cheers,
Andre.

> Changes for v2:
> - update the 'reset enablement' logic to do
>   required SoC's
> 
> Note: All changes available at u-boot-sunxi/next	
> 
> [1] https://patchwork.ozlabs.org/cover/1023710/
> 
> Any comments?
> Jagan.
> 
> Jagan Teki (7):
>   mmc: sunxi: Configure reset support for DM_MMC
>   mmc: sunxi: Add A83T emmc compatible
>   mmc: sunxi: Add mmc, emmc H5/A64 compatible
>   mmc: sunxi: Add DM_MMC support for H6
>   mmc: sunxi: Add DM_MMC support for A80
>   arm: sunxi: Enable DM_MMC
>   arm: dts: sunxi: Enumerate MMC2 as MMC1
> 
>  arch/arm/Kconfig                              |  1 +
>  arch/arm/dts/sunxi-u-boot.dtsi                |  4 +
>  .../include/asm/arch-sunxi/clock_sun50i_h6.h  |  3 +
>  arch/arm/mach-sunxi/Kconfig                   |  1 -
>  configs/Linksprite_pcDuino3_defconfig         |  1 -
>  drivers/mmc/sunxi_mmc.c                       | 73
> ++++++++++++++++++- 6 files changed, 79 insertions(+), 4 deletions(-)
> 

[U-Boot] [PATCH v2 0/7] mmc: sunxi: Enable DM_MMC

[Tom Rini]

On Fri, Jan 18, 2019 at 11:53:49AM +0000, Andre Przywara wrote:
> On Thu, 17 Jan 2019 22:39:44 +0530
> Jagan Teki <jagan@amarulasolutions.com> wrote:
> 
> > V2 for previous version[1] changes, for enabling DM_MMC
> > on Allwinner platform.
> 
> So this is a neat and simple solution to the DM_MMC problem, to the
> point where I am wondering why we actually need all those DT driven
> clock and reset drivers in the first place.
> But as I understand using plat data in this way is somewhat frowned
> upon and considered deprecated (although it makes a lot of sense in
> this context).
> 
> Also, isn't this series independent from the clock gates/reset
> patches? So why do you pile them on top of each other in sunxi/next?
> 
> If we really want to have the full featured DT driven clock and reset
> support, why not use it together:
> We keep the current mod clock support in the MMC driver, but use the
> newly introduced clock gates and reset support via the new clock
> driver, mostly replacing this series. This would give us some test
> coverage of the new clock driver, while still avoiding to rush the MMC
> mod clock implementation.
> 
> Does that make sense? Happy to bake some patches for that on the
> weekend.
> 
> Btw: After talking to Tom on IRC, the DM_MMC deadline is actually
> _after_ the 2019.04 release, so we don't need to have DM_MMC support in
> this merge window.

To be clearer, I plan to mark as BROKEN and start saying we're going to
remove stuff that isn't migrated, after the release.  So it would be
good to get things moved this release that can be moved this release.
Trying to use sunxi w/o MMC isn't going to be fun :)

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190118/8315887e/attachment.sig>

[U-Boot] [PATCH v2 0/7] mmc: sunxi: Enable DM_MMC

[Andre Przywara]

On Fri, 18 Jan 2019 07:17:41 -0500
Tom Rini <trini@konsulko.com> wrote:

> On Fri, Jan 18, 2019 at 11:53:49AM +0000, Andre Przywara wrote:
> > On Thu, 17 Jan 2019 22:39:44 +0530
> > Jagan Teki <jagan@amarulasolutions.com> wrote:
> >   
> > > V2 for previous version[1] changes, for enabling DM_MMC
> > > on Allwinner platform.  
> > 
> > So this is a neat and simple solution to the DM_MMC problem, to the
> > point where I am wondering why we actually need all those DT driven
> > clock and reset drivers in the first place.
> > But as I understand using plat data in this way is somewhat frowned
> > upon and considered deprecated (although it makes a lot of sense in
> > this context).
> > 
> > Also, isn't this series independent from the clock gates/reset
> > patches? So why do you pile them on top of each other in sunxi/next?
> > 
> > If we really want to have the full featured DT driven clock and
> > reset support, why not use it together:
> > We keep the current mod clock support in the MMC driver, but use the
> > newly introduced clock gates and reset support via the new clock
> > driver, mostly replacing this series. This would give us some test
> > coverage of the new clock driver, while still avoiding to rush the
> > MMC mod clock implementation.
> > 
> > Does that make sense? Happy to bake some patches for that on the
> > weekend.
> > 
> > Btw: After talking to Tom on IRC, the DM_MMC deadline is actually
> > _after_ the 2019.04 release, so we don't need to have DM_MMC
> > support in this merge window.  
> 
> To be clearer, I plan to mark as BROKEN and start saying we're going
> to remove stuff that isn't migrated, after the release.  So it would
> be good to get things moved this release that can be moved this
> release. Trying to use sunxi w/o MMC isn't going to be fun :)

Understood. I just gave it a quick try and it is actually quite easy: We
are pretty good already regarding gate clocks and resets, with the new
DM_CLK driver (v2 on the list). And using them in sunxi_mmc.c is a piece
of cake and very clean.
We just need to keep the MMC mod clock hack in (which this series here
does as well), but can still enable DM_MMC.
And for the next merge window we can tackle this by implementing the
MMC mod clock properly in the clock driver, then replacing the hack
with the normal clk_get_by_name(); clk_set_rate(); sequence.

Will send a patch later.

Cheers,
Andre

[U-Boot] [PATCH v2 0/7] mmc: sunxi: Enable DM_MMC

[Jagan Teki]

On Fri, Jan 18, 2019 at 6:00 PM Andre Przywara <andre.przywara@arm.com> wrote:
>
> On Fri, 18 Jan 2019 07:17:41 -0500
> Tom Rini <trini@konsulko.com> wrote:
>
> > On Fri, Jan 18, 2019 at 11:53:49AM +0000, Andre Przywara wrote:
> > > On Thu, 17 Jan 2019 22:39:44 +0530
> > > Jagan Teki <jagan@amarulasolutions.com> wrote:
> > >
> > > > V2 for previous version[1] changes, for enabling DM_MMC
> > > > on Allwinner platform.
> > >
> > > So this is a neat and simple solution to the DM_MMC problem, to the
> > > point where I am wondering why we actually need all those DT driven
> > > clock and reset drivers in the first place.
> > > But as I understand using plat data in this way is somewhat frowned
> > > upon and considered deprecated (although it makes a lot of sense in
> > > this context).
> > >
> > > Also, isn't this series independent from the clock gates/reset
> > > patches? So why do you pile them on top of each other in sunxi/next?
> > >
> > > If we really want to have the full featured DT driven clock and
> > > reset support, why not use it together:
> > > We keep the current mod clock support in the MMC driver, but use the
> > > newly introduced clock gates and reset support via the new clock
> > > driver, mostly replacing this series. This would give us some test
> > > coverage of the new clock driver, while still avoiding to rush the
> > > MMC mod clock implementation.
> > >
> > > Does that make sense? Happy to bake some patches for that on the
> > > weekend.
> > >
> > > Btw: After talking to Tom on IRC, the DM_MMC deadline is actually
> > > _after_ the 2019.04 release, so we don't need to have DM_MMC
> > > support in this merge window.
> >
> > To be clearer, I plan to mark as BROKEN and start saying we're going
> > to remove stuff that isn't migrated, after the release.  So it would
> > be good to get things moved this release that can be moved this
> > release. Trying to use sunxi w/o MMC isn't going to be fun :)
>
> Understood. I just gave it a quick try and it is actually quite easy: We
> are pretty good already regarding gate clocks and resets, with the new
> DM_CLK driver (v2 on the list). And using them in sunxi_mmc.c is a piece
> of cake and very clean.
> We just need to keep the MMC mod clock hack in (which this series here
> does as well), but can still enable DM_MMC.
> And for the next merge window we can tackle this by implementing the
> MMC mod clock properly in the clock driver, then replacing the hack
> with the normal clk_get_by_name(); clk_set_rate(); sequence.

I tried with ahb clock and reset, with v2 version of CLK series and
it's straightforward. but mmc clock may take some time along with
series of testing. So I just windup this, instead of making some noise
at last minute.

[U-Boot] [PATCH v2 0/7] mmc: sunxi: Enable DM_MMC

[Andre Przywara]

On Fri, 18 Jan 2019 22:11:36 +0530
Jagan Teki <jagan@amarulasolutions.com> wrote:

Hi,

> On Fri, Jan 18, 2019 at 6:00 PM Andre Przywara
> <andre.przywara@arm.com> wrote:
> >
> > On Fri, 18 Jan 2019 07:17:41 -0500
> > Tom Rini <trini@konsulko.com> wrote:
> >  
> > > On Fri, Jan 18, 2019 at 11:53:49AM +0000, Andre Przywara wrote:  
> > > > On Thu, 17 Jan 2019 22:39:44 +0530
> > > > Jagan Teki <jagan@amarulasolutions.com> wrote:
> > > >  
> > > > > V2 for previous version[1] changes, for enabling DM_MMC
> > > > > on Allwinner platform.  
> > > >
> > > > So this is a neat and simple solution to the DM_MMC problem, to
> > > > the point where I am wondering why we actually need all those
> > > > DT driven clock and reset drivers in the first place.
> > > > But as I understand using plat data in this way is somewhat
> > > > frowned upon and considered deprecated (although it makes a lot
> > > > of sense in this context).
> > > >
> > > > Also, isn't this series independent from the clock gates/reset
> > > > patches? So why do you pile them on top of each other in
> > > > sunxi/next?
> > > >
> > > > If we really want to have the full featured DT driven clock and
> > > > reset support, why not use it together:
> > > > We keep the current mod clock support in the MMC driver, but
> > > > use the newly introduced clock gates and reset support via the
> > > > new clock driver, mostly replacing this series. This would give
> > > > us some test coverage of the new clock driver, while still
> > > > avoiding to rush the MMC mod clock implementation.
> > > >
> > > > Does that make sense? Happy to bake some patches for that on the
> > > > weekend.
> > > >
> > > > Btw: After talking to Tom on IRC, the DM_MMC deadline is
> > > > actually _after_ the 2019.04 release, so we don't need to have
> > > > DM_MMC support in this merge window.  
> > >
> > > To be clearer, I plan to mark as BROKEN and start saying we're
> > > going to remove stuff that isn't migrated, after the release.  So
> > > it would be good to get things moved this release that can be
> > > moved this release. Trying to use sunxi w/o MMC isn't going to be
> > > fun :)  
> >
> > Understood. I just gave it a quick try and it is actually quite
> > easy: We are pretty good already regarding gate clocks and resets,
> > with the new DM_CLK driver (v2 on the list). And using them in
> > sunxi_mmc.c is a piece of cake and very clean.
> > We just need to keep the MMC mod clock hack in (which this series
> > here does as well), but can still enable DM_MMC.
> > And for the next merge window we can tackle this by implementing the
> > MMC mod clock properly in the clock driver, then replacing the hack
> > with the normal clk_get_by_name(); clk_set_rate(); sequence.  
> 
> I tried with ahb clock and reset, with v2 version of CLK series and
> it's straightforward. but mmc clock may take some time along with
> series of testing. So I just windup this, instead of making some noise
> at last minute.

What do you mean with that, exactly?
Do you plan to take your platdata hack for 2019.04?
I don't like the idea of hacking something up that has no future and
will be reverted very soon anyway. Instead we should expose the
foundation part of the clock driver to people now for testing (as you
did by pushing it, thanks!), but including the MMC gates and resets.
I have this code ready, just need to test it on some SoCs this evening.

I think taking this change is the best compromise between changing
not too many things at once, yet still exposing new code to the users
for testing.

And yes, the MMC mod clock is somewhat of a beast, but if we have
just this in the next release, it should be easier to debug than when
we expose the whole of the new clock framework to MMC by then only.

Cheers,
Andre.

[U-Boot] [PATCH v2 0/7] mmc: sunxi: Enable DM_MMC

[Jagan Teki]

On Fri, Jan 18, 2019 at 11:18 PM Andre Przywara <andre.przywara@arm.com> wrote:
>
> On Fri, 18 Jan 2019 22:11:36 +0530
> Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> Hi,
>
> > On Fri, Jan 18, 2019 at 6:00 PM Andre Przywara
> > <andre.przywara@arm.com> wrote:
> > >
> > > On Fri, 18 Jan 2019 07:17:41 -0500
> > > Tom Rini <trini@konsulko.com> wrote:
> > >
> > > > On Fri, Jan 18, 2019 at 11:53:49AM +0000, Andre Przywara wrote:
> > > > > On Thu, 17 Jan 2019 22:39:44 +0530
> > > > > Jagan Teki <jagan@amarulasolutions.com> wrote:
> > > > >
> > > > > > V2 for previous version[1] changes, for enabling DM_MMC
> > > > > > on Allwinner platform.
> > > > >
> > > > > So this is a neat and simple solution to the DM_MMC problem, to
> > > > > the point where I am wondering why we actually need all those
> > > > > DT driven clock and reset drivers in the first place.
> > > > > But as I understand using plat data in this way is somewhat
> > > > > frowned upon and considered deprecated (although it makes a lot
> > > > > of sense in this context).
> > > > >
> > > > > Also, isn't this series independent from the clock gates/reset
> > > > > patches? So why do you pile them on top of each other in
> > > > > sunxi/next?
> > > > >
> > > > > If we really want to have the full featured DT driven clock and
> > > > > reset support, why not use it together:
> > > > > We keep the current mod clock support in the MMC driver, but
> > > > > use the newly introduced clock gates and reset support via the
> > > > > new clock driver, mostly replacing this series. This would give
> > > > > us some test coverage of the new clock driver, while still
> > > > > avoiding to rush the MMC mod clock implementation.
> > > > >
> > > > > Does that make sense? Happy to bake some patches for that on the
> > > > > weekend.
> > > > >
> > > > > Btw: After talking to Tom on IRC, the DM_MMC deadline is
> > > > > actually _after_ the 2019.04 release, so we don't need to have
> > > > > DM_MMC support in this merge window.
> > > >
> > > > To be clearer, I plan to mark as BROKEN and start saying we're
> > > > going to remove stuff that isn't migrated, after the release.  So
> > > > it would be good to get things moved this release that can be
> > > > moved this release. Trying to use sunxi w/o MMC isn't going to be
> > > > fun :)
> > >
> > > Understood. I just gave it a quick try and it is actually quite
> > > easy: We are pretty good already regarding gate clocks and resets,
> > > with the new DM_CLK driver (v2 on the list). And using them in
> > > sunxi_mmc.c is a piece of cake and very clean.
> > > We just need to keep the MMC mod clock hack in (which this series
> > > here does as well), but can still enable DM_MMC.
> > > And for the next merge window we can tackle this by implementing the
> > > MMC mod clock properly in the clock driver, then replacing the hack
> > > with the normal clk_get_by_name(); clk_set_rate(); sequence.
> >
> > I tried with ahb clock and reset, with v2 version of CLK series and
> > it's straightforward. but mmc clock may take some time along with
> > series of testing. So I just windup this, instead of making some noise
> > at last minute.
>
> What do you mean with that, exactly?
> Do you plan to take your platdata hack for 2019.04?
> I don't like the idea of hacking something up that has no future and
> will be reverted very soon anyway. Instead we should expose the
> foundation part of the clock driver to people now for testing (as you
> did by pushing it, thanks!), but including the MMC gates and resets.
> I have this code ready, just need to test it on some SoCs this evening.
>
> I think taking this change is the best compromise between changing
> not too many things at once, yet still exposing new code to the users
> for testing.
>
> And yes, the MMC mod clock is somewhat of a beast, but if we have
> just this in the next release, it should be easier to debug than when
> we expose the whole of the new clock framework to MMC by then only.

This is I was thinking too, in fact I have created next version wrt
CLK support which may override your recent changes. May be I can
prepare and by combining both. what do you say?

[U-Boot] [PATCH v2 0/7] mmc: sunxi: Enable DM_MMC

[André Przywara]

On 19/01/2019 05:50, Jagan Teki wrote:
> On Fri, Jan 18, 2019 at 11:18 PM Andre Przywara <andre.przywara@arm.com> wrote:
>>
>> On Fri, 18 Jan 2019 22:11:36 +0530
>> Jagan Teki <jagan@amarulasolutions.com> wrote:
>>
>> Hi,
>>
>>> On Fri, Jan 18, 2019 at 6:00 PM Andre Przywara
>>> <andre.przywara@arm.com> wrote:
>>>>
>>>> On Fri, 18 Jan 2019 07:17:41 -0500
>>>> Tom Rini <trini@konsulko.com> wrote:
>>>>
>>>>> On Fri, Jan 18, 2019 at 11:53:49AM +0000, Andre Przywara wrote:
>>>>>> On Thu, 17 Jan 2019 22:39:44 +0530
>>>>>> Jagan Teki <jagan@amarulasolutions.com> wrote:
>>>>>>
>>>>>>> V2 for previous version[1] changes, for enabling DM_MMC
>>>>>>> on Allwinner platform.
>>>>>>
>>>>>> So this is a neat and simple solution to the DM_MMC problem, to
>>>>>> the point where I am wondering why we actually need all those
>>>>>> DT driven clock and reset drivers in the first place.
>>>>>> But as I understand using plat data in this way is somewhat
>>>>>> frowned upon and considered deprecated (although it makes a lot
>>>>>> of sense in this context).
>>>>>>
>>>>>> Also, isn't this series independent from the clock gates/reset
>>>>>> patches? So why do you pile them on top of each other in
>>>>>> sunxi/next?
>>>>>>
>>>>>> If we really want to have the full featured DT driven clock and
>>>>>> reset support, why not use it together:
>>>>>> We keep the current mod clock support in the MMC driver, but
>>>>>> use the newly introduced clock gates and reset support via the
>>>>>> new clock driver, mostly replacing this series. This would give
>>>>>> us some test coverage of the new clock driver, while still
>>>>>> avoiding to rush the MMC mod clock implementation.
>>>>>>
>>>>>> Does that make sense? Happy to bake some patches for that on the
>>>>>> weekend.
>>>>>>
>>>>>> Btw: After talking to Tom on IRC, the DM_MMC deadline is
>>>>>> actually _after_ the 2019.04 release, so we don't need to have
>>>>>> DM_MMC support in this merge window.
>>>>>
>>>>> To be clearer, I plan to mark as BROKEN and start saying we're
>>>>> going to remove stuff that isn't migrated, after the release.  So
>>>>> it would be good to get things moved this release that can be
>>>>> moved this release. Trying to use sunxi w/o MMC isn't going to be
>>>>> fun :)
>>>>
>>>> Understood. I just gave it a quick try and it is actually quite
>>>> easy: We are pretty good already regarding gate clocks and resets,
>>>> with the new DM_CLK driver (v2 on the list). And using them in
>>>> sunxi_mmc.c is a piece of cake and very clean.
>>>> We just need to keep the MMC mod clock hack in (which this series
>>>> here does as well), but can still enable DM_MMC.
>>>> And for the next merge window we can tackle this by implementing the
>>>> MMC mod clock properly in the clock driver, then replacing the hack
>>>> with the normal clk_get_by_name(); clk_set_rate(); sequence.
>>>
>>> I tried with ahb clock and reset, with v2 version of CLK series and
>>> it's straightforward. but mmc clock may take some time along with
>>> series of testing. So I just windup this, instead of making some noise
>>> at last minute.
>>
>> What do you mean with that, exactly?
>> Do you plan to take your platdata hack for 2019.04?
>> I don't like the idea of hacking something up that has no future and
>> will be reverted very soon anyway. Instead we should expose the
>> foundation part of the clock driver to people now for testing (as you
>> did by pushing it, thanks!), but including the MMC gates and resets.
>> I have this code ready, just need to test it on some SoCs this evening.
>>
>> I think taking this change is the best compromise between changing
>> not too many things at once, yet still exposing new code to the users
>> for testing.
>>
>> And yes, the MMC mod clock is somewhat of a beast, but if we have
>> just this in the next release, it should be easier to debug than when
>> we expose the whole of the new clock framework to MMC by then only.
> 
> This is I was thinking too, in fact I have created next version wrt
> CLK support which may override your recent changes. May be I can
> prepare and by combining both. what do you say?

It's hard to say without seeing the code, but I think we should take it
easy, since I believe we have enough invasive changes for one release
already.

Given the sheer number of Allwinner boards that we change (142!)
compared to the number of boards that we can test ourselves we should be
more careful, thinking about the breakages we had in December alone.

What's in sunxi/master is probably in good shape, and together with the
part that enables MMC to use it we get rid of the warnings already, so I
think it's worth trying to push this into the 2019.04 release. This
relieves us from the pressure and allows to give the new clock framework
some testing.

And by running buildman I saw that we still get warnings about DM_VIDEO
(95 boards) and DM_SCSI (22 boards), so there is still enough work ahead.

So sure, let's share the code, but lets keep the changes as minimal as
possible. The MMC mod clock certainly isn't minimal.

Cheers,
Andre.