* [PATCH 3/8] ARM: OMAP2+: clock: fix clkoutx2 with CLK_SET_RATE_PARENT
From: Tomi Valkeinen @ 2014-02-13 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392285846-13199-4-git-send-email-tomi.valkeinen@ti.com>
On 13/02/14 12:04, Tomi Valkeinen wrote:
> If CLK_SET_RATE_PARENT is set for a clkoutx2 clock, calling
> clk_set_rate() on the clock "skips" the x2 multiplier as there are no
> set_rate and round_rate functions defined for the clkoutx2.
>
> This results in getting double the requested clock rates, breaking the
> display on omap3430 based devices.
>
> This patch implements set_rate and round_rate for clkoutx2.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> arch/arm/mach-omap2/cclock3xxx_data.c | 2 ++
> arch/arm/mach-omap2/dpll3xxx.c | 62 +++++++++++++++++++++++++++++++++++
> include/linux/clk/ti.h | 4 +++
> 3 files changed, 68 insertions(+)
Argh. This patch 3/8 was an old version, and not valid. It does not work for
omap3430. I had earlier posted a proper version, but somehow I managed to get
an old version for this series.
The correct version can be found from
http://mid.gmane.org/1391080640-23370-1-git-send-email-tomi.valkeinen at ti.com
and I'll also include it below.
Tomi
>From 0d46054a8b33bc1f7a37bc9b17dd1631b1a06047 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date: Thu, 30 Jan 2014 13:17:20 +0200
Subject: [PATCH] ARM: OMAP2+: clock: fix clkoutx2 with CLK_SET_RATE_PARENT
If CLK_SET_RATE_PARENT is set for a clkoutx2 clock, calling
clk_set_rate() on the clock "skips" the x2 multiplier as there are no
set_rate and round_rate functions defined for the clkoutx2.
This results in getting double the requested clock rates, breaking the
display on omap3430 based devices. This got broken when
d0f58bd3bba3877fb1af4664c4e33273d36f00e4 and related patches were merged
for v3.14, as omapdss driver now relies more on the clk-framework and
CLK_SET_RATE_PARENT.
This patch implements set_rate and round_rate for clkoutx2.
Tested on OMAP3430, OMAP3630, OMAP4460.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/cclock3xxx_data.c | 2 +
arch/arm/mach-omap2/dpll3xxx.c | 92 +++++++++++++++++++++++++++++------
include/linux/clk/ti.h | 4 ++
3 files changed, 83 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c b/arch/arm/mach-omap2/cclock3xxx_data.c
index 3b05aea56d1f..11ed9152e665 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -433,7 +433,9 @@ static const struct clk_ops dpll4_m5x2_ck_ops = {
.enable = &omap2_dflt_clk_enable,
.disable = &omap2_dflt_clk_disable,
.is_enabled = &omap2_dflt_clk_is_enabled,
+ .set_rate = &omap3_clkoutx2_set_rate,
.recalc_rate = &omap3_clkoutx2_recalc,
+ .round_rate = &omap3_clkoutx2_round_rate,
};
static const struct clk_ops dpll4_m5x2_ck_3630_ops = {
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index 3185ced807c9..3c418ea54bbe 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -623,6 +623,32 @@ void omap3_dpll_deny_idle(struct clk_hw_omap *clk)
/* Clock control for DPLL outputs */
+/* Find the parent DPLL for the given clkoutx2 clock */
+static struct clk_hw_omap *omap3_find_clkoutx2_dpll(struct clk_hw *hw)
+{
+ struct clk_hw_omap *pclk = NULL;
+ struct clk *parent;
+
+ /* Walk up the parents of clk, looking for a DPLL */
+ do {
+ do {
+ parent = __clk_get_parent(hw->clk);
+ hw = __clk_get_hw(parent);
+ } while (hw && (__clk_get_flags(hw->clk) & CLK_IS_BASIC));
+ if (!hw)
+ break;
+ pclk = to_clk_hw_omap(hw);
+ } while (pclk && !pclk->dpll_data);
+
+ /* clk does not have a DPLL as a parent? error in the clock data */
+ if (!pclk) {
+ WARN_ON(1);
+ return NULL;
+ }
+
+ return pclk;
+}
+
/**
* omap3_clkoutx2_recalc - recalculate DPLL X2 output virtual clock rate
* @clk: DPLL output struct clk
@@ -637,27 +663,14 @@ unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
unsigned long rate;
u32 v;
struct clk_hw_omap *pclk = NULL;
- struct clk *parent;
if (!parent_rate)
return 0;
- /* Walk up the parents of clk, looking for a DPLL */
- do {
- do {
- parent = __clk_get_parent(hw->clk);
- hw = __clk_get_hw(parent);
- } while (hw && (__clk_get_flags(hw->clk) & CLK_IS_BASIC));
- if (!hw)
- break;
- pclk = to_clk_hw_omap(hw);
- } while (pclk && !pclk->dpll_data);
+ pclk = omap3_find_clkoutx2_dpll(hw);
- /* clk does not have a DPLL as a parent? error in the clock data */
- if (!pclk) {
- WARN_ON(1);
+ if (!pclk)
return 0;
- }
dd = pclk->dpll_data;
@@ -672,6 +685,55 @@ unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
return rate;
}
+int omap3_clkoutx2_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ return 0;
+}
+
+long omap3_clkoutx2_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *prate)
+{
+ const struct dpll_data *dd;
+ u32 v;
+ struct clk_hw_omap *pclk = NULL;
+
+ if (!*prate)
+ return 0;
+
+ pclk = omap3_find_clkoutx2_dpll(hw);
+
+ if (!pclk)
+ return 0;
+
+ dd = pclk->dpll_data;
+
+ /* TYPE J does not have a clkoutx2 */
+ if (dd->flags & DPLL_J_TYPE) {
+ *prate = __clk_round_rate(__clk_get_parent(pclk->hw.clk), rate);
+ return *prate;
+ }
+
+ WARN_ON(!dd->enable_mask);
+
+ v = omap2_clk_readl(pclk, dd->control_reg) & dd->enable_mask;
+ v >>= __ffs(dd->enable_mask);
+
+ /* If in bypass, the rate is fixed to the bypass rate*/
+ if (v != OMAP3XXX_EN_DPLL_LOCKED)
+ return *prate;
+
+ if (__clk_get_flags(hw->clk) & CLK_SET_RATE_PARENT) {
+ unsigned long best_parent;
+
+ best_parent = (rate / 2);
+ *prate = __clk_round_rate(__clk_get_parent(hw->clk),
+ best_parent);
+ }
+
+ return *prate * 2;
+}
+
/* OMAP3/4 non-CORE DPLL clkops */
const struct clk_hw_omap_ops clkhwops_omap3_dpll = {
.allow_idle = omap3_dpll_allow_idle,
diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h
index 092b64168d7f..4a21a872dbbd 100644
--- a/include/linux/clk/ti.h
+++ b/include/linux/clk/ti.h
@@ -245,6 +245,10 @@ long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long target_rate,
void omap2_init_clk_clkdm(struct clk_hw *clk);
unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
unsigned long parent_rate);
+int omap3_clkoutx2_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate);
+long omap3_clkoutx2_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *prate);
int omap2_clkops_enable_clkdm(struct clk_hw *hw);
void omap2_clkops_disable_clkdm(struct clk_hw *hw);
int omap2_clk_disable_autoidle_all(void);
--
1.8.3.2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140213/1f45fc18/attachment.sig>
^ permalink raw reply related
* [PATCH 4/4] phy: miphy365x: Provide support for the MiPHY356x Generic PHY
From: Lee Jones @ 2014-02-13 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212165454.GF25957@e106331-lin.cambridge.arm.com>
> > The MiPHY365x is a Generic PHY which can serve various SATA or PCIe
> > devices. It has 2 ports which it can use for either; both SATA, both
> > PCIe or one of each in any configuration.
> >
> > Cc: Kishon Vijay Abraham I <kishon@ti.com>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> > drivers/phy/Kconfig | 8 +
> > drivers/phy/Makefile | 1 +
> > drivers/phy/phy-miphy365x.c | 634 ++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 643 insertions(+)
> > create mode 100644 drivers/phy/phy-miphy365x.c
> >
>
> [...]
>
> > +static int miphy365x_phy_get_base_addr(struct platform_device *pdev,
> > + struct miphy365x_phy *phy, u8 port)
> > +{
> > + struct resource *res;
> > + char sata[16];
> > + char pcie[16];
>
> Isn't 6 enough for either of these? There are at most two ports IIUC, so
> we only need a single character for the port number.
Yep, being a bit overzealous there, will fix.
<snip>
> > +
> > + of_property_read_string(np, "st,sata_gen", &sata_gen);
>
> This wasn't in the binding documentation. It also violates dt style;
> s/_/-/
No problem, will fix.
> Could these not be numbers, or can this not come from elsewhere?
>
> Or are there some crazy SATA generations to support?
Nope, just [1|2|3] I think. Can be numbers, will fix.
> > + if (sata_gen) {
> > + if (!strcmp(sata_gen, "gen3"))
> > + phy_dev->sata_gen = SATA_GEN3;
> > + else if (!strcmp(sata_gen, "gen2"))
> > + phy_dev->sata_gen = SATA_GEN2;
> > + }
> > +
> > + phy_dev->pcie_tx_pol_inv =
> > + of_property_read_bool(np, "st,pcie_tx_pol_inv");
> > +
> > + phy_dev->sata_tx_pol_inv =
> > + of_property_read_bool(np, "st,sata_tx_pol_inv");
>
> Likewise for both of these on the first two points.
1. Roger will fix.
2. Not probeable I'm afraid.
> > +
> > + return 0;
> > +}
> > +
> > +static int miphy365x_phy_probe(struct platform_device *pdev)
> > +{
> > + struct device_node *np = pdev->dev.of_node;
> > + struct miphy365x_dev *phy_dev;
> > + struct device *dev = &pdev->dev;
> > + struct phy_provider *provider;
> > + u8 port;
> > + int ret;
> > +
> > + if (!np) {
> > + dev_err(dev, "No DT found\n");
>
> s/DT/node/ ?
s/DT/DT node/
Will fix, thanks.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v2 02/10] ARM: mvebu: add initial support for the Armada 375 SOCs
From: Thomas Petazzoni @ 2014-02-13 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3797172.YJcGPMeT5Y@wuerfel>
Dear Arnd Bergmann,
On Wed, 12 Feb 2014 14:08:42 +0100, Arnd Bergmann wrote:
> On Wednesday 12 February 2014 11:23:31 Thomas Petazzoni wrote:
> > From: Gregory CLEMENT <gregory.clement@free-electrons.com>
> >
> > This commit adds the basic support for the Armada 375 SOCs. These SoCs
> > share most of their IP with the Armada 370/XP SoCs. The main
> > difference is the use of a Cortex A9 CPU instead of the PJ4B CPU. The
> > interrupt controller and the L2 cache controller are also different
> > they are respectively the GIC and the PL310.
> >
> > Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> > ---
> > .../devicetree/bindings/arm/armada-375.txt | 9 +++++
> > arch/arm/mach-mvebu/Kconfig | 15 ++++++++
> > arch/arm/mach-mvebu/Makefile | 1 +
> > arch/arm/mach-mvebu/armada-375.c | 44 ++++++++++++++++++++++
>
> I don't know what the outcome was for the first version, but just
> for the record, I would prefer merging the board file into armada-370-xp.c
> without renaming that file. Keeping the separate Kconfig entry makes sense
> because we want to select different options there. If you have differences
> between the implementations (so far the 370/xp code should just work
> on 375), you can use a combination of if(IS_ENABLED(CONFIG_*)) and
> if(machine_is_compatible()) to do the detection but keep a common
> dt_compat list.
Thanks for your review! I will shortly post a new version that uses a
single "board file" (even though "board file" is a somewhat odd name in
this DT era!).
However, I've kept separate dt_compat lists, because we will need
different SMP operations between Armada 370/XP (which are PJ4B based)
and Armada 375/38x (which are Cortex-A9 based).
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 03/10] ARM: mvebu: add workaround for data abort issue on Armada 375
From: Thomas Petazzoni @ 2014-02-13 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2289743.0TLVompA6m@wuerfel>
Dear Arnd Bergmann,
On Wed, 12 Feb 2014 14:10:35 +0100, Arnd Bergmann wrote:
> On Wednesday 12 February 2014 11:23:32 Thomas Petazzoni wrote:
> > +/*
> > + * Early versions of Armada 375 SoC have a bug where the BootROM
> > + * leaves an external data abort pending. The kernel is hit by this
> > + * data abort as soon as it enters userspace, because it unmasks the
> > + * data aborts at this moment. We register a custom abort handler
> > + * below to ignore the first data abort to work around this problem.
> > + */
> > +static int armada_375_external_abort_wa(unsigned long addr, unsigned int fsr,
> > + struct pt_regs *regs)
> > +{
> > + static int ignore_first;
> > +
> > + if (!ignore_first) {
> > + ignore_first = 1;
> > + return 0;
> > + }
> > +
> > + return 1;
> > +}
>
> I think this should try to match the fsr and addr field if possible and
> only ignore the one external abort you expect.
I've added a check on fsr. Checking addr is not possible, because the
address changes from one boot to another. I must say I don't really
know the details of the BootROM code that leaves this data abort
pending, but it looks like the address that triggers the data abort is
not always the same.
Thanks for your review!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 05/10] ARM: mvebu: add Device Tree for the Armada 375 DB board
From: Thomas Petazzoni @ 2014-02-13 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2335694.A7tsOBXSlH@wuerfel>
Dear Arnd Bergmann,
On Wed, 12 Feb 2014 14:12:27 +0100, Arnd Bergmann wrote:
> On Wednesday 12 February 2014 11:23:34 Thomas Petazzoni wrote:
> > + i2c0: i2c at 11000 {
> > + status = "okay";
> > + clock-frequency = <100000>;
> > + pinctrl-0 = <&i2c0_pins>;
> > + pinctrl-names = "default";
> > + };
> > +
> > + i2c1: i2c at 11100 {
> > + status = "okay";
> > + clock-frequency = <100000>;
> > + pinctrl-0 = <&i2c1_pins>;
> > + pinctrl-names = "default";
> > + };
>
> I think you should either use the label to reference the node here,
> or omit it in the board.dts file. There is no point in defining
> multiple identical labels.
Indeed, good point. Will be fixed in v3.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 4/6] ARM: firmware: add prepare_idle() operation
From: Tomasz Figa @ 2014-02-13 11:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391747706-1847-5-git-send-email-acourbot@nvidia.com>
Hi Alexandre,
On 07.02.2014 05:35, Alexandre Courbot wrote:
> Some firmwares do not put the CPU into idle mode themselves, but still
> need to be informed that the CPU is about to enter idle mode before this
> happens. Add a prepare_idle() operation to the firmware_ops structure to
> handle such cases.
>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
> arch/arm/include/asm/firmware.h | 4 ++++
> 1 file changed, 4 insertions(+)
I wonder if .do_idle() couldn't simply return an appropriate error code
to let the upper layer know that it should proceed with normal CPU idle
activation, while still letting the firmware know that the CPU is going
to idle.
Best regards,
Tomasz
^ permalink raw reply
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
From: Lee Jones @ 2014-02-13 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212164019.GE25957@e106331-lin.cambridge.arm.com>
> > The MiPHY365x is a Generic PHY which can serve various SATA or PCIe
> > devices. It has 2 ports which it can use for either; both SATA, both
> > PCIe or one of each in any configuration.
> >
> > Cc: devicetree at vger.kernel.org
> > Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> > .../devicetree/bindings/phy/phy-miphy365x.txt | 43 ++++++++++++++++++++++
> > 1 file changed, 43 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> >
> > diff --git a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> > new file mode 100644
> > index 0000000..fdfa7ca
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> > @@ -0,0 +1,43 @@
> > +STMicroelectronics STi MIPHY365x PHY binding
> > +============================================
> > +
> > +This binding describes a miphy device that is used to control PHY hardware
> > +for SATA and PCIe.
> > +
> > +Required properties:
> > +- compatible: Should be "st,miphy365x-phy"
> > +- #phy-cells: Should be 2 (See example)
>
> The first example has #phy-cells = <1>.
Right, will fix. Should be 2.
> What do the cells mean? What are the expected values?
http://www.spinics.net/lists/arm-kernel/msg307209.html
> > +- reg: Address and length of the register set for the device
> > +- reg-names: The names of the register addresses corresponding to the
> > + registers filled in "reg".
>
> Whenever there is a ${PROP}-names property, there should be a list of
> explicit values, and a description of how it relates to ${PROP}. Without
> that it's a bit useless.
>
> Please provide an explicit list of expected names here.
>
> I assume here what you want is something like:
>
> - reg: a list of address + length pairs, one for each entry in reg-names
> - reg-names: should contain:
> * "sata0" for the sata0 control registers...
> * "sata1" ...
> * "pcie0" ...
> * "pcie1" ...
Can do.
> > +- st,syscfg : Should be a phandle of the syscfg node.
>
> What's this used for?
It's used to gain access to the system configuration
registers. Specifically in this case the bits to choose between PCI or
SATA mode.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v2 3/3] PCI: ARM: add support for generic PCI host controller
From: Will Deacon @ 2014-02-13 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1645474.vdytZl6znf@wuerfel>
Hi Arnd,
Thanks again for the comments.
On Wed, Feb 12, 2014 at 08:59:46PM +0000, Arnd Bergmann wrote:
> On Wednesday 12 February 2014 20:16:11 Will Deacon wrote:
> > +- ranges : As described in IEEE Std 1275-1994, but must provide
> > + at least a definition of one or both of IO and Memory
> > + Space.
>
> I'd say *must* provide at least non-prefetchable memory. *may* provide
> prefetchable memory and/or I/O space.
Can do. Should I enforce this in the driver too? (i.e. complain if
non-prefetchable memory is absent).
> > +Interrupt mapping is exactly as described in `Open Firmware Recommended
> > +Practice: Interrupt Mapping' and requires the following properties:
> > +
> > +- #interrupt-cells : Must be 1
> > +
> > +- interrupt-map : <see aforementioned specification>
> > +
> > +- interrupt-map-mask : <see aforementioned specification>
>
> We probably want to add an optional 'bus-range' property (the default being
> <0 255> if absent), so we don't have to map all the config space.
Yes, and that will be important given your comments later on.
> > diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> > index 47d46c6d8468..491d74c36f6a 100644
> > --- a/drivers/pci/host/Kconfig
> > +++ b/drivers/pci/host/Kconfig
> > @@ -33,4 +33,11 @@ config PCI_RCAR_GEN2
> > There are 3 internal PCI controllers available with a single
> > built-in EHCI/OHCI host controller present on each one.
> >
> > +config PCI_ARM_GENERIC
> > + bool "ARM generic PCI host controller"
> > + depends on ARM && OF
> > + help
> > + Say Y here if you want to support a simple generic PCI host
> > + controller, such as the one emulated by kvmtool.
> > +
> > endmenu
>
> Looks good for now. In the long run, I'd hope to get rid of the 'ARM'
> part here and make it work on any architecture, but that requires
> significant work that we should not depend on here.
Agreed. arm64 is the obvious next target (once Liviu's series is sorted out
-- I'm currently using a simplified port of bios32.c for testing).
> > +struct gen_pci_cfg_window {
> > + u64 cpu_phys;
> > + void __iomem *base;
> > + u8 bus;
> > + spinlock_t lock;
> > + const struct gen_pci_cfg_accessors *accessors;
> > +};
> > +
> > +struct gen_pci_resource {
> > + struct list_head list;
> > + struct resource cpu_res;
> > + resource_size_t offset;
> > +};
>
> Your gen_pci_resource is actually identical to struct pci_host_bridge_window,
> which I guess is coincidence, but it would be nice to actually use
> the standard structure to make it easier to integrate with common
> infrastructure later.
Ha, at least I managed to come up with the same struct! I'll move to the
generic version.
> > +
> > +struct gen_pci {
> > + struct device *dev;
> > + struct resource *io_res;
> > + struct list_head mem_res;
> > + struct gen_pci_cfg_window cfg;
> > +};
>
> How about making this structure derived from pci_host_bridge?
> That would already contain a lot of the members, and gets two things
> right:
>
> * it's useful to have an embedded 'struct device' here, and use dev->parent
> to point to the device from DT
> * for I/O, we actually want a pci_host_bridge_window, not just a resource,
> since we should keep track of the offset
Sure. Also, if we kill nr_controllers, then we can have a simple I/O space
allocator to populate the offset.
> > +static void __iomem *gen_pci_map_cfg_bus_ecam(struct pci_bus *bus,
> > + unsigned int devfn,
> > + int where)
> > +{
> > + struct pci_sys_data *sys = bus->sysdata;
> > + struct gen_pci *pci = sys->private_data;
> > + u32 busn = bus->number;
> > +
> > + spin_lock(&pci->cfg.lock);
> > + if (pci->cfg.bus != busn) {
> > + resource_size_t offset;
> > +
> > + devm_iounmap(pci->dev, pci->cfg.base);
> > + offset = pci->cfg.cpu_phys + (busn << 20);
> > + pci->cfg.base = devm_ioremap(pci->dev, offset, SZ_1M);
> > + pci->cfg.bus = busn;
> > + }
> > +
> > + return pci->cfg.base + ((devfn << 12) | where);
> > +}
>
> Nice idea, but unfortunately broken: we need config space access from
> atomic context, since there are drivers doing that.
That aside, I just took a spin_lock so this needs fixing regardless. The
only solution I can think of then is to map all of the buses at setup time
(making bus_ranges pretty important) and hope that I don't chew through all
of vmalloc.
> > +static int gen_pci_probe(struct platform_device *pdev)
> > +{
> > + struct hw_pci hw;
> > + struct of_pci_range range;
> > + struct of_pci_range_parser parser;
> > + struct gen_pci *pci;
> > + const __be32 *reg;
> > + const struct of_device_id *of_id;
> > + struct device *dev = &pdev->dev;
> > + struct device_node *np = dev->of_node;
>
> Could you try to move almost all of this function into gen_pci_setup()?
> I suspect this will make it easier later to share this driver with other
> architectures.
I'll take a look. If we get rid of nr_controllers, as suggested later on,
the line between probe and setup is somewhat blurred.
> > +
> > + hw = (struct hw_pci) {
> > + .nr_controllers = 1,
> > + .private_data = (void **)&pci,
> > + .setup = gen_pci_setup,
> > + .map_irq = of_irq_parse_and_map_pci,
> > + .ops = &gen_pci_ops,
> > + };
> > +
> > + pci_common_init_dev(dev, &hw);
> > + return 0;
> > +}
>
> A missing part here seems to be a way to propagate errors from
> the pci_common_init_dev or gen_pci_setup back to the caller.
>
> This seems to be a result of the arm pcibios implementation not
> being meant for loadable modules, but I suspect it can be fixed.
> The nr_controllers>1 logic gets a bit in the way there, but it's
> also a model that seems to be getting out of fashion:
> kirkwood/dove/orion5x/mv78xx0 use it at the moment, but are
> migrating over to the new pci-mvebu code that doesn't as they
> get rid of the non-DT probing. pci-rcar-gen2.c uses it, but it
> seems they already ran into problems with that and are changing
> it. That pretty much leaves iop13xx as the only user, but at
> that point we can probably move the loop into iop13xx specific
> code.
Makes sense once there are no users of the field.
Will
^ permalink raw reply
* [PATCH v3 00/13] Core support for Marvell Armada 375 and 38x
From: Thomas Petazzoni @ 2014-02-13 11:04 UTC (permalink / raw)
To: linux-arm-kernel
Jason, Andrew, Sebastian, Gregory,
Here comes the v3 of the Armada 375/38x core support.
Changes since v2
================
* Integrated the support of Armada 375 and Armada 38x in the same
"board file" as Armada 370/XP, as suggested by Arnd Bergmann. In
order to achieve this, I've renamed armada-370-xp.c to
armada-mvebu.c, and done corresponding minor cleanups before
introducing Armada 375/38x support.
* Made the data abort workaround check for a specific FSR value, as
suggested by Arnd Bergmann. Checking for the address is not
possible, because it changes from one boot to the other.
* Removed unnecessary duplicated aliases for i2c and spi nodes
(between .dtsi and .dts). Requested by Arnd Bergmann.
* Added aliases for network interfaces, like we already have for
Armada 370 and XP.
Changes since v1
================
* Merged armada-375.c and armada-38x.c into one file, as suggested by
Andrew Lunn.
* Do not require the introduction of new compatible strings in the
drivers for the timer, mbus and the 38x system controller (the 375
system controller being different, adding a different compatible
string is needed). The .dtsi files have been updated to use several
compatible strings: one designating the new SoC, and another one
designating the older SoC with which they are compatible as far as
we know today. Suggested by Jason Cooper and confirmed by Grant
Likely.
* Rename the Kconfig symbol from MACH_ARMADA_380 to MACH_ARMADA_38X,
as suggested by Andrew Lunn.
* Use <dt-bindings/gpio/gpio.h> defines instead of hardcoded values
in armada-375-db.dts. Suggested by Andrew Lunn.
Original cover letter
=====================
Here is a set of 11 patches that add minimal support for the new
Marvell Armada 375 and 38x SoCs. The Armada 375 has already been
announced a few months ago by Marvell, and a product brief is
available at
http://www.marvell.com/embedded-processors/armada-375/. As far as I
know, the Armada 380 and 385 have not yet been announced, but we
already have working kernel support for them.
Essentially, the Armada 375 is a dual-core Cortex-A9, which re-uses
most of the IP blocks of the Armada XP, except for the network unit
and core parts of the SoC, such as the interrupt controller or cache
controller (GIC and PL310 are used). They also added an XHCI USB 3.0
controller.
The Armada 380 and 385 also use Cortex-A9 CPU cores (single core for
the 380 and dual-core for the 385), but move a little further away
than 375 in terms of peripherals: an AHCI-compatible SATA interface, a
different MMC/SDIO interface, etc.
This set of patches only add minimal support for these SOCs, as well
as support for the peripherals for which no driver changes are
needed. We therefore have support for:
* Device Bus
* Clocks
* Interrupt controllers: GIC and MPIC
* GPIO controllers
* I2C buses
* SPI buses
* L2 cache
* MBus controller
* SDIO (for Armada 375 only)
* Pinctrl
* SATA (for Armada 375 only)
* Serial
* System controller
* XOR engines
* PCIe controllers
* Network (for Armada 38x only)
Some of these features require patches to other subsystems, and the
patches are being sent to the respective maintainers currently: clock
driver patches, pinctrl driver patches, irqchip driver patches, mbus
driver patches, etc. There is however no build dependency between the
arch/arm/mach-mvebu/ code and those other patches.
We aim at getting this minimal support merged for 3.15.
We have already working code for many more features, such as SMP,
coherency support, NAND, SATA and SDIO for Armada 380, etc. We will be
sending those additional features once the basic support has been
merged.
It is worth noting that contrary to the Marvell 370 and XP support,
which has been pushed mainline fairly late in the development cycle of
the SOCs, the support for Armada 375 and 38x is now being pushed quite
early in the development cycle of the SOCs. We are having mainline
support pretty much at the same time as the SOCs are being made
available to customers, which is really great!
Best regards,
Thomas
Gregory CLEMENT (2):
ARM: mvebu: add initial support for the Armada 375 SOCs
ARM: mvebu: add Device Tree description of the Armada 375 SoC
Thomas Petazzoni (11):
ARM: mvebu: rename armada-370-xp.c to armada-mvebu.c
ARM: mvebu: rename DT machine structure for Armada 370/XP
ARM: mvebu: make CPU_PJ4B selection a per-SoC choice
ARM: mvebu: add Armada 375 support to the system-controller driver
ARM: mvebu: add workaround for data abort issue on Armada 375
ARM: mvebu: add Device Tree for the Armada 375 DB board
ARM: mvebu: add initial support for the Armada 380/385 SOCs
ARM: mvebu: add Device Tree description of the Armada 380/385 SoCs
ARM: mvebu: add Device Tree for the Armada 385 DB board
ARM: mvebu: update defconfigs for Armada 375 and 38x
Documentation: arm: update Marvell documentation about Armada 375/38x
Documentation/arm/Marvell/README | 12 +-
.../devicetree/bindings/arm/armada-375.txt | 9 +
.../devicetree/bindings/arm/armada-38x.txt | 10 +
.../bindings/arm/mvebu-system-controller.txt | 3 +-
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/armada-375-db.dts | 107 +++++
arch/arm/boot/dts/armada-375.dtsi | 439 +++++++++++++++++++++
arch/arm/boot/dts/armada-380.dtsi | 117 ++++++
arch/arm/boot/dts/armada-385-db.dts | 101 +++++
arch/arm/boot/dts/armada-385.dtsi | 149 +++++++
arch/arm/boot/dts/armada-38x.dtsi | 345 ++++++++++++++++
arch/arm/configs/multi_v7_defconfig | 2 +
arch/arm/configs/mvebu_defconfig | 2 +
arch/arm/mach-mvebu/Kconfig | 37 +-
arch/arm/mach-mvebu/Makefile | 2 +-
.../mach-mvebu/{armada-370-xp.c => armada-mvebu.c} | 62 ++-
arch/arm/mach-mvebu/system-controller.c | 14 +-
17 files changed, 1397 insertions(+), 16 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/armada-375.txt
create mode 100644 Documentation/devicetree/bindings/arm/armada-38x.txt
create mode 100644 arch/arm/boot/dts/armada-375-db.dts
create mode 100644 arch/arm/boot/dts/armada-375.dtsi
create mode 100644 arch/arm/boot/dts/armada-380.dtsi
create mode 100644 arch/arm/boot/dts/armada-385-db.dts
create mode 100644 arch/arm/boot/dts/armada-385.dtsi
create mode 100644 arch/arm/boot/dts/armada-38x.dtsi
rename arch/arm/mach-mvebu/{armada-370-xp.c => armada-mvebu.c} (57%)
--
1.8.3.2
^ permalink raw reply
* [PATCH v3 01/13] ARM: mvebu: rename armada-370-xp.c to armada-mvebu.c
From: Thomas Petazzoni @ 2014-02-13 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392289475-8902-1-git-send-email-thomas.petazzoni@free-electrons.com>
In preparation to the introduction of the support of Armada 375 and
Armada 38x, this commit renames arch/arm/mach-mvebu/armada-370-xp.c to
arch/arm/mach-mvebu/armada-mvebu.c. The armada-mvebu.c name was chosen
because:
* As we are going to merge the support for Kirkwood and Dove into
mach-mvebu, there will be other files with DT_MACHINE_START
structures, so a generic name such as board-dt.c or mvebu.c does
not work.
* A simple armada.c does not work, because there are Marvell Armada
SOCs that are not part of the MVEBU family. For example, the
Marvell Armada 1500 are part of the mach-berlin family, which is a
completely separate line of SOCs.
In relation to this file rename, this commit also:
* Renames the hidden Kconfig symbol MACH_ARMADA_370_XP to
MACH_ARMADA_MVEBU. This hidden symbol is selected by the various
per-SoC visible Kconfig options to trigger the build of
armada-mvebu.c.
* Renames a certain number of functions in armada-mvebu.c so that
their armada_370_xp prefix is replaced by a armada_mvebu
prefix. The .dt_compat array keeps its armada_370_xp prefix because
the new SOCs will be introduced with separate .dt_compat arrays,
due to the need for different SMP operations.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
Jason, this commit will create a trivial conflict with the patch that
removed armada_370_xp_map_io(), which I submitted a few days. The
conflict should be easy to resolve (simply remove the ->map_io
function).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/mach-mvebu/Kconfig | 6 +++---
arch/arm/mach-mvebu/Makefile | 2 +-
arch/arm/mach-mvebu/{armada-370-xp.c => armada-mvebu.c} | 12 ++++++------
3 files changed, 10 insertions(+), 10 deletions(-)
rename arch/arm/mach-mvebu/{armada-370-xp.c => armada-mvebu.c} (89%)
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 5e269d7..35ef594 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -21,7 +21,7 @@ if ARCH_MVEBU
menu "Marvell SOC with device tree"
-config MACH_ARMADA_370_XP
+config MACH_ARMADA_MVEBU
bool
select ARMADA_370_XP_TIMER
select HAVE_SMP
@@ -31,7 +31,7 @@ config MACH_ARMADA_370_XP
config MACH_ARMADA_370
bool "Marvell Armada 370 boards"
select ARMADA_370_CLK
- select MACH_ARMADA_370_XP
+ select MACH_ARMADA_MVEBU
select PINCTRL_ARMADA_370
help
Say 'Y' here if you want your kernel to support boards based
@@ -40,7 +40,7 @@ config MACH_ARMADA_370
config MACH_ARMADA_XP
bool "Marvell Armada XP boards"
select ARMADA_XP_CLK
- select MACH_ARMADA_370_XP
+ select MACH_ARMADA_MVEBU
select PINCTRL_ARMADA_XP
help
Say 'Y' here if you want your kernel to support boards based
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index 878aebe..4386094 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -4,7 +4,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \
AFLAGS_coherency_ll.o := -Wa,-march=armv7-a
obj-y += system-controller.o mvebu-soc-id.o
-obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o
+obj-$(CONFIG_MACH_ARMADA_MVEBU) += armada-mvebu.o
obj-$(CONFIG_ARCH_MVEBU) += coherency.o coherency_ll.o pmsu.o
obj-$(CONFIG_SMP) += platsmp.o headsmp.o
obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-mvebu.c
similarity index 89%
rename from arch/arm/mach-mvebu/armada-370-xp.c
rename to arch/arm/mach-mvebu/armada-mvebu.c
index f6c9d1d..40e3a4d 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-mvebu.c
@@ -31,12 +31,12 @@
#include "coherency.h"
#include "mvebu-soc-id.h"
-static void __init armada_370_xp_map_io(void)
+static void __init armada_mvebu_map_io(void)
{
debug_ll_io_init();
}
-static void __init armada_370_xp_timer_and_clk_init(void)
+static void __init armada_mvebu_timer_and_clk_init(void)
{
of_clk_init(NULL);
clocksource_of_init();
@@ -75,7 +75,7 @@ static void __init i2c_quirk(void)
return;
}
-static void __init armada_370_xp_dt_init(void)
+static void __init armada_mvebu_dt_init(void)
{
if (of_machine_is_compatible("plathome,openblocks-ax3-4"))
i2c_quirk();
@@ -89,9 +89,9 @@ static const char * const armada_370_xp_dt_compat[] = {
DT_MACHINE_START(ARMADA_XP_DT, "Marvell Armada 370/XP (Device Tree)")
.smp = smp_ops(armada_xp_smp_ops),
- .init_machine = armada_370_xp_dt_init,
- .map_io = armada_370_xp_map_io,
- .init_time = armada_370_xp_timer_and_clk_init,
+ .init_machine = armada_mvebu_dt_init,
+ .map_io = armada_mvebu_map_io,
+ .init_time = armada_mvebu_timer_and_clk_init,
.restart = mvebu_restart,
.dt_compat = armada_370_xp_dt_compat,
MACHINE_END
--
1.8.3.2
^ permalink raw reply related
* [PATCH v3 02/13] ARM: mvebu: rename DT machine structure for Armada 370/XP
From: Thomas Petazzoni @ 2014-02-13 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392289475-8902-1-git-send-email-thomas.petazzoni@free-electrons.com>
Due to a mistake made when merging Armada 370 and Armada XP DT machine
structures, the name of the structure was incorrectly chosen as being
ARMADA_XP_DT, while the structure also covers Armada 370. Therefore,
we rename the structure to ARMADA_370_XP_DT.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/mach-mvebu/armada-mvebu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-mvebu/armada-mvebu.c b/arch/arm/mach-mvebu/armada-mvebu.c
index 40e3a4d..18fbb32 100644
--- a/arch/arm/mach-mvebu/armada-mvebu.c
+++ b/arch/arm/mach-mvebu/armada-mvebu.c
@@ -87,7 +87,7 @@ static const char * const armada_370_xp_dt_compat[] = {
NULL,
};
-DT_MACHINE_START(ARMADA_XP_DT, "Marvell Armada 370/XP (Device Tree)")
+DT_MACHINE_START(ARMADA_370_XP_DT, "Marvell Armada 370/XP (Device Tree)")
.smp = smp_ops(armada_xp_smp_ops),
.init_machine = armada_mvebu_dt_init,
.map_io = armada_mvebu_map_io,
--
1.8.3.2
^ permalink raw reply related
* [PATCH v3 03/13] ARM: mvebu: make CPU_PJ4B selection a per-SoC choice
From: Thomas Petazzoni @ 2014-02-13 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392289475-8902-1-git-send-email-thomas.petazzoni@free-electrons.com>
Until now, the CPU_PJ4B Kconfig option was selected by
MACH_ARMADA_MVEBU, i.e for all Armada MVEBU SOCs. In preparation to
the introduction of Cortex-A9 based Armada MVEBU SOCs, this selection
is moved down to the Armada 370 and Armada XP specific options.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/mach-mvebu/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 35ef594..c934f92 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -26,11 +26,11 @@ config MACH_ARMADA_MVEBU
select ARMADA_370_XP_TIMER
select HAVE_SMP
select CACHE_L2X0
- select CPU_PJ4B
config MACH_ARMADA_370
bool "Marvell Armada 370 boards"
select ARMADA_370_CLK
+ select CPU_PJ4B
select MACH_ARMADA_MVEBU
select PINCTRL_ARMADA_370
help
@@ -40,6 +40,7 @@ config MACH_ARMADA_370
config MACH_ARMADA_XP
bool "Marvell Armada XP boards"
select ARMADA_XP_CLK
+ select CPU_PJ4B
select MACH_ARMADA_MVEBU
select PINCTRL_ARMADA_XP
help
--
1.8.3.2
^ permalink raw reply related
* [PATCH v3 04/13] ARM: mvebu: add Armada 375 support to the system-controller driver
From: Thomas Petazzoni @ 2014-02-13 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392289475-8902-1-git-send-email-thomas.petazzoni@free-electrons.com>
The system controller block in the Armada 375 has different register
offsets for the system reset and other related functions. Therefore,
this commit introduces the new "armada-375-system-controller"
compatible string to identify the Armada 375 variant of the system
controller.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
.../devicetree/bindings/arm/mvebu-system-controller.txt | 3 ++-
arch/arm/mach-mvebu/system-controller.c | 14 ++++++++++++--
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/mvebu-system-controller.txt b/Documentation/devicetree/bindings/arm/mvebu-system-controller.txt
index 081c6a7..d24ab2e 100644
--- a/Documentation/devicetree/bindings/arm/mvebu-system-controller.txt
+++ b/Documentation/devicetree/bindings/arm/mvebu-system-controller.txt
@@ -1,12 +1,13 @@
MVEBU System Controller
-----------------------
-MVEBU (Marvell SOCs: Armada 370/XP, Dove, mv78xx0, Kirkwood, Orion5x)
+MVEBU (Marvell SOCs: Armada 370/375/XP, Dove, mv78xx0, Kirkwood, Orion5x)
Required properties:
- compatible: one of:
- "marvell,orion-system-controller"
- "marvell,armada-370-xp-system-controller"
+ - "marvell,armada-375-system-controller"
- reg: Should contain system controller registers location and length.
Example:
diff --git a/arch/arm/mach-mvebu/system-controller.c b/arch/arm/mach-mvebu/system-controller.c
index a7fb89a..1806187 100644
--- a/arch/arm/mach-mvebu/system-controller.c
+++ b/arch/arm/mach-mvebu/system-controller.c
@@ -1,5 +1,5 @@
/*
- * System controller support for Armada 370 and XP platforms.
+ * System controller support for Armada 370, 375 and XP platforms.
*
* Copyright (C) 2012 Marvell
*
@@ -11,7 +11,7 @@
* License version 2. This program is licensed "as is" without any
* warranty of any kind, whether express or implied.
*
- * The Armada 370 and Armada XP SoCs both have a range of
+ * The Armada 370, 375 and Armada XP SoCs have a range of
* miscellaneous registers, that do not belong to a particular device,
* but rather provide system-level features. This basic
* system-controller driver provides a device tree binding for those
@@ -47,6 +47,13 @@ static const struct mvebu_system_controller armada_370_xp_system_controller = {
.system_soft_reset = 0x1,
};
+static const struct mvebu_system_controller armada_375_system_controller = {
+ .rstoutn_mask_offset = 0x54,
+ .system_soft_reset_offset = 0x58,
+ .rstoutn_mask_reset_out_en = 0x1,
+ .system_soft_reset = 0x1,
+};
+
static const struct mvebu_system_controller orion_system_controller = {
.rstoutn_mask_offset = 0x108,
.system_soft_reset_offset = 0x10c,
@@ -61,6 +68,9 @@ static struct of_device_id of_system_controller_table[] = {
}, {
.compatible = "marvell,armada-370-xp-system-controller",
.data = (void *) &armada_370_xp_system_controller,
+ }, {
+ .compatible = "marvell,armada-375-system-controller",
+ .data = (void *) &armada_375_system_controller,
},
{ /* end of list */ },
};
--
1.8.3.2
^ permalink raw reply related
* [PATCH v3 05/13] ARM: mvebu: add initial support for the Armada 375 SOCs
From: Thomas Petazzoni @ 2014-02-13 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392289475-8902-1-git-send-email-thomas.petazzoni@free-electrons.com>
From: Gregory CLEMENT <gregory.clement@free-electrons.com>
This commit adds the basic support for the Armada 375 SOCs. These SoCs
share most of their IP with the Armada 370/XP SoCs. The main
difference is the use of a Cortex A9 CPU instead of the PJ4B CPU. The
interrupt controller and the L2 cache controller are also different
they are respectively the GIC and the PL310.
The support is introduced in armada-mvebu.c, together with Armada
370/XP, but a separate DT structure is added, because Armada 375 will
need a different set of SMP operations when the SMP support is
introduced.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
Documentation/devicetree/bindings/arm/armada-375.txt | 9 +++++++++
arch/arm/mach-mvebu/Kconfig | 14 ++++++++++++++
arch/arm/mach-mvebu/armada-mvebu.c | 11 +++++++++++
3 files changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/armada-375.txt
diff --git a/Documentation/devicetree/bindings/arm/armada-375.txt b/Documentation/devicetree/bindings/arm/armada-375.txt
new file mode 100644
index 0000000..867d0b8
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/armada-375.txt
@@ -0,0 +1,9 @@
+Marvell Armada 375 Platforms Device Tree Bindings
+-------------------------------------------------
+
+Boards with a SoC of the Marvell Armada 375 family shall have the
+following property:
+
+Required root node property:
+
+compatible: must contain "marvell,armada375"
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index c934f92..3e228af 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -37,6 +37,20 @@ config MACH_ARMADA_370
Say 'Y' here if you want your kernel to support boards based
on the Marvell Armada 370 SoC with device tree.
+config MACH_ARMADA_375
+ bool "Marvell Armada 375 boards"
+ select ARM_ERRATA_720789
+ select ARM_ERRATA_753970
+ select ARM_GIC
+ select ARMADA_375_CLK
+ select CPU_V7
+ select MACH_ARMADA_MVEBU
+ select NEON
+ select PINCTRL_ARMADA_375
+ help
+ Say 'Y' here if you want your kernel to support boards based
+ on the Marvell Armada 375 SoC with device tree.
+
config MACH_ARMADA_XP
bool "Marvell Armada XP boards"
select ARMADA_XP_CLK
diff --git a/arch/arm/mach-mvebu/armada-mvebu.c b/arch/arm/mach-mvebu/armada-mvebu.c
index 18fbb32..7d1687a 100644
--- a/arch/arm/mach-mvebu/armada-mvebu.c
+++ b/arch/arm/mach-mvebu/armada-mvebu.c
@@ -95,3 +95,14 @@ DT_MACHINE_START(ARMADA_370_XP_DT, "Marvell Armada 370/XP (Device Tree)")
.restart = mvebu_restart,
.dt_compat = armada_370_xp_dt_compat,
MACHINE_END
+
+static const char * const armada_375_dt_compat[] = {
+ "marvell,armada375",
+ NULL,
+};
+
+DT_MACHINE_START(ARMADA_375_DT, "Marvell Armada 375 (Device Tree)")
+ .init_time = armada_mvebu_timer_and_clk_init,
+ .restart = mvebu_restart,
+ .dt_compat = armada_375_dt_compat,
+MACHINE_END
--
1.8.3.2
^ permalink raw reply related
* [PATCH v3 06/13] ARM: mvebu: add workaround for data abort issue on Armada 375
From: Thomas Petazzoni @ 2014-02-13 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392289475-8902-1-git-send-email-thomas.petazzoni@free-electrons.com>
Early versions of Armada 375 SoC have a bug where the BootROM leaves
an external data abort pending. The kernel is hit by this data abort
as soon as it enters userspace, because it unmasks the data aborts at
this moment. We register a custom abort handler below to ignore the
first data abort to work around this problem.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/mach-mvebu/armada-mvebu.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/arm/mach-mvebu/armada-mvebu.c b/arch/arm/mach-mvebu/armada-mvebu.c
index 7d1687a..7e50464 100644
--- a/arch/arm/mach-mvebu/armada-mvebu.c
+++ b/arch/arm/mach-mvebu/armada-mvebu.c
@@ -36,6 +36,27 @@ static void __init armada_mvebu_map_io(void)
debug_ll_io_init();
}
+/*
+ * Early versions of Armada 375 SoC have a bug where the BootROM
+ * leaves an external data abort pending. The kernel is hit by this
+ * data abort as soon as it enters userspace, because it unmasks the
+ * data aborts at this moment. We register a custom abort handler
+ * below to ignore the first data abort to work around this
+ * problem.
+ */
+static int armada_375_external_abort_wa(unsigned long addr, unsigned int fsr,
+ struct pt_regs *regs)
+{
+ static int ignore_first;
+
+ if (!ignore_first && fsr == 0x1406) {
+ ignore_first = 1;
+ return 0;
+ }
+
+ return 1;
+}
+
static void __init armada_mvebu_timer_and_clk_init(void)
{
of_clk_init(NULL);
@@ -45,6 +66,10 @@ static void __init armada_mvebu_timer_and_clk_init(void)
#ifdef CONFIG_CACHE_L2X0
l2x0_of_init(0, ~0UL);
#endif
+
+ if (of_machine_is_compatible("marvell,armada375"))
+ hook_fault_code(16 + 6, armada_375_external_abort_wa, SIGBUS, 0,
+ "imprecise external abort");
}
static void __init i2c_quirk(void)
--
1.8.3.2
^ permalink raw reply related
* [PATCH v3 07/13] ARM: mvebu: add Device Tree description of the Armada 375 SoC
From: Thomas Petazzoni @ 2014-02-13 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392289475-8902-1-git-send-email-thomas.petazzoni@free-electrons.com>
From: Gregory CLEMENT <gregory.clement@free-electrons.com>
The Armada 375 SoC is a new SoC from Marvell, based on a dual core
Cortex-A9 and a number of hardware blocks that are common with earlier
SoCs from the mvebu family.
The provided Device Tree describes the following parts of the SoC:
* CPUs
* Device Bus
* Clocks
* Interrupt controllers: GIC and MPIC
* GPIO controllers
* I2C buses
* L2 cache
* MBus controller
* SDIO
* Pinctrl
* SATA
* Serial
* SPI buses
* System controller (for reboot)
* Timer
* XOR engines
* PCIe controllers
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 439 ++++++++++++++++++++++++++++++++++++++
1 file changed, 439 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-375.dtsi
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
new file mode 100644
index 0000000..31de4bf
--- /dev/null
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -0,0 +1,439 @@
+/*
+ * Device Tree Include file for Marvell Armada 375 family SoC
+ *
+ * Copyright (C) 2014 Marvell
+ *
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * 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/ "skeleton.dtsi"
+
+#define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16))
+
+/ {
+ model = "Marvell Armada 375 family SoC";
+ compatible = "marvell,armada375";
+
+ aliases {
+ gpio0 = &gpio0;
+ gpio1 = &gpio1;
+ gpio2 = &gpio2;
+ };
+
+ clocks {
+ /* 2 GHz fixed main PLL */
+ mainpll: mainpll {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2000000000>;
+ };
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu at 0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <0>;
+ };
+ cpu at 1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <1>;
+ };
+ };
+
+ soc {
+ compatible = "marvell,armada375-mbus", "marvell,armada370-mbus", "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ controller = <&mbusc>;
+ interrupt-parent = <&gic>;
+ pcie-mem-aperture = <0xe0000000 0x8000000>;
+ pcie-io-aperture = <0xe8000000 0x100000>;
+
+ bootrom {
+ compatible = "marvell,bootrom";
+ reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
+ };
+
+ devbus-bootcs {
+ compatible = "marvell,mvebu-devbus";
+ reg = <MBUS_ID(0xf0, 0x01) 0x10400 0x8>;
+ ranges = <0 MBUS_ID(0x01, 0x2f) 0 0xffffffff>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ clocks = <&coreclk 0>;
+ status = "disabled";
+ };
+
+ devbus-cs0 {
+ compatible = "marvell,mvebu-devbus";
+ reg = <MBUS_ID(0xf0, 0x01) 0x10408 0x8>;
+ ranges = <0 MBUS_ID(0x01, 0x3e) 0 0xffffffff>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ clocks = <&coreclk 0>;
+ status = "disabled";
+ };
+
+ devbus-cs1 {
+ compatible = "marvell,mvebu-devbus";
+ reg = <MBUS_ID(0xf0, 0x01) 0x10410 0x8>;
+ ranges = <0 MBUS_ID(0x01, 0x3d) 0 0xffffffff>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ clocks = <&coreclk 0>;
+ status = "disabled";
+ };
+
+ devbus-cs2 {
+ compatible = "marvell,mvebu-devbus";
+ reg = <MBUS_ID(0xf0, 0x01) 0x10418 0x8>;
+ ranges = <0 MBUS_ID(0x01, 0x3b) 0 0xffffffff>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ clocks = <&coreclk 0>;
+ status = "disabled";
+ };
+
+ devbus-cs3 {
+ compatible = "marvell,mvebu-devbus";
+ reg = <MBUS_ID(0xf0, 0x01) 0x10420 0x8>;
+ ranges = <0 MBUS_ID(0x01, 0x37) 0 0xffffffff>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ clocks = <&coreclk 0>;
+ status = "disabled";
+ };
+
+ internal-regs {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
+
+ L2: cache-controller at 8000 {
+ compatible = "arm,pl310-cache";
+ reg = <0x8000 0x1000>;
+ cache-unified;
+ cache-level = <2>;
+ };
+
+ timer at c600 {
+ compatible = "arm,cortex-a9-twd-timer";
+ reg = <0xc600 0x20>;
+ interrupts = <1 13 0x301>;
+ clocks = <&coreclk 2>;
+ };
+
+ gic: interrupt-controller at d000 {
+ compatible = "arm,cortex-a9-gic";
+ #interrupt-cells = <3>;
+ #size-cells = <0>;
+ interrupt-controller;
+ reg = <0xd000 0x1000>,
+ <0xc100 0x100>;
+ };
+
+ spi0: spi at 10600 {
+ compatible = "marvell,orion-spi";
+ reg = <0x10600 0x50>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <0>;
+ interrupts = <0 1 0x4>;
+ clocks = <&coreclk 0>;
+ status = "disabled";
+ };
+
+ spi1: spi at 10680 {
+ compatible = "marvell,orion-spi";
+ reg = <0x10680 0x50>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <1>;
+ interrupts = <0 63 0x4>;
+ clocks = <&coreclk 0>;
+ status = "disabled";
+ };
+
+ i2c0: i2c at 11000 {
+ compatible = "marvell,mv64xxx-i2c";
+ reg = <0x11000 0x20>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <0 2 0x4>;
+ timeout-ms = <1000>;
+ clocks = <&coreclk 0>;
+ status = "disabled";
+ };
+
+ i2c1: i2c at 11100 {
+ compatible = "marvell,mv64xxx-i2c";
+ reg = <0x11100 0x20>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <0 3 0x4>;
+ timeout-ms = <1000>;
+ clocks = <&coreclk 0>;
+ status = "disabled";
+ };
+
+ serial at 12000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x12000 0x100>;
+ reg-shift = <2>;
+ interrupts = <0 12 4>;
+ reg-io-width = <1>;
+ status = "disabled";
+ };
+
+ serial at 12100 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x12100 0x100>;
+ reg-shift = <2>;
+ interrupts = <0 13 4>;
+ reg-io-width = <1>;
+ status = "disabled";
+ };
+
+ pinctrl {
+ compatible = "marvell,mv88f6720-pinctrl";
+ reg = <0x18000 0x24>;
+
+ i2c0_pins: i2c0-pins {
+ marvell,pins = "mpp14", "mpp15";
+ marvell,function = "i2c0";
+ };
+
+ i2c1_pins: i2c1-pins {
+ marvell,pins = "mpp61", "mpp62";
+ marvell,function = "i2c1";
+ };
+
+ sdio_pins: sdio-pins {
+ marvell,pins = "mpp24", "mpp25", "mpp26",
+ "mpp27", "mpp28", "mpp29";
+ marvell,function = "sd";
+ };
+
+ spi0_pins: spi0-pins {
+ marvell,pins = "mpp0", "mpp1", "mpp4",
+ "mpp5", "mpp8", "mpp9";
+ marvell,function = "spi0";
+ };
+ };
+
+ gpio0: gpio at 18100 {
+ compatible = "marvell,orion-gpio";
+ reg = <0x18100 0x40>;
+ ngpios = <32>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <0 53 0x4>, <0 54 0x4>,
+ <0 55 0x4>, <0 56 0x4>;
+ };
+
+ gpio1: gpio at 18140 {
+ compatible = "marvell,orion-gpio";
+ reg = <0x18140 0x40>;
+ ngpios = <32>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <0 58 0x4>, <0 59 0x4>,
+ <0 60 0x4>, <0 61 0x4>;
+ };
+
+ gpio2: gpio at 18180 {
+ compatible = "marvell,orion-gpio";
+ reg = <0x18180 0x40>;
+ ngpios = <3>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <0 62 0x4>;
+ };
+
+ system-controller at 18200 {
+ compatible = "marvell,armada-375-system-controller";
+ reg = <0x18200 0x100>;
+ };
+
+ gateclk: clock-gating-control at 18220 {
+ compatible = "marvell,armada-375-gating-clock";
+ reg = <0x18220 0x4>;
+ clocks = <&coreclk 0>;
+ #clock-cells = <1>;
+ };
+
+ mbusc: mbus-controller at 20000 {
+ compatible = "marvell,mbus-controller";
+ reg = <0x20000 0x100>, <0x20180 0x20>;
+ };
+
+ mpic: interrupt-controller at 20000 {
+ compatible = "marvell,mpic";
+ reg = <0x20a00 0x2d0>, <0x21070 0x58>;
+ #interrupt-cells = <1>;
+ #size-cells = <1>;
+ interrupt-controller;
+ msi-controller;
+ interrupts = <1 15 0x4>;
+ };
+
+ timer at 20300 {
+ compatible = "marvell,armada-375-timer", "marvell,armada-370-timer";
+ reg = <0x20300 0x30>, <0x21040 0x30>;
+ interrupts-extended = <&gic 0 8 4>,
+ <&gic 0 9 4>,
+ <&gic 0 10 4>,
+ <&gic 0 11 4>,
+ <&mpic 5>,
+ <&mpic 6>;
+ clocks = <&coreclk 0>;
+ };
+
+ xor at 60800 {
+ compatible = "marvell,orion-xor";
+ reg = <0x60800 0x100
+ 0x60A00 0x100>;
+ clocks = <&gateclk 22>;
+ status = "okay";
+
+ xor00 {
+ interrupts = <0 22 0x4>;
+ dmacap,memcpy;
+ dmacap,xor;
+ };
+ xor01 {
+ interrupts = <0 23 0x4>;
+ dmacap,memcpy;
+ dmacap,xor;
+ dmacap,memset;
+ };
+ };
+
+ xor at 60900 {
+ compatible = "marvell,orion-xor";
+ reg = <0x60900 0x100
+ 0x60b00 0x100>;
+ clocks = <&gateclk 23>;
+ status = "okay";
+
+ xor10 {
+ interrupts = <0 65 0x4>;
+ dmacap,memcpy;
+ dmacap,xor;
+ };
+ xor11 {
+ interrupts = <0 66 0x4>;
+ dmacap,memcpy;
+ dmacap,xor;
+ dmacap,memset;
+ };
+ };
+
+ sata at a0000 {
+ compatible = "marvell,orion-sata";
+ reg = <0xa0000 0x5000>;
+ interrupts = <0 26 0x4>;
+ clocks = <&gateclk 14>, <&gateclk 20>;
+ clock-names = "0", "1";
+ status = "disabled";
+ };
+
+ mvsdio at d4000 {
+ compatible = "marvell,orion-sdio";
+ reg = <0xd4000 0x200>;
+ interrupts = <0 25 0x4>;
+ clocks = <&gateclk 17>;
+ bus-width = <4>;
+ cap-sdio-irq;
+ cap-sd-highspeed;
+ cap-mmc-highspeed;
+ status = "disabled";
+ };
+
+ coreclk: mvebu-sar at e8204 {
+ compatible = "marvell,armada-375-core-clock";
+ reg = <0xe8204 0x04>;
+ #clock-cells = <1>;
+ };
+
+ coredivclk: corediv-clock at e8250 {
+ compatible = "marvell,armada-375-corediv-clock";
+ reg = <0xe8250 0xc>;
+ #clock-cells = <1>;
+ clocks = <&mainpll>;
+ clock-output-names = "nand";
+ };
+ };
+
+ pcie-controller {
+ compatible = "marvell,armada-370-pcie";
+ status = "disabled";
+ device_type = "pci";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ msi-parent = <&mpic>;
+ bus-range = <0x00 0xff>;
+
+ ranges =
+ <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000
+ 0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000
+ 0x82000000 0x1 0 MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0 MEM */
+ 0x81000000 0x1 0 MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0 IO */
+ 0x82000000 0x2 0 MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 1 MEM */
+ 0x81000000 0x2 0 MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 1 IO */>;
+
+ pcie at 1,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
+ reg = <0x0800 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+ 0x81000000 0 0 0x81000000 0x1 0 1 0>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &gic 0 29 0x4>;
+ marvell,pcie-port = <0>;
+ marvell,pcie-lane = <0>;
+ clocks = <&gateclk 5>;
+ status = "disabled";
+ };
+
+ pcie at 2,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
+ reg = <0x1000 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
+ 0x81000000 0 0 0x81000000 0x2 0 1 0>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &gic 0 33 0x4>;
+ marvell,pcie-port = <0>;
+ marvell,pcie-lane = <1>;
+ clocks = <&gateclk 6>;
+ status = "disabled";
+ };
+
+ };
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCH v3 08/13] ARM: mvebu: add Device Tree for the Armada 375 DB board
From: Thomas Petazzoni @ 2014-02-13 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392289475-8902-1-git-send-email-thomas.petazzoni@free-electrons.com>
The Armada 375 DB board is the development board from Marvell for the
Armada 375 SoC. This commit adds a Device Tree description for this
board, which enables the following features:
* I2C buses
* SDIO
* Serial port
* SPI bus, with a SPI flash. Note that the SPI bus is disabled by
default, because it conflicts with the NAND, and can only work if
the board boots out of SPI. Since most boards are shipped to boot
out of NAND, we're default to having the SPI bus disabled.
* PCIe interfaces
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-375-db.dts | 107 ++++++++++++++++++++++++++++++++++++
2 files changed, 108 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-375-db.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b9d6a8b..f1eafbd 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -126,6 +126,7 @@ dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
armada-370-netgear-rn102.dtb \
armada-370-netgear-rn104.dtb \
armada-370-rd.dtb \
+ armada-375-db.dtb \
armada-xp-axpwifiap.dtb \
armada-xp-db.dtb \
armada-xp-gp.dtb \
diff --git a/arch/arm/boot/dts/armada-375-db.dts b/arch/arm/boot/dts/armada-375-db.dts
new file mode 100644
index 0000000..c50e246
--- /dev/null
+++ b/arch/arm/boot/dts/armada-375-db.dts
@@ -0,0 +1,107 @@
+/*
+ * Device Tree file for Marvell Armada 375 evaluation board
+ * (DB-88F6720)
+ *
+ * Copyright (C) 2014 Marvell
+ *
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * 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.
+ */
+
+/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
+#include "armada-375.dtsi"
+
+/ {
+ model = "Marvell Armada 375 Development Board";
+ compatible = "marvell,a375-db", "marvell,armada375";
+
+ chosen {
+ bootargs = "console=ttyS0,115200 earlyprintk";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x40000000>; /* 1 GB */
+ };
+
+ soc {
+ ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
+ MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000>;
+
+ internal-regs {
+ spi at 10600 {
+ pinctrl-0 = <&spi0_pins>;
+ pinctrl-names = "default";
+ /*
+ * SPI conflicts with NAND, so we disable it
+ * here, and select NAND as the enabled device
+ * by default.
+ */
+ status = "disabled";
+
+ spi-flash at 0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "n25q128a13";
+ reg = <0>; /* Chip select 0 */
+ spi-max-frequency = <108000000>;
+ };
+ };
+
+ i2c at 11000 {
+ status = "okay";
+ clock-frequency = <100000>;
+ pinctrl-0 = <&i2c0_pins>;
+ pinctrl-names = "default";
+ };
+
+ i2c at 11100 {
+ status = "okay";
+ clock-frequency = <100000>;
+ pinctrl-0 = <&i2c1_pins>;
+ pinctrl-names = "default";
+ };
+
+ serial at 12000 {
+ clock-frequency = <200000000>;
+ status = "okay";
+ };
+
+ pinctrl {
+ sdio_st_pins: sdio-st-pins {
+ marvell,pins = "mpp44", "mpp45";
+ marvell,function = "gpio";
+ };
+ };
+
+ mvsdio at d4000 {
+ pinctrl-0 = <&sdio_pins &sdio_st_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ cd-gpios = <&gpio1 12 GPIO_ACTIVE_HIGH>;
+ wp-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ pcie-controller {
+ status = "okay";
+ /*
+ * The two PCIe units are accessible through
+ * standard PCIe slots on the board.
+ */
+ pcie at 1,0 {
+ /* Port 0, Lane 0 */
+ status = "okay";
+ };
+ pcie at 2,0 {
+ /* Port 1, Lane 0 */
+ status = "okay";
+ };
+ };
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCH v3 09/13] ARM: mvebu: add initial support for the Armada 380/385 SOCs
From: Thomas Petazzoni @ 2014-02-13 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392289475-8902-1-git-send-email-thomas.petazzoni@free-electrons.com>
This commit adds the basic support for the Armada 380 and Armada 385
SOCs. These SoCs share most of their IP with the Armada 370/XP
SoCs. The main difference is the use of a Cortex A9 CPU instead of the
PJ4B CPU. The Armada 380 is a single core Cortex-A9, while the Armada
385 is a dual-core Cortex-A9.
The support is introduced in armada-mvebu.c, together with Armada
370/XP, but a separate DT structure is added, because Armada 38x will
need a different set of SMP operations when the SMP support is
introduced.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
Documentation/devicetree/bindings/arm/armada-38x.txt | 10 ++++++++++
arch/arm/mach-mvebu/Kconfig | 14 ++++++++++++++
arch/arm/mach-mvebu/armada-mvebu.c | 12 ++++++++++++
3 files changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/armada-38x.txt
diff --git a/Documentation/devicetree/bindings/arm/armada-38x.txt b/Documentation/devicetree/bindings/arm/armada-38x.txt
new file mode 100644
index 0000000..11f2330
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/armada-38x.txt
@@ -0,0 +1,10 @@
+Marvell Armada 38x Platforms Device Tree Bindings
+-------------------------------------------------
+
+Boards with a SoC of the Marvell Armada 38x family shall have the
+following property:
+
+Required root node property:
+
+ - compatible: must contain either "marvell,armada380" or
+ "marvell,armada385" depending on the variant of the SoC being used.
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 3e228af..57f4bde 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -51,6 +51,20 @@ config MACH_ARMADA_375
Say 'Y' here if you want your kernel to support boards based
on the Marvell Armada 375 SoC with device tree.
+config MACH_ARMADA_38X
+ bool "Marvell Armada 380/385 boards"
+ select ARM_ERRATA_720789
+ select ARM_ERRATA_753970
+ select ARM_GIC
+ select ARMADA_38X_CLK
+ select CPU_V7
+ select MACH_ARMADA_MVEBU
+ select NEON
+ select PINCTRL_ARMADA_38X
+ help
+ Say 'Y' here if you want your kernel to support boards based
+ on the Marvell Armada 380/385 SoC with device tree.
+
config MACH_ARMADA_XP
bool "Marvell Armada XP boards"
select ARMADA_XP_CLK
diff --git a/arch/arm/mach-mvebu/armada-mvebu.c b/arch/arm/mach-mvebu/armada-mvebu.c
index 7e50464..fcf4091 100644
--- a/arch/arm/mach-mvebu/armada-mvebu.c
+++ b/arch/arm/mach-mvebu/armada-mvebu.c
@@ -131,3 +131,15 @@ DT_MACHINE_START(ARMADA_375_DT, "Marvell Armada 375 (Device Tree)")
.restart = mvebu_restart,
.dt_compat = armada_375_dt_compat,
MACHINE_END
+
+static const char * const armada_38x_dt_compat[] = {
+ "marvell,armada380",
+ "marvell,armada385",
+ NULL,
+};
+
+DT_MACHINE_START(ARMADA_38X_DT, "Marvell Armada 380/385 (Device Tree)")
+ .init_time = armada_mvebu_timer_and_clk_init,
+ .restart = mvebu_restart,
+ .dt_compat = armada_38x_dt_compat,
+MACHINE_END
--
1.8.3.2
^ permalink raw reply related
* [PATCH v3 10/13] ARM: mvebu: add Device Tree description of the Armada 380/385 SoCs
From: Thomas Petazzoni @ 2014-02-13 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392289475-8902-1-git-send-email-thomas.petazzoni@free-electrons.com>
The Armada 380 and 385 SoCs are new SoCs from Marvell, based on a
Cortex-A9 cores (single core for 380, dual core for 385) and a number
of hardware blocks that are common with earlier SoCs from the mvebu
family.
The provided Device Tree describes the following parts of the SoC:
* CPU
* Device Bus
* Clocks
* Interrupt controllers: GIC and MPIC
* GPIO controllers
* I2C buses
* L2 cache
* MBus controller
* Pinctrl
* Serial
* SPI buses
* System controller (for reboot)
* Timer
* XOR engines
* PCIe controllers
* Network interfaces
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/boot/dts/armada-380.dtsi | 117 +++++++++++++
arch/arm/boot/dts/armada-385.dtsi | 149 ++++++++++++++++
arch/arm/boot/dts/armada-38x.dtsi | 345 ++++++++++++++++++++++++++++++++++++++
3 files changed, 611 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-380.dtsi
create mode 100644 arch/arm/boot/dts/armada-385.dtsi
create mode 100644 arch/arm/boot/dts/armada-38x.dtsi
diff --git a/arch/arm/boot/dts/armada-380.dtsi b/arch/arm/boot/dts/armada-380.dtsi
new file mode 100644
index 0000000..5a46ec7
--- /dev/null
+++ b/arch/arm/boot/dts/armada-380.dtsi
@@ -0,0 +1,117 @@
+/*
+ * Device Tree Include file for Marvell Armada 380 SoC.
+ *
+ * Copyright (C) 2014 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * 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/ "armada-38x.dtsi"
+
+/ {
+ model = "Marvell Armada 380 family SoC";
+ compatible = "marvell,armada380", "marvell,armada38x";
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu at 0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <0>;
+ };
+ };
+
+ soc {
+ internal-regs {
+ pinctrl {
+ compatible = "marvell,mv88f6810-pinctrl";
+ reg = <0x18000 0x20>;
+ };
+ };
+
+ pcie-controller {
+ compatible = "marvell,armada-370-pcie";
+ status = "disabled";
+ device_type = "pci";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ msi-parent = <&mpic>;
+ bus-range = <0x00 0xff>;
+
+ ranges =
+ <0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000
+ 0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000
+ 0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000
+ 0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000
+ 0x82000000 0x1 0 MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 0 MEM */
+ 0x81000000 0x1 0 MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 0 IO */
+ 0x82000000 0x2 0 MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 1 MEM */
+ 0x81000000 0x2 0 MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 1 IO */
+ 0x82000000 0x3 0 MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 2 MEM */
+ 0x81000000 0x3 0 MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 2 IO */>;
+
+ /* x1 port */
+ pcie at 1,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82000800 0 0x80000 0 0x2000>;
+ reg = <0x0800 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+ 0x81000000 0 0 0x81000000 0x1 0 1 0>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &gic 0 29 0x4>;
+ marvell,pcie-port = <0>;
+ marvell,pcie-lane = <0>;
+ clocks = <&gateclk 8>;
+ status = "disabled";
+ };
+
+ /* x1 port */
+ pcie at 2,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
+ reg = <0x1000 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
+ 0x81000000 0 0 0x81000000 0x2 0 1 0>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &gic 0 33 0x4>;
+ marvell,pcie-port = <1>;
+ marvell,pcie-lane = <0>;
+ clocks = <&gateclk 5>;
+ status = "disabled";
+ };
+
+ /* x1 port */
+ pcie at 3,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
+ reg = <0x1000 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0
+ 0x81000000 0 0 0x81000000 0x3 0 1 0>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &gic 0 70 0x4>;
+ marvell,pcie-port = <2>;
+ marvell,pcie-lane = <0>;
+ clocks = <&gateclk 6>;
+ status = "disabled";
+ };
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/armada-385.dtsi b/arch/arm/boot/dts/armada-385.dtsi
new file mode 100644
index 0000000..b22f5f1
--- /dev/null
+++ b/arch/arm/boot/dts/armada-385.dtsi
@@ -0,0 +1,149 @@
+/*
+ * Device Tree Include file for Marvell Armada 385 SoC.
+ *
+ * Copyright (C) 2014 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * 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 "armada-38x.dtsi"
+
+/ {
+ model = "Marvell Armada 385 family SoC";
+ compatible = "marvell,armada385", "marvell,armada38x";
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu at 0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <0>;
+ };
+ cpu at 1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <1>;
+ };
+ };
+
+ soc {
+ internal-regs {
+ pinctrl {
+ compatible = "marvell,mv88f6820-pinctrl";
+ reg = <0x18000 0x20>;
+ };
+ };
+
+ pcie-controller {
+ compatible = "marvell,armada-370-pcie";
+ status = "disabled";
+ device_type = "pci";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ msi-parent = <&mpic>;
+ bus-range = <0x00 0xff>;
+
+ ranges =
+ <0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000
+ 0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000
+ 0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000
+ 0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000
+ 0x82000000 0x1 0 MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 0 MEM */
+ 0x81000000 0x1 0 MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 0 IO */
+ 0x82000000 0x2 0 MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 1 MEM */
+ 0x81000000 0x2 0 MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 1 IO */
+ 0x82000000 0x3 0 MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 2 MEM */
+ 0x81000000 0x3 0 MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 2 IO */
+ 0x82000000 0x4 0 MBUS_ID(0x04, 0xb8) 0 1 0 /* Port 3 MEM */
+ 0x81000000 0x4 0 MBUS_ID(0x04, 0xb0) 0 1 0 /* Port 3 IO */>;
+
+ /*
+ * This port can be either x4 or x1. When
+ * configured in x4 by the bootloader, then
+ * pcie at 4,0 is not available.
+ */
+ pcie at 1,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82000800 0 0x80000 0 0x2000>;
+ reg = <0x0800 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+ 0x81000000 0 0 0x81000000 0x1 0 1 0>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &gic 0 29 0x4>;
+ marvell,pcie-port = <0>;
+ marvell,pcie-lane = <0>;
+ clocks = <&gateclk 8>;
+ status = "disabled";
+ };
+
+ /* x1 port */
+ pcie at 2,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
+ reg = <0x1000 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
+ 0x81000000 0 0 0x81000000 0x2 0 1 0>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &gic 0 33 0x4>;
+ marvell,pcie-port = <1>;
+ marvell,pcie-lane = <0>;
+ clocks = <&gateclk 5>;
+ status = "disabled";
+ };
+
+ /* x1 port */
+ pcie at 3,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
+ reg = <0x1000 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0
+ 0x81000000 0 0 0x81000000 0x3 0 1 0>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &gic 0 70 0x4>;
+ marvell,pcie-port = <2>;
+ marvell,pcie-lane = <0>;
+ clocks = <&gateclk 6>;
+ status = "disabled";
+ };
+
+ /*
+ * x1 port only available when pcie at 1,0 is
+ * configured as a x1 port
+ */
+ pcie at 4,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82000800 0 0x48000 0 0x2000>;
+ reg = <0x1000 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges = <0x82000000 0 0 0x82000000 0x4 0 1 0
+ 0x81000000 0 0 0x81000000 0x4 0 1 0>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &gic 0 71 0x4>;
+ marvell,pcie-port = <3>;
+ marvell,pcie-lane = <0>;
+ clocks = <&gateclk 7>;
+ status = "disabled";
+ };
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/armada-38x.dtsi b/arch/arm/boot/dts/armada-38x.dtsi
new file mode 100644
index 0000000..5a10248
--- /dev/null
+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -0,0 +1,345 @@
+/*
+ * Device Tree Include file for Marvell Armada 38x family of SoCs.
+ *
+ * Copyright (C) 2014 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * 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 "skeleton.dtsi"
+
+#define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16))
+
+/ {
+ model = "Marvell Armada 38x family SoC";
+ compatible = "marvell,armada38x";
+
+ aliases {
+ gpio0 = &gpio0;
+ gpio1 = &gpio1;
+ eth0 = ð0;
+ eth1 = ð1;
+ eth2 = ð2;
+ };
+
+ soc {
+ compatible = "marvell,armada380-mbus", "marvell,armada370-mbus",
+ "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ controller = <&mbusc>;
+ interrupt-parent = <&gic>;
+ pcie-mem-aperture = <0xe0000000 0x8000000>;
+ pcie-io-aperture = <0xe8000000 0x100000>;
+
+ bootrom {
+ compatible = "marvell,bootrom";
+ reg = <MBUS_ID(0x01, 0x1d) 0 0x200000>;
+ };
+
+ devbus-bootcs {
+ compatible = "marvell,mvebu-devbus";
+ reg = <MBUS_ID(0xf0, 0x01) 0x10400 0x8>;
+ ranges = <0 MBUS_ID(0x01, 0x2f) 0 0xffffffff>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ clocks = <&coreclk 0>;
+ status = "disabled";
+ };
+
+ devbus-cs0 {
+ compatible = "marvell,mvebu-devbus";
+ reg = <MBUS_ID(0xf0, 0x01) 0x10408 0x8>;
+ ranges = <0 MBUS_ID(0x01, 0x3e) 0 0xffffffff>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ clocks = <&coreclk 0>;
+ status = "disabled";
+ };
+
+ devbus-cs1 {
+ compatible = "marvell,mvebu-devbus";
+ reg = <MBUS_ID(0xf0, 0x01) 0x10410 0x8>;
+ ranges = <0 MBUS_ID(0x01, 0x3d) 0 0xffffffff>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ clocks = <&coreclk 0>;
+ status = "disabled";
+ };
+
+ devbus-cs2 {
+ compatible = "marvell,mvebu-devbus";
+ reg = <MBUS_ID(0xf0, 0x01) 0x10418 0x8>;
+ ranges = <0 MBUS_ID(0x01, 0x3b) 0 0xffffffff>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ clocks = <&coreclk 0>;
+ status = "disabled";
+ };
+
+ devbus-cs3 {
+ compatible = "marvell,mvebu-devbus";
+ reg = <MBUS_ID(0xf0, 0x01) 0x10420 0x8>;
+ ranges = <0 MBUS_ID(0x01, 0x37) 0 0xffffffff>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ clocks = <&coreclk 0>;
+ status = "disabled";
+ };
+
+ internal-regs {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
+
+ L2: cache-controller at 8000 {
+ compatible = "arm,pl310-cache";
+ reg = <0x8000 0x1000>;
+ cache-unified;
+ cache-level = <2>;
+ };
+
+ timer at c600 {
+ compatible = "arm,cortex-a9-twd-timer";
+ reg = <0xc600 0x20>;
+ interrupts = <1 13 0x301>;
+ clocks = <&coreclk 2>;
+ };
+
+ gic: interrupt-controller at d000 {
+ compatible = "arm,cortex-a9-gic";
+ #interrupt-cells = <3>;
+ #size-cells = <0>;
+ interrupt-controller;
+ reg = <0xd000 0x1000>,
+ <0xc100 0x100>;
+ };
+
+ spi0: spi at 10600 {
+ compatible = "marvell,orion-spi";
+ reg = <0x10600 0x50>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <0>;
+ interrupts = <0 1 0x4>;
+ clocks = <&coreclk 0>;
+ status = "disabled";
+ };
+
+ spi1: spi at 10680 {
+ compatible = "marvell,orion-spi";
+ reg = <0x10680 0x50>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <1>;
+ interrupts = <0 63 0x4>;
+ clocks = <&coreclk 0>;
+ status = "disabled";
+ };
+
+ i2c0: i2c at 11000 {
+ compatible = "marvell,mv64xxx-i2c";
+ reg = <0x11000 0x20>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <0 2 0x4>;
+ timeout-ms = <1000>;
+ clocks = <&coreclk 0>;
+ status = "disabled";
+ };
+
+ i2c1: i2c at 11100 {
+ compatible = "marvell,mv64xxx-i2c";
+ reg = <0x11100 0x20>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <0 3 0x4>;
+ timeout-ms = <1000>;
+ clocks = <&coreclk 0>;
+ status = "disabled";
+ };
+
+ serial at 12000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x12000 0x100>;
+ reg-shift = <2>;
+ interrupts = <0 12 4>;
+ reg-io-width = <1>;
+ status = "disabled";
+ };
+
+ serial at 12100 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x12100 0x100>;
+ reg-shift = <2>;
+ interrupts = <0 13 4>;
+ reg-io-width = <1>;
+ status = "disabled";
+ };
+
+ pinctrl {
+ compatible = "marvell,mv88f6820-pinctrl";
+ reg = <0x18000 0x20>;
+ };
+
+ gpio0: gpio at 18100 {
+ compatible = "marvell,orion-gpio";
+ reg = <0x18100 0x40>;
+ ngpios = <32>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <0 53 0x4>, <0 54 0x4>,
+ <0 55 0x4>, <0 56 0x4>;
+ };
+
+ gpio1: gpio at 18140 {
+ compatible = "marvell,orion-gpio";
+ reg = <0x18140 0x40>;
+ ngpios = <28>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <0 58 0x4>, <0 59 0x4>,
+ <0 60 0x4>, <0 61 0x4>;
+ };
+
+ system-controller at 18200 {
+ compatible = "marvell,armada-380-system-controller",
+ "marvell,armada-370-xp-system-controller";
+ reg = <0x18200 0x100>;
+ };
+
+ gateclk: clock-gating-control at 18220 {
+ compatible = "marvell,armada-380-gating-clock";
+ reg = <0x18220 0x4>;
+ clocks = <&coreclk 0>;
+ #clock-cells = <1>;
+ };
+
+ coreclk: mvebu-sar at 18600 {
+ compatible = "marvell,armada-380-core-clock";
+ reg = <0x18600 0x04>;
+ #clock-cells = <1>;
+ };
+
+ mbusc: mbus-controller at 20000 {
+ compatible = "marvell,mbus-controller";
+ reg = <0x20000 0x100>, <0x20180 0x20>;
+ };
+
+ mpic: interrupt-controller at 20000 {
+ compatible = "marvell,mpic";
+ reg = <0x20a00 0x2d0>, <0x21070 0x58>;
+ #interrupt-cells = <1>;
+ #size-cells = <1>;
+ interrupt-controller;
+ msi-controller;
+ interrupts = <1 15 0x4>;
+ };
+
+ timer at 20300 {
+ compatible = "marvell,armada-380-timer",
+ "marvell,armada-xp-timer";
+ reg = <0x20300 0x30>, <0x21040 0x30>;
+ interrupts-extended = <&gic 0 8 4>,
+ <&gic 0 9 4>,
+ <&gic 0 10 4>,
+ <&gic 0 11 4>,
+ <&mpic 5>,
+ <&mpic 6>;
+ clocks = <&coreclk 2>, <&refclk>;
+ clock-names = "nbclk", "fixed";
+ };
+
+ eth1: ethernet at 30000 {
+ compatible = "marvell,armada-370-neta";
+ reg = <0x30000 0x4000>;
+ interrupts-extended = <&mpic 10>;
+ clocks = <&gateclk 3>;
+ status = "disabled";
+ };
+
+ eth2: ethernet at 34000 {
+ compatible = "marvell,armada-370-neta";
+ reg = <0x34000 0x4000>;
+ interrupts-extended = <&mpic 12>;
+ clocks = <&gateclk 2>;
+ status = "disabled";
+ };
+
+ xor at 60800 {
+ compatible = "marvell,orion-xor";
+ reg = <0x60800 0x100
+ 0x60a00 0x100>;
+ clocks = <&gateclk 22>;
+ status = "okay";
+
+ xor00 {
+ interrupts = <0 22 0x4>;
+ dmacap,memcpy;
+ dmacap,xor;
+ };
+ xor01 {
+ interrupts = <0 23 0x4>;
+ dmacap,memcpy;
+ dmacap,xor;
+ dmacap,memset;
+ };
+ };
+
+ xor at 60900 {
+ compatible = "marvell,orion-xor";
+ reg = <0x60900 0x100
+ 0x60b00 0x100>;
+ clocks = <&gateclk 28>;
+ status = "okay";
+
+ xor10 {
+ interrupts = <0 65 0x4>;
+ dmacap,memcpy;
+ dmacap,xor;
+ };
+ xor11 {
+ interrupts = <0 66 0x4>;
+ dmacap,memcpy;
+ dmacap,xor;
+ dmacap,memset;
+ };
+ };
+
+ eth0: ethernet at 70000 {
+ compatible = "marvell,armada-370-neta";
+ reg = <0x70000 0x4000>;
+ interrupts-extended = <&mpic 8>;
+ clocks = <&gateclk 4>;
+ status = "disabled";
+ };
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "marvell,orion-mdio";
+ reg = <0x72004 0x4>;
+ };
+ };
+ };
+
+ clocks {
+ /* 25 MHz reference crystal */
+ refclk: oscillator {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000000>;
+ };
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCH v3 11/13] ARM: mvebu: add Device Tree for the Armada 385 DB board
From: Thomas Petazzoni @ 2014-02-13 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392289475-8902-1-git-send-email-thomas.petazzoni@free-electrons.com>
The Armada 385 DB board is the development board from Marvell for the
Armada 385 SoC. This commit adds a Device Tree description for this
board, which enables the following features:
* Network interfaces
* I2C buses
* SDIO
* Serial port
* SPI bus, with a SPI flash
* PCIe interfaces
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-385-db.dts | 101 ++++++++++++++++++++++++++++++++++++
2 files changed, 102 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-385-db.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f1eafbd..bd789fc 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -127,6 +127,7 @@ dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
armada-370-netgear-rn104.dtb \
armada-370-rd.dtb \
armada-375-db.dtb \
+ armada-385-db.dtb \
armada-xp-axpwifiap.dtb \
armada-xp-db.dtb \
armada-xp-gp.dtb \
diff --git a/arch/arm/boot/dts/armada-385-db.dts b/arch/arm/boot/dts/armada-385-db.dts
new file mode 100644
index 0000000..01b6cc7
--- /dev/null
+++ b/arch/arm/boot/dts/armada-385-db.dts
@@ -0,0 +1,101 @@
+/*
+ * Device Tree file for Marvell Armada 385 evaluation board
+ * (DB-88F6820)
+ *
+ * Copyright (C) 2014 Marvell
+ *
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * 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.
+ */
+
+/dts-v1/;
+#include "armada-385.dtsi"
+
+/ {
+ model = "Marvell Armada 385 Development Board";
+ compatible = "marvell,a385-db", "marvell,armada385", "marvell,armada38x";
+
+ chosen {
+ bootargs = "console=ttyS0,115200 earlyprintk";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x10000000>; /* 256 MB */
+ };
+
+ soc {
+ ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
+ MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000>;
+
+ internal-regs {
+ spi at 10600 {
+ status = "okay";
+
+ spi-flash at 0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "w25q32";
+ reg = <0>; /* Chip select 0 */
+ spi-max-frequency = <108000000>;
+ };
+ };
+
+ i2c at 11000 {
+ status = "okay";
+ clock-frequency = <100000>;
+ };
+
+ i2c at 11100 {
+ status = "okay";
+ clock-frequency = <100000>;
+ };
+
+ serial at 12000 {
+ clock-frequency = <200000000>;
+ status = "okay";
+ };
+
+ ethernet at 30000 {
+ status = "okay";
+ phy = <&phy1>;
+ phy-mode = "rgmii";
+ };
+
+ ethernet at 70000 {
+ status = "okay";
+ phy = <&phy0>;
+ phy-mode = "rgmii";
+ };
+
+ mdio {
+ phy0: ethernet-phy at 0 {
+ reg = <0>;
+ };
+
+ phy1: ethernet-phy at 1 {
+ reg = <1>;
+ };
+ };
+ };
+
+ pcie-controller {
+ status = "okay";
+ /*
+ * The two PCIe units are accessible through
+ * standard PCIe slots on the board.
+ */
+ pcie at 1,0 {
+ /* Port 0, Lane 0 */
+ status = "okay";
+ };
+ pcie at 2,0 {
+ /* Port 1, Lane 0 */
+ status = "okay";
+ };
+ };
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCH v3 12/13] ARM: mvebu: update defconfigs for Armada 375 and 38x
From: Thomas Petazzoni @ 2014-02-13 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392289475-8902-1-git-send-email-thomas.petazzoni@free-electrons.com>
This commit enables the Armada 375 and Armada 38x support in
mvebu_defconfig and multi_v7_defconfig.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/configs/multi_v7_defconfig | 2 ++
arch/arm/configs/mvebu_defconfig | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 845bc74..3c32fc9 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -9,6 +9,8 @@ CONFIG_MODULE_UNLOAD=y
CONFIG_PARTITION_ADVANCED=y
CONFIG_ARCH_MVEBU=y
CONFIG_MACH_ARMADA_370=y
+CONFIG_MACH_ARMADA_375=y
+CONFIG_MACH_ARMADA_38X=y
CONFIG_MACH_ARMADA_XP=y
CONFIG_ARCH_BCM=y
CONFIG_ARCH_BCM_MOBILE=y
diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index 0f4511d..5fc24ae 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -10,6 +10,8 @@ CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_ARCH_MVEBU=y
CONFIG_MACH_ARMADA_370=y
+CONFIG_MACH_ARMADA_375=y
+CONFIG_MACH_ARMADA_38X=y
CONFIG_MACH_ARMADA_XP=y
# CONFIG_CACHE_L2X0 is not set
# CONFIG_SWP_EMULATE is not set
--
1.8.3.2
^ permalink raw reply related
* [PATCH v3 13/13] Documentation: arm: update Marvell documentation about Armada 375/38x
From: Thomas Petazzoni @ 2014-02-13 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392289475-8902-1-git-send-email-thomas.petazzoni@free-electrons.com>
This commit updates the documentation that describes the various
families of SOCs produced by Marvell, together with the corresponding
available technical documents. It adds Armada 375 and Armada 38x, and
adds a link to the product brief for the already supported Armada 370.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
Documentation/arm/Marvell/README | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README
index 5a930c1..963ec44 100644
--- a/Documentation/arm/Marvell/README
+++ b/Documentation/arm/Marvell/README
@@ -83,14 +83,24 @@ EBU Armada family
88F6710
88F6707
88F6W11
+ Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf
+
+ Armada 375 Flavors:
+ 88F6720
+ Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA_375_SoC-01_product_brief.pdf
+
+ Armada 380/385 Flavors:
+ 88F6810
+ 88F6820
+ 88F6828
Armada XP Flavors:
MV78230
MV78260
MV78460
NOTE: not to be confused with the non-SMP 78xx0 SoCs
+ Product Brief: http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf
- Product Brief: http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf
No public datasheet available.
Core: Sheeva ARMv7 compatible
--
1.8.3.2
^ permalink raw reply related
* [PATCH v3 7/7] devicetree: bindings: Document PM8921/8058 PMICs
From: Lee Jones @ 2014-02-13 11:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140213053813.GB14769@codeaurora.org>
> > > +- interrupts:
> > > + Usage: required
> > > + Value type: <prop-encoded-array>
> >
> > Either provide an example or a comment to see the description of
> > #interrupt-cells
>
> It is part of the example. We also state that the format is
> defined by the interrupt parent binding.
Okay, fair enough.
> > > + Definition: specifies the interrupt that indicates a subdevice
> > > + has generated an interrupt (summary interrupt). The
> > > + format of the specifier is defined by the binding document
> > > + describing the node's interrupt parent.
> > > +
> > > +- #interrupt-cells:
> > > + Usage: required
> > > + Value type : <u32>
> > > + Definition: must be 2. Specifies the number of cells needed to encode
> > > + an interrupt source. The 1st cell contains the interrupt
> > > + number. The 2nd cell is the trigger type and level flags
> > > + encoded as follows:
> > > +
> > > + 1 = low-to-high edge triggered
> > > + 2 = high-to-low edge triggered
> > > + 4 = active high level-sensitive
> > > + 8 = active low level-sensitive
> >
> > Actually I'd prefer if you used the definitions in:
> > dt-bindings/interrupt-controller/irq.h
>
> These match the #defines in that file. I'd like to be explicit
> about the numbers to prevent people from thinking they have to
> use #defines and to match what other irq controllers have done
> (gic, atmel-aic, etc.)
I believe people _do_ have to use the #defines? Is there a good reason
for you not wanting to use them?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v2 3/3] PCI: ARM: add support for generic PCI host controller
From: Will Deacon @ 2014-02-13 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <D2AE4AE6-E8FA-4DD8-B92B-E37205A2548C@codeaurora.org>
On Wed, Feb 12, 2014 at 09:51:48PM +0000, Kumar Gala wrote:
>
> On Feb 12, 2014, at 2:16 PM, Will Deacon <will.deacon@arm.com> wrote:
>
> > This patch adds support for a generic PCI host controller, such as a
> > firmware-initialised device with static windows or an emulation by
> > something such as kvmtool.
> >
> > The controller itself has no configuration registers and has its address
> > spaces described entirely by the device-tree (using the bindings from
> > ePAPR). Both CAM and ECAM are supported for Config Space accesses.
> >
> > Corresponding documentation is added for the DT binding.
> >
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > ---
> > .../devicetree/bindings/pci/arm-generic-pci.txt | 51 ++++
> > drivers/pci/host/Kconfig | 7 +
> > drivers/pci/host/Makefile | 1 +
> > drivers/pci/host/pci-arm-generic.c | 318 +++++++++++++++++++++
> > 4 files changed, 377 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/pci/arm-generic-pci.txt
> > create mode 100644 drivers/pci/host/pci-arm-generic.c
> >
> > diff --git a/Documentation/devicetree/bindings/pci/arm-generic-pci.txt b/Documentation/devicetree/bindings/pci/arm-generic-pci.txt
> > new file mode 100644
> > index 000000000000..cc7a35ecfa2d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pci/arm-generic-pci.txt
> > @@ -0,0 +1,51 @@
> > +* ARM generic PCI host controller
> > +
> > +Firmware-initialised PCI host controllers and PCI emulations, such as the
> > +virtio-pci implementations found in kvmtool and other para-virtualised
> > +systems, do not require driver support for complexities such as regulator and
> > +clock management. In fact, the controller may not even require the
> > +configuration of a control interface by the operating system, instead
> > +presenting a set of fixed windows describing a subset of IO, Memory and
> > +Configuration Spaces.
> > +
> > +Such a controller can be described purely in terms of the standardized device
> > +tree bindings communicated in pci.txt:
> > +
> > +- compatible : Must be "arm,pci-cam-generic" or "arm,pci-ecam-generic"
> > + depending on the layout of configuration space (CAM vs
> > + ECAM respectively)
>
> What?s arm specific here? I don?t have a great suggestion, but seems odd
> for this to be vendor prefixed with "arm".
Happy to change it, but I'm also struggling for names. Maybe "linux,..."?
> > +- ranges : As described in IEEE Std 1275-1994, but must provide
> > + at least a definition of one or both of IO and Memory
> > + Space.
> > +
> > +- #address-cells : Must be 3
> > +
> > +- #size-cells : Must be 2
> > +
> > +- reg : The Configuration Space base address, as accessed by the
> > + parent bus.
>
> Isn?t the size fixed here for cam or ecam?
Yes, which is why reg just specifies the base address.
> > +Configuration Space is assumed to be memory-mapped (as opposed to being
> > +accessed via an ioport) and laid out with a direct correspondence to the
> > +geography of a PCI bus address by concatenating the various components to form
> > +an offset.
> > +
> > +For CAM, this 24-bit offset is:
> > +
> > + cfg_offset(bus, device, function, register) =
> > + bus << 16 | device << 11 | function << 8 | register
> > +
> > +Whilst ECAM extends this by 4 bits to accomodate 4k of function space:
> > +
> > + cfg_offset(bus, device, function, register) =
> > + bus << 20 | device << 15 | function << 12 | register
> > +
> > +Interrupt mapping is exactly as described in `Open Firmware Recommended
> > +Practice: Interrupt Mapping' and requires the following properties:
> > +
> > +- #interrupt-cells : Must be 1
> > +
> > +- interrupt-map : <see aforementioned specification>
> > +
> > +- interrupt-map-mask : <see aforementioned specification>
>
> Examples are always nice :)
Not in this case! kvmtool generates the following:
pci {
#address-cells = <0x3>;
#size-cells = <0x2>;
#interrupt-cells = <0x1>;
compatible = "arm,pci-cam-generic";
reg = <0x0 0x40000000>;
ranges = <0x1000000 0x0 0x0 0x0 0x0 0x0 0x10000 0x2000000 0x0 0x41000000 0x0 0x41000000 0x0 0x3f000000>;
interrupt-map = <0x0 0x0 0x0 0x1 0x1 0x0 0x4 0x1 0x800 0x0 0x0 0x1 0x1 0x0 0x5 0x1 0x1000 0x0 0x0 0x1 0x1 0x0 0x6 0x1 0x1800 0x0 0x0 0x1 0x1 0x0 0x7 0x1>;
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
};
I can add it if you like, but it looks like a random bunch of numbers to me.
Will
^ permalink raw reply
* [PATCH v3 1/7] cpufreq: cpufreq-cpu0: allow use of optional boost mode frequencies
From: Tomasz Figa @ 2014-02-13 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJuA9agoK4vO+1mTktgc6BoHLO8qR2482uizP1LbG5zgy9Q4kA@mail.gmail.com>
On 13.02.2014 09:02, Thomas Abraham wrote:
> On Wed, Feb 12, 2014 at 8:28 PM, Tomasz Figa <t.figa@samsung.com> wrote:
>> Hi Thomas,
>>
>>
>> On 07.02.2014 16:55, Thomas Abraham wrote:
[snip]
>>> diff --git a/drivers/cpufreq/cpufreq-cpu0.c
>>> b/drivers/cpufreq/cpufreq-cpu0.c
>>> index 0c12ffc..06539eb 100644
>>> --- a/drivers/cpufreq/cpufreq-cpu0.c
>>> +++ b/drivers/cpufreq/cpufreq-cpu0.c
>>> @@ -195,6 +195,9 @@ static int cpu0_cpufreq_probe(struct platform_device
>>> *pdev)
>>> transition_latency += ret * 1000;
>>> }
>>>
>>> + if (of_find_property(cpu_dev->of_node, "boost-frequency", NULL))
>>> + cpu0_cpufreq_driver.boost_supported = true;
>>> +
>>> ret = cpufreq_register_driver(&cpu0_cpufreq_driver);
>>> if (ret) {
>>> pr_err("failed register driver: %d\n", ret);
>>>
>>
>> I'd say that boost should be enabled depending on user's preference, as done
>> before in Exynos cpufreq driver. So both presence of boost-frequency
>> property and state of CPU_FREQ_BOOST_SW should be considered.
>>
>> As for CPU_FREQ_BOOST_SW, I don't think it should be always selected, but
>> ather, either converted to a user-selectable bool entry or made selectable
>> by other entry, like current ARM_EXYNOS_CPU_FREQ_BOOST_SW.
>
> We still will have the same problem on Exynos multi-platform kernel
> where one Exynos platform needs it and others don't. Same with just
> using the CPU_FREQ_BOOST_SW config option. So that was the reason to
> just fallback on presence of boost property.
I don't think we really have a problem here, because we have well
defined semantics for particular enable methods:
- Kconfig is supposed to be a global enable - if an option is
disabled, it is not even built into the kernel and can be used in any
way - this is per-user choice, regardless of platform the image is going
to be running on,
- device tree is supposed to be telling us whether the hardware we are
running on supports given feature and all the required data to enable
it, if yes,
- then, for per system configuration, you should be able to
enable/disable given feature by a command line parameter, e.g.
cpufreq.boost_disable.
If you follow the above description, you should be able to get any
configuration you want on any system, as long as it's supported by hardware.
Best regards,
Tomasz
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox