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

Ben Dooks ben.dooks at codethink.co.uk
Tue May 22 12:06:12 EDT 2012


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.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius



More information about the linux-arm-kernel mailing list