Now we need the missing cover note what should be in 0/4. What is the
big picture? How are these two functions supposed to be used? Is there
going to be a user space API via netlink? Should the MAC driver
somehow call these functions? Are you going to extend the phylib with
code to call these?
Those are all general questions for these two functions.
Now specifically for edge control, why did you decide not to use
device tree? Both the micrel and renesas phy driver uses device tree
for skew control. You need to explain why you need to do something
different to other drivers.
Thanks
Andrew
Hi Andrew,
Thank you for review the code and valuable comments.
I accepted your review comments.
I too use the Device Tree for Edge-rate and MAC interface
configuration.
Thanks,
Raju.
On Wed, Aug 24, 2016 at 02:59:34PM +0200, Andrew Lunn wrote:
EXTERNAL EMAIL
On Wed, Aug 24, 2016 at 12:20:03PM +0000, Raju Lakkaraju wrote:
quoted
From: Nagaraju Lakkaraju <redacted>
Edge rate control support will be added for VSC 85xx Microsemi PHYs.
Now we need the missing cover note what should be in 0/4. What is the
big picture? How are these two functions supposed to be used? Is there
going to be a user space API via netlink? Should the MAC driver
somehow call these functions? Are you going to extend the phylib with
code to call these?
Those are all general questions for these two functions.
Now specifically for edge control, why did you decide not to use
device tree? Both the micrel and renesas phy driver uses device tree
for skew control. You need to explain why you need to do something
different to other drivers.
Thanks
Andrew
From: Raju Lakkaraju <redacted>
Used Device Tree to configure the Edge-rate as per review comments and
re-sending code for review
Signed-off-by: Raju Lakkaraju <redacted>
---
drivers/net/phy/mscc.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 76 insertions(+)
From: Raju Lakkaraju <redacted>
Used Device Tree to configure the MAC Interface as per review comments and
re-sending code for review
Signed-off-by: Raju Lakkaraju <redacted>
---
drivers/net/phy/mscc.c | 60 ++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 60 insertions(+)
Patch 1/2:
This is Edge rate control feature.
As system and networking speeds increase, a signal's output transition,
also know as the edge rate or slew rate (V/ns), takes on greater importance
because high-speed signals come with a price. That price is an assortment of
interference problems like ringing on the line, signal overshoot and
undershoot, extended signal settling times, crosstalk noise, transmission line
reflections, false signal detection by the receiving device and electromagnetic
interference (EMI) -- all of which can negate the potential gains designers are
seeking when they try to increase system speeds through the use of higher
performance logic devices. The fact is, faster signaling edge rates can cause
a higher level of electrical noise or other type of interference that can
actually lead to slower line speeds and lower maximum system frequencies.
Microsemi PHY have the provision to configure the edge rate. Edge-rate function
program the right value based on Device Tree configuration.
Tested on Beaglebone Black with VSC 8531 PHY.
Patch 2/2:
This is MAC interface feature.
Microsemi PHY can support RGMII, RMII or GMII/MII interface between MAC and PHY.
MAC-IF function program the right value based on Device tree configuration.
Tested on Beaglebone Black with VSC 8531 PHY.
Raju Lakkaraju (2):
net: phy: Add Edge-rate driver for Microsemi PHYs.
net: phy: Add MAC-IF driver for Microsemi PHYs.
drivers/net/phy/mscc.c | 136 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 136 insertions(+)
--
2.7.4
From: Andrew Lunn <andrew@lunn.ch> Date: 2016-09-08 13:00:00
On Thu, Sep 08, 2016 at 02:47:20PM +0530, Raju Lakkaraju wrote:
Patch 1/2:
This is Edge rate control feature.
As system and networking speeds increase, a signal's output transition,
also know as the edge rate or slew rate (V/ns), takes on greater importance
because high-speed signals come with a price. That price is an assortment of
interference problems like ringing on the line, signal overshoot and
undershoot, extended signal settling times, crosstalk noise, transmission line
reflections, false signal detection by the receiving device and electromagnetic
interference (EMI) -- all of which can negate the potential gains designers are
seeking when they try to increase system speeds through the use of higher
performance logic devices. The fact is, faster signaling edge rates can cause
a higher level of electrical noise or other type of interference that can
actually lead to slower line speeds and lower maximum system frequencies.
Microsemi PHY have the provision to configure the edge rate. Edge-rate function
program the right value based on Device Tree configuration.
Tested on Beaglebone Black with VSC 8531 PHY.
Patch 2/2:
This is MAC interface feature.
Microsemi PHY can support RGMII, RMII or GMII/MII interface between MAC and PHY.
MAC-IF function program the right value based on Device tree configuration.
Hi Raju
In future, please start a new thread for a new version of the
patchset.
Thanks
Andrew
From: Andrew Lunn <andrew@lunn.ch> Date: 2016-09-08 13:14:17
On Thu, Sep 08, 2016 at 02:47:21PM +0530, Raju Lakkaraju wrote:
From: Raju Lakkaraju <redacted>
Used Device Tree to configure the Edge-rate as per review comments and
re-sending code for review
Signed-off-by: Raju Lakkaraju <redacted>
---
drivers/net/phy/mscc.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++
Hi Raju
You need to also document the new property in the device tree binding
documentation.
+static int vsc85xx_edge_rate_cntl_set(struct phy_device *phydev,
+ u8 edge_rate)
Until you have written the Documentation, it is hard for me to tell,
but device tree bindings should use real units, like seconds, Ohms,
Farads, etc. Is the edge rate in nS? Or is it some magic value which
just gets written into the register?
+
+ return rc;
+}
+#else
+static int vsc8531_of_init(struct phy_device *phydev)
+{
+ return 0;
+}
+#endif /* CONFIG_OF_MDIO */
+
static int vsc85xx_config_init(struct phy_device *phydev)
{
int rc;
+ struct vsc8531_private *vsc8531;
+
+ if (!phydev->priv) {
If there is no vsc8531,edge-rate property in device tree, is the phy
going to work O.K, if you configure it for 0nS edges? Or should there
be some default value assigned?
Thanks
Andrew
Do you need to wait for the reset to complete?
Does it make sense to call genphy_soft_reset() which will poll the phy
waiting for the BMCR_RESET bit to clear?
So somebody asks you to configure the phy as PHY_INTERFACE_MODE_NA or
PHY_INTERFACE_MODE_TBI, you are going to use GMII. Maybe returning
-EINVAL would be better?
Andrew
Hi Andrew,
Thank you for review the code and valuable comments.
On Thu, Sep 08, 2016 at 03:27:27PM +0200, Andrew Lunn wrote:
EXTERNAL EMAIL
On Thu, Sep 08, 2016 at 02:47:22PM +0530, Raju Lakkaraju wrote:
quoted
From: Raju Lakkaraju <redacted>
Used Device Tree to configure the MAC Interface as per review comments and
re-sending code for review
I don't see anything about device tree in this patch...
Ethernet driver (in my BBB environment, TI cpsw driver) read the device tree
phy interface parameter and update in phydev structure.
In device tree the following code holds the phy interface configuration.
&cpsw_emac0 {
phy_id = <&davinci_mdio>, <0>;
phy-mode = "rgmii";
};
I tested with different modes by changing device tree parameter (i.e. rmii/rgmii/mii).
I have used this parameter to configure the MAC interface.
Do you need to wait for the reset to complete?
Does it make sense to call genphy_soft_reset() which will poll the phy
waiting for the BMCR_RESET bit to clear?
I accepted your review comment.
I can use genphy_soft_reset( ) instead of creating another same function.
So somebody asks you to configure the phy as PHY_INTERFACE_MODE_NA or
PHY_INTERFACE_MODE_TBI, you are going to use GMII. Maybe returning
-EINVAL would be better?
Microsemi PHY can support only 3 modes (RGMII/RMII/GMII). Default configuration should be GMII
in PHY hardware.
I accepted your review comment.
In default switch case i will return -EINVAL.
Hi Andrew,
Thank you for review the code and valuable comments.
On Thu, Sep 08, 2016 at 03:14:15PM +0200, Andrew Lunn wrote:
EXTERNAL EMAIL
On Thu, Sep 08, 2016 at 02:47:21PM +0530, Raju Lakkaraju wrote:
quoted
From: Raju Lakkaraju <redacted>
Used Device Tree to configure the Edge-rate as per review comments and
re-sending code for review
Signed-off-by: Raju Lakkaraju <redacted>
---
drivers/net/phy/mscc.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++
Hi Raju
You need to also document the new property in the device tree binding
documentation.
Sure. I will do.
I created device tree binding header file. i will submit in different patch.
quoted
+static int vsc85xx_edge_rate_cntl_set(struct phy_device *phydev,
+ u8 edge_rate)
No spaces place.
I ran the checkpatch. I did not find any error. I created another workspace and
applied the same patch. It shows the correct alignement. I have used tabs (8 space width).
then some spaces to align braces.
Until you have written the Documentation, it is hard for me to tell,
but device tree bindings should use real units, like seconds, Ohms,
Farads, etc. Is the edge rate in nS? Or is it some magic value which
just gets written into the register?
This is some magic value which just gets written into the register.
In device tree file, defined in davinci_mdio structure:
vsc8531_0: ethernet-phy@0 {
compatible = "ethernet-phy-id0007.0570";
reg = <0>;
vsc8531,edge-rate = /bits/ 8 <MSCC_EDGE_RATE_CNTL_FASTEST>;
};
In device tree binding header file, MACRO has defined as
i.e. include/dt-bindings/net/mscc-vsc8531.h
/* MAC interface Edge rate control pad */
#define MSCC_EDGE_RATE_CNTL_SLOWEST 0x0
#define MSCC_EDGE_RATE_CNTL_PLUS_1 0x1
#define MSCC_EDGE_RATE_CNTL_PLUS_2 0x2
#define MSCC_EDGE_RATE_CNTL_PLUS_3 0x3
#define MSCC_EDGE_RATE_CNTL_PLUS_4 0x4
#define MSCC_EDGE_RATE_CNTL_PLUS_5 0x5
#define MSCC_EDGE_RATE_CNTL_PLUS_6 0x6
#define MSCC_EDGE_RATE_CNTL_FASTEST 0x7
quoted
+
+ return rc;
+}
+#else
+static int vsc8531_of_init(struct phy_device *phydev)
+{
+ return 0;
+}
+#endif /* CONFIG_OF_MDIO */
+
static int vsc85xx_config_init(struct phy_device *phydev)
{
int rc;
+ struct vsc8531_private *vsc8531;
+
+ if (!phydev->priv) {
How can this happen?
VSC 8531 driver don't have any private structure assigned initially.
Allways priv points to NULL.
Allocate vsc8531 private structure and initialize by calling vsc8531_of_init( )
function.
If there is no vsc8531,edge-rate property in device tree, is the phy
going to work O.K, if you configure it for 0nS edges? Or should there
be some default value assigned?
Yes. Default values configured as Fast Edge rate control (i.e.0b111).
Edge rate control has defined 3 bits (Bit 7:5) in register.
Hardware default value is 3 (i.e. 0b111)
From: Andrew Lunn <andrew@lunn.ch> Date: 2016-09-09 12:03:50
On Fri, Sep 09, 2016 at 11:23:52AM +0530, Raju Lakkaraju wrote:
Hi Andrew,
Thank you for review the code and valuable comments.
On Thu, Sep 08, 2016 at 03:27:27PM +0200, Andrew Lunn wrote:
quoted
EXTERNAL EMAIL
On Thu, Sep 08, 2016 at 02:47:22PM +0530, Raju Lakkaraju wrote:
quoted
From: Raju Lakkaraju <redacted>
Used Device Tree to configure the MAC Interface as per review comments and
re-sending code for review
I don't see anything about device tree in this patch...
Ethernet driver (in my BBB environment, TI cpsw driver) read the device tree
phy interface parameter and update in phydev structure.
In device tree the following code holds the phy interface configuration.
&cpsw_emac0 {
phy_id = <&davinci_mdio>, <0>;
phy-mode = "rgmii";
};
O.K, that is one place it can come from. But it is not the only,
e.g. platform data or ACPI. A better comment might be:
Configure the MAC/PHY interface as indicated in phydev->interface,
eg. GMII, RMII, RGMII.
Andrew
From: Andrew Lunn <andrew@lunn.ch> Date: 2016-09-09 13:18:36
quoted
quoted
+static int vsc85xx_edge_rate_cntl_set(struct phy_device *phydev,
+ u8 edge_rate)
No spaces place.
I ran the checkpatch. I did not find any error. I created another workspace and
applied the same patch. It shows the correct alignement. I have used tabs (8 space width).
then some spaces to align braces.
Sorry, i worded that poorly. I was meaning between the u8 and edge. A
single space is enough.
Until you have written the Documentation, it is hard for me to tell,
but device tree bindings should use real units, like seconds, Ohms,
Farads, etc. Is the edge rate in nS? Or is it some magic value which
just gets written into the register?
This is some magic value which just gets written into the register.
Magic values are generally not accepted in device tree bindings. Both
Micrel and Renesas define their clock skew in ps, for example. Since
this is rise time, it should also be possible to define it in a unit
of time.
quoted
quoted
static int vsc85xx_config_init(struct phy_device *phydev)
{
int rc;
+ struct vsc8531_private *vsc8531;
+
+ if (!phydev->priv) {
How can this happen?
VSC 8531 driver don't have any private structure assigned initially.
Allways priv points to NULL.
So if it cannot happen, don't check for it.
Also, by convention, you allocate memory in the .probe() function of a
driver. Please do it there.
Andrew
Hi Andrew,
Thank you for review the code.
On Fri, Sep 09, 2016 at 03:18:32PM +0200, Andrew Lunn wrote:
EXTERNAL EMAIL
quoted
quoted
quoted
+static int vsc85xx_edge_rate_cntl_set(struct phy_device *phydev,
+ u8 edge_rate)
No spaces place.
I ran the checkpatch. I did not find any error. I created another workspace and
applied the same patch. It shows the correct alignement. I have used tabs (8 space width).
then some spaces to align braces.
Sorry, i worded that poorly. I was meaning between the u8 and edge. A
single space is enough.
Until you have written the Documentation, it is hard for me to tell,
but device tree bindings should use real units, like seconds, Ohms,
Farads, etc. Is the edge rate in nS? Or is it some magic value which
just gets written into the register?
This is some magic value which just gets written into the register.
Magic values are generally not accepted in device tree bindings. Both
Micrel and Renesas define their clock skew in ps, for example. Since
this is rise time, it should also be possible to define it in a unit
of time.
I accepted your comment. I had discussion with my hardware team and explained
the code review comments.
They asked me to define as picoseconds as units.
quoted
quoted
quoted
static int vsc85xx_config_init(struct phy_device *phydev)
{
int rc;
+ struct vsc8531_private *vsc8531;
+
+ if (!phydev->priv) {
How can this happen?
VSC 8531 driver don't have any private structure assigned initially.
Allways priv points to NULL.
So if it cannot happen, don't check for it.
Also, by convention, you allocate memory in the .probe() function of a
driver. Please do it there.
I accepted your review comment.
I will re-send the patch with updates.
Hi Andrew,
Thank you for review the code.
I accepted all your review comments.
I will send the update patch for review again.
Thanks,
Raju.
On Fri, Sep 09, 2016 at 02:03:46PM +0200, Andrew Lunn wrote:
EXTERNAL EMAIL
On Fri, Sep 09, 2016 at 11:23:52AM +0530, Raju Lakkaraju wrote:
quoted
Hi Andrew,
Thank you for review the code and valuable comments.
On Thu, Sep 08, 2016 at 03:27:27PM +0200, Andrew Lunn wrote:
quoted
EXTERNAL EMAIL
On Thu, Sep 08, 2016 at 02:47:22PM +0530, Raju Lakkaraju wrote:
quoted
From: Raju Lakkaraju <redacted>
Used Device Tree to configure the MAC Interface as per review comments and
re-sending code for review
I don't see anything about device tree in this patch...
Ethernet driver (in my BBB environment, TI cpsw driver) read the device tree
phy interface parameter and update in phydev structure.
In device tree the following code holds the phy interface configuration.
&cpsw_emac0 {
phy_id = <&davinci_mdio>, <0>;
phy-mode = "rgmii";
};
O.K, that is one place it can come from. But it is not the only,
e.g. platform data or ACPI. A better comment might be:
Configure the MAC/PHY interface as indicated in phydev->interface,
eg. GMII, RMII, RGMII.
Andrew