[PATCH v4 2/4] net: phy: dp83867: add support for MAC impedance configuration

[Mugunthan V N]

Add support for programmable MAC impedance configuration

Signed-off-by: Mugunthan V N <mugunthan...@ti.com>
---
 drivers/net/phy/dp83867.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index 91177a4..1b63924 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -33,6 +33,7 @@
 /* Extended Registers */
 #define DP83867_RGMIICTL   0x0032
 #define DP83867_RGMIIDCTL  0x0086
+#define DP83867_IO_MUX_CFG 0x0170
 
 #define DP83867_SW_RESET   BIT(15)
 #define DP83867_SW_RESTART BIT(14)
@@ -62,10 +63,17 @@
 /* RGMIIDCTL bits */
 #define DP83867_RGMII_TX_CLK_DELAY_SHIFT   4
 
+/* IO_MUX_CFG bits */
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL   0x1f
+
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX0x0
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN0x1f
+
 struct dp83867_private {
int rx_id_delay;
int tx_id_delay;
int fifo_depth;
+   int io_impedance;
 };
 
 static int dp83867_ack_interrupt(struct phy_device *phydev)
@@ -111,6 +119,14 @@ static int dp83867_of_init(struct phy_device *phydev)
if (!of_node)
return -ENODEV;
 
+   dp83867->io_impedance = -EINVAL;
+
+   /* Optional configuration */
+   if (of_property_read_bool(of_node, "ti,max-output-impedance"))
+   dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
+   else if (of_property_read_bool(of_node, "ti,min-output-impedance"))
+   dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN;
+
ret = of_property_read_u32(of_node, "ti,rx-internal-delay",
   >rx_id_delay);
if (ret)
@@ -184,6 +200,18 @@ static int dp83867_config_init(struct phy_device *phydev)
 
phy_write_mmd_indirect(phydev, DP83867_RGMIIDCTL,
   DP83867_DEVADDR, delay);
+
+   if (dp83867->io_impedance >= 0) {
+   val = phy_read_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+   DP83867_DEVADDR);
+
+   val &= ~DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+   val |= dp83867->io_impedance &
+  DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+
+   phy_write_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+  DP83867_DEVADDR, val);
+   }
}
 
return 0;
-- 
2.10.1.445.g3cdd5d1

[PATCH v4 0/4] add support for impedance control for TI dp83867 phy and fix 2nd ethernet on dra72 rev C evm

[Mugunthan V N]

Add support for configurable impedance control for TI dp83867
phy via devicetree. More documentation in [1].
CPSW second ethernet is not working, fix it by enabling
impedance configuration on the phy.

Verified the patch on DRA72 Rev C evm, logs at [2]. Also pushed
a branch [3] for others to test.

Changes from v3:
* Fixup change log text and no code changes.

Changes from v2:
* Fixed a typo in dts and driver.

Changes from initial version:
* As per Sekhar's comment, instead of passing impedance values,
  change to max and min impedance from DT
* Adopted phy_read_mmd_indirect() to cunnrent implementation.
* Corrected the phy delay timings to the optimal value.

[1] - http://www.ti.com/lit/ds/symlink/dp83867ir.pdf
[2] - http://pastebin.ubuntu.com/23343139/
[3] - git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git dp83867-v4

Mugunthan V N (4):
  net: phy: dp83867: Add documentation for optional impedance control
  net: phy: dp83867: add support for MAC impedance configuration
  ARM: dts: dra72-evm-revc: add phy impedance settings
  ARM: dts: dra72-evm-revc: fix correct phy delay

 .../devicetree/bindings/net/ti,dp83867.txt | 12 ++
 arch/arm/boot/dts/dra72-evm-revc.dts   | 10 
 drivers/net/phy/dp83867.c  | 28 ++
 3 files changed, 46 insertions(+), 4 deletions(-)

-- 
2.10.1.445.g3cdd5d1

[PATCH v4 1/4] net: phy: dp83867: Add documentation for optional impedance control

[Mugunthan V N]

Add documention of ti,min-output-impedance and ti,max-output-impedance
which can be used to correct MAC impedance mismatch using phy extended
registers.

Signed-off-by: Mugunthan V N <mugunthan...@ti.com>
---
 Documentation/devicetree/bindings/net/ti,dp83867.txt | 12 
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt 
b/Documentation/devicetree/bindings/net/ti,dp83867.txt
index 5d21141..85bf945 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83867.txt
+++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt
@@ -9,6 +9,18 @@ Required properties:
- ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
for applicable values
 
+Optional property:
+   - ti,min-output-impedance - MAC Interface Impedance control to set
+   the programmable output impedance to
+   minimum value (35 ohms).
+   - ti,max-output-impedance - MAC Interface Impedance control to set
+   the programmable output impedance to
+   maximum value (70 ohms).
+
+Note: ti,min-output-impedance and ti,max-output-impedance are mutually
+  exclusive. When both properties are present ti,max-output-impedance
+  takes precedence.
+
 Default child nodes are standard Ethernet PHY device
 nodes as described in Documentation/devicetree/bindings/net/phy.txt
 
-- 
2.10.1.445.g3cdd5d1

[PATCH v4 3/4] ARM: dts: dra72-evm-revc: add phy impedance settings

[Mugunthan V N]

The default impedance settings of the phy is not the optimal
value, due to this the second ethernet is not working. Fix it
with correct values which makes the second ethernet port to work.

Signed-off-by: Mugunthan V N <mugunthan...@ti.com>
---
 arch/arm/boot/dts/dra72-evm-revc.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts 
b/arch/arm/boot/dts/dra72-evm-revc.dts
index 064b322..5450367 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -62,6 +62,7 @@
ti,rx-internal-delay = ;
ti,tx-internal-delay = ;
ti,fifo-depth = ;
+   ti,min-output-impedance;
};
 
dp83867_1: ethernet-phy@3 {
@@ -69,5 +70,6 @@
ti,rx-internal-delay = ;
ti,tx-internal-delay = ;
ti,fifo-depth = ;
+   ti,min-output-imepdance;
};
 };
-- 
2.10.1.445.g3cdd5d1

[PATCH v4 4/4] ARM: dts: dra72-evm-revc: fix correct phy delay

[Mugunthan V N]

The current delay settings of the phy are not the optimal value,
fix it with correct values.

Signed-off-by: Mugunthan V N <mugunthan...@ti.com>
---
 arch/arm/boot/dts/dra72-evm-revc.dts | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts 
b/arch/arm/boot/dts/dra72-evm-revc.dts
index 5450367..3b23b32 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -59,16 +59,16 @@
 _mdio {
dp83867_0: ethernet-phy@2 {
reg = <2>;
-   ti,rx-internal-delay = ;
-   ti,tx-internal-delay = ;
+   ti,rx-internal-delay = ;
+   ti,tx-internal-delay = ;
ti,fifo-depth = ;
ti,min-output-impedance;
};
 
dp83867_1: ethernet-phy@3 {
reg = <3>;
-   ti,rx-internal-delay = ;
-   ti,tx-internal-delay = ;
+   ti,rx-internal-delay = ;
+   ti,tx-internal-delay = ;
ti,fifo-depth = ;
ti,min-output-imepdance;
};
-- 
2.10.1.445.g3cdd5d1

Re: [PATCH v3 1/4] net: phy: dp83867: Add documentation for optional impedance control

[Mugunthan V N]

On Monday 10 October 2016 06:48 PM, Rob Herring wrote:
> On Thu, Oct 06, 2016 at 10:43:52AM +0530, Mugunthan V N wrote:
>> Add documention of ti,impedance-control which can be used to
> 
> Needs updating.

Oops, will update this in next version.

> 
>> correct MAC impedance mismatch using phy extended registers.
>>
>> Signed-off-by: Mugunthan V N <mugunthan...@ti.com>
>> ---
>>  Documentation/devicetree/bindings/net/ti,dp83867.txt | 12 
>>  1 file changed, 12 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt 
>> b/Documentation/devicetree/bindings/net/ti,dp83867.txt
>> index 5d21141..85bf945 100644
>> --- a/Documentation/devicetree/bindings/net/ti,dp83867.txt
>> +++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt
>> @@ -9,6 +9,18 @@ Required properties:
>>  - ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
>>  for applicable values
>>  
>> +Optional property:
>> +- ti,min-output-impedance - MAC Interface Impedance control to set
>> +the programmable output impedance to
>> +minimum value (35 ohms).
>> +- ti,max-output-impedance - MAC Interface Impedance control to set
>> +the programmable output impedance to
>> +maximum value (70 ohms).
> 
> Define what are valid range of values for these.

The values are already mentioned in documentation as 35/70 ohms.
Are you mentioning about the register values?

Regards
Mugunthan V N

[PATCH v3 1/4] net: phy: dp83867: Add documentation for optional impedance control

[Mugunthan V N]

Add documention of ti,impedance-control which can be used to
correct MAC impedance mismatch using phy extended registers.

Signed-off-by: Mugunthan V N <mugunthan...@ti.com>
---
 Documentation/devicetree/bindings/net/ti,dp83867.txt | 12 
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt 
b/Documentation/devicetree/bindings/net/ti,dp83867.txt
index 5d21141..85bf945 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83867.txt
+++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt
@@ -9,6 +9,18 @@ Required properties:
- ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
for applicable values
 
+Optional property:
+   - ti,min-output-impedance - MAC Interface Impedance control to set
+   the programmable output impedance to
+   minimum value (35 ohms).
+   - ti,max-output-impedance - MAC Interface Impedance control to set
+   the programmable output impedance to
+   maximum value (70 ohms).
+
+Note: ti,min-output-impedance and ti,max-output-impedance are mutually
+  exclusive. When both properties are present ti,max-output-impedance
+  takes precedence.
+
 Default child nodes are standard Ethernet PHY device
 nodes as described in Documentation/devicetree/bindings/net/phy.txt
 
-- 
2.10.0.372.g6fe1b14

[PATCH v3 0/4] add support for impedance control for TI dp83867 phy and fix 2nd ethernet on dra72 rev C evm

[Mugunthan V N]

Add support for configurable impedance control for TI dp83867
phy via devicetree. More documentation in [1].
CPSW second ethernet is not working, fix it by enabling
impedance configuration on the phy.

Verified the patch on DRA72 Rev C evm, logs at [2]. Also pushed
a branch [3] for others to test.

Changes from v2:
* Fixed a typo in dts and driver.

Changes from initial version:
* As per Sekhar's comment, instead of passing impedance values,
  change to max and min impedance from DT
* Adopted phy_read_mmd_indirect() to cunnrent implementation.
* Corrected the phy delay timings to the optimal value.

[1] - http://www.ti.com/lit/ds/symlink/dp83867ir.pdf
[2] - http://pastebin.ubuntu.com/23283056/
[3] - git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git dp83867-v3

Mugunthan V N (4):
  net: phy: dp83867: Add documentation for optional impedance control
  net: phy: dp83867: add support for MAC impedance configuration
  ARM: dts: dra72-evm-revc: add phy impedance settings
  ARM: dts: dra72-evm-revc: fix correct phy delay

 .../devicetree/bindings/net/ti,dp83867.txt | 12 ++
 arch/arm/boot/dts/dra72-evm-revc.dts   | 10 
 drivers/net/phy/dp83867.c  | 28 ++
 3 files changed, 46 insertions(+), 4 deletions(-)

-- 
2.10.0.372.g6fe1b14

[PATCH v3 2/4] net: phy: dp83867: add support for MAC impedance configuration

[Mugunthan V N]

Add support for programmable MAC impedance configuration

Signed-off-by: Mugunthan V N <mugunthan...@ti.com>
---
 drivers/net/phy/dp83867.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index 91177a4..1b63924 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -33,6 +33,7 @@
 /* Extended Registers */
 #define DP83867_RGMIICTL   0x0032
 #define DP83867_RGMIIDCTL  0x0086
+#define DP83867_IO_MUX_CFG 0x0170
 
 #define DP83867_SW_RESET   BIT(15)
 #define DP83867_SW_RESTART BIT(14)
@@ -62,10 +63,17 @@
 /* RGMIIDCTL bits */
 #define DP83867_RGMII_TX_CLK_DELAY_SHIFT   4
 
+/* IO_MUX_CFG bits */
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL   0x1f
+
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX0x0
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN0x1f
+
 struct dp83867_private {
int rx_id_delay;
int tx_id_delay;
int fifo_depth;
+   int io_impedance;
 };
 
 static int dp83867_ack_interrupt(struct phy_device *phydev)
@@ -111,6 +119,14 @@ static int dp83867_of_init(struct phy_device *phydev)
if (!of_node)
return -ENODEV;
 
+   dp83867->io_impedance = -EINVAL;
+
+   /* Optional configuration */
+   if (of_property_read_bool(of_node, "ti,max-output-impedance"))
+   dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
+   else if (of_property_read_bool(of_node, "ti,min-output-impedance"))
+   dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN;
+
ret = of_property_read_u32(of_node, "ti,rx-internal-delay",
   >rx_id_delay);
if (ret)
@@ -184,6 +200,18 @@ static int dp83867_config_init(struct phy_device *phydev)
 
phy_write_mmd_indirect(phydev, DP83867_RGMIIDCTL,
   DP83867_DEVADDR, delay);
+
+   if (dp83867->io_impedance >= 0) {
+   val = phy_read_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+   DP83867_DEVADDR);
+
+   val &= ~DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+   val |= dp83867->io_impedance &
+  DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+
+   phy_write_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+  DP83867_DEVADDR, val);
+   }
}
 
return 0;
-- 
2.10.0.372.g6fe1b14

[PATCH v3 4/4] ARM: dts: dra72-evm-revc: fix correct phy delay

[Mugunthan V N]

The current delay settings of the phy are not the optimal value,
fix it with correct values.

Signed-off-by: Mugunthan V N <mugunthan...@ti.com>
---
 arch/arm/boot/dts/dra72-evm-revc.dts | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts 
b/arch/arm/boot/dts/dra72-evm-revc.dts
index aafb594..01e1f39 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -59,16 +59,16 @@
 _mdio {
dp83867_0: ethernet-phy@2 {
reg = <2>;
-   ti,rx-internal-delay = ;
-   ti,tx-internal-delay = ;
+   ti,rx-internal-delay = ;
+   ti,tx-internal-delay = ;
ti,fifo-depth = ;
ti,min-output-impedance;
};
 
dp83867_1: ethernet-phy@3 {
reg = <3>;
-   ti,rx-internal-delay = ;
-   ti,tx-internal-delay = ;
+   ti,rx-internal-delay = ;
+   ti,tx-internal-delay = ;
ti,fifo-depth = ;
ti,min-output-imepdance;
};
-- 
2.10.0.372.g6fe1b14

[PATCH v3 3/4] ARM: dts: dra72-evm-revc: add phy impedance settings

[Mugunthan V N]

The default impedance settings of the phy is not the optimal
value, due to this the second ethernet is not working. Fix it
with correct values which makes the second ethernet port to work.

Signed-off-by: Mugunthan V N <mugunthan...@ti.com>
---
 arch/arm/boot/dts/dra72-evm-revc.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts 
b/arch/arm/boot/dts/dra72-evm-revc.dts
index f9cfd3b..aafb594 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -62,6 +62,7 @@
ti,rx-internal-delay = ;
ti,tx-internal-delay = ;
ti,fifo-depth = ;
+   ti,min-output-impedance;
};
 
dp83867_1: ethernet-phy@3 {
@@ -69,5 +70,6 @@
ti,rx-internal-delay = ;
ti,tx-internal-delay = ;
ti,fifo-depth = ;
+   ti,min-output-imepdance;
};
 };
-- 
2.10.0.372.g6fe1b14

Re: [PATCH v2 3/4] ARM: dts: dra72-evm-revc: fix correct phy delay and impedance settings

[Mugunthan V N]

On Tuesday 04 October 2016 06:41 PM, Lokesh Vutla wrote:
> 
> On Tuesday 04 October 2016 06:26 PM, Mugunthan V N wrote:
>> > The default impedance settings of the phy is not the optimal
>> > value, due to this the second ethernet is not working. Fix it
>> > with correct values which makes the second ethernet port to work.
>> > 
>> > Signed-off-by: Mugunthan V N <mugunthan...@ti.com>
>> > ---
>> >  arch/arm/boot/dts/dra72-evm-revc.dts | 2 ++
>> >  1 file changed, 2 insertions(+)
>> > 
>> > diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts 
>> > b/arch/arm/boot/dts/dra72-evm-revc.dts
>> > index f9cfd3b..d626cd7 100644
>> > --- a/arch/arm/boot/dts/dra72-evm-revc.dts
>> > +++ b/arch/arm/boot/dts/dra72-evm-revc.dts
>> > @@ -62,6 +62,7 @@
>> >ti,rx-internal-delay = ;
>> >ti,tx-internal-delay = ;
>> >ti,fifo-depth = ;
>> > +  ti,min-output-imepdance;
> s/imepdance/impedance
> 

Thanks for quick catch. Will fix this in v3.

Regards
Mugunthan V N

Re: [PATCH v2 2/4] net: phy: dp83867: add support for MAC impedance configuration

[Mugunthan V N]

On Tuesday 04 October 2016 06:40 PM, Andrew Lunn wrote:
>> +if (of_property_read_bool(of_node, "ti,max-output-imepdance"))
>> +dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
>> +else if (of_property_read_bool(of_node, "ti,min-output-imepdance"))
> 
> Did you really test this? Or did you make the same typos in your device
> tree file?
> 

I have tested this and attached the log in cover letter. Since there is
a typo error on both dts and driver it worked as expected. Will send a
v3 ASAP.

Regards
Mugunthan V N

[net-next PATCH] drivers: net: cpsw-phy-sel: add support to configure rgmii internal delay

[Mugunthan V N]

Add support to enable CPSW RGMII internal delay (id mode) bits
when rgmii internal delay is configured in phy.

Signed-off-by: Mugunthan V N <mugunthan...@ti.com>
---
 drivers/net/ethernet/ti/cpsw-phy-sel.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/net/ethernet/ti/cpsw-phy-sel.c 
b/drivers/net/ethernet/ti/cpsw-phy-sel.c
index c3e85ac..054a8dd 100644
--- a/drivers/net/ethernet/ti/cpsw-phy-sel.c
+++ b/drivers/net/ethernet/ti/cpsw-phy-sel.c
@@ -30,6 +30,8 @@
 
 #define AM33XX_GMII_SEL_RMII2_IO_CLK_ENBIT(7)
 #define AM33XX_GMII_SEL_RMII1_IO_CLK_ENBIT(6)
+#define AM33XX_GMII_SEL_RGMII2_IDMODE  BIT(5)
+#define AM33XX_GMII_SEL_RGMII1_IDMODE  BIT(4)
 
 #define GMII_SEL_MODE_MASK 0x3
 
