On Mon, Oct 27, 2014 at 09:17:55AM +0100, Geert Uytterhoeven wrote:

Hi Simon,

On Mon, Oct 27, 2014 at 5:03 AM, Simon Horman [off-list ref] wrote:

quoted

On Thu, Oct 23, 2014 at 01:18:57PM +0200, Geert Uytterhoeven wrote:

quoted

Add support for the A4MP power domain, and hook up the HDMI-Link and FSI
hardware blocks.
This domain also contains the SPU2, FMSI, and BBIF2 hardware blocks,
but these are currently not used by any driver.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

Is it possible to split this into two patches.

A board patch (that touches board-armadillo800eva.c)
and an SoC patch (the rest). Likewise for any remaining
patches in this series that touch both board and SoC code.

The reason for this is that it would make the patches fit
the branch scheme that arm-soc people like. In particular splitting
patches between soc and boards branches.

I kept them together as adding the PM domain without the devices will
cause regressions (the PM domain core will power down the PM domain as
it doesn't know about the to-be-added devices, and thus thinks it's unused).

As the link from a device to a PM domain is a name string, and not a
C reference, I could split them in two parts: first the board part
that adds some
devices, and then the SoC part that adds the PM domain and more devices.
But only if you can guarantee that the SoC part will be merged first, also
by arm-soc and Linus.

Still, I prefer to keep them together. Hooking up devices to PM domains is
SoC-specific, not board specific (for DT it lives in the .dtsi). It's
unfortunate this code is in the board-specific C files due to board-specific
configuration (cfr. .dts overriding/extending .dtsi).

What do you think? Do you agree?

Hi Geert, thanks for the explanation. I agree that it makes sense
to keep things together. I'll see about queuing-up your series as-is.