[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