@@ -48,6 +50,7 @@ static void cpsw_gmii_sel_am3352(struct cpsw_phy_sel_priv 
*priv,
u32 reg;
u32 mask;
u32 mode = 0;
+   bool rgmii_id = false;
 
reg = readl(priv->gmii_sel);
 
@@ -57,10 +60,14 @@ static void cpsw_gmii_sel_am3352(struct cpsw_phy_sel_priv 
*priv,
break;
 
case PHY_INTERFACE_MODE_RGMII:
+   mode = AM33XX_GMII_SEL_MODE_RGMII;
+   break;
+
case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RGMII_RXID:
case PHY_INTERFACE_MODE_RGMII_TXID:
mode = AM33XX_GMII_SEL_MODE_RGMII;
+   rgmii_id = true;
break;
 
default:
@@ -83,6 +90,13 @@ static void cpsw_gmii_sel_am3352(struct cpsw_phy_sel_priv 
*priv,
mode |= AM33XX_GMII_SEL_RMII2_IO_CLK_EN;
}
 
+   if (rgmii_id) {
+   if (slave == 0)
+   mode |= AM33XX_GMII_SEL_RGMII1_IDMODE;
+   else
+   mode |= AM33XX_GMII_SEL_RGMII2_IDMODE;
+   }
+
reg &= ~mask;
reg |= mode;
 
-- 
2.10.0.372.g6fe1b14

[PATCH v2 2/4] net: phy: dp83867: add support for MAC impedance configuration

[Mugunthan V N]

Add support for programmable MAC impedance configuration

Signed-off-by: Mugunthan V N <mugunthan...@ti.com>
---
 drivers/net/phy/dp83867.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index 91177a4..795ae17 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -33,6 +33,7 @@
 /* Extended Registers */
 #define DP83867_RGMIICTL   0x0032
 #define DP83867_RGMIIDCTL  0x0086
+#define DP83867_IO_MUX_CFG 0x0170
 
 #define DP83867_SW_RESET   BIT(15)
 #define DP83867_SW_RESTART BIT(14)
@@ -62,10 +63,17 @@
 /* RGMIIDCTL bits */
 #define DP83867_RGMII_TX_CLK_DELAY_SHIFT   4
 
+/* IO_MUX_CFG bits */
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL   0x1f
+
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX0x0
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN0x1f
+
 struct dp83867_private {
int rx_id_delay;
int tx_id_delay;
int fifo_depth;
+   int io_impedance;
 };
 
 static int dp83867_ack_interrupt(struct phy_device *phydev)
@@ -111,6 +119,14 @@ static int dp83867_of_init(struct phy_device *phydev)
if (!of_node)
return -ENODEV;
 
+   dp83867->io_impedance = -EINVAL;
+
+   /* Optional configuration */
+   if (of_property_read_bool(of_node, "ti,max-output-imepdance"))
+   dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
+   else if (of_property_read_bool(of_node, "ti,min-output-imepdance"))
+   dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN;
+
ret = of_property_read_u32(of_node, "ti,rx-internal-delay",
   >rx_id_delay);
if (ret)
@@ -184,6 +200,18 @@ static int dp83867_config_init(struct phy_device *phydev)
 
phy_write_mmd_indirect(phydev, DP83867_RGMIIDCTL,
   DP83867_DEVADDR, delay);
+
+   if (dp83867->io_impedance >= 0) {
+   val = phy_read_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+   DP83867_DEVADDR);
+
+   val &= ~DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+   val |= dp83867->io_impedance &
+  DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+
+   phy_write_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+  DP83867_DEVADDR, val);
+   }
}
 
return 0;
-- 
2.10.0.372.g6fe1b14

[PATCH v2 0/4] add support for impedance control for TI dp83867 phy and fix 2nd ethernet on dra72 rev C evm

[Mugunthan V N]

Add support for configurable impedance control for TI dp83867
phy via devicetree. More documentation in [1].
CPSW second ethernet is not working, fix it by enabling
impedance configuration on the phy.

Verified the patch on DRA72 Rev C evm, logs at [2]. Also pushed
a branch [3] for others to test.

Changes from initial version:
* As per Sekhar's comment, instead of passing impedance values,
  change to max and min impedance from DT
* Adopted phy_read_mmd_indirect() to cunnrent implementation.
* Corrected the phy delay timings to the optimal value.

[1] - http://www.ti.com/lit/ds/symlink/dp83867ir.pdf
[2] - http://pastebin.ubuntu.com/23274616/
[3] - git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git dp83867-v2

Mugunthan V N (4):
  net: phy: dp83867: Add documentation for optional impedance control
  net: phy: dp83867: add support for MAC impedance configuration
  ARM: dts: dra72-evm-revc: fix correct phy delay and impedance settings
  ARM: dts: dra72-evm-revc: fix correct phy delay

 .../devicetree/bindings/net/ti,dp83867.txt | 12 ++
 arch/arm/boot/dts/dra72-evm-revc.dts   | 10 
 drivers/net/phy/dp83867.c  | 28 ++
 3 files changed, 46 insertions(+), 4 deletions(-)

-- 
2.10.0.372.g6fe1b14

[PATCH v2 4/4] ARM: dts: dra72-evm-revc: fix correct phy delay

[Mugunthan V N]

The current delay settings of the phy are not the optimal value,
fix it with correct values.

Signed-off-by: Mugunthan V N <mugunthan...@ti.com>
---
 arch/arm/boot/dts/dra72-evm-revc.dts | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts 
b/arch/arm/boot/dts/dra72-evm-revc.dts
index d626cd7..8472a8c 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -59,16 +59,16 @@
 _mdio {
dp83867_0: ethernet-phy@2 {
reg = <2>;
-   ti,rx-internal-delay = ;
-   ti,tx-internal-delay = ;
+   ti,rx-internal-delay = ;
+   ti,tx-internal-delay = ;
ti,fifo-depth = ;
ti,min-output-imepdance;
};
 
dp83867_1: ethernet-phy@3 {
reg = <3>;
-   ti,rx-internal-delay = ;
-   ti,tx-internal-delay = ;
+   ti,rx-internal-delay = ;
+   ti,tx-internal-delay = ;
ti,fifo-depth = ;
ti,min-output-imepdance;
};
-- 
2.10.0.372.g6fe1b14

[PATCH v2 3/4] ARM: dts: dra72-evm-revc: fix correct phy delay and impedance settings

[Mugunthan V N]

The default impedance settings of the phy is not the optimal
value, due to this the second ethernet is not working. Fix it
with correct values which makes the second ethernet port to work.

Signed-off-by: Mugunthan V N <mugunthan...@ti.com>
---
 arch/arm/boot/dts/dra72-evm-revc.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts 
b/arch/arm/boot/dts/dra72-evm-revc.dts
index f9cfd3b..d626cd7 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -62,6 +62,7 @@
ti,rx-internal-delay = ;
ti,tx-internal-delay = ;
ti,fifo-depth = ;
+   ti,min-output-imepdance;
};
 
dp83867_1: ethernet-phy@3 {
@@ -69,5 +70,6 @@
ti,rx-internal-delay = ;
ti,tx-internal-delay = ;
ti,fifo-depth = ;
+   ti,min-output-imepdance;
};
 };
-- 
2.10.0.372.g6fe1b14

[PATCH v2 1/4] net: phy: dp83867: Add documentation for optional impedance control

[Mugunthan V N]

Add documention of ti,impedance-control which can be used to
correct MAC impedance mismatch using phy extended registers.

Signed-off-by: Mugunthan V N <mugunthan...@ti.com>
---
 Documentation/devicetree/bindings/net/ti,dp83867.txt | 12 
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt 
b/Documentation/devicetree/bindings/net/ti,dp83867.txt
index 5d21141..85bf945 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83867.txt
+++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt
@@ -9,6 +9,18 @@ Required properties:
- ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
for applicable values
 
+Optional property:
+   - ti,min-output-impedance - MAC Interface Impedance control to set
+   the programmable output impedance to
+   minimum value (35 ohms).
+   - ti,max-output-impedance - MAC Interface Impedance control to set
+   the programmable output impedance to
+   maximum value (70 ohms).
+
+Note: ti,min-output-impedance and ti,max-output-impedance are mutually
+  exclusive. When both properties are present ti,max-output-impedance
+  takes precedence.
+
 Default child nodes are standard Ethernet PHY device
 nodes as described in Documentation/devicetree/bindings/net/phy.txt
 
-- 
2.10.0.372.g6fe1b14

Re: [PATCH v4 1/5] net: ethernet: ti: davinci_cpdma: split descs num between all channels

[Mugunthan V N]

On Monday 22 August 2016 11:48 PM, Ivan Khoronzhuk wrote:
> Tx channels share same pool of descriptors. Thus one channel can
> block another if pool is emptied by one. But, the shaper should
> decide which channel is allowed to send packets. To avoid such
> impact of one channel on another, let every channel to have its
> own piece of pool.
> 
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronz...@linaro.org>

Reviewed-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH v4 5/5] net: ethernet: ti: cpsw: add ethtool channels support

[Mugunthan V N]

On Monday 22 August 2016 11:48 PM, Ivan Khoronzhuk wrote:
> These ops allow to control number of channels driver is allowed to
> work with at cpdma level. The maximum number of channels is 8 for
> rx and 8 for tx. In dual_emac mode the h/w channels are shared
> between two interfaces and changing number on one interface changes
> number of channels on another.
> 
> How many channels are supported and enabled:
> $ ethtool -l ethX
> 
> Change number of channels (up to 8)
> $ ethtool -L ethX rx 6 tx 6
> 
> Per-channel statistic:
> $ ethtool -S ethX
> 
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronz...@linaro.org>

Reviewed-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH v4 3/5] net: ethernet: ti: cpsw: add multi queue support

[Mugunthan V N]

On Monday 22 August 2016 11:48 PM, Ivan Khoronzhuk wrote:
> The cpsw h/w supports up to 8 tx and 8 rx channels. This patch adds
> multi-queue support to the driver only, shaper configuration will
> be added with separate patch series. Default shaper mode, as
> before, priority mode, but with corrected priority order, 0 - is
> highest priority, 7 - lowest.
> 
> The poll function handles all unprocessed channels, till all of
> them are free, beginning from hi priority channel.
> 
> In dual_emac mode the channels are shared between two network devices,
> as it's with single-queue default mode.
> 
> The statistic for every channel can be read with:
> $ ethtool -S ethX
> 
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronz...@linaro.org>

Reviewed-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH v3 4/5] net: ethernet: ti: davinci_cpdma: move cpdma channel struct macroses to internals

[Mugunthan V N]

On Tuesday 16 August 2016 04:55 AM, Ivan Khoronzhuk wrote:
> Keep the driver internals in C file. Currently it's not required for
> drivers to know rx or tx a channel is, except create function.
> So correct "channel create" function, and use all channel struct
> macroses only for internal use.
> 
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronz...@linaro.org>

Reviewed-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH v3 5/5] net: ethernet: ti: cpsw: add ethtool channels support

[Mugunthan V N]

On Tuesday 16 August 2016 04:55 AM, Ivan Khoronzhuk wrote:
> These ops allow to control number of channels driver is allowed to
> work with at cpdma level. The maximum number of channels is 8 for
> rx and 8 for tx. In dual_emac mode the h/w channels are shared
> between two interfaces and changing number on one interface changes
> number of channels on another.
> 
> How many channels are supported and enabled:
> $ ethtool -l ethX
> 
> Change number of channels (up to 8)
> $ ethtool -L ethX rx 6 tx 6
> 
> Per-channel statistic:
> $ ethtool -S ethX
> 
> Signed-off-by: Ivan Khoronzhuk 
> ---
>  drivers/net/ethernet/ti/cpsw.c | 180 
> -
>  1 file changed, 176 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
> index 6dcbd8a..f02e577 100644
> --- a/drivers/net/ethernet/ti/cpsw.c
> +++ b/drivers/net/ethernet/ti/cpsw.c
> @@ -735,6 +735,11 @@ static void cpsw_rx_handler(void *token, int len, int 
> status)
>   }
>  
>  requeue:
> + if (netif_dormant(ndev)) {
> + dev_kfree_skb_any(new_skb);
> + return;
> + }
> +
>   ch = cpsw->rxch[skb_get_queue_mapping(new_skb)];
>   ret = cpdma_chan_submit(ch, new_skb, new_skb->data,
>   skb_tailroom(new_skb), 0);
> @@ -1267,9 +1272,8 @@ static void cpsw_init_host_port(struct cpsw_priv *priv)
>   }
>  }
>  
> -static int cpsw_fill_rx_channels(struct net_device *ndev)
> +static int cpsw_fill_rx_channels(struct cpsw_priv *priv)

This change can be moved to patch 1/5 where the function definition is
added at first.

>  {
> - struct cpsw_priv *priv = netdev_priv(ndev);
>   struct cpsw_common *cpsw = priv->cpsw;
>   struct sk_buff *skb;
>   int ch, i, ret;
> @@ -1279,7 +1283,7 @@ static int cpsw_fill_rx_channels(struct net_device 
> *ndev)
>  
>   ch_buf_num = cpdma_chan_get_rx_buf_num(cpsw->rxch[ch]);
>   for (i = 0; i < ch_buf_num; i++) {
> - skb = __netdev_alloc_skb_ip_align(ndev,
> + skb = __netdev_alloc_skb_ip_align(priv->ndev,
> cpsw->rx_packet_max,
> GFP_KERNEL);
>   if (!skb) {
> @@ -1397,7 +1401,7 @@ static int cpsw_ndo_open(struct net_device *ndev)
>   enable_irq(cpsw->irqs_table[0]);
>   }
>  
> - ret = cpsw_fill_rx_channels(ndev);
> + ret = cpsw_fill_rx_channels(priv);
>   if (ret < 0)
>   goto err_cleanup;
>  
> @@ -2060,6 +2064,172 @@ static void cpsw_ethtool_op_complete(struct 
> net_device *ndev)
>   cpsw_err(priv, drv, "ethtool complete failed %d\n", ret);
>  }
>  
> +static void cpsw_get_channels(struct net_device *ndev,
> +   struct ethtool_channels *ch)
> +{
> + struct cpsw_common *cpsw = ndev_to_cpsw(ndev);
> +
> + ch->max_combined = 0;
> + ch->max_rx = CPSW_MAX_QUEUES;
> + ch->max_tx = CPSW_MAX_QUEUES;
> + ch->max_other = 0;
> + ch->other_count = 0;
> + ch->rx_count = cpsw->rx_ch_num;
> + ch->tx_count = cpsw->tx_ch_num;
> + ch->combined_count = 0;
> +}
> +
> +static int cpsw_check_ch_settings(struct cpsw_common *cpsw,
> +   struct ethtool_channels *ch)
> +{
> + if (ch->combined_count)
> + return -EINVAL;
> +
> + /* verify we have at least one channel in each direction */
> + if (!ch->rx_count || !ch->tx_count)
> + return -EINVAL;
> +
> + if (ch->rx_count > cpsw->data.channels ||
> + ch->tx_count > cpsw->data.channels)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static int cpsw_update_channels_res(struct cpsw_priv *priv, int ch_num, int 
> rx)
> +{
> + int (*poll)(struct napi_struct *, int);
> + struct cpsw_common *cpsw = priv->cpsw;
> + void (*handler)(void *, int, int);
> + struct cpdma_chan **chan;
> + int ret, *ch;
> +
> + if (rx) {
> + ch = >rx_ch_num;
> + chan = cpsw->rxch;
> + handler = cpsw_rx_handler;
> + poll = cpsw_rx_poll;
> + } else {
> + ch = >tx_ch_num;
> + chan = cpsw->txch;
> + handler = cpsw_tx_handler;
> + poll = cpsw_tx_poll;
> + }
> +
> + while (*ch < ch_num) {
> + chan[*ch] = cpdma_chan_create(cpsw->dma, *ch, handler, rx);
> +
> + if (IS_ERR(chan[*ch]))
> + return PTR_ERR(chan[*ch]);
> +
> + if (!chan[*ch])
> + return -EINVAL;
> +
> + cpsw_info(priv, ifup, "created new %d %s channel\n", *ch,
> +   (rx ? "rx" : "tx"));
> + (*ch)++;
> + }
> +
> + while (*ch > ch_num) {
> + (*ch)--;
> +
> + ret = 

Re: [PATCH v3 2/5] net: ethernet: ti: davinci_cpdma: fix locking while ctrl_stop

[Mugunthan V N]

On Tuesday 16 August 2016 04:55 AM, Ivan Khoronzhuk wrote:
> The interrupts shouldn't be disabled while receiving skb, but while
> ctrl_stop, the channels are stopped and all remaining packets are
> handled with netif_receive_skb():
> 
> lock_irq_save
> cpdma_ctlr_stop
>cpdma_chan_top
>__cpdma_chan_free
>cpsw_rx_handler
>netif_receive_skb
> 
> So, split locking while ctrl stop thus interrupts are still
> enabled while skbs handling. It can cause WARN_ONCE in rare
> cases when ctrl is stopping while not all packets were handled
> with NAPIs.
> 
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronz...@linaro.org>

Reviewed-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH v3 13/13] net: ethernet: ti: cpsw: move ale, cpts and drivers params under cpsw_common

[Mugunthan V N]

On Wednesday 10 August 2016 04:52 AM, Ivan Khoronzhuk wrote:
> The ale, cpts, version, rx_packet_max, bus_freq, interrupt pacing
> parameters are common per net device that uses the same h/w. So,
> move them to common driver structure.
> 
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronz...@linaro.org>

Reviewed-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH v3 10/13] net; ethernet: ti: cpsw: move irq stuff under cpsw_common

[Mugunthan V N]

On Wednesday 10 August 2016 04:52 AM, Ivan Khoronzhuk wrote:
> The irq data are common for net devs in dual_emac mode. So no need to
> hold these data in every priv struct, move them under cpsw_common.
> Also delete irq_num var, as after optimization it's not needed.
> Correct number of irqs to 2, as anyway, driver is using only 2,
> at least for now.
> 
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronz...@linaro.org>

Reviewed-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH v3 12/13] net: ethernet: ti: cpsw: move napi struct to cpsw_common

[Mugunthan V N]

On Wednesday 10 August 2016 04:52 AM, Ivan Khoronzhuk wrote:
> The napi structs are common for both net devices in dual_emac
> mode, In order to not hold duplicate links to them, move to
> cpsw_common.
> 
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronz...@linaro.org>
> ---

Reviewed-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH] drivers: net: cpsw: fix kmemleak false-positive reports for sk buffers

[Mugunthan V N]

On Tuesday 09 August 2016 05:39 PM, Grygorii Strashko wrote:
> Kmemleak reports following false positive memory leaks for each sk
> buffers allocated by CPSW (__netdev_alloc_skb_ip_align()) in
> cpsw_ndo_open() and cpsw_rx_handler():
> 
> unreferenced object 0xea915000 (size 2048):
>   comm "systemd-network", pid 713, jiffies 4294938323 (age 102.180s)
>   hex dump (first 32 bytes):
> 00 58 91 ea ff ff ff ff ff ff ff ff ff ff ff ff  .X..
> ff ff ff ff ff ff fd 0f 00 00 00 00 00 00 00 00  
>   backtrace:
> [] __kmalloc_track_caller+0x1a4/0x230
> [] __alloc_skb+0x68/0x16c
> [] __netdev_alloc_skb+0x40/0x104
> [] cpsw_ndo_open+0x374/0x670 [ti_cpsw]
> [] __dev_open+0xb0/0x114
> [] __dev_change_flags+0x9c/0x14c
> [] dev_change_flags+0x20/0x50
> [] do_setlink+0x2cc/0x78c
> [] rtnl_setlink+0xcc/0x100
> [] rtnetlink_rcv_msg+0x184/0x224
> [] netlink_rcv_skb+0xa8/0xc4
> [] rtnetlink_rcv+0x2c/0x34
> [] netlink_unicast+0x16c/0x1f8
> [] netlink_sendmsg+0x334/0x348
> [] sock_sendmsg+0x1c/0x2c
> [] SyS_sendto+0xc0/0xe8
> 
> unreferenced object 0xec861780 (size 192):
>   comm "softirq", pid 0, jiffies 4294938759 (age 109.540s)
>   hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
> 00 00 00 00 00 b0 5a ed 00 00 00 00 00 00 00 00  ..Z.
>   backtrace:
> [] kmem_cache_alloc+0x190/0x208
> [] __build_skb+0x30/0x98
> [] __netdev_alloc_skb+0xb8/0x104
> [] cpsw_rx_handler+0x68/0x1e4 [ti_cpsw]
> [] __cpdma_chan_free+0xa8/0xc4 [davinci_cpdma]
> [] __cpdma_chan_process+0x14c/0x16c [davinci_cpdma]
> [] cpdma_chan_process+0x44/0x5c [davinci_cpdma]
> [] cpsw_rx_poll+0x1c/0x9c [ti_cpsw]
> [] net_rx_action+0x1f0/0x2ec
> [] __do_softirq+0x134/0x258
> [] do_softirq+0x68/0x70
> [] __local_bh_enable_ip+0xd4/0xe8
> [] _raw_spin_unlock_bh+0x30/0x34
> [] igmp6_group_added+0x4c/0x1bc
> [] ipv6_dev_mc_inc+0x398/0x434
> [] addrconf_dad_work+0x224/0x39c
> 
> This happens because CPSW allocates SK buffers and then passes
> pointers on them in CPDMA where they stored in internal CPPI RAM
> (SRAM) which belongs to DEV MMIO space. Kmemleak does not scan IO
> memory and so reports memory leaks.
> 
> Hence, mark allocated sk buffers as false positive explicitly.
> 
> Cc: Catalin Marinas <catalin.mari...@arm.com>
> Signed-off-by: Grygorii Strashko <grygorii.stras...@ti.com>

Reviewed-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH v3 09/13] net: ethernet: ti: cpsw: move cpdma resources to cpsw_common

[Mugunthan V N]

On Wednesday 10 August 2016 04:52 AM, Ivan Khoronzhuk wrote:
> Every net device private struct holds links to shared cpdma resources.
> No need to save and every time synchronize these resources per net dev.
> So, move it to common driver struct.
> 
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronz...@linaro.org>

Reviewed-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH v3 11/13] net: ethernet: ti: cpsw: move platform data and slaves info to cpsw_common

[Mugunthan V N]

On Wednesday 10 August 2016 04:52 AM, Ivan Khoronzhuk wrote:
> These data are common for net devs in dual_emac mode. No need to hold
> it for every priv instance, so move them under cpsw_common.
> 
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronz...@linaro.org>

Reviewed-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH v3 06/13] net: ethernet: ti: cpsw: create common struct to hold shared driver data

[Mugunthan V N]

On Wednesday 10 August 2016 04:52 AM, Ivan Khoronzhuk wrote:
> This patch simply create holder for common data and as a start moves
> pdev var to it.
> 
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronz...@linaro.org>

Reviewed-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH v3 08/13] net: ethernet: ti: cpsw: move links on h/w registers to cpsw_common

[Mugunthan V N]

On Wednesday 10 August 2016 04:52 AM, Ivan Khoronzhuk wrote:
> The pointers on h/w registers are common for every cpsw_private
> instance, so no need to hold them for every ndev.
> 
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronz...@linaro.org>


Reviewed-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH v3 07/13] net: ethernet: ti: cpsw: replace pdev on dev

[Mugunthan V N]

On Wednesday 10 August 2016 04:52 AM, Ivan Khoronzhuk wrote:
> No need to hold pdev link when only dev is needed.
> This allows to simplify a bunch of cpsw->pdev->dev now and farther.
> 
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronz...@linaro.org>

Reviewed-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH] net: ethernet: ti: cpdma: remove used_desc counter

[Mugunthan V N]

On Thursday 04 August 2016 08:50 PM, Grygorii Strashko wrote:
> The struct cpdma_desc_pool->used_desc field can be safely removed from
> CPDMA driver (and hot patch) because used_descs counter is used just
> for pool consistency check at CPDMA deinitialization and now this
> check can be re-implemnted using gen_pool_size(pool->gen_pool) !=
> gen_pool_avail(pool->gen_pool).
> More over, this will allow to get rid of warnings in
> cpdma_desc_pool_destro()-> WARN_ON(pool->used_desc) which may happen
> because the used_descs is used unprotected, since CPDMA has been
> switched to use genalloc, and may get wrong values on SMP.
> 
> Hence, remove used_desc from struct cpdma_desc_pool.
> 
> Signed-off-by: Grygorii Strashko <grygorii.stras...@ti.com>

Reviewed-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH 1/2] net: davinci_cpdma: reduce time holding ctlr->lock in cpdma_control_set

[Mugunthan V N]

On Tuesday 26 July 2016 05:32 PM, Uwe Kleine-König wrote:
> The only user of cpdma_control_set (i.e. cpsw_ndo_open) doesn't check
> the return code, so it doesn't matter, which error triggers. So the
> checks that are independant of the fields protected by ctlr->lock can be
> moved out of the critical section.
> 
> Signed-off-by: Uwe Kleine-König <u.kleine-koe...@pengutronix.de>

Reviewed-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH v2 05/14] net: ethernet: ti: cpsw: don't check slave num in runtime

[Mugunthan V N]

On Saturday 06 August 2016 04:18 PM, Ivan Khoronzhuk wrote:
> No need to check const slave num in runtime for every packet,
> and ndev for slaves w/o ndev is anyway NULL. So remove redundant
> check.
> 
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronz...@linaro.org>

Reviewed-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH v2 04/14] net: ethernet: ti: cpsw: remove clk var from priv

[Mugunthan V N]

On Saturday 06 August 2016 04:18 PM, Ivan Khoronzhuk wrote:
> There is no need to hold link to clk, it's used only once
> while probe.
> 
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronz...@linaro.org>

Reviewed-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH v2 03/14] net: ethernet: ti: cpsw: remove priv from cpsw_get_slave_port() parameters list

[Mugunthan V N]

On Saturday 06 August 2016 04:18 PM, Ivan Khoronzhuk wrote:
> There is no need in priv here.
> 
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronz...@linaro.org>

Reviewed-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH v2 02/14] net: ethernet: ti: cpsw: remove redundant check in napi poll

[Mugunthan V N]

On Saturday 06 August 2016 04:18 PM, Ivan Khoronzhuk wrote:
> No need to check number of handled packets, when in most cases (> 99%)
> it's not 0. It can be 0 only in rare cases, even in this case
> it's not bad to print just 0.
> 
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronz...@linaro.org>

Reviewed-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH v2 01/14] net: ethernet: ti: cpsw: simplify submit routine

[Mugunthan V N]

On Saturday 06 August 2016 04:18 PM, Ivan Khoronzhuk wrote:
> As second net dev is created only in case of dual_emac mode, port
> number can be figured out in simpler way. Also no need to pass
> redundant ndev struct.
> 
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronz...@linaro.org>

Reviewed-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH v2 15/15] ethernet: ti: davinci_emac: add missing of_node_put after calling of_parse_phandle

[Mugunthan V N]

+omap ML

On Monday 01 August 2016 12:32 PM, Peter Chen wrote:
> of_node_put needs to be called when the device node which is got
> from of_parse_phandle has finished using.
> 
> Signed-off-by: Peter Chen <peter.c...@nxp.com>

Reviewed-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH 15/15] ethernet: ti: davinci_emac: add missing of_node_put after calling of_parse_phandle

[Mugunthan V N]

+ Linux Omap ML

On Wednesday 27 July 2016 01:13 PM, Peter Chen wrote:
>  
>> On Wednesday 27 July 2016 07:50 AM, Peter Chen wrote:
>>> of_node_put needs to be called when the device node which is got from
>>> of_parse_phandle has finished using.
>>>
>>> Signed-off-by: Peter Chen <peter.c...@nxp.com>
>>> ---
>>>  drivers/net/ethernet/ti/davinci_emac.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/net/ethernet/ti/davinci_emac.c
>>> b/drivers/net/ethernet/ti/davinci_emac.c
>>> index c6c5465..d8cb9d0 100644
>>> --- a/drivers/net/ethernet/ti/davinci_emac.c
>>> +++ b/drivers/net/ethernet/ti/davinci_emac.c
>>> @@ -1571,6 +1571,7 @@ static int emac_dev_open(struct net_device *ndev)
>>> if (priv->phy_node) {
>>> phydev = of_phy_connect(ndev, priv->phy_node,
>>> _adjust_link, 0, 0);
>>> +   of_node_put(priv->phy_node);
>>> if (!phydev) {
>>> dev_err(emac_dev, "could not connect to phy %s\n",
>>> priv->phy_node->full_name);
>>>
>>
>> phy_node is accessed in case of of_phy_connect() returns error, so it has to 
>> be
>> moved after the dev_err log
>>
> 
> Yeah, you are right. I will change it, thanks.
> 

I see one more problem, when you stop and open the interface there is no
way to get the phy_node and interface will be unusable, so of_node_put()
should be moved to remove()

Regards
Mugunthan V N

Re: [PATCH v2 3/4] drivers: net: cpsw: use of_platform_depopulate()

[Mugunthan V N]

On Thursday 28 July 2016 11:20 PM, Grygorii Strashko wrote:
> Use of_platform_depopulate() in cpsw_remove() instead of
> of_device_unregister(), because CSPW child devices will not be
> recreated otherwise on next insmod. of_platform_depopulate() is
> correct way now as it will ensure that all steps done in
> of_platform_populate() are reverted, including cleaning up of
> OF_POPULATED flag.
> 
> Signed-off-by: Grygorii Strashko <grygorii.stras...@ti.com>

Reviewed-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH v2 2/4] drivers: net: cpsw: fix wrong regs access in cpsw_remove

[Mugunthan V N]

On Thursday 28 July 2016 11:20 PM, Grygorii Strashko wrote:
> The L3 error will be generated and system will crash during unloading
> of CPSW driver if CPSW is used as module and ethX devices are down.
> This happens because CPSW can be power off by PM runtime now when ethX
> devices are down.
> 
> Hence, ensure that CPSW powered up by PM runtime before performing any
> deinitialization actions which require CPSW registers access. In case
> of PM runtime error just leave cpsw_remove() as we can't do anything
> anymore.
> 
> Signed-off-by: Grygorii Strashko <grygorii.stras...@ti.com>

Reviewed-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH v2 1/4] net: ethernet: ti: cpdma: fix lockup in cpdma_ctlr_destroy()

[Mugunthan V N]

On Thursday 28 July 2016 11:20 PM, Grygorii Strashko wrote:
> Fix deadlock in cpdma_ctlr_destroy() which is triggered now on
> cpsw module removal:
>  cpsw_remove()
>  - cpdma_ctlr_destroy()
>- spin_lock_irqsave(>lock, flags)
>- cpdma_ctlr_stop()
>  - spin_lock_irqsave(>lock, flags);
>- cpdma_chan_destroy()
>  - spin_lock_irqsave(>lock, flags);
> 
> The issue has not been observed before because CPDMA channels have
> been destroyed manually by CPSW until commit d941ebe88a41 ("net:
> ethernet: ti: cpsw: use destroy ctlr to destroy channels") was merged.
> 
> Signed-off-by: Grygorii Strashko <grygorii.stras...@ti.com>

Reviewed-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH 15/15] ethernet: ti: davinci_emac: add missing of_node_put after calling of_parse_phandle

[Mugunthan V N]

On Wednesday 27 July 2016 07:50 AM, Peter Chen wrote:
> of_node_put needs to be called when the device node which is got
> from of_parse_phandle has finished using.
> 
> Signed-off-by: Peter Chen <peter.c...@nxp.com>
> ---
>  drivers/net/ethernet/ti/davinci_emac.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/ethernet/ti/davinci_emac.c 
> b/drivers/net/ethernet/ti/davinci_emac.c
> index c6c5465..d8cb9d0 100644
> --- a/drivers/net/ethernet/ti/davinci_emac.c
> +++ b/drivers/net/ethernet/ti/davinci_emac.c
> @@ -1571,6 +1571,7 @@ static int emac_dev_open(struct net_device *ndev)
>   if (priv->phy_node) {
>   phydev = of_phy_connect(ndev, priv->phy_node,
>   _adjust_link, 0, 0);
> + of_node_put(priv->phy_node);
>   if (!phydev) {
>   dev_err(emac_dev, "could not connect to phy %s\n",
>   priv->phy_node->full_name);
> 

phy_node is accessed in case of of_phy_connect() returns error, so it
has to be moved after the dev_err log

Regards
Mugunthan V N

Re: [net-next PATCH 1/3] net: phy: dp83867: Add documentation for optional impedance control

[Mugunthan V N]

Rob,

On Friday 22 July 2016 02:44 AM, Rob Herring wrote:
> On Thu, Jul 21, 2016 at 11:52:36AM +0530, Sekhar Nori wrote:
>> Nishanth,
>>
>> On Wednesday 20 July 2016 09:03 PM, Nishanth Menon wrote:
>>> On 07/20/2016 09:56 AM, Mugunthan V N wrote:
>>>> Add documention of ti,impedance-control which can be used to
>>>> correct MAC impedance mismatch using phy extended registers.
>>>>
>>>> Signed-off-by: Mugunthan V N <mugunthan...@ti.com>
>>>> ---
>>>>   Documentation/devicetree/bindings/net/ti,dp83867.txt | 7 +++
>>>>   1 file changed, 7 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt
>>>> b/Documentation/devicetree/bindings/net/ti,dp83867.txt
>>>> index 5d21141..531ea3c5 100644
>>>> --- a/Documentation/devicetree/bindings/net/ti,dp83867.txt
>>>> +++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt
>>>> @@ -9,6 +9,13 @@ Required properties:
>>>>   - ti,fifo-depth - Transmitt FIFO depth- see
>>>> dt-bindings/net/ti-dp83867.h
>>>>   for applicable values
>>>>
>>>> +Optional property:
>>>> +- ti,impedance-control - MAC Interface Impedance control to vary the
>>>> + output impedance with an approximate range
>>>> + from 35-70 ohms in 32 steps. Value range can
>>>> + be 0x0 to 0x1f. Lowest impedance value is
>>>> + 0x1f and highest impedance being 0x0.
>>>> +
>>>
>>> Should'nt you be using the impedance values of 35 to 70 as the valid
>>> values here? that would be the hardware description, and the values to
>>> program corresponding to those are 0x00 to 0x1f. Right?
>>>
>>> Rob: is'nt that the right way to do it?
> 
> Normally, yes that is preferred. I don't have an issue with it here if 
> that is what makes sense.
> 
>> Agree that that is usually the right way to do it. I believe this case
>> is bit peculiar though. Here is the extract from the datasheet[1] about
>> how the register in question works.
>>
>> "
>> Output impedance approximate range from 35-70 ohms in 32 steps.
>> Lowest being 0 and highest being 0. Range and Step size
>> will vary with process.
>>
>> Default is set to 50 ohms by trim. But the default register value can
>> vary by process. Non default values of MAC I/O impedance can be
>> used based on trace impedance. Mismatch between device and
>> trace impedance can cause voltage overshoot and undershoot.
>> "
>>
>> So clearly, there is no easy correspondence that the hardware guarantees
>> between output impedance ohmage and the register value programmed. Only
>> couple of things are guaranteed.
>>
>> 1) Programming a value of 0 gives approximately 35 ohms
>> 2) Programming a value of 0x1F gives approximately 70 ohms
>> 3) Default value of the register gives 50 ohms (the default value could
>> vary by device).
>> 4) Programming a value in between will give some ohmage in the
>> approximate range 35-70 (curve is unknown).

Sekhar got it wrong, programming 0x1F provides the minimum impedance of
35 ohms and 0x0 provides the maximum impedance of 70 ohms.

>>
>> Given this, I am not sure how one can convert a given user supplied ohms
>> values to a reasonable register value. Clearly, the register is supposed
>> to be programmed by experimentation, not calculation.
> 
> So your are going to change from a known value tuned for the individual 
> Si (50ohm) to the same value for all chips (at least for a given board). 
> Or does this get set by firmware at boot? If not, seems like you would 
> want to specify a delta from the default register value in this case.

The delta will not be constant for each steps of the register content.
So this approach cannot be taken.

> 
>> That said, we could take another approach. At least for the current
>> issue we are trying to address, we only need to configure the register
>> to max value. And given the nature of the register, I am pretty sure
>> that is what most people will end up doing.
> 
> How does the max value get determined? Possibly it should just be set in 
> the kernel.

Yes, the min/max value will be determined in the kernel and the DT will
have either of the properties below.

>  
>> So, may be we have two properties:
>>
>> ti,max-output-impedance
>> ti,min-output-imepdance
> 
> Just define max if that's all you currently need.

Currently we care about only the min-output-impedance (register content
0x1f). Will respin the patch using ti,min-output-impedance.

Regards
Mugunthan V N

[net-next PATCH 1/3] net: phy: dp83867: Add documentation for optional impedance control

[Mugunthan V N]

Add documention of ti,impedance-control which can be used to
correct MAC impedance mismatch using phy extended registers.

Signed-off-by: Mugunthan V N <mugunthan...@ti.com>
---
 Documentation/devicetree/bindings/net/ti,dp83867.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt 
b/Documentation/devicetree/bindings/net/ti,dp83867.txt
index 5d21141..531ea3c5 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83867.txt
+++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt
@@ -9,6 +9,13 @@ Required properties:
- ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
for applicable values
 
+Optional property:
+   - ti,impedance-control - MAC Interface Impedance control to vary the
+output impedance with an approximate range
+from 35-70 ohms in 32 steps. Value range can
+be 0x0 to 0x1f. Lowest impedance value is
+0x1f and highest impedance being 0x0.
+
 Default child nodes are standard Ethernet PHY device
 nodes as described in Documentation/devicetree/bindings/net/phy.txt
 
-- 
2.9.2.368.g08bb350

[net-next PATCH 3/3] ARM: dts: dra72-evm-revc: fix non-working cpsw second ethernet

[Mugunthan V N]

Second ethernet of cpsw is not working, make it work by adding
impedance configuration.

Signed-off-by: Mugunthan V N <mugunthan...@ti.com>
---
 arch/arm/boot/dts/dra72-evm-revc.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts 
b/arch/arm/boot/dts/dra72-evm-revc.dts
index f9cfd3b..4313de5 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -69,5 +69,7 @@
ti,rx-internal-delay = ;
ti,tx-internal-delay = ;
ti,fifo-depth = ;
+   ti,impedance-control = <0x1f>;
};
 };
+
-- 
2.9.2.368.g08bb350

[net-next PATCH 2/3] net: phy: dp83867: add support for MAC impedance configuration

[Mugunthan V N]

Add support for programmable MAC impedance configuration

Signed-off-by: Mugunthan V N <mugunthan...@ti.com>
---
 drivers/net/phy/dp83867.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index 91177a4..ace3558 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -33,6 +33,7 @@
 /* Extended Registers */
 #define DP83867_RGMIICTL   0x0032
 #define DP83867_RGMIIDCTL  0x0086
