[PATCH] arm: Add basic support for new Marvell Armada SoC family

[Jason Cooper]

On Tue, May 22, 2012 at 05:06:12PM +0100, Ben Dooks wrote:
> On 22/05/12 17:03, Jason Cooper wrote:
> >On Tue, May 22, 2012 at 10:25:28AM -0400, Nicolas Pitre wrote:
> >>On Mon, 21 May 2012, Arnd Bergmann wrote:
> >>
> >>>On Monday 21 May 2012, Jason Cooper wrote:
> >>>>On Mon, May 21, 2012 at 05:11:31PM +0100, Russell King - ARM Linux wrote:
> >>>>>On Mon, May 21, 2012 at 11:35:59AM -0400, Jason Cooper wrote:
> >>>
> >>>>>I'd also suggest going against our current setup of not having "board/"
> >>>>>subdirectories in mach-*.  Just name them board-foo.c.
> >>>>
> >>>>This is what we are currently doing for boards in the midst of DT
> >>>>conversion.  In mach-kirkwood/ there is board-dt.c, and
> >>>>board-dreamplug.c.  board-dt.c is the DT code, while board-dreamplug.c
> >>>>is board specific init code that hasn't been converted to DT yet.  Once
> >>>>converted, board-dreamplug.c will disappear.  This follows what tegra is
> >>>>doing.
> >>>>
> >>>>We can leave the legacy, unconverted boards where they are
> >>>>(mach-kirkwood/guruplug-setup.c), but what about the common code they
> >>>>depend on (mpp.c, pcie.c, etc)?  That's what I was suggesting putting in
> >>>>mach-mvebu/board/...
> >>>
> >>>I like the idea of leaving the *-setup.c board files where they are,
> >>>while moving all the other files (headers and the platform-wide .c
> >>>files) to mach-mvebu.
> >>>
> >>>However, given that we still don't have consensus on where things
> >>>should really be and the merge window is already open, I would suggest
> >>>don't try to do it all now for v3.5 but rather plan it for v3.6 once
> >>>we agreed on one approach, and then do some of the next consolidation
> >>>steps as well.
> >>
> >>I'd suggest that mach-mvebu be created earlier for the new EBU ARmada
> >>SOC support though.
> >
> >I'd like to second that, and suggest moving mach-kirkwood/board-*.c to
> >it.  Basically, make it the one location for marvell SoC dt boards.
> >
> >I'm looking at the scope of it now.
> 
> I'm going to say let's leave these alone for the moment. The kernel
> per-version diff is large enough as it is and moving stuff around for
> the sake of it is just going to make it larger and thus draw more
> unwanted attention to arch/arm.

Fair enough.

thx,

Jason.