arm: Add basic support for new Marvell Armada 370 and Armada XP SoC

arch/arm/mach-mvebu/include/mach/uncompress.h new file +6 -0

new file mode 100644
index 0000000..3642997
@@ -0,0 +1,41 @@
+/*
+ * Marvell Armada SoC kernel uncompression UART routines
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>

Quoted 10 lines · Gregory CLEMENT

arch/arm/mach-mvebu/Kconfig new file +4 -0

new file mode 100644
index 0000000..72d39e5
@@ -0,0 +1,7 @@
+if ARCH_MVEBU
+
+menu "Marvell SOC with device tree"
+

arch/arm/mach-mvebu/Kconfig line 7

Quoted 3 lines

arch/arm/mach-mvebu/Kconfig new file +3 -0

+endmenu
+
+endif

The "with device tree" part is implied here, so you should not need to mention it, but it would be good if you could say which SOC this relates to, i.e. not the pxa/mmp series but the other line, in whatever way you want to name it.

Quoted 13 lines

arch/arm/mach-mvebu/Kconfig new file +12 -0

+static struct map_desc mvebu_io_desc[] __initdata = {
+	{
+		.virtual	= MVEBU_REGS_VIRT_BASE,
+		.pfn		= __phys_to_pfn(MVEBU_REGS_PHYS_BASE),
+		.length		= MVEBU_REGS_SIZE,
+		.type		= MT_DEVICE,
+	},
+};
+
+void __init mvebu_map_io(void)
+{
+	iotable_init(mvebu_io_desc, ARRAY_SIZE(mvebu_io_desc));

Quoted 1 line

+}

It looks like MVEBU_REGS_PHYS_BASE is common between Armada XP and Armada 370, but is different for the other ones we want to support here (kirkwood, orion5x, mv78xx0, dove), so the name seems to be inappropriate. I would recommend dropping the entire file and just leaving the map_desc in the individual soc specific files, even thouth that means you have two identical calls here.

Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Quoted 11 lines · Arnd Bergmann

Quoted 10 lines · Gregory CLEMENT

arch/arm/mach-mvebu/Kconfig new file +4 -0

new file mode 100644
index 0000000..72d39e5
@@ -0,0 +1,7 @@
+if ARCH_MVEBU
+
+menu "Marvell SOC with device tree"
+

Quoted 8 lines

arch/arm/mach-mvebu/Kconfig line 7

Quoted 3 lines

arch/arm/mach-mvebu/Kconfig new file +3 -0

+endmenu
+
+endif

The "with device tree" part is implied here, so you should not need to mention it, but it would be good if you could say which SOC this relates to, i.e. not the pxa/mmp series but the other line, in whatever way you want to name it.

Do you mean to name all the SOC aimed to be supported ? and write something like that:

menu "Marvell SOC from EBU division (Orion, Kirkwood, Dove, MV78xx0, Armada 370/XP, ...)"

Or for now just the currently supported SOC ? :
menu "Marvell SOC from EBU division (Armada 370, Armada XP, ...)"

OK I will drop common.* files. We will see later to introduce them again when we find common features with the other SOC.

Quoted 11 lines · Arnd Bergmann

Quoted 10 lines · Gregory CLEMENT

arch/arm/mach-mvebu/Kconfig new file +4 -0

new file mode 100644
index 0000000..72d39e5
@@ -0,0 +1,7 @@
+if ARCH_MVEBU
+
+menu "Marvell SOC with device tree"
+

Quoted 8 lines

arch/arm/mach-mvebu/Kconfig line 7

Quoted 3 lines

arch/arm/mach-mvebu/Kconfig new file +3 -0

+endmenu
+
+endif

The "with device tree" part is implied here, so you should not need to mention it, but it would be good if you could say which SOC this relates to, i.e. not the pxa/mmp series but the other line, in whatever way you want to name it.

Do you mean to name all the SOC aimed to be supported ? and write something like that:

menu "Marvell SOC from EBU division (Orion, Kirkwood, Dove, MV78xx0, Armada 370/XP, ...)"

Or for now just the currently supported SOC ? :
menu "Marvell SOC from EBU division (Armada 370, Armada XP, ...)"

Signed-off-by Gregory CLEMENT <[email protected]>

Signed-off-by Thomas Petazzoni <[email protected]>

Signed-off-by Lior Amsalem <[email protected]>

Quoted 3 lines · Gregory CLEMENT

Signed-off-by Gregory CLEMENT <[email protected]>

Signed-off-by Thomas Petazzoni <[email protected]>

Signed-off-by Lior Amsalem <[email protected]>

Please always keep this patch last in the series, as soon as it is applied, one can build a kernel for mvebu, which ends up not working. Each step in a patch series needs to provide a working, incremental improvement over the previous one, so when adding a new feature in parts, you can only enable it once you have something that actually builds.

Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

arch/arm/mach-mvebu/armada-370-xp-dt.c new file +19 -0

@@ -0,0 +1,65 @@
+/*
+ * Device Tree support for Armada XP platforms.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ * Gregory CLEMENT <[email protected]>
+ * Thomas Petazzoni <[email protected]>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/of_platform.h>
+#include <linux/io.h>
+#include <asm/mach/arch.h>

Arnd, Olof,

You'll find in this patch set the new version of the initial support for a new family of ARMv7-compatible Marvell SoCs initially submitted by my colleague Thomas Petazzoni. Following the conclusion of the discussion when we submitted our first version we have chosen to add this support for this SoC family in the to support in the arch/arm/mach-mvebu/ directory.

As for the previous release, both the Armada 370 and the Armada XP SoCs are supported in this directory, and we are able to build a single kernel image that boots on both SoCs. Both SoCs use the PJ4B processor, a Marvell-developed ARM core that implements the ARMv7 instruction set. We are currently using Marvell evaluation boards for both of those SoCs, and the support for those boards is added in this patch set.

We remained focused on a limited preliminary support which only includes the necessary code for timer and IRQ support, the serial controller is a standard 16550-compatible one. The diffstat looks like:

 Documentation/devicetree/bindings/arm/armada_370_xp-mpic.txt  |   23 +
 Documentation/devicetree/bindings/arm/armada_370_xp-timer.txt |   11 +
 Documentation/devicetree/bindings/arm/armada_370_xp.txt       |   24 +
 MAINTAINERS                                                   |    8 +
 arch/arm/Kconfig                                              |   15 +
 arch/arm/Makefile                                             |    1 +
 arch/arm/boot/dts/armada-370-db.dts                           |   41 ++
 arch/arm/boot/dts/armada-370-xp.dtsi                          |   66 +++
 arch/arm/boot/dts/armada-370.dtsi                             |   29 +
 arch/arm/boot/dts/armada-xp-db.dts                            |   40 ++
 arch/arm/boot/dts/armada-xp.dtsi                              |   49 ++
 arch/arm/configs/mvebu_defconfig                              |   47 ++
 arch/arm/mach-mvebu/Kconfig                                   |   14 +
 arch/arm/mach-mvebu/Makefile                                  |    2 +
 arch/arm/mach-mvebu/Makefile.boot                             |    1 +
 arch/arm/mach-mvebu/armada-370-xp-dt.c                        |   65 +++
 arch/arm/mach-mvebu/common.c                                  |   36 ++
 arch/arm/mach-mvebu/common.h                                  |   24 +
 arch/arm/mach-mvebu/include/mach/armada-370-xp.h              |   22 +
 arch/arm/mach-mvebu/include/mach/debug-macro.S                |   24 +
 arch/arm/mach-mvebu/include/mach/mvebu.h                      |   22 +
 arch/arm/mach-mvebu/include/mach/timex.h                      |   13 +
 arch/arm/mach-mvebu/include/mach/uncompress.h                 |   41 ++
 arch/arm/mach-mvebu/irq-armada-370-xp.c                       |  133 +++++
 arch/arm/mach-mvebu/time-armada-370-xp.c                      |  244 +++++++++
 25 files changed, 995 insertions(+)

This patch set, and the support for those SoCs, started as a collaborative effort from Marvell engineers (who have done the initial development work) and Free Electrons engineers (who are reshaping the code for mainline submission, adding device tree support, etc.). And for this new version we got contributions from Ben Dooks from Codethink.

The patch set is based on your arm-soc/for-next branch (updated on Monday 11th June).

The main change between V1 and V2 is the use of a new mach-mvebu directory as this directory is aimed to receive most of the Marvell SOC converted to the device tree, we intended to make the code less specific. The other main part was to remove all the unnecessary code or even files.

Here comes a pretty exhaustive list of the changes:

* Created a new mach- directory called mach-mvebu as suggested on the mainling-list. Converted most the "armada" word by the "mvebu", but as some code remains specific to the armada 370 and armada XP SOC, then created also the aramada_370_xp suffix for this part. This suffix was dedicated for the irq and timer part. It was also used for the register related to the reset part. And of course it was also used for the device tree part.

* Merged axp-dt.c and a370-dt.c files in one single armada_370_xp-dt.c file.

* Deleted most of the mapping address in include/mach/armada.h and split it in two headers file:

- mvebu.h which contains the virtual and physical mapping for the internal registers of the mvebu SOC. This ones are mainly used for the early print during boot.

- armada_370_xp which contains the registers offset and mask for resetting the CPU.

* Removed unused headers such as
- hardware.h by directly including accurate header when needed
- gpio.h by removing the dependencies to PLAT-ORION
- io.h no more needed for CPI
- irqs.h by using SPARSE_IRQ
- system.h no more needed for new SOC

* Removed the PCI related code as it was not necessary for the initial submission

* Removed all the PLAT-ORION dependencies remaining

* Ensured property reading checks for error when getting data from device tree in the timer file. This was a patch from Ben Dooks with the following comments:

"The call to of_property_read_u32() only checks for the value that the clk
variable is set to being non-zero, and not the return value of the call itself.

This caused a system without the clock-frequency attribute to fail to boot as it used a random value on the stack to setup the system timers and thus cause an interrupt storm.

Also ensure clk is set to zero, to avoid warnings."

* Converted irq.c to use SPARSE_IRQ

* Added the following bug fixes and improvements in irq.c from Ben Dooks

- MPIC: BUG_ON() if the of_iomap() fails: Ensure that if either resource is missing, we stop the kernel in a reasonably fatal way.

- MPIC: Move main register base to base of MPIC registers: The current kernel driver had the MPIC base at the base of the block containing the MPIC and not the MPIC itself. Change this value in the driver and the .dtsi file

Also change the register size in the .dtsi to be the size of the register range for the MIPC and not the block it is in.

- MPIC: Move per-cpu register base: The current kernel driver had the MPIC per-cpu register base at the base of the per-cpu register block and not at the base of the specific per-cpu interrupt registers.

Move the driver and .dtsi to use the correct base and size.

- MPIC: number fetch should use irqd_to_hwirq(): The mask and unmask routines are assuming that d->irq is a 1:1 mapping with the interrupt hardware. Use the irqd_to_hwirq() call to map the irq_data to the hardware irq number directly.

- MPIC: read number of interrupts from control register: Read the number of MPIC interrupts from the controller and only register that many.

Andrew Lunn asked for refactoring the _restart() function to being used by any MVEBU SOC, but we didn't find a nice way to do it. Indeed the registers mapping differs between the SOC and the bit mask too. A solution could be to get this mapping through the device tree, but we are not sure it was a good usage of the device tree.

Best regards,

Gregory Clement

I noticed that you are using mach-mvebu in these patches. I have seen these machines referred to as 'armada', 'axp', 'armadaxp', etc. Will 'mvebu' be the official machine name to use for these systems? I'm looking for a 'name' to identify the common kernel for these systems. For reference, the names of the ARM kernels we are currently building in Fedora include: 'highbank', 'imx', 'kirkwood', 'omap', and 'tegra'.

Thank you,

d.marlin
===========

Quoted 7 lines · Gregory CLEMENT

Arnd, Olof,

You'll find in this patch set the new version of the initial support for a new family of ARMv7-compatible Marvell SoCs initially submitted by my colleague Thomas Petazzoni. Following the conclusion of the discussion when we submitted our first version we have chosen to add this support for this SoC family in the to support in the arch/arm/mach-mvebu/ directory.

Quoted 9 lines · David Marlin

I noticed that you are using mach-mvebu in these patches. I have seen these machines referred to as 'armada', 'axp', 'armadaxp', etc. Will 'mvebu' be the official machine name to use for these systems? I'm looking for a 'name' to identify the common kernel for these systems. For reference, the names of the ARM kernels we are currently building in Fedora include: 'highbank', 'imx', 'kirkwood', 'omap', and 'tegra'.

Quoted 5 lines

Thank you,

d.marlin
===========

Hello David,

Mvebu is aimed to be the official name for the all the SOC with device tree support coming out of Marvell's EBU division. As stated Nicolas Pitre: "One thing that is common to Orion/Kirkwood/Dove/(insert some Armada flavours here)/etc though is that they came out of Marvell's EBU division."

For the beginning only Armada XP and Armada 370 are in this directory but as son as the other Marvell architectures will be converted to device tree they will be moved to mach-mvebu.

I noticed that you are using mach-mvebu in these patches. I have seen these machines referred to as 'armada', 'axp', 'armadaxp', etc. Will 'mvebu' be the official machine name to use for these systems? I'm looking for a 'name' to identify the common kernel for these systems. For reference, the names of the ARM kernels we are currently building in Fedora include: 'highbank', 'imx', 'kirkwood', 'omap', and 'tegra'.

You'll find in this patch set the new version of the initial support for a new family of ARMv7-compatible Marvell SoCs initially submitted by my colleague Thomas Petazzoni. Following the conclusion of the discussion when we submitted our first version we have chosen to add this support for this SoC family in the to support in the arch/arm/mach-mvebu/ directory.

As for the previous release, both the Armada 370 and the Armada XP SoCs are supported in this directory, and we are able to build a single kernel image that boots on both SoCs. Both SoCs use the PJ4B processor, a Marvell-developed ARM core that implements the ARMv7 instruction set. We are currently using Marvell evaluation boards for both of those SoCs, and the support for those boards is added in this patch set.

Andrew Lunn asked for refactoring the _restart() function to being used by any MVEBU SOC, but we didn't find a nice way to do it. Indeed the registers mapping differs between the SOC and the bit mask too. A solution could be to get this mapping through the device tree, but we are not sure it was a good usage of the device tree.

Quoted 6 lines · Gregory CLEMENT

You'll find in this patch set the new version of the initial support for a new family of ARMv7-compatible Marvell SoCs initially submitted by my colleague Thomas Petazzoni. Following the conclusion of the discussion when we submitted our first version we have chosen to add this support for this SoC family in the to support in the arch/arm/mach-mvebu/ directory.

Quoted 6 lines

As for the previous release, both the Armada 370 and the Armada XP SoCs are supported in this directory, and we are able to build a single kernel image that boots on both SoCs. Both SoCs use the PJ4B processor, a Marvell-developed ARM core that implements the ARMv7 instruction set. We are currently using Marvell evaluation boards for both of those SoCs, and the support for those boards is added in this patch set.

Ok, very good.

Quoted 5 lines

Andrew Lunn asked for refactoring the _restart() function to being used by any MVEBU SOC, but we didn't find a nice way to do it. Indeed the registers mapping differs between the SOC and the bit mask too. A solution could be to get this mapping through the device tree, but we are not sure it was a good usage of the device tree.

As I suggested in my reply to patch 4/8, I think this can be encapsulated in one file that acts as a driver for the generic ("bridge regs") registers and provides functions for that based on the "compatible" property.

On a more general note, I'd prefer to have the patches renaming the existing files first for the mach-mvebu directory first, and then adding your patches on top.

I can provide a new version of the patch I did once we have agreement on what goes where. I've put some more thought into it and the best I could come up with is now.

arch/arm/mach-{orion5x,dove,kirkwood,mv78xx0}/include/mach/*

	-> arch/arm/mach-mvebu/include/mach/
arch/arm/plat-orion/include/plat/*
	-> arch/arm/mach-mvebu/include/mach/
arch/arm/plat-orion/*
	-> arch/arm/mach-mvebu/
arch/arm/mach-{orion5x,dove,kirkwood,mv78xx0}/{add-map,common,irq,mpp,pci}.*
	-> arch/arm/mach-mvebu/
arch/arm/mach-kirkwood/board-* (DT files)
	-> arch/arm/mach-mvebu/

This is basically the same as the patch I sent out before, but with the new machine name, and leaving all the *-setup.c files in their existing locations, where they can either get removed after being converted to DT or after being assumed dead.

Arnd

arch/arm/mach-kirkwood/board-* (DT files)

	-> arch/arm/mach-mvebu/

Quoted 2 lines

arch/arm/mach-kirkwood/board-* (DT files)

	-> arch/arm/mach-mvebu/

I know of work being done to make orion5x and dove also support DT. Should we consider some sort of prefix or midfix indicating which SoC a board file is for? It will not be easy to mentally keep track of board-ts209.c is an orion5x and board-ts219.c is kirkwood etc.

Quoted 7 lines · Andrew Lunn

Quoted 2 lines

arch/arm/mach-kirkwood/board-* (DT files)

    -> arch/arm/mach-mvebu/

I know of work being done to make orion5x and dove also support DT. Should we consider some sort of prefix or midfix indicating which SoC a board file is for? It will not be easy to mentally keep track of board-ts209.c is an orion5x and board-ts219.c is kirkwood etc.

The board-BOARD.c files are transitional files, and will disappear once the DT conversion is done. All that will remain is board-dt.c. So, there is no long-term issue. Since it's a short term issue, and we're moving/renaming anyway, how about kirkwood-dreamplug.c, orion5x-ts209.c, etc?

Quoted 9 lines · Jason Cooper

Quoted 7 lines · Andrew Lunn

Quoted 2 lines

arch/arm/mach-kirkwood/board-* (DT files)

    -> arch/arm/mach-mvebu/

I know of work being done to make orion5x and dove also support DT. Should we consider some sort of prefix or midfix indicating which SoC a board file is for? It will not be easy to mentally keep track of board-ts209.c is an orion5x and board-ts219.c is kirkwood etc.

Quoted 5 lines

The board-BOARD.c files are transitional files, and will disappear once the DT conversion is done. All that will remain is board-dt.c. So, there is no long-term issue. Since it's a short term issue, and we're moving/renaming anyway, how about kirkwood-dreamplug.c, orion5x-ts209.c, etc?

FWIW, the board-dt.c from mach-kirkwood should just become kirkwood.c and we might want to merge it with the kirkwood common.c file in the long run, if any contents from that file remain for the dt version.

Quoted 4 lines

FWIW, the board-dt.c from mach-kirkwood should just become kirkwood.c and we might want to merge it with the kirkwood common.c file in the long run, if any contents from that file remain for the dt version.

So, there would be an orion5x.c, dove.c as well? Or, should it be mvebu.c to encompass all of them?

Quoted 5 lines

Andrew Lunn asked for refactoring the _restart() function to being used by any MVEBU SOC, but we didn't find a nice way to do it. Indeed the registers mapping differs between the SOC and the bit mask too. A solution could be to get this mapping through the device tree, but we are not sure it was a good usage of the device tree.

As I suggested in my reply to patch 4/8, I think this can be encapsulated in one file that acts as a driver for the generic ("bridge regs") registers and provides functions for that based on the "compatible" property.

Hello Arnd,

Le Tue, 12 Jun 2012 13:49:27 +0000,
Arnd Bergmann <[email protected]> a ?crit :

Quoted 9 lines

Quoted 5 lines

Andrew Lunn asked for refactoring the _restart() function to being used by any MVEBU SOC, but we didn't find a nice way to do it. Indeed the registers mapping differs between the SOC and the bit mask too. A solution could be to get this mapping through the device tree, but we are not sure it was a good usage of the device tree.

As I suggested in my reply to patch 4/8, I think this can be encapsulated in one file that acts as a driver for the generic ("bridge regs") registers and provides functions for that based on the "compatible" property.

The problem here is that those registers are part of a random set of registers, that do not really constitute a sort of coherent "device", as we have for other IP blocks (SATA controllers, SPI controllers, etc.). First of all, the "bridge regs" name was unfortunate and a left-over from early versions of the code, the datasheet does not refer to them as "bridge registers" in any location.

On the Armada 370, the registers needed to restart the machine are part of a "Miscellaneous Registers" section in the list of register sections. This Miscellaneous Registers are 32 bits registers organized as follows:

* SoC Control Register
* SoC Device Mux Register
* Power Management Memory Power Down 2 Register
* Power Management Memory Power Down 3 Register
* Power Management Memory Power Down 4 Register
* Power Management Memory Power Down 5 Register
* Power Management Clock Gating Control Register
* Power Management Memory Power Down 6 Register
* Sample at Reset Register
* Sample at Register High Register
* Device ID Register
* CPU SoC ID Register
* SYSRSTn Length Counter Register
* RSTOUTn Mask Register -- this one needed for restart
* System Soft Reset Register -- this one needed for restart
* Shared SERDES 063 selectors Register
* Boot ROM Routine and Error Code Register
* PCI Express Boot Address Register

This registers are more or less contiguous, from offset 0x18204 to 0x182D4. As you can see, the purpose of those registers are very different from one register to another, so it's kind of odd to create a "driver" that would span those registers.

On the Armada XP, we have a "System Registers" area, subdivided by the datasheet in "Configuration and Control", "QSGMII Control and Status", "SERDES", "Power Management and Memory Power Down", "Thermal Manager", "BootROM", "Interrupt, "Design for Testability". But from an offset/address perspective, some registers of the "Power Management and Memory Power Down" subsection are in the middle of the registers of the "Configuration and Control" registers.

For the restart problem on Armada XP, the two registers of interest are within the "Configuration and Control" subsection.

Our biggest problem is that all those registers do not really match very well with a device/driver representation, so we don't know how to nicely represent them in the device tree. How would you recommend to handle these?

You'll find in this patch set the new version of the initial support for a new family of ARMv7-compatible Marvell SoCs initially submitted by my colleague Thomas Petazzoni. Following the conclusion of the discussion when we submitted our first version we have chosen to add this support for this SoC family in the to support in the arch/arm/mach-mvebu/ directory.

Quoted 5 lines · Gregory CLEMENT

You'll find in this patch set the new version of the initial support for a new family of ARMv7-compatible Marvell SoCs initially submitted by my colleague Thomas Petazzoni. Following the conclusion of the discussion when we submitted our first version we have chosen to add this support for this SoC family in the to support in the arch/arm/mach-mvebu/ directory.

Pardon my silly question. I know that there's an effort to reconcile the two different SoCs so you're picking a neutral name, but what does "mvebu" mean, and will you be persistently keeping this name? Our guys want to know what this new platform will entail for Fedora support in terms of the platform name being used in various non-kernel places.

Quoted 5 lines · Gregory CLEMENT

You'll find in this patch set the new version of the initial support for a new family of ARMv7-compatible Marvell SoCs initially submitted by my colleague Thomas Petazzoni. Following the conclusion of the discussion when we submitted our first version we have chosen to add this support for this SoC family in the to support in the arch/arm/mach-mvebu/ directory.

Pardon my silly question. I know that there's an effort to reconcile the two different SoCs so you're picking a neutral name, but what does "mvebu" mean, and will you be persistently keeping this name? Our guys want to know what this new platform will entail for Fedora support in terms of the platform name being used in various non-kernel places.

Quoted 5 lines · Gregory CLEMENT

You'll find in this patch set the new version of the initial support for a new family of ARMv7-compatible Marvell SoCs initially submitted by my colleague Thomas Petazzoni. Following the conclusion of the discussion when we submitted our first version we have chosen to add this support for this SoC family in the to support in the arch/arm/mach-mvebu/ directory.

Pardon my silly question. I know that there's an effort to reconcile the two different SoCs so you're picking a neutral name, but what does "mvebu" mean, and will you be persistently keeping this name?

Our guys want to know what this new platform will entail for Fedora support in terms of the platform name being used in various non-kernel places.

Quoted 11 lines · Jon Masters

Quoted 5 lines · Gregory CLEMENT

You'll find in this patch set the new version of the initial support for a new family of ARMv7-compatible Marvell SoCs initially submitted by my colleague Thomas Petazzoni. Following the conclusion of the discussion when we submitted our first version we have chosen to add this support for this SoC family in the to support in the arch/arm/mach-mvebu/ directory.

Pardon my silly question. I know that there's an effort to reconcile the two different SoCs so you're picking a neutral name, but what does "mvebu" mean, and will you be persistently keeping this name?

As persistent as anything else is in life ;-P It covers all the SoCs that have come out of Marvell's EBU division. This includes orion5x, kirkwood, dove, mv78xxx, the new armada xp, etc.

We're placing all boards under that umbrella with DT support into mach-mvebu/. Eventually, once DT conversion is complete, the other directories will empty out and mach-mvebu/ will hold all support for those SoCs.

Currently, the only boards with DT support are in mach-kirkwood/: the dreamplug, iconnect, and a few others. Before it gets too out of hand, Arnd has a patch series which consolidates it all into mach-mvebu/.

Quoted 3 lines

Our guys want to know what this new platform will entail for Fedora support in terms of the platform name being used in various non-kernel places.

I'm not familiar with how Fedora does it, but debian has five different

armel kernels, each supporting a range of boards.

linux-image-iop32x
linux-image-ixp4xx
linux-image-kirkwood
linux-image-orion5x
linux-image-versatile

Quoted 5 lines · Gregory CLEMENT

You'll find in this patch set the new version of the initial support for a new family of ARMv7-compatible Marvell SoCs initially submitted by my colleague Thomas Petazzoni. Following the conclusion of the discussion when we submitted our first version we have chosen to add this support for this SoC family in the to support in the arch/arm/mach-mvebu/ directory.

Pardon my silly question. I know that there's an effort to reconcile the two different SoCs so you're picking a neutral name, but what does "mvebu" mean, and will you be persistently keeping this name? Our guys want to know what this new platform will entail for Fedora support in terms of the platform name being used in various non-kernel places.