[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 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 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

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

[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

[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

[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 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

[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

[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: [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

[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

[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.