[PATCH] net: ethernet: freescale: remove unneeded include for ucc_geth
net/sch_generic.h does not need to be included, remove it. Signed-off-by: Valentin Longchamp --- drivers/net/ethernet/freescale/ucc_geth.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c index 552e7554a9f8..db791f60b884 100644 --- a/drivers/net/ethernet/freescale/ucc_geth.c +++ b/drivers/net/ethernet/freescale/ucc_geth.c @@ -42,7 +42,6 @@ #include #include #include -#include #include "ucc_geth.h" -- 2.25.1
Re: [PATCH] net/ethernet/freescale: rework quiesce/activate for ucc_geth
Le 23.05.2020 à 00:50, David Miller a écrit : From: Valentin Longchamp Date: Wed, 20 May 2020 17:53:50 +0200 ugeth_quiesce/activate are used to halt the controller when there is a link change that requires to reconfigure the mac. The previous implementation called netif_device_detach(). This however causes the initial activation of the netdevice to fail precisely because it's detached. For details, see [1]. A possible workaround was the revert of commit net: linkwatch: add check for netdevice being present to linkwatch_do_dev However, the check introduced in the above commit is correct and shall be kept. The netif_device_detach() is thus replaced with netif_tx_stop_all_queues() that prevents any tranmission. This allows to perform mac config change required by the link change, without detaching the corresponding netdevice and thus not preventing its initial activation. [1] https://lists.openwall.net/netdev/2020/01/08/201 Signed-off-by: Valentin Longchamp Acked-by: Matteo Ghidoni Applied, thanks. Thanks David. May I suggest that this get backported to stable until (including) the 4.19 stable release ? As the above mentioned commit, merged for 4.19, 124eee3f6955 net: linkwatch: add check for netdevice being present to linkwatch_do_dev does indeed break the ucc_geth driver, this patch can be considered as a bugfix that should be taken into account for stable.
[PATCH] net/ethernet/freescale: rework quiesce/activate for ucc_geth
ugeth_quiesce/activate are used to halt the controller when there is a
link change that requires to reconfigure the mac.
The previous implementation called netif_device_detach(). This however
causes the initial activation of the netdevice to fail precisely because
it's detached. For details, see [1].
A possible workaround was the revert of commit
net: linkwatch: add check for netdevice being present to linkwatch_do_dev
However, the check introduced in the above commit is correct and shall be
kept.
The netif_device_detach() is thus replaced with
netif_tx_stop_all_queues() that prevents any tranmission. This allows to
perform mac config change required by the link change, without detaching
the corresponding netdevice and thus not preventing its initial
activation.
[1] https://lists.openwall.net/netdev/2020/01/08/201
Signed-off-by: Valentin Longchamp
Acked-by: Matteo Ghidoni
---
drivers/net/ethernet/freescale/ucc_geth.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c
b/drivers/net/ethernet/freescale/ucc_geth.c
index 6e5f6dd169b5..552e7554a9f8 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include "ucc_geth.h"
@@ -1548,11 +1549,8 @@ static int ugeth_disable(struct ucc_geth_private *ugeth,
enum comm_dir mode)
static void ugeth_quiesce(struct ucc_geth_private *ugeth)
{
- /* Prevent any further xmits, plus detach the device. */
- netif_device_detach(ugeth->ndev);
-
- /* Wait for any current xmits to finish. */
- netif_tx_disable(ugeth->ndev);
+ /* Prevent any further xmits */
+ netif_tx_stop_all_queues(ugeth->ndev);
/* Disable the interrupt to avoid NAPI rescheduling. */
disable_irq(ugeth->ug_info->uf_info.irq);
@@ -1565,7 +1563,10 @@ static void ugeth_activate(struct ucc_geth_private
*ugeth)
{
napi_enable(>napi);
enable_irq(ugeth->ug_info->uf_info.irq);
- netif_device_attach(ugeth->ndev);
+
+ /* allow to xmit again */
+ netif_tx_wake_all_queues(ugeth->ndev);
+ __netdev_watchdog_up(ugeth->ndev);
}
/* Called every time the controller might need to be made
--
2.25.1
[PATCH] powerpc/kmcent2: add ranges to the pci bridges
This removes the warnings about the fact that the 4 pci bridges (i.e.
the 4 pci hosts) don't have any ranges.
Signed-off-by: Valentin Longchamp
---
arch/powerpc/boot/dts/fsl/kmcent2.dts | 36 +++
1 file changed, 36 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/kmcent2.dts
b/arch/powerpc/boot/dts/fsl/kmcent2.dts
index 48b7f9797124..5731928e9264 100644
--- a/arch/powerpc/boot/dts/fsl/kmcent2.dts
+++ b/arch/powerpc/boot/dts/fsl/kmcent2.dts
@@ -258,14 +258,50 @@
pci1: pcie@ffe25 {
status = "disabled";
+ reg = <0xf 0xfe25 0 0x1>;
+ ranges = <0x0200 0 0xe000 0xc 0x1000 0 0x1000
+ 0x0100 0 0 0xf 0xf801 0 0x0001>;
+ pcie@0 {
+ ranges = <0x0200 0 0xe000
+ 0x0200 0 0xe000
+ 0 0x1000
+
+ 0x0100 0 0x
+ 0x0100 0 0x
+ 0 0x0001>;
+ };
};
pci2: pcie@ffe26 {
status = "disabled";
+ reg = <0xf 0xfe26 0 0x1>;
+ ranges = <0x0200 0 0xe000 0xc 0x2000 0 0x1000
+ 0x0100 0 0x 0xf 0xf802 0 0x0001>;
+ pcie@0 {
+ ranges = <0x0200 0 0xe000
+ 0x0200 0 0xe000
+ 0 0x1000
+
+ 0x0100 0 0x
+ 0x0100 0 0x
+ 0 0x0001>;
+ };
};
pci3: pcie@ffe27 {
status = "disabled";
+ reg = <0xf 0xfe27 0 0x1>;
+ ranges = <0x0200 0 0xe000 0xc 0x3000 0 0x1000
+ 0x0100 0 0x 0xf 0xf803 0 0x0001>;
+ pcie@0 {
+ ranges = <0x0200 0 0xe000
+ 0x0200 0 0xe000
+ 0 0x1000
+
+ 0x0100 0 0x
+ 0x0100 0 0x
+ 0 0x0001>;
+ };
};
qe: qe@ffe14 {
--
2.17.1
Re: [PATCH] powerpc/kmcent2: update the ethernet devices' phy properties
Le mar. 30 juil. 2019 à 11:44, Madalin-cristian Bucur
a écrit :
>
> > -Original Message-
> >
> > > Le dim. 14 juil. 2019 à 22:05, Valentin Longchamp
> > > a écrit :
> > > >
> > > > Change all phy-connection-type properties to phy-mode that are better
> > > > supported by the fman driver.
> > > >
> > > > Use the more readable fixed-link node for the 2 sgmii links.
> > > >
> > > > Change the RGMII link to rgmii-id as the clock delays are added by the
> > > > phy.
> > > >
> > > > Signed-off-by: Valentin Longchamp
> >
> > I don't see any other uses of phy-mode in arch/powerpc/boot/dts/fsl, and I
> > see
> > lots of phy-connection-type with fman. Madalin, does this patch look OK?
> >
> > -Scott
>
> Hi,
>
> we are using "phy-connection-type" not "phy-mode" for the NXP (former
> Freescale)
> DPAA platforms. While the two seem to be interchangeable ("phy-mode" seems to
> be
> more recent, looking at the device tree bindings), the driver code in Linux
> seems
> to use one or the other, not both so one should stick with the variant the
> driver
> is using. To make things more complex, there may be dependencies in
> bootloaders,
> I see code in u-boot using only "phy-connection-type" or only "phy-mode".
>
> I'd leave "phy-connection-type" as is.
So I have finally had time to have a look and now I understand what
happens. You are right, there are bootloader dependencies: u-boot
calls fdt_fixup_phy_connection() that somehow in our case adds (or
changes if already in the device tree) the phy-connection-type
property to a wrong value ! By having a phy-mode in the device tree,
that is not changed by u-boot and by chance picked up by the kernel
fman driver (of_get_phy_mode() ) over phy-connection-mode, the below
patch fixes it for us.
I agree with you, it's not correct to have both phy-connection-type
and phy-mode. Ideally, u-boot on the board should be reworked so that
it does not perform the above wrong fixup. However, in an "unfixed"
.dtb (I have disabled fdt_fixup_phy_connection), the device tree in
the end only has either phy-connection-type or phy-mode, according to
what was chosen in the .dts file. And the fman driver works well with
both (thanks to the call to of_get_phy_mode() ). I would therefore
argue that even if all other DPAA platforms use phy-connection-type,
phy-mode is valid as well. (Furthermore we already have hundreds of
such boards in the field and we don't really support "remote" u-boot
update, so the u-boot fix is going to be difficult for us to pull).
Valentin
>
> Madalin
>
> > > > ---
> > > > arch/powerpc/boot/dts/fsl/kmcent2.dts | 16 +++-
> > > > 1 file changed, 11 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/arch/powerpc/boot/dts/fsl/kmcent2.dts
> > > > b/arch/powerpc/boot/dts/fsl/kmcent2.dts
> > > > index 48b7f9797124..c3e0741cafb1 100644
> > > > --- a/arch/powerpc/boot/dts/fsl/kmcent2.dts
> > > > +++ b/arch/powerpc/boot/dts/fsl/kmcent2.dts
> > > > @@ -210,13 +210,19 @@
> > > >
> > > > fman@40 {
> > > > ethernet@e {
> > > > - fixed-link = <0 1 1000 0 0>;
> > > > - phy-connection-type = "sgmii";
> > > > + phy-mode = "sgmii";
> > > > + fixed-link {
> > > > + speed = <1000>;
> > > > + full-duplex;
> > > > + };
> > > > };
> > > >
> > > > ethernet@e2000 {
> > > > - fixed-link = <1 1 1000 0 0>;
> > > > - phy-connection-type = "sgmii";
> > > > + phy-mode = "sgmii";
> > > > + fixed-link {
> > > > + speed = <1000>;
> > > > + full-duplex;
> > > > + };
> > > > };
> > > >
> > > > ethernet@e4000 {
> > > > @@ -229,7 +235,7 @@
> > > >
> > > > ethernet@e8000 {
> > > > phy-handle = <_phy>;
> > > > - phy-connection-type = "rgmii";
> > > > + phy-mode = "rgmii-id";
> > > > };
> > > >
> > > > mdio0: mdio@fc000 {
> > > > --
> > > > 2.17.1
> > > >
> > >
> > >
>
Re: [PATCH] powerpc/kmcent2: update the ethernet devices' phy properties
Le dim. 28 juil. 2019 à 21:26, Scott Wood a écrit :
> On Sun, 2019-07-28 at 18:01 +0200, Valentin Longchamp wrote:
> > Le dim. 14 juil. 2019 à 22:05, Valentin Longchamp
> > a écrit :
> > >
> > > Change all phy-connection-type properties to phy-mode that are better
> > > supported by the fman driver.
> > >
> > > Use the more readable fixed-link node for the 2 sgmii links.
> > >
> > > Change the RGMII link to rgmii-id as the clock delays are added by the
> > > phy.
> > >
> > > Signed-off-by: Valentin Longchamp
>
> I don't see any other uses of phy-mode in arch/powerpc/boot/dts/fsl, and I see
> lots of phy-connection-type with fman. Madalin, does this patch look OK?
The fman driver (mac_probe()) calls of_get_phy_mode() which first
looks for phy-mode, and then phy-connection-type. Both should be the
same according to the device tree binding.
With some older kernels I remember we had issues with
phy-connection-type but not phy-mode, but this is more than 2 years
ago, I don't remember the details. phy-mode works well (tested ~2
weeks ago) with 4.14, 4.19 and 5.2, for sure.
Valentin
>
> -Scott
>
> > > ---
> > > arch/powerpc/boot/dts/fsl/kmcent2.dts | 16 +++-
> > > 1 file changed, 11 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/arch/powerpc/boot/dts/fsl/kmcent2.dts
> > > b/arch/powerpc/boot/dts/fsl/kmcent2.dts
> > > index 48b7f9797124..c3e0741cafb1 100644
> > > --- a/arch/powerpc/boot/dts/fsl/kmcent2.dts
> > > +++ b/arch/powerpc/boot/dts/fsl/kmcent2.dts
> > > @@ -210,13 +210,19 @@
> > >
> > > fman@40 {
> > > ethernet@e {
> > > - fixed-link = <0 1 1000 0 0>;
> > > - phy-connection-type = "sgmii";
> > > + phy-mode = "sgmii";
> > > + fixed-link {
> > > + speed = <1000>;
> > > + full-duplex;
> > > + };
> > > };
> > >
> > > ethernet@e2000 {
> > > - fixed-link = <1 1 1000 0 0>;
> > > - phy-connection-type = "sgmii";
> > > + phy-mode = "sgmii";
> > > + fixed-link {
> > > + speed = <1000>;
> > > + full-duplex;
> > > + };
> > > };
> > >
> > > ethernet@e4000 {
> > > @@ -229,7 +235,7 @@
> > >
> > > ethernet@e8000 {
> > > phy-handle = <_phy>;
> > > - phy-connection-type = "rgmii";
> > > + phy-mode = "rgmii-id";
> > > };
> > >
> > > mdio0: mdio@fc000 {
> > > --
> > > 2.17.1
> > >
> >
> >
>
Re: [PATCH] powerpc/kmcent2: update the ethernet devices' phy properties
Hi Scott, Kumar,
Looking at this patch I have realised that I had already submitted it
to the mailing list nearly 2 years ago:
https://patchwork.ozlabs.org/patch/842944/
Could you please make sure that this one gets merged in the next
window, so that I avoid forgetting such a patch a 2nd time ?
Thanks a lot
Le dim. 14 juil. 2019 à 22:05, Valentin Longchamp
a écrit :
>
> Change all phy-connection-type properties to phy-mode that are better
> supported by the fman driver.
>
> Use the more readable fixed-link node for the 2 sgmii links.
>
> Change the RGMII link to rgmii-id as the clock delays are added by the
> phy.
>
> Signed-off-by: Valentin Longchamp
> ---
> arch/powerpc/boot/dts/fsl/kmcent2.dts | 16 +++-
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/fsl/kmcent2.dts
> b/arch/powerpc/boot/dts/fsl/kmcent2.dts
> index 48b7f9797124..c3e0741cafb1 100644
> --- a/arch/powerpc/boot/dts/fsl/kmcent2.dts
> +++ b/arch/powerpc/boot/dts/fsl/kmcent2.dts
> @@ -210,13 +210,19 @@
>
> fman@40 {
> ethernet@e {
> - fixed-link = <0 1 1000 0 0>;
> - phy-connection-type = "sgmii";
> + phy-mode = "sgmii";
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> };
>
> ethernet@e2000 {
> - fixed-link = <1 1 1000 0 0>;
> - phy-connection-type = "sgmii";
> + phy-mode = "sgmii";
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> };
>
> ethernet@e4000 {
> @@ -229,7 +235,7 @@
>
> ethernet@e8000 {
> phy-handle = <_phy>;
> - phy-connection-type = "rgmii";
> + phy-mode = "rgmii-id";
> };
>
> mdio0: mdio@fc000 {
> --
> 2.17.1
>
--
Valentin Longchamp
Rue de la Carrière 30, CH-1700 Fribourg
valen...@longchamp.me
Mobile: +41 79 569 25 75
[PATCH] powerpc/kmcent2: update the ethernet devices' phy properties
Change all phy-connection-type properties to phy-mode that are better
supported by the fman driver.
Use the more readable fixed-link node for the 2 sgmii links.
Change the RGMII link to rgmii-id as the clock delays are added by the
phy.
Signed-off-by: Valentin Longchamp
---
arch/powerpc/boot/dts/fsl/kmcent2.dts | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/kmcent2.dts
b/arch/powerpc/boot/dts/fsl/kmcent2.dts
index 48b7f9797124..c3e0741cafb1 100644
--- a/arch/powerpc/boot/dts/fsl/kmcent2.dts
+++ b/arch/powerpc/boot/dts/fsl/kmcent2.dts
@@ -210,13 +210,19 @@
fman@40 {
ethernet@e {
- fixed-link = <0 1 1000 0 0>;
- phy-connection-type = "sgmii";
+ phy-mode = "sgmii";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
};
ethernet@e2000 {
- fixed-link = <1 1 1000 0 0>;
- phy-connection-type = "sgmii";
+ phy-mode = "sgmii";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
};
ethernet@e4000 {
@@ -229,7 +235,7 @@
ethernet@e8000 {
phy-handle = <_phy>;
- phy-connection-type = "rgmii";
+ phy-mode = "rgmii-id";
};
mdio0: mdio@fc000 {
--
2.17.1
Re: [PATCH] powerpc/kmcent2: update the ethernet nodes to the internal switch
From: Valentin Longchamp <valentin.longch...@keymile.com>
Sent: Thursday, November 30, 2017 10:16
To: o...@buserror.net; linuxppc-dev@lists.ozlabs.org
Cc: devicet...@vger.kernel.org; valentin.longch...@keymile.com
Subject: [PATCH] powerpc/kmcent2: update the ethernet nodes to the internal
switch
Sorry for the noise, please ignore this patch, I've messed up my rebase with
our internal tree.
The fman driver only calls of_get_phy_node, ignoring the
phy-connection-type field. While we're at it, update the fixed link to
the new more readable way to specify it.
Signed-off-by: Valentin Longchamp <valentin.longch...@keymile.com>
---
arch/powerpc/boot/dts/fsl/kmcent2.dts | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/kmcent2.dts
b/arch/powerpc/boot/dts/fsl/kmcent2.dts
index 5922c1ea0e96..b53ff8f71474 100644
--- a/arch/powerpc/boot/dts/fsl/kmcent2.dts
+++ b/arch/powerpc/boot/dts/fsl/kmcent2.dts
@@ -214,13 +214,19 @@
fman@40 {
ethernet@e {
- fixed-link = <0 1 1000 0 0>;
- phy-connection-type = "sgmii";
+ phy-mode = "sgmii";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
};
ethernet@e2000 {
- fixed-link = <1 1 1000 0 0>;
- phy-connection-type = "sgmii";
+ phy-mode = "sgmii";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
};
ethernet@e4000 {
--
2.14.3
[PATCH] powerpc/kmcent2: update the ethernet nodes to use phy-mode
The fman driver only calls of_get_phy_node, ignoring the
phy-connection-type field. While we're at it, update the fixed link to
the new more readable way to specify it and set phy-mode to rgmii-id for
the node with a phy.
Signed-off-by: Valentin Longchamp <valentin.longch...@keymile.com>
---
arch/powerpc/boot/dts/fsl/kmcent2.dts | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/kmcent2.dts
b/arch/powerpc/boot/dts/fsl/kmcent2.dts
index 5922c1ea0e96..095c9a661a08 100644
--- a/arch/powerpc/boot/dts/fsl/kmcent2.dts
+++ b/arch/powerpc/boot/dts/fsl/kmcent2.dts
@@ -214,13 +214,19 @@
fman@40 {
ethernet@e {
- fixed-link = <0 1 1000 0 0>;
- phy-connection-type = "sgmii";
+ phy-mode = "sgmii";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
};
ethernet@e2000 {
- fixed-link = <1 1 1000 0 0>;
- phy-connection-type = "sgmii";
+ phy-mode = "sgmii";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
};
ethernet@e4000 {
@@ -233,7 +239,7 @@
ethernet@e8000 {
phy-handle = <_phy>;
- phy-connection-type = "rgmii";
+ phy-mode = "rgmii-id";
};
mdio0: mdio@fc000 {
--
2.14.3
[PATCH] powerpc/kmcent2: update the ethernet nodes to the internal switch
The fman driver only calls of_get_phy_node, ignoring the
phy-connection-type field. While we're at it, update the fixed link to
the new more readable way to specify it.
Signed-off-by: Valentin Longchamp <valentin.longch...@keymile.com>
---
arch/powerpc/boot/dts/fsl/kmcent2.dts | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/kmcent2.dts
b/arch/powerpc/boot/dts/fsl/kmcent2.dts
index 5922c1ea0e96..b53ff8f71474 100644
--- a/arch/powerpc/boot/dts/fsl/kmcent2.dts
+++ b/arch/powerpc/boot/dts/fsl/kmcent2.dts
@@ -214,13 +214,19 @@
fman@40 {
ethernet@e {
- fixed-link = <0 1 1000 0 0>;
- phy-connection-type = "sgmii";
+ phy-mode = "sgmii";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
};
ethernet@e2000 {
- fixed-link = <1 1 1000 0 0>;
- phy-connection-type = "sgmii";
+ phy-mode = "sgmii";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
};
ethernet@e4000 {
--
2.14.3
[PATCH v2] net/ethernet/freescale: fix warning for ucc_geth
uf_info.regs is resource_size_t i.e. phys_addr_t that can be either u32
or u64 according to CONFIG_PHYS_ADDR_T_64BIT.
The printk format is thus adaptet to u64 and the regs value cast to u64
to take both u32 and u64 into account.
Signed-off-by: Valentin Longchamp <valentin.longch...@keymile.com>
---
drivers/net/ethernet/freescale/ucc_geth.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c
b/drivers/net/ethernet/freescale/ucc_geth.c
index f77ba9fa257b..a96b838cffce 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -3857,8 +3857,9 @@ static int ucc_geth_probe(struct platform_device* ofdev)
}
if (netif_msg_probe())
- pr_info("UCC%1d at 0x%8x (irq = %d)\n",
- ug_info->uf_info.ucc_num + 1, ug_info->uf_info.regs,
+ pr_info("UCC%1d at 0x%8llx (irq = %d)\n",
+ ug_info->uf_info.ucc_num + 1,
+ (u64)ug_info->uf_info.regs,
ug_info->uf_info.irq);
/* Create an ethernet device instance */
--
2.13.5
[PATCH] net/ethernet/freescale: fix warning for ucc_geth
Simple printk format warning for the the ucc registers address.
Signed-off-by: Valentin Longchamp <valentin.longch...@keymile.com>
---
drivers/net/ethernet/freescale/ucc_geth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c
b/drivers/net/ethernet/freescale/ucc_geth.c
index f77ba9fa257b..56b8fdb35c3b 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -3857,7 +3857,7 @@ static int ucc_geth_probe(struct platform_device* ofdev)
}
if (netif_msg_probe())
- pr_info("UCC%1d at 0x%8x (irq = %d)\n",
+ pr_info("UCC%1d at 0x%8llx (irq = %d)\n",
ug_info->uf_info.ucc_num + 1, ug_info->uf_info.regs,
ug_info->uf_info.irq);
--
2.13.5
[PATCH] net/wan: add MODULE_LICENSE for fsl_ucc_hdlc
It is required to build it as a module.
Signed-off-by: Valentin Longchamp <valentin.longch...@keymile.com>
---
drivers/net/wan/fsl_ucc_hdlc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index e38ce4d..1f38c06 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.c
+++ b/drivers/net/wan/fsl_ucc_hdlc.c
@@ -1175,3 +1175,4 @@ static int ucc_hdlc_remove(struct platform_device *pdev)
};
module_platform_driver(ucc_hdlc_driver);
+MODULE_LICENSE("GPL");
--
1.8.3.1
[PATCH 1/3] soc/fsl/qe: round brg_freq to 1kHz granularity
Because of integer computation rounding in u-boot (that sets the QE
brg-frequency DTS prop), the clk value is Hz even though it is
100 MHz.
When setting brg clks that are exact divisors of 100 MHz, this small
differnce plays a role and can result in lower clks to be output (for
instance 20 MHz - divide by 5 - results in 16.666 MHz - divide by 6).
This patch fixes that by "forcing" the brg_clk to the nearest kHz when
the difference is below 2 integer rouding errors (i.e. 4).
Signed-off-by: Valentin Longchamp <valentin.longch...@keymile.com>
---
drivers/soc/fsl/qe/qe.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index ade168f..03874df 100644
--- a/drivers/soc/fsl/qe/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -163,11 +163,15 @@ int qe_issue_cmd(u32 cmd, u32 device, u8 mcn_protocol,
u32 cmd_input)
*/
static unsigned int brg_clk = 0;
+#define CLK_GRAN (1000)
+#define CLK_GRAN_LIMIT (5)
+
unsigned int qe_get_brg_clk(void)
{
struct device_node *qe;
int size;
const u32 *prop;
+ unsigned int mod;
if (brg_clk)
return brg_clk;
@@ -185,6 +189,15 @@ unsigned int qe_get_brg_clk(void)
of_node_put(qe);
+ /* round this if near to a multiple of CLK_GRAN */
+ mod = brg_clk % CLK_GRAN;
+ if (mod) {
+ if (mod < CLK_GRAN_LIMIT)
+ brg_clk -= mod;
+ else if (mod > (CLK_GRAN - CLK_GRAN_LIMIT))
+ brg_clk += CLK_GRAN - mod;
+ }
+
return brg_clk;
}
EXPORT_SYMBOL(qe_get_brg_clk);
--
1.8.3.1
[PATCH 0/3] soc/fsl: various fixes for QE support
Testing the QE's UCC for our HDLC bus I noticed a few odd things and I have fixed these in these 3 patches. Valentin Longchamp (3): soc/fsl/qe: round brg_freq to 1kHz granularity soc/fsl/qe: only apply QE_General4 workaround on affected SoCs soc/fsl/qe: add EXPORT_SYMBOL for the 2 qe_tdm functions drivers/soc/fsl/qe/qe.c | 21 +++-- drivers/soc/fsl/qe/qe_tdm.c | 2 ++ 2 files changed, 21 insertions(+), 2 deletions(-) -- 1.8.3.1
[PATCH 2/3] soc/fsl/qe: only apply QE_General4 workaround on affected SoCs
The QE_General4 workaround is only valid for the MPC832x and MPC836x
SoCs. The other SoCs that embed a QUICC engine are not affected by this
hardware bug and thus can use the computed divisors (this was
successfully tested on the T1040).
Similalry to what was done in commit 8ce795cb0c6b ("i2c: mpc: assign the
correct prescaler from SVR") in order to avoid changes in
the device tree nodes of the QE (with maybe a variant of the compatible
property), the PVR reg is read out to find out if the workaround must be
applied or not.
Signed-off-by: Valentin Longchamp <valentin.longch...@keymile.com>
---
drivers/soc/fsl/qe/qe.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index 03874df..b66157fc 100644
--- a/drivers/soc/fsl/qe/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -202,6 +202,9 @@ unsigned int qe_get_brg_clk(void)
}
EXPORT_SYMBOL(qe_get_brg_clk);
+#define PVR_VER_836x 0x8083
+#define PVR_VER_832x 0x8084
+
/* Program the BRG to the given sampling rate and multiplier
*
* @brg: the BRG, QE_BRG1 - QE_BRG16
@@ -228,8 +231,9 @@ int qe_setbrg(enum qe_clock brg, unsigned int rate,
unsigned int multiplier)
/* Errata QE_General4, which affects some MPC832x and MPC836x SOCs, says
that the BRG divisor must be even if you're not using divide-by-16
mode. */
- if (!div16 && (divisor & 1) && (divisor > 3))
- divisor++;
+ if (pvr_version_is(PVR_VER_836x) || pvr_version_is(PVR_VER_832x))
+ if (!div16 && (divisor & 1) && (divisor > 3))
+ divisor++;
tempval = ((divisor - 1) << QE_BRGC_DIVISOR_SHIFT) |
QE_BRGC_ENABLE | div16;
--
1.8.3.1
[PATCH 3/3] soc/fsl/qe: add EXPORT_SYMBOL for the 2 qe_tdm functions
This allows to build the fsl_ucc_hdlc driver as a module.
Signed-off-by: Valentin Longchamp <valentin.longch...@keymile.com>
---
drivers/soc/fsl/qe/qe_tdm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/soc/fsl/qe/qe_tdm.c b/drivers/soc/fsl/qe/qe_tdm.c
index a1048b4..f744c21 100644
--- a/drivers/soc/fsl/qe/qe_tdm.c
+++ b/drivers/soc/fsl/qe/qe_tdm.c
@@ -177,6 +177,7 @@ int ucc_of_parse_tdm(struct device_node *np, struct ucc_tdm
*utdm,
devm_iounmap(>dev, utdm->si_regs);
return ret;
}
+EXPORT_SYMBOL(ucc_of_parse_tdm);
void ucc_tdm_init(struct ucc_tdm *utdm, struct ucc_tdm_info *ut_info)
{
@@ -274,3 +275,4 @@ void ucc_tdm_init(struct ucc_tdm *utdm, struct ucc_tdm_info
*ut_info)
break;
}
}
+EXPORT_SYMBOL(ucc_tdm_init);
--
1.8.3.1
[RFC 2/3] soc/fsl/qe: only apply QE_General4 workaround on affected SoCs
The QE_General4 workaround is only valid for the MPC832x and MPC836x
SoCs. The other SoCs that embed a QUICC engine are not affected by this
hardware bug and thus can use the computed divisors (this was
successfully tested on the T1040).
Similalry to what was done in commit 8ce795cb0c6b ("i2c: mpc: assign the
correct prescaler from SVR") in order to avoid changes in
the device tree nodes of the QE (with maybe a variant of the compatible
property), the PVR reg is read out to find out if the workaround must be
applied or not.
Signed-off-by: Valentin Longchamp <valentin.longch...@keymile.com>
---
drivers/soc/fsl/qe/qe.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index 5482302..8cf9493 100644
--- a/drivers/soc/fsl/qe/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -202,6 +202,9 @@ unsigned int qe_get_brg_clk(void)
}
EXPORT_SYMBOL(qe_get_brg_clk);
+#define PVR_VER_836x 0x8083
+#define PVR_VER_832x 0x8084
+
/* Program the BRG to the given sampling rate and multiplier
*
* @brg: the BRG, QE_BRG1 - QE_BRG16
@@ -228,8 +231,9 @@ int qe_setbrg(enum qe_clock brg, unsigned int rate,
unsigned int multiplier)
/* Errata QE_General4, which affects some MPC832x and MPC836x SOCs, says
that the BRG divisor must be even if you're not using divide-by-16
mode. */
- if (!div16 && (divisor & 1) && (divisor > 3))
- divisor++;
+ if (pvr_version_is(PVR_VER_836x) || pvr_version_is(PVR_VER_832x))
+ if (!div16 && (divisor & 1) && (divisor > 3))
+ divisor++;
tempval = ((divisor - 1) << QE_BRGC_DIVISOR_SHIFT) |
QE_BRGC_ENABLE | div16;
--
1.8.3.1
[RFC 3/3] soc/fsl/qe: add EXPORT_SYMBOL for the 2 qe_tdm functions
This allows to build the fsl_ucc_hdlc driver as a module.
Signed-off-by: Valentin Longchamp <valentin.longch...@keymile.com>
---
drivers/soc/fsl/qe/qe_tdm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/soc/fsl/qe/qe_tdm.c b/drivers/soc/fsl/qe/qe_tdm.c
index a1048b4..f744c21 100644
--- a/drivers/soc/fsl/qe/qe_tdm.c
+++ b/drivers/soc/fsl/qe/qe_tdm.c
@@ -177,6 +177,7 @@ int ucc_of_parse_tdm(struct device_node *np, struct ucc_tdm
*utdm,
devm_iounmap(>dev, utdm->si_regs);
return ret;
}
+EXPORT_SYMBOL(ucc_of_parse_tdm);
void ucc_tdm_init(struct ucc_tdm *utdm, struct ucc_tdm_info *ut_info)
{
@@ -274,3 +275,4 @@ void ucc_tdm_init(struct ucc_tdm *utdm, struct ucc_tdm_info
*ut_info)
break;
}
}
+EXPORT_SYMBOL(ucc_tdm_init);
--
1.8.3.1
[RFC 1/3] soc/fsl/qe: round brg_freq to 1kHz granularity
Because of integer computation rounding in u-boot (that sets the QE
brg-frequency DTS prop), the clk value is Hz even though it is
100 MHz.
When setting brg clks that are exact divisors of 100 MHz, this small
differnce plays a role and can result in lower clks to be output (for
instance 20 MHz - divide by 5 - results in 16.666 MHz - divide by 6).
This patch fixes that by "forcing" the brg_clk to the nearest kHz when
the difference is below 2 integer rouding errors (i.e. 4).
Signed-off-by: Valentin Longchamp <valentin.longch...@keymile.com>
---
drivers/soc/fsl/qe/qe.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index 2707a82..5482302 100644
--- a/drivers/soc/fsl/qe/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -163,11 +163,15 @@ int qe_issue_cmd(u32 cmd, u32 device, u8 mcn_protocol,
u32 cmd_input)
*/
static unsigned int brg_clk = 0;
+#define CLK_GRAN (1000)
+#define CLK_GRAN_LIMIT (5)
+
unsigned int qe_get_brg_clk(void)
{
struct device_node *qe;
int size;
const u32 *prop;
+ unsigned int mod;
if (brg_clk)
return brg_clk;
@@ -185,6 +189,15 @@ unsigned int qe_get_brg_clk(void)
of_node_put(qe);
+ /* round this if near to a multiple of CLK_GRAN */
+ mod = brg_clk % CLK_GRAN;
+ if (mod) {
+ if (mod < CLK_GRAN_LIMIT)
+ brg_clk -= mod;
+ else if (mod > (CLK_GRAN - CLK_GRAN_LIMIT))
+ brg_clk += CLK_GRAN - mod;
+ }
+
return brg_clk;
}
EXPORT_SYMBOL(qe_get_brg_clk);
--
1.8.3.1
[RFC 0/3] soc/fsl: various fixes for QE support
Testing the QE's UCC for our HDLC bus I noticed a few odd things and I have fixed these in these 3 patches. Valentin Longchamp (3): soc/fsl/qe: round brg_freq to 1kHz granularity soc/fsl/qe: only apply QE_General4 workaround on affected SoCs soc/fsl/qe: add EXPORT_SYMBOL for the 2 qe_tdm functions drivers/soc/fsl/qe/qe.c | 21 +++-- drivers/soc/fsl/qe/qe_tdm.c | 2 ++ 2 files changed, 21 insertions(+), 2 deletions(-) -- 1.8.3.1
Re: [PATCH 3/3] powerpc/corenet: add support for the kmcent2 board
On 15/12/16 15:00, Joakim Tjernlund wrote:
> On Thu, 2016-12-15 at 14:22 +0100, Valentin Longchamp wrote:
>> This board is built around Freescale's T1040 SoC.
>>
>> The peripherals used by this design are:
>> - DDR3 RAM with SPD support
>> - parallel NOR Flash as boot medium
>> - 1 PCIe bus (PCIe1 x1)
>> - 3 FMAN Ethernet devices (FMAN1 DTSEC1/2/5)
>> - 4 IFC bus devices:
>> - NOR flash
>> - NAND flash
>> - QRIO reset/power mgmt CPLD
>> - BFTIC chassis management CPLD
>> - 2 I2C buses
>> - 1 SPI bus
>> - HDLC bus with the QE's UCC1
>> - last but not least, the mandatory serial port
>>
>> The board can be used with the corenet32_smp_defconfig.
>>
>> Signed-off-by: Valentin Longchamp <valentin.longch...@keymile.com>
>> ---
>> arch/powerpc/boot/dts/fsl/kmcent2.dts | 303
>> ++
>> arch/powerpc/platforms/85xx/corenet_generic.c | 1 +
>> 2 files changed, 304 insertions(+)
>> create mode 100644 arch/powerpc/boot/dts/fsl/kmcent2.dts
>>
>> diff --git a/arch/powerpc/boot/dts/fsl/kmcent2.dts
>> b/arch/powerpc/boot/dts/fsl/kmcent2.dts
>> new file mode 100644
>> index 000..47afa43
>> --- /dev/null
>> +++ b/arch/powerpc/boot/dts/fsl/kmcent2.dts
>> @@ -0,0 +1,303 @@
>> +/*
>> + * Keymile kmcent2 Device Tree Source, based on T1040RDB DTS
>> + *
>> + * (C) Copyright 2016
>> + * Valentin Longchamp, Keymile AG, valentin.longch...@keymile.com
>> + *
>> + * Copyright 2014 - 2015 Freescale Semiconductor Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License as published by the
>> + * Free Software Foundation; either version 2 of the License, or (at your
>> + * option) any later version.
>> + */
>> +
>
> [SNIP]
>
>> +
>> +ucc_hdlc: ucc@2000 {
>> +device_type = "hdlc";
>> +compatible = "fsl,ucc-hdlc";
>> +rx-clock-name = "clk9";
>> +tx-clock-name = "clk9";
>
> Should it be clk9 on both tx and rx clock?
>
Yeah, why not ? The bus clock is generated somewhere else and is connected to
the clk9 input. Or maybe have I not understood your question ?
[PATCH 3/3] powerpc/corenet: add support for the kmcent2 board
This board is built around Freescale's T1040 SoC.
The peripherals used by this design are:
- DDR3 RAM with SPD support
- parallel NOR Flash as boot medium
- 1 PCIe bus (PCIe1 x1)
- 3 FMAN Ethernet devices (FMAN1 DTSEC1/2/5)
- 4 IFC bus devices:
- NOR flash
- NAND flash
- QRIO reset/power mgmt CPLD
- BFTIC chassis management CPLD
- 2 I2C buses
- 1 SPI bus
- HDLC bus with the QE's UCC1
- last but not least, the mandatory serial port
The board can be used with the corenet32_smp_defconfig.
Signed-off-by: Valentin Longchamp <valentin.longch...@keymile.com>
---
arch/powerpc/boot/dts/fsl/kmcent2.dts | 303 ++
arch/powerpc/platforms/85xx/corenet_generic.c | 1 +
2 files changed, 304 insertions(+)
create mode 100644 arch/powerpc/boot/dts/fsl/kmcent2.dts
diff --git a/arch/powerpc/boot/dts/fsl/kmcent2.dts
b/arch/powerpc/boot/dts/fsl/kmcent2.dts
new file mode 100644
index 000..47afa43
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/kmcent2.dts
@@ -0,0 +1,303 @@
+/*
+ * Keymile kmcent2 Device Tree Source, based on T1040RDB DTS
+ *
+ * (C) Copyright 2016
+ * Valentin Longchamp, Keymile AG, valentin.longch...@keymile.com
+ *
+ * Copyright 2014 - 2015 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/include/ "t104xsi-pre.dtsi"
+
+/ {
+ model = "keymile,kmcent2";
+ compatible = "keymile,kmcent2";
+
+ aliases {
+ front_phy = _phy;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ bman_fbpr: bman-fbpr {
+ size = <0 0x100>;
+ alignment = <0 0x100>;
+ };
+ qman_fqd: qman-fqd {
+ size = <0 0x40>;
+ alignment = <0 0x40>;
+ };
+ qman_pfdr: qman-pfdr {
+ size = <0 0x200>;
+ alignment = <0 0x200>;
+ };
+ };
+
+ ifc: localbus@ffe124000 {
+ reg = <0xf 0xfe124000 0 0x2000>;
+ ranges = <0 0 0xf 0xe800 0x0400
+ 1 0 0xf 0xfa00 0x0001
+ 2 0 0xf 0xfb00 0x0001
+ 4 0 0xf 0xc000 0x0800
+ 6 0 0xf 0xd000 0x0800
+ 7 0 0xf 0xd800 0x0800>;
+
+ nor@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x0400>;
+ bank-width = <2>;
+ device-width = <2>;
+ };
+
+ nand@1,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,ifc-nand";
+ reg = <0x1 0x0 0x1>;
+ };
+
+ board-control@2,0 {
+ compatible = "keymile,qriox";
+ reg = <0x2 0x0 0x80>;
+ };
+
+ chassis-mgmt@6,0 {
+ compatible = "keymile,bfticu";
+ reg = <6 0 0x100>;
+ interrupt-controller;
+ interrupt-parent = <>;
+ interrupts = <11 1 0 0>;
+ #interrupt-cells = <1>;
+ };
+
+ };
+
+ memory {
+ device_type = "memory";
+ };
+
+ dcsr: dcsr@f {
+ ranges = <0x 0xf 0x 0x01072000>;
+ };
+
+ bportals: bman-portals@ff400 {
+ ranges = <0x0 0xf 0xf400 0x200>;
+ };
+
+ qportals: qman-portals@ff600 {
+ ranges = <0x0 0xf 0xf600 0x200>;
+ };
+
+ soc: soc@ffe00 {
+ ranges = <0x 0xf 0xfe00 0x100>;
+ reg = <0xf 0xfe00 0 0x1000>;
+
+ spi@11 {
+ network-clock@1 {
+ compatible = "zarlink,zl30364";
+ reg = <1>;
+ spi-max-frequency = <100>;
+ };
+ };
+
+ sdhc@114000 {
+ status = "disabled";
+
[PATCH 2/3] powerpc/85xx: remove the kmp204x_defconfig
It is not maintained and thus obsolete. corenet32_smp_defconfig can be used as reference for the kmcoge4/kmp204x boards. Signed-off-by: Valentin Longchamp <valentin.longch...@keymile.com> --- arch/powerpc/configs/85xx/kmp204x_defconfig | 220 1 file changed, 220 deletions(-) delete mode 100644 arch/powerpc/configs/85xx/kmp204x_defconfig diff --git a/arch/powerpc/configs/85xx/kmp204x_defconfig b/arch/powerpc/configs/85xx/kmp204x_defconfig deleted file mode 100644 index a60..000 --- a/arch/powerpc/configs/85xx/kmp204x_defconfig +++ /dev/null @@ -1,220 +0,0 @@ -CONFIG_PPC_85xx=y -CONFIG_SMP=y -CONFIG_NR_CPUS=8 -CONFIG_SYSVIPC=y -CONFIG_POSIX_MQUEUE=y -CONFIG_AUDIT=y -CONFIG_NO_HZ=y -CONFIG_HIGH_RES_TIMERS=y -CONFIG_BSD_PROCESS_ACCT=y -CONFIG_IKCONFIG=y -CONFIG_IKCONFIG_PROC=y -CONFIG_LOG_BUF_SHIFT=14 -CONFIG_CGROUPS=y -CONFIG_CGROUP_SCHED=y -CONFIG_RELAY=y -CONFIG_BLK_DEV_INITRD=y -CONFIG_KALLSYMS_ALL=y -CONFIG_EMBEDDED=y -CONFIG_PERF_EVENTS=y -CONFIG_SLAB=y -CONFIG_MODULES=y -CONFIG_MODULE_UNLOAD=y -CONFIG_MODULE_FORCE_UNLOAD=y -CONFIG_MODVERSIONS=y -# CONFIG_BLK_DEV_BSG is not set -CONFIG_PARTITION_ADVANCED=y -CONFIG_MAC_PARTITION=y -CONFIG_CORENET_GENERIC=y -CONFIG_MPIC_MSGR=y -CONFIG_HIGHMEM=y -# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set -CONFIG_BINFMT_MISC=m -CONFIG_KEXEC=y -CONFIG_FORCE_MAX_ZONEORDER=13 -CONFIG_PCI=y -CONFIG_PCIEPORTBUS=y -# CONFIG_PCIEASPM is not set -CONFIG_PCI_MSI=y -CONFIG_ADVANCED_OPTIONS=y -CONFIG_LOWMEM_SIZE_BOOL=y -CONFIG_LOWMEM_SIZE=0x2000 -CONFIG_NET=y -CONFIG_PACKET=y -CONFIG_UNIX=y -CONFIG_XFRM_USER=y -CONFIG_XFRM_SUB_POLICY=y -CONFIG_XFRM_STATISTICS=y -CONFIG_NET_KEY=y -CONFIG_NET_KEY_MIGRATE=y -CONFIG_INET=y -CONFIG_IP_MULTICAST=y -CONFIG_IP_ADVANCED_ROUTER=y -CONFIG_IP_MULTIPLE_TABLES=y -CONFIG_IP_ROUTE_MULTIPATH=y -CONFIG_IP_ROUTE_VERBOSE=y -CONFIG_IP_PNP=y -CONFIG_IP_PNP_DHCP=y -CONFIG_IP_PNP_BOOTP=y -CONFIG_IP_PNP_RARP=y -CONFIG_NET_IPIP=y -CONFIG_IP_MROUTE=y -CONFIG_IP_PIMSM_V1=y -CONFIG_IP_PIMSM_V2=y -CONFIG_INET_AH=y -CONFIG_INET_ESP=y -CONFIG_INET_IPCOMP=y -CONFIG_IPV6=y -CONFIG_IP_SCTP=m -CONFIG_TIPC=y -CONFIG_NET_SCHED=y -CONFIG_NET_SCH_CBQ=y -CONFIG_NET_SCH_HTB=y -CONFIG_NET_SCH_HFSC=y -CONFIG_NET_SCH_PRIO=y -CONFIG_NET_SCH_MULTIQ=y -CONFIG_NET_SCH_RED=y -CONFIG_NET_SCH_SFQ=y -CONFIG_NET_SCH_TEQL=y -CONFIG_NET_SCH_TBF=y -CONFIG_NET_SCH_GRED=y -CONFIG_NET_CLS_BASIC=y -CONFIG_NET_CLS_TCINDEX=y -CONFIG_NET_CLS_U32=y -CONFIG_CLS_U32_PERF=y -CONFIG_CLS_U32_MARK=y -CONFIG_NET_CLS_FLOW=y -CONFIG_NET_CLS_CGROUP=y -CONFIG_UEVENT_HELPER_PATH="/sbin/mdev" -CONFIG_DEVTMPFS=y -CONFIG_MTD=y -CONFIG_MTD_CMDLINE_PARTS=y -CONFIG_MTD_BLOCK=y -CONFIG_MTD_CFI=y -CONFIG_MTD_CFI_AMDSTD=y -CONFIG_MTD_PHYSMAP_OF=y -CONFIG_MTD_PHRAM=y -CONFIG_MTD_NAND=y -CONFIG_MTD_NAND_ECC_BCH=y -CONFIG_MTD_NAND_FSL_ELBC=y -CONFIG_MTD_UBI=y -CONFIG_MTD_UBI_GLUEBI=y -CONFIG_BLK_DEV_LOOP=y -CONFIG_BLK_DEV_RAM=y -CONFIG_BLK_DEV_RAM_COUNT=2 -CONFIG_BLK_DEV_RAM_SIZE=2048 -CONFIG_EEPROM_AT24=y -CONFIG_SCSI=y -CONFIG_BLK_DEV_SD=y -CONFIG_CHR_DEV_ST=y -CONFIG_BLK_DEV_SR=y -CONFIG_CHR_DEV_SG=y -CONFIG_SCSI_LOGGING=y -CONFIG_SCSI_SYM53C8XX_2=y -CONFIG_NETDEVICES=y -# CONFIG_NET_VENDOR_3COM is not set -# CONFIG_NET_VENDOR_ADAPTEC is not set -# CONFIG_NET_VENDOR_ALTEON is not set -# CONFIG_NET_VENDOR_AMD is not set -# CONFIG_NET_VENDOR_ATHEROS is not set -# CONFIG_NET_VENDOR_BROADCOM is not set -# CONFIG_NET_VENDOR_BROCADE is not set -# CONFIG_NET_VENDOR_CHELSIO is not set -# CONFIG_NET_VENDOR_CISCO is not set -# CONFIG_NET_VENDOR_DEC is not set -# CONFIG_NET_VENDOR_DLINK is not set -# CONFIG_NET_VENDOR_EMULEX is not set -# CONFIG_NET_VENDOR_EXAR is not set -CONFIG_FSL_PQ_MDIO=y -CONFIG_FSL_XGMAC_MDIO=y -# CONFIG_NET_VENDOR_HP is not set -# CONFIG_NET_VENDOR_INTEL is not set -# CONFIG_NET_VENDOR_MARVELL is not set -# CONFIG_NET_VENDOR_MELLANOX is not set -# CONFIG_NET_VENDOR_MICREL is not set -# CONFIG_NET_VENDOR_MICROCHIP is not set -# CONFIG_NET_VENDOR_MYRI is not set -# CONFIG_NET_VENDOR_NATSEMI is not set -# CONFIG_NET_VENDOR_NVIDIA is not set -# CONFIG_NET_VENDOR_OKI is not set -# CONFIG_NET_PACKET_ENGINE is not set -# CONFIG_NET_VENDOR_QLOGIC is not set -# CONFIG_NET_VENDOR_REALTEK is not set -# CONFIG_NET_VENDOR_RDC is not set -# CONFIG_NET_VENDOR_SEEQ is not set -# CONFIG_NET_VENDOR_SILAN is not set -# CONFIG_NET_VENDOR_SIS is not set -# CONFIG_NET_VENDOR_SMSC is not set -# CONFIG_NET_VENDOR_STMICRO is not set -# CONFIG_NET_VENDOR_SUN is not set -# CONFIG_NET_VENDOR_TEHUTI is not set -# CONFIG_NET_VENDOR_TI is not set -# CONFIG_NET_VENDOR_VIA is not set -# CONFIG_NET_VENDOR_WIZNET is not set -# CONFIG_NET_VENDOR_XILINX is not set -CONFIG_MARVELL_PHY=y -CONFIG_VITESSE_PHY=y -CONFIG_FIXED_PHY=y -# CONFIG_WLAN is not set -# CONFIG_INPUT_MOUSEDEV is not set -# CONFIG_INPUT_KEYBOARD is not set -# CONFIG_INPUT_MOUSE is not set -CONFIG_SERIO_LIBPS2=y -# CONFIG_LEGACY_PTYS is not set -CONFIG_PPC_EPAPR_HV_BYTECHAN=y -CONF
[PATCH 0/3] powerpc: update for the Keymile QorIQ boards
This series contains some updates for the Keymile QorIQ boards. There is a small fix for the kmcoge4 board DTS, the removal of the kmp204x_defconfig file which is unmaintained (corenet32_smp_defconfig can be used instead) and the addition of the kmcent2 board. Valentin Longchamp (3): powerpc/corenet: explicitly disable the SDHC controller on kmcoge4 powerpc/85xx: remove the kmp204x_defconfig powerpc/corenet: add support for the kmcent2 board arch/powerpc/boot/dts/fsl/kmcent2.dts | 303 ++ arch/powerpc/boot/dts/fsl/kmcoge4.dts | 4 + arch/powerpc/configs/85xx/kmp204x_defconfig | 220 --- arch/powerpc/platforms/85xx/corenet_generic.c | 1 + 4 files changed, 308 insertions(+), 220 deletions(-) create mode 100644 arch/powerpc/boot/dts/fsl/kmcent2.dts delete mode 100644 arch/powerpc/configs/85xx/kmp204x_defconfig -- 1.8.3.1
[PATCH 1/3] powerpc/corenet: explicitly disable the SDHC controller on kmcoge4
It is not implemented on the kmcoge4 hardware and if not disabled it
leads to error messages with the corenet32_smp_defconfig.
Signed-off-by: Valentin Longchamp <valentin.longch...@keymile.com>
---
arch/powerpc/boot/dts/fsl/kmcoge4.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/kmcoge4.dts
b/arch/powerpc/boot/dts/fsl/kmcoge4.dts
index ae70a24..e103c0f 100644
--- a/arch/powerpc/boot/dts/fsl/kmcoge4.dts
+++ b/arch/powerpc/boot/dts/fsl/kmcoge4.dts
@@ -83,6 +83,10 @@
};
};
+ sdhc@114000 {
+ status = "disabled";
+ };
+
i2c@119000 {
status = "disabled";
};
--
1.8.3.1
[PATCH v2] powerpc: define the fman node for the kmcoge4 DTS
Now that the FMAN mac driver has been merged the fman node is relevant.
The kmcoge4 board implements 3 ethernet interfaces, 1 with a RGMII phy
and 2 with fixed 1 Giga SGMII links.
Signed-off-by: Valentin Longchamp <valentin.longch...@keymile.com>
---
arch/powerpc/boot/dts/fsl/kmcoge4.dts | 37 +++
1 file changed, 37 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/kmcoge4.dts
b/arch/powerpc/boot/dts/fsl/kmcoge4.dts
index 6858ec9..67bfcec 100644
--- a/arch/powerpc/boot/dts/fsl/kmcoge4.dts
+++ b/arch/powerpc/boot/dts/fsl/kmcoge4.dts
@@ -106,6 +106,43 @@
sata@221000 {
status = "disabled";
};
+
+ fman0: fman@40 {
+ enet0: ethernet@e {
+ phy-connection-type = "sgmii";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ mdio0: mdio@e1120 {
+ front_phy: ethernet-phy@11 {
+ reg = <0x11>;
+ };
+ };
+
+ enet1: ethernet@e2000 {
+ phy-connection-type = "sgmii";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ enet2: ethernet@e4000 {
+ status = "disabled";
+ };
+
+ enet3: ethernet@e6000 {
+ status = "disabled";
+ };
+ enet4: ethernet@e8000 {
+ phy-handle = <_phy>;
+ phy-connection-type = "rgmii";
+ };
+ enet5: ethernet@f {
+ status = "disabled";
+ };
+ };
};
rio: rapidio@ffe0c {
--
1.8.3.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: define the fman node for the kmcoge4 DTS
On 17/04/16 03:49, Scott Wood wrote:
> On Thu, 2016-04-07 at 08:14 +0200, Valentin Longchamp wrote:
>> On 06/04/16 23:49, Scott Wood wrote:
>>> On Wed, 2016-04-06 at 15:37 +0200, Valentin Longchamp wrote:
>>>> Now that the FMAN mac driver has been merged the fman node is relevant.
>>>>
>>>> The kmcoge4 board implements 3 ethernet interfaces, 1 with a RGMII phy
>>>> and 2 with fixed 1 Giga SGMII links.
>>>>
>>>> Signed-off-by: Valentin Longchamp <valentin.longch...@keymile.com>
>>>> ---
>>>> arch/powerpc/boot/dts/fsl/kmcoge4.dts | 39
>>>> +++
>>>> 1 file changed, 39 insertions(+)
>>>>
>>>> diff --git a/arch/powerpc/boot/dts/fsl/kmcoge4.dts
>>>> b/arch/powerpc/boot/dts/fsl/kmcoge4.dts
>>>> index 6858ec9..1cec66d 100644
>>>> --- a/arch/powerpc/boot/dts/fsl/kmcoge4.dts
>>>> +++ b/arch/powerpc/boot/dts/fsl/kmcoge4.dts
>>>> @@ -106,6 +106,45 @@
>>>>sata@221000 {
>>>>status = "disabled";
>>>>};
>>>> +
>>>> + fman0: fman@40 {
>>>> + enet0: ethernet@e {
>>>> + phy-connection-type = "sgmii";
>>>> + local-mac-address = [00 11 22 33 44
>>>> 55];
>>>> + fixed-link {
>>>> + speed = <1000>;
>>>> + full-duplex;
>>>> + };
>>>> + };
>>>> + mdio0: mdio@e1120 {
>>>> + front_phy: ethernet-phy@11 {
>>>> + reg = <0x11>;
>>>> + };
>>>> + };
>>>> +
>>>> + enet1: ethernet@e2000 {
>>>> + phy-connection-type = "sgmii";
>>>> + local-mac-address = [00 11 22 33 44
>>>> 56];
>>>> + fixed-link {
>>>> + speed = <1000>;
>>>> + full-duplex;
>>>> + };
>>>> + };
>>>
>>> No hardcoded MAC addresses.
>>>
>>
>> For these 2 interfaces where I have the local-mac-address field, the MAC
>> addresses are set later by an application that reads the real address in
>> some
>> EEPROM. However, in order to let the fman mac_probe to run successfully in
>> the
>> first place I have set non-zero MAC addresses since the local-mac-address
>> fields
>> are not set by u-boot.
>
> Why can't it be set from U-Boot?
It can and should be set from u-boot. It's an old leftover from the vxworks time
where all the MAC addresses where set from the vxworks application itself. When
the company migrated to embedded Linux, they only implemented setting the MAC
address for the "debug" Ethernet interface in u-boot (for NFS boot). The other
were still controlled by the application after the Kernel boot and since then it
has remained so.
I will write this down on the (long) list of remaining vxworks migration
cleanups.
>
> If you absolutely must hardcode a mac address, use one with the locally
> -administered bit set (0x02 in the first byte).
I don't think this is necessary. As you hinted above, the correct way would be
to set them from u-boot and there is nothing that would prevent it other than
actually implementing it (u-boot actually has access to the MAC-address list of
the board).
I send a v2 patch without these fields.
>
>> I have found several local-mac-address fields in other DTS files that are
>> all
>> zeros, and thus are rejected by of_get_mac_address. Are they leftovers from
>> the
>> past or should they be used here as well ? If not, I will simply drop these
>> 2
>> fields.
>
> That's a relic from ancient U-Boots that could only overwrite existing
> properties rather than insert them from scratch.
>
OK, interesting to know, thanks for the explanation.
Valentin
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: define the fman node for the kmcoge4 DTS
On 06/04/16 23:49, Scott Wood wrote:
> On Wed, 2016-04-06 at 15:37 +0200, Valentin Longchamp wrote:
>> Now that the FMAN mac driver has been merged the fman node is relevant.
>>
>> The kmcoge4 board implements 3 ethernet interfaces, 1 with a RGMII phy
>> and 2 with fixed 1 Giga SGMII links.
>>
>> Signed-off-by: Valentin Longchamp <valentin.longch...@keymile.com>
>> ---
>> arch/powerpc/boot/dts/fsl/kmcoge4.dts | 39
>> +++
>> 1 file changed, 39 insertions(+)
>>
>> diff --git a/arch/powerpc/boot/dts/fsl/kmcoge4.dts
>> b/arch/powerpc/boot/dts/fsl/kmcoge4.dts
>> index 6858ec9..1cec66d 100644
>> --- a/arch/powerpc/boot/dts/fsl/kmcoge4.dts
>> +++ b/arch/powerpc/boot/dts/fsl/kmcoge4.dts
>> @@ -106,6 +106,45 @@
>> sata@221000 {
>> status = "disabled";
>> };
>> +
>> +fman0: fman@40 {
>> +enet0: ethernet@e {
>> +phy-connection-type = "sgmii";
>> +local-mac-address = [00 11 22 33 44 55];
>> +fixed-link {
>> +speed = <1000>;
>> +full-duplex;
>> +};
>> +};
>> +mdio0: mdio@e1120 {
>> +front_phy: ethernet-phy@11 {
>> +reg = <0x11>;
>> +};
>> +};
>> +
>> +enet1: ethernet@e2000 {
>> +phy-connection-type = "sgmii";
>> +local-mac-address = [00 11 22 33 44 56];
>> +fixed-link {
>> +speed = <1000>;
>> +full-duplex;
>> +};
>> +};
>
> No hardcoded MAC addresses.
>
For these 2 interfaces where I have the local-mac-address field, the MAC
addresses are set later by an application that reads the real address in some
EEPROM. However, in order to let the fman mac_probe to run successfully in the
first place I have set non-zero MAC addresses since the local-mac-address fields
are not set by u-boot.
I have found several local-mac-address fields in other DTS files that are all
zeros, and thus are rejected by of_get_mac_address. Are they leftovers from the
past or should they be used here as well ? If not, I will simply drop these 2
fields.
Thanks
Valentin
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: define the fman node for the kmcoge4 DTS
Now that the FMAN mac driver has been merged the fman node is relevant.
The kmcoge4 board implements 3 ethernet interfaces, 1 with a RGMII phy
and 2 with fixed 1 Giga SGMII links.
Signed-off-by: Valentin Longchamp <valentin.longch...@keymile.com>
---
arch/powerpc/boot/dts/fsl/kmcoge4.dts | 39 +++
1 file changed, 39 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/kmcoge4.dts
b/arch/powerpc/boot/dts/fsl/kmcoge4.dts
index 6858ec9..1cec66d 100644
--- a/arch/powerpc/boot/dts/fsl/kmcoge4.dts
+++ b/arch/powerpc/boot/dts/fsl/kmcoge4.dts
@@ -106,6 +106,45 @@
sata@221000 {
status = "disabled";
};
+
+ fman0: fman@40 {
+ enet0: ethernet@e {
+ phy-connection-type = "sgmii";
+ local-mac-address = [00 11 22 33 44 55];
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ mdio0: mdio@e1120 {
+ front_phy: ethernet-phy@11 {
+ reg = <0x11>;
+ };
+ };
+
+ enet1: ethernet@e2000 {
+ phy-connection-type = "sgmii";
+ local-mac-address = [00 11 22 33 44 56];
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ enet2: ethernet@e4000 {
+ status = "disabled";
+ };
+
+ enet3: ethernet@e6000 {
+ status = "disabled";
+ };
+ enet4: ethernet@e8000 {
+ phy-handle = <_phy>;
+ phy-connection-type = "rgmii";
+ };
+ enet5: ethernet@f {
+ status = "disabled";
+ };
+ };
};
rio: rapidio@ffe0c {
--
1.8.3.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC 00/10] introduce DPAA Ethernet driver
On 04/01/2015 06:19 PM, Madalin Bucur wrote: This is the second version of a patch series that adds the Ethernet driver for the Freescale QorIQ Data Path Acceleration Architecture (DPAA). This second version includes the changes requested by Kumar Gala. The PM ops patch was removed as the supporting FMan driver code was de-featured from the first submission of the driver to reduce the review effort. Together with the driver a managed version of alloc_percpu is provided that simplifies the release of percpu memory. The Freescale DPAA architecture consists in a series of hardware blocks that support the Ethernet connectivity. the Ethernet driver depends upon the Peripheral Access Memory Unit (PAMU), Frame Manager (FMan), Queue Manager (QMan), Buffer Manager (BMan). Drivers for these blocks are currently in the kernel or in review. The current set of RFC patches is meant to provide early access to the codebase and also provide context and aid the review of the latest FMan driver patches submitted by Igal Liberman: [RFC,v2,12/12] soc/fman: Add FMan MAC driver [RFC,v2,11/12] soc/fman: Add FMan Port Support [RFC,v2,10/12] soc/fman: Add FMan SP support [RFC,v2,09/12] soc/fman: Add FMan MAC support [RFC,v2,08/12] soc/fman: Add Frame Manager support [RFC,v2,07/12] soc/fman: Add FMan MURAM support [RFC,v2,06/12] soc/fman: Add the FMan MAC FLIB [RFC,v2,05/12] soc/fman: Add the FMan MAC FLIB headers [RFC,v2,04/12] soc/fman: Add the FMan port FLIB [RFC,v2,03/12] soc/fman: Add the FMan port FLIB headers [RFC,v2,02/12] soc/fman: Add the FMan FLIB [RFC,v2,01/12] soc/fman: Add the FMan FLIB headers https://patchwork.ozlabs.org/project/linuxppc-dev/list/?submitter=Igal.Libermanstate=*q=RFC%2Cv2 These patches rely also on the Q/BMan drivers submitted by Emil Medve: [RFC,v3,10/10] fsl_qman: Add HOTPLUG_CPU support [RFC,v3,09/10] fsl_bman: Add HOTPLUG_CPU support [RFC,v3,08/10] fsl_qman: Add debugfs support [RFC,v3,07/10] fsl_bman: Add debugfs support [RFC,v3,06/10] fsl_qman: Add self-tester [RFC,v3,05/10] fsl_bman: Add self-tester [RFC,v3,04/10] powerpc/mpc85xx: Add platform support for the Freescale DPAA QMan [RFC,v3,03/10] powerpc/mpc85xx: Add platform support for the Freescale DPAA BMan [RFC,v3,02/10] fsl_qman: Add drivers for the Freescale DPAA QMan [RFC,v3,01/10] fsl_bman: Add drivers for the Freescale DPAA BMan https://patchwork.ozlabs.org/project/linuxppc-dev/list/?submitter=Emil+Medvestate=*q=RFC Hello Madalin, Thank you very much for this summary that helps keeping an overview on the current Freescale mainline DPAA effort (by the way, I am also very pleased to see these patches getting to the mailing-lists, this is very important to us). Now I would like to give all this a try on our P2041 board, the kmcoge4 for which there is a DT in mainline. Could you please tell me on what kernel branch these patches are based on ? Best Regards Valentin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] i2c-qoriq: modified compatibility for correct prescaler
Wolfgang, Scott, On 12/11/2014 02:44 PM, Valentin Longchamp wrote: Hi all, Picking up this issue again. On 11/26/2014 02:41 AM, Scott Wood wrote: On Tue, 2014-11-25 at 19:13 +0100, Wolfram Sang wrote: On Mon, Nov 17, 2014 at 07:28:03PM -0600, Scott Wood wrote: On Fri, 2014-11-14 at 09:28 +0100, Wolfram Sang wrote: If we're going to change the device tree I'd rather just add a property to say what the prescaler is. We would however, leave the boards' device trees that use things like fsl,mpc8543-i2c as is and introduce the prescaler for the others requiring it. Now the drawback is that the driver would require a change, to parse this prescaler new prescaler property. Would this be OK from your point of view Wolfram ? If yes, I will send the patches for it. I don't think it is OK. Why? Because I thought it could be deduced. Then, a seperate property would not be OK. I'd think it can be deduced from the compatible property. For almost all existing device trees it cannot be. Pity :( If we do introduce a new property, it should probably be clock-div. Grepping through binding documentation, that seems accepted. We should ask DT maintainers, too, to be safe. If you want something that will work without changing device trees, you'll need to use SVR to identify the SoC. The driver is doing that already, see mpc_i2c_get_sec_cfg_8xxx(). Dunno if it makes sense to add to it for consistency reasons? That's not SVR, but sure. Better to avoid messing with existing device trees. What is then the agreement here ? Add a clock-div to the device trees ? Or do something similar to mpc_i2c_get_sec_cfg_8xxx() ? I think the clock-div property is better according to Freescale's AN 2919 section 3.1 Source clock. All the source clocks are fixed (with a clock-div of 2 in case of mpc8536/43/45/47/48/67/68/72, plus p2020) except for the mpc8533/44 where it can be 2 or 3, and that's what mpc_i2c_get_sec_cfg_8xxx() determines. So mpc_i2c_get_sec_cfg_8xxx() should remain the exception and the other prescaler values should be derived from an additional clock-div that must be added in the respective device trees (at least for the qoriq devices, because for instance mpc8543 already has the correct prescaler thanks to mpc_i2c_data_8543 from i2c-mpc.c). Do you have an opinion on the above ? Valentin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] i2c-qoriq: modified compatibility for correct prescaler
Hi all, Picking up this issue again. On 11/26/2014 02:41 AM, Scott Wood wrote: On Tue, 2014-11-25 at 19:13 +0100, Wolfram Sang wrote: On Mon, Nov 17, 2014 at 07:28:03PM -0600, Scott Wood wrote: On Fri, 2014-11-14 at 09:28 +0100, Wolfram Sang wrote: If we're going to change the device tree I'd rather just add a property to say what the prescaler is. We would however, leave the boards' device trees that use things like fsl,mpc8543-i2c as is and introduce the prescaler for the others requiring it. Now the drawback is that the driver would require a change, to parse this prescaler new prescaler property. Would this be OK from your point of view Wolfram ? If yes, I will send the patches for it. I don't think it is OK. Why? Because I thought it could be deduced. Then, a seperate property would not be OK. I'd think it can be deduced from the compatible property. For almost all existing device trees it cannot be. Pity :( If we do introduce a new property, it should probably be clock-div. Grepping through binding documentation, that seems accepted. We should ask DT maintainers, too, to be safe. If you want something that will work without changing device trees, you'll need to use SVR to identify the SoC. The driver is doing that already, see mpc_i2c_get_sec_cfg_8xxx(). Dunno if it makes sense to add to it for consistency reasons? That's not SVR, but sure. Better to avoid messing with existing device trees. What is then the agreement here ? Add a clock-div to the device trees ? Or do something similar to mpc_i2c_get_sec_cfg_8xxx() ? I think the clock-div property is better according to Freescale's AN 2919 section 3.1 Source clock. All the source clocks are fixed (with a clock-div of 2 in case of mpc8536/43/45/47/48/67/68/72, plus p2020) except for the mpc8533/44 where it can be 2 or 3, and that's what mpc_i2c_get_sec_cfg_8xxx() determines. So mpc_i2c_get_sec_cfg_8xxx() should remain the exception and the other prescaler values should be derived from an additional clock-div that must be added in the respective device trees (at least for the qoriq devices, because for instance mpc8543 already has the correct prescaler thanks to mpc_i2c_data_8543 from i2c-mpc.c). Valentin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] i2c-qoriq: modified compatibility for correct prescaler
On 11/13/2014 01:34 AM, Wolfram Sang wrote: If we wanted to be on the safe side and strict (since we are not sure that the hardware is 100% compatible), we maybe should add a fsl,qoriq-i2c compatible to the driver that does the same as mpc8543-i2c. Or you leave the driver as is and use both compatibles: compatible = fsl,qoriq-i2c, fsl,mpc8543-i2c, fsl-i2c; ? I like Scott's proposition to add the prescaler in the device tree more. From the hardware description point of view, it makes more sense: the devices are all just fsl-i2c, with a different prescaler. I just quote it below as a reminder. If we're going to change the device tree I'd rather just add a property to say what the prescaler is. We would however, leave the boards' device trees that use things like fsl,mpc8543-i2c as is and introduce the prescaler for the others requiring it. Now the drawback is that the driver would require a change, to parse this prescaler new prescaler property. Would this be OK from your point of view Wolfram ? If yes, I will send the patches for it. Valentin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] i2c-qoriq: modified compatibility for correct prescaler
On 10/29/2014 12:08 AM, Scott Wood wrote:
On Fri, 2014-10-17 at 11:27 +0200, Valentin Longchamp wrote:
With fsl-i2c compatibility the i2c frequency is not set
correctly, because it sets no prescaler. According to the AN2919 from
Freescale and the QorIQ (P2041) documentation, the source clock is 1/2
the platform clock. This implies that a prescaler of 2 must be used.
This changes the compatibility of the qoriq-i2c .dtsi files to pick the
mpc8543, which uses the same driver but sets the correct prescaler.
Signed-off-by: Rainer Boschung rainer.bosch...@keymile.com
Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com
---
arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi | 4 ++--
arch/powerpc/boot/dts/fsl/qoriq-i2c-1.dtsi | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi
b/arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi
index 5f9bf7d..aa6c366 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi
@@ -36,7 +36,7 @@ i2c@118000 {
#address-cells = 1;
#size-cells = 0;
cell-index = 0;
-compatible = fsl-i2c;
+compatible = fsl,mpc8543-i2c, fsl-i2c;
reg = 0x118000 0x100;
interrupts = 38 2 0 0;
dfsrr;
@@ -46,7 +46,7 @@ i2c@118100 {
#address-cells = 1;
#size-cells = 0;
cell-index = 1;
-compatible = fsl-i2c;
+compatible = fsl,mpc8543-i2c, fsl-i2c;
reg = 0x118100 0x100;
interrupts = 38 2 0 0;
dfsrr;
Are all chips that use this dtsi 100% compatible with mpc8543's i2c, or
just in ways the Linux driver cares about?
I have just looked briefly at the mpc8548 RM (covers mpc8543) and its i2c
controller looks the same as the qoriq's. I cannot however state if they are
100% compatible.
If we wanted to be on the safe side and strict (since we are not sure that the
hardware is 100% compatible), we maybe should add a fsl,qoriq-i2c compatible to
the driver that does the same as mpc8543-i2c.
What about fsl,mpc8544-i2c, which has additional special handling in the
driver, but is only used in socrates.dts (not mpc8544ds.dts)?
From the mpc8544 RM, this controller looks the same as the above 2, except for
the prescaler from the driver which is set to 3. As to why it is only used in
the socrates.dts, I cannot comment about it.
The prescaler is confirmed to be 3 by default by the Table 3 of the AN-219 for
the mpc8544.
What about pq3-i2c-*.dtsi?
This is also interesting: from the AN-219 Table 4, some pq3 have a 2:1
(mcpc8536/43/45/47/48/67/68/72, plus p2020) prescaler where some don't
(mpc8533/44, where it can be 3:1 -default- or 2:1). However pq3-i2c-*.dtsi
defines no prescaler.
Now if I look at what files include these pq3-i2c-*.dtsi, I see some that are in
the the 2:1 list:
arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi
arch/powerpc/boot/dts/fsl/mpc8548si-post.dtsi
arch/powerpc/boot/dts/fsl/mpc8568si-post.dtsi
arch/powerpc/boot/dts/fsl/mpc8572si-post.dtsi
arch/powerpc/boot/dts/fsl/p2020si-post.dtsi
I don't have any hardware to do some tests with these, but from my measurements
on our qoriq based system (P2041 SoC) I think that the generated I2C clocks for
the above SoC currently are not correct because of the ignored prescaler.
Valentin
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] i2c-qoriq: modified compatibility for correct prescaler
With fsl-i2c compatibility the i2c frequency is not set
correctly, because it sets no prescaler. According to the AN2919 from
Freescale and the QorIQ (P2041) documentation, the source clock is 1/2
the platform clock. This implies that a prescaler of 2 must be used.
This changes the compatibility of the qoriq-i2c .dtsi files to pick the
mpc8543, which uses the same driver but sets the correct prescaler.
Signed-off-by: Rainer Boschung rainer.bosch...@keymile.com
Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com
---
arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi | 4 ++--
arch/powerpc/boot/dts/fsl/qoriq-i2c-1.dtsi | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi
b/arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi
index 5f9bf7d..aa6c366 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi
@@ -36,7 +36,7 @@ i2c@118000 {
#address-cells = 1;
#size-cells = 0;
cell-index = 0;
- compatible = fsl-i2c;
+ compatible = fsl,mpc8543-i2c, fsl-i2c;
reg = 0x118000 0x100;
interrupts = 38 2 0 0;
dfsrr;
@@ -46,7 +46,7 @@ i2c@118100 {
#address-cells = 1;
#size-cells = 0;
cell-index = 1;
- compatible = fsl-i2c;
+ compatible = fsl,mpc8543-i2c, fsl-i2c;
reg = 0x118100 0x100;
interrupts = 38 2 0 0;
dfsrr;
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-i2c-1.dtsi
b/arch/powerpc/boot/dts/fsl/qoriq-i2c-1.dtsi
index 7989bf5..b697a3b 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-i2c-1.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-i2c-1.dtsi
@@ -36,7 +36,7 @@ i2c@119000 {
#address-cells = 1;
#size-cells = 0;
cell-index = 2;
- compatible = fsl-i2c;
+ compatible = fsl,mpc8543-i2c, fsl-i2c;
reg = 0x119000 0x100;
interrupts = 39 2 0 0;
dfsrr;
@@ -46,7 +46,7 @@ i2c@119100 {
#address-cells = 1;
#size-cells = 0;
cell-index = 3;
- compatible = fsl-i2c;
+ compatible = fsl,mpc8543-i2c, fsl-i2c;
reg = 0x119100 0x100;
interrupts = 39 2 0 0;
dfsrr;
--
1.8.0.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/mpc85xx: fix fsl/p2041-post.dtsi clockgen mux2
The mux2 node is missing the clock-output-names field that is required
by the clk-ppc-corenet driver.
Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com
---
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
b/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
index e2987a3..45ce43c 100644
--- a/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
@@ -358,6 +358,7 @@
compatible = fsl,qoriq-core-mux-1.0;
clocks = pll0 0, pll0 1, pll1 0, pll1 1;
clock-names = pll0, pll0-div2, pll1, pll1-div2;
+ clock-output-names = cmux2;
};
mux3: mux3@60 {
--
1.8.0.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 0/3] Support of the kmcoge4 board
This series adds support for Keymile's COGE4 board, called kmcoge4. This board is the reference design for further designs at Keymile around the P2040/P2041 SoCs from Freescale. This reference design is internally called kmp204x. Changes in v4: - remove the addition of the KEYMILE vendor-prefix as it is already picked by Rob - Take Scott's and Rob's comments regarding the bindings for the interrupt-cells into account - remove the partition layout for the NAND Flash as well as it was forgotten - Rebased on top of v3.15-rc1 Changes in v3: - add a patch with the bindings for the KEYMILE FPGAs - add the compatible strings for the localbus nodes - remove the IRQ part of the board-control node as it is currently being reworked Changes in v2: - add a patch so that the Zarlink vendor prefix is defined - add some nodes on the localbus CS when possible - only use the corenet_generic machine and add kmcoge4 to the supported boards instead of defining a new kmp204x machine - set better and more precise device nodes for the spi devices - remove the partion layout for the spi_flash@0 Valentin Longchamp (3): devicetree: bindings: add Zarlink to the vendor prefixes devcietree: bindings: add some MFD Keymile FPGAs powerpc/mpc85xx: add support for Keymile's kmcoge4 board Documentation/devicetree/bindings/mfd/bfticu.txt | 25 +++ Documentation/devicetree/bindings/mfd/qriox.txt| 17 ++ .../devicetree/bindings/vendor-prefixes.txt| 1 + arch/powerpc/boot/dts/kmcoge4.dts | 152 ++ arch/powerpc/configs/85xx/kmp204x_defconfig| 225 + arch/powerpc/platforms/85xx/Kconfig| 2 +- arch/powerpc/platforms/85xx/corenet_generic.c | 3 +- 7 files changed, 423 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/bfticu.txt create mode 100644 Documentation/devicetree/bindings/mfd/qriox.txt create mode 100644 arch/powerpc/boot/dts/kmcoge4.dts create mode 100644 arch/powerpc/configs/85xx/kmp204x_defconfig -- 1.8.0.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 1/3] devicetree: bindings: add Zarlink to the vendor prefixes
Even though the company belongs to Microsemi, many chips are still labeled as Zarlink. Among them is the family of network clock generators, the zl3034x. Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com --- Changes in v4: None Changes in v3: None Changes in v2: - add a patch so that the Zarlink vendor prefix is defined Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 0f01c9b..93cc7dc 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -119,3 +119,4 @@ wlf Wolfson Microelectronics wm Wondermedia Technologies, Inc. xesExtreme Engineering Solutions (X-ES) xlnx Xilinx +zarlinkZarlink Semiconductor -- 1.8.0.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 3/3] powerpc/mpc85xx: add support for Keymile's kmcoge4 board
This patch introduces the support for Keymile's kmcoge4 board which is
the internal reference design for boards based on Freescale's
P2040/P2041 SoCs. This internal reference design is named kmp204x.
The peripherals used on this board are:
- SPI NOR Flash as bootloader medium
- NAND Flash with a ubi partition
- 2 PCIe busses (hosts 1 and 3)
- 3 FMAN Ethernet devices (FMAN1 DTSEC1/2/5)
- 4 Local Bus windows, with one dedicated to the QRIO reset/power mgmt
CPLD
- 2 I2C busses
- last but not least, the mandatory serial port
The patch also adds a defconfig file for this reference design that is
necessary because of the lowmem option that must be set higher due to
the number of PCIe devices with big ioremapped mem ranges on the boad.
Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com
---
Changes in v4:
- remove the partition layout for the NAND Flash as well as it was
forgotten
- Rebased on top of v3.15-rc1
Changes in v3:
- add the compatible strings for the localbus nodes
- remove the IRQ part of the board-control node as it is currently being
reworked
Changes in v2:
- add some nodes on the localbus CS when possible
- only use the corenet_generic machine and add kmcoge4 to the supported
boards instead of defining a new kmp204x machine
- set better and more precise device nodes for the spi devices
- remove the partion layout for the spi_flash@0
arch/powerpc/boot/dts/kmcoge4.dts | 152 +
arch/powerpc/configs/85xx/kmp204x_defconfig | 225 ++
arch/powerpc/platforms/85xx/Kconfig | 2 +-
arch/powerpc/platforms/85xx/corenet_generic.c | 3 +-
4 files changed, 380 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/boot/dts/kmcoge4.dts
create mode 100644 arch/powerpc/configs/85xx/kmp204x_defconfig
diff --git a/arch/powerpc/boot/dts/kmcoge4.dts
b/arch/powerpc/boot/dts/kmcoge4.dts
new file mode 100644
index 000..89b4119
--- /dev/null
+++ b/arch/powerpc/boot/dts/kmcoge4.dts
@@ -0,0 +1,152 @@
+/*
+ * Keymile kmcoge4 Device Tree Source, based on the P2041RDB DTS
+ *
+ * (C) Copyright 2014
+ * Valentin Longchamp, Keymile AG, valentin.longch...@keymile.com
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/include/ fsl/p2041si-pre.dtsi
+
+/ {
+ model = keymile,kmcoge4;
+ compatible = keymile,kmcoge4, keymile,kmp204x;
+ #address-cells = 2;
+ #size-cells = 2;
+ interrupt-parent = mpic;
+
+ memory {
+ device_type = memory;
+ };
+
+ dcsr: dcsr@f {
+ ranges = 0x 0xf 0x 0x01008000;
+ };
+
+ soc: soc@ffe00 {
+ ranges = 0x 0xf 0xfe00 0x100;
+ reg = 0xf 0xfe00 0 0x1000;
+ spi@11 {
+ flash@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = spansion,s25fl256s1;
+ reg = 0;
+ spi-max-frequency = 2000; /* input clock
*/
+ };
+
+ network_clock@1 {
+ compatible = zarlink,zl30343;
+ reg = 1;
+ spi-max-frequency = 800;
+ };
+
+ flash@2 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = micron,m25p32;
+ reg = 2;
+ spi-max-frequency = 1500;
+ };
+ };
+
+ i2c@119000 {
+ status = disabled;
+ };
+
+ i2c@119100 {
+ status = disabled;
+ };
+
+ usb0: usb@21 {
+ status = disabled;
+ };
+
+ usb1: usb@211000 {
+ status = disabled;
+ };
+
+ sata@22 {
+ status = disabled;
+ };
+
+ sata@221000 {
+ status = disabled;
+ };
+ };
+
+ rio: rapidio@ffe0c {
+ status = disabled;
+ };
+
+ lbc: localbus@ffe124000 {
+ reg = 0xf 0xfe124000 0 0x1000;
+ ranges = 0 0 0xf 0xffa0 0x0004 /* LB 0 */
+ 1 0 0xf 0xfb00 0x0001 /* LB 1 */
+ 2 0 0xf 0xd000 0x1000 /* LB 2
Re: [PATCH v3 2/3] devcietree: bindings: add some MFD Keymile FPGAs
On 04/09/2014 02:44 AM, Scott Wood wrote:
On Tue, 2014-03-25 at 14:41 +0100, Valentin Longchamp wrote:
These are the bindings for 2 MFD devices used on some of the Keymile boards.
The first one is the chassis managmenet bfticu FPGA.
The second one is the board controller (reset, LEDs, GPIOs) QRIO CPDL.
These FPGAs are used in the kmcoge4 board.
This patch also add KEYMILE to the vendor-prefixes.
Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com
---
Changes in v3:
- add a patch with the bindings for the KEYMILE FPGAs
Changes in v2: None
Documentation/devicetree/bindings/mfd/bfticu.txt | 26
++
Documentation/devicetree/bindings/mfd/qriox.txt| 17 ++
.../devicetree/bindings/vendor-prefixes.txt| 1 +
3 files changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/bfticu.txt
create mode 100644 Documentation/devicetree/bindings/mfd/qriox.txt
diff --git a/Documentation/devicetree/bindings/mfd/bfticu.txt
b/Documentation/devicetree/bindings/mfd/bfticu.txt
new file mode 100644
index 000..92de32e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/bfticu.txt
@@ -0,0 +1,26 @@
+KEYMILE bfticu Chassis Management FPGA
+
+The bfticu is a multifunction device that manages the whole chassis.
+Its main functionality is to collect IRQs from the whole chassis and signals
+them to a single controller.
+
+Required properties:
+- compatible: keymile,bfticu
+- interrupt-controller: the bfticu FPGA is an interrupt controller
+- interrupts: the main IRQ line to signal the collected IRQs
+- #interrupt-cells : is 2
+- The 1st cell is the local IRQ number on the bfticu
+- The 2nd cell is the type of the IRQ (IRQ_TYPE_xxx)
Device tree bindings should not depend on the content of Linux headers.
One is stable ABI, and the other isn't.
If you want you can make the values the same for convenience, as is done
by IPIC, CPM PIC, etc -- but the values need to be explicitly stated in
the binding. It'll still break if the Linux values change (so it may
not be a good idea to try to keep the values the same), but at least the
fix would be in Linux code rather than an ABI change.
OK. I will then explicitly give the list of the values.
diff --git a/Documentation/devicetree/bindings/mfd/qriox.txt
b/Documentation/devicetree/bindings/mfd/qriox.txt
new file mode 100644
index 000..f301e2d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/qriox.txt
@@ -0,0 +1,17 @@
+KEYMILE qrio Board Control CPLD
+
+The qrio is a multifunction device that controls the KEYMILE boards based on
+the kmp204x design.
+It is consists of a reset controller, watchdog timer, LEDs, and 2 IRQ
capable
+GPIO blocks.
+
+Required properties:
+- compatible: keymile,qriox
+- reg: access on the parent local bus (chip select, offset in chip select,
size)
+
+Example:
+
+board-control@1,0 {
+compatible = keymile,qriox;
+reg = 1 0 0x80;
+};
If it has GPIO blocks, shouldn't it be using the GPIO binding?
You are right it should. But this is currently being reworked (also in HW) and
that's why I left it out completely, instead of submitting something subject to
change.
Valentin
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 1/3] devicetree: bindings: add Zarlink to the vendor prefixes
Even though the company belongs to Microsemi, many chips are still labeled as Zarlink. Among them is the family of network clock generators, the zl3034x. Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com --- Changes in v3: None Changes in v2: - add a patch so that the Zarlink vendor prefix is defined Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 40ce2df..4a6eba0 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -95,3 +95,4 @@ winbond Winbond Electronics corp. wlfWolfson Microelectronics wm Wondermedia Technologies, Inc. xlnx Xilinx +zarlinkZarlink Semiconductor -- 1.8.0.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 3/3] powerpc/mpc85xx: add support for Keymile's kmcoge4 board
This patch introduces the support for Keymile's kmcoge4 board which is
the internal reference design for boards based on Freescale's
P2040/P2041 SoCs. This internal reference design is named kmp204x.
The peripherals used on this board are:
- SPI NOR Flash as bootloader medium
- NAND Flash with a ubi partition
- 2 PCIe busses (hosts 1 and 3)
- 3 FMAN Ethernet devices (FMAN1 DTSEC1/2/5)
- 4 Local Bus windows, with one dedicated to the QRIO reset/power mgmt
CPLD
- 2 I2C busses
- last but not least, the mandatory serial port
The patch also adds a defconfig file for this reference design that is
necessary because of the lowmem option that must be set higher due to
the number of PCIe devices with big ioremapped mem ranges on the boad.
Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com
---
Changes in v3:
- add the compatible strings for the localbus nodes
- remove the IRQ part of the board-control node as it is currently being
reworked
Changes in v2:
- add some nodes on the localbus CS when possible
- only use the corenet_generic machine and add kmcoge4 to the supported
boards instead of defining a new kmp204x machine
- set better and more precise device nodes for the spi devices
- remove the partion layout for the spi_flash@0
arch/powerpc/boot/dts/kmcoge4.dts | 157 ++
arch/powerpc/configs/85xx/kmp204x_defconfig | 227 ++
arch/powerpc/platforms/85xx/Kconfig | 2 +-
arch/powerpc/platforms/85xx/corenet_generic.c | 3 +-
4 files changed, 387 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/boot/dts/kmcoge4.dts
create mode 100644 arch/powerpc/configs/85xx/kmp204x_defconfig
diff --git a/arch/powerpc/boot/dts/kmcoge4.dts
b/arch/powerpc/boot/dts/kmcoge4.dts
new file mode 100644
index 000..bcd0263
--- /dev/null
+++ b/arch/powerpc/boot/dts/kmcoge4.dts
@@ -0,0 +1,157 @@
+/*
+ * Keymile kmcoge4 Device Tree Source, based on the P2041RDB DTS
+ *
+ * (C) Copyright 2014
+ * Valentin Longchamp, Keymile AG, valentin.longch...@keymile.com
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/include/ fsl/p2041si-pre.dtsi
+
+/ {
+ model = keymile,kmcoge4;
+ compatible = keymile,kmcoge4, keymile,kmp204x;
+ #address-cells = 2;
+ #size-cells = 2;
+ interrupt-parent = mpic;
+
+ memory {
+ device_type = memory;
+ };
+
+ dcsr: dcsr@f {
+ ranges = 0x 0xf 0x 0x01008000;
+ };
+
+ soc: soc@ffe00 {
+ ranges = 0x 0xf 0xfe00 0x100;
+ reg = 0xf 0xfe00 0 0x1000;
+ spi@11 {
+ flash@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = spansion,s25fl256s1;
+ reg = 0;
+ spi-max-frequency = 2000; /* input clock
*/
+ };
+
+ network_clock@1 {
+ compatible = zarlink,zl30343;
+ reg = 1;
+ spi-max-frequency = 800;
+ };
+
+ flash@2 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = micron,m25p32;
+ reg = 2;
+ spi-max-frequency = 1500;
+ };
+ };
+
+ i2c@119000 {
+ status = disabled;
+ };
+
+ i2c@119100 {
+ status = disabled;
+ };
+
+ usb0: usb@21 {
+ status = disabled;
+ };
+
+ usb1: usb@211000 {
+ status = disabled;
+ };
+
+ sata@22 {
+ status = disabled;
+ };
+
+ sata@221000 {
+ status = disabled;
+ };
+ };
+
+ rio: rapidio@ffe0c {
+ status = disabled;
+ };
+
+ lbc: localbus@ffe124000 {
+ reg = 0xf 0xfe124000 0 0x1000;
+ ranges = 0 0 0xf 0xffa0 0x0004 /* LB 0 */
+ 1 0 0xf 0xfb00 0x0001 /* LB 1 */
+ 2 0 0xf 0xd000 0x1000 /* LB 2 */
+ 3 0 0xf 0xe000 0x1000; /* LB 3 */
+
+ nand@0,0 {
+ #address-cells = 1
[PATCH v3 0/3] Support of the kmcoge4 board
This series adds support for Keymile's COGE4 board, called kmcoge4. This board is the reference design for further designs at Keymile around the P2040/P2041 SoCs from Freescale. This reference design is internally called kmp204x. Changes in v3: - add a patch with the bindings for the KEYMILE FPGAs - add the compatible strings for the localbus nodes - remove the IRQ part of the board-control node as it is currently being reworked Changes in v2: - add a patch so that the Zarlink vendor prefix is defined - add some nodes on the localbus CS when possible - only use the corenet_generic machine and add kmcoge4 to the supported boards instead of defining a new kmp204x machine - set better and more precise device nodes for the spi devices - remove the partion layout for the spi_flash@0 Valentin Longchamp (3): devicetree: bindings: add Zarlink to the vendor prefixes devcietree: bindings: add some MFD Keymile FPGAs powerpc/mpc85xx: add support for Keymile's kmcoge4 board Documentation/devicetree/bindings/mfd/bfticu.txt | 26 +++ Documentation/devicetree/bindings/mfd/qriox.txt| 17 ++ .../devicetree/bindings/vendor-prefixes.txt| 2 + arch/powerpc/boot/dts/kmcoge4.dts | 157 ++ arch/powerpc/configs/85xx/kmp204x_defconfig| 227 + arch/powerpc/platforms/85xx/Kconfig| 2 +- arch/powerpc/platforms/85xx/corenet_generic.c | 3 +- 7 files changed, 432 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/bfticu.txt create mode 100644 Documentation/devicetree/bindings/mfd/qriox.txt create mode 100644 arch/powerpc/boot/dts/kmcoge4.dts create mode 100644 arch/powerpc/configs/85xx/kmp204x_defconfig -- 1.8.0.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 2/3] devcietree: bindings: add some MFD Keymile FPGAs
These are the bindings for 2 MFD devices used on some of the Keymile boards.
The first one is the chassis managmenet bfticu FPGA.
The second one is the board controller (reset, LEDs, GPIOs) QRIO CPDL.
These FPGAs are used in the kmcoge4 board.
This patch also add KEYMILE to the vendor-prefixes.
Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com
---
Changes in v3:
- add a patch with the bindings for the KEYMILE FPGAs
Changes in v2: None
Documentation/devicetree/bindings/mfd/bfticu.txt | 26 ++
Documentation/devicetree/bindings/mfd/qriox.txt| 17 ++
.../devicetree/bindings/vendor-prefixes.txt| 1 +
3 files changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/bfticu.txt
create mode 100644 Documentation/devicetree/bindings/mfd/qriox.txt
diff --git a/Documentation/devicetree/bindings/mfd/bfticu.txt
b/Documentation/devicetree/bindings/mfd/bfticu.txt
new file mode 100644
index 000..92de32e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/bfticu.txt
@@ -0,0 +1,26 @@
+KEYMILE bfticu Chassis Management FPGA
+
+The bfticu is a multifunction device that manages the whole chassis.
+Its main functionality is to collect IRQs from the whole chassis and signals
+them to a single controller.
+
+Required properties:
+- compatible: keymile,bfticu
+- interrupt-controller: the bfticu FPGA is an interrupt controller
+- interrupts: the main IRQ line to signal the collected IRQs
+- #interrupt-cells : is 2
+ - The 1st cell is the local IRQ number on the bfticu
+ - The 2nd cell is the type of the IRQ (IRQ_TYPE_xxx)
+- interrupt-parent: the parent IRQ ctrl the main IRQ is connected to
+- reg: access on the parent local bus (chip select, offset in chip select,
size)
+
+Example:
+
+ chassis-mgmt@3,0 {
+ compatible = keymile,bfticu;
+ interrupt-controller;
+ #interrupt-cells = 2;
+ reg = 3 0 0x100;
+ interrupt-parent = mpic;
+ interrupts = 6 1 0 0;
+ };
diff --git a/Documentation/devicetree/bindings/mfd/qriox.txt
b/Documentation/devicetree/bindings/mfd/qriox.txt
new file mode 100644
index 000..f301e2d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/qriox.txt
@@ -0,0 +1,17 @@
+KEYMILE qrio Board Control CPLD
+
+The qrio is a multifunction device that controls the KEYMILE boards based on
+the kmp204x design.
+It is consists of a reset controller, watchdog timer, LEDs, and 2 IRQ capable
+GPIO blocks.
+
+Required properties:
+- compatible: keymile,qriox
+- reg: access on the parent local bus (chip select, offset in chip select,
size)
+
+Example:
+
+ board-control@1,0 {
+ compatible = keymile,qriox;
+ reg = 1 0 0x80;
+ };
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 4a6eba0..913a007 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -49,6 +49,7 @@ img Imagination Technologies Ltd.
intercontrol Inter Control Group
islIntersil
karo Ka-Ro electronics GmbH
+keymileKEYMILE GmbH
lg LG Corporation
linux Linux-specific binding
lsiLSI Corp. (LSI Logic)
--
1.8.0.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v2, 2/2] powerpc/mpc85xx: add support for Keymile's kmcoge4 board
On 03/20/2014 12:08 AM, Scott Wood wrote:
On Tue, Feb 11, 2014 at 12:50:07PM +0100, Valentin Longchamp wrote:
+reset_cpld@1,0 {
+interrupt-controller;
+#interrupt-cells = 2;
+reg = 1 0 0x80;
+interrupt-parent = mpic;
+interrupts =
+4 1 0 0
+5 1 0 0;
+};
+
+chassis_mgmt@3,0 {
+interrupt-controller;
+#interrupt-cells = 2;
+reg = 3 0 0x100;
+interrupt-parent = mpic;
+interrupts = 6 1 0 0;
+};
Dashes are preferred to underscores in device trees.
OK.
More importantly, these nodes need proper compatibles and bindings. Once
that's done, the name for the nodes should probably be
board_control@whatever for both.
The first one can be board-ctrl. The second however manages things that are
beyond this board and important for other boards in the chassis, so I think
chassis-mgmt is correct.
For the binding/compatbiles issues: in the first discussion I had omitted these
nodes because these are not available (and honestly for such FPGAs I doubt they
will ever be mainlined). We discussed it and concluded that the DTS should
describe the HW and not the drivers available in the kernel so I have now added
them. Do you want me to add the compatible strings we use in our tree even
though there are no bindings ? Leave them as is ? Or drop them ?
Valentin
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: EDAC PCIe errors when scannning the bus
Hello Johannes, On 03/19/2014 04:54 PM, Johannes Thumshirn wrote: On Wed, Mar 19, 2014 at 01:46:37PM +0100, Valentin Longchamp wrote: Hello, We have a board that is based on Freescale's P2041 SoC. The boards has 2 PCIe buses with this topology: PCIe 0 --- PEX8505 switch --- 4 network devices PCIE 2 --- FPGA On 3.10.33 + a subset of the Freescale SDK 1.4 patches, both PCIe buses work well and we are able to use the devices on them. For each bus, I however keep getting EDAC PCIe errors at the very first stage of bus enumeration (please see the attached kernel log, with some debug output from arch/powerpc/kernel/pci-common.c and drivers/pci/probe.c) for both buses. My current understanding of the situation is such: since PCI_PROBE_NORMAL is used, pcibios_scan_phb() calls pci_scan_child_bus() that does a pci_scan_slot() on the bus for 32 slots. The first pci_scan_slot() is successful and it discovers the P2041's PCIe Controller. All the 31 other pci_scan_slot() calls generate an EDAC PCIe error, that is triggered by the configuration read transaction to read an hypothetical vendor ID of a device on the bus. This is relevant with that is reported by the EDAC error handler (all the 31 are the same): PCIE error(s) detected PCIE ERR_DR register: 0x0002 ICCA bit is set: Access to an illegal configuration space from PEX_CONFIG_ADDR/PEX_CONFIG_DATA was detected. PCIE ERR_CAP_STAT register: 0x8001 To is set: Transaction originated from PEX_CONFIG_ADDR/PEX_CONFIG_DATA. PCIE ERR_CAP_R0 register: 0x0800 FMT: 0b00, TYPE: 0b00100 (Config read I guess) PCIE ERR_CAP_R1 register: 0x PCIE ERR_CAP_R2 register: 0x PCIE ERR_CAP_R3 register: 0x Afterwards, pci_scan_child_bus() calls pcibios_fixup_bus (that maybe helps ?). From here, since the P2041's PCIe Controller is a bridge, pci_scan_bridge is called for this bus and all the devices are detected without having any configuration transaction causing EDAC errors. Has someone already observed such a behavior ? Why do these initial transaction generate an error ? What would be a possible fix to avoid these transaction errors for these 31 (unneded ?) pci_scan_slot() calls on the initial bus ? I've encountered similar problems on a P4080 based design (mine has additional machine checks that cause an oops). I haven't solved it yet, so I unfortunately can't offer you a fix. But I was told there are some errata workarounds that more or less could have an impact on PCIe behavior. Could you show me the output of U-Boot's errata command? Here is the output for the errata command: = errata Work-around for Erratum CPU-A003999 enabled Work-around for Erratum DDR-A003473 enabled Work-around for Erratum ESDHC111 enabled Work-around for Erratum DDR-A003 enabled Work-around for Erratum A004510 enabled Work-around for Erratum SRIO-A004034 enabled Work-around for Erratum A004849 is not enabled Work-around for Erratum A004580 is not enabled Work-around for Erratum USB14 enabled Especially if the workarounds for A-004580 and A-004849 are in place. So both are not enabled, I am going to fix that. Surprisingly, A-004580 is not defined for the P2041 in u-boot even though it is also present in the P2041's errata sheet, I had to enable it myself. However, I expect that enabling the workarounds for these 2 Errata are good for the system but it will not solve the PCIe EDAC problem. Thank you for the input. Valentin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 0/2] Support of the kmcoge4 board
This series adds support for Keymile's COGE4 board, called kmcoge4. This board is the reference design for further designs at Keymile around the P2040/P2041 SoCs from Freescale. This reference design is internally called kmp204x. Changes in v2: - add a patch so that the Zarlink vendor prefix is defined - add some nodes on the localbus CS when possible - only use the corenet_generic machine and add kmcoge4 to the supported boards instead of defining a new kmp204x machine - set better and more precise device nodes for the spi devices - remove the partion layout for the spi_flash@0 Valentin Longchamp (2): devicetree: bindings: add Zarlink to the vendor prefixes powerpc/mpc85xx: add support for Keymile's kmcoge4 board .../devicetree/bindings/vendor-prefixes.txt| 1 + arch/powerpc/boot/dts/kmcoge4.dts | 161 +++ arch/powerpc/configs/85xx/kmp204x_defconfig| 227 + arch/powerpc/platforms/85xx/Kconfig| 2 +- arch/powerpc/platforms/85xx/corenet_generic.c | 3 +- 5 files changed, 392 insertions(+), 2 deletions(-) create mode 100644 arch/powerpc/boot/dts/kmcoge4.dts create mode 100644 arch/powerpc/configs/85xx/kmp204x_defconfig -- 1.8.0.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 1/2] devicetree: bindings: add Zarlink to the vendor prefixes
Even though the company belongs to Microsemi, many chips are still labeled as Zarlink. Among them is the family of network clock generators, the zl3034x. Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com --- Changes in v2: - add a patch so that the Zarlink vendor prefix is defined Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index edbb8d8..35f1c9b 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -81,3 +81,4 @@ winbond Winbond Electronics corp. wlfWolfson Microelectronics wm Wondermedia Technologies, Inc. xlnx Xilinx +zarlinkZarlink Semiconductor -- 1.8.0.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 2/2] powerpc/mpc85xx: add support for Keymile's kmcoge4 board
This patch introduces the support for Keymile's kmcoge4 board which is
the internal reference design for boards based on Freescale's
P2040/P2041 SoCs. This internal reference design is named kmp204x.
The peripherals used on this board are:
- SPI NOR Flash as bootloader medium
- NAND Flash with a ubi partition
- 2 PCIe busses (hosts 1 and 3)
- 3 FMAN Ethernet devices (FMAN1 DTSEC1/2/5)
- 4 Local Bus windows, with one dedicated to the QRIO reset/power mgmt
CPLD
- 2 I2C busses
- last but not least, the mandatory serial port
The patch also adds a defconfig file for this reference design that is
necessary because of the lowmem option that must be set higher due to
the number of PCIe devices with big ioremapped mem ranges on the boad.
Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com
---
Changes in v2:
- add some nodes on the localbus CS when possible
- only use the corenet_generic machine and add kmcoge4 to the supported
boards instead of defining a new kmp204x machine
- set better and more precise device nodes for the spi devices
- remove the partion layout for the spi_flash@0
arch/powerpc/boot/dts/kmcoge4.dts | 161 ++
arch/powerpc/configs/85xx/kmp204x_defconfig | 227 ++
arch/powerpc/platforms/85xx/Kconfig | 2 +-
arch/powerpc/platforms/85xx/corenet_generic.c | 3 +-
4 files changed, 391 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/boot/dts/kmcoge4.dts
create mode 100644 arch/powerpc/configs/85xx/kmp204x_defconfig
diff --git a/arch/powerpc/boot/dts/kmcoge4.dts
b/arch/powerpc/boot/dts/kmcoge4.dts
new file mode 100644
index 000..5eab9df
--- /dev/null
+++ b/arch/powerpc/boot/dts/kmcoge4.dts
@@ -0,0 +1,161 @@
+/*
+ * Keymile kmcoge4 Device Tree Source, based on the P2041RDB DTS
+ *
+ * (C) Copyright 2014
+ * Valentin Longchamp, Keymile AG, valentin.longch...@keymile.com
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/include/ fsl/p2041si-pre.dtsi
+
+/ {
+ model = keymile,kmcoge4;
+ compatible = keymile,kmcoge4, keymile,kmp204x;
+ #address-cells = 2;
+ #size-cells = 2;
+ interrupt-parent = mpic;
+
+ memory {
+ device_type = memory;
+ };
+
+ dcsr: dcsr@f {
+ ranges = 0x 0xf 0x 0x01008000;
+ };
+
+ soc: soc@ffe00 {
+ ranges = 0x 0xf 0xfe00 0x100;
+ reg = 0xf 0xfe00 0 0x1000;
+ spi@11 {
+ flash@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = spansion,s25fl256s1;
+ reg = 0;
+ spi-max-frequency = 2000; /* input clock
*/
+ };
+
+ network_clock@1 {
+ compatible = zarlink,zl30343;
+ reg = 1;
+ spi-max-frequency = 800;
+ };
+
+ flash@2 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = micron,m25p32;
+ reg = 2;
+ spi-max-frequency = 1500;
+ };
+ };
+
+ i2c@119000 {
+ status = disabled;
+ };
+
+ i2c@119100 {
+ status = disabled;
+ };
+
+ usb0: usb@21 {
+ status = disabled;
+ };
+
+ usb1: usb@211000 {
+ status = disabled;
+ };
+
+ sata@22 {
+ status = disabled;
+ };
+
+ sata@221000 {
+ status = disabled;
+ };
+ };
+
+ rio: rapidio@ffe0c {
+ status = disabled;
+ };
+
+ lbc: localbus@ffe124000 {
+ reg = 0xf 0xfe124000 0 0x1000;
+ ranges = 0 0 0xf 0xffa0 0x0004 /* LB 0 */
+ 1 0 0xf 0xfb00 0x0001 /* LB 1 */
+ 2 0 0xf 0xd000 0x1000 /* LB 2 */
+ 3 0 0xf 0xe000 0x1000; /* LB 3 */
+
+ nand@0,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,elbc-fcm-nand;
+ reg = 0 0 0x4
Re: [PATCH RFC] powerpc/mpc85xx: add support for the kmp204x reference board
On 01/21/2014 06:01 PM, Scott Wood wrote:
On Tue, 2014-01-21 at 17:34 +0100, Valentin Longchamp wrote:
On 01/20/2014 11:37 PM, Scott Wood wrote:
On Mon, 2014-01-20 at 17:38 +0100, Valentin Longchamp wrote:
On 01/17/2014 10:48 PM, Scott Wood wrote:
Why isn't the compatible keymile,kmcoge4, like the model?
Because kmcoge4 is the board that is based on the kmp204x
architecture/design.
We expect other boards (kmcoge7 for instance) based on the same kmp204x
design.
The top-level compatible isn't for the architecture or the design.
It's for the board. Surely there's something different about kmcoge7
versus kmcoge4 -- is it visible to software?
There should only be a few differences in the dts between the two boards.
Reading the ePAPR my understanding was that compatible is the programming
model and that's what I have named above design/architecture while model is
the
exact model of the device in this case the exact board name.
In practice, model is more for human consumption (e.g. there may be many
variants that all look identical to software). The programming model
for an entire board includes everything on it.
You would prefer that I have the model and compatible stricly the same and
add
any future board into the compatible boards[] from corenet_generic ?
That's how it's usually done. Or, at least provide the board
architecture name as a secondary compatible after the board name.
If possible I would like to be able to see the boards that are based on a
similar design, that's what I wanted to achieve with this kmp204x name.
Is kmp204x an official name of the architecture, rather than a
generalization of kmp2040 and kmp2041? If there were a p2042, and
you made a board for it, is there any chance it would be called kmp204x
even if it were very different from the p2040/p2041 board?
It's the name we have picked up, but it's not official. We also use km83xx,
km82xx and it was derived from that.
If the hypothetical p2042 board was different it would then have another
name.
In that case, I don't object to it being listed in compatible, though
the specific board name should come first.
OK then to sum up both points we would have:
model = keymile,kmcoge4;
compatible = keymile,kmcoge4, keymile,kmp204x;
And I would add keymile,kmcoge4 into the boards[] table.
The device tree describes the hardware, not what driver you want to use.
Plus, I don't see any driver that matches gen,spidev nor any binding
for it, and gen doesn't make sense as a vendor prefix. The only
instance of that string I can find in the Linux tree is in mgcoge.dts.
Well it comes from mgcoge and that's why I have used this
It's for usage with the spidev driver (driver/spi/spidev.c). I agree that
the
gen brings nothing. Would
spidev@1 {
compatible = spidev;
make more sense ?
It doesn't address any of the other comments.
Can you please explicitly tell me how I should build this node ? What other
comments ? Must I be more generic with the name ?
Something like :
spi@1 {
compatible = zarlink,30343, spidev;
Remove spidev. Any nodes under the SPI controller node will be SPI
devices, right? So it doesn't add anything regarding hardware
description.
OK.
Thank you for the feedback, I will then send a revised patch as soon as I have
time.
Valentin
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC] powerpc/mpc85xx: add support for the kmp204x reference board
On 01/20/2014 11:37 PM, Scott Wood wrote:
On Mon, 2014-01-20 at 17:38 +0100, Valentin Longchamp wrote:
On 01/17/2014 10:48 PM, Scott Wood wrote:
On Fri, 2014-01-17 at 13:51 +0100, Valentin Longchamp wrote:
Hi Scott,
Thanks for you feedback.
On 01/17/2014 12:35 AM, Scott Wood wrote:
On Thu, 2014-01-16 at 14:38 +0100, Valentin Longchamp wrote:
This patch introduces the support for Keymile's kmp204x reference
design. This design is based on Freescale's P2040/P2041 SoC.
The peripherals used by this design are:
- SPI NOR Flash as bootloader medium
- NAND Flash with a ubi partition
- 2 PCIe busses (hosts 1 and 3)
- 3 FMAN Ethernet devices (FMAN1 DTSEC1/2/5)
- 4 Local Bus windows, with one dedicated to the QRIO reset/power mgmt
FPGA
- 2 HW I2C busses
- last but not least, the mandatory serial port
The patch also adds a defconfig file for this reference design and a DTS
file for the kmcoge4 board which is the first one based on this
reference design.
To try to avoid code duplication, the support was added directly to the
corenet_generic.c file.
Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com
---
arch/powerpc/boot/dts/kmcoge4.dts | 165 ++
arch/powerpc/configs/85xx/kmp204x_defconfig | 231
++
arch/powerpc/platforms/85xx/Kconfig | 14 ++
arch/powerpc/platforms/85xx/Makefile | 1 +
arch/powerpc/platforms/85xx/corenet_generic.c | 52 ++
5 files changed, 463 insertions(+)
create mode 100644 arch/powerpc/boot/dts/kmcoge4.dts
create mode 100644 arch/powerpc/configs/85xx/kmp204x_defconfig
diff --git a/arch/powerpc/boot/dts/kmcoge4.dts
b/arch/powerpc/boot/dts/kmcoge4.dts
new file mode 100644
index 000..c10df6d
--- /dev/null
+++ b/arch/powerpc/boot/dts/kmcoge4.dts
@@ -0,0 +1,165 @@
+/*
+ * Keymile kmcoge4 Device Tree Source, based on the P2041RDB DTS
+ *
+ * (C) Copyright 2014
+ * Valentin Longchamp, Keymile AG, valentin.longch...@keymile.com
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or
modify it
+ * under the terms of the GNU General Public License as published by
the
+ * Free Software Foundation; either version 2 of the License, or (at
your
+ * option) any later version.
+ */
+
+/include/ fsl/p2041si-pre.dtsi
+
+/ {
+model = keymile,kmcoge4;
+compatible = keymile,kmp204x;
Don't put wildcards in compatible.
Well it's a wildcard in the sense that we support both the p2040 and the
p2041,
but it's also the name of the plaftorm, similarly to names like '85xx' or
'tqm85xx'.
Names like 85xx are not allowed in device trees.
With p204x, what would happen if a p2042 were introduced, that were
not compatible?
What would you suggest as a generic name for the architecture that supports
both ?
Why isn't the compatible keymile,kmcoge4, like the model?
Because kmcoge4 is the board that is based on the kmp204x
architecture/design.
We expect other boards (kmcoge7 for instance) based on the same kmp204x
design.
The top-level compatible isn't for the architecture or the design.
It's for the board. Surely there's something different about kmcoge7
versus kmcoge4 -- is it visible to software?
There should only be a few differences in the dts between the two boards.
Reading the ePAPR my understanding was that compatible is the programming
model and that's what I have named above design/architecture while model is the
exact model of the device in this case the exact board name.
You would prefer that I have the model and compatible stricly the same and
add
any future board into the compatible boards[] from corenet_generic ?
That's how it's usually done. Or, at least provide the board
architecture name as a secondary compatible after the board name.
If possible I would like to be able to see the boards that are based on a
similar design, that's what I wanted to achieve with this kmp204x name.
Is kmp204x an official name of the architecture, rather than a
generalization of kmp2040 and kmp2041? If there were a p2042, and
you made a board for it, is there any chance it would be called kmp204x
even if it were very different from the p2040/p2041 board?
It's the name we have picked up, but it's not official. We also use km83xx,
km82xx and it was derived from that.
If the hypothetical p2042 board was different it would then have another name.
+zl30343@1 {
+compatible = gen,spidev;
Node names are supposed to be generic. Compatibles are supposed to be
specific.
That's a very specific device for which we only have a userspace driver
and for
which we must use the generic kernel spidev driver.
The device tree describes the hardware, not what driver you want to use.
Plus, I don't see any driver that matches gen,spidev nor any binding
for it, and gen
Re: [PATCH RFC] powerpc/mpc85xx: add support for the kmp204x reference board
On 01/17/2014 10:48 PM, Scott Wood wrote:
On Fri, 2014-01-17 at 13:51 +0100, Valentin Longchamp wrote:
Hi Scott,
Thanks for you feedback.
On 01/17/2014 12:35 AM, Scott Wood wrote:
On Thu, 2014-01-16 at 14:38 +0100, Valentin Longchamp wrote:
This patch introduces the support for Keymile's kmp204x reference
design. This design is based on Freescale's P2040/P2041 SoC.
The peripherals used by this design are:
- SPI NOR Flash as bootloader medium
- NAND Flash with a ubi partition
- 2 PCIe busses (hosts 1 and 3)
- 3 FMAN Ethernet devices (FMAN1 DTSEC1/2/5)
- 4 Local Bus windows, with one dedicated to the QRIO reset/power mgmt
FPGA
- 2 HW I2C busses
- last but not least, the mandatory serial port
The patch also adds a defconfig file for this reference design and a DTS
file for the kmcoge4 board which is the first one based on this
reference design.
To try to avoid code duplication, the support was added directly to the
corenet_generic.c file.
Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com
---
arch/powerpc/boot/dts/kmcoge4.dts | 165 ++
arch/powerpc/configs/85xx/kmp204x_defconfig | 231
++
arch/powerpc/platforms/85xx/Kconfig | 14 ++
arch/powerpc/platforms/85xx/Makefile | 1 +
arch/powerpc/platforms/85xx/corenet_generic.c | 52 ++
5 files changed, 463 insertions(+)
create mode 100644 arch/powerpc/boot/dts/kmcoge4.dts
create mode 100644 arch/powerpc/configs/85xx/kmp204x_defconfig
diff --git a/arch/powerpc/boot/dts/kmcoge4.dts
b/arch/powerpc/boot/dts/kmcoge4.dts
new file mode 100644
index 000..c10df6d
--- /dev/null
+++ b/arch/powerpc/boot/dts/kmcoge4.dts
@@ -0,0 +1,165 @@
+/*
+ * Keymile kmcoge4 Device Tree Source, based on the P2041RDB DTS
+ *
+ * (C) Copyright 2014
+ * Valentin Longchamp, Keymile AG, valentin.longch...@keymile.com
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
it
+ * under the terms of the GNU General Public License as published by
the
+ * Free Software Foundation; either version 2 of the License, or (at
your
+ * option) any later version.
+ */
+
+/include/ fsl/p2041si-pre.dtsi
+
+/ {
+ model = keymile,kmcoge4;
+ compatible = keymile,kmp204x;
Don't put wildcards in compatible.
Well it's a wildcard in the sense that we support both the p2040 and the
p2041,
but it's also the name of the plaftorm, similarly to names like '85xx' or
'tqm85xx'.
Names like 85xx are not allowed in device trees.
With p204x, what would happen if a p2042 were introduced, that were
not compatible?
What would you suggest as a generic name for the architecture that supports
both ?
Why isn't the compatible keymile,kmcoge4, like the model?
Because kmcoge4 is the board that is based on the kmp204x architecture/design.
We expect other boards (kmcoge7 for instance) based on the same kmp204x design.
You would prefer that I have the model and compatible stricly the same and add
any future board into the compatible boards[] from corenet_generic ?
If possible I would like to be able to see the boards that are based on a
similar design, that's what I wanted to achieve with this kmp204x name.
I realize it's common practice, but it would be good to get away from
putting partition layouts in the dts file. Alternatives include using
mtdparts on the command line, or having U-Boot put the partition info
into the dtb based on the mtdparts environment variable (there is
existing code for this).
I agree that u-boot also has to know about the addresses because it also
accesses these partitions.
But I think it is clearer to have this in the device tree: I try to keep the
kernel command line small and I don't like having u-boot fixing the dtb at
runtime.
The problem is that the dts source is often far removed from the actual
programming of flash, and the partitioning can vary based on use case,
or change for other reasons (e.g. there have been requests to change
existing partition layouts to accommodate growth in U-Boot size).
Ideally it wouldn't be in the device tree at all, but having U-Boot fix
it up based on an environment variable is better than statically
defining it in a file in the Linux tree.
+ zl30343@1 {
+ compatible = gen,spidev;
Node names are supposed to be generic. Compatibles are supposed to be
specific.
That's a very specific device for which we only have a userspace driver and
for
which we must use the generic kernel spidev driver.
The device tree describes the hardware, not what driver you want to use.
Plus, I don't see any driver that matches gen,spidev nor any binding
for it, and gen doesn't make sense as a vendor prefix. The only
instance of that string I can find in the Linux tree is in mgcoge.dts.
Well it comes from mgcoge and that's why I have
Re: [PATCH RFC] powerpc/mpc85xx: add support for the kmp204x reference board
Hi Scott,
Thanks for you feedback.
On 01/17/2014 12:35 AM, Scott Wood wrote:
On Thu, 2014-01-16 at 14:38 +0100, Valentin Longchamp wrote:
This patch introduces the support for Keymile's kmp204x reference
design. This design is based on Freescale's P2040/P2041 SoC.
The peripherals used by this design are:
- SPI NOR Flash as bootloader medium
- NAND Flash with a ubi partition
- 2 PCIe busses (hosts 1 and 3)
- 3 FMAN Ethernet devices (FMAN1 DTSEC1/2/5)
- 4 Local Bus windows, with one dedicated to the QRIO reset/power mgmt
FPGA
- 2 HW I2C busses
- last but not least, the mandatory serial port
The patch also adds a defconfig file for this reference design and a DTS
file for the kmcoge4 board which is the first one based on this
reference design.
To try to avoid code duplication, the support was added directly to the
corenet_generic.c file.
Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com
---
arch/powerpc/boot/dts/kmcoge4.dts | 165 ++
arch/powerpc/configs/85xx/kmp204x_defconfig | 231
++
arch/powerpc/platforms/85xx/Kconfig | 14 ++
arch/powerpc/platforms/85xx/Makefile | 1 +
arch/powerpc/platforms/85xx/corenet_generic.c | 52 ++
5 files changed, 463 insertions(+)
create mode 100644 arch/powerpc/boot/dts/kmcoge4.dts
create mode 100644 arch/powerpc/configs/85xx/kmp204x_defconfig
diff --git a/arch/powerpc/boot/dts/kmcoge4.dts
b/arch/powerpc/boot/dts/kmcoge4.dts
new file mode 100644
index 000..c10df6d
--- /dev/null
+++ b/arch/powerpc/boot/dts/kmcoge4.dts
@@ -0,0 +1,165 @@
+/*
+ * Keymile kmcoge4 Device Tree Source, based on the P2041RDB DTS
+ *
+ * (C) Copyright 2014
+ * Valentin Longchamp, Keymile AG, valentin.longch...@keymile.com
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/include/ fsl/p2041si-pre.dtsi
+
+/ {
+model = keymile,kmcoge4;
+compatible = keymile,kmp204x;
Don't put wildcards in compatible.
Well it's a wildcard in the sense that we support both the p2040 and the p2041,
but it's also the name of the plaftorm, similarly to names like '85xx' or
'tqm85xx'.
+soc: soc@ffe00 {
+ranges = 0x 0xf 0xfe00 0x100;
+reg = 0xf 0xfe00 0 0x1000;
+spi@11 {
+flash@0 {
+#address-cells = 1;
+#size-cells = 1;
+compatible = spansion,s25fl256s1;
+reg = 0;
+spi-max-frequency = 2000; /* input clock
*/
+partition@u-boot {
+label = u-boot;
+reg = 0x 0x0010;
+read-only;
+};
+partition@env {
+label = env;
+reg = 0x0010 0x0001;
+};
+partition@envred {
+label = envred;
+reg = 0x0011 0x0001;
+};
+partition@fman {
+label = fman-ucode;
+reg = 0x0012 0x0001;
+read-only;
+};
+};
I realize it's common practice, but it would be good to get away from
putting partition layouts in the dts file. Alternatives include using
mtdparts on the command line, or having U-Boot put the partition info
into the dtb based on the mtdparts environment variable (there is
existing code for this).
I agree that u-boot also has to know about the addresses because it also
accesses these partitions.
But I think it is clearer to have this in the device tree: I try to keep the
kernel command line small and I don't like having u-boot fixing the dtb at
runtime.
+zl30343@1 {
+compatible = gen,spidev;
Node names are supposed to be generic. Compatibles are supposed to be
specific.
That's a very specific device for which we only have a userspace driver and for
which we must use the generic kernel spidev driver. That's why the node name is
so specific and the compatible field very generic.
+lbc: localbus@ffe124000 {
+reg = 0xf 0xfe124000 0 0x1000;
+ranges = 0 0 0xf 0xffa0 0x0004 /* LB 0
[PATCH RFC] powerpc/mpc85xx: add support for the kmp204x reference board
This patch introduces the support for Keymile's kmp204x reference
design. This design is based on Freescale's P2040/P2041 SoC.
The peripherals used by this design are:
- SPI NOR Flash as bootloader medium
- NAND Flash with a ubi partition
- 2 PCIe busses (hosts 1 and 3)
- 3 FMAN Ethernet devices (FMAN1 DTSEC1/2/5)
- 4 Local Bus windows, with one dedicated to the QRIO reset/power mgmt
FPGA
- 2 HW I2C busses
- last but not least, the mandatory serial port
The patch also adds a defconfig file for this reference design and a DTS
file for the kmcoge4 board which is the first one based on this
reference design.
To try to avoid code duplication, the support was added directly to the
corenet_generic.c file.
Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com
---
arch/powerpc/boot/dts/kmcoge4.dts | 165 ++
arch/powerpc/configs/85xx/kmp204x_defconfig | 231 ++
arch/powerpc/platforms/85xx/Kconfig | 14 ++
arch/powerpc/platforms/85xx/Makefile | 1 +
arch/powerpc/platforms/85xx/corenet_generic.c | 52 ++
5 files changed, 463 insertions(+)
create mode 100644 arch/powerpc/boot/dts/kmcoge4.dts
create mode 100644 arch/powerpc/configs/85xx/kmp204x_defconfig
diff --git a/arch/powerpc/boot/dts/kmcoge4.dts
b/arch/powerpc/boot/dts/kmcoge4.dts
new file mode 100644
index 000..c10df6d
--- /dev/null
+++ b/arch/powerpc/boot/dts/kmcoge4.dts
@@ -0,0 +1,165 @@
+/*
+ * Keymile kmcoge4 Device Tree Source, based on the P2041RDB DTS
+ *
+ * (C) Copyright 2014
+ * Valentin Longchamp, Keymile AG, valentin.longch...@keymile.com
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/include/ fsl/p2041si-pre.dtsi
+
+/ {
+ model = keymile,kmcoge4;
+ compatible = keymile,kmp204x;
+ #address-cells = 2;
+ #size-cells = 2;
+ interrupt-parent = mpic;
+
+ memory {
+ device_type = memory;
+ };
+
+ dcsr: dcsr@f {
+ ranges = 0x 0xf 0x 0x01008000;
+ };
+
+ soc: soc@ffe00 {
+ ranges = 0x 0xf 0xfe00 0x100;
+ reg = 0xf 0xfe00 0 0x1000;
+ spi@11 {
+ flash@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = spansion,s25fl256s1;
+ reg = 0;
+ spi-max-frequency = 2000; /* input clock
*/
+ partition@u-boot {
+ label = u-boot;
+ reg = 0x 0x0010;
+ read-only;
+ };
+ partition@env {
+ label = env;
+ reg = 0x0010 0x0001;
+ };
+ partition@envred {
+ label = envred;
+ reg = 0x0011 0x0001;
+ };
+ partition@fman {
+ label = fman-ucode;
+ reg = 0x0012 0x0001;
+ read-only;
+ };
+ };
+
+ zl30343@1 {
+ compatible = gen,spidev;
+ reg = 1;
+ spi-max-frequency = 800;
+ };
+
+ flash@2 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = micron,m25p32;
+ reg = 2;
+ spi-max-frequency = 1500;
+ partition@fpga-config {
+ label = fpga-config;
+ reg = 0x 0x0040;
+ };
+ };
+ };
+
+ i2c@119000 {
+ status = disabled;
+ };
+
+ i2c@119100 {
+ status = disabled;
+ };
+
+ usb0: usb@21 {
+ status = disabled;
+ };
+
+ usb1: usb@211000 {
+ status = disabled;
+ };
+
+ sata@22
Re: [PATCH] powerpc/mpc85xx:Add initial device tree support of T104x
On 09/13/2013 04:53 PM, Kumar Gala wrote:
On Sep 13, 2013, at 4:14 AM, Valentin Longchamp wrote:
On 09/11/2013 08:58 AM, Prabhakar Kushwaha wrote:
+
+pci0 {
+ compatible = fsl,t1042-pcie, fsl,qoriq-pcie-v2.4, fsl,qoriq-pcie;
+ device_type = pci;
+ #size-cells = 2;
+ #address-cells = 3;
+ bus-range = 0x0 0xff;
+ interrupts = 20 2 0 0;
+ fsl,iommu-parent = pamu0;
+ pcie@0 {
+ reg = 0 0 0 0 0;
+ #interrupt-cells = 1;
+ #size-cells = 2;
+ #address-cells = 3;
+ device_type = pci;
+ interrupts = 20 2 0 0;
+ interrupt-map-mask = 0xf800 0 0 7;
+ interrupt-map =
+ /* IDSEL 0x0 */
+ 0 0 1 mpic 40 1 0 0
+ 0 0 2 mpic 1 1 0 0
+ 0 0 3 mpic 2 1 0 0
+ 0 0 4 mpic 3 1 0 0
+ ;
+ };
+};
+
+pci1 {
+ compatible = fsl,t1042-pcie, fsl,qoriq-pcie-v2.4, fsl,qoriq-pcie;
+ device_type = pci;
+ #size-cells = 2;
+ #address-cells = 3;
+ bus-range = 0 0xff;
+ interrupts = 21 2 0 0;
+ fsl,iommu-parent = pamu0;
+ pcie@0 {
+ reg = 0 0 0 0 0;
+ #interrupt-cells = 1;
+ #size-cells = 2;
+ #address-cells = 3;
+ device_type = pci;
+ interrupts = 21 2 0 0;
+ interrupt-map-mask = 0xf800 0 0 7;
+ interrupt-map =
+ /* IDSEL 0x0 */
+ 0 0 1 mpic 41 1 0 0
+ 0 0 2 mpic 5 1 0 0
+ 0 0 3 mpic 6 1 0 0
+ 0 0 4 mpic 7 1 0 0
+ ;
+ };
+};
+
+pci2 {
+ compatible = fsl,t1042-pcie, fsl,qoriq-pcie-v2.4, fsl,qoriq-pcie;
+ device_type = pci;
+ #size-cells = 2;
+ #address-cells = 3;
+ bus-range = 0x0 0xff;
+ interrupts = 22 2 0 0;
+ fsl,iommu-parent = pamu0;
+ pcie@0 {
+ reg = 0 0 0 0 0;
+ #interrupt-cells = 1;
+ #size-cells = 2;
+ #address-cells = 3;
+ device_type = pci;
+ interrupts = 22 2 0 0;
+ interrupt-map-mask = 0xf800 0 0 7;
+ interrupt-map =
+ /* IDSEL 0x0 */
+ 0 0 1 mpic 42 1 0 0
+ 0 0 2 mpic 9 1 0 0
+ 0 0 3 mpic 10 1 0 0
+ 0 0 4 mpic 11 1 0 0
+ ;
+ };
+};
+
+pci3 {
+ compatible = fsl,t1042-pcie, fsl,qoriq-pcie-v2.4, fsl,qoriq-pcie;
+ device_type = pci;
+ #size-cells = 2;
+ #address-cells = 3;
+ bus-range = 0x0 0xff;
+ interrupts = 23 2 0 0;
+ fsl,iommu-parent = pamu0;
+ pcie@0 {
+ reg = 0 0 0 0 0;
+ #interrupt-cells = 1;
+ #size-cells = 2;
+ #address-cells = 3;
+ device_type = pci;
+ interrupts = 23 2 0 0;
+ interrupt-map-mask = 0xf800 0 0 7;
+ interrupt-map =
+ /* IDSEL 0x0 */
+ 0 0 1 mpic 43 1 0 0
+ 0 0 2 mpic 0 1 0 0
+ 0 0 3 mpic 4 1 0 0
+ 0 0 4 mpic 8 1 0 0
+ ;
+ };
+};
+
The above 4 nodes have the consequence that it will then be mandatory that a
board support .dts file that would like to inlcude the SOC-NAMEsi-post.dtsi
defines the pci0, pci1, pci2, pci3 aliases.
Now it is possible that a board does not implement pci1 for instance. So its
.dts file would ideally not define a node for it, and thus not define the
respective alias. However, this triggers this dtc compile error (which is
correct):
[chlongv1@chber1-10533x linux-km]$ make kmp204x.dtb
DTC arch/powerpc/boot/kmp204x.dtb
Error: arch/powerpc/boot/dts/fsl/p2041si-post.dtsi:98.2-3 label or path,
'pci1', not found
FATAL ERROR: Syntax error parsing input tree
make[1]: *** [arch/powerpc/boot/kmp204x.dtb] Error 1
make: *** [kmp204x.dtb] Error 2
The solution I have found is to define a dummy disabled node so that I can
define the alias, but I am not really happy about this:
pci1: pcie@ffe201000 {
status = disabled;
};
I am here missing something obvious or shouldn't it be possible that such
.dtsi
files allow not to define unused/unnecessary nodes ?
Isn't this correct, that you are disabling the PCIe1 interface on the SoC for
your board?
Yes it is correct. So this confirms that a board .dts file must disable all not
used interfaces/peripherals with such a disabled node.
I just wanted to be sure that this was the correct way of doing things and that
I had not missed a better way (where you don't need to define such disabled
nodes in .dts files).
Valentin
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mpc85xx:Add initial device tree support of T104x
On 09/11/2013 08:58 AM, Prabhakar Kushwaha wrote:
The QorIQ T1040/T1042 processor support four integrated 64-bit e5500 PA
processor cores with high-performance data path acceleration architecture
and network peripheral interfaces required for networking
telecommunications.
T1042 personality is a reduced personality of T1040 without Integrated 8-port
Gigabit Ethernet switch.
The T1040/T1042 SoC includes the following function and features:
- Four e5500 cores, each with a private 256 KB L2 cache
- 256 KB shared L3 CoreNet platform cache (CPC)
- Interconnect CoreNet platform
- 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and interleaving
support
- Data Path Acceleration Architecture (DPAA) incorporating acceleration
for the following functions:
- Packet parsing, classification, and distribution
- Queue management for scheduling, packet sequencing, and congestion
management
- Cryptography Acceleration (SEC 5.0)
- RegEx Pattern Matching Acceleration (PME 2.2)
- IEEE Std 1588 support
- Hardware buffer management for buffer allocation and deallocation
- Ethernet interfaces
- Integrated 8-port Gigabit Ethernet switch (T1040 only)
- Four 1 Gbps Ethernet controllers
- Two RGMII interfaces or one RGMII and one MII interfaces
- High speed peripheral interfaces
- Four PCI Express 2.0 controllers running at up to 5 GHz
- Two SATA controllers supporting 1.5 and 3.0 Gb/s operation
- Upto two QSGMII interface
- Upto six SGMII interface supporting 1000 Mbps
- One SGMII interface supporting upto 2500 Mbps
- Additional peripheral interfaces
- Two USB 2.0 controllers with integrated PHY
- SD/eSDHC/eMMC
- eSPI controller
- Four I2C controllers
- Four UARTs
- Four GPIO controllers
- Integrated flash controller (IFC)
- Change this to LCD/ HDMI interface (DIU) with 12 bit dual data rate
- TDM interface
- Multicore programmable interrupt controller (PIC)
- Two 8-channel DMA engines
- Single source clocking implementation
- Deep Sleep power implementaion (wakeup from GPIO/Timer/Ethernet/USB)
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
Signed-off-by: Priyanka Jain priyanka.j...@freescale.com
Signed-off-by: Varun Sethi varun.se...@freescale.com
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
Based upon git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git
TODO: Add noded for ethernet
arch/powerpc/boot/dts/fsl/t1040si-post.dtsi | 116
arch/powerpc/boot/dts/fsl/t1042si-post.dtsi | 430
+++
arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi | 111 +++
3 files changed, 657 insertions(+)
create mode 100644 arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/t1042si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi
I am currently working on a design bases on the p2041 but my issue seems to be
generic to all the QorIQ dtsi files since the structure is exactly the same, so
I pick the opportunity that such a file is submitted to the mailing-list to
raise it.
DISCLAIMER: I am no DTS expert, so there may be a way to achieve what I want to
I have not seen.
My understanding is that the SOC-NAMEsi-post.dtsi and SOC-NAMEsi-pre.dtsi are
files that describe the SoC internals. They will be maintained when new drivers
are merged or changed and therefore they should be used by all boards using the
SoCs. Can someone confirm this or am I already wrong (since there are on
Freescale boards that use them in mainline) ?
[snip]
+
+pci0 {
+ compatible = fsl,t1042-pcie, fsl,qoriq-pcie-v2.4, fsl,qoriq-pcie;
+ device_type = pci;
+ #size-cells = 2;
+ #address-cells = 3;
+ bus-range = 0x0 0xff;
+ interrupts = 20 2 0 0;
+ fsl,iommu-parent = pamu0;
+ pcie@0 {
+ reg = 0 0 0 0 0;
+ #interrupt-cells = 1;
+ #size-cells = 2;
+ #address-cells = 3;
+ device_type = pci;
+ interrupts = 20 2 0 0;
+ interrupt-map-mask = 0xf800 0 0 7;
+ interrupt-map =
+ /* IDSEL 0x0 */
+ 0 0 1 mpic 40 1 0 0
+ 0 0 2 mpic 1 1 0 0
+ 0 0 3 mpic 2 1 0 0
+ 0 0 4 mpic 3 1 0 0
+ ;
+ };
+};
+
+pci1 {
+ compatible = fsl,t1042-pcie, fsl,qoriq-pcie-v2.4, fsl,qoriq-pcie;
+ device_type = pci;
+ #size-cells = 2;
+ #address-cells = 3;
+ bus-range = 0 0xff;
+ interrupts = 21 2 0 0;
+ fsl,iommu-parent = pamu0;
+ pcie@0 {
+ reg = 0 0 0 0 0;
+ #interrupt-cells = 1;
+ #size-cells = 2;
+ #address-cells = 3;
+ device_type = pci;
+ interrupts = 21 2 0 0;
+