+#define DP83867_IO_MUX_CFG 0x0170
 
 #define DP83867_SW_RESET   BIT(15)
 #define DP83867_SW_RESTART BIT(14)
@@ -62,10 +63,14 @@
 /* RGMIIDCTL bits */
 #define DP83867_RGMII_TX_CLK_DELAY_SHIFT   4
 
+/* IO_MUX_CFG bits */
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL   0x1F
+
 struct dp83867_private {
int rx_id_delay;
int tx_id_delay;
int fifo_depth;
+   int io_impedance;
 };
 
 static int dp83867_ack_interrupt(struct phy_device *phydev)
@@ -111,6 +116,12 @@ static int dp83867_of_init(struct phy_device *phydev)
if (!of_node)
return -ENODEV;
 
+   dp83867->io_impedance = -EINVAL;
+
+   /* Optional configuration */
+   of_property_read_u32(of_node, "ti,impedance-control",
+>io_impedance);
+
ret = of_property_read_u32(of_node, "ti,rx-internal-delay",
   >rx_id_delay);
if (ret)
@@ -184,6 +195,17 @@ static int dp83867_config_init(struct phy_device *phydev)
 
phy_write_mmd_indirect(phydev, DP83867_RGMIIDCTL,
   DP83867_DEVADDR, delay);
+
+   if (dp83867->io_impedance >= 0) {
+   val = phy_read_mmd_indirect(phydev,
+   DP83867_IO_MUX_CFG,
+   DP83867_DEVADDR);
+   val &= ~DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+   val |= dp83867->io_impedance &
+  DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+   phy_write_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+  DP83867_DEVADDR, val);
+   }
}
 
return 0;
-- 
2.9.2.368.g08bb350

[net-next PATCH 0/3] add support for impedance control for TI dp83867 phy and fix 2nd ethernet on dra72 rev C evm

[Mugunthan V N]

Add support for configurable impedance control for TI dp83867
phy via devicetree. More documentation in [1]
CPSW second ethernet is not working, fix it by enabling
impedance configuration on the phy.

Public Datasheet - http://www.ti.com/lit/ds/symlink/dp83867ir.pdf

Mugunthan V N (3):
  net: phy: dp83867: Add documentation for optional impedance control
  net: phy: dp83867: add support for MAC impedance configuration
  ARM: dts: dra72-evm-revc: fix non-working cpsw second ethernet

 .../devicetree/bindings/net/ti,dp83867.txt |  7 +++
 arch/arm/boot/dts/dra72-evm-revc.dts   |  2 ++
 drivers/net/phy/dp83867.c  | 22 ++
 3 files changed, 31 insertions(+)

-- 
2.9.2.368.g08bb350

Re: [PATCH v2 00/15] drivers: net: cpsw: improve runtime pm

[Mugunthan V N]

On Friday 24 June 2016 11:53 PM, Grygorii Strashko wrote:
> This series intended to improve runtime PM and allow CPSW to be
> RPM suspended when all ethX netdevices are down.
> 
> To achieve above goal it is required to relax runtime PM constraints for
> Davinci MDIO which blocks CPSW runtime PM now, because Davinci MDIO is always
> powered on during probe and powered off only when it's going to be removed.
> - Patches 6-11 implement PM runtime autosuspend for Davinci MDIO, but keep it
> disabled by default, because Davinci MDIO is integrated in big set of TI 
> devices
> and not all of them verified to work correctly with RPM autosuspend enabled:
>  expected to work on SoCs where MDIO is defined as part of CPSW in DT
>  (cpsw.c DRA7/am57x, am437x, am335x)
> The CPSW need to be fixed before RPM suspended can be allowed:
>  - Patches 1-5 ensure that CPSW will not cause L3 errors while it is in RPM
>suspended state.
> 
> Davinci MDIO RPM autosuspend can be enabled through sysfs:
>  echo 100 > 
> /sys/devices/../48484000.ethernet/48485000.mdio/power/autosuspend_delay_ms
> 
> Patches 12 - 15: introduce new compatible string "ti,cpsw-mdio" which is used
> then to enable RPM for am335x/am437x/dra7 SoCs.
> 
> Tested on am335x, am437x, am572x and k2g (on k2g with RPM disabled for 
> Davinci MDIO)
> These changes should not affect on errata i877 implementation on DRA7.
> 
> Power measurement on am335x GP EVM:
>  Without this series:  547.60 mW total SoC power
>  With this series + "ifconfig eth0 down": 477.32 mW Total Soc Power
> 
> Changes in v2:
> - CPSW ethtool interface updated to use .begin()/.complete() callbacks
> - kbuild failure fixed
> - davinci_mdio DT updated with proper description of allowed compatible 
> strings
>   combinations
> 
> Link on v1:
>  https://lkml.org/lkml/2016/6/15/362

For the series.
Reviewed-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

> 
> Grygorii Strashko (15):
>   drivers: net: cpsw: fix suspend when all ethX devices are down
>   drivers: net: cpsw: check return code from pm runtime calls
>   drivers: net: cpsw: remove pm runtime calls from suspend callbacks
>   drivers: net: cpsw: ethtool: fix accessing to suspended device
>   drivers: net: cpsw: ndev: fix accessing to suspended device
>   drivers: net: davinci_mdio: do pm runtime initialization later in probe
>   drivers: net: davinci_mdio: remove pm runtime calls from suspend callbacks
>   drivers: net: davinci_mdio: drop suspended and lock fields from mdio_data
>   drivers: net: davinci_mdio: split reset function on init_clk and enable
>   drivers: net: davinci_mdio: add pm runtime callbacks
>   drivers: net: davinci_mdio: implement pm runtime auto mode
>   net: davinci_mdio: document missed "ti,am4372-mdio" compat string
>   net: davinci_mdio: introduce "ti,cpsw-mdio" compat string
>   drivers: net: davinci_mdio: enable pm runtime auto for ti cpsw-mdio
>   ARM: dts: am335x/am437x/dra7: use new "ti,cpsw-mdio" compat string
> 
>  .../devicetree/bindings/net/davinci-mdio.txt   |   5 +-
>  arch/arm/boot/dts/am33xx.dtsi  |   2 +-
>  arch/arm/boot/dts/am4372.dtsi  |   2 +-
>  arch/arm/boot/dts/dra7.dtsi|   2 +-
>  drivers/net/ethernet/ti/cpsw.c |  79 --
>  drivers/net/ethernet/ti/davinci_mdio.c | 169 
> +
>  6 files changed, 182 insertions(+), 77 deletions(-)
> 

Re: [PATCH v2] net: ethernet: ti: cpdma: switch to use genalloc

[Mugunthan V N]

On Friday 24 June 2016 05:13 PM, Grygorii Strashko wrote:
> TI CPDMA currently uses a bitmap for tracking descriptors alloactions
> allocations, but The genalloc already handles the same and can be used
> as with special memory (SRAM) as with DMA cherent memory chank
> (dma_alloc_coherent()). Hence, switch to using genalloc and add
> desc_num property for each channel for limitation of max number of
> allowed descriptors for each CPDMA channel. This patch do not affect
> on net throuput.
> 
> Tested-by: Ivan Khoronzhuk <ivan.khoronz...@linaro.org> 
> Signed-off-by: Grygorii Strashko <grygorii.stras...@ti.com>

Acked-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH] net: ethernet: ti: cpdma: switch to use genalloc

[Mugunthan V N]

