[PATCH 00/13] Remove mach-kirkwood and mach-dove

[PATCH 00/13] Remove mach-kirkwood and mach-dove

[Andrew Lunn]

This patchset removes arch/arm/mach-kirkwood and arch/arm/mach-dove.
These SoCs are now supported in arch/arm/mach-mvebu using device tree.

Change the dependencies for a number of drivers, either to use
ARCH_MVEBU where the drivers are generic, or MACH_KIRKWOOD and
MACH_DOVE where the drivers are specific to a SoC.


Andrew Lunn (13):
  ARM: Kirkwood: Remove mach-kirkwood
  ARM: Dove: Remove mach-dove
  sound: ASoC: kirkwood: Remove unused drivers
  sound: ASoC: kirkwood: Remove ARCH_KIRKWOOD and ARCH_DOVE dependency
  cpuidle: kirkwood: Replace ARCH_KIRKWOOD dependency
  ata: Remove ARCH_KIRKWOOD and ARCH_DOVE dependency
  thermal: Replace ARCH_KIRKWOOD and ARCH_DOVE dependency
  leds: Replace ARCH_KIRKWOOD dependency
  PCI: Remove ARCH_KIRKWOOD and ARCH_DOVE dependency
  phy: Replace ARCH_KIRKWOOD and ARCH_DOVE dependency
  rtc: Remove ARCH_KIRKWOOD and ARCH_DOVE dependency
  watchdog: Remove ARCH_KIRKWOOD and ARCH_DOVE dependency
  Remove ARCH_DOVE dependency

 arch/arm/Kconfig                                  |  32 -
 arch/arm/Kconfig.debug                            |  10 +-
 arch/arm/Makefile                                 |   2 -
 arch/arm/boot/dts/Makefile                        |   5 +-
 arch/arm/configs/dove_defconfig                   | 146 -----
 arch/arm/configs/kirkwood_defconfig               | 181 ------
 arch/arm/mach-dove/Kconfig                        |  25 -
 arch/arm/mach-dove/Makefile                       |   5 -
 arch/arm/mach-dove/Makefile.boot                  |   3 -
 arch/arm/mach-dove/cm-a510.c                      |  97 ---
 arch/arm/mach-dove/common.c                       | 411 ------------
 arch/arm/mach-dove/common.h                       |  49 --
 arch/arm/mach-dove/dove-db-setup.c                | 103 ---
 arch/arm/mach-dove/include/mach/bridge-regs.h     |  57 --
 arch/arm/mach-dove/include/mach/dove.h            | 190 ------
 arch/arm/mach-dove/include/mach/entry-macro.S     |  33 -
 arch/arm/mach-dove/include/mach/hardware.h        |  19 -
 arch/arm/mach-dove/include/mach/irqs.h            |  96 ---
 arch/arm/mach-dove/include/mach/pm.h              |  72 ---
 arch/arm/mach-dove/include/mach/uncompress.h      |  36 --
 arch/arm/mach-dove/irq.c                          | 178 ------
 arch/arm/mach-dove/mpp.c                          | 162 -----
 arch/arm/mach-dove/mpp.h                          | 196 ------
 arch/arm/mach-dove/pcie.c                         | 220 -------
 arch/arm/mach-kirkwood/Kconfig                    | 111 ----
 arch/arm/mach-kirkwood/Makefile                   |  14 -
 arch/arm/mach-kirkwood/Makefile.boot              |   3 -
 arch/arm/mach-kirkwood/board-dt.c                 | 223 -------
 arch/arm/mach-kirkwood/common.c                   | 746 ----------------------
 arch/arm/mach-kirkwood/common.h                   |  74 ---
 arch/arm/mach-kirkwood/d2net_v2-setup.c           | 231 -------
 arch/arm/mach-kirkwood/include/mach/bridge-regs.h |  86 ---
 arch/arm/mach-kirkwood/include/mach/entry-macro.S |  34 -
 arch/arm/mach-kirkwood/include/mach/hardware.h    |  14 -
 arch/arm/mach-kirkwood/include/mach/irqs.h        |  65 --
 arch/arm/mach-kirkwood/include/mach/kirkwood.h    | 142 ----
 arch/arm/mach-kirkwood/include/mach/uncompress.h  |  46 --
 arch/arm/mach-kirkwood/irq.c                      |  82 ---
 arch/arm/mach-kirkwood/lacie_v2-common.c          | 114 ----
 arch/arm/mach-kirkwood/lacie_v2-common.h          |  16 -
 arch/arm/mach-kirkwood/mpp.c                      |  43 --
 arch/arm/mach-kirkwood/mpp.h                      | 348 ----------
 arch/arm/mach-kirkwood/netxbig_v2-setup.c         | 422 ------------
 arch/arm/mach-kirkwood/openrd-setup.c             | 255 --------
 arch/arm/mach-kirkwood/pcie.c                     | 296 ---------
 arch/arm/mach-kirkwood/pm.c                       |  76 ---
 arch/arm/mach-kirkwood/pm.h                       |  26 -
 arch/arm/mach-kirkwood/rd88f6192-nas-setup.c      |  89 ---
 arch/arm/mach-kirkwood/rd88f6281-setup.c          | 128 ----
 arch/arm/mach-kirkwood/t5325-setup.c              | 216 -------
 arch/arm/mach-kirkwood/ts219-setup.c              | 142 ----
 arch/arm/mach-kirkwood/ts41x-setup.c              | 186 ------
 arch/arm/mach-kirkwood/tsx1x-common.c             | 113 ----
 arch/arm/mach-kirkwood/tsx1x-common.h             |   7 -
 arch/arm/mm/Kconfig                               |   2 +-
 drivers/ata/Kconfig                               |   4 +-
 drivers/cpuidle/Kconfig.arm                       |   2 +-
 drivers/leds/Kconfig                              |   4 +-
 drivers/mmc/host/Kconfig                          |   2 +-
 drivers/pci/host/Kconfig                          |   2 +-
 drivers/phy/Kconfig                               |   2 +-
 drivers/rtc/Kconfig                               |   2 +-
 drivers/thermal/Kconfig                           |   4 +-
 drivers/watchdog/Kconfig                          |   2 +-
 sound/soc/kirkwood/Kconfig                        |  19 +-
 sound/soc/kirkwood/Makefile                       |   4 -
 sound/soc/kirkwood/kirkwood-openrd.c              | 109 ----
 sound/soc/kirkwood/kirkwood-t5325.c               | 116 ----
 68 files changed, 20 insertions(+), 6930 deletions(-)
 delete mode 100644 arch/arm/configs/dove_defconfig
 delete mode 100644 arch/arm/configs/kirkwood_defconfig
 delete mode 100644 arch/arm/mach-dove/Kconfig
 delete mode 100644 arch/arm/mach-dove/Makefile
 delete mode 100644 arch/arm/mach-dove/Makefile.boot
 delete mode 100644 arch/arm/mach-dove/cm-a510.c
 delete mode 100644 arch/arm/mach-dove/common.c
 delete mode 100644 arch/arm/mach-dove/common.h
 delete mode 100644 arch/arm/mach-dove/dove-db-setup.c
 delete mode 100644 arch/arm/mach-dove/include/mach/bridge-regs.h
 delete mode 100644 arch/arm/mach-dove/include/mach/dove.h
 delete mode 100644 arch/arm/mach-dove/include/mach/entry-macro.S
 delete mode 100644 arch/arm/mach-dove/include/mach/hardware.h
 delete mode 100644 arch/arm/mach-dove/include/mach/irqs.h
 delete mode 100644 arch/arm/mach-dove/include/mach/pm.h
 delete mode 100644 arch/arm/mach-dove/include/mach/uncompress.h
 delete mode 100644 arch/arm/mach-dove/irq.c
 delete mode 100644 arch/arm/mach-dove/mpp.c
 delete mode 100644 arch/arm/mach-dove/mpp.h
 delete mode 100644 arch/arm/mach-dove/pcie.c
 delete mode 100644 arch/arm/mach-kirkwood/Kconfig
 delete mode 100644 arch/arm/mach-kirkwood/Makefile
 delete mode 100644 arch/arm/mach-kirkwood/Makefile.boot
 delete mode 100644 arch/arm/mach-kirkwood/board-dt.c
 delete mode 100644 arch/arm/mach-kirkwood/common.c
 delete mode 100644 arch/arm/mach-kirkwood/common.h
 delete mode 100644 arch/arm/mach-kirkwood/d2net_v2-setup.c
 delete mode 100644 arch/arm/mach-kirkwood/include/mach/bridge-regs.h
 delete mode 100644 arch/arm/mach-kirkwood/include/mach/entry-macro.S
 delete mode 100644 arch/arm/mach-kirkwood/include/mach/hardware.h
 delete mode 100644 arch/arm/mach-kirkwood/include/mach/irqs.h
 delete mode 100644 arch/arm/mach-kirkwood/include/mach/kirkwood.h
 delete mode 100644 arch/arm/mach-kirkwood/include/mach/uncompress.h
 delete mode 100644 arch/arm/mach-kirkwood/irq.c
 delete mode 100644 arch/arm/mach-kirkwood/lacie_v2-common.c
 delete mode 100644 arch/arm/mach-kirkwood/lacie_v2-common.h
 delete mode 100644 arch/arm/mach-kirkwood/mpp.c
 delete mode 100644 arch/arm/mach-kirkwood/mpp.h
 delete mode 100644 arch/arm/mach-kirkwood/netxbig_v2-setup.c
 delete mode 100644 arch/arm/mach-kirkwood/openrd-setup.c
 delete mode 100644 arch/arm/mach-kirkwood/pcie.c
 delete mode 100644 arch/arm/mach-kirkwood/pm.c
 delete mode 100644 arch/arm/mach-kirkwood/pm.h
 delete mode 100644 arch/arm/mach-kirkwood/rd88f6192-nas-setup.c
 delete mode 100644 arch/arm/mach-kirkwood/rd88f6281-setup.c
 delete mode 100644 arch/arm/mach-kirkwood/t5325-setup.c
 delete mode 100644 arch/arm/mach-kirkwood/ts219-setup.c
 delete mode 100644 arch/arm/mach-kirkwood/ts41x-setup.c
 delete mode 100644 arch/arm/mach-kirkwood/tsx1x-common.c
 delete mode 100644 arch/arm/mach-kirkwood/tsx1x-common.h
 delete mode 100644 sound/soc/kirkwood/kirkwood-openrd.c
 delete mode 100644 sound/soc/kirkwood/kirkwood-t5325.c


Cc: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org
Cc: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: linux-pm@vger.kernel.org
Cc: Tejun Heo <tj@kernel.org>
Cc: linux-ide@vger.kernel.org
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: Bryan Wu <cooloney@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: linux-leds@vger.kernel.org
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-pci@vger.kernel.org
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: rtc-linux@googlegroups.com
Cc: Wim Van Sebroeck <wim@iguana.be>
Cc: linux-watchdog@vger.kernel.org

-- 
2.0.0

[PATCH 03/13] ASoC: kirkwood: Remove unused drivers

[Andrew Lunn]

Both kirkwood-openrd and kirkwood-t5325 drivers have been replaced
with DT based simple-card equivelents.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Cc: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org
---
 sound/soc/kirkwood/Kconfig           |  17 -----
 sound/soc/kirkwood/Makefile          |   4 --
 sound/soc/kirkwood/kirkwood-openrd.c | 109 --------------------------------
 sound/soc/kirkwood/kirkwood-t5325.c  | 116 -----------------------------------
 4 files changed, 246 deletions(-)
 delete mode 100644 sound/soc/kirkwood/kirkwood-openrd.c
 delete mode 100644 sound/soc/kirkwood/kirkwood-t5325.c

diff --git a/sound/soc/kirkwood/Kconfig b/sound/soc/kirkwood/Kconfig
index 06f4e8aa93ae..1f7c7ee3527a 100644
--- a/sound/soc/kirkwood/Kconfig
+++ b/sound/soc/kirkwood/Kconfig
@@ -15,20 +15,3 @@ config SND_KIRKWOOD_SOC_ARMADA370_DB
 	  Say Y if you want to add support for SoC audio on
 	  the Armada 370 Development Board.
 
-config SND_KIRKWOOD_SOC_OPENRD
-	tristate "SoC Audio support for Kirkwood Openrd Client"
-	depends on SND_KIRKWOOD_SOC && (MACH_OPENRD_CLIENT || MACH_OPENRD_ULTIMATE || COMPILE_TEST)
-	depends on I2C
-	select SND_SOC_CS42L51
-	help
-	  Say Y if you want to add support for SoC audio on
-	  Openrd Client.
-
-config SND_KIRKWOOD_SOC_T5325
-	tristate "SoC Audio support for HP t5325"
-	depends on SND_KIRKWOOD_SOC && (MACH_T5325 || COMPILE_TEST) && I2C
-	select SND_SOC_ALC5623
-	help
-	  Say Y if you want to add support for SoC audio on
-	  the HP t5325 thin client.
-
diff --git a/sound/soc/kirkwood/Makefile b/sound/soc/kirkwood/Makefile
index 7c1d8fe09e6b..c36b03d8006c 100644
--- a/sound/soc/kirkwood/Makefile
+++ b/sound/soc/kirkwood/Makefile
@@ -2,10 +2,6 @@ snd-soc-kirkwood-objs := kirkwood-dma.o kirkwood-i2s.o
 
 obj-$(CONFIG_SND_KIRKWOOD_SOC) += snd-soc-kirkwood.o
 
-snd-soc-openrd-objs := kirkwood-openrd.o
-snd-soc-t5325-objs := kirkwood-t5325.o
 snd-soc-armada-370-db-objs := armada-370-db.o
 
 obj-$(CONFIG_SND_KIRKWOOD_SOC_ARMADA370_DB) += snd-soc-armada-370-db.o
-obj-$(CONFIG_SND_KIRKWOOD_SOC_OPENRD) += snd-soc-openrd.o
-obj-$(CONFIG_SND_KIRKWOOD_SOC_T5325) += snd-soc-t5325.o
diff --git a/sound/soc/kirkwood/kirkwood-openrd.c b/sound/soc/kirkwood/kirkwood-openrd.c
deleted file mode 100644
index 65f2a5b9ec3b..000000000000
diff --git a/sound/soc/kirkwood/kirkwood-t5325.c b/sound/soc/kirkwood/kirkwood-t5325.c
deleted file mode 100644
index 844b8415a011..000000000000
-- 
2.0.0

[PATCH 03/13] sound: ASoC: kirkwood: Remove unused drivers

[Andrew Lunn]

Both kirkwood-openrd and kirkwood-t5325 drivers have been replaced
with DT based simple-card equivelents.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Cc: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org
---
 sound/soc/kirkwood/Kconfig           |  17 -----
 sound/soc/kirkwood/Makefile          |   4 --
 sound/soc/kirkwood/kirkwood-openrd.c | 109 --------------------------------
 sound/soc/kirkwood/kirkwood-t5325.c  | 116 -----------------------------------
 4 files changed, 246 deletions(-)
 delete mode 100644 sound/soc/kirkwood/kirkwood-openrd.c
 delete mode 100644 sound/soc/kirkwood/kirkwood-t5325.c

