Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1601668 > unrolled thread
| Started by | Gregory CLEMENT <gregory.clement@free-electrons.com> |
|---|---|
| First post | 2017-03-15 20:20 +0100 |
| Last post | 2017-03-16 06:50 +0100 |
| Articles | 2 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH] ARM: dts: mvebu: linksys: enable buffer manager support Gregory CLEMENT <gregory.clement@free-electrons.com> - 2017-03-15 20:20 +0100
Re: [PATCH] ARM: dts: mvebu: linksys: enable buffer manager support Ralph Sennhauser <ralph.sennhauser@gmail.com> - 2017-03-16 06:50 +0100
| From | Gregory CLEMENT <gregory.clement@free-electrons.com> |
|---|---|
| Date | 2017-03-15 20:20 +0100 |
| Subject | Re: [PATCH] ARM: dts: mvebu: linksys: enable buffer manager support |
| Message-ID | <tlmCL-3E9-11@gated-at.bofh.it> |
Hi Ralph,
On mer., mars 08 2017, Ralph Sennhauser <ralph.sennhauser@gmail.com> wrote:
> Add appropriate properties to devices in the Linksys WRT AC Series for the
> mvneta driver to use hardware buffer management.
>
> Also update "soc" ranges property and set the status of bm and bm-bppi
> to "okay" (SRAM).
>
> Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
> ---
> arch/arm/boot/dts/armada-385-linksys.dtsi | 17 ++++++++++++++++-
> arch/arm/boot/dts/armada-xp-linksys-mamba.dts | 17 ++++++++++++++++-
> 2 files changed, 32 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/armada-385-linksys.dtsi b/arch/arm/boot/dts/armada-385-linksys.dtsi
> index df47bf1..4aac375 100644
> --- a/arch/arm/boot/dts/armada-385-linksys.dtsi
> +++ b/arch/arm/boot/dts/armada-385-linksys.dtsi
> @@ -59,7 +59,8 @@
> ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
> MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
> MBUS_ID(0x09, 0x19) 0 0xf1100000 0x10000
> - MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000>;
> + MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000
> + MBUS_ID(0x0c, 0x04) 0 0xf1200000 0x100000>;
>
> internal-regs {
> i2c@11000 {
> @@ -88,6 +89,9 @@
> ethernet@70000 {
> status = "okay";
> phy-mode = "rgmii-id";
> + buffer-manager = <&bm>;
> + bm,pool-long = <1>;
> + bm,pool-short = <3>;
> fixed-link {
> speed = <1000>;
> full-duplex;
> @@ -97,6 +101,9 @@
> ethernet@34000 {
> status = "okay";
> phy-mode = "sgmii";
> + buffer-manager = <&bm>;
> + bm,pool-long = <0>;
> + bm,pool-short = <3>;
Any reason to reuse the same pool than the other port?
As only two ports are used here, then each of them can have use 2 of the
4 availables pools.
> fixed-link {
> speed = <1000>;
> full-duplex;
> @@ -159,6 +166,10 @@
> status = "okay";
> };
>
> + bm@c8000 {
> + status = "okay";
> + };
> +
> /* USB part of the eSATA/USB 2.0 port */
> usb@58000 {
> status = "okay";
> @@ -241,6 +252,10 @@
> };
> };
>
> + bm-bppi {
> + status = "okay";
> + };
> +
> pcie-controller {
> status = "okay";
>
> diff --git a/arch/arm/boot/dts/armada-xp-linksys-mamba.dts b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
> index 3744ba3..b188a4dc 100644
> --- a/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
> +++ b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
> @@ -71,7 +71,8 @@
> ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000
> MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
> MBUS_ID(0x09, 0x09) 0 0 0xf1100000 0x10000
> - MBUS_ID(0x09, 0x05) 0 0 0xf1110000 0x10000>;
> + MBUS_ID(0x09, 0x05) 0 0 0xf1110000 0x10000
> + MBUS_ID(0x0c, 0x04) 0 0 0xf1200000 0x100000>;
>
> internal-regs {
>
> @@ -95,6 +96,9 @@
> pinctrl-names = "default";
> status = "okay";
> phy-mode = "rgmii-id";
> + buffer-manager = <&bm>;
> + bm,pool-long = <0>;
> + bm,pool-short = <3>;
> fixed-link {
> speed = <1000>;
> full-duplex;
> @@ -106,6 +110,9 @@
> pinctrl-names = "default";
> status = "okay";
> phy-mode = "rgmii-id";
> + buffer-manager = <&bm>;
> + bm,pool-long = <1>;
> + bm,pool-short = <3>;
Same question that above.
Gregory
> fixed-link {
> speed = <1000>;
> full-duplex;
> @@ -186,6 +193,10 @@
> };
> };
>
> + bm@c8000 {
> + status = "okay";
> + };
> +
> nand@d0000 {
> status = "okay";
> num-cs = <1>;
> @@ -259,6 +270,10 @@
> };
> };
> };
> +
> + bm-bppi {
> + status = "okay";
> + };
> };
>
> gpio_keys {
> --
> 2.10.2
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
[toc] | [next] | [standalone]
| From | Ralph Sennhauser <ralph.sennhauser@gmail.com> |
|---|---|
| Date | 2017-03-16 06:50 +0100 |
| Message-ID | <tlwsp-27G-11@gated-at.bofh.it> |
| In reply to | #1601668 |
On Wed, 15 Mar 2017 20:17:35 +0100
Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> Hi Ralph,
>
> On mer., mars 08 2017, Ralph Sennhauser <ralph.sennhauser@gmail.com>
> wrote:
>
> </snip>
>
> > @@ -88,6 +89,9 @@
> > ethernet@70000 {
> > status = "okay";
> > phy-mode = "rgmii-id";
> > + buffer-manager = <&bm>;
> > + bm,pool-long = <1>;
> > + bm,pool-short = <3>;
> > fixed-link {
> > speed = <1000>;
> > full-duplex;
> > @@ -97,6 +101,9 @@
> > ethernet@34000 {
> > status = "okay";
> > phy-mode = "sgmii";
> > + buffer-manager = <&bm>;
> > + bm,pool-long = <0>;
> > + bm,pool-short = <3>;
> Any reason to reuse the same pool than the other port?
>
> As only two ports are used here, then each of them can have use 2 of
> the 4 availables pools.
>
> </snip>
Hi Gregory,
It has been quite a while since I have written that patch. Something
written somewhere in the Documentation / commit message which I can't
find anymore gave me the impression that using the same for short
doesn't make a difference. So I went with the pool IDs used for other
similar boards for "consistency".
Will send a v2 shortly using all independent pools using the IDs witch
come most natural in context.
Thanks
Ralph
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web