On Thursday 23 June 2016 06:26 PM, Ivan Khoronzhuk wrote:
> 
> 
> On 23.06.16 15:36, Grygorii Strashko wrote:
>> TI CPDMA currently uses a bitmap for tracking descriptors alloactions
>> allocations, but The genalloc already handles the same and can be used
>> as with special memory (SRAM) as with DMA cherent memory chank
>> (dma_alloc_coherent()). Hence, switch to using genalloc and add
>> desc_num property for each channel for limitation of max number of
>> allowed descriptors for each CPDMA channel. This patch do not affect
>> on net throuput.
>>
>> Cc: Ivan Khoronzhuk <ivan.khoronz...@linaro.org>
>> Signed-off-by: Grygorii Strashko <grygorii.stras...@ti.com>
>> ---
>> Testing
>> TCP window: 256K, bandwidth in Mbits/sec:
>>   host: iperf -s
>>   device: iperf -c  172.22.39.17 -t600 -i5 -d -w128K
>>
>> AM437x-idk, 1Gbps link
>>   before: : 341.60, after: 232+123=355
>> am57xx-beagle-x15, 1Gbps link
>>   before: : 1112.80, after: 814+321=1135
>> am335x-boneblack, 100Mbps link
>>   before: : 162.40, after: 72+93=165
>>
>>   drivers/net/ethernet/ti/davinci_cpdma.c | 136
>> +++-
>>   1 file changed, 62 insertions(+), 74 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c
>> b/drivers/net/ethernet/ti/davinci_cpdma.c
>> index 18bf3a8..03b9882 100644
>> --- a/drivers/net/ethernet/ti/davinci_cpdma.c
>> +++ b/drivers/net/ethernet/ti/davinci_cpdma.c
>> @@ -21,7 +21,7 @@
>>   #include 
>>   #include 
>>   #include 
>> -
>> +#include 
>>   #include "davinci_cpdma.h"
>>
>>   /* DMA Registers */
>> @@ -87,9 +87,8 @@ struct cpdma_desc_pool {
>>   void*cpumap;/* dma_alloc map */
>>   intdesc_size, mem_size;
>>   intnum_desc, used_desc;
>> -unsigned long*bitmap;
>>   struct device*dev;
>> -spinlock_tlock;
>> +struct gen_pool*gen_pool;
>>   };
>>
>>   enum cpdma_state {
>> @@ -117,6 +116,7 @@ struct cpdma_chan {
>>   intchan_num;
>>   spinlock_tlock;
>>   intcount;
>> +u32desc_num;
>>   u32mask;
>>   cpdma_handler_fnhandler;
>>   enum dma_data_directiondir;
>> @@ -145,6 +145,20 @@ struct cpdma_chan {
>>(directed << CPDMA_TO_PORT_SHIFT));\
>>   } while (0)
>>
>> +static void cpdma_desc_pool_destroy(struct cpdma_desc_pool *pool)
>> +{
>> +if (!pool)
>> +return;
>> +
>> +WARN_ON(pool->used_desc);
>> +if (pool->cpumap) {
>> +dma_free_coherent(pool->dev, pool->mem_size, pool->cpumap,
>> +  pool->phys);
>> +} else {
>> +iounmap(pool->iomap);
>> +}
>> +}
>> +
> single if, brackets?

if() has multiple line statement, so brackets are must.

Regards
Mugunthan V N

> 
>>   /*
>>* Utility constructs for a cpdma descriptor pool.  Some devices
>> (e.g. davinci
>>* emac) have dedicated on-chip memory for these descriptors.  Some
>> other
>> @@ -155,24 +169,25 @@ static struct cpdma_desc_pool *
>>   cpdma_desc_pool_create(struct device *dev, u32 phys, dma_addr_t
>> hw_addr,
>>   int size, int align)
>>   {
>> -int bitmap_size;
>>   struct cpdma_desc_pool *pool;
>> +int ret;
>>
>>   pool = devm_kzalloc(dev, sizeof(*pool), GFP_KERNEL);
>>   if (!pool)
>> -goto fail;
>> -
>> -spin_lock_init(>lock);
>> +goto gen_pool_create_fail;
>>
>>   pool->dev= dev;
>>   pool->mem_size= size;
>>   pool->desc_size= ALIGN(sizeof(struct cpdma_desc), align);
>>   pool->num_desc= size / pool->desc_size;
>>
>> -bitmap_size  = (pool->num_desc / BITS_PER_LONG) * sizeof(long);
>> -pool->bitmap = devm_kzalloc(dev, bitmap_size, GFP_KERNEL);
>> -if (!pool->bitmap)
>> -goto fail;
>> +pool->gen_pool = devm_gen_pool_create(dev,
>> ilog2(pool->desc_size), -1,
>> +  "cpdma");
>> +if (IS_ERR(pool->gen_pool)) {
>> +dev_err(dev, "pool create failed %ld\n",
>> +PTR_ERR(pool->gen_pool));
>> +goto gen_pool_create_fail;
>> +}
>>
&

Re: [PATCH] net: ethernet: ti: cpdma: switch to use genalloc

[Mugunthan V N]

On Thursday 23 June 2016 06:06 PM, Grygorii Strashko wrote:
> TI CPDMA currently uses a bitmap for tracking descriptors alloactions
> allocations, but The genalloc already handles the same and can be used
> as with special memory (SRAM) as with DMA cherent memory chank
> (dma_alloc_coherent()). Hence, switch to using genalloc and add
> desc_num property for each channel for limitation of max number of
> allowed descriptors for each CPDMA channel. This patch do not affect
> on net throuput.
> 
> Cc: Ivan Khoronzhuk <ivan.khoronz...@linaro.org>
> Signed-off-by: Grygorii Strashko <grygorii.stras...@ti.com>

Acked-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH v3 0/2] net: ethernet: ti: cpsw: delete rx_descs property

[Mugunthan V N]

On Friday 17 June 2016 03:55 PM, Ivan Khoronzhuk wrote:
> There is no reason in rx_descs property because davinici_cpdma
> driver splits pool of descriptors equally between tx and rx channels.
> So, this patch series makes driver to use available number of
> descriptors for rx channels.
> 
> Based on
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
> master
> 
> Since v2:
> - add declaration of buf_num in correct order
> 
> Since v1:
> - separate device tree and driver patches
> - return number of rx buffers from cpdma driver
> 

Acked-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH v2 0/2] net: ethernet: ti: cpsw: delete rx_descs property

[Mugunthan V N]

On Tuesday 14 June 2016 06:08 PM, Ivan Khoronzhuk wrote:
> 
> 
> On 13.06.16 18:19, Andrew F. Davis wrote:
>> On 06/13/2016 03:22 AM, Mugunthan V N wrote:
>>> On Saturday 11 June 2016 04:34 AM, Schuyler Patton wrote:
>>>>
>>>>
>>>> On 06/08/2016 07:03 PM, Ivan Khoronzhuk wrote:
>>>>>
>>>>>
>>>>> On 09.06.16 02:11, Schuyler Patton wrote:
>>>>>>
>>>>>>
>>>>>> On 06/08/2016 09:06 AM, Ivan Khoronzhuk wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 08.06.16 17:01, Ivan Khoronzhuk wrote:
>>>>>>>> Hi Schuyer,
>>>>>>>>
>>>>>>>> On 07.06.16 18:26, Schuyler Patton wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On 06/07/2016 08:59 AM, Ivan Khoronzhuk wrote:
>>>>>>>>>> There is no reason in rx_descs property because davinici_cpdma
>>>>>>>>>> driver splits pool of descriptors equally between tx and rx
>>>>>>>>>> channels.
>>>>>>>>>> So, this patch series makes driver to use available number of
>>>>>>>>>> descriptors for rx channels.
>>>>>>>>>
>>>>>>>>> I agree with the idea of consolidating how the descriptors are
>>>>>>>>> defined because of
>>>>>>>>> the two variable components, number and size of the pool can be
>>>>>>>>> confusing to
>>>>>>>>> end users. I would like to request to change how it is being
>>>>>>>>> proposed here.
>>>>>>>>>
>>>>>>>>> I think the number of descriptors should be left in the device
>>>>>>>>> tree source file as
>>>>>>>>> is and remove the BD size variable and have the driver calculate
>>>>>>>>> the size of the
>>>>>>>>> pool necessary to support the descriptor request. From an user
>>>>>>>>> perspective it is
>>>>>>>>> easier I think to be able to list the number of descriptors
>>>>>>>>> necessary vs. the size
>>>>>>>>> of the pool.
>>>>>>>>>
>>>>>>>>> Since the patch series points out how it is used so in the driver
>>>>>>>>> so to make that
>>>>>>>>> consistent is perhaps change rx_descs to total_descs.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Schuyler
>>>>>>>>
>>>>>>>> The DT entry for cpsw doesn't have property for size of the pool.
>>>>>>>> It contains only BD ram size, if you mean this. The size of the
>>>>>>>> pool is
>>>>>>>> software decision. Current version of DT entry contain only rx desc
>>>>>>>> number.
>>>>>>>> That is not correct, as it depends on the size of the descriptor,
>>>>>>>> which is also
>>>>>>>> h/w parameter. The DT entry has to describe only h/w part and
>>>>>>>> shouldn't contain
>>>>>>>> driver implementation details, and I'm looking on it from this
>>>>>>>> perspective.
>>>>>>>>
>>>>>>>> Besides, rx_descs describes only rx number of descriptors, that are
>>>>>>>> taken from
>>>>>>>> the same pool as tx descriptors, and setting rx desc to some new
>>>>>>>> value doesn't
>>>>>>>> mean that rest of them are freed for tx. Also, I'm going to send
>>>>>>>> series that
>>>>>>>> adds multi channel support to the driver, and in this case,
>>>>>>>> splitting of the
>>>>>>>> pool will be more sophisticated than now, after what setting those
>>>>>>>> parameters
>>>>>>>> for user (he should do this via device tree) can be even more
>>>>>>>> confusing. But,
>>>>>>> should -> shouldn't
>>>>>>>
>>>>>>>> as it's supposed, it's software decision that shouldn't leak to the
&

Re: [PATCH v2 0/2] net: ethernet: ti: cpsw: delete rx_descs property

[Mugunthan V N]

fter previous was freed).
>> That means, 64 rx descs are unused. In case of rx descriptor
>> exhaustion, an user can
>> set rx_descs to 128, for instance, in this case all descriptors will
>> be in use, but then question,
>> why intentionally limit number of rx descs, anyway rest 64 descs
>> cannot be used for other
>> purposes. In case of this patch, all rx descs are in use, and no need
>> to correct number
>> of rx descs anymore, use all of themand it doesn't have impact on
>> performance, as
>> anyway, bunch of rx descs were simply limited by DT and unused. So,
>> probably, there is no
>> reason to worry about that.
> 
> When we see this issue we set the descriptors to DDR and put a large number
> in the desc count. unfortunately I wish I could provide a number,
> usually the issue
> is a volume burst of short UDP packets.
> 
>>
>> PS:
>> It doesn't concern this patch, but, which PPS makes rx descs to be
>> exhausted?...
>> (In this case "desc_alloc_fail" counter contains some value for rx
>> channel,
>> and can be read with "ethtool -S eth0". Also, the user will be WARNed
>> ON by the driver)
>>
>> it's interesting to test it, I'm worrying about, because in case of
>> multichannel,
>> the pool is split between all channels... they are throughput limited,
>> but
>> anyway, it's good to correlate the number of descs with throughput
>> assigned to
>> a channel, if possible. That has to be possible, if setting to 128
>> helps, then
>> has to be value between 64 and 128 to make handling of rx packets fast
>> enough.
>> After what, can be calculated correlation between number of rx descs
>> and throughput
>> split between channels
> 
> With gigabit networks 64 or 128 rx descriptors is not going to enough to
> fix the
> DMA overrun problem. Usually we set this number to an arbitrarily large
> 2000
> descriptors in external DDR to demonstrate it is possible to not drop
> packets. All
> this does is move the problem higher up so that the drops occur in network
> stack if the ARM is overloaded. With the high speed networks I would like
> to propose that the descriptor pool or pools are moved to DDR by
> default. It would
> be nice to have some reconfigurability or set a pool size that reduces
> or eliminates
> the DMA issue that is seen in these types of applications.
> 
> This test gets used a lot, which is to send very short UDP packets. If I
> have the math
> right, a 52 byte (64 byte with the inter-frame gap) UDP packet the
> default 64
> descriptors gets consumed in roughly 33uS. There are the switch fifos
> which will also
> allow some headroom, but a user was dropping packets at the switch when
> they
> were bursting 360 packets at the processor on a gigabit link
> 

I too agree that rx-descs can be derived from the pool size and
descriptor size in driver itself. The current driver uses bd_ram_size to
set the pool size when the descriptors are placed in DDR which is wrong.

Here I propose an idea to solve Schuyler's concern to keep the
descriptors in DDR when a system need more rx descriptors for lossless
UDB performance.

The DT property rx-descs can be removed and add a new DT property
*pool_size* to add support for descriptors memory size in DDR and define
a pool size which the system needs for a network to have lossless UDP
transfers.

So based on no_bd_ram DT entry, the driver can decide whether it can use
internal BD-ram or DDR to initialize the cpdma driver.

Regards
Mugunthan V N

Re: [PATCH net-next 4/5] treewide: replace dev->trans_start update with helper

[Mugunthan V N]

On Tuesday 03 May 2016 08:03 PM, Florian Westphal wrote:
> Replace all trans_start updates with netif_trans_update helper.
> change was done via spatch:
> 
> struct net_device *d;
> @@
> - d->trans_start = jiffies
> + netif_trans_update(d)
> 
> Compile tested only.
> 
> Cc: user-mode-linux-de...@lists.sourceforge.net
> Cc: linux-xte...@linux-xtensa.org
> Cc: linux1394-de...@lists.sourceforge.net
> Cc: linux-r...@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Cc: mpt-fusionlinux@broadcom.com
> Cc: linux-s...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-par...@vger.kernel.org
> Cc: linux-o...@vger.kernel.org
> Cc: linux-h...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-wirel...@vger.kernel.org
> Cc: linux-s...@vger.kernel.org
> Cc: de...@driverdev.osuosl.org
> Cc: b.a.t.m@lists.open-mesh.org
> Cc: linux-blueto...@vger.kernel.org
> Signed-off-by: Florian Westphal <f...@strlen.de>
> ---

snip...


> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
> index 0fa75a8..3d4662d 100644
> --- a/drivers/net/ethernet/ti/cpsw.c
> +++ b/drivers/net/ethernet/ti/cpsw.c
> @@ -1381,7 +1381,7 @@ static netdev_tx_t cpsw_ndo_start_xmit(struct sk_buff 
> *skb,
>   struct cpsw_priv *priv = netdev_priv(ndev);
>   int ret;
>  
> - ndev->trans_start = jiffies;
> + netif_trans_update(ndev);
>  
>   if (skb_padto(skb, CPSW_MIN_PACKET_SIZE)) {
>   cpsw_err(priv, tx_err, "packet pad failed\n");

for cpsw

Acked-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH net v3 4/5] dt: cpsw: phy-handle, phy_id, and fixed-link are mutually exclusive

[Mugunthan V N]

On Thursday 28 April 2016 07:12 AM, David Rivshin (Allworx) wrote:
> From: David Rivshin <drivs...@allworx.com>
> 
> The phy-handle, phy_id, and fixed-link properties are mutually exclusive,
> and only one need be specified. Make this clear in the binding doc.
> 
> Also mark the phy_id property as deprecated, as phy-handle should be
> used instead.
> 
> Signed-off-by: David Rivshin <drivs...@allworx.com>

Reviewed-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH] net: ethernet: davinci_emac: Fix devioctl while in fixed link

[Mugunthan V N]

On Monday 25 April 2016 11:11 PM, Neil Armstrong wrote:
> When configured in fixed link, the DaVinci emac driver sets the
> priv->phydev to NULL and further ioctl calls to the phy_mii_ioctl()
> causes the kernel to crash.
> 
> Cc: Brian Hutchinson <b.hutch...@gmail.com>
> Fixes: 1bb6aa56bb38 ("net: davinci_emac: Add support for fixed-link PHY")
> Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>

Reviewed-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH net v2 0/3] drivers: net: cpsw: phy-handle fixes

[Mugunthan V N]

On Thursday 21 April 2016 11:20 PM, David Rivshin (Allworx) wrote:
> From: David Rivshin <drivs...@allworx.com>
> 
> The first patch fixes a bug that makes dual_emac mode break if
> either slave uses the phy-handle property in the devicetree.
> 
> The second patch fixes some cosmetic problems with error messages,
> and also makes the binding documentation more explicit.
> 
> The third patch cleans up the fixed-link case to work like
> the now-fixed phy-handle case.
> 
> I have tested on the following hardware configurations:
>  - (EVMSK) dual emac, phy_id property in both slaves
>  - (EVMSK) dual emac, phy-handle property in both slaves
>  - (BeagleBoneBlack) single emac, phy_id property
>  - (custom) single emac, fixed-link subnode
> 
> Nicolas Chauvet reported testing on an HP t410 (dm8148).
> 
> Markus Brunner reported testing v1 on the following [1]:
>  - emac0 with phy_id and emac1 with fixed phy
>  - emac0 with phy-handle and emac1 with fixed phy
>  - emac0 with fixed phy and emac1 with fixed phy
> 
> 

Reviewed-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH v2] MAINTAINERS: net: add entry for TI Ethernet Switch drivers

[Mugunthan V N]

On Thursday 21 April 2016 03:43 PM, Grygorii Strashko wrote:
> Add record for TI Ethernet Switch Driver CPSW/CPDMA/MDIO HW
> (am33/am43/am57/dr7/davinci) to ensure that related patches
> will go through dedicated linux-omap list.
> 
> Also add Mugunthan as maintainer and myself as the reviewer.
> 
> Cc: "David S. Miller" <da...@davemloft.net>
> Cc: Tony Lindgren <t...@atomide.com>
> Cc: Mugunthan V N <mugunthan...@ti.com>
> Cc: Richard Cochran <richardcoch...@gmail.com>
> Signed-off-by: Grygorii Strashko <grygorii.stras...@ti.com>

Acked-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH 0/2] drivers: net: cpsw: fix ale calls and drop host_port field from cpsw_priv

[Mugunthan V N]

On Thursday 07 April 2016 05:46 PM, Grygorii Strashko wrote:
> This clean up series intended to:
>  - fix port_mask parameters in ale calls and drop unnecessary shifts
>  - drop host_port field from struct cpsw_priv
> 
> Nothing critical. Tested on am437x-idk-evm in dual mac and switch modes.
> 
> Grygorii Strashko (2):
>   drivers: net: cpsw: fix port_mask parameters in ale calls
>   drivers: net: cpsw: drop host_port field from struct cpsw_priv
> 
>  drivers/net/ethernet/ti/cpsw.c | 52 
> +-
>  1 file changed, 21 insertions(+), 31 deletions(-)
> 

Reviewed-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: am335x: no multicast reception over VLAN

[Mugunthan V N]

On Friday 01 April 2016 05:39 PM, Grygorii Strashko wrote:
> On 03/31/2016 10:52 AM, Yegor Yefremov wrote:
>> On Thu, Mar 31, 2016 at 8:37 AM, Mugunthan V N <mugunthan...@ti.com> wrote:
>>> On Thursday 31 March 2016 01:17 AM, Peter Korsgaard wrote:
>>>>>>>>> "Mugunthan" == Mugunthan V N <mugunthan...@ti.com> writes:
>>>>
>>>> Hi,
>>>>
>>>>   > You had received these packets as tcpdump will enable promiscuous mode
>>>>   > so that you receive all the packets from the wire.
>>>>
>>>> FYI, you can use the -p option to tcpdump to not put the interface into
>>>> promiscuous mode.
>>>>
>>>
>>> Thanks for the information Peter Korsgaard.
>>>
>>> Yegor, can you provide tcpdump using -p as well in Grygorii commands.
>>
>> Before VLAN configuration:
>>
>> # switch-config -d
>> cpsw hw version 1.12 (0)
>> 0   : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
>> unreg_mcast = 0x0, member_list = 0x3
>> 1   : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
>> no super, port_mask = 0x3
>> 2   : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
>> persistant, port_num = 0x0, Secure
>> 3   : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
>> unreg_mcast = 0x0, member_list = 0x7
>> 4   : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
>> no super, port_mask = 0x3
>> 5   : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
>> unreg_mcast = 0x0, member_list = 0x5
>> 6   : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
>> no super, port_mask = 0x5
>> 7   : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
>> persistant, port_num = 0x0, Secure
>> 8   : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
>> no super, port_mask = 0x5
>>
>> After VLAN configuration:
>>
>> # switch-config -d
>> cpsw hw version 1.12 (0)
>> 0   : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
>> unreg_mcast = 0x0, member_list = 0x3
>> 1   : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
>> no super, port_mask = 0x3
>> 2   : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
>> persistant, port_num = 0x0, Secure
>> 3   : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
>> unreg_mcast = 0x0, member_list = 0x7
>> 4   : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
>> no super, port_mask = 0x3
>> 5   : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
>> unreg_mcast = 0x0, member_list = 0x5
>> 6   : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
>> no super, port_mask = 0x5
>> 7   : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
>> persistant, port_num = 0x0, Secure
>> 8   : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
>> no super, port_mask = 0x5
>> 9   : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5,
>> unreg_mcast = 0x0, member_list = 0x5
>> 10  : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type =
>> persistant, port_num = 0x0
>> 11  : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state =
>> f, no super, port_mask = 0x5
>> 12  : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f,
>> no super, port_mask = 0x5
>>
>> During mulitcast receive:
>>
>> # switch-config -d
>> cpsw hw version 1.12 (0)
>> 0   : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3, unreg_mcast 
>> = 0x0, member_list = 0x3
>> 1   : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f, no 
>> super, port_mask = 0x3
>> 2   : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type = 
>> persistant, port_num = 0x0, Secure
>> 3   : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0, unreg_mcast 
>> = 0x0, member_list = 0x7
> 
> unreg_mcast = 0x0 means unregistered multicast packets will be dropped
> 
>> 4   : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f, no 
>> super, port_mask = 0x3
>> 5   : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5, unreg_mcast 
>> = 0x0, member_list = 0x5
> 
> unreg_mcast = 0x0 
> 
>> 6   : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f, no 
>> super, port_mask = 0x5
>> 7   : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type = 
>> persistant, port_num = 0x0, Secure
>> 8   : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, 

Re: am335x: no multicast reception over VLAN

[Mugunthan V N]

On Thursday 31 March 2016 01:22 PM, Yegor Yefremov wrote:
> On Thu, Mar 31, 2016 at 8:37 AM, Mugunthan V N <mugunthan...@ti.com> wrote:
>> On Thursday 31 March 2016 01:17 AM, Peter Korsgaard wrote:
>>>>>>>> "Mugunthan" == Mugunthan V N <mugunthan...@ti.com> writes:
>>>
>>> Hi,
>>>
>>>  > You had received these packets as tcpdump will enable promiscuous mode
>>>  > so that you receive all the packets from the wire.
>>>
>>> FYI, you can use the -p option to tcpdump to not put the interface into
>>> promiscuous mode.
>>>
>>
>> Thanks for the information Peter Korsgaard.
>>
>> Yegor, can you provide tcpdump using -p as well in Grygorii commands.
> 
> Before VLAN configuration:
> 
> # switch-config -d
> cpsw hw version 1.12 (0)
> 0   : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
> unreg_mcast = 0x0, member_list = 0x3
> 1   : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x3
> 2   : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
> persistant, port_num = 0x0, Secure
> 3   : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
> unreg_mcast = 0x0, member_list = 0x7
> 4   : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x3
> 5   : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
> unreg_mcast = 0x0, member_list = 0x5
> 6   : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x5
> 7   : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0, Secure
> 8   : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x5
> 
> After VLAN configuration:
> 
> # switch-config -d
> cpsw hw version 1.12 (0)
> 0   : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
> unreg_mcast = 0x0, member_list = 0x3
> 1   : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x3
> 2   : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
> persistant, port_num = 0x0, Secure
> 3   : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
> unreg_mcast = 0x0, member_list = 0x7
> 4   : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x3
> 5   : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
> unreg_mcast = 0x0, member_list = 0x5
> 6   : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x5
> 7   : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0, Secure
> 8   : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x5
> 9   : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5,
> unreg_mcast = 0x0, member_list = 0x5
> 10  : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0
> 11  : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state =
> f, no super, port_mask = 0x5
> 12  : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f,
> no super, port_mask = 0x5
> 
> During mulitcast receive:
> 
> # switch-config -d
> cpsw hw version 1.12 (0)
> 0   : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
> unreg_mcast = 0x0, member_list = 0x3
> 1   : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x3
> 2   : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
> persistant, port_num = 0x0, Secure
> 3   : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
> unreg_mcast = 0x0, member_list = 0x7
> 4   : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x3
> 5   : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
> unreg_mcast = 0x0, member_list = 0x5
> 6   : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x5
> 7   : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0, Secure
> 8   : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x5
> 9   : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5,
> unreg_mcast = 0x0, member_list = 0x5
> 10  : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0
> 11  : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state =
> f, no super, port_mask = 0x5
> 12  : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f,
> no super, port_mask = 0x5
> 13  : type: mcast, vid = 2, addr = 01:00:5e:03:1d:47, mcast_state = f,
> no super, port_mask = 0x5
> 14  : type: ucast, vid = 100, addr = 66:22:04:bc:90:26, ucast_type =
> untouched , port_num = 0x2

I could see multicast address 01:00:5e:03:1d:47 is added to ALE table at
index 13, but it is added for VLAN id 2 ie eth1, did you ran the test
for eth1 or eth1.100?

Regards
Mugunthan V N

Re: am335x: no multicast reception over VLAN

[Mugunthan V N]

On Thursday 31 March 2016 01:17 AM, Peter Korsgaard wrote:
>>>>>> "Mugunthan" == Mugunthan V N <mugunthan...@ti.com> writes:
> 
> Hi,
> 
>  > You had received these packets as tcpdump will enable promiscuous mode
>  > so that you receive all the packets from the wire.
> 
> FYI, you can use the -p option to tcpdump to not put the interface into
> promiscuous mode.
> 

Thanks for the information Peter Korsgaard.

Yegor, can you provide tcpdump using -p as well in Grygorii commands.

Regards
Mugunthan V N

Re: am335x: no multicast reception over VLAN

[Mugunthan V N]

On Wednesday 30 March 2016 02:05 PM, Yegor Yefremov wrote:
> On Wed, Mar 30, 2016 at 7:33 AM, Mugunthan V N <mugunthan...@ti.com> wrote:
>> On Tuesday 29 March 2016 06:14 PM, Grygorii Strashko wrote:
>>> On 03/29/2016 03:35 PM, Yegor Yefremov wrote:
>>>> On Tue, Mar 29, 2016 at 1:05 PM, Grygorii Strashko
>>>> <grygorii.stras...@ti.com> wrote:
>>>>> On 03/29/2016 08:21 AM, Yegor Yefremov wrote:
>>>>>> Hi Mugunthan,
>>>>>>
>>>>>> On Tue, Mar 29, 2016 at 6:00 AM, Mugunthan V N <mugunthan...@ti.com> 
>>>>>> wrote:
>>>>>>> Hi Yegor
>>>>>>>
>>>>>>> On Wednesday 16 March 2016 08:35 PM, Yegor Yefremov wrote:
>>>>>>>> I have an am335x based board using CPSW in Dual EMAC mode. Without
>>>>>>>> VLAN IDs I can receive and send multicast packets [1]. When I create
>>>>>>>> VLAN ID:
>>>>>>>>
>>>>>>>> ip link add link eth1 name eth1.100 type vlan id 100
>>>>>>>> ip addr add 192.168.100.2/24 brd 192.168.100.255 dev eth1.100
>>>>>>>> route add -net 224.0.0.0 netmask 224.0.0.0 eth1.100
>>>>>>>>
>>>>>>>> I can successfully send multicast packets, but not receive them. On
>>>>>>>> the other side of the Ethernet cable I've used Pandaboard. Pandaboard
>>>>>>>> could both receive and send multicast packets via VLAN.
>>>>>>>
>>>>>>> Are you trying multicast tx/rx on eth1 or eth1.100?
>>>>>>
>>>>>> I'm trying multicast tx/rx on eth1.100.
>>>>>>
>>>>>> eth1 has no problems.
>>>>>>
>>>>>
>>>>> it'd be nice if will be able to post here output fom commands:
>>>>> # switch-config -d [git://git.ti.com/switch-config/switch-config.git v4.1]
>>>>> # ifconfig -a
>>>>> # tcpdump -e -f -Q in -i eth0
>>>>> # tcpdump -e -f -Q in -i eth0.100
>>>>
>>>> Which kernel/branch do you want me to test?
>>>>
>>>> git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git and ti-rt-linux-4.1.y?
>>>>
>>>> So far I was using vanilla kernel.
>>>
>>> Your branch (but better 4.5 kernels (or 4.4)).
>>> Just when you've done with configuration run cmds 1&2,
>>> and when you run your use-case - run cmds 2&3 on receiver side (grap ~5-10 
>>> packets).
>>> then stop test and run cmd 1 again.
>>>
>>> After all could you provide your console output here, pls.
>>>
>>>
>>
>> To use command 1, you need TI kernel [1] as it won't build with vanilla
>> kernel.
>>
>> [1]: git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git ti-linux-4.1.y
> 
> # uname -a
> Linux buildroot 4.1.18 #1 SMP Wed Mar 30 09:48:37 CEST 2016 armv7l GNU/Linux
> 
> # switch-config -d
> cpsw hw version 1.12 (0)
> 0   : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
> unreg_mcast = 0x1, member_list = 0x3
> 
> 1   : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x3
> 2   : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
> persistant, port_num = 0x0, Secure
> 3   : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
> unreg_mcast = 0x1, member_list = 0x7
> 4   : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x3
> 5   : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
> unreg_mcast = 0x1, member_list = 0x5
> 6   : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x5
> 7   : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0, Secure
> 8   : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x5
> 9   : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5,
> unreg_mcast = 0x1, member_list = 0x5
> 10  : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0
> 11  : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state =
> f, no super, port_mask = 0x5
> 12  : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f,
> no super, port_mask = 0x5
> 13  : type: mcast, vid = 2, addr = 01:00:5e:03:1d:47, mcast_state = f,
> no super, port_mask = 0x5

I don't see multicast entry added to ALE table for 01:00:5e:03:1d:47,
can you run the receive c

Re: am335x: no multicast reception over VLAN

[Mugunthan V N]

On Tuesday 29 March 2016 06:14 PM, Grygorii Strashko wrote:
> On 03/29/2016 03:35 PM, Yegor Yefremov wrote:
>> On Tue, Mar 29, 2016 at 1:05 PM, Grygorii Strashko
>> <grygorii.stras...@ti.com> wrote:
>>> On 03/29/2016 08:21 AM, Yegor Yefremov wrote:
>>>> Hi Mugunthan,
>>>>
>>>> On Tue, Mar 29, 2016 at 6:00 AM, Mugunthan V N <mugunthan...@ti.com> wrote:
>>>>> Hi Yegor
>>>>>
>>>>> On Wednesday 16 March 2016 08:35 PM, Yegor Yefremov wrote:
>>>>>> I have an am335x based board using CPSW in Dual EMAC mode. Without
>>>>>> VLAN IDs I can receive and send multicast packets [1]. When I create
>>>>>> VLAN ID:
>>>>>>
>>>>>> ip link add link eth1 name eth1.100 type vlan id 100
>>>>>> ip addr add 192.168.100.2/24 brd 192.168.100.255 dev eth1.100
>>>>>> route add -net 224.0.0.0 netmask 224.0.0.0 eth1.100
>>>>>>
>>>>>> I can successfully send multicast packets, but not receive them. On
>>>>>> the other side of the Ethernet cable I've used Pandaboard. Pandaboard
>>>>>> could both receive and send multicast packets via VLAN.
>>>>>
>>>>> Are you trying multicast tx/rx on eth1 or eth1.100?
>>>>
>>>> I'm trying multicast tx/rx on eth1.100.
>>>>
>>>> eth1 has no problems.
>>>>
>>>
>>> it'd be nice if will be able to post here output fom commands:
>>> # switch-config -d [git://git.ti.com/switch-config/switch-config.git v4.1]
>>> # ifconfig -a
>>> # tcpdump -e -f -Q in -i eth0
>>> # tcpdump -e -f -Q in -i eth0.100
>>
>> Which kernel/branch do you want me to test?
>>
>> git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git and ti-rt-linux-4.1.y?
>>
>> So far I was using vanilla kernel.
> 
> Your branch (but better 4.5 kernels (or 4.4)). 
> Just when you've done with configuration run cmds 1&2,
> and when you run your use-case - run cmds 2&3 on receiver side (grap ~5-10 
> packets).
> then stop test and run cmd 1 again.
> 
> After all could you provide your console output here, pls.
> 
> 

To use command 1, you need TI kernel [1] as it won't build with vanilla
kernel.

[1]: git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git ti-linux-4.1.y

Regards
Mugunthan V N

Re: am335x: no multicast reception over VLAN

[Mugunthan V N]

Hi Yegor

On Wednesday 16 March 2016 08:35 PM, Yegor Yefremov wrote:
> I have an am335x based board using CPSW in Dual EMAC mode. Without
> VLAN IDs I can receive and send multicast packets [1]. When I create
> VLAN ID:
> 
> ip link add link eth1 name eth1.100 type vlan id 100
> ip addr add 192.168.100.2/24 brd 192.168.100.255 dev eth1.100
> route add -net 224.0.0.0 netmask 224.0.0.0 eth1.100
> 
> I can successfully send multicast packets, but not receive them. On
> the other side of the Ethernet cable I've used Pandaboard. Pandaboard
> could both receive and send multicast packets via VLAN.

Are you trying multicast tx/rx on eth1 or eth1.100?

> 
> This setup was tested with both 3.18.21 and 4.5 kernels.
> 
> Any idea?
> 
> [1] https://pymotw.com/2/socket/multicast.html
> 

--
Regards
Mugunthan V N

Re: [PATCH] drivers: net: cpsw-phy-sel: add dev_warn() for unsupported PHY mode

[Mugunthan V N]

On Saturday 13 February 2016 06:15 AM, David Rivshin (Allworx) wrote:
> From: David Rivshin <drivs...@allworx.com>
> 
> The cpsw-phy-sel driver supports only MII, RMII, and RGMII PHY modes,
> and silently handled any other values as if MII was specified. In a
> case where the PHY mode was incorrectly specified, or a bug elsewhere,
> there would be no indication of a problem. If MII was the correct mode,
> then this will go unnoticed, otherwise the symptom will be a failure
> to transmit/receive data over the RMII/RGMII link.
> 
> Add a dev_warn() to make this condition obvious and provide a
> breadcrumb to follow.
> 
> Cc: Mugunthan V N <mugunthan...@ti.com>
> Signed-off-by: David Rivshin <drivs...@allworx.com>

Acked-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N

Re: [PATCH] net: cpsw: Fix ethernet regression for dm814x

[Mugunthan V N]

On Thursday 19 November 2015 06:57 AM, Tony Lindgren wrote:
> Commit b6745f6e4e63 ("drivers: net: cpsw: davinci_emac: move reading mac
> id to common file") started using of_machine_is_compatible for detecting
> type but missed at dm8148 causing Ethernet to stop working.
> 
> Let's fix the issue by adding handling for dm814x.
> 
> Cc: Mugunthan V N <mugunthan...@ti.com>
> Signed-off-by: Tony Lindgren <t...@atomide.com>

Acked-by: Mugunthnan V N <mugunthan...@ti.com>

Regards
Mugunthan V N
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] drivers: net: cpsw: Add support for fixed-link PHY

[Mugunthan V N]

On Wednesday 04 November 2015 02:39 AM, Markus Brunner wrote:
> Add support for a fixed-link devicetree sub-node in case the the 
> cpsw MAC is directly connected to a non-mdio PHY/device. 
> 
> Signed-off-by: Markus Brunner <systemprogrammierung.brun...@gmail.com>

Looks good to me.

Acked-by: Mugunthan V N <mugunthan...@ti.com>

Regards
Mugunthan V N
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [net-next PATCH] driver: net: cpsw: add no_bd_ram dt parsing

[Mugunthan V N]

On Friday 09 October 2015 03:36 PM, Mugunthan V N wrote:
> cpdma is capable of placing the dma descriptors in ddr using
> dma_alloc_coherent() when the internal bd ram size is not enough.
> To utilize this feature pass the DT parameter "no_bd_ram" and
> increase bd_ram_size and number of rx descriptors.
> 
> Signed-off-by: Mugunthan V N <mugunthan...@ti.com>

Dave

Please drop this patch as it is not working on AM437x platform. Will
send a v2 after fixing it.

Regards
Mugunthan V N

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[net-next PATCH] driver: net: cpsw: add no_bd_ram dt parsing

[Mugunthan V N]

cpdma is capable of placing the dma descriptors in ddr using
dma_alloc_coherent() when the internal bd ram size is not enough.
To utilize this feature pass the DT parameter "no_bd_ram" and
increase bd_ram_size and number of rx descriptors.

Signed-off-by: Mugunthan V N <mugunthan...@ti.com>
---
 drivers/net/ethernet/ti/cpsw.c | 4 
 drivers/net/ethernet/ti/cpsw.h | 1 +
 2 files changed, 5 insertions(+)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 8fc90f1..cf1a625 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1987,6 +1987,8 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
}
data->ale_entries = prop;
 
+   data->no_bd_ram = of_property_read_bool(node, "no_bd_ram");
+
if (of_property_read_u32(node, "bd_ram_size", )) {
dev_err(>dev, "Missing bd_ram_size property in the 
DT.\n");
return -EINVAL;
@@ -2358,6 +2360,8 @@ static int cpsw_probe(struct platform_device *pdev)
dma_params.desc_mem_size= data->bd_ram_size;
dma_params.desc_align   = 16;
dma_params.has_ext_regs = true;
+   if (data->no_bd_ram)
+   dma_params.desc_mem_phys = 0;
dma_params.desc_hw_addr = dma_params.desc_mem_phys;
 
priv->dma = cpdma_ctlr_create(_params);
diff --git a/drivers/net/ethernet/ti/cpsw.h b/drivers/net/ethernet/ti/cpsw.h
index ca90efa..b654ac2 100644
--- a/drivers/net/ethernet/ti/cpsw.h
+++ b/drivers/net/ethernet/ti/cpsw.h
@@ -33,6 +33,7 @@ struct cpsw_platform_data {
u32 cpts_clock_mult;  /* convert input clock ticks to nanoseconds */
u32 cpts_clock_shift; /* convert input clock ticks to nanoseconds */
u32 ale_entries;/* ale table size */
+   boolno_bd_ram;  /* set if cpsw bd ram should not be used */
u32 bd_ram_size;  /*buffer descriptor ram size */
u32 rx_descs;   /* Number of Rx Descriptios */
u32 mac_control;/* Mac control register */
-- 
2.6.1.133.gf5b6079

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[net-next PATCH 1/4] drivers: net: cpsw: davinci_emac: move reading mac id to common file

[Mugunthan V N]

Moving mac address reading from ethernet driver to common
file for better maintenance and for code reusable.

Signed-off-by: Mugunthan V N <mugunthan...@ti.com>
---
 drivers/net/ethernet/ti/cpsw-common.c  | 58 --
 drivers/net/ethernet/ti/cpsw.c | 11 +++
 drivers/net/ethernet/ti/cpsw.h |  3 +-
 drivers/net/ethernet/ti/davinci_emac.c | 44 ++
 4 files changed, 57 insertions(+), 59 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw-common.c 
b/drivers/net/ethernet/ti/cpsw-common.c
index f595094..c70417c 100644
--- a/drivers/net/ethernet/ti/cpsw-common.c
+++ b/drivers/net/ethernet/ti/cpsw-common.c
@@ -19,11 +19,38 @@
 
 #include "cpsw.h"
 
-#define AM33XX_CTRL_MAC_LO_REG(offset, id) ((offset) + 0x8 * (id))
-#define AM33XX_CTRL_MAC_HI_REG(offset, id) ((offset) + 0x8 * (id) + 0x4)
+#define CTRL_MAC_LO_REG(offset, id) ((offset) + 0x8 * (id))
+#define CTRL_MAC_HI_REG(offset, id) ((offset) + 0x8 * (id) + 0x4)
 
-int cpsw_am33xx_cm_get_macid(struct device *dev, u16 offset, int slave,
-u8 *mac_addr)
+static int davinci_emac_3517_get_macid(struct device *dev, u16 offset,
+  int slave, u8 *mac_addr)
+{
+   u32 macid_lsb;
+   u32 macid_msb;
+   struct regmap *syscon;
+
+   syscon = syscon_regmap_lookup_by_phandle(dev->of_node, "syscon");
+   if (IS_ERR(syscon)) {
+   if (PTR_ERR(syscon) == -ENODEV)
+   return 0;
+   return PTR_ERR(syscon);
+   }
+
+   regmap_read(syscon, CTRL_MAC_LO_REG(offset, slave), _lsb);
+   regmap_read(syscon, CTRL_MAC_HI_REG(offset, slave), _msb);
+
+   mac_addr[0] = (macid_msb >> 16) & 0xff;
+   mac_addr[1] = (macid_msb >> 8)  & 0xff;
+   mac_addr[2] = macid_msb & 0xff;
+   mac_addr[3] = (macid_lsb >> 16) & 0xff;
+   mac_addr[4] = (macid_lsb >> 8)  & 0xff;
+   mac_addr[5] = macid_lsb & 0xff;
+
+   return 0;
+}
+
+static int cpsw_am33xx_cm_get_macid(struct device *dev, u16 offset, int slave,
+   u8 *mac_addr)
 {
u32 macid_lo;
u32 macid_hi;
@@ -36,10 +63,8 @@ int cpsw_am33xx_cm_get_macid(struct device *dev, u16 offset, 
int slave,
return PTR_ERR(syscon);
}
 
-   regmap_read(syscon, AM33XX_CTRL_MAC_LO_REG(offset, slave),
-   _lo);
-   regmap_read(syscon, AM33XX_CTRL_MAC_HI_REG(offset, slave),
-   _hi);
+   regmap_read(syscon, CTRL_MAC_LO_REG(offset, slave), _lo);
+   regmap_read(syscon, CTRL_MAC_HI_REG(offset, slave), _hi);
 
mac_addr[5] = (macid_lo >> 8) & 0xff;
mac_addr[4] = macid_lo & 0xff;
@@ -50,6 +75,21 @@ int cpsw_am33xx_cm_get_macid(struct device *dev, u16 offset, 
int slave,
 
return 0;
 }
-EXPORT_SYMBOL_GPL(cpsw_am33xx_cm_get_macid);
+
+int ti_cm_get_macid(struct device *dev, int slave, u8 *mac_addr)
+{
+   if (of_machine_is_compatible("ti,am33xx"))
+   return cpsw_am33xx_cm_get_macid(dev, 0x630, slave, mac_addr);
+
+   if (of_device_is_compatible(dev->of_node, "ti,am3517-emac"))
+   return davinci_emac_3517_get_macid(dev, 0x110, slave, mac_addr);
+
+   if (of_device_is_compatible(dev->of_node, "ti,dm816-emac"))
+   return cpsw_am33xx_cm_get_macid(dev, 0x30, slave, mac_addr);
+
+   dev_err(dev, "incompatible machine/device type for reading mac 
address\n");
+   return -ENOENT;
+}
+EXPORT_SYMBOL_GPL(ti_cm_get_macid);
 
 MODULE_LICENSE("GPL");
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index c670317..75584cc 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -2058,13 +2058,10 @@ no_phy_slave:
if (mac_addr) {
memcpy(slave_data->mac_addr, mac_addr, ETH_ALEN);
} else {
-   if (of_machine_is_compatible("ti,am33xx")) {
-   ret = cpsw_am33xx_cm_get_macid(>dev,
-   0x630, i,
-   slave_data->mac_addr);
-   if (ret)
-   return ret;
-   }
+   ret = ti_cm_get_macid(>dev, i,
+ slave_data->mac_addr);
+   if (ret)
+   return ret;
}
if (data->dual_emac) {
if (of_property_read_u32(slave_node, 
"dual_emac_res_vlan",
diff --git a/drivers/net/ethernet/ti/cpsw.h b/drivers/net/ethernet/ti/cpsw.h
index ca90efa..442a703 100644
--- a/drivers/net/ethernet/ti/cpsw.h
+++ b/driv

[net-next PATCH 2/4] drivers: net: cpsw-common: add support for reading mac address for dra7 and am437x platforms

[Mugunthan V N]

Adding support for reading mac address using syscon driver for
dra7 and am437x platforms

Signed-off-by: Mugunthan V N <mugunthan...@ti.com>
---
 drivers/net/ethernet/ti/cpsw-common.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/ethernet/ti/cpsw-common.c 
b/drivers/net/ethernet/ti/cpsw-common.c
index c70417c..c08be62 100644
--- a/drivers/net/ethernet/ti/cpsw-common.c
+++ b/drivers/net/ethernet/ti/cpsw-common.c
@@ -87,6 +87,12 @@ int ti_cm_get_macid(struct device *dev, int slave, u8 
*mac_addr)
if (of_device_is_compatible(dev->of_node, "ti,dm816-emac"))
return cpsw_am33xx_cm_get_macid(dev, 0x30, slave, mac_addr);
 
+   if (of_machine_is_compatible("ti,am4372"))
+   return cpsw_am33xx_cm_get_macid(dev, 0x630, slave, mac_addr);
+
+   if (of_machine_is_compatible("ti,dra7"))
+   return davinci_emac_3517_get_macid(dev, 0x514, slave, mac_addr);
+
dev_err(dev, "incompatible machine/device type for reading mac 
address\n");
return -ENOENT;
 }
-- 
2.6.0.rc2.10.gf4d9753

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[net-next PATCH 3/4] arm: dts: dra7: add syscon phandle to cpsw node

[Mugunthan V N]

There are 2 MACIDs stored in the control module of the dra7.
These are read by the cpsw driver if no valid MACID was found
in the devicetree.

Signed-off-by: Mugunthan V N <mugunthan...@ti.com>
---
 arch/arm/boot/dts/dra7.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 5d65db9..76c739d 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1447,6 +1447,7 @@
 ,
 ;
ranges;
+   syscon = <_conf>;
status = "disabled";
 
davinci_mdio: mdio@48485000 {
-- 
2.6.0.rc2.10.gf4d9753

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[net-next PATCH 4/4] arm: dts: am4372: add syscon phandle to cpsw node

[Mugunthan V N]

There are 2 MACIDs stored in the control module of the am4372.
These are read by the cpsw driver if no valid MACID was found
in the devicetree.

Signed-off-by: Mugunthan V N <mugunthan...@ti.com>
---
 arch/arm/boot/dts/am4372.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 0447c04a..d83ff9c 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -591,6 +591,7 @@
cpts_clock_mult = <0x8000>;
cpts_clock_shift = <29>;
ranges;
+   syscon = <_conf>;
 
davinci_mdio: mdio@4a101000 {
compatible = "ti,am4372-mdio","ti,davinci_mdio";
-- 
2.6.0.rc2.10.gf4d9753

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[net-next PATCH 0/4] Add support for reading macid when DT macid not found

[Mugunthan V N]

Did a boot test on dra7-evm [1] and am437x-gp-evm [2].
Pushed a branch [3] for others to test the patch.

[1]: http://pastebin.ubuntu.com/12513420/
[2]: http://pastebin.ubuntu.com/12513428/
[3]: git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git 
cpsw-macid-read-support

Mugunthan V N (4):
  drivers: net: cpsw: davinci_emac: move reading mac id to common file
  drivers: net: cpsw-common: add support for reading mac address for
dra7 and am437x platforms
  arm: dts: dra7: add syscon phandle to cpsw node
  arm: dts: am4372: add syscon phandle to cpsw node

 arch/arm/boot/dts/am4372.dtsi  |  1 +
 arch/arm/boot/dts/dra7.dtsi|  1 +
 drivers/net/ethernet/ti/cpsw-common.c  | 64 +-
 drivers/net/ethernet/ti/cpsw.c | 11 +++---
 drivers/net/ethernet/ti/cpsw.h |  3 +-
 drivers/net/ethernet/ti/davinci_emac.c | 44 ++-
 6 files changed, 65 insertions(+), 59 deletions(-)

-- 
2.6.0.rc2.10.gf4d9753

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[net-next PATCH v3] drivers: net: cpsw: Add support to drive gpios for ethernet to be functional

[Mugunthan V N]

In DRA72x EVM, by default slave 1 is connected to the onboard
phy, but slave 2 pins are also muxed with video input module
which is controlled by pcf857x gpio and currently to select slave
0 to connect to phy gpio hogging is used, but with
omap2plus_defconfig the pcf857x gpio is built as module. So when
using NFS on DRA72x EVM, board doesn't boot as gpio hogging do
not set proper gpio state to connect slave 0 to phy as it is
built as module and you do not see any errors for not setting
gpio and just mentions dhcp reply not got.

To solve this issue, introducing "mode-gpios" in DT when gpio
based muxing is required. This will throw a warning when gpio
get fails and returns probe defer. When gpio-pcf857x module is
installed, cpsw probes again and ethernet becomes functional.
Verified this on DRA72x with pcf as module and ramdisk.

Signed-off-by: Mugunthan V N <mugunthan...@ti.com>
---

Changes from v2:
* Used mode-gpios, so that the driver is generic enough to handle
  multiple gpios

This patch is tested on DRA72x, Logs [1] and pushed a branch [2]

[1]: http://pastebin.ubuntu.com/12306224/
[2]: git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git 
cpsw-gpio-optional-v3

---
 Documentation/devicetree/bindings/net/cpsw.txt | 7 +++
 drivers/net/ethernet/ti/cpsw.c | 9 +
 2 files changed, 16 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
b/Documentation/devicetree/bindings/net/cpsw.txt
index a9df21a..676ecf6 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -30,6 +30,13 @@ Optional properties:
 - dual_emac: Specifies Switch to act as Dual EMAC
 - syscon   : Phandle to the system control device node, which is
  the control module device of the am33x
+- mode-gpios   : Should be added if one/multiple gpio lines are
+ required to be driven so that cpsw data lines
+ can be connected to the phy via selective mux.
+ For example in dra72x-evm, pcf gpio has to be
+ driven low so that cpsw slave 0 and phy data
+ lines are connected via mux.
+
 
 Slave Properties:
 Required properties:
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 8fc90f1..c670317 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2207,6 +2208,7 @@ static int cpsw_probe(struct platform_device *pdev)
void __iomem*ss_regs;
struct resource *res, *ss_res;
const struct of_device_id   *of_id;
+   struct gpio_descs   *mode;
u32 slave_offset, sliver_offset, slave_size;
int ret = 0, i;
int irq;
@@ -2232,6 +2234,13 @@ static int cpsw_probe(struct platform_device *pdev)
goto clean_ndev_ret;
}
 
+   mode = devm_gpiod_get_array_optional(>dev, "mode", GPIOD_OUT_LOW);
+   if (IS_ERR(mode)) {
+   ret = PTR_ERR(mode);
+   dev_err(>dev, "gpio request failed, ret %d\n", ret);
+   goto clean_ndev_ret;
+   }
+
/*
 * This may be required here for child devices.
 */
-- 
2.6.0.rc0.24.gec371ff

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[net-next PATCH v2] drivers: net: cpsw: Add support to make gpio drive which slave connected to phy

[Mugunthan V N]

In DRA72x EVM, by default slave 1 is connected to the onboard
phy, but slave 2 pins are also muxed with video input module
which is controlled by pcf857x gpio and currently to select slave
0 to connect to phy gpio hogging is used, but with
omap2plus_defconfig the pcf857x gpio is built as module. So when
using NFS on DRA72x EVM, board doesn't boot as gpio hogging do
not set proper gpio state to connect slave 0 to phy as it is
built as module and you do not see any errors for not setting
gpio and just mentions dhcp reply not got.

To solve this issue, introducing "mode-gpio" in DT when gpio
based muxing is required. This will throw a warning when gpio
get fails and returns probe defer. When gpio-pcf857x module is
installed, cpsw probes again and ethernet becomes functional.
Verified this on DRA72x with pcf as module and ramdisk.

Signed-off-by: Mugunthan V N <mugunthan...@ti.com>
---

Changes from initial version:
* Updated the gpio dt naming to be more generic.

This patch is texted on DRA72x, Logs [1] and pushed a branch [2]

[1]: http://pastebin.ubuntu.com/12260767/
[2]: git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git 
cpsw-gpio-optional-v2

---
 Documentation/devicetree/bindings/net/cpsw.txt | 7 +++
 drivers/net/ethernet/ti/cpsw.c | 9 +
 2 files changed, 16 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
b/Documentation/devicetree/bindings/net/cpsw.txt
index 33fe846..dfe3e0b 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -26,6 +26,13 @@ Optional properties:
 - dual_emac: Specifies Switch to act as Dual EMAC
 - syscon   : Phandle to the system control device node, which is
  the control module device of the am33x
+- mode-gpio: Should be added if a gpio line is required to
+ be driven so that cpsw data lines can be
+ connected to the phy via selective mux. For
+ example in dra72x-evm, pcf gpio has to be
+ driven low so that cpsw slave 0 and phy
+ data lines are connected via mux.
+
 
 Slave Properties:
 Required properties:
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 8fc90f1..90ae3f9 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2207,6 +2208,7 @@ static int cpsw_probe(struct platform_device *pdev)
void __iomem*ss_regs;
struct resource *res, *ss_res;
const struct of_device_id   *of_id;
+   struct gpio_desc*mode;
u32 slave_offset, sliver_offset, slave_size;
int ret = 0, i;
int irq;
@@ -2232,6 +2234,13 @@ static int cpsw_probe(struct platform_device *pdev)
goto clean_ndev_ret;
}
 
+   mode = devm_gpiod_get_optional(>dev, "mode", GPIOD_OUT_LOW);
+   if (IS_ERR(mode)) {
+   ret = PTR_ERR(mode);
+   dev_err(>dev, "gpio request failed, ret %d\n", ret);
+   goto clean_ndev_ret;
+   }
+
/*
 * This may be required here for child devices.
 */
-- 
2.5.1.522.g7aa67f6

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [net-next PATCH] drivers: net: cpsw: Add support to make gpio drive which slave connected to phy

[Mugunthan V N]

On Tuesday 01 September 2015 09:06 PM, Tony Lindgren wrote:
> * Mugunthan V N <mugunthan...@ti.com> [150901 04:28]:
>> --- a/Documentation/devicetree/bindings/net/cpsw.txt
>> +++ b/Documentation/devicetree/bindings/net/cpsw.txt
>> @@ -26,6 +26,9 @@ Optional properties:
>>  - dual_emac : Specifies Switch to act as Dual EMAC
>>  - syscon: Phandle to the system control device node, which is
>>the control module device of the am33x
>> +- select-slave-gpio : Should be added if a gpio line is required to
>> +  select which slave is connected to phy
>> +
> 
> How about using something more generic here for the name?
> Something like mode-gpios?
> 

Yeah, agreed, for DRA72x it is used for connecting to phy, if some other
board wanted to drive a GPIO for something else we can use this node to
drive GPIO.

Will submit a v2 with name change

Regards
Mugunthan V N

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[net-next PATCH] drivers: net: cpsw: Add support to make gpio drive which slave connected to phy

[Mugunthan V N]

In DRA72x EVM, by default slave 1 is connected to the onboard
phy, but slave 2 pins are also muxed with video input module
which is controlled by pcf857x gpio and currently to select slave
0 to connect to phy gpio hogging is used, but with
omap2plus_defconfig the pcf857x gpio is built as module. So when
using NFS on DRA72x EVM, board doesn't boot as gpio hogging do
not set proper gpio state to connect slave 0 to phy as it is
built as module and you do not see any errors for not setting
gpio and just mentions dhcp reply not got.

To solve this issue, introducing "select-slave-gpio" in DT when
gpio based muxing is required. This will through a warning when
vgpio get fails and returns probe defer. When gpio-pcf857x module
is installed, cpsw probes again and ethernet becomes functional.
Verified this on DRA72x with pcf as module and ramdisk [1]

Signed-off-by: Mugunthan V N <mugunthan...@ti.com>
---

This patch is texted on DRA72x, Logs [1] and pushed a branch [2]

[1]: http://pastebin.ubuntu.com/12244652/
[2]: git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git cpsw-gpio-optional

---
 Documentation/devicetree/bindings/net/cpsw.txt |  3 +++
 drivers/net/ethernet/ti/cpsw.c | 10 ++
 2 files changed, 13 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
b/Documentation/devicetree/bindings/net/cpsw.txt
index 33fe846..cb693aa 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -26,6 +26,9 @@ Optional properties:
 - dual_emac: Specifies Switch to act as Dual EMAC
 - syscon   : Phandle to the system control device node, which is
  the control module device of the am33x
+- select-slave-gpio: Should be added if a gpio line is required to
+ select which slave is connected to phy
+
 
 Slave Properties:
 Required properties:
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 8fc90f1..ce965ad 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2207,6 +2208,7 @@ static int cpsw_probe(struct platform_device *pdev)
void __iomem*ss_regs;
struct resource *res, *ss_res;
const struct of_device_id   *of_id;
+   struct gpio_desc*select_slave;
u32 slave_offset, sliver_offset, slave_size;
int ret = 0, i;
int irq;
@@ -2232,6 +2234,14 @@ static int cpsw_probe(struct platform_device *pdev)
goto clean_ndev_ret;
}
 
+   select_slave = devm_gpiod_get_optional(>dev, "select-slave",
+  GPIOD_OUT_LOW);
+   if (IS_ERR(select_slave)) {
+   ret = PTR_ERR(select_slave);
+   dev_err(>dev, "gpio request failed, ret %d\n", ret);
+   goto clean_ndev_ret;
+   }
+
/*
 * This may be required here for child devices.
 */
-- 
2.5.0.474.g3a9835b

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [net-next PATCH 1/3] drivers: net: cpsw: add am335x errata workarround for interrutps

[Mugunthan V N]

On Monday 24 August 2015 03:34 PM, Sekhar Nori wrote:
 Hi Mugunthan,
 
 On Wednesday 12 August 2015 03:22 PM, Mugunthan V N wrote:
  +static const struct of_device_id cpsw_of_mtable[] = {
  +  { .compatible = ti,cpsw, .data = cpsw_devtype[CPSW], },
  +  { .compatible = ti,am335x-cpsw, .data = cpsw_devtype[AM335X_CPSW], },
  +  { .compatible = ti,am4372-cpsw, .data = cpsw_devtype[AM4372_CPSW], },
  +  { .compatible = ti,dra7-cpsw, .data = cpsw_devtype[DRA7_CPSW], },
 I do not see documentation added for these compatibles. Since the series
 is already applied, can you send additional patches adding documentation?

Will submit a patch ASAP

Regards
Mugunthan V N
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dhcp nfsroot booting failure on bb white

[Mugunthan V N]

On Wednesday 12 August 2015 02:06 PM, Alexander Aring wrote:
 Hi,
 
 my beaglebone (white edition) fails to boot via dhcp and nfsroot. The
 last messages which I see are:
 
 ...
 [2.970593] Sending DHCP requests .
 [5.996876] cpsw 4a10.ethernet eth0: Link is Up - 100Mbps/Full -
 flow control off
 
 
 then it stucks forever. I reverted the recently cpsw patches:
 
 32a7432c0fb8b0117961bdc7ab256667d039de16 (drivers: net: cpsw: add
 separate napi for tx)
 
 d354eb85d61803e07831b68d1985cd9cfe2f8b59 (drivers: net: cpsw:
 dual_emac: simplify napi usage)
 
 870915feabdc3af5f0ebb72d1fcf96bff01837b0 (drivers: net: cpsw: remove
 disable_irq/enable_irq as irq can be masked from cpsw itself)
 
 
 I did a test after each revert, I finally figured out that after reverting
 the last patch:
 
 870915feabdc3af5f0ebb72d1fcf96bff01837b0 (drivers: net: cpsw: remove
 disable_irq/enable_irq as irq can be masked from cpsw itself)
 
 it worked again to boot via dhcp nfsroot.
 
 
 My bootparameters are:
 
 commandline: console=ttyO0,115200n8 console=ttyO0,115200n8 ip=dhcp
 root=/dev/nfs nfsroot=$IP:$NFS_EXPORT,v3,tcp
 

I am already looking into it. Will submit a fix soon. The issue is with
AM335x PG1.0 as there is a errata in CPSW interrupts, PG2.x and other
SoCs are working fine.

Regards
Mugunthan V N

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[net-next PATCH] net: ipv4: increase dhcp inter device timeout

[Mugunthan V N]

When a system has multiple ethernet devices and during DHCP
request (for using NFS), the system waits only for HZ/2 which is
500mS before switching to another interface for DHCP.

There are some routers (Ex: Trendnet routers) which responds to
DHCP request at about 560mS. When the system has only one
ethernet interface there is no issue as the timeout is 2S and the
dev xid doesn't changes and only retries.

But when the system has multiple Ethernet like DRA74x with CPSW
in dual EMAC mode, the DHCP response is dropped as the dev xid
changes while shifting to the next device. So changing inter
device timeout to HZ (which is 1S).

Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
 net/ipv4/ipconfig.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 8e7328c..ed4ef09 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -94,7 +94,7 @@
 /* Define the timeout for waiting for a DHCP/BOOTP/RARP reply */
 #define CONF_OPEN_RETRIES  2   /* (Re)open devices twice */
 #define CONF_SEND_RETRIES  6   /* Send six requests per open */
-#define CONF_INTER_TIMEOUT (HZ/2)  /* Inter-device timeout: 1/2 second */
+#define CONF_INTER_TIMEOUT (HZ)/* Inter-device timeout: 1 second */
 #define CONF_BASE_TIMEOUT  (HZ*2)  /* Initial timeout: 2 seconds */
 #define CONF_TIMEOUT_RANDOM(HZ)/* Maximum amount of randomization */
 #define CONF_TIMEOUT_MULT  *7/4/* Rate of timeout growth */
-- 
2.5.0.234.gefc8a62

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[net-next PATCH 0/3] Add AM335x PG1.0 CPSW errata workaround

[Mugunthan V N]

With commit 870915feabdc (drivers: net: cpsw: remove
disable_irq/enable_irq as irq can be masked from cpsw itself),
CPSW on AM335x beagle bone white is broken as there is a errata
for AM335x PG1.0. This patch series implements the workaround by
disabling the interrupts from ARM IRQ controller for AM335x SoC
in addition to the masking of interrupts in CPSW.

Mugunthan V N (3):
  drivers: net: cpsw: add am335x errata workarround for interrutps
  ARM: dts: dra7: update cpsw compatible
  ARM: dts: am33xx: update cpsw compatible

 arch/arm/boot/dts/am33xx.dtsi  |  2 +-
 arch/arm/boot/dts/dra7.dtsi|  2 +-
 drivers/net/ethernet/ti/cpsw.c | 83 +++---
 3 files changed, 79 insertions(+), 8 deletions(-)

-- 
2.5.0.234.gefc8a62

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[net-next PATCH 2/3] ARM: dts: dra7: update cpsw compatible

[Mugunthan V N]

CPSW driver has been updated with compatibles for enabling errata
workarounds. So updating cpsw compatibles.

Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
 arch/arm/boot/dts/dra7.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 8f1e25b..b4fdd10 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1398,7 +1398,7 @@
};
 
mac: ethernet@4a10 {
-   compatible = ti,cpsw;
+   compatible = ti,dra7-cpsw,ti,cpsw;
ti,hwmods = gmac;
clocks = dpll_gmac_ck, gmac_gmii_ref_clk_div;
clock-names = fck, cpts;
-- 
2.5.0.234.gefc8a62

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[net-next PATCH 3/3] ARM: dts: am33xx: update cpsw compatible

[Mugunthan V N]

CPSW driver has been updated with compatibles for enabling errata
workarounds. So updating cpsw compatibles.

Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
 arch/arm/boot/dts/am33xx.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 21fcc44..8b59c86 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -700,7 +700,7 @@
};
 
mac: ethernet@4a10 {
-   compatible = ti,cpsw;
+   compatible = ti,am335x-cpsw,ti,cpsw;
ti,hwmods = cpgmac0;
clocks = cpsw_125mhz_gclk, cpsw_cpts_rft_clk;
clock-names = fck, cpts;
-- 
2.5.0.234.gefc8a62

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[net-next PATCH 1/3] drivers: net: cpsw: add am335x errata workarround for interrutps

[Mugunthan V N]

As per Am335x Errata [1] Advisory 1.0.9, The CPSW C0_TX_PEND and
C0_RX_PEND interrupt outputs provide a single transmit interrupt
that combines transmit channel interrupts TXPEND[7:0] and a
single receive interrupt that combines receive channel interrupts
RXPEND[7:0]. The TXPEND[0] and RXPEND[0] interrupt outputs are
connected to the ARM Cortex-A8 interrupt controller (INTC) rather
than the C0_TX_PEND and C0_RX_PEND interrupt outputs. So even
though CPSW interrupt is cleared by writing appropriate values to
EOI register the interrupt is not cleared in IRQ controller. So
interrupt is still pending and CPU is struck in ISR, the
workaround is to disable the interrupts in ARM irq controller.

[1] http://www.ti.com/lit/er/sprz360f/sprz360f.pdf

Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
 drivers/net/ethernet/ti/cpsw.c | 83 +++---
 1 file changed, 77 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 3b81b39..8fc90f1 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -387,6 +387,9 @@ struct cpsw_priv {
struct cpsw_ale *ale;
boolrx_pause;
booltx_pause;
+   boolquirk_irq;
+   boolrx_irq_disabled;
+   booltx_irq_disabled;
/* snapshot of IRQ numbers */
u32 irqs_table[4];
u32 num_irqs;
@@ -755,6 +758,11 @@ static irqreturn_t cpsw_tx_interrupt(int irq, void *dev_id)
writel(0, priv-wr_regs-tx_en);
cpdma_ctlr_eoi(priv-dma, CPDMA_EOI_TX);
 
+   if (priv-quirk_irq) {
+   disable_irq_nosync(priv-irqs_table[1]);
+   priv-tx_irq_disabled = true;
+   }
+
napi_schedule(priv-napi_tx);
return IRQ_HANDLED;
 }
@@ -766,6 +774,11 @@ static irqreturn_t cpsw_rx_interrupt(int irq, void *dev_id)
cpdma_ctlr_eoi(priv-dma, CPDMA_EOI_RX);
writel(0, priv-wr_regs-rx_en);
 
+   if (priv-quirk_irq) {
+   disable_irq_nosync(priv-irqs_table[0]);
+   priv-rx_irq_disabled = true;
+   }
+
napi_schedule(priv-napi_rx);
return IRQ_HANDLED;
 }
@@ -779,6 +792,10 @@ static int cpsw_tx_poll(struct napi_struct *napi_tx, int 
budget)
if (num_tx  budget) {
napi_complete(napi_tx);
writel(0xff, priv-wr_regs-tx_en);
+   if (priv-quirk_irq  priv-tx_irq_disabled) {
+   priv-tx_irq_disabled = false;
+   enable_irq(priv-irqs_table[1]);
+   }
}
 
if (num_tx)
@@ -796,6 +813,10 @@ static int cpsw_rx_poll(struct napi_struct *napi_rx, int 
budget)
if (num_rx  budget) {
napi_complete(napi_rx);
writel(0xff, priv-wr_regs-rx_en);
+   if (priv-quirk_irq  priv-rx_irq_disabled) {
+   priv-rx_irq_disabled = false;
+   enable_irq(priv-irqs_table[0]);
+   }
}
 
if (num_rx)
@@ -1267,6 +1288,16 @@ static int cpsw_ndo_open(struct net_device *ndev)
napi_enable(priv_sl0-napi_rx);
napi_enable(priv_sl0-napi_tx);
 
+   if (priv_sl0-tx_irq_disabled) {
+   priv_sl0-tx_irq_disabled = false;
+   enable_irq(priv-irqs_table[1]);
+   }
+
+   if (priv_sl0-rx_irq_disabled) {
+   priv_sl0-rx_irq_disabled = false;
+   enable_irq(priv-irqs_table[0]);
+   }
+
if (WARN_ON(!priv-data.rx_descs))
priv-data.rx_descs = 128;
 
@@ -2128,6 +2159,44 @@ static int cpsw_probe_dual_emac(struct platform_device 
*pdev,
return ret;
 }
 
+#define CPSW_QUIRK_IRQ BIT(0)
+
+static struct platform_device_id cpsw_devtype[] = {
+   {
+   /* keep it for existing comaptibles */
+   .name = cpsw,
+   .driver_data = CPSW_QUIRK_IRQ,
+   }, {
+   .name = am335x-cpsw,
+   .driver_data = CPSW_QUIRK_IRQ,
+   }, {
+   .name = am4372-cpsw,
+   .driver_data = 0,
+   }, {
+   .name = dra7-cpsw,
+   .driver_data = 0,
+   }, {
+   /* sentinel */
+   }
+};
+MODULE_DEVICE_TABLE(platform, cpsw_devtype);
+
+enum ti_cpsw_type {
+   CPSW = 0,
+   AM335X_CPSW,
+   AM4372_CPSW,
+   DRA7_CPSW,
+};
+
+static const struct of_device_id cpsw_of_mtable[] = {
+   { .compatible = ti,cpsw, .data = cpsw_devtype[CPSW], },
+   { .compatible = ti,am335x-cpsw, .data = cpsw_devtype[AM335X_CPSW], },
+   { .compatible = ti,am4372-cpsw, .data = cpsw_devtype[AM4372_CPSW], },
+   { .compatible = ti,dra7-cpsw, .data = cpsw_devtype[DRA7_CPSW], },
+   { /* sentinel

Re: [RFC PATCH] net: ipv4: increase dhcp inter device timeout

[Mugunthan V N]

On Friday 07 August 2015 12:45 PM, YOSHIFUJI Hideaki wrote:
 diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
  index 8e7328c..bdb8cb5 100644
  --- a/net/ipv4/ipconfig.c
  +++ b/net/ipv4/ipconfig.c
  @@ -94,7 +94,7 @@
   /* Define the timeout for waiting for a DHCP/BOOTP/RARP reply */
   #define CONF_OPEN_RETRIES 2   /* (Re)open devices twice */
   #define CONF_SEND_RETRIES 6   /* Send six requests per open */
  -#define CONF_INTER_TIMEOUT(HZ/2)  /* Inter-device timeout: 1/2 
  second */
  +#define CONF_INTER_TIMEOUT(HZ)/* Inter-device timeout: 1/2 
  second */
 You should update comment as well at least.

Will update in next version.

Regards
Mugunthan V N
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH] net: ipv4: increase dhcp inter device timeout

[Mugunthan V N]

When a system has multiple ethernet devices and during DHCP
request (for using NFS), the system waits only for HZ/2 which is
500mS before switching to another interface for DHCP.

There are some routers (Ex: Trendnet routers) which responds to
DHCP request at about 560mS. When the system has only one
ethernet interface there is no issue as the timeout is 2S and the
dev xid doesn't change and only retries.

But when the system has multiple Ethernet like DRA74x with CPSW
in dual EMAC mode, the DHCP response is dropped as the dev xid
changes while shifting to the next device. So changing inter
device timeout to HZ (which is 1S).

Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
 net/ipv4/ipconfig.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 8e7328c..bdb8cb5 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -94,7 +94,7 @@
 /* Define the timeout for waiting for a DHCP/BOOTP/RARP reply */
 #define CONF_OPEN_RETRIES  2   /* (Re)open devices twice */
 #define CONF_SEND_RETRIES  6   /* Send six requests per open */
-#define CONF_INTER_TIMEOUT (HZ/2)  /* Inter-device timeout: 1/2 second */
+#define CONF_INTER_TIMEOUT (HZ)/* Inter-device timeout: 1/2 second */
 #define CONF_BASE_TIMEOUT  (HZ*2)  /* Initial timeout: 2 seconds */
 #define CONF_TIMEOUT_RANDOM(HZ)/* Maximum amount of randomization */
 #define CONF_TIMEOUT_MULT  *7/4/* Rate of timeout growth */
-- 
2.5.0.234.gefc8a62

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[net-next PATCH v2 3/3] drivers: net: cpsw: add separate napi for tx

[Mugunthan V N]

Instead of processing tx events in isr adding separate napi for
tx which improves performance by ~180Mbps with
omap2plus_defconfig on DRA74x platform. Also cleaning up rx napis
by renaming to napi_rx for better understanding the code.

Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
 drivers/net/ethernet/ti/cpsw.c | 44 +-
 1 file changed, 31 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 1d923e8..3b81b39 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -365,7 +365,8 @@ struct cpsw_priv {
spinlock_t  lock;
struct platform_device  *pdev;
struct net_device   *ndev;
-   struct napi_struct  napi;
+   struct napi_struct  napi_rx;
+   struct napi_struct  napi_tx;
struct device   *dev;
struct cpsw_platform_data   data;
struct cpsw_ss_regs __iomem *regs;
@@ -751,13 +752,10 @@ static irqreturn_t cpsw_tx_interrupt(int irq, void 
*dev_id)
 {
struct cpsw_priv *priv = dev_id;
 
+   writel(0, priv-wr_regs-tx_en);
cpdma_ctlr_eoi(priv-dma, CPDMA_EOI_TX);
-   cpdma_chan_process(priv-txch, 128);
-
-   priv = cpsw_get_slave_priv(priv, 1);
-   if (priv)
-   cpdma_chan_process(priv-txch, 128);
 
+   napi_schedule(priv-napi_tx);
return IRQ_HANDLED;
 }
 
@@ -768,18 +766,35 @@ static irqreturn_t cpsw_rx_interrupt(int irq, void 
*dev_id)
cpdma_ctlr_eoi(priv-dma, CPDMA_EOI_RX);
writel(0, priv-wr_regs-rx_en);
 
-   napi_schedule(priv-napi);
+   napi_schedule(priv-napi_rx);
return IRQ_HANDLED;
 }
 
-static int cpsw_poll(struct napi_struct *napi, int budget)
+static int cpsw_tx_poll(struct napi_struct *napi_tx, int budget)
+{
+   struct cpsw_priv*priv = napi_to_priv(napi_tx);
+   int num_tx;
+
+   num_tx = cpdma_chan_process(priv-txch, budget);
+   if (num_tx  budget) {
+   napi_complete(napi_tx);
+   writel(0xff, priv-wr_regs-tx_en);
+   }
+
+   if (num_tx)
+   cpsw_dbg(priv, intr, poll %d tx pkts\n, num_tx);
+
+   return num_tx;
+}
+
+static int cpsw_rx_poll(struct napi_struct *napi_rx, int budget)
 {
-   struct cpsw_priv*priv = napi_to_priv(napi);
+   struct cpsw_priv*priv = napi_to_priv(napi_rx);
int num_rx;
 
num_rx = cpdma_chan_process(priv-rxch, budget);
if (num_rx  budget) {
-   napi_complete(napi);
+   napi_complete(napi_rx);
writel(0xff, priv-wr_regs-rx_en);
}
 
@@ -1249,7 +1264,8 @@ static int cpsw_ndo_open(struct net_device *ndev)
/* Enable internal fifo flow control */
writel(0x7, priv-regs-flow_control);
 
-   napi_enable(priv_sl0-napi);
+   napi_enable(priv_sl0-napi_rx);
+   napi_enable(priv_sl0-napi_tx);
 
if (WARN_ON(!priv-data.rx_descs))
priv-data.rx_descs = 128;
@@ -1315,7 +1331,8 @@ static int cpsw_ndo_stop(struct net_device *ndev)
if (cpsw_common_res_usage_state(priv) = 1) {
struct cpsw_priv *priv_sl0 = cpsw_get_slave_priv(priv, 0);
 
-   napi_disable(priv_sl0-napi);
+   napi_disable(priv_sl0-napi_rx);
+   napi_disable(priv_sl0-napi_tx);
cpts_unregister(priv-cpts);
cpsw_intr_disable(priv);
cpdma_ctlr_stop(priv-dma);
@@ -2349,7 +2366,8 @@ static int cpsw_probe(struct platform_device *pdev)
 
ndev-netdev_ops = cpsw_netdev_ops;
ndev-ethtool_ops = cpsw_ethtool_ops;
-   netif_napi_add(ndev, priv-napi, cpsw_poll, CPSW_POLL_WEIGHT);
+   netif_napi_add(ndev, priv-napi_rx, cpsw_rx_poll, CPSW_POLL_WEIGHT);
+   netif_napi_add(ndev, priv-napi_tx, cpsw_tx_poll, CPSW_POLL_WEIGHT);
 
/* register the network device */
SET_NETDEV_DEV(ndev, pdev-dev);
-- 
2.5.0.234.gefc8a62

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[net-next PATCH v2 0/3] CPSW interrupt handling cleanup and performance improvement

[Mugunthan V N]

This patch series removes the irq controller disable interrupt and
adding a napi for tx event handling which improves the performance by
~180Mbps on dra7-evm

[  5] local 192.168.10.116 port 5001 connected with 192.168.10.165 port 44176
[  5]  0.0-60.0 sec  1.48 GBytes   210 Mbits/sec
[  4] local 192.168.10.116 port 5001 connected with 192.168.10.165 port 33257
[  4]  0.0-60.0 sec  2.71 GBytes   386 Mbits/sec

Changes from initial version: 
* Added a patch to have napi only for first interface as there is
  no use of having seperate napis for each interface as the
  interrupt is shared by both interface and only one napi is
  scheduled for each interrupt.

Mugunthan V N (3):
  drivers: net: cpsw: remove  disable_irq/enable_irq as irq can be
masked from cpsw itself
  drivers: net: cpsw: dual_emac: simplify napi usage
  drivers: net: cpsw: add separate napi for tx

 drivers/net/ethernet/ti/cpsw.c | 83 ++
 1 file changed, 35 insertions(+), 48 deletions(-)

-- 
2.5.0.234.gefc8a62

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[net-next PATCH v2 2/3] drivers: net: cpsw: dual_emac: simplify napi usage

[Mugunthan V N]

Since interrupt is shared between the two ethernet interface and
in isr only one napi is scheduled at an instance so having two
napis doesn't make any difference. So making napi also as a
common resource for the dual ethernet interfaces.

Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
 drivers/net/ethernet/ti/cpsw.c | 26 +-
 1 file changed, 9 insertions(+), 17 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index d68d759..1d923e8 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -768,20 +768,8 @@ static irqreturn_t cpsw_rx_interrupt(int irq, void *dev_id)
cpdma_ctlr_eoi(priv-dma, CPDMA_EOI_RX);
writel(0, priv-wr_regs-rx_en);
 
-   if (netif_running(priv-ndev)) {
-   napi_schedule(priv-napi);
-   return IRQ_HANDLED;
-   }
-
-   priv = cpsw_get_slave_priv(priv, 1);
-   if (!priv)
-   return IRQ_NONE;
-
-   if (netif_running(priv-ndev)) {
-   napi_schedule(priv-napi);
-   return IRQ_HANDLED;
-   }
-   return IRQ_NONE;
+   napi_schedule(priv-napi);
+   return IRQ_HANDLED;
 }
 
 static int cpsw_poll(struct napi_struct *napi, int budget)
@@ -1246,6 +1234,8 @@ static int cpsw_ndo_open(struct net_device *ndev)
  ALE_ALL_PORTS  priv-host_port, 0, 0);
 
if (!cpsw_common_res_usage_state(priv)) {
+   struct cpsw_priv *priv_sl0 = cpsw_get_slave_priv(priv, 0);
+
/* setup tx dma to fixed prio and zero offset */
cpdma_control_set(priv-dma, CPDMA_TX_PRIO_FIXED, 1);
cpdma_control_set(priv-dma, CPDMA_RX_BUFFER_OFFSET, 0);
@@ -1259,6 +1249,8 @@ static int cpsw_ndo_open(struct net_device *ndev)
/* Enable internal fifo flow control */
writel(0x7, priv-regs-flow_control);
 
+   napi_enable(priv_sl0-napi);
+
if (WARN_ON(!priv-data.rx_descs))
priv-data.rx_descs = 128;
 
@@ -1297,7 +1289,6 @@ static int cpsw_ndo_open(struct net_device *ndev)
cpsw_set_coalesce(ndev, coal);
}
 
-   napi_enable(priv-napi);
cpdma_ctlr_start(priv-dma);
cpsw_intr_enable(priv);
 
@@ -1319,10 +1310,12 @@ static int cpsw_ndo_stop(struct net_device *ndev)
 
cpsw_info(priv, ifdown, shutting down cpsw device\n);
netif_stop_queue(priv-ndev);
-   napi_disable(priv-napi);
netif_carrier_off(priv-ndev);
 
if (cpsw_common_res_usage_state(priv) = 1) {
+   struct cpsw_priv *priv_sl0 = cpsw_get_slave_priv(priv, 0);
+
+   napi_disable(priv_sl0-napi);
cpts_unregister(priv-cpts);
cpsw_intr_disable(priv);
cpdma_ctlr_stop(priv-dma);
@@ -2105,7 +2098,6 @@ static int cpsw_probe_dual_emac(struct platform_device 
*pdev,
 
ndev-netdev_ops = cpsw_netdev_ops;
ndev-ethtool_ops = cpsw_ethtool_ops;
-   netif_napi_add(ndev, priv_sl2-napi, cpsw_poll, CPSW_POLL_WEIGHT);
 
/* register the network device */
SET_NETDEV_DEV(ndev, pdev-dev);
-- 
2.5.0.234.gefc8a62

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[net-next PATCH v2 1/3] drivers: net: cpsw: remove disable_irq/enable_irq as irq can be masked from cpsw itself

[Mugunthan V N]

CPSW interrupts can be disabled by masking CPSW interrupts and
clearing interrupt by writing appropriate EOI. So removing all
disable_irq/enable_irq as discussed in [1]

[1] http://patchwork.ozlabs.org/patch/492741/

Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
 drivers/net/ethernet/ti/cpsw.c | 27 ++-
 1 file changed, 2 insertions(+), 25 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index d155bf2..d68d759 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -389,7 +389,6 @@ struct cpsw_priv {
/* snapshot of IRQ numbers */
u32 irqs_table[4];
u32 num_irqs;
-   bool irq_enabled;
struct cpts *cpts;
u32 emac_port;
 };
@@ -767,12 +766,7 @@ static irqreturn_t cpsw_rx_interrupt(int irq, void *dev_id)
struct cpsw_priv *priv = dev_id;
 
cpdma_ctlr_eoi(priv-dma, CPDMA_EOI_RX);
-
-   cpsw_intr_disable(priv);
-   if (priv-irq_enabled == true) {
-   disable_irq_nosync(priv-irqs_table[0]);
-   priv-irq_enabled = false;
-   }
+   writel(0, priv-wr_regs-rx_en);
 
if (netif_running(priv-ndev)) {
napi_schedule(priv-napi);
@@ -797,15 +791,8 @@ static int cpsw_poll(struct napi_struct *napi, int budget)
 
num_rx = cpdma_chan_process(priv-rxch, budget);
if (num_rx  budget) {
-   struct cpsw_priv *prim_cpsw;
-
napi_complete(napi);
-   cpsw_intr_enable(priv);
-   prim_cpsw = cpsw_get_slave_priv(priv, 0);
-   if (prim_cpsw-irq_enabled == false) {
-   prim_cpsw-irq_enabled = true;
-   enable_irq(priv-irqs_table[0]);
-   }
+   writel(0xff, priv-wr_regs-rx_en);
}
 
if (num_rx)
@@ -1230,7 +1217,6 @@ static void cpsw_slave_stop(struct cpsw_slave *slave, 
struct cpsw_priv *priv)
 static int cpsw_ndo_open(struct net_device *ndev)
 {
struct cpsw_priv *priv = netdev_priv(ndev);
-   struct cpsw_priv *prim_cpsw;
int i, ret;
u32 reg;
 
@@ -1315,14 +1301,6 @@ static int cpsw_ndo_open(struct net_device *ndev)
cpdma_ctlr_start(priv-dma);
cpsw_intr_enable(priv);
 
-   prim_cpsw = cpsw_get_slave_priv(priv, 0);
-   if (prim_cpsw-irq_enabled == false) {
-   if ((priv == prim_cpsw) || !netif_running(prim_cpsw-ndev)) {
-   prim_cpsw-irq_enabled = true;
-   enable_irq(prim_cpsw-irqs_table[0]);
-   }
-   }
-
if (priv-data.dual_emac)
priv-slaves[priv-emac_port].open_stat = true;
return 0;
@@ -2169,7 +2147,6 @@ static int cpsw_probe(struct platform_device *pdev)
priv-msg_enable = netif_msg_init(debug_level, CPSW_DEBUG);
priv-rx_packet_max = max(rx_packet_max, 128);
priv-cpts = devm_kzalloc(pdev-dev, sizeof(struct cpts), GFP_KERNEL);
-   priv-irq_enabled = true;
if (!priv-cpts) {
dev_err(pdev-dev, error allocating cpts\n);
ret = -ENOMEM;
-- 
2.5.0.234.gefc8a62

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [net-next PATCH 2/2] drivers: net: cpsw: add separate napi for tx packet handling for performance improvment

[Mugunthan V N]

On Thursday 30 July 2015 04:27 AM, Francois Romieu wrote:
 Mugunthan V N mugunthan...@ti.com :
 On Wednesday 29 July 2015 04:00 AM, Francois Romieu wrote:
 Mugunthan V N mugunthan...@ti.com :
 On Tuesday 28 July 2015 02:52 AM, Francois Romieu wrote:
 [...]
 cpsw_ndo_stop calls napi_disable: you can remove netif_running.


 This netif_running check is to find which interface is up as the
 interrupt is shared by both the interfaces. When first interface is down
 and second interface is active then napi_schedule for first interface
 will fail and second interface napi needs to be scheduled.

 So I don't think netif_running needs to be removed.

 Each interface has its own napi tx (resp. rx) context: I would had expected
 two unconditional napi_schedule per tx (resp. rx) shared irq, not one.

 I'll read it again after some sleep.


 For each interrupt only one napi will be scheduled, when the first
 interface is down then only second interface napi is scheduled in both
 tx and rx irqs.
 
 Ok, I've had some hints from the Assumptions section at
 http://processors.wiki.ti.com/index.php/AM335x_CPSW_%28Ethernet%29_Driver%27s_Guide#Dual_Standalone_EMAC_mode
 
 Why does the driver create 2 rx napi contexts ? They don't run at the
 same time and the port demux is done in cpsw_dual_emac_src_port_detect.
 The driver would work the same with a single rx (resp. tx) napi context
 for both interfaces.
 

The wiki you had pointed out is old design done on v3.2 and doesn't have
device tree support also. In mainline Dual EMAC implementation has
changed a lot.

I can think of a way with one napi implementation for each rx and tx,
will submit a separate patch for it.

Regards
Mugunthan V N
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [net-next PATCH 2/2] drivers: net: cpsw: add separate napi for tx packet handling for performance improvment

[Mugunthan V N]

On Wednesday 29 July 2015 04:00 AM, Francois Romieu wrote:
 Mugunthan V N mugunthan...@ti.com :
 On Tuesday 28 July 2015 02:52 AM, Francois Romieu wrote:
 Mugunthan V N mugunthan...@ti.com :
 [...]
 @@ -752,13 +753,22 @@ static irqreturn_t cpsw_tx_interrupt(int irq, void 
 *dev_id)
struct cpsw_priv *priv = dev_id;
  
cpdma_ctlr_eoi(priv-dma, CPDMA_EOI_TX);
 -  cpdma_chan_process(priv-txch, 128);
 +  writel(0, priv-wr_regs-tx_en);
 +
 +  if (netif_running(priv-ndev)) {
 +  napi_schedule(priv-napi_tx);
 +  return IRQ_HANDLED;
 +  }


 cpsw_ndo_stop calls napi_disable: you can remove netif_running.


 This netif_running check is to find which interface is up as the
 interrupt is shared by both the interfaces. When first interface is down
 and second interface is active then napi_schedule for first interface
 will fail and second interface napi needs to be scheduled.

 So I don't think netif_running needs to be removed.
 
 Each interface has its own napi tx (resp. rx) context: I would had expected
 two unconditional napi_schedule per tx (resp. rx) shared irq, not one.
 
 I'll read it again after some sleep.
 

For each interrupt only one napi will be scheduled, when the first
interface is down then only second interface napi is scheduled in both
tx and rx irqs.

Regards
Mugunthan V N
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html