diff --git a/sound/soc/kirkwood/Kconfig b/sound/soc/kirkwood/Kconfig
index 06f4e8aa93ae..1f7c7ee3527a 100644
--- a/sound/soc/kirkwood/Kconfig
+++ b/sound/soc/kirkwood/Kconfig
@@ -15,20 +15,3 @@ config SND_KIRKWOOD_SOC_ARMADA370_DB
 	  Say Y if you want to add support for SoC audio on
 	  the Armada 370 Development Board.
 
-config SND_KIRKWOOD_SOC_OPENRD
-	tristate "SoC Audio support for Kirkwood Openrd Client"
-	depends on SND_KIRKWOOD_SOC && (MACH_OPENRD_CLIENT || MACH_OPENRD_ULTIMATE || COMPILE_TEST)
-	depends on I2C
-	select SND_SOC_CS42L51
-	help
-	  Say Y if you want to add support for SoC audio on
-	  Openrd Client.
-
-config SND_KIRKWOOD_SOC_T5325
-	tristate "SoC Audio support for HP t5325"
-	depends on SND_KIRKWOOD_SOC && (MACH_T5325 || COMPILE_TEST) && I2C
-	select SND_SOC_ALC5623
-	help
-	  Say Y if you want to add support for SoC audio on
-	  the HP t5325 thin client.
-
diff --git a/sound/soc/kirkwood/Makefile b/sound/soc/kirkwood/Makefile
index 7c1d8fe09e6b..c36b03d8006c 100644
--- a/sound/soc/kirkwood/Makefile
+++ b/sound/soc/kirkwood/Makefile
@@ -2,10 +2,6 @@ snd-soc-kirkwood-objs := kirkwood-dma.o kirkwood-i2s.o
 
 obj-$(CONFIG_SND_KIRKWOOD_SOC) += snd-soc-kirkwood.o
 
-snd-soc-openrd-objs := kirkwood-openrd.o
-snd-soc-t5325-objs := kirkwood-t5325.o
 snd-soc-armada-370-db-objs := armada-370-db.o
 
 obj-$(CONFIG_SND_KIRKWOOD_SOC_ARMADA370_DB) += snd-soc-armada-370-db.o
-obj-$(CONFIG_SND_KIRKWOOD_SOC_OPENRD) += snd-soc-openrd.o
-obj-$(CONFIG_SND_KIRKWOOD_SOC_T5325) += snd-soc-t5325.o
diff --git a/sound/soc/kirkwood/kirkwood-openrd.c b/sound/soc/kirkwood/kirkwood-openrd.c
deleted file mode 100644
index 65f2a5b9ec3b..000000000000
diff --git a/sound/soc/kirkwood/kirkwood-t5325.c b/sound/soc/kirkwood/kirkwood-t5325.c
deleted file mode 100644
index 844b8415a011..000000000000
-- 
2.0.0

[PATCH 04/13] ASoC: kirkwood: Remove ARCH_KIRKWOOD and ARCH_DOVE dependency

[Andrew Lunn]

Both mach-kirkwood and mach-dove has been removed, now that Kirkwood
and Dove live in mach-mvebu. Remove these config symbols since
ARCH_MVEBU is sufficient.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Cc: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org
---
 sound/soc/kirkwood/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/kirkwood/Kconfig b/sound/soc/kirkwood/Kconfig
index 1f7c7ee3527a..952234de0cac 100644
--- a/sound/soc/kirkwood/Kconfig
+++ b/sound/soc/kirkwood/Kconfig
@@ -1,6 +1,6 @@
 config SND_KIRKWOOD_SOC
 	tristate "SoC Audio for the Marvell Kirkwood and Dove chips"
-	depends on ARCH_KIRKWOOD || ARCH_DOVE || ARCH_MVEBU || MACH_KIRKWOOD || COMPILE_TEST
+	depends on ARCH_MVEBU || COMPILE_TEST
 	help
 	  Say Y or M if you want to add support for codecs attached to
 	  the Kirkwood I2S interface. You will also need to select the
-- 
2.0.0

[PATCH 04/13] sound: ASoC: kirkwood: Remove ARCH_KIRKWOOD and ARCH_DOVE dependency

[Andrew Lunn]

Both mach-kirkwood and mach-dove has been removed, now that Kirkwood
and Dove live in mach-mvebu. Remove these config symbols since
ARCH_MVEBU is sufficient.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Cc: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org
---
 sound/soc/kirkwood/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/kirkwood/Kconfig b/sound/soc/kirkwood/Kconfig
index 1f7c7ee3527a..952234de0cac 100644
--- a/sound/soc/kirkwood/Kconfig
+++ b/sound/soc/kirkwood/Kconfig
@@ -1,6 +1,6 @@
 config SND_KIRKWOOD_SOC
 	tristate "SoC Audio for the Marvell Kirkwood and Dove chips"
-	depends on ARCH_KIRKWOOD || ARCH_DOVE || ARCH_MVEBU || MACH_KIRKWOOD || COMPILE_TEST
+	depends on ARCH_MVEBU || COMPILE_TEST
 	help
 	  Say Y or M if you want to add support for codecs attached to
 	  the Kirkwood I2S interface. You will also need to select the
-- 
2.0.0

[PATCH 05/13] cpuidle: kirkwood: Replace ARCH_KIRKWOOD dependency

[Andrew Lunn]

mach-kirkwood has been removed, now that kirkwood lives in mach-mvebu.
Use MACH_KIRKWOOD, which is set when kirkwood is built as part of
mach-mvebu.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: linux-pm@vger.kernel.org
---
 drivers/cpuidle/Kconfig.arm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
index b6d69e899f5d..dd9afb405766 100644
--- a/drivers/cpuidle/Kconfig.arm
+++ b/drivers/cpuidle/Kconfig.arm
@@ -33,7 +33,7 @@ config ARM_HIGHBANK_CPUIDLE
 
 config ARM_KIRKWOOD_CPUIDLE
 	bool "CPU Idle Driver for Marvell Kirkwood SoCs"
-	depends on ARCH_KIRKWOOD || MACH_KIRKWOOD
+	depends on MACH_KIRKWOOD
 	help
 	  This adds the CPU Idle driver for Marvell Kirkwood SoCs.
 
-- 
2.0.0

[PATCH 06/13] ata: Remove ARCH_KIRKWOOD and ARCH_DOVE dependency

[Andrew Lunn]

Both mach-kirkwood and mach-dove have been removed, now that both SoCs
lives in mach-mvebu. ARCH_MVEBU is sufficient.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Cc: Tejun Heo <tj@kernel.org>
Cc: linux-ide@vger.kernel.org
---
 drivers/ata/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 7671dbac6015..5991089492d0 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -289,8 +289,8 @@ config SATA_HIGHBANK
 
 config SATA_MV
 	tristate "Marvell SATA support"
-	depends on PCI || ARCH_DOVE || ARCH_KIRKWOOD || ARCH_MV78XX0 || \
-		   ARCH_MVEBU || ARCH_ORION5X || COMPILE_TEST
+	depends on PCI || ARCH_MV78XX0 || ARCH_MVEBU || ARCH_ORION5X || \
+		   COMPILE_TEST
 	select GENERIC_PHY
 	help
 	  This option enables support for the Marvell Serial ATA family.
-- 
2.0.0

[PATCH 07/13] thermal: Replace ARCH_KIRKWOOD and ARCH_DOVE dependency

[Andrew Lunn]

Both mach-kirkwood and mach-dove has been removed, now that these SoCs
live in mach-mvebu. Depend on MACH_KIRKWOOD and MACH_DOVE, which will
be set when these SoCs are built as part of ARCH_MVEBU.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
---
 drivers/thermal/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index f9a13867cb70..a0f1371517ee 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -143,7 +143,7 @@ config RCAR_THERMAL
 
 config KIRKWOOD_THERMAL
 	tristate "Temperature sensor on Marvell Kirkwood SoCs"
-	depends on ARCH_KIRKWOOD || MACH_KIRKWOOD
+	depends on MACH_KIRKWOOD
 	depends on OF
 	help
 	  Support for the Kirkwood thermal sensor driver into the Linux thermal
@@ -151,7 +151,7 @@ config KIRKWOOD_THERMAL
 
 config DOVE_THERMAL
 	tristate "Temperature sensor on Marvell Dove SoCs"
-	depends on ARCH_DOVE
+	depends on MACH_DOVE
 	depends on OF
 	help
 	  Support for the Dove thermal sensor driver in the Linux thermal
-- 
2.0.0

[PATCH 08/13] leds: Replace ARCH_KIRKWOOD dependency

[Andrew Lunn]

mach-kirkwood has been removed, now that kirkwood SoC lives in
mach-mvebu. Use MACH_KIRKWOOD which will be set when kirkwood is built
as part of mach-mvebu.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Cc: Bryan Wu <cooloney@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: linux-leds@vger.kernel.org
---
 drivers/leds/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index a1b044e7eaad..2d7c380f79ce 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -411,7 +411,7 @@ config LEDS_MC13783
 config LEDS_NS2
 	tristate "LED support for Network Space v2 GPIO LEDs"
 	depends on LEDS_CLASS
-	depends on ARCH_KIRKWOOD || MACH_KIRKWOOD
+	depends on MACH_KIRKWOOD
 	default y
 	help
 	  This option enable support for the dual-GPIO LED found on the
@@ -421,7 +421,7 @@ config LEDS_NS2
 config LEDS_NETXBIG
 	tristate "LED support for Big Network series LEDs"
 	depends on LEDS_CLASS
-	depends on ARCH_KIRKWOOD || MACH_KIRKWOOD
+	depends on MACH_KIRKWOOD
 	default y
 	help
 	  This option enable support for LEDs found on the LaCie 2Big
-- 
2.0.0

[PATCH 09/13] PCI: Remove ARCH_KIRKWOOD and ARCH_DOVE dependency

[Andrew Lunn]

mach-kirkwood and mach-dove have been removed, now that these SoCs
lives in mach-mvebu. ARCH_MVEBU is sufficient.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-pci@vger.kernel.org
---
 drivers/pci/host/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 21df477be0c8..b9692deeb99a 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -3,7 +3,7 @@ menu "PCI host controller drivers"
 
 config PCI_MVEBU
 	bool "Marvell EBU PCIe controller"
-	depends on ARCH_MVEBU || ARCH_DOVE || ARCH_KIRKWOOD
+	depends on ARCH_MVEBU
 	depends on OF
 
 config PCIE_DW
-- 
2.0.0

[PATCH 12/13] watchdog: Remove ARCH_KIRKWOOD and ARCH_DOVE dependency

[Andrew Lunn]

Both mach-kirkwood and mach-dove has been removed, now that these SoCs
lives in mach-mvebu. ARCH_MVEBU is sufficient.

Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Cc: Wim Van Sebroeck <wim@iguana.be>
Cc: linux-watchdog@vger.kernel.org
---
 drivers/watchdog/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 76dd54122f76..e4f0ae3a59dc 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -301,7 +301,7 @@ config DAVINCI_WATCHDOG
 
 config ORION_WATCHDOG
 	tristate "Orion watchdog"
-	depends on ARCH_ORION5X || ARCH_KIRKWOOD || ARCH_DOVE || MACH_DOVE || ARCH_MVEBU
+	depends on ARCH_ORION5X || ARCH_MVEBU
 	select WATCHDOG_CORE
 	help
 	  Say Y here if to include support for the watchdog timer
-- 
2.0.0

Re: [PATCH 00/13] Remove mach-kirkwood and mach-dove

[Russell King - ARM Linux]

On Sun, Jun 29, 2014 at 10:59:47PM +0200, Andrew Lunn wrote:
> This patchset removes arch/arm/mach-kirkwood and arch/arm/mach-dove.
> These SoCs are now supported in arch/arm/mach-mvebu using device tree.
> 
> Change the dependencies for a number of drivers, either to use
> ARCH_MVEBU where the drivers are generic, or MACH_KIRKWOOD and
> MACH_DOVE where the drivers are specific to a SoC.
> 
> 
> Andrew Lunn (13):
>   ARM: Kirkwood: Remove mach-kirkwood
>   ARM: Dove: Remove mach-dove

There is actually a cubox regression which has yet to be tracked down.
Running with my kernel (which is not-DT based) runs perfectly.  With
DT, HDMI output can be unstable.

One of the problems is that it's /very/ difficult to reproduce, but it
is reproducable.  I've seen it on two days over many reboots, and I've
proved it by switching back and forth.  DT sometimes suffers from the
problem, whereas non-DT /never/ does.

Sebastian is aware of this, and as yet we haven't found a solution,
nor have we found a way to reliably reproduce it.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Re: [alsa-devel] [PATCH 00/13] Remove mach-kirkwood and mach-dove

[Jean-Francois Moine]

On Sun, 29 Jun 2014 22:35:11 +0100
Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:

> There is actually a cubox regression which has yet to be tracked down.
> Running with my kernel (which is not-DT based) runs perfectly.  With
> DT, HDMI output can be unstable.

Russell,

What is this HDMI problem with DT?

I am running a DT based kernel on my Cubox for more than 1 year and the
only problem I have is a random black screen at startup time, and this
black screen problem also exists with the old non-DT kernels from
SolidRun.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

Re: [alsa-devel] [PATCH 00/13] Remove mach-kirkwood and mach-dove

[Jean-Francois Moine]

On Sun, 29 Jun 2014 22:35:11 +0100
Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:

> There is actually a cubox regression which has yet to be tracked down.
> Running with my kernel (which is not-DT based) runs perfectly.  With
> DT, HDMI output can be unstable.

Russell,

What is this HDMI problem with DT?

I am running a DT based kernel on my Cubox for more than 1 year and the
only problem I have is a random black screen at startup time, and this
black screen problem also exists with the old non-DT kernels from
SolidRun.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH 00/13] Remove mach-kirkwood and mach-dove

[Russell King - ARM Linux]

On Mon, Jun 30, 2014 at 09:16:43AM +0200, Jean-Francois Moine wrote:
> On Sun, 29 Jun 2014 22:35:11 +0100
> Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> 
> > There is actually a cubox regression which has yet to be tracked down.
> > Running with my kernel (which is not-DT based) runs perfectly.  With
> > DT, HDMI output can be unstable.
> 
> Russell,
> 
> What is this HDMI problem with DT?
> 
> I am running a DT based kernel on my Cubox for more than 1 year and the
> only problem I have is a random black screen at startup time, and this
> black screen problem also exists with the old non-DT kernels from
> SolidRun.

The problem is that the picture appears for about a second, then goes black
for maybe a couple of seconds, then reappears for about a second and this
cycle repeats.  Rebooting into the DT kernel doesn't fix it.  Rebooting
back into the non-DT kernel does fix it.  Then if you boot back into the DT
kernel it's back again.  Boot back into the non-DT kernel and it's again
fixed.

I have compared register settings for the Si5351, LCD controllers and the
TDA998x between the non-DT and DT versions, and can find no differences
there.  Yet, DT kernels are the only kernels which exhibit this behaviour.
Non-DT kernels (which I've run continuously including many reboots) for
the last two years have *never* shown this problem.

I have also verified that the HDMI clock is correct.  The problem occurs
at both 1080p and 720p resolutions (which are the two that are used during
boot - I have the kernel using 720p, and Xorg uses 1080p.)

I should also point out that in both cases, it is the _same_ kernel binary
(3.15) that I'm running - the DT test case just has the DT blob attached
whereas the non-DT case boots without (and therefore falls back to the
old platform stuff.)

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Re: [alsa-devel] [PATCH 00/13] Remove mach-kirkwood and mach-dove

[Jean-Francois Moine]

On Mon, 30 Jun 2014 09:49:18 +0100
Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:

> The problem is that the picture appears for about a second, then goes black
> for maybe a couple of seconds, then reappears for about a second and this
> cycle repeats.  Rebooting into the DT kernel doesn't fix it.  Rebooting
> back into the non-DT kernel does fix it.  Then if you boot back into the DT
> kernel it's back again.  Boot back into the non-DT kernel and it's again
> fixed.
> 
> I have compared register settings for the Si5351, LCD controllers and the
> TDA998x between the non-DT and DT versions, and can find no differences
> there.  Yet, DT kernels are the only kernels which exhibit this behaviour.
> Non-DT kernels (which I've run continuously including many reboots) for
> the last two years have *never* shown this problem.
> 
> I have also verified that the HDMI clock is correct.  The problem occurs
> at both 1080p and 720p resolutions (which are the two that are used during
> boot - I have the kernel using 720p, and Xorg uses 1080p.)
> 
> I should also point out that in both cases, it is the _same_ kernel binary
> (3.15) that I'm running - the DT test case just has the DT blob attached
> whereas the non-DT case boots without (and therefore falls back to the
> old platform stuff.)

Have you declared the LCD clock in dove.dtsi?

 	lcdclk: fixed-clock {
		compatible = "fixed-clock";
 		#clock-cells = <0>;
 		clock-frequency = <400000000>;
 	};

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

Re: [alsa-devel] [PATCH 00/13] Remove mach-kirkwood and mach-dove

[Jean-Francois Moine]

On Mon, 30 Jun 2014 09:49:18 +0100
Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:

> The problem is that the picture appears for about a second, then goes black
> for maybe a couple of seconds, then reappears for about a second and this
> cycle repeats.  Rebooting into the DT kernel doesn't fix it.  Rebooting
> back into the non-DT kernel does fix it.  Then if you boot back into the DT
> kernel it's back again.  Boot back into the non-DT kernel and it's again
> fixed.
> 
> I have compared register settings for the Si5351, LCD controllers and the
> TDA998x between the non-DT and DT versions, and can find no differences
> there.  Yet, DT kernels are the only kernels which exhibit this behaviour.
> Non-DT kernels (which I've run continuously including many reboots) for
> the last two years have *never* shown this problem.
> 
> I have also verified that the HDMI clock is correct.  The problem occurs
> at both 1080p and 720p resolutions (which are the two that are used during
> boot - I have the kernel using 720p, and Xorg uses 1080p.)
> 
> I should also point out that in both cases, it is the _same_ kernel binary
> (3.15) that I'm running - the DT test case just has the DT blob attached
> whereas the non-DT case boots without (and therefore falls back to the
> old platform stuff.)

Have you declared the LCD clock in dove.dtsi?

 	lcdclk: fixed-clock {
		compatible = "fixed-clock";
 		#clock-cells = <0>;
 		clock-frequency = <400000000>;
 	};

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH 00/13] Remove mach-kirkwood and mach-dove

[Russell King - ARM Linux]

On Mon, Jun 30, 2014 at 11:47:01AM +0200, Jean-Francois Moine wrote:
> Have you declared the LCD clock in dove.dtsi?
> 
>  	lcdclk: fixed-clock {
> 		compatible = "fixed-clock";
>  		#clock-cells = <0>;
>  		clock-frequency = <400000000>;
>  	};

And what difference would that make - this would not be used.

The clock used for the LCD controller somes from the Si5351.  The internal
clocks are not used as they are unsuitable for generating the resolutions
we require.  The other clocks used by the LCD controller (AXI clock and
PLL clock) are both fundamental clocks in the SoC, neither are 400MHz.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Re: [PATCH 00/13] Remove mach-kirkwood and mach-dove

[Sebastian Hesselbarth]

On 06/29/2014 11:35 PM, Russell King - ARM Linux wrote:
> On Sun, Jun 29, 2014 at 10:59:47PM +0200, Andrew Lunn wrote:
>> This patchset removes arch/arm/mach-kirkwood and arch/arm/mach-dove.
>> These SoCs are now supported in arch/arm/mach-mvebu using device tree.
>>
>> Change the dependencies for a number of drivers, either to use
>> ARCH_MVEBU where the drivers are generic, or MACH_KIRKWOOD and
>> MACH_DOVE where the drivers are specific to a SoC.
>>
>>
>> Andrew Lunn (13):
>>    ARM: Kirkwood: Remove mach-kirkwood
>>    ARM: Dove: Remove mach-dove
>
> There is actually a cubox regression which has yet to be tracked down.
> Running with my kernel (which is not-DT based) runs perfectly.  With
> DT, HDMI output can be unstable.
>
> One of the problems is that it's /very/ difficult to reproduce, but it
> is reproducable.  I've seen it on two days over many reboots, and I've
> proved it by switching back and forth.  DT sometimes suffers from the
> problem, whereas non-DT /never/ does.
>
> Sebastian is aware of this, and as yet we haven't found a solution,
> nor have we found a way to reliably reproduce it.

I am aware of the issue but have not been able to reproduce it. Also,
we have no /official/ non-DT CuBox support in mainline Linux at all.
I understand that removing non-DT mach-dove currently is not your
most preferred patch but from a mainline POV, mach-dove isn't actively
used. The three officially supported boards have been converted to DT
months ago and haven't received any TLC since then, so I doubt they are
used by anyone.

My current impression of the issue is that it is more related with
driver load order/missing delays for clocks/ignoring IP behavior on
clock rate change or something like it.

Can you give a /rough/ schedule for your plans to sort out your private
branches? If we can all investigate the issue with the same code basis,
I am sure we can make DT dove behave the same way non-DT dove seems to
be.

Sebastian

Re: [PATCH 00/13] Remove mach-kirkwood and mach-dove

[Russell King - ARM Linux]

On Mon, Jun 30, 2014 at 02:15:58PM +0200, Sebastian Hesselbarth wrote:
> Can you give a /rough/ schedule for your plans to sort out your private
> branches? If we can all investigate the issue with the same code basis,
> I am sure we can make DT dove behave the same way non-DT dove seems to
> be.

As you will be aware, that is an unreasonable question.  I have no
idea what so ever how long it will take to sort out my private
branches, because it doesn't depend all that much on me.

For example, I've had fully working audio on the Cubox for 18+ months,
but there's a big problem getting it into mainline.  First it was the
lack of co-operation from the ASoC maintainers.  Then it was the ASoC
maintainers accepting Jean-Francois patches (which really torpedoed
my efforts.)  And the final problem which makes it totally impossible
is that pushing the DPCM stuff will completely break the DT based
kirkwood ASoC stuff which got pushed in.

I suspect that the PMU work I did has also been torpedoed because of
no one in the mvebu circles has really thought about how to deal
properly with the overlapping registers for the PMU, hwmon and RTC.

Right now, I have 250 patches in my Cubox tree against a base of
3.15 plus the original set of changes.  And no, I'm *not* going
to be stupid enough to publish the tree because of the non-GPL
license header(s) on various files in the Vivante code base.

I'm actually on the point of just giving up with mainlike on the Cubox
because of this kind of crap, and the extreme difficulty to get any
kind of progress on this stuff - and I'm seeing a growing number of
patches on the Cubox-i side of things, the mainline churn on mach-dove
is becoming a /big/ problem.

So... if you want to remove mach-dove, then I'll just add to my
cubox tree an entire revert of it.  Especially as DT does not work
properly here and non-DT does.

And I really don't buy your "it's down to the timing" explanation -
because (a) switching from 720p to 1080p reprograms the clock chain
right from the Si5351, which is no different to what happens on
initial bring up, and (b) I've measured the HDMI clock which is
derived from this chain and it is correct and unmodulated.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Re: [PATCH 00/13] Remove mach-kirkwood and mach-dove

[Sebastian Hesselbarth]

On 06/30/2014 02:43 PM, Russell King - ARM Linux wrote:
> On Mon, Jun 30, 2014 at 02:15:58PM +0200, Sebastian Hesselbarth wrote:
>> Can you give a /rough/ schedule for your plans to sort out your private
>> branches? If we can all investigate the issue with the same code basis,
>> I am sure we can make DT dove behave the same way non-DT dove seems to
>> be.
>
> As you will be aware, that is an unreasonable question.  I have no
> idea what so ever how long it will take to sort out my private
> branches, because it doesn't depend all that much on me.

Russell,

we all know about the pain to get things into mainline especially when
it touches different sub-systems. That is why I was asking for /your/
plans, so we can think of ways to deal with mach-dove removal and your
pending patches.

> For example, I've had fully working audio on the Cubox for 18+ months,
> but there's a big problem getting it into mainline.  First it was the
> lack of co-operation from the ASoC maintainers.  Then it was the ASoC
> maintainers accepting Jean-Francois patches (which really torpedoed
> my efforts.)  And the final problem which makes it totally impossible
> is that pushing the DPCM stuff will completely break the DT based
> kirkwood ASoC stuff which got pushed in.
>
> I suspect that the PMU work I did has also been torpedoed because of
> no one in the mvebu circles has really thought about how to deal
> properly with the overlapping registers for the PMU, hwmon and RTC.

Of course we thought about it. But as you are dealing with different
SoCs at a time, we also have to care about some more SoCs than just
Dove. And, of course, we also run out of spare time to prepare proper
patches over and over again. I really /know/ that if you send patches,
they are well thought and well tested, so I basically postpone work
on that if I know you are working on it.

My current idea of PMU register space is to have a DT provided regmap
but again, there are patches floating around but currently that regmap
helpers are still WIP. FWIW, if you look at dove pinctrl, we did a
last-minute patch for the PMU regs - just because you mentioned a
concern, so we really care about your opinion. The fact that it is not
solved is pure lack of time.

> Right now, I have 250 patches in my Cubox tree against a base of
> 3.15 plus the original set of changes.  And no, I'm *not* going
> to be stupid enough to publish the tree because of the non-GPL
> license header(s) on various files in the Vivante code base.

Exactly that increasing amount of (valuable) patches makes it more
and more difficult for you and us to reproduce any issues. All I am
asking for is: if you don't push that branch for good reason, try to
split off at least some patches. Hunting issues like the HDMI thing
with 250 patches off, really isn't going to work well.

> I'm actually on the point of just giving up with mainlike on the Cubox
> because of this kind of crap, and the extreme difficulty to get any
> kind of progress on this stuff - and I'm seeing a growing number of
> patches on the Cubox-i side of things, the mainline churn on mach-dove
> is becoming a /big/ problem.
>
> So... if you want to remove mach-dove, then I'll just add to my
> cubox tree an entire revert of it.  Especially as DT does not work
> properly here and non-DT does.

Nobody wants you to revert any cubox patches! Honestly, I repeatedly
said that /although/ I cannot reproduce the issue on my (mainline)
branch, I still /agree/ that there may be issues. But as long as I
cannot reproduce it, I cannot dig into it.

To put it another way: "Especially for me DT does work properly here
and non-DT does not". Let's just try to reduce the gap between mainline
and your branch incrementally.

> And I really don't buy your "it's down to the timing" explanation -
> because (a) switching from 720p to 1080p reprograms the clock chain
> right from the Si5351, which is no different to what happens on
> initial bring up, and (b) I've measured the HDMI clock which is
> derived from this chain and it is correct and unmodulated.

I didn't say I *know* it is 'timing', but neither I do buy "it's because
of DT". I said it may be related with init order and ignoring clock
stable requirements. I've written Si5351 driver from an Application
Note that is not very noisy about dynamic configuration, there are no
checks for stable clocks at all.

Anyway, I still offer my time to hunt the HDMI issue: If we agree on
some way to share your code or you provide some binaries I can reproduce
the issue with, it will be a small step forward.

Sebastian

Re: [PATCH 00/13] Remove mach-kirkwood and mach-dove

[Russell King - ARM Linux]

On Mon, Jun 30, 2014 at 03:22:58PM +0200, Sebastian Hesselbarth wrote:
> Of course we thought about it. But as you are dealing with different
> SoCs at a time, we also have to care about some more SoCs than just
> Dove. And, of course, we also run out of spare time to prepare proper
> patches over and over again. I really /know/ that if you send patches,
> they are well thought and well tested, so I basically postpone work
> on that if I know you are working on it.
>
> My current idea of PMU register space is to have a DT provided regmap
> but again, there are patches floating around but currently that regmap
> helpers are still WIP. FWIW, if you look at dove pinctrl, we did a
> last-minute patch for the PMU regs - just because you mentioned a
> concern, so we really care about your opinion. The fact that it is not
> solved is pure lack of time.

Nothing has changed on the PMU patches since I posted them, because
they're based on 3.15 and there's been no changes there.

> Exactly that increasing amount of (valuable) patches makes it more
> and more difficult for you and us to reproduce any issues. All I am
> asking for is: if you don't push that branch for good reason, try to
> split off at least some patches. Hunting issues like the HDMI thing
> with 250 patches off, really isn't going to work well.

Right, so what I have against mainline right now in my tree is:

* two SPI patches, which have been taken by Mark
* one long term core ARM patch adding optimised memset/memcpy IO operations
* the PMU stuff
* BMM (already published in git form)
* Vmeta (already published in git form)
* ASoC cleanup patches, which Mark took last week.

What isn't visible is the stuff which converts Armada DRM to component
support, along with the TDA998x driver (and it sounds like the TI LCDC
people may end up blocking that effort).  This is necessary to convert
it to DT support.  However, this depends on the component helper, and
that's where there's a blocking problem.

I sent out a bunch of patches last week, with a request for help from
the Exynos people.  So far, that has only attracted one relatively minor
comment from the iMX people.  I can't move forwards with the Armada
DRM until this is sorted.  Neither can I move forward with the TDA998x
driver.

As for the ASoC stuff which you avoided commenting on, let me repeat
that _that_ stuff is now totally dead and can /never/ be merged into
mainline without breaking the existing ASoC kirkwood support.  In
that case, it's not like I wasn't sending the patches out, because
I had been... so everyone was aware of what was going on there,
but I guess converting stuff to DT in ways that totally fuck over
other patches is what now happens in the kernel.

What I think you're missing is that for those of us who want to have
a platform fully supported, the choice has been non-DT until relatively
recently.  We're now at the point where the DT support on Dove has
matured to the point where it's relatively easy to end up with a fully
functional (but not necessarily bug free) setup with DT.  It's at the
sweet spot where you can switch between DT and non-DT and preserve
that functionality... but as soon as we get there we want to rip out
the old stuff.

Let me put that another way: it's at the point where those of us who
have been using non-DT support can start moving the remaining drivers
over to a DT environment without any functional loss.

What I'm trying to get you to understand is that leaving the old stuff
behind for a little while longer is beneficial - while those who have
been running crippled DT based setups for the last year don't care
about having full support, there are those who do.

Of course, there's another solution to this.  I stay with my present
3.15 kernel for ever.  That basically bars me from sending any further
patches.  It also means that I stop maintaining TDA998x and Armada DRM,
and you will have to take those over, which means you get the additional
workload from those.  Is that what you really want?

The Cubox is the /only/ ARM platform I have which is a capable media
player, and I'm trying not to have it screwed by this kind of crap.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Re: [PATCH 00/13] Remove mach-kirkwood and mach-dove

[Sebastian Hesselbarth]

On 06/30/2014 04:25 PM, Russell King - ARM Linux wrote:
> On Mon, Jun 30, 2014 at 03:22:58PM +0200, Sebastian Hesselbarth wrote:
>> Of course we thought about it. But as you are dealing with different
>> SoCs at a time, we also have to care about some more SoCs than just
>> Dove. And, of course, we also run out of spare time to prepare proper
>> patches over and over again. I really /know/ that if you send patches,
>> they are well thought and well tested, so I basically postpone work
>> on that if I know you are working on it.
>>
>> My current idea of PMU register space is to have a DT provided regmap
>> but again, there are patches floating around but currently that regmap
>> helpers are still WIP. FWIW, if you look at dove pinctrl, we did a
>> last-minute patch for the PMU regs - just because you mentioned a
>> concern, so we really care about your opinion. The fact that it is not
>> solved is pure lack of time.
>
> Nothing has changed on the PMU patches since I posted them, because
> they're based on 3.15 and there's been no changes there.

I offered to deal with mainlining them end of April, you never replied.
I know that if you dislike something you answer, but it is hard to tell
if silence means agreement.

I am not going to waste any time preparing patches just to get a NAK.

>> Exactly that increasing amount of (valuable) patches makes it more
>> and more difficult for you and us to reproduce any issues. All I am
>> asking for is: if you don't push that branch for good reason, try to
>> split off at least some patches. Hunting issues like the HDMI thing
>> with 250 patches off, really isn't going to work well.
>
> Right, so what I have against mainline right now in my tree is:
>
> * two SPI patches, which have been taken by Mark
> * one long term core ARM patch adding optimised memset/memcpy IO operations
> * the PMU stuff
> * BMM (already published in git form)
> * Vmeta (already published in git form)
> * ASoC cleanup patches, which Mark took last week.
>
> What isn't visible is the stuff which converts Armada DRM to component
> support, along with the TDA998x driver (and it sounds like the TI LCDC
> people may end up blocking that effort).  This is necessary to convert
> it to DT support.  However, this depends on the component helper, and
> that's where there's a blocking problem.
>
> I sent out a bunch of patches last week, with a request for help from
> the Exynos people.  So far, that has only attracted one relatively minor
> comment from the iMX people.  I can't move forwards with the Armada
> DRM until this is sorted.  Neither can I move forward with the TDA998x
> driver.
>
> As for the ASoC stuff which you avoided commenting on, let me repeat
> that _that_ stuff is now totally dead and can /never/ be merged into
> mainline without breaking the existing ASoC kirkwood support.  In
> that case, it's not like I wasn't sending the patches out, because
> I had been... so everyone was aware of what was going on there,
> but I guess converting stuff to DT in ways that totally fuck over
> other patches is what now happens in the kernel.

If you are talking about "Kirkwood ASoC updates", you got a Tested-by
from Andrew even before I read your patches. And besides, just because
I am interested in Dove does not mean I just swallowed the whole Linux
API knowledge. I simply avoided commenting on it, because there is
/nothing/ I can add to it.

Really, I know you do dig down to the bottom of every subsystem you
are working with but I simply cannot. Just because I don't have the
time for it.

> What I think you're missing is that for those of us who want to have
> a platform fully supported, the choice has been non-DT until relatively
> recently.  We're now at the point where the DT support on Dove has
> matured to the point where it's relatively easy to end up with a fully
> functional (but not necessarily bug free) setup with DT.  It's at the
> sweet spot where you can switch between DT and non-DT and preserve
> that functionality... but as soon as we get there we want to rip out
> the old stuff.

Oh, ok.. you think it is "me" and "us"? It is you who actually want to
use Dove and me just wanting a DT representation for it?

It is not my fault that your patches are blocked by others. I can offer
help to track down the issue, but I am not going to be your scapegoat.

> Let me put that another way: it's at the point where those of us who
> have been using non-DT support can start moving the remaining drivers
> over to a DT environment without any functional loss.
>
> What I'm trying to get you to understand is that leaving the old stuff
> behind for a little while longer is beneficial - while those who have
> been running crippled DT based setups for the last year don't care
> about having full support, there are those who do.

Ok, let's have mach-dove for a little longer, fine with me.

> Of course, there's another solution to this.  I stay with my present
> 3.15 kernel for ever.  That basically bars me from sending any further
> patches.  It also means that I stop maintaining TDA998x and Armada DRM,
> and you will have to take those over, which means you get the additional
> workload from those.  Is that what you really want?

What I really want is to stop that blackmailing with giving up on
sending patches. It will be a huge loss if you do and many have said
that in the past.

If it is really me who upsets you because you feel I am blocking your
patches, just ignore my comments. Jason will happily pick them up
just because you signed them off.

Sebastian

> The Cubox is the /only/ ARM platform I have which is a capable media
> player, and I'm trying not to have it screwed by this kind of crap.
>

Re: [PATCH 00/13] Remove mach-kirkwood and mach-dove

[Jean-Francois Moine]

On Mon, 30 Jun 2014 13:43:20 +0100
Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:

> For example, I've had fully working audio on the Cubox for 18+ months,
> but there's a big problem getting it into mainline.  First it was the
> lack of co-operation from the ASoC maintainers.  Then it was the ASoC
> maintainers accepting Jean-Francois patches (which really torpedoed
> my efforts.)  And the final problem which makes it totally impossible
> is that pushing the DPCM stuff will completely break the DT based
> kirkwood ASoC stuff which got pushed in.

I already tried DPCM with the kirkwood audio subsystem. It just ask to
add a 'system' DAI in kirkwood-i2s. The card is defined as:

- link 0:
	CPU: 'system' (kirkwood new DAI)
	CODEC: 'dummy'
	front-end
- link 1:
	CPU: 'i2s' (kirkwood)
	CODEC: 'i2s-hdmi' (tda998x codec)
	back-end
- link 2
	CPU: 'spdif' (kirkwood)
	CODEC: 'spdif-hdmi' (tda998x codec)
	back-end
- link 3
	CPU: 'spdif' (kirkwood)
	CODEC: 'dit-hifi' (spdif codec)
	backend

with the routes (simple-card format):

	"I2S Playback",   "System Playback",
	"SPDIF Playback", "System Playback",
        
 	"hdmi-out",     "I2S Playback",
 	"hdmi-out",     "SPDIF Playback",
	"spdif-out",    "SPDIF Playback";

This works, but the HW constraints of the sinks are not handled, so,
all backends are always activated for any format/any rate.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH 00/13] Remove mach-kirkwood and mach-dove

[Russell King - ARM Linux]

On Mon, Jun 30, 2014 at 06:13:47PM +0200, Jean-Francois Moine wrote:
> On Mon, 30 Jun 2014 13:43:20 +0100
> Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> 
> > For example, I've had fully working audio on the Cubox for 18+ months,
> > but there's a big problem getting it into mainline.  First it was the
> > lack of co-operation from the ASoC maintainers.  Then it was the ASoC
> > maintainers accepting Jean-Francois patches (which really torpedoed
> > my efforts.)  And the final problem which makes it totally impossible
> > is that pushing the DPCM stuff will completely break the DT based
> > kirkwood ASoC stuff which got pushed in.
> 
> I already tried DPCM with the kirkwood audio subsystem. It just ask to
> add a 'system' DAI in kirkwood-i2s. The card is defined as:
> 
> - link 0:
> 	CPU: 'system' (kirkwood new DAI)
> 	CODEC: 'dummy'
> 	front-end
> - link 1:
> 	CPU: 'i2s' (kirkwood)
> 	CODEC: 'i2s-hdmi' (tda998x codec)
> 	back-end
> - link 2
> 	CPU: 'spdif' (kirkwood)
> 	CODEC: 'spdif-hdmi' (tda998x codec)
> 	back-end
> - link 3
> 	CPU: 'spdif' (kirkwood)
> 	CODEC: 'dit-hifi' (spdif codec)
> 	backend
> 
> with the routes (simple-card format):
> 
> 	"I2S Playback",   "System Playback",
> 	"SPDIF Playback", "System Playback",
>         
>  	"hdmi-out",     "I2S Playback",
>  	"hdmi-out",     "SPDIF Playback",
> 	"spdif-out",    "SPDIF Playback";
> 
> This works, but the HW constraints of the sinks are not handled, so,
> all backends are always activated for any format/any rate.

Not quite.  Your changes do not provide DPCM support.  What your changes
did was provide to CPU interfaces, one of which can only be used.

Here's the proper DPCM implementation (which may or may not apply),
which had post-kernel summit Mark's blessing as being the right
solution.  It's the right solution because it allows both I2S and
SPDIF to be active at one time, if you have such a setup.

From: Russell King <rmk+kernel@arm.linux.org.uk>
Subject: [PATCH] ASoC: kirkwood: add DPCM support

Add DPCM support to kirkwood-i2s to support the I2S and SPDIF streams.
This consists of:
- a single front end DAI called "kirkwood-fe" with "dma-tx" and "dma-rx"
  streams.
- one backend DAI called "kirkwood-i2s" for I2S with streams named
  "i2s-tx" and "i2s-rx"
- one backend DAI called "kirkwood-spdif" for SPDIF with a single stream
  named "spdif-tx".

DAPM widgets are used to connect the backend i2s-tx/spdif-tx streams to
the dma-tx frontend stream, and similarly for the capture side.  SPDIF
capture is not supported by this patch.

We avoid the requirement that streams must not be started independently
by keeping a separate mask of which streams are enabled - and this mask
is only used in the playback trigger when we start playback.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 sound/soc/kirkwood/kirkwood-i2s.c    | 261 +++++++++++++++++++++++------------
 sound/soc/kirkwood/kirkwood-openrd.c |  14 +-
 sound/soc/kirkwood/kirkwood-spdif.c  |  26 +++-
 sound/soc/kirkwood/kirkwood-t5325.c  |  13 +-
 sound/soc/kirkwood/kirkwood.h        |  20 +++
 5 files changed, 239 insertions(+), 95 deletions(-)

diff --git a/sound/soc/kirkwood/kirkwood-i2s.c b/sound/soc/kirkwood/kirkwood-i2s.c
index c06920364e93..0425571017e7 100644
--- a/sound/soc/kirkwood/kirkwood-i2s.c
+++ b/sound/soc/kirkwood/kirkwood-i2s.c
@@ -38,6 +38,18 @@
 	(SNDRV_PCM_FMTBIT_S16_LE | \
 	 SNDRV_PCM_FMTBIT_S24_LE)
 
+/* Workaround ASoC not respecting backend restrictions */
+#define KIRKWOOD_FE_FORMATS (KIRKWOOD_I2S_FORMATS & KIRKWOOD_SPDIF_FORMATS)
+
+enum {
+	KW_DAI_FE,
+	KW_DAI_BE_I2S,
+	KW_DAI_BE_SPDIF,
+
+	KW_DAI_BE_SPDIF_PLAYBACK = BIT(0),
+	KW_DAI_BE_SPDIF_CAPTURE = BIT(1),
+};
+
 static void kirkwood_i2s_dump_spdif(struct device *dev,
 	struct kirkwood_dma_data *priv)
 {
@@ -381,13 +393,12 @@ static int kirkwood_i2s_play_trigger(struct snd_pcm_substream *substream,
 
 	switch (cmd) {
 	case SNDRV_PCM_TRIGGER_START:
+		if (priv->ctl_play_mask == ~KIRKWOOD_PLAYCTL_ENABLE_MASK)
+			return -EINVAL;
+
 		/* configure */
-		ctl = priv->ctl_play;
-		if (dai->id == 0)
-			ctl &= ~KIRKWOOD_PLAYCTL_SPDIF_EN;	/* i2s */
-		else
-			ctl &= ~KIRKWOOD_PLAYCTL_I2S_EN;	/* spdif */
-		ctl = kirkwood_i2s_play_mute(ctl);
+		ctl = kirkwood_i2s_play_mute(priv->ctl_play &
+					     priv->ctl_play_mask);
 		value = ctl & ~KIRKWOOD_PLAYCTL_ENABLE_MASK;
 		writel(value, priv->io + KIRKWOOD_PLAYCTL);
 
@@ -452,13 +463,11 @@ static int kirkwood_i2s_rec_trigger(struct snd_pcm_substream *substream,
 
 	switch (cmd) {
 	case SNDRV_PCM_TRIGGER_START:
-		/* configure */
-		ctl = priv->ctl_rec;
-		if (dai->id == 0)
-			ctl &= ~KIRKWOOD_RECCTL_SPDIF_EN;	/* i2s */
-		else
-			ctl &= ~KIRKWOOD_RECCTL_I2S_EN;		/* spdif */
+		if (priv->ctl_rec_mask == ~KIRKWOOD_RECCTL_ENABLE_MASK)
+			return -EINVAL;
 
+		/* configure */
+		ctl = priv->ctl_rec & priv->ctl_rec_mask;
 		value = ctl & ~KIRKWOOD_RECCTL_ENABLE_MASK;
 		writel(value, priv->io + KIRKWOOD_RECCTL);
 
@@ -519,19 +528,25 @@ static int kirkwood_i2s_trigger(struct snd_pcm_substream *substream, int cmd,
 	return 0;
 }
 
-static int kirkwood_i2s_init(struct kirkwood_dma_data *priv)
+static int kirkwood_fe_probe(struct snd_soc_dai *dai)
 {
+	struct kirkwood_dma_data *priv = snd_soc_dai_get_drvdata(dai);
 	unsigned long value;
 	unsigned int reg_data;
-	int ret;
 
-	ret = snd_soc_add_dai_controls(dai, kirkwood_i2s_iec958_controls,
+	if (priv->have_spdif) {
+		int ret;
+
+		ret = snd_soc_add_dai_controls(dai,
+				kirkwood_i2s_iec958_controls,
 				ARRAY_SIZE(kirkwood_i2s_iec958_controls));
-	if (ret) {
-		dev_err(dai->dev,
-			"unable to add soc card controls: %d\n", ret);
-		return ret;
+		if (ret) {
+			dev_err(dai->dev,
+				"unable to add soc card controls: %d\n", ret);
+			return ret;
+		}
 	}
+
 	/* put system in a "safe" state : */
 	/* disable audio interrupts */
 	writel(0xffffffff, priv->io + KIRKWOOD_INT_CAUSE);
@@ -564,97 +579,134 @@ static int kirkwood_i2s_init(struct kirkwood_dma_data *priv)
 
 }
 
-static const struct snd_soc_dai_ops kirkwood_i2s_dai_ops = {
+static const struct snd_soc_dai_ops kirkwood_dai_fe_ops = {
 	.startup	= kirkwood_i2s_startup,
 	.trigger	= kirkwood_i2s_trigger,
 	.hw_params      = kirkwood_i2s_hw_params,
 	.set_fmt        = kirkwood_i2s_set_fmt,
 };
 
-static struct snd_soc_dai_driver kirkwood_i2s_dai[2] = {
-    {
-	.name = "i2s",
-	.id = 0,
-	.playback = {
-		.channels_min = 1,
-		.channels_max = 2,
-		.rates = SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 |
-				SNDRV_PCM_RATE_96000,
-		.formats = KIRKWOOD_I2S_FORMATS,
-	},
-	.capture = {
-		.channels_min = 1,
-		.channels_max = 2,
-		.rates = SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 |
-				SNDRV_PCM_RATE_96000,
-		.formats = KIRKWOOD_I2S_FORMATS,
-	},
-	.ops = &kirkwood_i2s_dai_ops,
-    },
-    {
-	.name = "spdif",
-	.id = 1,
+static int kirkwood_i2s_be_startup(struct snd_pcm_substream *substream,
+	struct snd_soc_dai *dai)
+{
+	struct kirkwood_dma_data *priv = snd_soc_dai_get_drvdata(dai);
+
+	switch (dai->id) {
+	case KW_DAI_BE_I2S:
+		priv->ctl_play_mask |= KIRKWOOD_PLAYCTL_I2S_EN;
+		priv->ctl_rec_mask |= KIRKWOOD_RECCTL_I2S_EN;
+		break;
+
+	case KW_DAI_BE_SPDIF:
+		priv->ctl_play_mask |= KIRKWOOD_PLAYCTL_SPDIF_EN;
+		priv->ctl_rec_mask |= KIRKWOOD_RECCTL_SPDIF_EN;
+		break;
+
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static void kirkwood_i2s_be_shutdown(struct snd_pcm_substream *substream,
+	struct snd_soc_dai *dai)
+{
+	struct kirkwood_dma_data *priv = snd_soc_dai_get_drvdata(dai);
+
+	switch (dai->id) {
+	case KW_DAI_BE_I2S:
+		priv->ctl_play_mask &= ~KIRKWOOD_PLAYCTL_I2S_EN;
+		priv->ctl_rec_mask &= ~KIRKWOOD_RECCTL_I2S_EN;
+		break;
+
+	case KW_DAI_BE_SPDIF:
+		priv->ctl_play_mask &= ~KIRKWOOD_PLAYCTL_SPDIF_EN;
+		priv->ctl_rec_mask &= ~KIRKWOOD_RECCTL_SPDIF_EN;
+		break;
+	}
+}
+
+static const struct snd_soc_dai_ops kirkwood_i2s_be_dai_ops = {
+	.startup	= kirkwood_i2s_be_startup,
+	.shutdown	= kirkwood_i2s_be_shutdown,
+};
+
+
+static const struct snd_soc_dai_driver kirkwood_dai_fe = {
+	.name = "kirkwood-fe",
+	.id = KW_DAI_FE,
+	.probe = kirkwood_fe_probe,
 	.playback = {
+		.stream_name = "dma-tx",
 		.channels_min = 1,
 		.channels_max = 2,
 		.rates = SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 |
 				SNDRV_PCM_RATE_96000,
-		.formats = KIRKWOOD_SPDIF_FORMATS,
+		.formats = KIRKWOOD_FE_FORMATS,
 	},
 	.capture = {
+		.stream_name = "dma-rx",
 		.channels_min = 1,
 		.channels_max = 2,
 		.rates = SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 |
 				SNDRV_PCM_RATE_96000,
-		.formats = KIRKWOOD_SPDIF_FORMATS,
+		.formats = KIRKWOOD_FE_FORMATS,
 	},
-	.ops = &kirkwood_i2s_dai_ops,
-    },
+	.ops = &kirkwood_dai_fe_ops,
 };
 
-static struct snd_soc_dai_driver kirkwood_i2s_dai_extclk[2] = {
-    {
-	.name = "i2s",
-	.id = 0,
+static const struct snd_soc_dai_driver kirkwood_dai_fe_extclk = {
+	.name = "kirkwood-fe",
+	.id = KW_DAI_FE,
+	.probe = kirkwood_fe_probe,
 	.playback = {
+		.stream_name = "dma-tx",
 		.channels_min = 1,
 		.channels_max = 2,
-		.rates = SNDRV_PCM_RATE_CONTINUOUS,
-		.rate_min = 5512,
-		.rate_max = 192000,
-		.formats = KIRKWOOD_I2S_FORMATS,
+		.rates = SNDRV_PCM_RATE_8000_192000 |
+			 SNDRV_PCM_RATE_CONTINUOUS |
+			 SNDRV_PCM_RATE_KNOT,
+		.formats = KIRKWOOD_FE_FORMATS,
 	},
 	.capture = {
+		.stream_name = "dma-rx",
 		.channels_min = 1,
 		.channels_max = 2,
-		.rates = SNDRV_PCM_RATE_CONTINUOUS,
-		.rate_min = 5512,
-		.rate_max = 192000,
-		.formats = KIRKWOOD_I2S_FORMATS,
-	},
-	.ops = &kirkwood_i2s_dai_ops,
-    },
-    {
-	.name = "spdif",
-	.id = 1,
-	.playback = {
-		.channels_min = 1,
-		.channels_max = 2,
-		.rates = SNDRV_PCM_RATE_CONTINUOUS,
-		.rate_min = 5512,
-		.rate_max = 192000,
-		.formats = KIRKWOOD_SPDIF_FORMATS,
+		.rates = SNDRV_PCM_RATE_8000_192000 |
+			 SNDRV_PCM_RATE_CONTINUOUS |
+			 SNDRV_PCM_RATE_KNOT,
+		.formats = KIRKWOOD_FE_FORMATS,
 	},
-	.capture = {
-		.channels_min = 1,
-		.channels_max = 2,
-		.rates = SNDRV_PCM_RATE_CONTINUOUS,
-		.rate_min = 5512,
-		.rate_max = 192000,
-		.formats = KIRKWOOD_SPDIF_FORMATS,
+	.ops = &kirkwood_dai_fe_ops,
+};
+
+static const struct snd_soc_dai_driver kirkwood_dai_be[] = {
+	{
+		.name = "kirkwood-i2s",
+		.id = KW_DAI_BE_I2S,
+		.ops = &kirkwood_i2s_be_dai_ops,
+		.playback = {
+			.stream_name = "i2s-tx",
+			.formats = KIRKWOOD_I2S_FORMATS,
+		},
+		.capture = {
+			.stream_name = "i2s-rx",
+			.formats = KIRKWOOD_I2S_FORMATS,
+		},
+	}, {
+		.name = "kirkwood-spdif",
+		.id = KW_DAI_BE_SPDIF,
+		.ops = &kirkwood_i2s_be_dai_ops,
+		.playback = {
+			.stream_name = "spdif-tx",
+			.formats = KIRKWOOD_SPDIF_FORMATS,
+		},
+		.capture = {
+			.stream_name = "spdif-rx",
+			.formats = KIRKWOOD_SPDIF_FORMATS,
+		},
 	},
-	.ops = &kirkwood_i2s_dai_ops,
-    },
 };
 
 static const struct snd_soc_component_driver kirkwood_i2s_component = {
@@ -664,10 +716,12 @@ static const struct snd_soc_component_driver kirkwood_i2s_component = {
 static int kirkwood_i2s_dev_probe(struct platform_device *pdev)
 {
 	struct kirkwood_asoc_platform_data *data = pdev->dev.platform_data;
-	struct snd_soc_dai_driver *soc_dai = kirkwood_i2s_dai;
+	const struct snd_soc_dai_driver *soc_dai = &kirkwood_dai_fe;
+	struct snd_soc_dai_driver *dai;
 	struct kirkwood_dma_data *priv;
 	struct resource *mem;
 	struct device_node *np = pdev->dev.of_node;
+	unsigned i;
 	int err;
 
 	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
@@ -688,6 +742,13 @@ static int kirkwood_i2s_dev_probe(struct platform_device *pdev)
 		return -ENXIO;
 	}
 
+	/*
+	 * We currently have no way to determine whether SPDIF playback
+	 * or capture is currently supported; take the middle ground
+	 * for the time being until DT/platform data passes this detail.
+	 */
+	priv->have_spdif = KW_DAI_BE_SPDIF_PLAYBACK;
+
 	if (np) {
 		priv->burst = 128;		/* might be 32 or 128 */
 	} else if (data) {
@@ -718,13 +779,15 @@ static int kirkwood_i2s_dev_probe(struct platform_device *pdev)
 		} else {
 			dev_info(&pdev->dev, "found external clock\n");
 			clk_prepare_enable(priv->extclk);
-			soc_dai = kirkwood_i2s_dai_extclk;
+			soc_dai = &kirkwood_dai_fe_extclk;
 		}
 	}
 
 	/* Some sensible defaults - this reflects the powerup values */
 	priv->ctl_play = KIRKWOOD_PLAYCTL_SIZE_24;
 	priv->ctl_rec = KIRKWOOD_RECCTL_SIZE_24;
+	priv->ctl_play_mask = ~KIRKWOOD_PLAYCTL_ENABLE_MASK;
+	priv->ctl_rec_mask = ~KIRKWOOD_RECCTL_ENABLE_MASK;
 
 	/* Select the burst size */
 	if (priv->burst == 32) {
@@ -738,8 +801,35 @@ static int kirkwood_i2s_dev_probe(struct platform_device *pdev)
 	writel(KIRKWOOD_MCLK_SOURCE_DCO, 
 	       priv->io+KIRKWOOD_CLOCKS_CTRL);
 
+	dai = priv->dai_driver;
+	memcpy(dai, soc_dai, sizeof(*dai));
+
+	/* Copy the frontend channels and rates to the backends */
+	for (i = 1; i < ARRAY_SIZE(priv->dai_driver); i++) {
+		memcpy(&dai[i], &kirkwood_dai_be[i - 1], sizeof(*dai));
+		dai[i].playback.channels_min = dai[0].playback.channels_min;
+		dai[i].playback.channels_max = dai[0].playback.channels_max;
+		dai[i].playback.rates        = dai[0].playback.rates;
+		dai[i].playback.rate_min     = dai[0].playback.rate_min;
+		dai[i].playback.rate_max     = dai[0].playback.rate_max;
+		dai[i].capture.channels_min  = dai[0].capture.channels_min;
+		dai[i].capture.channels_max  = dai[0].capture.channels_max;
+		dai[i].capture.rates         = dai[0].capture.rates;
+		dai[i].capture.rate_min      = dai[0].capture.rate_min;
+		dai[i].capture.rate_max      = dai[0].capture.rate_max;
+	}
+
+	/*
+	 * Kill the SPDIF stream information according to
+	 * the capabilities we have on this device.
+	 */
+	if (!(priv->have_spdif & KW_DAI_BE_SPDIF_PLAYBACK))
+		memset(&dai[2].playback, 0, sizeof(dai[2].playback));
+	if (!(priv->have_spdif & KW_DAI_BE_SPDIF_CAPTURE))
+		memset(&dai[2].capture, 0, sizeof(dai[2].capture));
+
 	err = snd_soc_register_component(&pdev->dev, &kirkwood_i2s_component,
-					 soc_dai, 2);
+					 dai, 2 + !!priv->have_spdif);
 	if (err) {
 		dev_err(&pdev->dev, "snd_soc_register_component failed\n");
 		goto err_component;
@@ -751,9 +841,8 @@ static int kirkwood_i2s_dev_probe(struct platform_device *pdev)
 		goto err_platform;
 	}
 
-	kirkwood_i2s_init(priv);
-
 	return 0;
+
  err_platform:
 	snd_soc_unregister_component(&pdev->dev);
  err_component:
diff --git a/sound/soc/kirkwood/kirkwood-openrd.c b/sound/soc/kirkwood/kirkwood-openrd.c
index 65f2a5b9ec3b..78fb05ff44a8 100644
--- a/sound/soc/kirkwood/kirkwood-openrd.c
+++ b/sound/soc/kirkwood/kirkwood-openrd.c
@@ -49,24 +49,34 @@ static struct snd_soc_ops openrd_client_ops = {
 
 
 static struct snd_soc_dai_link openrd_client_dai[] = {
+	KIRKWOOD_FE_DAI_LINK(".0", 1, 1),
 {
 	.name = "CS42L51",
 	.stream_name = "CS42L51 HiFi",
-	.cpu_dai_name = "i2s",
-	.platform_name = "mvebu-audio",
+	.cpu_name = "mvebu-audio.0",
+	.cpu_dai_name = "kirkwood-i2s",
+	.platform_name = "snd-soc-dummy",
 	.codec_dai_name = "cs42l51-hifi",
 	.codec_name = "cs42l51-codec.0-004a",
 	.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_CBS_CFS,
 	.ops = &openrd_client_ops,
+	.dpcm_playback = 1,
+	.dpcm_capture = 1,
 },
 };
 
+static const struct snd_soc_dapm_route openrd_route[] = {
+	{ "i2s-tx",		NULL,	"dma-tx" },
+	{ "dma-rx",		NULL,	"i2s-rx" },
+};
 
 static struct snd_soc_card openrd_client = {
 	.name = "OpenRD Client",
 	.owner = THIS_MODULE,
 	.dai_link = openrd_client_dai,
 	.num_links = ARRAY_SIZE(openrd_client_dai),
+	.dapm_routes = openrd_route,
+	.num_dapm_routes = ARRAY_SIZE(openrd_route),
 };
 
 static int openrd_probe(struct platform_device *pdev)
diff --git a/sound/soc/kirkwood/kirkwood-spdif.c b/sound/soc/kirkwood/kirkwood-spdif.c
index 9d49bc53f07d..6098dde85fc9 100644
--- a/sound/soc/kirkwood/kirkwood-spdif.c
+++ b/sound/soc/kirkwood/kirkwood-spdif.c
@@ -20,25 +20,39 @@
 #include <sound/pcm.h>
 #include <sound/soc.h>
 
+#include "kirkwood.h"
+
+static const struct snd_soc_dapm_route routes[] = {
+	{ "spdif-tx", NULL, "dma-tx" },
+};
+
 static struct snd_soc_dai_link kirkwood_spdif_dai0[] = {
+	KIRKWOOD_FE_DAI_LINK(".0", 1, 0),
 	{
 		.name = "S/PDIF0",
 		.stream_name = "S/PDIF0 PCM Playback",
-		.platform_name = "mvebu-audio.0",
-		.cpu_dai_name = "mvebu-audio.0",
+		.cpu_name = "mvebu-audio.0",
+		.platform_name = "snd-soc-dummy",
+		.cpu_dai_name = "kirkwood-spdif",
 		.codec_dai_name = "dit-hifi",
 		.codec_name = "spdif-dit",
+		.no_pcm = 1,
+		.dpcm_playback = 1,
 	},
 };
 
 static struct snd_soc_dai_link kirkwood_spdif_dai1[] = {
+	KIRKWOOD_FE_DAI_LINK(".1", 1, 0),
 	{
 		.name = "S/PDIF1",
 		.stream_name = "IEC958 Playback",
-		.platform_name = "mvebu-audio.1",
-		.cpu_dai_name = "mvebu-audio.1",
+		.cpu_name = "mvebu-audio.1",
+		.platform_name = "snd-soc-dummy",
+		.cpu_dai_name = "kirkwood-spdif",
 		.codec_dai_name = "dit-hifi",
 		.codec_name = "spdif-dit",
+		.no_pcm = 1,
+		.dpcm_playback = 1,
 	},
 };
 
@@ -66,7 +80,9 @@ static int kirkwood_spdif_probe(struct platform_device *pdev)
 		card->dai_link = kirkwood_spdif_dai0;
 	else
 		card->dai_link = kirkwood_spdif_dai1;
-	card->num_links = 1;
+	card->num_links = 2;
+	card->dapm_routes = routes;
+	card->num_dapm_routes = ARRAY_SIZE(routes);
 	card->dev = &pdev->dev;
 
 	ret = snd_soc_register_card(card);
diff --git a/sound/soc/kirkwood/kirkwood-t5325.c b/sound/soc/kirkwood/kirkwood-t5325.c
index d213832b0c72..5c0ea0d12a6c 100644
--- a/sound/soc/kirkwood/kirkwood-t5325.c
+++ b/sound/soc/kirkwood/kirkwood-t5325.c
@@ -18,6 +18,8 @@
 #include <linux/platform_data/asoc-kirkwood.h>
 #include "../codecs/alc5623.h"
 
+#include "kirkwood.h"
+
 static int t5325_hw_params(struct snd_pcm_substream *substream,
 		struct snd_pcm_hw_params *params)
 {
@@ -50,6 +52,9 @@ static const struct snd_soc_dapm_route t5325_route[] = {
 
 	{ "MIC1",		NULL,	"Mic Jack" },
 	{ "MIC2",		NULL,	"Mic Jack" },
+
+	{ "i2s-tx",		NULL,	"dma-tx" },
+	{ "dma-rx",		NULL,	"i2s-rx" },
 };
 
 static int t5325_dai_init(struct snd_soc_pcm_runtime *rtd)
@@ -65,16 +70,20 @@ static int t5325_dai_init(struct snd_soc_pcm_runtime *rtd)
 }
 
 static struct snd_soc_dai_link t5325_dai[] = {
+	KIRKWOOD_FE_DAI_LINK(".0", 1, 1),
 {
 	.name = "ALC5621",
 	.stream_name = "ALC5621 HiFi",
-	.cpu_dai_name = "i2s",
-	.platform_name = "mvebu-audio",
+	.cpu_name = "mvebu-audio.0",
+	.cpu_dai_name = "kirkwood-i2s",
+	.platform_name = "snd-soc-dummy",
 	.codec_dai_name = "alc5621-hifi",
 	.codec_name = "alc562x-codec.0-001a",
 	.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_CBS_CFS,
 	.ops = &t5325_ops,
 	.init = t5325_dai_init,
+	.dpcm_playback = 1,
+	.dpcm_capture = 1,
 },
 };
 
diff --git a/sound/soc/kirkwood/kirkwood.h b/sound/soc/kirkwood/kirkwood.h
index 2404de0963d4..8afe7190eaea 100644
--- a/sound/soc/kirkwood/kirkwood.h
+++ b/sound/soc/kirkwood/kirkwood.h
@@ -141,12 +141,19 @@
 #define KIRKWOOD_SND_MAX_PERIOD_BYTES		0x800000
 #define KIRKWOOD_SND_MAX_BUFFER_BYTES		0x100000
 
+#define KIRKWOOD_NUM_DAIS 3
+
 struct kirkwood_dma_data {
 	void __iomem *io;
 	struct clk *clk;
 	struct clk *extclk;
+	unsigned have_spdif;
+	uint32_t ctl_play_mask;
 	uint32_t ctl_play;
+	uint32_t ctl_rec_mask;
 	uint32_t ctl_rec;
+	struct snd_soc_dai *active_dai;
+	struct snd_soc_dai_driver dai_driver[KIRKWOOD_NUM_DAIS];
 	struct snd_pcm_substream *substream_play;
 	struct snd_pcm_substream *substream_rec;
 	int irq;
@@ -155,4 +162,17 @@ struct kirkwood_dma_data {
 
 extern struct snd_soc_platform_driver kirkwood_soc_platform;
 
+#define KIRKWOOD_FE_DAI_LINK(id, play, capt) {	\
+	.name = "Kirkwood-FE",			\
+	.stream_name = "FE PCM Playback",	\
+	.cpu_name = "mvebu-audio" id,		\
+	.cpu_dai_name = "kirkwood-fe",		\
+	.codec_name = "snd-soc-dummy",		\
+	.codec_dai_name = "snd-soc-dummy-dai",	\
+	.platform_name = "mvebu-audio" id,	\
+	.dynamic = 1,				\
+	.dpcm_capture = capt,			\
+	.dpcm_playback = play,			\
+}
+
 #endif
-- 
1.8.3.1

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Re: [PATCH 00/13] Remove mach-kirkwood and mach-dove

[Russell King - ARM Linux]

On Mon, Jun 30, 2014 at 05:35:49PM +0200, Sebastian Hesselbarth wrote:
> On 06/30/2014 04:25 PM, Russell King - ARM Linux wrote:
>> Nothing has changed on the PMU patches since I posted them, because
>> they're based on 3.15 and there's been no changes there.
>
> I offered to deal with mainlining them end of April, you never replied.
> I know that if you dislike something you answer, but it is hard to tell
> if silence means agreement.
>
> I am not going to waste any time preparing patches just to get a NAK.

That's because I am quite prepared to work on them _if_ there is a way
forward.  You've already said that changing things like hwmon and rtc
is a work in progress to convert them to regmap.  That's great, but
in order to progress these myself, I need *visibility* of that work,
and there is zero visibility of that.

>> As for the ASoC stuff which you avoided commenting on, let me repeat
>> that _that_ stuff is now totally dead and can /never/ be merged into
>> mainline without breaking the existing ASoC kirkwood support.  In
>> that case, it's not like I wasn't sending the patches out, because
>> I had been... so everyone was aware of what was going on there,
>> but I guess converting stuff to DT in ways that totally fuck over
>> other patches is what now happens in the kernel.
>
> If you are talking about "Kirkwood ASoC updates", you got a Tested-by
> from Andrew even before I read your patches. And besides, just because
> I am interested in Dove does not mean I just swallowed the whole Linux
> API knowledge. I simply avoided commenting on it, because there is
> /nothing/ I can add to it.

No I am not - and those are the patches which I referred to as having
been already taken by Mark into his tree.  The patch I'm referring to
which can never be merged now is the one which I replied to Jean
Francois just now - and if you read through it, you'll understand
why - that's because it /totally/ breaks the simple DT bindings that
are now established - independently - for Kirkwood stuff.

>> What I think you're missing is that for those of us who want to have
>> a platform fully supported, the choice has been non-DT until relatively
>> recently.  We're now at the point where the DT support on Dove has
>> matured to the point where it's relatively easy to end up with a fully
>> functional (but not necessarily bug free) setup with DT.  It's at the
>> sweet spot where you can switch between DT and non-DT and preserve
>> that functionality... but as soon as we get there we want to rip out
>> the old stuff.
>
> Oh, ok.. you think it is "me" and "us"? It is you who actually want to
> use Dove and me just wanting a DT representation for it?
>
> It is not my fault that your patches are blocked by others. I can offer
> help to track down the issue, but I am not going to be your scapegoat.

Right, and removing the non-DT support and screwing people like me
who have out of tree patches is good for MVEBU development because...
(complete the sentence with a damned good reason.)

>> What I'm trying to get you to understand is that leaving the old stuff
>> behind for a little while longer is beneficial - while those who have
>> been running crippled DT based setups for the last year don't care
>> about having full support, there are those who do.
>
> Ok, let's have mach-dove for a little longer, fine with me.

Great, that's all I ask.  I'm trying as fast as I can to push stuff
out - I'm not being anywhere close to idle about it - but it takes time
to deal with the updates from each merge window and such like, work out
what has been accepted, which patches need to be revised, and do all the
testing that's necessary before trying to get some more out.  Oh, and
port some more of the patches over to be mainline-based.

I would've preferred to be clear of the ASoC stuff 12 months ago, and
we all know why that was a big problem.

> What I really want is to stop that blackmailing with giving up on
> sending patches. It will be a huge loss if you do and many have said
> that in the past.

It's not blackmail.  It's reality.  If the kernel becomes too much
hassle to deal with, then volunteers will walk away from it - that's
almost a fact of life.

Even with DT support, I'm nowhere near being "DT clean" on the Cubox -
I need this as a minimum to do "special" stuff there:

#include <linux/of_platform.h>
#include <asm/hardware/cache-tauros2.h>
#include "clock.h"

static struct resource armada_drm_resources[] = {
        DEFINE_RES_MEM(0, 0),
};

static const char *armada_drm_devices[4];

static const struct platform_device_info armada_drm_dev_info __initconst = {
        .name = "armada-drm",
        .id = -1,
        .res = armada_drm_resources,
        .num_res = ARRAY_SIZE(armada_drm_resources),
        .data = armada_drm_devices,
        .size_data = sizeof(armada_drm_devices),
};

static struct platform_device cubox_spdif = {
        .name   = "kirkwood-spdif-audio",
        .id     = 1,
};

static const struct platform_device_info cubox_spdif_dit __initconst = {
        .name = "spdif-dit",
        .id = -1,
};

static void __init cubox_reserve(void)
{
        phys_addr_t phys;

        dove_reserve();

        /* Steal 32MB for the drm framebuffers */
        phys = arm_memblock_steal(SZ_32M, SZ_2M);
        armada_drm_resources[0].start = phys;
        armada_drm_resources[0].end = phys + SZ_32M - 1;
}

static void __init cubox_dt_init(void)
{
        struct device_node *node;
        struct platform_device *pdev;
        int i;

        pr_info("Dove 88AP510 SoC\n");

#ifdef CONFIG_CACHE_TAUROS2
        tauros2_init(0);
#endif
        dove_init_pmu();

        BUG_ON(mvebu_mbus_dt_init());
        of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);

        dove_devclks_init();
        dove_gpu_init();
        dove_bmm_init();

        for (i = 0, node = NULL; (node = of_find_compatible_node(node, NULL, "marvell,dove-lcd")) != NULL; ) {
                if (!of_device_is_available(node))
                        continue;
                pdev = of_find_device_by_node(node);
                if (pdev)
                        armada_drm_devices[i++] = dev_name(&pdev->dev);
        }
        armada_drm_devices[i++] = NULL;
        platform_device_register_full(&armada_drm_dev_info);

        platform_device_register_full(&cubox_spdif_dit);
        platform_device_register(&cubox_spdif);
}

static const char * const cubox_dt_compat[] = {
        "solidrun,cubox",
        NULL
};

DT_MACHINE_START(DOVE_DT, "Marvell Dove (Cubox)")
        .dt_compat      = cubox_dt_compat,
        .reserve        = cubox_reserve,
        .map_io         = dove_map_io,
        .init_machine   = cubox_dt_init,
        .restart        = dove_restart,
};


-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Re: [PATCH 08/13] leds: Replace ARCH_KIRKWOOD dependency

[Bryan Wu]

On Sun, Jun 29, 2014 at 1:59 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> mach-kirkwood has been removed, now that kirkwood SoC lives in
> mach-mvebu. Use MACH_KIRKWOOD which will be set when kirkwood is built
> as part of mach-mvebu.
>

Looks good to me. You can take my Ack and merge it with other patches.

Acked-by: Bryan Wu <cooloney@gmail.com>

> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> Cc: Bryan Wu <cooloney@gmail.com>
> Cc: Richard Purdie <rpurdie@rpsys.net>
> Cc: linux-leds@vger.kernel.org
> ---
>  drivers/leds/Kconfig | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index a1b044e7eaad..2d7c380f79ce 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -411,7 +411,7 @@ config LEDS_MC13783
>  config LEDS_NS2
>         tristate "LED support for Network Space v2 GPIO LEDs"
>         depends on LEDS_CLASS
> -       depends on ARCH_KIRKWOOD || MACH_KIRKWOOD
> +       depends on MACH_KIRKWOOD
>         default y
>         help
>           This option enable support for the dual-GPIO LED found on the
> @@ -421,7 +421,7 @@ config LEDS_NS2
>  config LEDS_NETXBIG
>         tristate "LED support for Big Network series LEDs"
>         depends on LEDS_CLASS
> -       depends on ARCH_KIRKWOOD || MACH_KIRKWOOD
> +       depends on MACH_KIRKWOOD
>         default y
>         help
>           This option enable support for LEDs found on the LaCie 2Big
> --
> 2.0.0
>

Re: [PATCH 00/13] Remove mach-kirkwood and mach-dove

[Sebastian Hesselbarth]

On 06/30/2014 06:56 PM, Russell King - ARM Linux wrote:
> On Mon, Jun 30, 2014 at 05:35:49PM +0200, Sebastian Hesselbarth wrote:
>> On 06/30/2014 04:25 PM, Russell King - ARM Linux wrote:
>>> Nothing has changed on the PMU patches since I posted them, because
>>> they're based on 3.15 and there's been no changes there.
>>
>> I offered to deal with mainlining them end of April, you never replied.
>> I know that if you dislike something you answer, but it is hard to tell
>> if silence means agreement.
>>
>> I am not going to waste any time preparing patches just to get a NAK.
> 
> That's because I am quite prepared to work on them _if_ there is a way
> forward.  You've already said that changing things like hwmon and rtc
> is a work in progress to convert them to regmap.  That's great, but
> in order to progress these myself, I need *visibility* of that work,
> and there is zero visibility of that.

So, we are on the same boat. For the HDMI issue, I also need visibility
to add any more ideas how to deal with it. Just provide me the binaries,
I see if I can at least reproduce the issue.

>>> As for the ASoC stuff which you avoided commenting on, let me repeat
>>> that _that_ stuff is now totally dead and can /never/ be merged into
>>> mainline without breaking the existing ASoC kirkwood support.  In
>>> that case, it's not like I wasn't sending the patches out, because
>>> I had been... so everyone was aware of what was going on there,
>>> but I guess converting stuff to DT in ways that totally fuck over
>>> other patches is what now happens in the kernel.
>>
>> If you are talking about "Kirkwood ASoC updates", you got a Tested-by
>> from Andrew even before I read your patches. And besides, just because
>> I am interested in Dove does not mean I just swallowed the whole Linux
>> API knowledge. I simply avoided commenting on it, because there is
>> /nothing/ I can add to it.
> 
> No I am not - and those are the patches which I referred to as having
> been already taken by Mark into his tree.  The patch I'm referring to
> which can never be merged now is the one which I replied to Jean
> Francois just now - and if you read through it, you'll understand
> why - that's because it /totally/ breaks the simple DT bindings that
> are now established - independently - for Kirkwood stuff.

And I stopped discussing the pros and cons of the simple DT binding
as soon as I realized that my comments had no impact on the way it
will be implemented. I am not responsible for the binding.

>>> What I think you're missing is that for those of us who want to have
>>> a platform fully supported, the choice has been non-DT until relatively
>>> recently.  We're now at the point where the DT support on Dove has
>>> matured to the point where it's relatively easy to end up with a fully
>>> functional (but not necessarily bug free) setup with DT.  It's at the
>>> sweet spot where you can switch between DT and non-DT and preserve
>>> that functionality... but as soon as we get there we want to rip out
>>> the old stuff.
>>
>> Oh, ok.. you think it is "me" and "us"? It is you who actually want to
>> use Dove and me just wanting a DT representation for it?
>>
>> It is not my fault that your patches are blocked by others. I can offer
>> help to track down the issue, but I am not going to be your scapegoat.
> 
> Right, and removing the non-DT support and screwing people like me
> who have out of tree patches is good for MVEBU development because...
> (complete the sentence with a damned good reason.)

...ranting at people not jumping into review and testing is.

>>> What I'm trying to get you to understand is that leaving the old stuff
>>> behind for a little while longer is beneficial - while those who have
>>> been running crippled DT based setups for the last year don't care
>>> about having full support, there are those who do.
>>
>> Ok, let's have mach-dove for a little longer, fine with me.
> 
> Great, that's all I ask.  I'm trying as fast as I can to push stuff
> out - I'm not being anywhere close to idle about it - but it takes time
> to deal with the updates from each merge window and such like, work out
> what has been accepted, which patches need to be revised, and do all the
> testing that's necessary before trying to get some more out.  Oh, and
> port some more of the patches over to be mainline-based.

> I would've preferred to be clear of the ASoC stuff 12 months ago, and
> we all know why that was a big problem.

>> What I really want is to stop that blackmailing with giving up on
>> sending patches. It will be a huge loss if you do and many have said
>> that in the past.
> 
> It's not blackmail.  It's reality.  If the kernel becomes too much
> hassle to deal with, then volunteers will walk away from it - that's
> almost a fact of life.

Right. And since I am one of those volunteers, I can tell you that
some specific attitude in dealing with people is definitely reducing
the willingness to stick with it.

I constantly offered to spend my spare time for hunting the issue
but only received ranting.

> Even with DT support, I'm nowhere near being "DT clean" on the Cubox -
> I need this as a minimum to do "special" stuff there:

Sure, nobody said that DT is feature complete. But you'd have to do
the same on mainline non-DT dove as there has never been support for
the cubox.

If it helps us tracking down the HDMI issue, we can have below setup
for DT dove and get rid of it incrementally.

I am sure, Andrew can drop removing mach-dove removal from the patches
and we can continue improving Dove mainline.

Sebastian

> #include <linux/of_platform.h>
> #include <asm/hardware/cache-tauros2.h>
> #include "clock.h"
> 
> static struct resource armada_drm_resources[] = {
>         DEFINE_RES_MEM(0, 0),
> };
> 
> static const char *armada_drm_devices[4];
> 
> static const struct platform_device_info armada_drm_dev_info __initconst = {
>         .name = "armada-drm",
>         .id = -1,
>         .res = armada_drm_resources,
>         .num_res = ARRAY_SIZE(armada_drm_resources),
>         .data = armada_drm_devices,
>         .size_data = sizeof(armada_drm_devices),
> };
> 
> static struct platform_device cubox_spdif = {
>         .name   = "kirkwood-spdif-audio",
>         .id     = 1,
> };
> 
> static const struct platform_device_info cubox_spdif_dit __initconst = {
>         .name = "spdif-dit",
>         .id = -1,
> };
> 
> static void __init cubox_reserve(void)
> {
>         phys_addr_t phys;
> 
>         dove_reserve();
> 
>         /* Steal 32MB for the drm framebuffers */
>         phys = arm_memblock_steal(SZ_32M, SZ_2M);
>         armada_drm_resources[0].start = phys;
>         armada_drm_resources[0].end = phys + SZ_32M - 1;
> }
> 
> static void __init cubox_dt_init(void)
> {
>         struct device_node *node;
>         struct platform_device *pdev;
>         int i;
> 
>         pr_info("Dove 88AP510 SoC\n");
> 
> #ifdef CONFIG_CACHE_TAUROS2
>         tauros2_init(0);
> #endif
>         dove_init_pmu();
> 
>         BUG_ON(mvebu_mbus_dt_init());
>         of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> 
>         dove_devclks_init();
>         dove_gpu_init();
>         dove_bmm_init();
> 
>         for (i = 0, node = NULL; (node = of_find_compatible_node(node, NULL, "marvell,dove-lcd")) != NULL; ) {
>                 if (!of_device_is_available(node))
>                         continue;
>                 pdev = of_find_device_by_node(node);
>                 if (pdev)
>                         armada_drm_devices[i++] = dev_name(&pdev->dev);
>         }
>         armada_drm_devices[i++] = NULL;
>         platform_device_register_full(&armada_drm_dev_info);
> 
>         platform_device_register_full(&cubox_spdif_dit);
>         platform_device_register(&cubox_spdif);
> }
> 
> static const char * const cubox_dt_compat[] = {
>         "solidrun,cubox",
>         NULL
> };
> 
> DT_MACHINE_START(DOVE_DT, "Marvell Dove (Cubox)")
>         .dt_compat      = cubox_dt_compat,
>         .reserve        = cubox_reserve,
>         .map_io         = dove_map_io,
>         .init_machine   = cubox_dt_init,
>         .restart        = dove_restart,
> };
> 
> 

Re: [PATCH 00/13] Remove mach-kirkwood and mach-dove

[Andrew Lunn]

> > If you are talking about "Kirkwood ASoC updates", you got a Tested-by
> > from Andrew even before I read your patches. And besides, just because
> > I am interested in Dove does not mean I just swallowed the whole Linux
> > API knowledge. I simply avoided commenting on it, because there is
> > /nothing/ I can add to it.
> 
> No I am not - and those are the patches which I referred to as having
> been already taken by Mark into his tree.  The patch I'm referring to
> which can never be merged now is the one which I replied to Jean
> Francois just now - and if you read through it, you'll understand
> why - that's because it /totally/ breaks the simple DT bindings that
> are now established - independently - for Kirkwood stuff.

Hi Russell

Are you referring to http://www.spinics.net/lists/arm-kernel/msg328068.html

    Andrew

Re: [PATCH 00/13] Remove mach-kirkwood and mach-dove

[Russell King - ARM Linux]

On Mon, Jun 30, 2014 at 07:43:51PM +0200, Andrew Lunn wrote:
> > > If you are talking about "Kirkwood ASoC updates", you got a Tested-by
> > > from Andrew even before I read your patches. And besides, just because
> > > I am interested in Dove does not mean I just swallowed the whole Linux
> > > API knowledge. I simply avoided commenting on it, because there is
> > > /nothing/ I can add to it.
> > 
> > No I am not - and those are the patches which I referred to as having
> > been already taken by Mark into his tree.  The patch I'm referring to
> > which can never be merged now is the one which I replied to Jean
> > Francois just now - and if you read through it, you'll understand
> > why - that's because it /totally/ breaks the simple DT bindings that
> > are now established - independently - for Kirkwood stuff.
> 
> Hi Russell
> 
> Are you referring to http://www.spinics.net/lists/arm-kernel/msg328068.html

I'm referring to the _entire_ addition of DT support for the sound stuff
on mvebu.

The timeline from my point of view started around March/April 2013, which
is where I was told that the kirkwood stuff should be converted to DPCM
in order to allow the SPDIF output to be used.  The documentation and
hints how to use it fell way short of what was required - and moreover,
the ASoC code to support this feature was missing several patches that
Liam had (and was freezing on to, eventually sending them after last
year's kernel summit.)

However, eventually it got sorted through face to face discussions with
Mark and Liam at kernel summit, but not before Jean-Francois patches
had been merged.  My solution was developed and tested without Jean's
patches in place.

While I was sorting out the fallout from that, the patches to convert
kirkwood to use the simple-card stuff were merged.  At this point, I
basically decided that was the end of nine months of effort to get SPDIF
with DPCM properly supported, and earlier this year I emailed Mark to
say that I regard that effort as being completely dead (even though I
still use it, because it's the only way to get SPDIF output properly
working with MPEG/AC3 compressed output.)

Jean is only interested in feeding I2S out to the HDMI port, he's not
interested in the SPDIF optical connector on the side, neither is he
interested in the compressed stream support.  Neither of these are now
possible without breaking the DT bindings for the ASoC implementation.

This is the problem - in the mad headlong rush for DT support as if
it's the most important thing on the planet, it seems that things
haven't been properly considered - and it's not like I haven't been
publishing these ASoC patches.  I've sent numerous rounds of patches
during 2013.

So, what do we do now with support for compressed audio streams via
SPDIF on kirkwood hardware?  As far as I can see, it's no longer
possible and mainline kernels will never support this.  Please tell
me I'm wrong...

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Re: [PATCH 00/13] Remove mach-kirkwood and mach-dove

[Andrew Lunn]

> So, what do we do now with support for compressed audio streams via
> SPDIF on kirkwood hardware?  As far as I can see, it's no longer
> possible and mainline kernels will never support this.  Please tell
> me I'm wrong...

Well, it would of been nice if you had made a comment to either v1 or
v2 of my patchset saying this is going to cause problems for some
devices.

So i will go look at your patch to add frontend and backend and see
what it means for the current DT binding. The nice thing about
kirkwood (and Dove) is, there is no uboot with DT support. Hence
nobody is flashing there DT blob. They are always using appended DT.
So i'm not against changing the binding. And it has only been in the
kernel for one cycle, so i doubt there are too many users at the
moment.

	Andrew

Re: [PATCH 00/13] Remove mach-kirkwood and mach-dove

[Russell King - ARM Linux]

On Mon, Jun 30, 2014 at 07:31:30PM +0200, Sebastian Hesselbarth wrote:
> On 06/30/2014 06:56 PM, Russell King - ARM Linux wrote:
> > On Mon, Jun 30, 2014 at 05:35:49PM +0200, Sebastian Hesselbarth wrote:
> >> On 06/30/2014 04:25 PM, Russell King - ARM Linux wrote:
> >>> Nothing has changed on the PMU patches since I posted them, because
> >>> they're based on 3.15 and there's been no changes there.
> >>
> >> I offered to deal with mainlining them end of April, you never replied.
> >> I know that if you dislike something you answer, but it is hard to tell
> >> if silence means agreement.
> >>
> >> I am not going to waste any time preparing patches just to get a NAK.
> > 
> > That's because I am quite prepared to work on them _if_ there is a way
> > forward.  You've already said that changing things like hwmon and rtc
> > is a work in progress to convert them to regmap.  That's great, but
> > in order to progress these myself, I need *visibility* of that work,
> > and there is zero visibility of that.
> 
> So, we are on the same boat. For the HDMI issue, I also need visibility
> to add any more ideas how to deal with it. Just provide me the binaries,
> I see if I can at least reproduce the issue.

What I can do is provide a branch of all the current stuff which is
relatively clean for mainline:

http://ftp.arm.linux.org.uk/cgit/linux-cubox.git/log/?h=cubox-ml-3.15

there's lots missing from it, and it probably doesn't even build
properly, but that's one of the side effects of trying to keep
everything working and juggling between mainline and something that
works.

> Right. And since I am one of those volunteers, I can tell you that
> some specific attitude in dealing with people is definitely reducing
> the willingness to stick with it.
> 
> I constantly offered to spend my spare time for hunting the issue
> but only received ranting.

All that I'm /complaining/ about is the very quick removal of the
non-DT support.

> Sure, nobody said that DT is feature complete. But you'd have to do
> the same on mainline non-DT dove as there has never been support for
> the cubox.

Indeed, but successively merging mainline into Rabeeh's tree is rather
trivial for the most part (apart from a few nasty conflicts, such as the
completely different si5531 driver).  Where that happens, I take
mainline's version, and if necessary augment it to make non-DT work
again.

That has pros and cons - the pro is that I get to keep a feature complete
kernel on the hardware.  The con is that I still need to use bits of
mach-dove to make everything work, even with DT.

> If it helps us tracking down the HDMI issue, we can have below setup
> for DT dove and get rid of it incrementally.

Right, and you'll also need stuff such as the component updates I've
been trying to push recently, updates to Armada DRM so that it can be
used in a DT environment (included in the above git tree), and probably
a few other things.

The timeline for DRM stuff looks something like this:

- get the component updates reviewed and acceptable
- get those merged by Greg
- chase up what's happening with the DRM bug fix
- get the DRM of_graph helper reviewed and merged
- get the Armada DRM component helper conversion reviewed and merged
  (which depends on sorting out how to deal with the component helper
   dependency and need for those changes to be with these changes.)
- same for the tda998x driver, which will also need the DRM of_graph
  helpers.

I /suspect/ what's going to happen there is that the component updates
will make the 3.17 merge window, and maybe the initial DRM stuff.
The remainder will be for the 3.18 merge window when everyone has
the dependencies in their trees to cope with those changes.

So that's probably something like 4 to 6 months just for that (assuming
a kernel cycle is three months.)

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Re: [PATCH 00/13] Remove mach-kirkwood and mach-dove

[Ezequiel Garcia]

On 30 Jun 03:25 PM, Russell King - ARM Linux wrote:
[..]
> 
> Right, so what I have against mainline right now in my tree is:
> 
> * two SPI patches, which have been taken by Mark
> * one long term core ARM patch adding optimised memset/memcpy IO operations
> * the PMU stuff
> * BMM (already published in git form)
> * Vmeta (already published in git form)
> * ASoC cleanup patches, which Mark took last week.
> 
> What isn't visible is the stuff which converts Armada DRM to component
> support, along with the TDA998x driver (and it sounds like the TI LCDC
> people may end up blocking that effort).  This is necessary to convert
> it to DT support.  However, this depends on the component helper, and
> that's where there's a blocking problem.
> 
> I sent out a bunch of patches last week, with a request for help from
> the Exynos people.  So far, that has only attracted one relatively minor
> comment from the iMX people.  I can't move forwards with the Armada
> DRM until this is sorted.  Neither can I move forward with the TDA998x
> driver.
> 

I'm not sure I understand why tilcdc people are an obstacle for the
component stuff, other than the lack of responsiveness. In any case, if
you have some tilcdc or tda998x patches and you need help with the mainline
process, feel free to ask.

I've been doing some tilcdc work lately, and I'd be happy to help you with
that.

Do you plan to change the devicetree binding? While the current one works fine,
it has several deficiencies, and it would be great to sort them out before
the whole platform becomes obsolete.

Really, if you need help and if you think I can handle it, just drop me a line
and I'll see what I can do.
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

Re: [PATCH 00/13] Remove mach-kirkwood and mach-dove

[Ezequiel Garcia]

On 30 Jun 03:25 PM, Russell King - ARM Linux wrote:
[..]
> 
> Right, so what I have against mainline right now in my tree is:
> 
> * two SPI patches, which have been taken by Mark
> * one long term core ARM patch adding optimised memset/memcpy IO operations
> * the PMU stuff
> * BMM (already published in git form)
> * Vmeta (already published in git form)
> * ASoC cleanup patches, which Mark took last week.
> 
> What isn't visible is the stuff which converts Armada DRM to component
> support, along with the TDA998x driver (and it sounds like the TI LCDC
> people may end up blocking that effort).  This is necessary to convert
> it to DT support.  However, this depends on the component helper, and
> that's where there's a blocking problem.
> 
> I sent out a bunch of patches last week, with a request for help from
> the Exynos people.  So far, that has only attracted one relatively minor
> comment from the iMX people.  I can't move forwards with the Armada
> DRM until this is sorted.  Neither can I move forward with the TDA998x
> driver.
> 

I'm not sure I understand why tilcdc people are an obstacle for the
component stuff, other than the lack of responsiveness. In any case, if
you have some tilcdc or tda998x patches and you need help with the mainline
process, feel free to ask.

I've been doing some tilcdc work lately, and I'd be happy to help you with
that.

Do you plan to change the devicetree binding? While the current one works fine,
it has several deficiencies, and it would be great to sort them out before
the whole platform becomes obsolete.

Really, if you need help and if you think I can handle it, just drop me a line
and I'll see what I can do.
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/13] Remove mach-kirkwood and mach-dove

[Jean-Francois Moine]

On Mon, 30 Jun 2014 17:20:51 +0100
Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:

> Add DPCM support to kirkwood-i2s to support the I2S and SPDIF streams.
> This consists of:
> - a single front end DAI called "kirkwood-fe" with "dma-tx" and "dma-rx"
>   streams.
> - one backend DAI called "kirkwood-i2s" for I2S with streams named
>   "i2s-tx" and "i2s-rx"
> - one backend DAI called "kirkwood-spdif" for SPDIF with a single stream
>   named "spdif-tx".

In the Cubox, you may have kirkwood S/PDIF with both HDMI and S/PDIF
outputs and this avoids to activate both kirkwood I2S and S/PDIF in
most cases.

> -		.rates = SNDRV_PCM_RATE_CONTINUOUS,
> -		.rate_min = 5512,
> -		.rate_max = 192000,
> -		.formats = KIRKWOOD_I2S_FORMATS,
> +		.rates = SNDRV_PCM_RATE_8000_192000 |
> +			 SNDRV_PCM_RATE_CONTINUOUS |
> +			 SNDRV_PCM_RATE_KNOT,
> +		.formats = KIRKWOOD_FE_FORMATS,

This does not work: SNDRV_PCM_RATE_CONTINUOUS asks for rate_min and
rate_max. SNDRV_PCM_RATE_KNOT is of no interest here.

> diff --git a/sound/soc/kirkwood/kirkwood-openrd.c b/sound/soc/kirkwood/kirkwood-openrd.c
> index 65f2a5b9ec3b..78fb05ff44a8 100644
> --- a/sound/soc/kirkwood/kirkwood-openrd.c
> +++ b/sound/soc/kirkwood/kirkwood-openrd.c
> @@ -49,24 +49,34 @@ static struct snd_soc_ops openrd_client_ops = {
>  
>  
>  static struct snd_soc_dai_link openrd_client_dai[] = {
> +	KIRKWOOD_FE_DAI_LINK(".0", 1, 1),
>  {
>  	.name = "CS42L51",
>  	.stream_name = "CS42L51 HiFi",
> -	.cpu_dai_name = "i2s",
> -	.platform_name = "mvebu-audio",
> +	.cpu_name = "mvebu-audio.0",
> +	.cpu_dai_name = "kirkwood-i2s",
> +	.platform_name = "snd-soc-dummy",
>  	.codec_dai_name = "cs42l51-hifi",
>  	.codec_name = "cs42l51-codec.0-004a",
>  	.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_CBS_CFS,
>  	.ops = &openrd_client_ops,
> +	.dpcm_playback = 1,
> +	.dpcm_capture = 1,
>  },
>  };

There is no need to change the openrd and t5325 drivers: they may use
the kirkwood DAI's in a non-DPCM way.

> diff --git a/sound/soc/kirkwood/kirkwood-spdif.c b/sound/soc/kirkwood/kirkwood-spdif.c
> index 9d49bc53f07d..6098dde85fc9 100644
> --- a/sound/soc/kirkwood/kirkwood-spdif.c
> +++ b/sound/soc/kirkwood/kirkwood-spdif.c

What is that file?

Eventually, your code is close to the one I tested end 2013. But, once
again, this does not work because DPCM does not handle the format and
rate constraints of the backends. This is critical for the device which
is connected to HDMI.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH 00/13] Remove mach-kirkwood and mach-dove

[Russell King - ARM Linux]

On Tue, Jul 01, 2014 at 06:44:13PM +0200, Jean-Francois Moine wrote:
> On Mon, 30 Jun 2014 17:20:51 +0100
> Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> 
> > Add DPCM support to kirkwood-i2s to support the I2S and SPDIF streams.
> > This consists of:
> > - a single front end DAI called "kirkwood-fe" with "dma-tx" and "dma-rx"
> >   streams.
> > - one backend DAI called "kirkwood-i2s" for I2S with streams named
> >   "i2s-tx" and "i2s-rx"
> > - one backend DAI called "kirkwood-spdif" for SPDIF with a single stream
> >   named "spdif-tx".
> 
> In the Cubox, you may have kirkwood S/PDIF with both HDMI and S/PDIF
> outputs and this avoids to activate both kirkwood I2S and S/PDIF in
> most cases.

I run my Cubox with just SPDIF output to both.

> > -		.rates = SNDRV_PCM_RATE_CONTINUOUS,
> > -		.rate_min = 5512,
> > -		.rate_max = 192000,
> > -		.formats = KIRKWOOD_I2S_FORMATS,
> > +		.rates = SNDRV_PCM_RATE_8000_192000 |
> > +			 SNDRV_PCM_RATE_CONTINUOUS |
> > +			 SNDRV_PCM_RATE_KNOT,
> > +		.formats = KIRKWOOD_FE_FORMATS,
> 
> This does not work: SNDRV_PCM_RATE_CONTINUOUS asks for rate_min and
> rate_max. SNDRV_PCM_RATE_KNOT is of no interest here.

Yes, there was a recent discussion about that, but I've yet to update
this driver for it.

> > diff --git a/sound/soc/kirkwood/kirkwood-openrd.c b/sound/soc/kirkwood/kirkwood-openrd.c
> > index 65f2a5b9ec3b..78fb05ff44a8 100644
> > --- a/sound/soc/kirkwood/kirkwood-openrd.c
> > +++ b/sound/soc/kirkwood/kirkwood-openrd.c
> > @@ -49,24 +49,34 @@ static struct snd_soc_ops openrd_client_ops = {
> >  
> >  
> >  static struct snd_soc_dai_link openrd_client_dai[] = {
> > +	KIRKWOOD_FE_DAI_LINK(".0", 1, 1),
> >  {
> >  	.name = "CS42L51",
> >  	.stream_name = "CS42L51 HiFi",
> > -	.cpu_dai_name = "i2s",
> > -	.platform_name = "mvebu-audio",
> > +	.cpu_name = "mvebu-audio.0",
> > +	.cpu_dai_name = "kirkwood-i2s",
> > +	.platform_name = "snd-soc-dummy",
> >  	.codec_dai_name = "cs42l51-hifi",
> >  	.codec_name = "cs42l51-codec.0-004a",
> >  	.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_CBS_CFS,
> >  	.ops = &openrd_client_ops,
> > +	.dpcm_playback = 1,
> > +	.dpcm_capture = 1,
> >  },
> >  };
> 
> There is no need to change the openrd and t5325 drivers: they may use
> the kirkwood DAI's in a non-DPCM way.

With a proper DPCM solution, at least one backend must be linked so that
the CPU side knows which interface(s) are in use.  This solution allows
both to be used simultaneously, which, if you wish to use I2S on the
Cubox to drive the TDA998x (against my advice, but I'm not going to
stop you) and also have the SPDIF output on the side of the device
working, this is required.

> > diff --git a/sound/soc/kirkwood/kirkwood-spdif.c b/sound/soc/kirkwood/kirkwood-spdif.c
> > index 9d49bc53f07d..6098dde85fc9 100644
> > --- a/sound/soc/kirkwood/kirkwood-spdif.c
> > +++ b/sound/soc/kirkwood/kirkwood-spdif.c
> 
> What is that file?

This is the file for supporting SPDIF on the Cubox.

> Eventually, your code is close to the one I tested end 2013. But, once
> again, this does not work because DPCM does not handle the format and
> rate constraints of the backends. This is critical for the device which
> is connected to HDMI.

DPCM may have these shortcomings, but this is how Mark Brown was telling
me he wanted the hardware on Dove supported, and would not accept any
other solution from me.

However, what you say does not hold for all cases - if you use the SPDIF
output on the side of the Cubox (as I do) you are not limited to the
constraints of the attached HDMI device - in fact, limiting this case to
the constraints of the attached HDMI device is wrong.  The only time
this makes sense is if you only want to use the HDMI device and not the
optical out on the side.

With a decoder box connected to the optical output, I can decode a wide
range of sample rates beyond those which my TV can cope with, and I can
also directly decode AC-3 and MPEG2 audio streams in hardware - even to
decoding AC-3 to 5.1 audio without any load on the Dove CPU beyond
sending the compressed audio stream.

This is where getting this stuff correct is most important - the TV must
not see valid audio being sent to it (with SPDIF, compressed audio is
always sent with the valid bit not set.)  With I2S, the I2S output must
be muted or disabled - exactly as the Dove manuals clearly state.

Also bear in mind that HDMI is based on SPDIF (it's SPDIF with a few
bits omitted) and HDMI also supports compressed audio, dependent on the
attached device's capabilities, and the attached device will decode
compressed audio when presented correctly - which is only possible via
a SPDIF connection between the Dove and TDA998x.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Re: [PATCH 09/13] PCI: Remove ARCH_KIRKWOOD and ARCH_DOVE dependency

[Andrew Lunn]

On Sat, Jul 05, 2014 at 11:54:58AM -0600, Bjorn Helgaas wrote:
> On Sun, Jun 29, 2014 at 10:59:58PM +0200, Andrew Lunn wrote:
> > mach-kirkwood and mach-dove have been removed, now that these SoCs
> > lives in mach-mvebu. ARCH_MVEBU is sufficient.
> 
> Looks like there's still discussion about the cubox regression, so
> I'll wait until that's resolved and Thomas or Jason ack this.

I will produce a kirkwood only version soon.

  Andrew

> 
> > 
> > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: linux-pci@vger.kernel.org
> > ---
> >  drivers/pci/host/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> > index 21df477be0c8..b9692deeb99a 100644
> > --- a/drivers/pci/host/Kconfig
> > +++ b/drivers/pci/host/Kconfig
> > @@ -3,7 +3,7 @@ menu "PCI host controller drivers"
> >  
> >  config PCI_MVEBU
> >  	bool "Marvell EBU PCIe controller"
> > -	depends on ARCH_MVEBU || ARCH_DOVE || ARCH_KIRKWOOD
> > +	depends on ARCH_MVEBU
> >  	depends on OF
> >  
> >  config PCIE_DW
> > -- 
> > 2.0.0
> > 

Re: [PATCH 09/13] PCI: Remove ARCH_KIRKWOOD and ARCH_DOVE dependency

[Bjorn Helgaas]

On Sun, Jun 29, 2014 at 10:59:58PM +0200, Andrew Lunn wrote:
> mach-kirkwood and mach-dove have been removed, now that these SoCs
> lives in mach-mvebu. ARCH_MVEBU is sufficient.

Looks like there's still discussion about the cubox regression, so
I'll wait until that's resolved and Thomas or Jason ack this.

> 
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: linux-pci@vger.kernel.org
> ---
>  drivers/pci/host/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index 21df477be0c8..b9692deeb99a 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -3,7 +3,7 @@ menu "PCI host controller drivers"
>  
>  config PCI_MVEBU
>  	bool "Marvell EBU PCIe controller"
> -	depends on ARCH_MVEBU || ARCH_DOVE || ARCH_KIRKWOOD
> +	depends on ARCH_MVEBU
>  	depends on OF
>  
>  config PCIE_DW
> -- 
> 2.0.0
> 

Re: [rtc-linux] Re: [PATCH 00/13] Remove mach-kirkwood and mach-dove

[Alexander Holler]

Am 30.06.2014 20:16, schrieb Andrew Lunn:
>> So, what do we do now with support for compressed audio streams via
>> SPDIF on kirkwood hardware?  As far as I can see, it's no longer
>> possible and mainline kernels will never support this.  Please tell
>> me I'm wrong...
> 
> Well, it would of been nice if you had made a comment to either v1 or
> v2 of my patchset saying this is going to cause problems for some
> devices.
> 
> So i will go look at your patch to add frontend and backend and see
> what it means for the current DT binding. The nice thing about
> kirkwood (and Dove) is, there is no uboot with DT support. Hence
> nobody is flashing there DT blob. They are always using appended DT.
> So i'm not against changing the binding. And it has only been in the
> kernel for one cycle, so i doubt there are too many users at the
> moment.

And most people just don't care if some DT-binding changes as they can
change the provided DT themself. At least on every sane device.

Re: [PATCH 00/13] Remove mach-kirkwood and mach-dove

[Jason Cooper]

Andrew,

On Sun, Jun 29, 2014 at 10:59:47PM +0200, Andrew Lunn wrote:
> This patchset removes arch/arm/mach-kirkwood and arch/arm/mach-dove.
> These SoCs are now supported in arch/arm/mach-mvebu using device tree.
> 
> Change the dependencies for a number of drivers, either to use
> ARCH_MVEBU where the drivers are generic, or MACH_KIRKWOOD and
> MACH_DOVE where the drivers are specific to a SoC.
> 
> 
> Andrew Lunn (13):
>   ARM: Kirkwood: Remove mach-kirkwood
>   ARM: Dove: Remove mach-dove
>   sound: ASoC: kirkwood: Remove unused drivers
>   sound: ASoC: kirkwood: Remove ARCH_KIRKWOOD and ARCH_DOVE dependency
>   cpuidle: kirkwood: Replace ARCH_KIRKWOOD dependency
>   ata: Remove ARCH_KIRKWOOD and ARCH_DOVE dependency
>   thermal: Replace ARCH_KIRKWOOD and ARCH_DOVE dependency
>   leds: Replace ARCH_KIRKWOOD dependency
>   PCI: Remove ARCH_KIRKWOOD and ARCH_DOVE dependency
>   phy: Replace ARCH_KIRKWOOD and ARCH_DOVE dependency
>   rtc: Remove ARCH_KIRKWOOD and ARCH_DOVE dependency
>   watchdog: Remove ARCH_KIRKWOOD and ARCH_DOVE dependency
>   Remove ARCH_DOVE dependency

Let's just do mach-kirkwood/ removal this time around and we'll
re-address mach-dove next window.

thx,

Jason.