Re: [PATCH net-next 1/3] net: stmmac: add gmac autoneg set for SGMII, TBI, and RTBI
Hello Byungho
sorry for my late reply. I'm attaching two patches built for net-next
as we had clarified. I had written the first patch long time ago
and on top of it I have added some part of your code below with some
fixes (see also the comments inline below).
This work is not yet completed but I do hope these two patches will
help you to complete all. Unfortunately, I cannot do any tests
because I have no HW that supports PCS. :-(
In the second patch, take a look at the comment that reports
the missing parts. For example, ethtool, SGMII etc.
I wonder if you could review/test the two patches on your side.
Also I hope you can improve all adding the missing features (that is
what you were already doing).
If you agree, you could also re-send *all* to the mailing list to
be finally reviewed.
On 1/25/2013 11:01 PM, Byungho An wrote:
On 1/23/2013 1:43 PM, Giuseppe CAVALLARO write:
[snip]
I modified this part like below
@@ -1044,12 +1046,8 @@ static int stmmac_open(struct net_device *dev)
priv->hw->mac->core_init(priv->ioaddr);
/* Enable auto-negotiation for SGMII, TBI or RTBI */
- if (interface == PHY_INTERFACE_MODE_SGMII ||
- interface == PHY_INTERFACE_MODE_TBI ||
- interface == PHY_INTERFACE_MODE_RTBI) {
- if (priv->phydev->autoneg)
- priv->hw->mac->set_autoneg(priv->ioaddr);
- }
+ if (priv->dma_cap.pcs)
+ priv->hw->mac->ctrl_ane(priv->ioaddr, 0);
/* Request the IRQ lines */
ret = request_irq(dev->irq, stmmac_interrupt,
As you may know, auto-negotiation is essential for SGMII, TBI, or RTBI
interface.
good, add it on top of the second patch.
And ctrl_ane funciont is like that
@@ -311,6 +317,18 @@ static void dwmac1000_set_autoneg(void __iomem *ioaddr)
writel(value, ioaddr + GMAC_AN_CTRL);
}
+static void dwmac1000_ctrl_ane(void __iomem *ioaddr, bool restart)
+{
+ u32 value;
+
+ value = readl(ioaddr + GMAC_AN_CTRL);
+ /* auto negotiation enable and External Loopback enable */
+ value = GMAC_AN_CTRL__ANE | GMAC_AN_CTRL__ELE;
+
+ if (restart)
+ value |= GMAC_AN_CTRL_RAN;
+
+ writel(value, ioaddr + GMAC_AN_CTRL);
+}
static const struct stmmac_ops dwmac1000_ops = {
.core_init = dwmac1000_core_init,
well done and added in the second patch.
[snip]
I've changed restart AN like below.
@@ -610,6 +607,27 @@ static int stmmac_set_coalesce(struct net_device *dev,
return 0;
}
+static int
+stmmac_nway_reset(struct net_device *netdev)
+{
+ struct stmmac_priv *priv = netdev_priv(netdev);
+ struct phy_device *phy = priv->phydev;
+ int ret = 0;
+
+ spin_lock(&priv->lock);
+
+ if (netif_running(netdev)) {
+ phy_stop(phy);
+ phy_start(phy);
+ ret = phy_start_aneg(phy);
+ if (priv->dma_cap.pcs)
+ priv->hw->mac->ctrl_ane(priv->ioaddr, true);
+ }
+
+ spin_unlock(&priv->lock);
+ return ret;
+}
+
static const struct ethtool_ops stmmac_ethtool_ops = {
.begin = stmmac_check_if_running,
.get_drvinfo = stmmac_ethtool_getdrvinfo,
we have to review this. I expect to have a new patch that includes the
ethtool support but, at first glance, the stmmac_nway_reset should only
call the ctrl_ane.
pay attention that also some other ethtool functions have to be fixed
for this support.
[snip]
I think whenever link is changed, phy->state is changed and call
stmmac_adjust_link. It would update gmac's link.
I can get autonegotiation complete and link change irqs if we need something
we can add code in the handler but I'm not sure which one is need yet.
As of now I just added phy_state = PHY_CHANGELINK as a test code in the link
change irq handler.
@@ -1624,8 +1629,43 @@ static irqreturn_t stmmac_interrupt(int irq, void
*dev_id)
priv->xstats.mmc_rx_csum_offload_irq_n++;
if (status & core_irq_receive_pmt_irq)
priv->xstats.irq_receive_pmt_irq_n++;
+ if (status & core_irq_pcs_autoneg_complete)
+priv->core_pcs_an = true;
+ if (status & core_irq_pcs_link_status_change) {
+ priv->core_pcs_link_change = true;
+ status = readl(priv->ioaddr +
GMAC_AN_STATUS);
+ if (status & GMAC_AN_STATUS_LS)
+ if ((priv->speed != phy->speed) ||
(priv->oldduplex != phy->duplex))
+ phy->state = PHY_CHANGELINK; /* for
test */
+ }
/* For LPI we need to save the tx status */
Re: [RFC] net: stmmac: keep RXC running in LPI mode to avoid system overload
Hello Romain
On 10/8/2013 5:06 PM, Romain Baeriswyl wrote:
In order to avoid system overload, the clock RXC from the Phy should not be
stopped when in LPI mode.
With the RTL8211E PHY which support EEE mode and with Apple Airport Extreme that
supports it also, the kernel get frozen as soon as some Ethernet transfers are
hmm, I have a board with this transceiver so I could do some tests
this could take a while, unfortunately.
on-going. System seems to be overloaded with too many interrupts. The 'top'
command reports often around ~80% irq.
do you mean lpi mac interrupts?
By letting the RXC clock running even in LPI mode as proposed below, the issue
seems solved. Is it the right way to proceed?
For EEE capability, RX_CLK may be halted for this reason i used it as
default in the stmmac and never seen your issue.
What is the power impact to not stop RXC in LPI mode?
I can point you to "22.2.2.8a Receive direction LPI transition"
in IEEE802-3az... where is it reported that the PHY halt the RX_CLK
in LPI mode.
May I suspect some issues on your HW? or disable it with ethtool
peppe
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index e9eab29..d40d26b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -314,7 +314,8 @@ bool stmmac_eee_init(struct stmmac_priv *priv)
/* MAC core supports the EEE feature. */
if (priv->dma_cap.eee) {
/* Check if the PHY supports EEE */
- if (phy_init_eee(priv->phydev, 1))
+ /* Keeps RXC running in LPI mode to avoid stability issue */
+ if (phy_init_eee(priv->phydev, 0))
goto out;
if (!priv->eee_active) {
@@ -770,7 +771,8 @@ static void stmmac_adjust_link(struct net_device *dev)
/* At this stage, it could be needed to setup the EEE or adjust some
* MAC related HW registers.
*/
- priv->eee_enabled = stmmac_eee_init(priv);
+ if (new_state)
+ priv->eee_enabled = stmmac_eee_init(priv);
this seems out of context and not necessary
spin_unlock_irqrestore(&priv->lock, flags);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] net: stmmac: change GMAC control register for SGMII
On 11/28/2012 11:57 AM, Byungho An wrote:
On 11/26/2012 07:31 PM, Giuseppe CABALLARO wrote:
On 11/23/2012 10:04 AM, Byungho An wrote:
This patch changes GMAC control register (TC(Transmit
Configuration) and PS(Port Selection) bit for SGMII.
In case of SGMII, TC bit is '1' and PS bit is 0.
IMO this new support that should be released for net-next and further
effort is actually needed.
OK, I see but if possible, I want to support the new features which is
included in this patch from v3.8
ok I agree and I can support you.
The availability of the PCS registers is given by looking at the HW
feature register. In fact, these are optional registers.
I don't want to break the compatibility with old chips.
It means that old chip doesn't have this bit or this register? If that, how
about using compatible in DT blob like snps,dwmac-3.70a and then in just
this case trying to read this bit and this register.
The driver also works on mac 10/100 Databook 2.0 that has not these
registers.
I do not see why we have to use Kconfig macro to select ANE etc (as
you do in your patches).
OK. I agree with you.
we have to use the HW feature reg.
The driver could directly manage the phy device by itself if possible
and the stmmac_init_phy should be reworked.
Could you explain more detail? As I understood, after set ANE bit in MAC
side then PHY auto-negotiation can be enabled. If I'm wrong let me know.
According to your mention, MAC and PHY auto-negotiation can be managed in
stmmac_init_phy?
Currently the driver uses the Physical Abstraction Layer (PAL) to dialog
with a PHY. On all the platforms supported (not only ST) we have always
used it. Personally, I tested several phy devices with different MII
interfaces (MII/RMII/GMII/RGMII ... ) but not TBI/RTBI/SGMII interfaces.
There are several things that need to be implemented. For example:
The ISR (e.g. priv->hw->mac->host_irq_status) should be able to manage
these new interrupts.
I think that there would be two additional interrupts."PCS Auto-Negotiation
Complete" and "PCS Link Status Changed". These two interrupts are added to
"stmmac_interrupt". In my opinion, there are no specific processing for
these two irqs. What do you think about it?
if the link changes this has to be logged in the driver.
For example, depending on the link speed on some platforms we need to
call dedicated call-back to set sysconfig registers or custom clocks.
The code has to be able to maintain the user interface.
For example if you want to enable ANE or manage Advertisement caps.
Does it mean that command line or other network command(e.g. ifconfig...) or
ioctol? Actually I don't understand exact user interface way. Could you
recommend the method for user interface?
Using ethtool or mii-tool the user want to know the link status. So
these kind of information have to be maintained.
Take a look at the stmmac_adjust_link that is called by the PAL.
Signed-off-by: Byungho An
---
[snip]
+ if (priv->phydev->interface == PHY_INTERFACE_MODE_SGMII) {
+ value = readl(priv->ioaddr);
+ /* GMAC_CONTROL_TC : transmit config in RGMII/SGMII */
+ value |= 0x100;
+ /* GMAC_CONTROL_PS : Port Selection for GMII */
+ value &= ~(0x8000);
+ writel(value, priv->ioaddr);
+ }
+
This parts of code have to be moved in
drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
OK.
Pls, do not use value |= 0x100 but provide the appropriate defines.
OK.
/* Request the IRQ lines */
ret = request_irq(dev->irq, stmmac_interrupt,
IRQF_SHARED, dev->name, dev);
Thank you.
you are welcome
Peppe
Byungho An.
--
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 2/3] dt:net:stmmac: Add support to dwmac version 3.610 and 3.710
On 7/1/2013 1:43 PM, Srinivas KANDAGATLA wrote:
From: Srinivas Kandagatla
This patch adds dt support to dwmac version 3.610 and 3.710 these
versions are integrated in STiH415 and STiH416 ARM A9 SOCs.
To support these IP version, some of the device tree properties are
extended.
Signed-off-by: Srinivas Kandagatla
---
Documentation/devicetree/bindings/net/stmmac.txt |4 +++
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 25
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt
b/Documentation/devicetree/bindings/net/stmmac.txt
index 060bbf0..e1ddfcc 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -12,6 +12,10 @@ Required properties:
property
- phy-mode: String, operation mode of the PHY interface.
Supported values are: "mii", "rmii", "gmii", "rgmii".
+- snps,phy-addrphy address to connect to.
+- snps,pbl Programmable Burst Length
+- snps,fixed-burst Program the DMA to use the fixed burst mode
+- snps,mixed-burst Program the DMA to use the mixed burst mode
Optional properties:
- mac-address: 6 bytes, mac address
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 5907920..060758d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -29,17 +29,26 @@
#include "stmmac.h"
#ifdef CONFIG_OF
+
static int stmmac_probe_config_dt(struct platform_device *pdev,
struct plat_stmmacenet_data *plat,
const char **mac)
{
struct device_node *np = pdev->dev.of_node;
+ struct stmmac_dma_cfg *dma_cfg;
if (!np)
return -ENODEV;
*mac = of_get_mac_address(np);
plat->interface = of_get_phy_mode(np);
+
+ plat->bus_id = of_alias_get_id(np, "ethernet");
+ if (plat->bus_id < 0)
+ plat->bus_id = 0;
+
+ of_property_read_u32(np, "snps,phy-addr", &plat->phy_addr);
+
plat->mdio_bus_data = devm_kzalloc(&pdev->dev,
sizeof(struct stmmac_mdio_bus_data),
GFP_KERNEL);
@@ -51,11 +60,25 @@ static int stmmac_probe_config_dt(struct platform_device
*pdev,
*/
if (of_device_is_compatible(np, "st,spear600-gmac") ||
of_device_is_compatible(np, "snps,dwmac-3.70a") ||
+ of_device_is_compatible(np, "snps,dwmac-3.610") ||
of_device_is_compatible(np, "snps,dwmac")) {
plat->has_gmac = 1;
plat->pmt = 1;
}
+ if (of_device_is_compatible(np, "snps,dwmac-3.610") ||
+ of_device_is_compatible(np, "snps,dwmac-3.710")) {
+ plat->enh_desc = 1;
+ plat->bugged_jumbo = 1;
+ plat->force_sf_dma_mode = 1;
+ }
I think some these shouldn't be forced here. Maybe plat->enh_desc could
be set because for new syn mac cores.
Also pmt could not be forced because it is an extra module so it could
happen that a new chip has no PMT block.
+
+ dma_cfg = devm_kzalloc(&pdev->dev, sizeof(*dma_cfg), GFP_KERNEL);
+ plat->dma_cfg = dma_cfg;
+ of_property_read_u32(np, "snps,pbl", &dma_cfg->pbl);
+ dma_cfg->fixed_burst = of_property_read_bool(np, "snps,fixed-burst");
+ dma_cfg->mixed_burst = of_property_read_bool(np, "snps,mixed-burst");
+
return 0;
}
#else
@@ -230,7 +253,9 @@ static const struct dev_pm_ops stmmac_pltfr_pm_ops;
static const struct of_device_id stmmac_dt_ids[] = {
{ .compatible = "st,spear600-gmac"},
+ { .compatible = "snps,dwmac-3.610"},
{ .compatible = "snps,dwmac-3.70a"},
+ { .compatible = "snps,dwmac-3.710"},
{ .compatible = "snps,dwmac"},
{ /* sentinel */ }
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 1/3] dt:net:stmmac: Allocate platform data only if its NULL.
On 7/1/2013 1:43 PM, Srinivas KANDAGATLA wrote:
From: Srinivas Kandagatla
In some DT use-cases platform data might be already allocated and passed
via AUXDATA. These are the cases where machine level code populates few
callbacks in the platform data.
This patch adds check and reuses platform_data if its valid, before
allocating a new one.
Yes, we had seen this long time ago and IIRC i prepared the patch
so
Acked-by: Giuseppe Cavallaro
Signed-off-by: Srinivas Kandagatla
---
.../net/ethernet/stmicro/stmmac/stmmac_platform.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 1d3780f..5907920 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -92,8 +92,10 @@ static int stmmac_pltfr_probe(struct platform_device *pdev)
if (IS_ERR(addr))
return PTR_ERR(addr);
+ plat_dat = pdev->dev.platform_data;
if (pdev->dev.of_node) {
- plat_dat = devm_kzalloc(&pdev->dev,
+ if (!plat_dat)
+ plat_dat = devm_kzalloc(&pdev->dev,
sizeof(struct plat_stmmacenet_data),
GFP_KERNEL);
if (!plat_dat) {
@@ -106,8 +108,6 @@ static int stmmac_pltfr_probe(struct platform_device *pdev)
pr_err("%s: main dt probe failed", __func__);
return ret;
}
- } else {
- plat_dat = pdev->dev.platform_data;
}
/* Custom initialisation (if needed)*/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 1/3] dt:net:stmmac: Allocate platform data only if its NULL.
On 7/1/2013 1:43 PM, Srinivas KANDAGATLA wrote:
From: Srinivas Kandagatla
In some DT use-cases platform data might be already allocated and passed
via AUXDATA. These are the cases where machine level code populates few
callbacks in the platform data.
This patch adds check and reuses platform_data if its valid, before
allocating a new one.
Ye, we had seen this long time ago and IIRC i prepared the patch
so
Acked-by: Giuseppe Cavallaro
Signed-off-by: Srinivas Kandagatla
---
.../net/ethernet/stmicro/stmmac/stmmac_platform.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 1d3780f..5907920 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -92,8 +92,10 @@ static int stmmac_pltfr_probe(struct platform_device *pdev)
if (IS_ERR(addr))
return PTR_ERR(addr);
+ plat_dat = pdev->dev.platform_data;
if (pdev->dev.of_node) {
- plat_dat = devm_kzalloc(&pdev->dev,
+ if (!plat_dat)
+ plat_dat = devm_kzalloc(&pdev->dev,
sizeof(struct plat_stmmacenet_data),
GFP_KERNEL);
if (!plat_dat) {
@@ -106,8 +108,6 @@ static int stmmac_pltfr_probe(struct platform_device *pdev)
pr_err("%s: main dt probe failed", __func__);
return ret;
}
- } else {
- plat_dat = pdev->dev.platform_data;
}
/* Custom initialisation (if needed)*/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 2/3] dt:net:stmmac: Add support to dwmac version 3.610 and 3.710
On 7/2/2013 8:42 AM, Srinivas KANDAGATLA wrote: Are you happy with the setting pmt based on compatible string or do you think passing pmt as another property to device tree makes more sense? I prefer to pass pmt as another property but indeed this is not a big problem because all the new chips have the HW cap. register to fix at run-time the driver capability. This field, as others, was really useful on old mac generations where sometime the PMT was synthesized, sometime not. The code should be safe enough because if, for example, we have a new GMAC but w/o the extended module for PMT, so at probing time the driver will fix all by looking at the HW cap register and it will be never able to do WoL. ciao peppe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 1/3] net: stmmac: add gmac autoneg set for SGMII, TBI, and RTBI
On 3/6/2013 5:13 AM, Byungho An wrote: Hello Peppe, If you agree, you could also re-send *all* to the mailing list to be finally reviewed. Anyway, in my opinion, you can take them in your tree for now with my tested-by if you want. Of course, I'll implement additional patches as you requested on top of them for remained stuff such as SGMII, TBI, ethtool and so on. I think those should be separated for each purpose and we can add and modify after those two patches. Ok Byungho, I'm preparing a new update for the stmmac that will also include the initial support for SGMII and RGMII. Thx to have tested it! Obviously on top of these patches, feel free to add further code. TBI and RTBI are not supported yet. P.S. in this update I've also added the ethtool missing stuff ;-) Peppe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 1/3] net: stmmac: add gmac autoneg set for SGMII, TBI, and RTBI
Hello Byungho
On 1/18/2013 6:41 PM, Byungho An wrote:
Hello Peppe,
On 1/15/2013 11:28 PM, Giuseppe CAVALLARO write:
On 1/15/2013 10:45 PM, Byungho An wrote:
This patch adds gmac autoneg set function for SGMII, TBI, or RTBI
interface. In case of PHY's autoneg is set, gmac's autoneg enable bit
should set. After checking phy's autoneg if phydev's autoneg is '1'
gmac's ANE bit set for those interface.
Sorry I've some doubts about these patches.
Firstly if the MAC is able to manage RGMII/SGMII etc this should be
verified
by looking at the HW cap register: i.e. PCS bit.
(I have no HW that support this so I cannot do any tests).
I agree with you and actually I tried to use a PCS bit previously.
(PCS bit indicates TBI, SGMII, or RTBI PHY interface)
But I was confused which one I should use among PSC, ACTPHYIF or phydev to
recognize the interface.
At this time, I want to add auto-negotiation enable because sgmii interface
is not working without ANE using PCS bit(in H/W feature register).
really strange, from the synopsys databook we should only look at the RO
bit in the HW cap reg just to understand if the feature is supported.
In case of this feature is actually supported then the driver could manage
everything bypassing the MDIO.
IMO, we could not need to call the stmmac_phy_init and we should not use
the PHYLIB.
I mean if we have the PCS module we could have a minimal support to get
link status, restart ANE etc w/o using at all the PHYLIB (so w/o touching
the
PHY regs via the MDIO/MDC).
Yes. For example SGMII/RGMII/SMII Status Register is useful to know status
so we can use this register to manage status of SGMII/RGMII/SMII
It could also be useful to complete the support with the RGMII... no
extra effort should be needed while adding SGMII if you look at the
core registers.
If you add the RGMII on some platforms we could guarantee to manage
the fix_mac_speed (see stmmac doc).
Unfortunately I have only the SGMII.
no problem, I'll complete it by my hand later.
Looking at the other your patches, the ethtool support is not completed. I
expected to restart ANE, get/set link property etc.
What is link property? It means link up, speed and duplex mode.
Are there anything else?
I think get link property is already working using ethtool.
In case of SGMII/RGMII/SMII, I think we can use SGMII/RGMII/SMII Status
Register for link status.
I have a question regarding it.
In the mainline code, there is hardcode interrupt mask in
dwmac1000_core_init function.
When I try to get interrupt for link change, interrupt is not occurred
because of this mask.
Can we modify that?
yes you can. I had wrote an initial patch that started doing something.
I have tested it on my boards and I can send it to the mailing list to
be reviewed. Maybe you can build your patch on top of it.
Also pay attention to properly treat EEE. Maybe, as first stage we should
disable the feature in this case. We will see it later.
The question is that we could not be able to use some extra features that
currently need to dialog more with the PHY device. I mean what we actually
do by using PHYLIB.
OK. As I understood, using gmac register instead of phydev or phylib...
I agree. In my opinion gmac and phy communicate using mdio each other, after
that gmac can get updated status.
yep, this is the point :-)
Signed-off-by: Byungho An
---
drivers/net/ethernet/stmicro/stmmac/common.h |1 +
drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 11
+++
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c|9 +
3 files changed, 21 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h
b/drivers/net/ethernet/stmicro/stmmac/common.h
index 186d148..72ba769 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -344,6 +344,7 @@ struct stmmac_ops {
void (*reset_eee_mode) (void __iomem *ioaddr);
void (*set_eee_timer) (void __iomem *ioaddr, int ls, int tw);
void (*set_eee_pls) (void __iomem *ioaddr, int link);
+ void (*set_autoneg) (void __iomem *ioaddr);
};
struct mac_link {
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index bfe0226..a0737b39 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -297,6 +297,16 @@ static void dwmac1000_set_eee_timer(void
__iomem
*ioaddr, int ls, int tw)
writel(value, ioaddr + LPI_TIMER_CTRL);
}
+static void dwmac1000_set_autoneg(void __iomem *ioaddr) {
+ u32 value;
+
+ value = readl(ioaddr + GMAC_AN_CTRL);
+ value |= 0x1000;
pls use define instead of raw values ... see below.
+ writel(value, ioaddr + GMAC_AN_CTRL); }
+
+
static const struct stmmac_ops dwmac1000_ops
Re: [PATCH] Prevent interrupt loop with DWMAC MMC RX IPC Counter
Hello Christian
On 2/15/2013 2:15 PM, Christian Ruppert wrote:
If the DesignWare MAC is synthesised with MMC RX IPC Counter, an unmanaged
and unacknowledged interrupt is generated after some time of operation. To
my knowledge there is no way to autodetect this configuration.
This patch adds a Kconfig option to tell the driver about the counter which
in turn masks the undesired interrupts.
Signed-off-by: Christian Ruppert
---
drivers/net/ethernet/stmicro/stmmac/Kconfig|8
drivers/net/ethernet/stmicro/stmmac/mmc_core.c |3 +++
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig
b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 1164930..60e5130 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -71,5 +71,13 @@ config STMMAC_CHAINED
endchoice
+config STMMAC_RX_IPC_CTRS
+ bool "MMC Receive IPC Counters enabled"
+ depends on STMMAC_ETH
+ default n
+ ---help---
+ Select this option in case MMC Receive IPC counters were enabled at
+ synthesis time of the block. If this option is not set correctly,
+ system might hang after a certain amount of time.
endif
diff --git a/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
b/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
index 0c74a70..ae877ee 100644
--- a/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
@@ -149,6 +149,9 @@ void dwmac_mmc_intr_all_mask(void __iomem *ioaddr)
{
writel(MMC_DEFAULT_MASK, ioaddr + MMC_RX_INTR_MASK);
writel(MMC_DEFAULT_MASK, ioaddr + MMC_TX_INTR_MASK);
+#ifdef CONFIG_STMMAC_RX_IPC_CTRS
+ writel(MMC_DEFAULT_MASK, ioaddr + MMC_RX_IPC_INTR_MASK);
+#endif
your fix makes sense to me; I have never faced this problem because the
MMC RX IPC Counter is not synthesised on the GMAC chip I used.
Anyway all mmc interrupts are not managed by defsign so I only ask you
to remove the Kconfig option and add the writel in the
dwmac_mmc_intr_all_mask.
peppe
}
/* This reads the MAC core counters (if actaully supported).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Prevent interrupt loop with DWMAC MMC RX IPC Counter
On 2/15/2013 3:58 PM, Christian Ruppert wrote:
If the DesignWare MAC is synthesised with MMC RX IPC Counter, an unmanaged
and unacknowledged interrupt is generated after some time of operation.
This patch masks the undesired interrupts.
Signed-off-by: Christian Ruppert
Acked-by: Giuseppe Cavallaro
---
drivers/net/ethernet/stmicro/stmmac/mmc_core.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
b/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
index 0c74a70..50617c5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
@@ -149,6 +149,7 @@ void dwmac_mmc_intr_all_mask(void __iomem *ioaddr)
{
writel(MMC_DEFAULT_MASK, ioaddr + MMC_RX_INTR_MASK);
writel(MMC_DEFAULT_MASK, ioaddr + MMC_TX_INTR_MASK);
+ writel(MMC_DEFAULT_MASK, ioaddr + MMC_RX_IPC_INTR_MASK);
}
/* This reads the MAC core counters (if actaully supported).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent interrupt loop with DWMAC MMC RX IPC Counter
On 2/15/2013 3:48 PM, Christian Ruppert wrote:
Hello Guiseppe,
Thanks for the feedback. I'll send a new patch shortly which
unconditionally masks the interrupts as you suggest. The mask register
does not exist in DWMACs without RX IPC counters, however, and I have no
way of testing if accessing this register nevertheless generates a bus
error. Do you have hardware to verify if everything works fine even
without RX IPC counters before integrating the patch?
Tests done on two boards and no issue on my side
peppe
Greetings,
Christian
On Fri, Feb 15, 2013 at 02:46:16PM +0100, Giuseppe CAVALLARO wrote:
Hello Christian
On 2/15/2013 2:15 PM, Christian Ruppert wrote:
If the DesignWare MAC is synthesised with MMC RX IPC Counter, an unmanaged
and unacknowledged interrupt is generated after some time of operation. To
my knowledge there is no way to autodetect this configuration.
This patch adds a Kconfig option to tell the driver about the counter which
in turn masks the undesired interrupts.
Signed-off-by: Christian Ruppert
---
drivers/net/ethernet/stmicro/stmmac/Kconfig|8
drivers/net/ethernet/stmicro/stmmac/mmc_core.c |3 +++
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig
b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 1164930..60e5130 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -71,5 +71,13 @@ config STMMAC_CHAINED
endchoice
+config STMMAC_RX_IPC_CTRS
+ bool "MMC Receive IPC Counters enabled"
+ depends on STMMAC_ETH
+ default n
+ ---help---
+ Select this option in case MMC Receive IPC counters were enabled at
+ synthesis time of the block. If this option is not set correctly,
+ system might hang after a certain amount of time.
endif
diff --git a/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
b/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
index 0c74a70..ae877ee 100644
--- a/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
@@ -149,6 +149,9 @@ void dwmac_mmc_intr_all_mask(void __iomem *ioaddr)
{
writel(MMC_DEFAULT_MASK, ioaddr + MMC_RX_INTR_MASK);
writel(MMC_DEFAULT_MASK, ioaddr + MMC_TX_INTR_MASK);
+#ifdef CONFIG_STMMAC_RX_IPC_CTRS
+ writel(MMC_DEFAULT_MASK, ioaddr + MMC_RX_IPC_INTR_MASK);
+#endif
your fix makes sense to me; I have never faced this problem because the
MMC RX IPC Counter is not synthesised on the GMAC chip I used.
Anyway all mmc interrupts are not managed by defsign so I only ask
you to remove the Kconfig option and add the writel in the
dwmac_mmc_intr_all_mask.
peppe
}
/* This reads the MAC core counters (if actaully supported).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] net: stmmac: change GMAC control register for SGMII
Hello An
On 11/23/2012 10:04 AM, Byungho An wrote:
This patch changes GMAC control register (TC(Transmit
Configuration) and PS(Port Selection) bit for SGMII.
In case of SGMII, TC bit is '1' and PS bit is 0.
I was looking at this too. In particular, I was working on the rgmii
interrupt so I guess we could improve this part together.
First my note is that I would like to have this kind of code never
placed in the stmmac_main. It should stay in the core part.
Also I 'd like to avoid the Kconfig option where possible.
At any rate, I'll come back with further details soon.
BR,
Peppe
Signed-off-by: Byungho An
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index c6cdbc4..a719c87 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1037,6 +1037,7 @@ static int stmmac_open(struct net_device *dev)
{
struct stmmac_priv *priv = netdev_priv(dev);
int ret;
+ u32 value;
#ifdef CONFIG_STMMAC_TIMER
priv->tm = kzalloc(sizeof(struct stmmac_timer *), GFP_KERNEL);
@@ -1088,6 +1089,15 @@ static int stmmac_open(struct net_device *dev)
/* Initialize the MAC Core */
priv->hw->mac->core_init(priv->ioaddr);
+ if (priv->phydev->interface == PHY_INTERFACE_MODE_SGMII) {
+ value = readl(priv->ioaddr);
+ /* GMAC_CONTROL_TC : transmit config in RGMII/SGMII */
+ value |= 0x100;
+ /* GMAC_CONTROL_PS : Port Selection for GMII */
+ value &= ~(0x8000);
+ writel(value, priv->ioaddr);
+ }
+
/* Request the IRQ lines */
ret = request_irq(dev->irq, stmmac_interrupt,
IRQF_SHARED, dev->name, dev);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] net: stmmac: change GMAC control register for SGMII
On 11/23/2012 10:04 AM, Byungho An wrote:
This patch changes GMAC control register (TC(Transmit
Configuration) and PS(Port Selection) bit for SGMII.
In case of SGMII, TC bit is '1' and PS bit is 0.
IMO this new support that should be released for net-next and further
effort is actually needed.
The availability of the PCS registers is given by looking at the HW
feature register. In fact, these are optional registers.
I don't want to break the compatibility with old chips.
I do not see why we have to use Kconfig macro to select ANE etc
(as you do in your patches).
The driver could directly manage the phy device by itself if possible
and the stmmac_init_phy should be reworked.
There are several things that need to be implemented. For example:
The ISR (e.g. priv->hw->mac->host_irq_status) should be able to manage
these new interrupts.
The code has to be able to maintain the user interface.
For example if you want to enable ANE or manage Advertisement caps.
Signed-off-by: Byungho An
---
[snip]
+ if (priv->phydev->interface == PHY_INTERFACE_MODE_SGMII) {
+ value = readl(priv->ioaddr);
+ /* GMAC_CONTROL_TC : transmit config in RGMII/SGMII */
+ value |= 0x100;
+ /* GMAC_CONTROL_PS : Port Selection for GMII */
+ value &= ~(0x8000);
+ writel(value, priv->ioaddr);
+ }
+
This parts of code have to be moved in
drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
Pls, do not use value |= 0x100 but provide the appropriate defines.
/* Request the IRQ lines */
ret = request_irq(dev->irq, stmmac_interrupt,
IRQF_SHARED, dev->name, dev);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 1/3] net: stmmac: add gmac autoneg set for SGMII, TBI, and RTBI
Hello Byungho,
On 1/15/2013 10:45 PM, Byungho An wrote:
This patch adds gmac autoneg set function for SGMII, TBI,
or RTBI interface. In case of PHY's autoneg is set, gmac's
autoneg enable bit should set. After checking phy's autoneg
if phydev's autoneg is '1' gmac's ANE bit set for those
interface.
Sorry I've some doubts about these patches.
Firstly if the MAC is able to manage RGMII/SGMII etc this should be
verified by looking at the HW cap register: i.e. PCS bit.
(I have no HW that support this so I cannot do any tests).
In case of this feature is actually supported then the driver could
manage everything bypassing the MDIO.
IMO, we could not need to call the stmmac_phy_init and we should not
use the PHYLIB.
I mean if we have the PCS module we could have a minimal support to get
link status, restart ANE etc w/o using at all the PHYLIB (so w/o
touching the PHY regs via the MDIO/MDC).
It could also be useful to complete the support with the RGMII... no
extra effort should be needed while adding SGMII if you look at the
core registers.
If you add the RGMII on some platforms we could guarantee to manage
the fix_mac_speed (see stmmac doc).
Looking at the other your patches, the ethtool support is not
completed. I expected to restart ANE, get/set link property etc.
Also pay attention to properly treat EEE. Maybe, as first stage we
should disable the feature in this case. We will see it later.
The question is that we could not be able to use some extra features
that currently need to dialog more with the PHY device. I mean what we
actually do by using PHYLIB.
Signed-off-by: Byungho An
---
drivers/net/ethernet/stmicro/stmmac/common.h |1 +
drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 11 +++
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c|9 +
3 files changed, 21 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h
b/drivers/net/ethernet/stmicro/stmmac/common.h
index 186d148..72ba769 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -344,6 +344,7 @@ struct stmmac_ops {
void (*reset_eee_mode) (void __iomem *ioaddr);
void (*set_eee_timer) (void __iomem *ioaddr, int ls, int tw);
void (*set_eee_pls) (void __iomem *ioaddr, int link);
+ void (*set_autoneg) (void __iomem *ioaddr);
};
struct mac_link {
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index bfe0226..a0737b39 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -297,6 +297,16 @@ static void dwmac1000_set_eee_timer(void __iomem
*ioaddr, int ls, int tw)
writel(value, ioaddr + LPI_TIMER_CTRL);
}
+static void dwmac1000_set_autoneg(void __iomem *ioaddr)
+{
+ u32 value;
+
+ value = readl(ioaddr + GMAC_AN_CTRL);
+ value |= 0x1000;
pls use define instead of raw values ... see below.
+ writel(value, ioaddr + GMAC_AN_CTRL);
+}
+
+
static const struct stmmac_ops dwmac1000_ops = {
.core_init = dwmac1000_core_init,
.rx_ipc = dwmac1000_rx_ipc_enable,
@@ -311,6 +321,7 @@ static const struct stmmac_ops dwmac1000_ops = {
.reset_eee_mode = dwmac1000_reset_eee_mode,
.set_eee_timer = dwmac1000_set_eee_timer,
.set_eee_pls = dwmac1000_set_eee_pls,
+ .set_autoneg = dwmac1000_set_autoneg,
};
struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index f07c061..3e28934 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1007,6 +1007,7 @@ static int stmmac_open(struct net_device *dev)
{
struct stmmac_priv *priv = netdev_priv(dev);
int ret;
+ int interface = priv->plat->interface;
clk_prepare_enable(priv->stmmac_clk);
@@ -1041,6 +1042,14 @@ static int stmmac_open(struct net_device *dev)
/* Initialize the MAC Core */
priv->hw->mac->core_init(priv->ioaddr);
+ /* If phy autoneg is on, set gmac autoneg for SGMII, TBI and RTBI*/
+ if (interface == PHY_INTERFACE_MODE_SGMII ||
+ interface == PHY_INTERFACE_MODE_TBI ||
+ interface == PHY_INTERFACE_MODE_RTBI) {
+ if (priv->phydev->autoneg)
+ priv->hw->mac->set_autoneg(priv->ioaddr);
+ }
we could use the following instead of priv->hw->mac->set_autoneg:
static void dwmac1000_ctrl_ane(void __iomem *ioaddr, bool restart)
{
int value = GMAC_CTRL_ANE_EN;
if (restart)
value |= GMAC_CTRL_ANE_RESTART;
writel(value, ioaddr +GMAC_AN_CTRL);
}
where we should defines all the missing macros for the registers 48, 49 ...
/* RGMI/SGMII defines */
#define GMAC_CTRL_ANE_SGMII_RAL (1
Re: [PATCH 1/3] net: stmac: add gmac autonet set for SGMII, TBI, and RTBI
Hello Byungho
On 1/9/2013 12:35 AM, Byungho An wrote:
This patch adds gmac autoneg set function for SGMII, TBI,
and RTBI interface. In case of PHY's autoneg is set, gmac's
autoneg enable bit should set. After checking phy's autoneg
if phydev's autoneg is '1' gmac's ANE bit set for those
interface.
I suppose I have to not look at this patch but I have to directly look
at the series:
[PATCH v2 1/3] net: stmac: add gmac autonet set for SGMII, TBI, and RTBI
[PATCH v2 2/3] net: stmmac: add autoneg complete irq
[PATCH v2 3/3] net: stmmac: add gmac autonego set for ethtool support
At any rate, I'm looking at them and they actually sound better than the
previous ones.
Pls use stmmac instead of stmac.
Also these patches add a new functionality and, IMO, they should be done
for net-next. In this case, pls verify if the patches are for this
branch and add in the subject net-next.
I'll come back with further details asap.
BR
Peppe
Signed-off-by: Byungho An
---
drivers/net/ethernet/stmicro/stmmac/common.h |1 +
drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 11 +++
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c|9 +
3 files changed, 21 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h
b/drivers/net/ethernet/stmicro/stmmac/common.h
index 186d148..72ba769 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -344,6 +344,7 @@ struct stmmac_ops {
void (*reset_eee_mode) (void __iomem *ioaddr);
void (*set_eee_timer) (void __iomem *ioaddr, int ls, int tw);
void (*set_eee_pls) (void __iomem *ioaddr, int link);
+ void (*set_autoneg) (void __iomem *ioaddr);
};
struct mac_link {
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index bfe0226..a0737b39 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -297,6 +297,16 @@ static void dwmac1000_set_eee_timer(void __iomem
*ioaddr, int ls, int tw)
writel(value, ioaddr + LPI_TIMER_CTRL);
}
+static void dwmac1000_set_autoneg(void __iomem *ioaddr)
+{
+ u32 value;
+
+ value = readl(ioaddr + GMAC_AN_CTRL);
+ value |= 0x1000;
+ writel(value, ioaddr + GMAC_AN_CTRL);
+}
+
+
static const struct stmmac_ops dwmac1000_ops = {
.core_init = dwmac1000_core_init,
.rx_ipc = dwmac1000_rx_ipc_enable,
@@ -311,6 +321,7 @@ static const struct stmmac_ops dwmac1000_ops = {
.reset_eee_mode = dwmac1000_reset_eee_mode,
.set_eee_timer = dwmac1000_set_eee_timer,
.set_eee_pls = dwmac1000_set_eee_pls,
+ .set_autoneg = dwmac1000_set_autoneg,
};
struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index f07c061..3e28934 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1007,6 +1007,7 @@ static int stmmac_open(struct net_device *dev)
{
struct stmmac_priv *priv = netdev_priv(dev);
int ret;
+ int interface = priv->plat->interface;
clk_prepare_enable(priv->stmmac_clk);
@@ -1041,6 +1042,14 @@ static int stmmac_open(struct net_device *dev)
/* Initialize the MAC Core */
priv->hw->mac->core_init(priv->ioaddr);
+ /* If phy autoneg is on, set gmac autoneg for SGMII, TBI and RTBI*/
+ if((interface == PHY_INTERFACE_MODE_SGMII) ||
+ (interface == PHY_INTERFACE_MODE_TBI) ||
+ (interface == PHY_INTERFACE_MODE_RTBI)) {
+ if (priv->phydev->autoneg)
+ priv->hw->mac->set_autoneg(priv->ioaddr);
+ }
+
/* Request the IRQ lines */
ret = request_irq(dev->irq, stmmac_interrupt,
IRQF_SHARED, dev->name, dev);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 2/2] bindings: net: stmmac: Add documentation for TSN parameters
Hello On 10/27/2017 11:05 AM, Jose Abreu wrote: I think we should take advantage of the fact that this is working and ready to be merged. Its just HW configuration but maybe it can serve as momentum for other drivers to also integrate this? Let me propose to have it now in the next-next. This support is for dwmac 5.x so no disturb for the common driver APIs and there is no risk to have regressions, IMO. IIUC, you already tested it on a real environment that sounds to be very good progress. Regards Peppe Best Regards, Jose Miguel Abreu
Re: [PATCH net-next v2] net: stmmac: Fix reception of Broadcom switches tags
On 1/19/2018 12:12 AM, Florian Fainelli wrote:
Broadcom tags inserted by Broadcom switches put a 4 byte header after
the MAC SA and before the EtherType, which may look like some sort of 0
length LLC/SNAP packet (tcpdump and wireshark do think that way). With
ACS enabled in stmmac the packets were truncated to 8 bytes on
reception, whereas clearing this bit allowed normal reception to occur.
In order to make that possible, we need to pass a net_device argument to
the different core_init() functions and we are dependent on the Broadcom
tagger padding packets correctly (which it now does). To be as little
invasive as possible, this is only done for gmac1000 when the network
device is DSA-enabled (netdev_uses_dsa() returns true).
Signed-off-by: Florian Fainelli
Acked-by: Giuseppe Cavallaro
---
Changes in v2:
- fixed build failure in dwmac4_core.c
- updated dwmac100_core.c to also clear the ASTP bit
drivers/net/ethernet/stmicro/stmmac/common.h | 2 +-
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c| 3 ++-
drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 12 +++-
drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c | 15 +--
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c| 12 +++-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c| 2 +-
6 files changed, 39 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h
b/drivers/net/ethernet/stmicro/stmmac/common.h
index ce2ea2d491ac..2ffe76c0ff74 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -474,7 +474,7 @@ struct mac_device_info;
/* Helpers to program the MAC core */
struct stmmac_ops {
/* MAC core initialization */
- void (*core_init)(struct mac_device_info *hw, int mtu);
+ void (*core_init)(struct mac_device_info *hw, struct net_device *dev);
/* Enable the MAC RX/TX */
void (*set_mac)(void __iomem *ioaddr, bool enable);
/* Enable and verify that the IPC module is supported */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 9eb7f65d8000..a3fa65b1ca8e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -483,7 +483,8 @@ static int sun8i_dwmac_init(struct platform_device *pdev,
void *priv)
return 0;
}
-static void sun8i_dwmac_core_init(struct mac_device_info *hw, int mtu)
+static void sun8i_dwmac_core_init(struct mac_device_info *hw,
+ struct net_device *dev)
{
void __iomem *ioaddr = hw->pcsr;
u32 v;
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index 8a86340ff2d3..540d21786a43 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -25,18 +25,28 @@
#include
#include
#include
+#include
#include
#include "stmmac_pcs.h"
#include "dwmac1000.h"
-static void dwmac1000_core_init(struct mac_device_info *hw, int mtu)
+static void dwmac1000_core_init(struct mac_device_info *hw,
+ struct net_device *dev)
{
void __iomem *ioaddr = hw->pcsr;
u32 value = readl(ioaddr + GMAC_CONTROL);
+ int mtu = dev->mtu;
/* Configure GMAC core */
value |= GMAC_CORE_INIT;
+ /* Clear ACS bit because Ethernet switch tagging formats such as
+* Broadcom tags can look like invalid LLC/SNAP packets and cause the
+* hardware to truncate packets on reception.
+*/
+ if (netdev_uses_dsa(dev))
+ value &= ~GMAC_CONTROL_ACS;
+
if (mtu > 1500)
value |= GMAC_CONTROL_2K;
if (mtu > 2000)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
index 8ef517356313..91b23f9db31a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
@@ -25,15 +25,26 @@
***/
#include
+#include
#include
#include "dwmac100.h"
-static void dwmac100_core_init(struct mac_device_info *hw, int mtu)
+static void dwmac100_core_init(struct mac_device_info *hw,
+ struct net_device *dev)
{
void __iomem *ioaddr = hw->pcsr;
u32 value = readl(ioaddr + MAC_CONTROL);
- writel((value | MAC_CORE_INIT), ioaddr + MAC_CONTROL);
+ value |= MAC_CORE_INIT;
+
+ /* Clear ASTP bit because Ethernet switch tagging formats such as
+* Broadcom tags can look like invalid LLC/SNAP packets and cause the
+* hardware to truncate packets on reception.
+*/
+
Re: [PATCH net-next] net: stmmac: Fix reception of Broadcom switches tags
Hi Florian
for gmac4.x and gmac3.x series the ACS bit is the Automatic Pad or CRC
Stripping, so the
core strips the Pad or FCS on frames if the value of the length field is
< 1536 bytes.
For MAC10-100 there is the Bit 8 (ASTP) of the reg0 that does the same
if len is < 46bytes.
In your patch I can just suggest to add a new field to strip the PAD/FCS
w/o passing the whole
netdev struct to the core_init. In the main driver, we could manage the
pad-strip feature (also
by using dt) or disable it in case of netdev_uses_dsa; then propagating
this setting to the core_init
or calling a new callback. What do you think?
Regards
Peppe
On 1/17/2018 12:25 AM, Florian Fainelli wrote:
Broadcom tags inserted by Broadcom switches put a 4 byte header after
the MAC SA and before the EtherType, which may look like some sort of 0
length LLC/SNAP packet (tcpdump and wireshark do think that way). With
ACS enabled in stmmac the packets were truncated to 8 bytes on
reception, whereas clearing this bit allowed normal reception to occur.
In order to make that possible, we need to pass a net_device argument to
the different core_init() functions and we are dependent on the Broadcom
tagger padding packets correctly (which it now does). To be as little
invasive as possible, this is only done for gmac1000 when the network
device is DSA-enabled (netdev_uses_dsa() returns true).
Signed-off-by: Florian Fainelli
---
drivers/net/ethernet/stmicro/stmmac/common.h | 2 +-
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c| 3 ++-
drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 12 +++-
drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c | 3 ++-
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c| 11 ++-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c| 2 +-
6 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h
b/drivers/net/ethernet/stmicro/stmmac/common.h
index ce2ea2d491ac..2ffe76c0ff74 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -474,7 +474,7 @@ struct mac_device_info;
/* Helpers to program the MAC core */
struct stmmac_ops {
/* MAC core initialization */
- void (*core_init)(struct mac_device_info *hw, int mtu);
+ void (*core_init)(struct mac_device_info *hw, struct net_device *dev);
/* Enable the MAC RX/TX */
void (*set_mac)(void __iomem *ioaddr, bool enable);
/* Enable and verify that the IPC module is supported */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 9eb7f65d8000..a3fa65b1ca8e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -483,7 +483,8 @@ static int sun8i_dwmac_init(struct platform_device *pdev,
void *priv)
return 0;
}
-static void sun8i_dwmac_core_init(struct mac_device_info *hw, int mtu)
+static void sun8i_dwmac_core_init(struct mac_device_info *hw,
+ struct net_device *dev)
{
void __iomem *ioaddr = hw->pcsr;
u32 v;
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index 8a86340ff2d3..540d21786a43 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -25,18 +25,28 @@
#include
#include
#include
+#include
#include
#include "stmmac_pcs.h"
#include "dwmac1000.h"
-static void dwmac1000_core_init(struct mac_device_info *hw, int mtu)
+static void dwmac1000_core_init(struct mac_device_info *hw,
+ struct net_device *dev)
{
void __iomem *ioaddr = hw->pcsr;
u32 value = readl(ioaddr + GMAC_CONTROL);
+ int mtu = dev->mtu;
/* Configure GMAC core */
value |= GMAC_CORE_INIT;
+ /* Clear ACS bit because Ethernet switch tagging formats such as
+* Broadcom tags can look like invalid LLC/SNAP packets and cause the
+* hardware to truncate packets on reception.
+*/
+ if (netdev_uses_dsa(dev))
+ value &= ~GMAC_CONTROL_ACS;
+
if (mtu > 1500)
value |= GMAC_CONTROL_2K;
if (mtu > 2000)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
index 8ef517356313..c1ee427c42cb 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
@@ -28,7 +28,8 @@
#include
#include "dwmac100.h"
-static void dwmac100_core_init(struct mac_device_info *hw, int mtu)
+static void dwmac100_core_init(struct mac_device_info *hw,
+ struct net_device *dev)
{
void __iomem *ioaddr = hw->pcsr;
u32 value = readl(ioaddr + MAC_CONTROL);
diff --
Re: [PATCH net 0/5] stmmac: Correct flow control configuration
Hi Vince On 4/15/2015 6:17 PM, Vince Bridgers wrote: This series of patches corrects flow control configuration for the Synopsys GMAC driver. Thx for these patches For the series Acked-by: Giuseppe Cavallaro peppe Flow control is configured based on a configurable receive fifo size. If less than 4Kbytes flow control is left disabled and a warning is presented. If a receive fifo size is not specified, flow control is left disabled to maintain current behavior. Unicast pause detection was disabled, but is now enabled. The pause time was modified to be maximum time per a XON/XOFF flow control mode of operation. This patch was tested on an Altera Cyclone 5 and an Altera Arria 10 devkit, and verified that flow control operates as expected when enabled. Please consider this series for inclusion so that flow control will function as expected for the Synopsys GMAC controller. Vince Bridgers (5): stmmac: Add properties for transmit and receive fifo sizes stmmac: Add defines and documentation for enabling flow control stmmac: Read tx-fifo-depth and rx-fifo-depth from the devicetree stmmac: Enable unicast pause frame detect in GMAC Register 6 stmmac: Configure Flow Control to work correctly based on rxfifo size Documentation/devicetree/bindings/net/ethernet.txt | 6 +++ Documentation/devicetree/bindings/net/stmmac.txt | 4 ++ drivers/net/ethernet/stmicro/stmmac/common.h | 5 ++- drivers/net/ethernet/stmicro/stmmac/dwmac1000.h| 51 ++ .../net/ethernet/stmicro/stmmac/dwmac1000_core.c | 5 ++- .../net/ethernet/stmicro/stmmac/dwmac1000_dma.c| 26 ++- drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c | 2 +- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 16 --- .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 4 ++ include/linux/stmmac.h | 2 + 10 files changed, 111 insertions(+), 10 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] net: stmmac: keep RXC running in LPI mode to avoid system overload
Hello Romain On 10/13/2013 10:02 PM, Romain Baeriswyl wrote: Hello Guiseppe, Thanks for your answer. Please find below some details and answers. In order to avoid system overload, the clock RXC from the Phy should not be stopped when in LPI mode. With the RTL8211E PHY which support EEE mode and with Apple Airport Extreme that supports it also, the kernel get frozen as soon as some Ethernet transfers are hmm, I have a board with this transceiver so I could do some tests this could take a while, unfortunately. on-going. System seems to be overloaded with too many interrupts. The 'top' command reports often around ~80% irq. do you mean lpi mac interrupts? By disabling the LPI mode with ethtool --set-eee eth0 eee off, the interrupt overload remains. Both counters irq_rx_path_in_lpi_mode_n and irq_rx_path_exit_lpi_mode_n continue to run meaning the PHY continue to put the RX path in LPI mode. Only way I found to get ride of the overload is to keep the RX_CLK running in LPI mode. In this configuration, the RX link still continue to go in LPI mode and the two above counters continue to run. By letting the RXC clock running even in LPI mode as proposed below, the issue seems solved. Is it the right way to proceed? For EEE capability, RX_CLK may be halted for this reason i used it as default in the stmmac and never seen your issue. What is the power impact to not stop RXC in LPI mode? I can point you to "22.2.2.8a Receive direction LPI transition" in IEEE802-3az... where is it reported that the PHY halt the RX_CLK in LPI mode. Actually the PHY "may" stop RX_CLK. Another option it could be add a new parameter to enable/disable it. We can decide a parameter for the stmmac or something for ethtool. May I suspect some issues on your HW? or disable it with ethtool Yes, it could be HW issue. It would be very useful if you could reproduce the setup using a SoC with "DesignWare Cores Ethernet MAC" core, the RTL8211E PHY and an Apple Airport Extreme. The issue could well be between the controller and the PHY. Which Ethernet switch or router did you use to test the EEE mode? when I tested EEE I connected with P2P two STi boards. You can test it too. I may try these equipments as well. peppe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/10] ARM: dts: sun7i: cubietruck: Enable the GMAC
On 12/7/2013 2:57 AM, Florian Fainelli wrote:
2013/12/6 Chen-Yu Tsai :
On Sat, Dec 7, 2013 at 5:09 AM, Florian Fainelli wrote:
2013/12/6 Chen-Yu Tsai :
The CubieTruck uses the GMAC with an RGMII phy.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
index 8a1009d..af212a2 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
@@ -33,6 +33,14 @@
pinctrl-0 = <&uart0_pins_a>;
status = "okay";
};
+
+ gmac: ethernet@01c5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac_pins_rgmii>;
+ snps,phy-addr = <1>;
What is this snps,phy-addr property? Why is not a standard device tree
node for an Ethernet PHY node used?
This property is implemented by stmmac and documented in the DT
bindings. stmmac has not been updated to use Ethernet PHY nodes.
This driver property should be removed and deprecated since there is
an ePAPR standardized Ethernet PHY node. What I am worried here is the
loss of information, the standard Ethernet DT node allows to specify
much more information (clause, maximum speed, compatible string
etc...).
yes Florian you are right and I have already started updating the
driver. I do not sure that I'll be able to send all the patches soon
but for sure I can re-base them.
Removing this property will not affect the function of the driver.
The driver probes its MDIO bus and selects the lowest available
address if not specified.
So if this is just giving the driver a hint on where to probe for a
PHY on the MDIO bus, then let's drop it and use the standard DT node
no?
+ phy-mode = "rgmii";
Especially since you use the relatively standard "phy-mode" property here?
Used as specified in stmmac DT bindings.
That one is kind of okay because of_get_phy_mode() knows about it,
even though ePAPR states this should be "phy-connection-type", so I am
okay with keeping that one because current practice and helpers are
here.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: stmmac: fix stmmac_pci_probe failed when CONFIG_HAVE_CLK is selected
On 9/18/2014 2:34 PM, Kweh Hock Leong wrote:
From: "Kweh, Hock Leong"
When the CONFIG_HAVE_CLK is selected for the system, the stmmac_pci_probe
will fail with dmesg:
[2.167225] stmmaceth :00:14.6: enabling device ( -> 0002)
[2.178267] stmmaceth :00:14.6: enabling bus mastering
[2.178436] stmmaceth :00:14.6: irq 24 for MSI/MSI-X
[2.178703] stmmaceth :00:14.6: stmmac_dvr_probe: warning: cannot
get CSR clock
[2.186503] stmmac_pci_probe: main driver probe failed
[2.194003] stmmaceth :00:14.6: disabling bus mastering
[2.196473] stmmaceth: probe of :00:14.6 failed with error -2
This patch fix the issue by breaking the dependency to devm_clk_get()
as the CSR clock can be obtained at priv->plat->clk_csr from pci driver.
Reported-by: Tobias Klausmann
Signed-off-by: Kweh, Hock Leong
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 08addd6..ea3859a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2714,10 +2714,15 @@ struct stmmac_priv *stmmac_dvr_probe(struct device
*device,
priv->stmmac_clk = devm_clk_get(priv->device, STMMAC_RESOURCE_NAME);
if (IS_ERR(priv->stmmac_clk)) {
- dev_warn(priv->device, "%s: warning: cannot get CSR clock\n",
Hmm I am not sure this is the right fix. The driver has to fail if the
main clock is not found. Indeed dev_warn has to be changed in dev_err.
Take a look at Documentation/networking/stmmac.txt but I will post some
patch to improve the documentation adding further detail for clocks too.
The the logic behind the code is that the CSR clock will be set at
runtime if in case of priv->plat->clk_csr ==0 or it will be forced to
a fixed value if passed from the platform instead of.
IIRC This was required on some platforms time ago.
For sure the driver is designed to fail in case of no main clock is
found.
Peppe
-__func__);
- ret = PTR_ERR(priv->stmmac_clk);
- goto error_clk_get;
+ if (!priv->plat->clk_csr) {
+ dev_warn(priv->device,
+"%s: warning: cannot get CSR clock\n",
+__func__);
+ ret = PTR_ERR(priv->stmmac_clk);
+ goto error_clk_get;
+ } else {
+ priv->stmmac_clk = NULL;
+ }
}
clk_prepare_enable(priv->stmmac_clk);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: stmmac: fix stmmac_pci_probe failed when CONFIG_HAVE_CLK is selected
On 9/23/2014 3:16 AM, Kweh, Hock Leong wrote: -Original Message- From: David Miller [mailto:da...@davemloft.net] Sent: Tuesday, September 23, 2014 2:19 AM From: Kweh Hock Leong Date: Thu, 18 Sep 2014 20:34:10 +0800 Giuseppe, Kweh, where are we with this patch? We are discussing whether this is the correct fix to the issue. Below is the discussion log: Hmm I am not sure this is the right fix. The driver has to fail if the main clock is not found. Indeed dev_warn has to be changed in dev_err. Take a look at Documentation/networking/stmmac.txt but I will post some patch to improve the documentation adding further detail for clocks too. The the logic behind the code is that the CSR clock will be set at runtime if in case of priv->plat->clk_csr ==0 or it will be forced to a fixed value if passed from the platform instead of. IIRC This was required on some platforms time ago. For sure the driver is designed to fail in case of no main clock is found. Peppe Hi Peppe, I understand your point from the code below (at file stmmac_main.c line 2784): /* If a specific clk_csr value is passed from the platform * this means that the CSR Clock Range selection cannot be * changed at run-time and it is fixed. Viceversa the driver'll try to * set the MDC clock dynamically according to the csr actual * clock input. */ if (!priv->plat->clk_csr) stmmac_clk_csr_set(priv); else priv->clk_csr = priv->plat->clk_csr; I did search through the whole stmmac_main.c file and found that only stmmac_clk_csr_set() function is leveraging the priv->stmmac_clk params for it calculation. By the logic point of view, I do not need priv->stmmac_clk when I got priv->plat->clk_csr. With this thinking, I propose this fix as when the probe get priv->plat->clk_csr, it shouldn't fail if priv->stmmac_clk has the error value. Hi Peppe, Are you trying to tell that if there is a fix CSR clock value, but driver cannot obtain the clk from devm_clk_get() (even it is not in use), the driver should fail the probe? You have a case with this condition: HW allow SW to discover the STMMAC controller but HW/SW configures not to supply the CLOCK to STMMAC controller? My understanding to these priv->plat->clk_csr and priv->stmmac_clk is that 1st one is fixed and 2nd one is dynamic. When fixed value occurs, dynamic one would not be use. Do I understand this correctly? the logic is: the priv->stmmac_clk must be always provided from the platform then we have two cases: 1) if priv->plat->clk_csr is also passed then it will be adopt in the mdio functions to program the Reg4[5:2] This was required in the past IIRC on SPEAr platforms. 2) if priv->plat->clk_csr is not passed from the platform then the priv->clk_csr will be set according to the priv->stmmac_clk and always used in the mdio part. So IIUC now you are asking for not passing the priv->stmmac_clk and warning this event w/o failing. Why you cannot pass this clock? peppe Thanks. Regards, Wilson -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: net: stmmac glue layer for Amlogic Meson SoCs
On 9/20/2014 3:29 PM, Beniamino Galvani wrote:
Hi,
the Ethernet controller available in Amlogic Meson6 and Meson8 SoCs is
a Synopsys DesignWare MAC IP core, already supported by the stmmac
driver.
These patches add a glue layer to the driver for the platform-specific
settings required by the Amlogic variant.
This has been tested on a Amlogic S802 device with the initial Meson
support submitted by Carlo Caione [1].
patches look fine just a warning with checkpatch as shown below then
Acked-by: Giuseppe Cavallaro
[cavagiu@lxmcdt5 net.git]$ git-format-patch -2
0001-net-stmmac-add-Amlogic-Meson-glue-layer.patch
0002-net-stmmac-meson-document-device-tree-bindings.patch
[cavagiu@lxmcdt5 net.git]$ !./
./scripts/checkpatch.pl 000*
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#57:
new file mode 100644
WARNING: DT compatible string vendor "amlogic" appears un-documented --
check ./Documentation/devicetree/bindings/vendor-prefixes.txt
#152: FILE: drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:34:
+ { .compatible = "amlogic,meson6-dwmac", .data = &meson6_dwmac_data},
total: 0 errors, 2 warnings, 0 checks, 108 lines checked
0001-net-stmmac-add-Amlogic-Meson-glue-layer.patch has style problems,
please review.
If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#17:
new file mode 100644
total: 0 errors, 1 warnings, 25 lines checked
0002-net-stmmac-meson-document-device-tree-bindings.patch has style
problems, please review.
If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
[1] http://lwn.net/Articles/612000/
Beniamino Galvani (2):
net: stmmac: add Amlogic Meson glue layer
net: stmmac: meson: document device tree bindings
.../devicetree/bindings/net/meson-dwmac.txt| 25
drivers/net/ethernet/stmicro/stmmac/Kconfig| 10
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c | 67 ++
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 3 +
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 3 +
6 files changed, 109 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/meson-dwmac.txt
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: stmmac: fix stmmac_pci_probe failed when CONFIG_HAVE_CLK is selected
On 9/23/2014 9:03 AM, Kweh, Hock Leong wrote: -Original Message- From: Giuseppe CAVALLARO [mailto:peppe.cavall...@st.com] Sent: Tuesday, September 23, 2014 2:10 PM the logic is: the priv->stmmac_clk must be always provided from the platform then we have two cases: 1) if priv->plat->clk_csr is also passed then it will be adopt in the mdio functions to program the Reg4[5:2] This was required in the past IIRC on SPEAr platforms. 2) if priv->plat->clk_csr is not passed from the platform then the priv->clk_csr will be set according to the priv->stmmac_clk and always used in the mdio part. So IIUC now you are asking for not passing the priv->stmmac_clk and warning this event w/o failing. Why you cannot pass this clock? peppe Hi peppe, Appreciate for the explanation. Just to clarify that I am not asking not to pass in the priv->stmmac_clk. In fact, the fix will fail at case 2 if driver cannot obtain the priv->stmmac_clk, but just not the case 1. For case 1, seem like it does not require the stmmac_clk then I think it should be OK not to fail it when driver did not get stmmac_clk but have the clk_csr set. ok we can do that but this clock is also managed when the iface is down. Maybe it could be convenient to manage it for power consumption. What do you think? Anyway, I can change the fix by adding the clock registration APIs being call at the stmmac_pci.c probe there before calling stmmac_dvr_probe. By doing this, it created a dependency to the pci driver that must have CONFIG_HAVE_CLK to be turned on. Besides, I would need you guys to provide me information on other platforms about what is the best value to set? Can I just set to zero since the stmmac_pci driver is always using the priv->plat->clk_csr? Regards, Wilson -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: stmmac: fix stmmac_pci_probe failed when CONFIG_HAVE_CLK is selected
On 9/24/2014 12:48 PM, Kweh, Hock Leong wrote: -Original Message- From: Giuseppe CAVALLARO [mailto:peppe.cavall...@st.com] Sent: Wednesday, September 24, 2014 2:10 PM Hi peppe, Appreciate for the explanation. Just to clarify that I am not asking not to pass in the priv->stmmac_clk. In fact, the fix will fail at case 2 if driver cannot obtain the priv->stmmac_clk, but just not the case 1. For case 1, seem like it does not require the stmmac_clk then I think it should be OK not to fail it when driver did not get stmmac_clk but have the clk_csr set. ok we can do that but this clock is also managed when the iface is down. Maybe it could be convenient to manage it for power consumption. What do you think? Hi peppe, I don't really get what you mean here. Are you telling that you are OK with the fix? Or you are referring to the bottom idea which introduce clock registration APIs to stmmac_pci driver? I just meant that if no clock is passed then the probe doesn't fail and we can keep a dev_warn. Pls surround the code with a comment and repost the patch. Let me know and sorry for the delay on replying. peppe Regarding the power management, isn't this taking care by the PCI framework itself for the PCI devices / PCI cards? Sorry, may be would need you to provide a big picture to this. Thanks. :) Anyway, I can change the fix by adding the clock registration APIs being call at the stmmac_pci.c probe there before calling stmmac_dvr_probe. By doing this, it created a dependency to the pci driver that must have CONFIG_HAVE_CLK to be turned on. Besides, I would need you guys to provide me information on other platforms about what is the best value to set? Can I just set to zero since the stmmac_pci driver is always using the priv->plat->clk_csr? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: ethernet : stmicro: fixed power suspend and resume failure in stmmac driver
Hello Hao Liang
On 9/30/2014 7:55 AM, hliang1...@gmail.com wrote:
From: Hao Liang
This is the fix for a power management issue caused by suspend and resume
function in stmmac_main.c.
After enable CONFIG_DEBUG_ATOMIC_SLEEP which enable sleep-inside atomic section
checking, power
managemet can not work normally. Board couldn't wakeup successfully after
suspend. Command
"echo mem > /sys/power/state" suspend the board.
In suspend and resume function of stmmac driver, there are some sleep-inside
function in atomic section
created by spin lock. These functions will causes system warnings and wakeup
issue when enable
CONFIG_DEBUG_ATOMIC_SLEEP.
This bug was fixed by:
* replace some sleep function with non-sleep function
clk_disable_unprepare -> clk_disable ...
* decrease the atomic area created by spin lock function. The original atomic
area in resume function is
too large.
I had done something in this patch:
[PATCH (net.git)] stmmac: fix and review whole driver locking
Indeed I was not able to review it after some advice but I will do it!
So we can review your patch and then I will re-base my work on top of
yours.
I just wonder if the spinlock can be safely removed instead of
surrounding just the code to clear the descriptors that should
not be claimed by others. Maybe the only part shared is the
stmmac_hw_setup that can be invoked by open method.
peppe
Signed-off-by: Hao Liang
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 6e6ee22..2effbfe 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2924,9 +2924,8 @@ int stmmac_suspend(struct net_device *ndev)
if (priv->phydev)
phy_stop(priv->phydev);
- spin_lock_irqsave(&priv->lock, flags);
-
netif_device_detach(ndev);
+
netif_stop_queue(ndev);
napi_disable(&priv->napi);
@@ -2935,6 +2934,8 @@ int stmmac_suspend(struct net_device *ndev)
priv->hw->dma->stop_tx(priv->ioaddr);
priv->hw->dma->stop_rx(priv->ioaddr);
+ spin_lock_irqsave(&priv->lock, flags);
+
stmmac_clear_descriptors(priv);
/* Enable Power down mode by programming the PMT regs */
@@ -2945,7 +2946,7 @@ int stmmac_suspend(struct net_device *ndev)
stmmac_set_mac(priv->ioaddr, false);
pinctrl_pm_select_sleep_state(priv->device);
/* Disable clock in case of PWM is off */
- clk_disable_unprepare(priv->stmmac_clk);
+ clk_disable(priv->stmmac_clk);
}
spin_unlock_irqrestore(&priv->lock, flags);
@@ -2977,12 +2978,14 @@ int stmmac_resume(struct net_device *ndev)
} else {
pinctrl_pm_select_default_state(priv->device);
/* enable the clk prevously disabled */
- clk_prepare_enable(priv->stmmac_clk);
+ clk_enable(priv->stmmac_clk);
/* reset the phy so that it's ready */
if (priv->mii)
stmmac_mdio_reset(priv->mii);
}
+ spin_unlock_irqrestore(&priv->lock, flags);
+
netif_device_attach(ndev);
stmmac_hw_setup(ndev);
@@ -2991,8 +2994,6 @@ int stmmac_resume(struct net_device *ndev)
netif_start_queue(ndev);
- spin_unlock_irqrestore(&priv->lock, flags);
-
if (priv->phydev)
phy_start(priv->phydev);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] might sleep functions in atomic context in stmmac_resume()
Hello Alexey On 5/17/2014 1:15 AM, Alexey Khoroshilov wrote: There are calls to might sleep functions in atomic context in stmmac_resume(): - the first one is clk_prepare_enable(priv->stmmac_clk); - the second one is stmmac_hw_setup() -> init_dma_desc_rings() -> stmmac_init_rx_buffers() -> __netdev_alloc_skb(GFP_KERNEL) What is the purpose of spin_lock_irqsave(&priv->lock, flags) section? What does it protect against? Some part of this driver, especially on PM stuff, has been reworked time ago. I have in plan to do further tests and investigations also to understand and try to solve this kind of issues. I do not want to see this kind of BUGs. Also I have some other patches on other pending problem I will submit to be reviewed. I hope to start doing this task in the incoming days. BR peppe Found by Linux Driver Verification project (linuxtesting.org). -- Alexey Khoroshilov Linux Verification Center, ISPRAS web: http://linuxtesting.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/10] net: stmmac: Enable stmmac main clock when probing hardware
Hello Chen-Yu
On 12/6/2013 6:29 PM, Chen-Yu Tsai wrote:
Signed-off-by: Chen-Yu Tsai
---
Guiseppe previously stated that the "stmmaceth" clock is the
main clock that drives the IP. The stmmac driver does not
enable this clock during the probe phase. When the driver is
built in to the kernel, this is fine because the clock maybe
on by default, or the boot loader had enabled it.
If stmmac is built as a module, when the module is loaded,
the clock may be found unused and disabled by the kernel.
the clk_prepare_enable is then called in the open.
Is it not working for you?
Do you mean that the stmmac_hw_init fails if you do not move
the clk_get and clk_prepare_enable on top of the stmmac_dvr_probe?
Peppe
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 24 +--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 8d4ccd3..7da71ed 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2688,10 +2688,17 @@ struct stmmac_priv *stmmac_dvr_probe(struct device
*device,
if ((phyaddr >= 0) && (phyaddr <= 31))
priv->plat->phy_addr = phyaddr;
+ priv->stmmac_clk = clk_get(priv->device, STMMAC_RESOURCE_NAME);
+ if (IS_ERR(priv->stmmac_clk)) {
+ pr_warn("%s: warning: cannot get CSR clock\n", __func__);
+ goto error_clk_get;
+ }
+ clk_prepare_enable(priv->stmmac_clk);
+
/* Init MAC and get the capabilities */
ret = stmmac_hw_init(priv);
if (ret)
- goto error_free_netdev;
+ goto error_hw_init;
ndev->netdev_ops = &stmmac_netdev_ops;
@@ -2729,12 +2736,6 @@ struct stmmac_priv *stmmac_dvr_probe(struct device
*device,
goto error_netdev_register;
}
- priv->stmmac_clk = clk_get(priv->device, STMMAC_RESOURCE_NAME);
- if (IS_ERR(priv->stmmac_clk)) {
- pr_warn("%s: warning: cannot get CSR clock\n", __func__);
- goto error_clk_get;
- }
-
/* If a specific clk_csr value is passed from the platform
* this means that the CSR Clock Range selection cannot be
* changed at run-time and it is fixed. Viceversa the driver'll try to
@@ -2759,15 +2760,18 @@ struct stmmac_priv *stmmac_dvr_probe(struct device
*device,
}
}
+ clk_disable_unprepare(priv->stmmac_clk);
+
return priv;
error_mdio_register:
- clk_put(priv->stmmac_clk);
-error_clk_get:
unregister_netdev(ndev);
error_netdev_register:
netif_napi_del(&priv->napi);
-error_free_netdev:
+error_hw_init:
+ clk_disable_unprepare(priv->stmmac_clk);
+ clk_put(priv->stmmac_clk);
+error_clk_get:
free_netdev(ndev);
return NULL;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 0/9]net: stmmac PM related fixes.
On 11/18/2013 12:30 PM, srinivas.kandaga...@st.com wrote: From: Srinivas Kandagatla Hi Peppe, During PM_SUSPEND_FREEZE testing, I have noticed that PM support in STMMAC is partly broken. I had to re-arrange the code to do PM correctly. There were lot of things I did not like personally and some bits did not work in the first place. I thought this is the nice opportunity to clean the mess up. Here is what I did: 1> Test PM suspend freeeze via pm_test It did not work for following reasons. - If the power to gmac is removed when it enters in low power state. stmmac_resume could not cope up with such behaviour, it was expecting the ip register contents to be still same as before entering low power, This assumption is wrong. So I started to add some code to do Hardware initialization, thats when I started to re-arrange the code. stmmac_open contains both resource and memory allocations and hardware initialization. I had to separate these two things in two different functions. These two patches do that net: stmmac: move dma allocation to new function net: stmmac: move hardware setup for stmmac_open to new function And rest of the other patches are fixing the loose ends, things like mdio reset, which might be necessary in cases likes hibernation(I did not test). In hibernation cases the driver was just unregistering with subsystems and releasing resources which I did not like and its not necessary to do this as part of PM. So using the same stmmac_suspend/resume made more sense for hibernation cases than using stmmac_open/release. Also fixed a NULL pointer dereference bug too. 2> Test WOL via PM_SUSPEND_FREEZE Did get an wakeup interrupt, but could not wakeup a freeze system. So I had to add pm_wakeup_event to the driver. net: stmmac: notify the PM core of a wakeup event. patch. Also few patches like net: stmmac: make stmmac_mdio_reset non-static net: stmmac: restore pinstate in pm resume. helps the resume function to reset the phy and put back the pins in default state. Comments? Srini, as we had internally discussed before sending the patches to the net ML, I agreed with your work. Some parts of the PM stuff was fully tested on our product kernels (where the PM was a bit different especially on HoM) and nobody raised issues to me for this code. Also some rework you did, for example to move the dma allocation in a new function is fine for me. So you continue to have my Acked-by for all. peppe Thanks, srini Srinivas Kandagatla (9): net: stmmac: support max-speed device tree property net: stmmac: mdio: remove reset gpio free net: stmmac: move dma allocation to new function net: stmmac: move hardware setup for stmmac_open to new function net: stmmac: make stmmac_mdio_reset non-static net: stmmac: fix power mangement suspend-resume case net: stmmac: use suspend functions for hibernation net: stmmac: restore pinstate in pm resume. net: stmmac: notify the PM core of a wakeup event. drivers/net/ethernet/stmicro/stmmac/stmmac.h |4 +- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 360 ++-- drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c |3 +- .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 51 +-- include/linux/stmmac.h |1 + 5 files changed, 209 insertions(+), 210 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 00/10] ARM: STi: Add dwmac glue and reset controller
On 11/12/2013 2:51 PM, srinivas.kandaga...@st.com wrote: From: Srinivas Kandagatla Hi All, This patch series adds Ethernet support to STi series SOCs STiH415 and STiH416. STi SOC series integrates dwmac IP from synopsis, however there is a hardware glue on top of this standard IP, this glue needs to configured before the actual dwmac can be used. To add this a new driver dwmac-sti is introduced whose responsibility is to configure dwmac glue and before dwmac driver, this is achieved by making dwmac device node as child to ethernet glue node. Inspired by usb/dwc3. Also the glue needs to come out of softreset which is why we have added a softreset controller to driver which looked perfectly neat, rather then driving the softreset bit from the glue driver. Also as part of power management in glue driver, I found that there was no function to determine if the child device is a wakeup source or not. I have added a new api device_child_may_wakeup API which could be useful for drivers like this. "PM / wakeup : Introduce device_child_may_wakeup" patch has that new API and "net: stmmac:sti: Add STi SOC glue driver." glue driver uses this new API. The reason for combining all these patches in a same series is because of dependencies. This patch series is tested on B2000 and B2020 boards with STiH415, STiH416 SOC on ethernet 100/1000 Links. Comments? Hello Srini ll these patches are ok for me and, as you know, I have already started using them while porting other SoC. Glue logic is mandatory now! Thanks peppe Thanks, srini Srinivas Kandagatla (6): drivers: reset: stih415: add softreset controller drivers: reset: stih416: add softreset controller PM / wakeup : Introduce device_child_may_wakeup net: stmmac:sti: Add STi SOC glue driver. ARM: STi: Add STiH415 ethernet support. ARM: STi: Add STiH416 ethernet support. Stephen Gallimore (4): drivers: reset: STi SoC system configuration reset controller support drivers: reset: Reset controller driver for STiH415 drivers: reset: Reset controller driver for STiH416 ARM: STi: Add reset controller support to mach-sti Kconfig .../devicetree/bindings/net/sti-dwmac.txt | 45 +++ .../devicetree/bindings/reset/st,sti-powerdown.txt | 46 +++ .../devicetree/bindings/reset/st,sti-softreset.txt | 45 +++ arch/arm/boot/dts/stih415-clock.dtsi | 14 + arch/arm/boot/dts/stih415-pinctrl.dtsi | 82 ++ arch/arm/boot/dts/stih415.dtsi | 67 + arch/arm/boot/dts/stih416-clock.dtsi | 14 + arch/arm/boot/dts/stih416-pinctrl.dtsi | 106 +++ arch/arm/boot/dts/stih416.dtsi | 69 + arch/arm/boot/dts/stih41x-b2000.dtsi | 32 +++ arch/arm/boot/dts/stih41x-b2020.dtsi | 33 +++ arch/arm/mach-sti/Kconfig |3 + drivers/base/power/wakeup.c| 23 ++ drivers/net/ethernet/stmicro/stmmac/Makefile |1 + drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c| 294 drivers/reset/Kconfig |2 + drivers/reset/Makefile |3 + drivers/reset/sti/Kconfig | 15 + drivers/reset/sti/Makefile |4 + drivers/reset/sti/reset-stih415.c | 99 +++ drivers/reset/sti/reset-stih416.c | 101 +++ drivers/reset/sti/reset-syscfg.c | 186 drivers/reset/sti/reset-syscfg.h | 69 + .../dt-bindings/reset-controller/stih415-resets.h | 23 ++ .../dt-bindings/reset-controller/stih416-resets.h | 25 ++ include/linux/pm_wakeup.h |1 + 26 files changed, 1402 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/sti-dwmac.txt create mode 100644 Documentation/devicetree/bindings/reset/st,sti-powerdown.txt create mode 100644 Documentation/devicetree/bindings/reset/st,sti-softreset.txt create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c create mode 100644 drivers/reset/sti/Kconfig create mode 100644 drivers/reset/sti/Makefile create mode 100644 drivers/reset/sti/reset-stih415.c create mode 100644 drivers/reset/sti/reset-stih416.c create mode 100644 drivers/reset/sti/reset-syscfg.c create mode 100644 drivers/reset/sti/reset-syscfg.h create mode 100644 include/dt-bindings/reset-controller/stih415-resets.h create mode 100644 include/dt-bindings/reset-controller/stih416-resets.h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: stmmac: add dcrs parameter
Hello
On 8/25/2014 1:50 PM, Ley Foon Tan wrote:
This patch add the option to enable DCRS bit in GMAC control register.
Default is disabled if snps,dcrs is not defined.
For MII, Carrier Sense (CRS) must be asserted during transmission
whereas in RGMII, CRS is not. RGMII does not provide a way to signal
loss of carrier during a transmission.
When DCRS bit set high in control register, the MAC transmitter
ignore the (G)MII Carrier Sense signal during frame transmission
in the half-duplex mode. This request results in no errors generated
because of Loss of Carrier or No Carrier during such transmission.
We have to add this fix in the driver. I wonder if we can avoid to have
another parameter and just have it set as default
(http://git.stlinux.com/?p=stm/linux-sh4-2.6.32.y.git;a=commit;h=b0b863bf65c36dc593f6b7b4b418394fd880dae2)
Or we could touch this bit according to the link duplex negotiated and
the phy mode selected.
peppe
Signed-off-by: Ley Foon Tan
---
Documentation/devicetree/bindings/net/stmmac.txt | 4
drivers/net/ethernet/stmicro/stmmac/common.h | 3 ++-
drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 4 +++-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 ++-
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 ++
include/linux/stmmac.h| 1 +
6 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt
b/Documentation/devicetree/bindings/net/stmmac.txt
index 9b03c57..a68e720 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -39,6 +39,10 @@ Optional properties:
further clocks may be specified in derived bindings.
- clock-names: One name for each entry in the clocks property, the
first one should be "stmmaceth".
+- snps,dcrs: Enable DCRS bit in GMAC control register. This DCRS bit makes the
+ MAC transmitter ignore the (G)MII CRS signal during frame transmission
+ in the half-duplex mode. This request results in no errors generated
+ because of Loss of Carrier or No Carrier during such transmission.
Examples:
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h
b/drivers/net/ethernet/stmicro/stmmac/common.h
index de507c3..9abe221 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -445,10 +445,11 @@ struct mac_device_info {
int multicast_filter_bins;
int unicast_filter_entries;
int mcast_bits_log2;
+ int dcrs;
};
struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr, int mcbins,
- int perfect_uc_entries);
+ int perfect_uc_entries, int dcrs);
struct mac_device_info *dwmac100_setup(void __iomem *ioaddr);
void stmmac_set_mac_addr(void __iomem *ioaddr, u8 addr[6],
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index d8ef187..924d450 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -37,6 +37,7 @@ static void dwmac1000_core_init(struct mac_device_info *hw,
int mtu)
void __iomem *ioaddr = hw->pcsr;
u32 value = readl(ioaddr + GMAC_CONTROL);
value |= GMAC_CORE_INIT;
+ value |= hw->dcrs;
if (mtu > 1500)
value |= GMAC_CONTROL_2K;
if (mtu > 2000)
@@ -409,7 +410,7 @@ static const struct stmmac_ops dwmac1000_ops = {
};
struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr, int mcbins,
- int perfect_uc_entries)
+ int perfect_uc_entries, int dcrs)
{
struct mac_device_info *mac;
u32 hwid = readl(ioaddr + GMAC_VERSION);
@@ -422,6 +423,7 @@ struct mac_device_info *dwmac1000_setup(void __iomem
*ioaddr, int mcbins,
mac->multicast_filter_bins = mcbins;
mac->unicast_filter_entries = perfect_uc_entries;
mac->mcast_bits_log2 = 0;
+ mac->dcrs = dcrs;
if (mac->multicast_filter_bins)
mac->mcast_bits_log2 = ilog2(mac->multicast_filter_bins);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 08addd6..bf35b19 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2600,7 +2600,8 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
priv->dev->priv_flags |= IFF_UNICAST_FLT;
mac = dwmac1000_setup(priv->ioaddr,
priv->plat->multicast_filter_bins,
- priv->plat->unicast_filter_entries);
+ priv->plat->unicast_filter_entries,
+
Re: [PATCH] net: stmmac: add dcrs parameter
On 8/25/2014 2:34 PM, Chen-Yu Tsai wrote:
Hi,
On Mon, Aug 25, 2014 at 7:50 PM, Ley Foon Tan wrote:
This patch add the option to enable DCRS bit in GMAC control register.
Default is disabled if snps,dcrs is not defined.
For MII, Carrier Sense (CRS) must be asserted during transmission
whereas in RGMII, CRS is not. RGMII does not provide a way to signal
loss of carrier during a transmission.
When DCRS bit set high in control register, the MAC transmitter
ignore the (G)MII Carrier Sense signal during frame transmission
in the half-duplex mode. This request results in no errors generated
because of Loss of Carrier or No Carrier during such transmission.
Signed-off-by: Ley Foon Tan
---
Documentation/devicetree/bindings/net/stmmac.txt | 4
drivers/net/ethernet/stmicro/stmmac/common.h | 3 ++-
drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 4 +++-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 ++-
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 ++
include/linux/stmmac.h| 1 +
6 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt
b/Documentation/devicetree/bindings/net/stmmac.txt
index 9b03c57..a68e720 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -39,6 +39,10 @@ Optional properties:
further clocks may be specified in derived bindings.
- clock-names: One name for each entry in the clocks property, the
first one should be "stmmaceth".
+- snps,dcrs: Enable DCRS bit in GMAC control register. This DCRS bit makes the
+ MAC transmitter ignore the (G)MII CRS signal during frame transmission
+ in the half-duplex mode. This request results in no errors generated
Since you know this is only required under (G)MII, could you not re-use
the "phy-mode" property, instead of adding another one?
Better yet, use the "interface" field in the platform data. This way you'll
fix non-DT devices as well. You could then avoid touching the platform driver,
and just modify the driver core.
yes this is what I asked. Thx ChenYu for the this detail.
Ley Foon Tan, could you do that? Let me know
peppe
Cheers
ChenYu
+ because of Loss of Carrier or No Carrier during such transmission.
Examples:
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h
b/drivers/net/ethernet/stmicro/stmmac/common.h
index de507c3..9abe221 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -445,10 +445,11 @@ struct mac_device_info {
int multicast_filter_bins;
int unicast_filter_entries;
int mcast_bits_log2;
+ int dcrs;
};
struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr, int mcbins,
- int perfect_uc_entries);
+ int perfect_uc_entries, int dcrs);
struct mac_device_info *dwmac100_setup(void __iomem *ioaddr);
void stmmac_set_mac_addr(void __iomem *ioaddr, u8 addr[6],
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index d8ef187..924d450 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -37,6 +37,7 @@ static void dwmac1000_core_init(struct mac_device_info *hw,
int mtu)
void __iomem *ioaddr = hw->pcsr;
u32 value = readl(ioaddr + GMAC_CONTROL);
value |= GMAC_CORE_INIT;
+ value |= hw->dcrs;
if (mtu > 1500)
value |= GMAC_CONTROL_2K;
if (mtu > 2000)
@@ -409,7 +410,7 @@ static const struct stmmac_ops dwmac1000_ops = {
};
struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr, int mcbins,
- int perfect_uc_entries)
+ int perfect_uc_entries, int dcrs)
{
struct mac_device_info *mac;
u32 hwid = readl(ioaddr + GMAC_VERSION);
@@ -422,6 +423,7 @@ struct mac_device_info *dwmac1000_setup(void __iomem
*ioaddr, int mcbins,
mac->multicast_filter_bins = mcbins;
mac->unicast_filter_entries = perfect_uc_entries;
mac->mcast_bits_log2 = 0;
+ mac->dcrs = dcrs;
if (mac->multicast_filter_bins)
mac->mcast_bits_log2 = ilog2(mac->multicast_filter_bins);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 08addd6..bf35b19 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2600,7 +2600,8 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
priv->dev->priv_flags |= IFF_UNICAST_FLT;
mac = dwmac1000_setup(priv->ioaddr,
priv->plat->multicast_filter_b
Re: [PATCH] net: stmmac: add dcrs parameter
On 8/25/2014 5:10 PM, Vince Bridgers wrote: Hi, On Mon, Aug 25, 2014 at 7:51 AM, Giuseppe CAVALLARO wrote: On 8/25/2014 2:34 PM, Chen-Yu Tsai wrote: Hi, On Mon, Aug 25, 2014 at 7:50 PM, Ley Foon Tan wrote: This patch add the option to enable DCRS bit in GMAC control register. Default is disabled if snps,dcrs is not defined. For MII, Carrier Sense (CRS) must be asserted during transmission whereas in RGMII, CRS is not. RGMII does not provide a way to signal loss of carrier during a transmission. While technically true, from a practical point of view, this is only useful if using true half-duplex media (like the now obsolete 10Base2 and 10Base5 - think old school coax with vampire taps). When DCRS bit set high in control register, the MAC transmitter ignore the (G)MII Carrier Sense signal during frame transmission in the half-duplex mode. This request results in no errors generated because of Loss of Carrier or No Carrier during such transmission. Signed-off-by: Ley Foon Tan --- Since you know this is only required under (G)MII, could you not re-use the "phy-mode" property, instead of adding another one? Better yet, use the "interface" field in the platform data. This way you'll fix non-DT devices as well. You could then avoid touching the platform driver, and just modify the driver core. yes this is what I asked. Thx ChenYu for the this detail. Ley Foon Tan, could you do that? Let me know peppe In the Synopsys EMAC case, carrier sense is used to stop transmitting if no carrier is sensed during a transmission. This is only useful if the media in use is true half duplex media (like obsolete 10Base2 or 10Base5). If no one in using true half duplex media, then is it possible to set this disable by default? If we're not sure, then having an option feels like the right thing to do. Indeed this is what I had done in the patch. http://git.stlinux.com/?p=stm/linux-sh4-2.6.32.y.git;a=commit;h=b0b863bf65c36dc593f6b7b4b418394fd880dae2 Also in case of carrier sense the frame will be dropped in any case later. Let me know if you Acked this patch so I will rebase it on net.git and I send it soon peppe Vince -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: stmmac: fix warning from Sparse for socfpga
On 8/26/2014 9:11 AM, Ley Foon Tan wrote:
Warning:
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c:122:41:
sparse: cast removes address space of expression
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c:122:38:
sparse: incorrect type in assignment (different address spaces)
Signed-off-by: Ley Foon Tan
---
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index cd613d7..c1addce 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -119,7 +119,8 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac
*dwmac, struct device *
return -EINVAL;
}
- dwmac->splitter_base = (void *)devm_ioremap_resource(dev,
+ dwmac->splitter_base =
+ (void __iomem *)devm_ioremap_resource(dev,
I think, no casting should be done:
dwmac->splitter_base = devm_ioremap_resource(dev,
patch should be for net-next
peppe
&res_splitter);
if (!dwmac->splitter_base) {
dev_info(dev, "Failed to mapping emac splitter\n");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: stmmac: fix warning from Sparse for socfpga
On 8/26/2014 9:47 AM, Ley Foon Tan wrote: On Tue, Aug 26, 2014 at 3:24 PM, Giuseppe CAVALLARO wrote: @@ -119,7 +119,8 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac *dwmac, struct device * return -EINVAL; } - dwmac->splitter_base = (void *)devm_ioremap_resource(dev, + dwmac->splitter_base = + (void __iomem *)devm_ioremap_resource(dev, I think, no casting should be done: dwmac->splitter_base = devm_ioremap_resource(dev, Oh ya, since both are same type. Will send new patch. thx a lot patch should be for net-next Do you mean the patch need based on net-next git? yes I do. I'm using linux-next git now. ok, can you signal it in the subject (e.g. [PATCH (net-next)] This can help on reviewing and IIRC required by Maintainer too Thanks. welcome BR peppe Regards Ley Foon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH (net-next) v2] net: stmmac: fix warning from Sparse for socfpga
On 8/26/2014 11:47 AM, Ley Foon Tan wrote:
Warning:
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c:122:41:
sparse: cast removes address space of expression
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c:122:38:
sparse: incorrect type in assignment (different address spaces)
Signed-off-by: Ley Foon Tan
---
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index cd613d7..ff54a1f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -119,7 +119,7 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac
*dwmac, struct device *
return -EINVAL;
}
- dwmac->splitter_base = (void *)devm_ioremap_resource(dev,
+ dwmac->splitter_base = devm_ioremap_resource(dev,
&res_splitter);
can the ioremap call stay in a single line ? or pls review indent looks
NOK
peppe
if (!dwmac->splitter_base) {
dev_info(dev, "Failed to mapping emac splitter\n");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: stmmac: add dcrs parameter
On 8/26/2014 2:35 PM, Vince Bridgers wrote: Hi Peppe, In the Synopsys EMAC case, carrier sense is used to stop transmitting if no carrier is sensed during a transmission. This is only useful if the media in use is true half duplex media (like obsolete 10Base2 or 10Base5). If no one in using true half duplex media, then is it possible to set this disable by default? If we're not sure, then having an option feels like the right thing to do. Indeed this is what I had done in the patch. http://git.stlinux.com/?p=stm/linux-sh4-2.6.32.y.git;a=commit;h=b0b863bf65c36dc593f6b7b4b418394fd880dae2 Also in case of carrier sense the frame will be dropped in any case later. Let me know if you Acked this patch so I will rebase it on net.git and I send it soon peppe Yes, this looks good to me. I don't expect anyone is using 10Base2 or 10Base5 anymore, so it's ok to disable DCRS by default. ack All the best, thx so much, I will send this patch (with your Acked-by) and ported on net.git soon. Chen-Yu, Ley Foon, pls let me know if it is ok for you as well Kind Regards Peppe Vince -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] net: stmmac: Enable Intel Quark SoC X1000 Ethernet support
On 8/27/2014 12:32 PM, Kweh Hock Leong wrote: From: "Kweh, Hock Leong" Hi, Intel Quark X1000 SoC has 2 Ethernet controllers integrated on chip and they are PCI devices. We adopted the stmmac_pci driver and added on code to support Intel Quark SoC X1000 by creating the patchset below. The patchset has been built and tested on Galileo board and found to be working as expected. We believe that the changes are transparent to other non Intel Quark platform. Please help to review the code change and feedback if there is any concern. hello and thx for these patches that at first glance look ok to me. Just some minor remark, in the stmmac I try to align the function parameters with the open parenthesis (devm_kzalloc in your case in not aligned). Added on copy also Rayagond he tested PCI. I cannot do any test because I have no PCI cards. peppe Thank you very much. Kweh, Hock Leong (4): net: stmmac: enhance to support multiple device instances net: stmmac: better code manageability with platform data struct net: stmmac: add support for Intel Quark X1000 net: stmmac: add MSI support for Intel Quark X1000 drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 195 +++--- 1 file changed, 172 insertions(+), 23 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH (net-next) v3] net: stmmac: fix warning from Sparse for socfpga
On 8/28/2014 6:59 AM, Ley Foon Tan wrote:
Warning:
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c:122:41:
sparse: cast removes address space of expression
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c:122:38:
sparse: incorrect type in assignment (different address spaces)
Signed-off-by: Ley Foon Tan
Acked-by: Giuseppe Cavallaro
---
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index cd613d7..ddc6115 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -119,8 +119,7 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac
*dwmac, struct device *
return -EINVAL;
}
- dwmac->splitter_base = (void *)devm_ioremap_resource(dev,
- &res_splitter);
+ dwmac->splitter_base = devm_ioremap_resource(dev,
&res_splitter);
if (!dwmac->splitter_base) {
dev_info(dev, "Failed to mapping emac splitter\n");
return -EINVAL;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the net tree
On 10/15/2014 4:02 AM, David Miller wrote:
From: Stephen Rothwell
Date: Wed, 15 Oct 2014 10:44:11 +1100
Hi all,
After merging the net tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/built-in.o: In function `.LANCHOR0':
:(.rodata+0x6b764): undefined reference to `sti_gmac_data'
:(.rodata+0x6b828): undefined reference to `sti_gmac_data'
:(.rodata+0x6b8ec): undefined reference to `sti_gmac_data'
:(.rodata+0x6b9b0): undefined reference to `sti_gmac_data'
Caused by commit 53b26b9bc9a5 ("stmmac: dwmac-sti: review the
glue-logic for STi4xx and STiD127 SoCs") which renamed sti_gmac_data to
stih4xx_dwmac_data (or something) without updating all the references
to it (including the one added in the previous commit ...).
I reverted that commit for today.
Sigh, Giuseppe if I don't see a proper fix by tomorrow I'm
reverting all of the stmmac changes I applied today.
I am looking at this now and let you know soon
peppe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH (net.git) 1/1] stmmac: fix sti compatibililies
this patch is to fix the stmmac data compatibilities for
all the SoCs inside the platform file.
Signed-off-by: Giuseppe Cavallaro
---
drivers/net/ethernet/stmicro/stmmac/stmmac.h |3 ++-
.../net/ethernet/stmicro/stmmac/stmmac_platform.c |8
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index 4452889..c3c4065 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -144,7 +144,8 @@ extern const struct stmmac_of_data meson6_dwmac_data;
extern const struct stmmac_of_data sun7i_gmac_data;
#endif
#ifdef CONFIG_DWMAC_STI
-extern const struct stmmac_of_data sti_gmac_data;
+extern const struct stmmac_of_data stih4xx_dwmac_data;
+extern const struct stmmac_of_data stid127_dwmac_data;
#endif
#ifdef CONFIG_DWMAC_SOCFPGA
extern const struct stmmac_of_data socfpga_gmac_data;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 0d6b9ad..db56fa7 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -37,10 +37,10 @@ static const struct of_device_id stmmac_dt_ids[] = {
{ .compatible = "allwinner,sun7i-a20-gmac", .data = &sun7i_gmac_data},
#endif
#ifdef CONFIG_DWMAC_STI
- { .compatible = "st,stih415-dwmac", .data = &sti_gmac_data},
- { .compatible = "st,stih416-dwmac", .data = &sti_gmac_data},
- { .compatible = "st,stid127-dwmac", .data = &sti_gmac_data},
- { .compatible = "st,stih407-dwmac", .data = &sti_gmac_data},
+ { .compatible = "st,stih415-dwmac", .data = &stih4xx_dwmac_data},
+ { .compatible = "st,stih416-dwmac", .data = &stih4xx_dwmac_data},
+ { .compatible = "st,stid127-dwmac", .data = &stid127_dwmac_data},
+ { .compatible = "st,stih407-dwmac", .data = &stih4xx_dwmac_data},
#endif
#ifdef CONFIG_DWMAC_SOCFPGA
{ .compatible = "altr,socfpga-stmmac", .data = &socfpga_gmac_data },
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: ethernet : stmicro: fixed power suspend and resume failure in stmmac driver
Hello Hao Liang On 10/1/2014 7:45 PM, David Miller wrote: From: Hao Liang Date: Wed, 1 Oct 2014 14:08:28 +0800 I double-check my patch and the ->mac->xxx calls are still under the lock. I think that lock is trying to protect priv struct and related data, so i just remove some functions have no bearing on priv struct. It's preventing parallel invocations of the ->mac->xxx calls. The other instances are in device open/close, where RTNL semaphore is held, and no other code paths in the driver can be active. You need the lock. Do you have a new patch for this problem after David's advice? I am reviewing the patches sent some weeks ago for driver looking and I can also try to fix this in case of you have no news. Let me know, Regards, peppe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: stmmac: potential circular locking dependency
Hello Emilio
I have a subset of new patches to review and fix locks in the
driver. I will plan to send them in the next days.
Sincerely
Peppe
On 11/3/2014 3:36 PM, Emilio López wrote:
Hi everyone,
I was playing with iperf on my Cubietruck today when I hit this lockdep
report/breakage on stmmac. It seems to be fairly reproducible by
1) Being on a GbE network
2) "iperf -s" on the stmmmac device
3) "iperf -c -d -P 5" on some other device on the LAN
Here it goes:
==
[ INFO: possible circular locking dependency detected ]
3.18.0-rc3-3-g7180edf #916 Not tainted
---
iperf/141 is trying to acquire lock:
(&(&dev->tx_global_lock)->rlock){+.-...}, at: []
stmmac_tx_clean+0x350/0x43c
but task is already holding lock:
(&(&priv->tx_lock)->rlock){+.-...}, at: []
stmmac_tx_clean+0x30/0x43c
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&(&priv->tx_lock)->rlock){+.-...}:
[] _raw_spin_lock+0x5c/0x94
[] stmmac_xmit+0x88/0x620
[] dev_hard_start_xmit+0x230/0x49c
[] sch_direct_xmit+0xdc/0x20c
[] __dev_queue_xmit+0x218/0x604
[] dev_queue_xmit+0x1c/0x20
[] neigh_resolve_output+0x180/0x254
[] ip6_finish_output2+0x188/0x8a4
[] ip6_output+0xc8/0x398
[] mld_sendpack+0x2e0/0x6d8
[] mld_ifc_timer_expire+0x1f0/0x308
[] call_timer_fn+0xb4/0x1f0
[] run_timer_softirq+0x224/0x2f0
[] __do_softirq+0x1d4/0x3e0
[] irq_exit+0x9c/0xd0
[] __handle_domain_irq+0x70/0xb4
[] gic_handle_irq+0x34/0x6c
[] __irq_svc+0x44/0x5c
[] lock_acquire+0xec/0x17c
[] lock_acquire+0xec/0x17c
[] _raw_spin_lock+0x5c/0x94
[] do_read_fault.isra.93+0xa8/0x2a0
[] handle_mm_fault+0x44c/0x8dc
[] do_page_fault+0x160/0x2d8
[] do_PrefetchAbort+0x44/0xa8
[] ret_from_exception+0x0/0x20
[] 0xb6eb0120
-> #1 (_xmit_ETHER#2){+.-...}:
[] _raw_spin_lock+0x5c/0x94
[] dev_deactivate_many+0xd0/0x250
[] dev_deactivate+0x3c/0x4c
[] linkwatch_do_dev+0x50/0x84
[] __linkwatch_run_queue+0xdc/0x148
[] linkwatch_event+0x3c/0x44
[] process_one_work+0x1ec/0x510
[] worker_thread+0x5c/0x4d8
[] kthread+0xe8/0xfc
[] ret_from_fork+0x14/0x20
-> #0 (&(&dev->tx_global_lock)->rlock){+.-...}:
[] lock_acquire+0xdc/0x17c
[] _raw_spin_lock+0x5c/0x94
[] stmmac_tx_clean+0x350/0x43c
[] stmmac_poll+0x3c/0x618
[] net_rx_action+0x178/0x28c
[] __do_softirq+0x1d4/0x3e0
[] irq_exit+0x9c/0xd0
[] __handle_domain_irq+0x70/0xb4
[] gic_handle_irq+0x34/0x6c
[] __irq_svc+0x44/0x5c
[] __local_bh_enable_ip+0x9c/0xfc
[] __local_bh_enable_ip+0x9c/0xfc
[] _raw_read_unlock_bh+0x40/0x44
[] inet6_dump_addr+0x33c/0x530
[] inet6_dump_ifaddr+0x1c/0x20
[] rtnl_dump_all+0x50/0xf4
[] netlink_dump+0xc0/0x250
[] netlink_recvmsg+0x234/0x300
[] sock_recvmsg+0xa4/0xc8
[] ___sys_recvmsg.part.33+0xe4/0x1c0
[] __sys_recvmsg+0x60/0x90
[] SyS_recvmsg+0x18/0x1c
[] ret_fast_syscall+0x0/0x48
other info that might help us debug this:
Chain exists of:
&(&dev->tx_global_lock)->rlock --> _xmit_ETHER#2 -->
&(&priv->tx_lock)->rlock
Possible unsafe locking scenario:
CPU0CPU1
lock(&(&priv->tx_lock)->rlock);
lock(_xmit_ETHER#2);
lock(&(&priv->tx_lock)->rlock);
lock(&(&dev->tx_global_lock)->rlock);
*** DEADLOCK ***
3 locks held by iperf/141:
#0: (rtnl_mutex){+.+.+.}, at: [] netlink_dump+0x28/0x250
#1: (rcu_read_lock){..}, at: [] inet6_dump_addr+0x0/0x530
#2: (&(&priv->tx_lock)->rlock){+.-...}, at: []
stmmac_tx_clean+0x30/0x43c
stack backtrace:
CPU: 0 PID: 141 Comm: iperf Not tainted 3.18.0-rc3-3-g7180edf #916
[] (unwind_backtrace) from [] (show_stack+0x20/0x24)
[] (show_stack) from [] (dump_stack+0x9c/0xbc)
[] (dump_stack) from []
(print_circular_bug+0x21c/0x33c)
[] (print_circular_bug) from []
(__lock_acquire+0x2060/0x2148)
[] (__lock_acquire) from [] (lock_acquire+0xdc/0x17c)
[] (lock_acquire) from [] (_raw_spin_lock+0x5c/0x94)
[] (_raw_spin_lock) from []
(stmmac_tx_clean+0x350/0x43c)
[] (stmmac_tx_clean) from [] (stmmac_poll+0x3c/0x618)
[] (stmmac_poll) from [] (net_rx_action+0x178/0x28c)
[] (net_rx_action) from [] (__do_softirq+0x1d4/0x3e0)
[] (__do_softirq) from [] (irq_exit+0x9c/0xd0)
[] (irq_exit) from [] (__handle_domain_irq+0x70/0xb4)
[] (__handle_domain_irq) from []
(gic_handle_irq+0x34/0x6c)
[] (gic_handle_irq) from [] (__irq_svc+0x44/0x5c)
Exception stack(0xcabc1be0 to 0xcabc1c28)
1be0: 0001 2df53000 caf15e80 cabc 02
Re: [PATCH 2/5] regulator: st-flashss: Add a regulator driver for flashss vsense.
Hello Mark
On 4/13/2016 7:23 PM, Mark Brown wrote:
On Wed, Apr 13, 2016 at 09:59:00AM +0200, Giuseppe CAVALLARO wrote:
On 4/13/2016 8:15 AM, Mark Brown wrote:
+static void st_get_satinize_powerup_voltage(struct st_vsense *vsense)
+{
or am I missing something? Why do we need to do this anyway, it's very
surprsing?
This functions is to sanitize the vsense voltages when the regulator
is probed and in some circumstances the reset value of this register
does not reflect the hw status/config. For example, by default, after
the reset, the bit 0 is set so the EMMC, inside the flash subsystem,
is supposed to operate at 3v3. But the latched bit 24 can be 0 on
a platform where it is actually set at 1v8.
So the bit 0 must be reset to keep this coherent and to allow MMC
framework to properly setup the Vdd when the framework starts.
I'm afraid I can't follow that explanation, perhaps because I don't know
anything about the content of this register except for these three bits.
I think we do need a comment in the driver explaining what's going on,
yes you are right
and probably a simplification of the code too if my understanding of the
effect of all those operations is correct.
Maybe we can simplify the function as:
static void st_get_satinize_powerup_voltage(struct st_vsense *vsense)
{
void __iomem *ioaddr = vsense->ioaddr;
u32 value = readl_relaxed(ioaddr);
/*
* After resetting, the CONFIG_REG_PSW_ are set, this
* means 3v3 operating voltage.
* The CONFIG_LATCHED_PSW_ must be used to fix the previous
* bits so operating at 1v8 if this is the real HW configuration
* at boot time.
*/
if (!(value & TOP_VSENSE_CONFIG_LATCHED_PSW_EMMC))
value &= ~TOP_VSENSE_CONFIG_REG_PSW_EMMC;
if (!(value & TOP_VSENSE_CONFIG_LATCHED_PSW_NAND))
value &= ~TOP_VSENSE_CONFIG_REG_PSW_NAND;
if (!(value & TOP_VSENSE_CONFIG_LATCHED_PSW_SPI))
value &= ~TOP_VSENSE_CONFIG_REG_PSW_SPI;
writel_relaxed(value, ioaddr);
}
Le me know if this looks a bit more clear.
Peppe
Re: [PATCH 1/1] net: ethernet: Add SGMII support to dwmac-socfpga
Hello Tien
On 5/13/2016 9:01 AM, th...@altera.com wrote:
From: Tien Hock Loh
Adds SGMII support for dwmac-socfpga to enable the SGMII PHY when phy-mode
of the dwmac is set to sgmii.
I wonder if part of this patch can be unified to the common code
reusing (or improving) existent PCS support (see, for example the
defines inside the common.h and dwmac1000.h header files).
I had added some code for RGMII but never tested the SGMII indeed.
what is your feeling about that?
Peppe
Signed-off-by: Tien Hock Loh
---
.../net/ethernet/stmicro/stmmac/dwmac-socfpga.c| 339 -
1 file changed, 329 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index 41f4c58..a59d590 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -40,6 +40,43 @@
#define EMAC_SPLITTER_CTRL_SPEED_100 0x3
#define EMAC_SPLITTER_CTRL_SPEED_1000 0x0
+#define TSE_PCS_CONTROL_AN_EN_MASK 0x1000
+#define TSE_PCS_CONTROL_REG0x00
+#define TSE_PCS_CONTROL_RESTART_AN_MASK0x0200
+#define TSE_PCS_IF_MODE_REG0x28
+#define TSE_PCS_LINK_TIMER_0_REG 0x24
+#define TSE_PCS_LINK_TIMER_1_REG 0x26
+#define TSE_PCS_SIZE 0x40
+#define TSE_PCS_STATUS_AN_COMPLETED_MASK 0x0020
+#define TSE_PCS_STATUS_LINK_MASK 0x0004
+#define TSE_PCS_STATUS_REG 0x02
+#define TSE_PCS_SGMII_SPEED_1000 0x8
+#define TSE_PCS_SGMII_SPEED_1000x4
+#define TSE_PCS_SGMII_SPEED_10 0x0
+#define TSE_PCS_SW_RST_MASK0x8000
+#define TSE_PCS_PARTNER_ABILITY_REG0x0A
+#define TSE_PCS_PARTNER_DUPLEX_FULL0x1000
+#define TSE_PCS_PARTNER_DUPLEX_HALF0x
+#define TSE_PCS_PARTNER_DUPLEX_MASK0x1000
+#define TSE_PCS_PARTNER_SPEED_MASK 0x0c00
+#define TSE_PCS_PARTNER_SPEED_1000 0x0800
+#define TSE_PCS_PARTNER_SPEED_100 0x0400
+#define TSE_PCS_PARTNER_SPEED_10 0x
+#define TSE_PCS_PARTNER_SPEED_1000 0x0800
+#define TSE_PCS_PARTNER_SPEED_100 0x0400
+#define TSE_PCS_PARTNER_SPEED_10 0x
+#define TSE_PCS_SGMII_SPEED_MASK 0x000C
+#define TSE_PCS_SGMII_LINK_TIMER_0 0x0D40
+#define TSE_PCS_SGMII_LINK_TIMER_1 0x0003
+#define TSE_PCS_SW_RESET_TIMEOUT 100
+#define TSE_PCS_USE_SGMII_AN_MASK 0x0002
+
+#define SGMII_ADAPTER_CTRL_REG 0x00
+#define SGMII_ADAPTER_DISABLE 0x0001
+#define SGMII_ADAPTER_ENABLE 0x
+#define LINK_TIMER 20
+#define AUTONEGO_TIMER 20
+
struct socfpga_dwmac {
int interface;
u32 reg_offset;
@@ -49,18 +86,17 @@ struct socfpga_dwmac {
struct reset_control *stmmac_rst;
void __iomem *splitter_base;
bool f2h_ptp_ref_clk;
+ void __iomem *tse_pcs_base;
+ void __iomem *sgmii_adapter_base;
+ struct timer_list an_timer;
+ struct timer_list link_timer;
};
-static void socfpga_dwmac_fix_mac_speed(void *priv, unsigned int speed)
+static void config_emac_splitter_speed(void __iomem *base, unsigned int speed)
{
- struct socfpga_dwmac *dwmac = (struct socfpga_dwmac *)priv;
- void __iomem *splitter_base = dwmac->splitter_base;
u32 val;
- if (!splitter_base)
- return;
-
- val = readl(splitter_base + EMAC_SPLITTER_CTRL_REG);
+ val = readl(base + EMAC_SPLITTER_CTRL_REG);
val &= ~EMAC_SPLITTER_CTRL_SPEED_MASK;
switch (speed) {
@@ -76,8 +112,214 @@ static void socfpga_dwmac_fix_mac_speed(void *priv,
unsigned int speed)
default:
return;
}
+ writel(val, base + EMAC_SPLITTER_CTRL_REG);
+}
+
+static void config_tx_buffer(u16 data, void __iomem *base)
+{
+ writew(data, base + SGMII_ADAPTER_CTRL_REG);
+}
+
+static void tse_pcs_reset(void __iomem *base, struct socfpga_dwmac *dwmac)
+{
+ int counter = 0;
+ u16 val;
+
+ val = readw(base + TSE_PCS_CONTROL_REG);
+ val |= TSE_PCS_SW_RST_MASK;
+ writew(val, base + TSE_PCS_CONTROL_REG);
+
+ while (counter < TSE_PCS_SW_RESET_TIMEOUT) {
+ val = readw(base + TSE_PCS_CONTROL_REG);
+ val &= TSE_PCS_SW_RST_MASK;
+ if (val == 0)
+ break;
+ counter++;
+ udel
Re: [PATCH v1] net: stmmac: Free rx_skbufs before realloc
Hello On 11/24/2015 7:09 PM, David Miller wrote: From: Shunqian Zheng Date: Sun, 22 Nov 2015 16:44:18 +0800 From: ZhengShunQian The init_dma_desc_rings() may realloc the rx_skbuff[] when suspend and resume. This patch free the rx_skbuff[] before reallocing memory. Signed-off-by: ZhengShunQian This isn't really the right way to fix this. I see two reasonable approaches: 1) suspend liberates the RX ring, although this approach is less desirable 2) resume doesn't try to allocate already populated RX ring entries Freeing the whole RX ring just to allocate it again immediately makes no sense at all and is wasteful work. This is a bug in this driver version that, to be honest, we fixed with the first approach on STi kernel. The patch just called the dma_free_rx_skbufs(priv) in the suspend. I can give you this patch that is tested on my side too. But! I do think we should move on second approach. Indeed, also on ST platforms, when we play with suspend states the DDR although in self-refresh the data are not lost at all. No reason to free and reallocate all in suspend/resume. I can test that and then provide another patch to this mailing list asap. Let me know. peppe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1] net: stmmac: Free rx_skbufs before realloc
On 11/25/2015 4:13 PM, Giuseppe CAVALLARO wrote: Hello On 11/24/2015 7:09 PM, David Miller wrote: From: Shunqian Zheng Date: Sun, 22 Nov 2015 16:44:18 +0800 From: ZhengShunQian The init_dma_desc_rings() may realloc the rx_skbuff[] when suspend and resume. This patch free the rx_skbuff[] before reallocing memory. Signed-off-by: ZhengShunQian This isn't really the right way to fix this. I see two reasonable approaches: 1) suspend liberates the RX ring, although this approach is less desirable 2) resume doesn't try to allocate already populated RX ring entries Freeing the whole RX ring just to allocate it again immediately makes no sense at all and is wasteful work. This is a bug in this driver version that, to be honest, we fixed with the first approach on STi kernel. The patch just called the dma_free_rx_skbufs(priv) in the suspend. I can give you this patch that is tested on my side too. But! I do think we should move on second approach. Indeed, also on ST platforms, when we play with suspend states the DDR although in self-refresh the data are not lost at all. No reason to free and reallocate all in suspend/resume. I can test that and then provide another patch to this mailing list asap. I have just send the patch (directly for approach #2). Peppe Let me know. peppe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/4] Add Ethernet support on STM32F429
On 2/26/2016 11:51 AM, Alexandre TORGUE wrote: STM32F429 Chip embeds a Synopsys 3.50a MAC IP. This series: -enhance current stmmac driver to control it (code already available) and adds basic glue for STM32F429 chip. -Enable basic Net config in kernel. Note that DT patches are not present because STM32 pinctrl code is not yet avalaible. Changes since v2: -Fix alphabetic order in Kconfig and Makefile. -Improve code according to Joachim review. -Binding: remove useless entry. Changes since v1: -Fix Kbuild issue in Kconfig. -Remove init/exit callbacks. Suspend/Resume and remove driver is no more driven in stmmac_pltfr but directly in dwmac-stm32 glue driver. -Take into account Joachim review. Regards. Alexandre. thanks Alex, for the series please consider my: Acked-by: Giuseppe Cavallaro Alexandre TORGUE (4): net: ethernet: dwmac: add Ethernet glue logic for stm32 chip Documentation: Bindings: Add STM32 DWMAC glue net: ethernet: stmmac: add support of Synopsys 3.50a MAC IP ARM: STM32: Enable Ethernet in stm32_defconfig .../devicetree/bindings/net/stm32-dwmac.txt| 40 + arch/arm/configs/stm32_defconfig | 9 + drivers/net/ethernet/stmicro/stmmac/Kconfig| 12 ++ drivers/net/ethernet/stmicro/stmmac/Makefile | 1 + drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c | 193 + .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 1 + 6 files changed, 256 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/stm32-dwmac.txt create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
Re: [PATCH 1/4] GMAC: add driver for Rockchip RK3288 SoCs integrated GMAC
Hello Roger
thx for these patches, my comments inline below
On 11/25/2014 10:07 AM, Roger Chen wrote:
This driver is based on stmmac driver.
Signed-off-by: Roger Chen
---
drivers/net/ethernet/stmicro/stmmac/Makefile |2 +-
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 629
.../net/ethernet/stmicro/stmmac/stmmac_platform.c |3 +
.../net/ethernet/stmicro/stmmac/stmmac_platform.h |1 +
4 files changed, 634 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile
b/drivers/net/ethernet/stmicro/stmmac/Makefile
index ac4d562..73c2715 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -6,7 +6,7 @@ stmmac-objs:= stmmac_main.o stmmac_ethtool.o stmmac_mdio.o
ring_mode.o \
obj-$(CONFIG_STMMAC_PLATFORM) += stmmac-platform.o
stmmac-platform-objs:= stmmac_platform.o dwmac-meson.o dwmac-sunxi.o \
- dwmac-sti.o dwmac-socfpga.o
+ dwmac-sti.o dwmac-socfpga.o dwmac-rk.o
obj-$(CONFIG_STMMAC_PCI) += stmmac-pci.o
stmmac-pci-objs:= stmmac_pci.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
new file mode 100644
index 000..9e50b37
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -0,0 +1,629 @@
+/**
+ * dwmac-rk.c - Rockchip RK3288 DWMAC specific glue layer
+ *
+ * Copyright (C) 2014 Chen-Zhi (Roger Chen)
+ *
+ * Chen-Zhi (Roger Chen)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct rk_priv_data {
+ struct platform_device *pdev;
+ int phy_iface;
+ bool power_ctrl_by_pmu;
+ char pmu_regulator[32];
+ int pmu_enable_level;
+
+ int power_io;
+ int power_io_level;
+ int reset_io;
+ int reset_io_level;
+ int phyirq_io;
+ int phyirq_io_level;
+
+ bool clk_enabled;
+ bool clock_input;
+
+ struct clk *clk_mac;
+ struct clk *clk_mac_pll;
+ struct clk *gmac_clkin;
+ struct clk *mac_clk_rx;
+ struct clk *mac_clk_tx;
+ struct clk *clk_mac_ref;
+ struct clk *clk_mac_refout;
+ struct clk *aclk_mac;
+ struct clk *pclk_mac;
+
+ int tx_delay;
+ int rx_delay;
+
+ struct regmap *grf;
+};
+
+#define RK3288_GRF_SOC_CON1 0x0248
+#define RK3288_GRF_SOC_CON3 0x0250
+#define RK3288_GRF_GPIO3D_E 0x01ec
+#define RK3288_GRF_GPIO4A_E 0x01f0
+#define RK3288_GRF_GPIO4B_E 0x01f4
+
+/*RK3288_GRF_SOC_CON1*/
+#define GMAC_PHY_INTF_SEL_RGMII ((0x01C0 << 16) | (0x0040))
+#define GMAC_PHY_INTF_SEL_RMII ((0x01C0 << 16) | (0x0100))
+#define GMAC_FLOW_CTRL ((0x0200 << 16) | (0x0200))
+#define GMAC_FLOW_CTRL_CLR ((0x0200 << 16) | (0x))
+#define GMAC_SPEED_10M ((0x0400 << 16) | (0x))
+#define GMAC_SPEED_100M ((0x0400 << 16) | (0x0400))
+#define GMAC_RMII_CLK_25M ((0x0800 << 16) | (0x0800))
+#define GMAC_RMII_CLK_2_5M ((0x0800 << 16) | (0x))
+#define GMAC_CLK_125M ((0x3000 << 16) | (0x))
+#define GMAC_CLK_25M((0x3000 << 16) | (0x3000))
+#define GMAC_CLK_2_5M ((0x3000 << 16) | (0x2000))
+#define GMAC_RMII_MODE ((0x4000 << 16) | (0x4000))
+#define GMAC_RMII_MODE_CLR ((0x4000 << 16) | (0x))
+
+/*RK3288_GRF_SOC_CON3*/
+#define GMAC_TXCLK_DLY_ENABLE ((0x4000 << 16) | (0x4000))
+#define GMAC_TXCLK_DLY_DISABLE ((0x4000 << 16) | (0x))
+#define GMAC_RXCLK_DLY_ENABLE ((0x8000 << 16) | (0x8000))
+#define GMAC_RXCLK_DLY_DISABLE ((0x8000 << 16) | (0x))
+#define GMAC_CLK_RX_DL_CFG(val) ((0x3F80 << 16) | (val<<7))
+#define GMAC_CLK_TX_DL_CFG(val) ((0x007F << 16) | (val))
why do not use BIT and BIT_MASK where possible?
+static void set_to_rgmii(struct rk_priv_data *bsp_priv,
+int tx_delay, int rx_delay)
+{
+ if (IS_ERR(bsp_priv->grf)) {
+ pr_err("%s: Missing rockchip,grf property\n", __func__);
+ return;
+ }
+
+ regmap_write(bsp_priv->grf, RK3288_GRF_SOC_CON1,
+GMAC_PHY_INTF_SEL_RGMII);
+ regmap_write(bsp_priv->grf, RK3288_GRF_SOC_CON1,
+GMAC_RMII_MODE_CLR);
maybe you could perform just one write unless there is some HW
constraint.
+ regmap_wri
Re: [PATCH 1/4] GMAC: add driver for Rockchip RK3288 SoCs integrated GMAC
On 11/26/2014 3:29 AM, Roger wrote:
Hi! Giuseppe CAVALLARO
在 2014/11/25 18:05, Giuseppe CAVALLARO 写道:
Hello Roger
thx for these patches, my comments inline below
On 11/25/2014 10:07 AM, Roger Chen wrote:
This driver is based on stmmac driver.
Signed-off-by: Roger Chen
---
drivers/net/ethernet/stmicro/stmmac/Makefile |2 +-
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 629
.../net/ethernet/stmicro/stmmac/stmmac_platform.c |3 +
.../net/ethernet/stmicro/stmmac/stmmac_platform.h |1 +
4 files changed, 634 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile
b/drivers/net/ethernet/stmicro/stmmac/Makefile
index ac4d562..73c2715 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -6,7 +6,7 @@ stmmac-objs:= stmmac_main.o stmmac_ethtool.o
stmmac_mdio.o ring_mode.o\
obj-$(CONFIG_STMMAC_PLATFORM) += stmmac-platform.o
stmmac-platform-objs:= stmmac_platform.o dwmac-meson.o
dwmac-sunxi.o\
- dwmac-sti.o dwmac-socfpga.o
+ dwmac-sti.o dwmac-socfpga.o dwmac-rk.o
obj-$(CONFIG_STMMAC_PCI) += stmmac-pci.o
stmmac-pci-objs:= stmmac_pci.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
new file mode 100644
index 000..9e50b37
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -0,0 +1,629 @@
+/**
+ * dwmac-rk.c - Rockchip RK3288 DWMAC specific glue layer
+ *
+ * Copyright (C) 2014 Chen-Zhi (Roger Chen)
+ *
+ * Chen-Zhi (Roger Chen)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct rk_priv_data {
+struct platform_device *pdev;
+int phy_iface;
+bool power_ctrl_by_pmu;
+char pmu_regulator[32];
+int pmu_enable_level;
+
+int power_io;
+int power_io_level;
+int reset_io;
+int reset_io_level;
+int phyirq_io;
+int phyirq_io_level;
+
+bool clk_enabled;
+bool clock_input;
+
+struct clk *clk_mac;
+struct clk *clk_mac_pll;
+struct clk *gmac_clkin;
+struct clk *mac_clk_rx;
+struct clk *mac_clk_tx;
+struct clk *clk_mac_ref;
+struct clk *clk_mac_refout;
+struct clk *aclk_mac;
+struct clk *pclk_mac;
+
+int tx_delay;
+int rx_delay;
+
+struct regmap *grf;
+};
+
+#define RK3288_GRF_SOC_CON1 0x0248
+#define RK3288_GRF_SOC_CON3 0x0250
+#define RK3288_GRF_GPIO3D_E 0x01ec
+#define RK3288_GRF_GPIO4A_E 0x01f0
+#define RK3288_GRF_GPIO4B_E 0x01f4
+
+/*RK3288_GRF_SOC_CON1*/
+#define GMAC_PHY_INTF_SEL_RGMII ((0x01C0 << 16) | (0x0040))
+#define GMAC_PHY_INTF_SEL_RMII ((0x01C0 << 16) | (0x0100))
+#define GMAC_FLOW_CTRL ((0x0200 << 16) | (0x0200))
+#define GMAC_FLOW_CTRL_CLR ((0x0200 << 16) | (0x))
+#define GMAC_SPEED_10M ((0x0400 << 16) | (0x))
+#define GMAC_SPEED_100M ((0x0400 << 16) | (0x0400))
+#define GMAC_RMII_CLK_25M ((0x0800 << 16) | (0x0800))
+#define GMAC_RMII_CLK_2_5M ((0x0800 << 16) | (0x))
+#define GMAC_CLK_125M ((0x3000 << 16) | (0x))
+#define GMAC_CLK_25M((0x3000 << 16) | (0x3000))
+#define GMAC_CLK_2_5M ((0x3000 << 16) | (0x2000))
+#define GMAC_RMII_MODE ((0x4000 << 16) | (0x4000))
+#define GMAC_RMII_MODE_CLR ((0x4000 << 16) | (0x))
+
+/*RK3288_GRF_SOC_CON3*/
+#define GMAC_TXCLK_DLY_ENABLE ((0x4000 << 16) | (0x4000))
+#define GMAC_TXCLK_DLY_DISABLE ((0x4000 << 16) | (0x))
+#define GMAC_RXCLK_DLY_ENABLE ((0x8000 << 16) | (0x8000))
+#define GMAC_RXCLK_DLY_DISABLE ((0x8000 << 16) | (0x))
+#define GMAC_CLK_RX_DL_CFG(val) ((0x3F80 << 16) | (val<<7))
+#define GMAC_CLK_TX_DL_CFG(val) ((0x007F << 16) | (val))
why do not use BIT and BIT_MASK where possible?
+static void set_to_rgmii(struct rk_priv_data *bsp_priv,
+ int tx_delay, int rx_delay)
+{
+if (IS_ERR(bsp_priv->grf)) {
+pr_err("%s: Missing rockchip,grf property\n", __func__);
+return;
+}
+
+regmap_write(bsp_priv->grf, RK3288_GRF_SOC_CON1,
+ GMAC_PHY_INTF_SEL_RGMII);
+regmap_write(bsp_priv->grf, RK3288_GRF_SOC_CON1,
+ GMAC_RMII_MOD
Re: [PATCH net] stmmac: correct mc_filter local variable in set_filter and set_mac_addr call
On 10/9/2014 5:10 PM, Vince Bridgers wrote:
Testing revealed that the local variable mc_filter was dimensioned
incorrectly for all possible configurations and get_mac_addr should
have been set_mac_addr (a typo). Make sure mc_filter is dimensioned
to 8 32-bit unsigned longs - the largest size of the Synopsys
multicast filter register set.
Signed-off-by: Vince Bridgers
Acked-by: Giuseppe Cavallaro
---
drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index 5efe60e..0adcf73 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -134,7 +134,7 @@ static void dwmac1000_set_filter(struct mac_device_info *hw,
void __iomem *ioaddr = (void __iomem *)dev->base_addr;
unsigned int value = 0;
unsigned int perfect_addr_number = hw->unicast_filter_entries;
- u32 mc_filter[2];
+ u32 mc_filter[8];
int mcbitslog2 = hw->mcast_bits_log2;
pr_debug("%s: # mcasts %d, # unicast %d\n", __func__,
@@ -182,7 +182,7 @@ static void dwmac1000_set_filter(struct mac_device_info *hw,
struct netdev_hw_addr *ha;
netdev_for_each_uc_addr(ha, dev) {
- stmmac_get_mac_addr(ioaddr, ha->addr,
+ stmmac_set_mac_addr(ioaddr, ha->addr,
GMAC_ADDR_HIGH(reg),
GMAC_ADDR_LOW(reg));
reg++;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next V2 17/23] ptp: stmmac: convert to the 64 bit get/set time methods.
On 3/21/2015 10:39 PM, Richard Cochran wrote:
This device stores the number of seconds in a 32 bit register. So
more work is needed on this driver before the year 2038 comes around.
Compile tested only.
I cannot perform tests on my side, unfortunately. I have no setup at
this moment. Added Rayagond on copy too
Peppe
Signed-off-by: Richard Cochran
---
drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
index c5ee79d8..172f318 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
@@ -105,7 +105,7 @@ static int stmmac_adjust_time(struct ptp_clock_info *ptp,
s64 delta)
* Description: this function will read the current time from the
* hardware clock and store it in @ts.
*/
-static int stmmac_get_time(struct ptp_clock_info *ptp, struct timespec *ts)
+static int stmmac_get_time(struct ptp_clock_info *ptp, struct timespec64 *ts)
{
struct stmmac_priv *priv =
container_of(ptp, struct stmmac_priv, ptp_clock_ops);
@@ -135,7 +135,7 @@ static int stmmac_get_time(struct ptp_clock_info *ptp,
struct timespec *ts)
* hardware clock.
*/
static int stmmac_set_time(struct ptp_clock_info *ptp,
- const struct timespec *ts)
+ const struct timespec64 *ts)
{
struct stmmac_priv *priv =
container_of(ptp, struct stmmac_priv, ptp_clock_ops);
@@ -168,8 +168,8 @@ static struct ptp_clock_info stmmac_ptp_clock_ops = {
.pps = 0,
.adjfreq = stmmac_adjust_freq,
.adjtime = stmmac_adjust_time,
- .gettime = stmmac_get_time,
- .settime = stmmac_set_time,
+ .gettime64 = stmmac_get_time,
+ .settime64 = stmmac_set_time,
.enable = stmmac_enable,
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] net: stmmac: add BQL support
On 1/21/2015 7:07 PM, Beniamino Galvani wrote:
Add support for Byte Queue Limits to the STMicro MAC driver.
Tested on a Amlogic S802 quad Cortex-A9 board, where the use of BQL
decreases the latency of a high priority ping from ~12ms to ~1ms when
the 100Mbit link is saturated by 20 TCP streams.
Signed-off-by: Beniamino Galvani
Ciao Beniamino
thx for the patch, I also see some improvements on my side
Acked-by: Giuseppe Cavallaro
---
Changes since v1:
- don't access skb->len after the start of DMA transmission in
stmmac_xmit(), to avoid potential use after free in case tx_lock is
removed in the future
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 118a427..1d74313 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1097,6 +1097,7 @@ static int init_dma_desc_rings(struct net_device *dev,
gfp_t flags)
priv->dirty_tx = 0;
priv->cur_tx = 0;
+ netdev_reset_queue(priv->dev);
stmmac_clear_descriptors(priv);
@@ -1300,6 +1301,7 @@ static void stmmac_dma_operation_mode(struct stmmac_priv
*priv)
static void stmmac_tx_clean(struct stmmac_priv *priv)
{
unsigned int txsize = priv->dma_tx_size;
+ unsigned int bytes_compl = 0, pkts_compl = 0;
spin_lock(&priv->tx_lock);
@@ -1356,6 +1358,8 @@ static void stmmac_tx_clean(struct stmmac_priv *priv)
priv->hw->mode->clean_desc3(priv, p);
if (likely(skb != NULL)) {
+ pkts_compl++;
+ bytes_compl += skb->len;
dev_consume_skb_any(skb);
priv->tx_skbuff[entry] = NULL;
}
@@ -1364,6 +1368,9 @@ static void stmmac_tx_clean(struct stmmac_priv *priv)
priv->dirty_tx++;
}
+
+ netdev_completed_queue(priv->dev, pkts_compl, bytes_compl);
+
if (unlikely(netif_queue_stopped(priv->dev) &&
stmmac_tx_avail(priv) > STMMAC_TX_THRESH(priv))) {
netif_tx_lock(priv->dev);
@@ -1418,6 +1425,7 @@ static void stmmac_tx_err(struct stmmac_priv *priv)
(i == txsize - 1));
priv->dirty_tx = 0;
priv->cur_tx = 0;
+ netdev_reset_queue(priv->dev);
priv->hw->dma->start_tx(priv->ioaddr);
priv->dev->stats.tx_errors++;
@@ -2048,6 +2056,7 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb,
struct net_device *dev)
if (!priv->hwts_tx_en)
skb_tx_timestamp(skb);
+ netdev_sent_queue(dev, skb->len);
priv->hw->dma->enable_dma_transmission(priv->ioaddr);
spin_unlock(&priv->tx_lock);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement
Hello Tomeu, Andreas, On 3/9/2016 10:52 AM, Giuseppe CAVALLARO wrote: * today's linux-next: probe failed * today's linux-next + revert of 88f8b1bb41c6 stmmac: Fix 'eth0: No PHY found' regression: probe succeeded but no network at all * today's linux-next + revert of 88f8b1bb41c6 (stmmac: Fix 'eth0: No PHY found' regression) + revert of 0e80bdc9a72d (stmmac: first frame prep at the end of xmit routine): probe succeeded, dhcp succeeds and nfsroot works for a few seconds before timing out ok, I was looking at this problem now that seems to related the "stmmac: first frame prep at the end of xmit routine" that, at first glance, is breaking the gmac 3.50 with normal descriptor. I have no Hw where to test this use case. So, I wonder if may I ask you to test some patch. This first patch adds a missing barrier to the normal routine that inits the descriptor. Barrier was needed to well manage the OWN descriptor and it was not added in case of normal desc case after the xmit rework. Then I will check the algo behind the new xmit and in case of problems, if you agree, we will decide to revert it because it aimed to add an optimization. Let me know if you agree. Regards Peppe diff --git a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c index e13228f..4392610 100644 --- a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c +++ b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c @@ -210,7 +210,7 @@ static void ndesc_prepare_tx_desc(struct dma_desc *p, int is_fs, int len, tdes1 &= ~TDES1_FIRST_SEGMENT; if (likely(csum_flag)) - tdes1 |= (TX_CIC_FULL) << TDES1_CHECKSUM_INSERTION_SHIFT; + tdes1 |= (TX_CIC_FULL << TDES1_CHECKSUM_INSERTION_SHIFT); else tdes1 &= ~(TX_CIC_FULL << TDES1_CHECKSUM_INSERTION_SHIFT); @@ -220,6 +220,13 @@ static void ndesc_prepare_tx_desc(struct dma_desc *p, int is_fs, int len, if (tx_own) tdes1 |= TDES0_OWN; + if (is_fs & tx_own) + /* When the own bit, for the first frame, has to be set, all + * descriptors for the same frame has to be set before, to + * avoid race condition. + */ + wmb(); + p->des1 = tdes1; }
Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement
Hi Tomeu On 3/9/2016 11:53 AM, Tomeu Vizoso wrote: On 9 March 2016 at 11:27, Giuseppe CAVALLARO wrote: Hello Tomeu, Andreas, On 3/9/2016 10:52 AM, Giuseppe CAVALLARO wrote: * today's linux-next: probe failed * today's linux-next + revert of 88f8b1bb41c6 stmmac: Fix 'eth0: No PHY found' regression: probe succeeded but no network at all * today's linux-next + revert of 88f8b1bb41c6 (stmmac: Fix 'eth0: No PHY found' regression) + revert of 0e80bdc9a72d (stmmac: first frame prep at the end of xmit routine): probe succeeded, dhcp succeeds and nfsroot works for a few seconds before timing out ok, I was looking at this problem now that seems to related the "stmmac: first frame prep at the end of xmit routine" that, at first glance, is breaking the gmac 3.50 with normal descriptor. I have no Hw where to test this use case. So, I wonder if may I ask you to test some patch. This first patch adds a missing barrier to the normal routine that inits the descriptor. Barrier was needed to well manage the OWN descriptor and it was not added in case of normal desc case after the xmit rework. Then I will check the algo behind the new xmit and in case of problems, if you agree, we will decide to revert it because it aimed to add an optimization. Let me know if you agree. I'm not sure what you would like to be tested, but just in case, I have just tried your patch on top of these commits and the result is the "transmit queue 0 timed out" error during boot: 6542b30d0a67 Revert "stmmac: first frame prep at the end of xmit routine" eb5274cbc0f7 Revert "stmmac: do not poll phy handler when attach a switch" e88e625a68d9 Revert "stmmac: fix phy init when attached to a phy" ef5dd3777876 stmmac: fix MDIO settings 77634ba1f25c Revert "stmmac: Fix 'eth0: No PHY found' regression" 7811b4ffc312 Add linux-next specific files for 20160309 I missed that the issue is not only related the "stmmac: first frame prep at the end of xmit routine" I have to try to test on 3.50 with normal descriptor. When using enhanced descriptors all works fine on my side. I keep you informed. peppe Regards, Tomeu Regards Peppe
Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement
Hi Tomeu, Dinh, Andreas I need a sum and help from you to go ahead on the tx timeout. The "stmmac: MDIO fixes" seems to be the candidate to fix the phy connection and I will send the V2 asap (Andreas' comment). So, supposing the probe is ok and phy is connected, I need your input ... Tomeu: after revering the 0e80bdc9a72d (stmmac: first frame prep at the end of xmit routine) the network is not stable and there is a timeout after a while. The box has 3.50 with normal desc settings. Dinh: the network is ok, I wonder if you can share a boot log just to understand if the normal or enhanced descriptors are used. Andreas: you are also using 3.50 with normal desc but I have not clear if just reverting 0e80bdc9a72d commit the network is ok or you see timeout issues. In the meantime I am trying to find a box where try normal setup and I can confirm that enhanced descriptors are ok on my side Regards Peppe On 3/9/2016 3:31 PM, Giuseppe CAVALLARO wrote: Hi Tomeu On 3/9/2016 11:53 AM, Tomeu Vizoso wrote: On 9 March 2016 at 11:27, Giuseppe CAVALLARO wrote: Hello Tomeu, Andreas, On 3/9/2016 10:52 AM, Giuseppe CAVALLARO wrote: * today's linux-next: probe failed * today's linux-next + revert of 88f8b1bb41c6 stmmac: Fix 'eth0: No PHY found' regression: probe succeeded but no network at all * today's linux-next + revert of 88f8b1bb41c6 (stmmac: Fix 'eth0: No PHY found' regression) + revert of 0e80bdc9a72d (stmmac: first frame prep at the end of xmit routine): probe succeeded, dhcp succeeds and nfsroot works for a few seconds before timing out ok, I was looking at this problem now that seems to related the "stmmac: first frame prep at the end of xmit routine" that, at first glance, is breaking the gmac 3.50 with normal descriptor. I have no Hw where to test this use case. So, I wonder if may I ask you to test some patch. This first patch adds a missing barrier to the normal routine that inits the descriptor. Barrier was needed to well manage the OWN descriptor and it was not added in case of normal desc case after the xmit rework. Then I will check the algo behind the new xmit and in case of problems, if you agree, we will decide to revert it because it aimed to add an optimization. Let me know if you agree. I'm not sure what you would like to be tested, but just in case, I have just tried your patch on top of these commits and the result is the "transmit queue 0 timed out" error during boot: 6542b30d0a67 Revert "stmmac: first frame prep at the end of xmit routine" eb5274cbc0f7 Revert "stmmac: do not poll phy handler when attach a switch" e88e625a68d9 Revert "stmmac: fix phy init when attached to a phy" ef5dd3777876 stmmac: fix MDIO settings 77634ba1f25c Revert "stmmac: Fix 'eth0: No PHY found' regression" 7811b4ffc312 Add linux-next specific files for 20160309 I missed that the issue is not only related the "stmmac: first frame prep at the end of xmit routine" I have to try to test on 3.50 with normal descriptor. When using enhanced descriptors all works fine on my side. I keep you informed. peppe Regards, Tomeu Regards Peppe
Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement
On 3/9/2016 5:31 PM, Dinh Nguyen wrote: On Wed, Mar 9, 2016 at 8:53 AM, Giuseppe CAVALLARO wrote: Hi Tomeu, Dinh, Andreas I need a sum and help from you to go ahead on the tx timeout. The "stmmac: MDIO fixes" seems to be the candidate to fix the phy connection and I will send the V2 asap (Andreas' comment). So, supposing the probe is ok and phy is connected, I need your input ... Tomeu: after revering the 0e80bdc9a72d (stmmac: first frame prep at the end of xmit routine) the network is not stable and there is a timeout after a while. The box has 3.50 with normal desc settings. Dinh: the network is ok, I wonder if you can share a boot log just to understand if the normal or enhanced descriptors are used. Here it is: ... [0.850523] stmmac - user ID: 0x10, Synopsys ID: 0x37 [0.855570] Ring mode enabled [0.858611] DMA HW capability register supported [0.863128] Enhanced/Alternate descriptors [0.867482] Enabled extended descriptors [0.871482] RX Checksum Offload Engine supported (type 2) [0.876948] TX Checksum insertion supported [0.881204] Enable RX Mitigation via HW Watchdog Timer [0.886863] socfpga-dwmac ff702000.ethernet eth0: No MDIO subnode found [0.899090] libphy: stmmac: probed [0.902484] eth0: PHY ID 00221611 at 4 IRQ POLL (stmmac-0:04) active Thx Dinh, so you are using the Enhanced/Alternate descriptors I am debugging on my side on a setup with normal descriptors, I let you know peppe
Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement
Hello Tomeu
On 3/15/2016 8:23 AM, Tomeu Vizoso wrote:
Thanks.
Btw, I have rebased on top of 4.5 this morning and I have noticed that
88f8b1bb41c6 ("stmmac: Fix 'eth0: No PHY found' regression") got in
there, so I guess we have now a bunch of boards with broken network on
that release:(
This is the status on my side: I am testing on an HW that has the
Enhanced descriptors and all works fine.
On this HW, if I force the driver to use the normal descriptor
layout, I meet problems but using both net.git and net-next.
So I suspect I cannot ply with this HW forcing the normal descriptors.
But! That is helping me to check if, on net-next, the stmmac is
actually programming fine the normal desc case.
I have just found another fix so I kindly ask you to apply the temp
patch attached and let me know.
In details, I have noticed that the OWN bit was not set in the right
TDES0.
I also ask you to give me a log of the kernel where the stmmac was
running fine. I would like to see which configuration it is selected
at runtime by the driver on your box.
From your previous logs (where the stmmac failed), it seems that
the problem is on normal desc but, to be honest, this is the first
case I see a 3.50a with HW capability register and w/o Enhanced
descriptors.
Best Regards
Peppe
Regards,
Tomeu
diff --git a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
index e13228f..44c052f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
@@ -217,10 +217,10 @@ static void ndesc_prepare_tx_desc(struct dma_desc *p, int is_fs, int len,
if (ls)
tdes1 |= TDES1_LAST_SEGMENT;
- if (tx_own)
- tdes1 |= TDES0_OWN;
-
p->des1 = tdes1;
+
+ if (tx_own)
+ p->des0 |= TDES0_OWN;
}
static void ndesc_set_tx_ic(struct dma_desc *p)
Re: [PATCH v2] ARC: axs10x - add Ethernet PHY description in .dts
On 4/6/2016 11:12 AM, Vineet Gupta wrote:
Hi,
On Thursday 17 March 2016 03:11 PM, Alexey Brodkin wrote:
Following commit broke DW GMAC functionality on AXS10x boards:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e34d65696d2ef13dc32f2a162556c86c461ed763
That's what happens on eth0 up:
--->8
libphy: PHY stmmac-0: not found
eth0: Could not attach to PHY
stmmac_open: Cannot attach to PHY (error: -19)
--->8
Simplest solution is to add PHY description in board's .dts.
And so we do here.
Signed-off-by: Alexey Brodkin
Cc: Rob Herring
Cc: Phil Reid
Cc: David S. Miller
Cc: linux-kernel@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: sta...@vger.kernel.org # 4.5.x
Cc: Sergei Shtylyov
---
Changes v1 -> v2:
* PHY node name changed to match real PHY number being used (Sergei)
arch/arc/boot/dts/axs10x_mb.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
index 44a578c..ab5d570 100644
--- a/arch/arc/boot/dts/axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/axs10x_mb.dtsi
@@ -47,6 +47,14 @@
clocks = <&apbclk>;
clock-names = "stmmaceth";
max-speed = <100>;
+ mdio0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+ };
};
ehci@0x4 {
So above DT fix for ARC went into 4.6-rc1 and ethernet was still broken on
axs103
board.
-->8-
libphy: PHY stmmac-0: not found
eth0: Could not attach to PHY
stmmac_open: Cannot attach to PHY (error: -19)
-->8-
On 4.6-rc2 if I revert the DT change, ethernet works again.
@Giuseppe, @Phil, @Gabriel, I see you have made changes in that area. I presume
that above revert is the right/sufficient thing or do we need to do something
else
as well.
hmm I think so, we pushed all the changes in net-next to fix the MDIO
initialization according to the different DT parameter settings. So
unless there is some other case to cover, I think that the best
approach is to do the revert.
pls, let me know
peppe
TIA,
-Vineet
Re: [PATCH v5 2/4] Documentation: Bindings: Add STM32 DWMAC glue
On 3/22/2016 5:11 PM, Alexandre Torgue wrote: Hi guys, I will fix typo issues (s/vesrion/version and ethernet @). Concerning compatible string. For sure "snps,dwmac-3.50a" string is not used inside glue driver. I perfere to keep it for information but if you really want that I remove it I will not block ;) 2016-03-21 16:36 GMT+01:00 Joachim Eastwood : On 21 March 2016 at 13:40, Rob Herring wrote: On Sat, Mar 19, 2016 at 12:00:22AM +0800, Chen-Yu Tsai wrote: Hi, On Fri, Mar 18, 2016 at 11:37 PM, Alexandre TORGUE wrote: +- clocks: Must contain a phandle for each entry in clock-names. +- clock-names: Should be "stmmaceth" for the host clock. We can remove host clock (stmmac eth) entry here and refer to stmmac.txt binding for common entry This doesn't sound like the clock input signal name... + Should be "tx-clk" for the MAC TX clock. + Should be "rx-clk" for the MAC RX clock. How can other DWMAC blocks not have these clocks? The glue can't really add these clocks. It could combine them into one or a new version of DWMAC could have a different number of clock inputs. So if there is variation here, then some of the bindings are probably wrong. I guess the only change I'm suggesting is possibly moving these into common binding doc. The LPC18xx implementation probably have these clocks as well but the LPC1850 user manual only documents the main clock. Someone with access to the IP block doc from Synopsys should be able to check which clocks the MAC really needs. Rockchip bindings have two clocks named "mac_clk_rx" and "mac_clk_tx". These are probably the same as stm32 needs so maybe use these names and move them into the main doc and update the rockchip binding. I think we can use same name. But I have a doubt on moving it in a common bindings (maybe I don't well understood). When you say "common binding file" is it "stmmac.txt" binding ? If yes does it mean that we have to control it inside stmmac driver (no more in glue) ? In this case those clocks will become "required" for stm32 and rockship but not for others chip. It could create confusion? Currently we keep the "host" and "csr" " ptp "clock from common bindings because directly connected to the either MAC core or optional internals modules. Indeed, also clk_tx_i and clk_rx_i could be treated in the same way. but... (my personal view). Many platforms, also inside STi, have different clock routing schema, so we could relax them giving each glue the way to internally manage all (as done nowadays). So these clocks can stay inside the glue and documented inside each binding doc. Maybe, it could be not so easy to have generic schema suitable for all the glues so documenting all inside the same binding text file. We could try to better name these clocks in each glue. For example, for this, although I do not know the clk schema, I can image a single rmii_clk (maybe from internal oscillator) that is connected to clk_tx_i and clk_rx_i. So it could be useless to pass both. Please let me know if I am wrong... In case of (G)MII, we should use something like (g)mii_tx_clk, (g)mii_rx_clk according to the real connections (if from an internal oscillator and not from an ext one connected to the phy). Regards, Peppe Best regards Alex regards, Joachim Eastwood
Re: [PATCH] stmmac: Fix phy without MDIO subnode
Hello Robert On 3/30/2016 8:22 PM, Robert Gadsdon wrote: I have applied this to my Rock2 - Kernel 4.6-rc1 - and eth0 is present, now, but no network traffic gets through: there are some patches not yet applied that fix known problems pls take a look at : "stmmac: MDIO fixes" and [PATCH (net-next.git)] STMMAC: fix TX Normal descriptor peppe To rock2: $ ping rgrock2 PING rgrock2 (192.168.0.xx) 56(84) bytes of data. ^C --- rgrock2 ping statistics --- 9 packets transmitted, 0 received, 100% packet loss, time 7999ms From rock2: # ping 192.168.0.x PING 192.168.0.x (192.168.0.2) 56(84) bytes of data. From 192.168.0.xx icmp_seq=1 Destination Host Unreachable From 192.168.0.xx icmp_seq=2 Destination Host Unreachable From 192.168.0.xx icmp_seq=3 Destination Host Unreachable From 192.168.0.xx icmp_seq=4 Destination Host Unreachable From 192.168.0.xx icmp_seq=5 Destination Host Unreachable From 192.168.0.xx icmp_seq=6 Destination Host Unreachable From 192.168.0.xx icmp_seq=7 Destination Host Unreachable From 192.168.0.xx icmp_seq=8 Destination Host Unreachable --- 192.168.0.x ping statistics --- 9 packets transmitted, 0 received, +8 errors, 100% packet loss, time 8001ms Everything worked OK with kernel 4.5-rc7, and with 4.5 Final with the -rc7 versions of stmmac_platform.c and stmmac_mdio.c substituted.. Robert Gadsdon. March 30, 2016
Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement
On 3/30/2016 6:44 PM, Dinh Nguyen wrote:
On Tue, Mar 15, 2016 at 7:36 AM, Giuseppe CAVALLARO
wrote:
Hello Tomeu
On 3/15/2016 8:23 AM, Tomeu Vizoso wrote:
Thanks.
Btw, I have rebased on top of 4.5 this morning and I have noticed that
88f8b1bb41c6 ("stmmac: Fix 'eth0: No PHY found' regression") got in
there, so I guess we have now a bunch of boards with broken network on
that release:(
This is the status on my side: I am testing on an HW that has the
Enhanced descriptors and all works fine.
On this HW, if I force the driver to use the normal descriptor
layout, I meet problems but using both net.git and net-next.
So I suspect I cannot ply with this HW forcing the normal descriptors.
But! That is helping me to check if, on net-next, the stmmac is
actually programming fine the normal desc case.
I have just found another fix so I kindly ask you to apply the temp
patch attached and let me know.
In details, I have noticed that the OWN bit was not set in the right
TDES0.
I also ask you to give me a log of the kernel where the stmmac was
running fine. I would like to see which configuration it is selected
at runtime by the driver on your box.
From your previous logs (where the stmmac failed), it seems that
the problem is on normal desc but, to be honest, this is the first
case I see a 3.50a with HW capability register and w/o Enhanced
descriptors.
Are you still working on a fix for:
[1.196110] libphy: PHY stmmac-0: not found
[1.200972] eth0: Could not attach to PHY
[1.204991] stmmac_open: Cannot attach to PHY (error: -19)
I see the error still there as of linux-next 20160330.
this could be because the fixes have been not applied on net-next
I will check and resend all asap
peppe
Dinh
[PATCH (net.git) 0/3] stmmac MDIO and normal descr fixes
This patch series is to fix the problems below and recently debugged in this mailing list: o to fix a problem for the HW where the normal descriptor o to fix the mdio registration according to the different platform configurations I am resending all the patches again: built on top of net.git repo. Giuseppe Cavallaro (3): stmmac: fix TX normal DESC Revert "stmmac: Fix 'eth0: No PHY found' regression" stmmac: fix MDIO settings drivers/net/ethernet/stmicro/stmmac/norm_desc.c| 16 ++-- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 16 +--- drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 10 +-- .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 91 ++-- include/linux/stmmac.h |1 - 5 files changed, 80 insertions(+), 54 deletions(-) -- 1.7.4.4
[PATCH (net.git) 3/3] stmmac: fix MDIO settings
Initially the phy_bus_name was added to manipulate the
driver name but it was recently just used to manage the
fixed-link and then to take some decision at run-time.
So the patch uses the is_pseudo_fixed_link and removes
the phy_bus_name variable not necessary anymore.
The driver can manage the mdio registration by using phy-handle,
dwmac-mdio and own parameter e.g. snps,phy-addr.
This patch takes care about all these possible configurations
and fixes the mdio registration in case of there is a real
transceiver or a switch (that needs to be managed by using
fixed-link).
Signed-off-by: Giuseppe Cavallaro
Reviewed-by: Andreas Färber
Tested-by: Frank Schäfer
Cc: Gabriel Fernandez
Cc: Dinh Nguyen
Cc: David S. Miller
Cc: Phil Reid
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 16 +---
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 19 +
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 84 +++
include/linux/stmmac.h |2 +-
4 files changed, 73 insertions(+), 48 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 4c5ce98..78464fa 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -278,7 +278,6 @@ static void stmmac_eee_ctrl_timer(unsigned long arg)
*/
bool stmmac_eee_init(struct stmmac_priv *priv)
{
- char *phy_bus_name = priv->plat->phy_bus_name;
unsigned long flags;
bool ret = false;
@@ -290,7 +289,7 @@ bool stmmac_eee_init(struct stmmac_priv *priv)
goto out;
/* Never init EEE in case of a switch is attached */
- if (phy_bus_name && (!strcmp(phy_bus_name, "fixed")))
+ if (priv->phydev->is_pseudo_fixed_link)
goto out;
/* MAC core supports the EEE feature. */
@@ -827,12 +826,8 @@ static int stmmac_init_phy(struct net_device *dev)
phydev = of_phy_connect(dev, priv->plat->phy_node,
&stmmac_adjust_link, 0, interface);
} else {
- if (priv->plat->phy_bus_name)
- snprintf(bus_id, MII_BUS_ID_SIZE, "%s-%x",
-priv->plat->phy_bus_name, priv->plat->bus_id);
- else
- snprintf(bus_id, MII_BUS_ID_SIZE, "stmmac-%x",
-priv->plat->bus_id);
+ snprintf(bus_id, MII_BUS_ID_SIZE, "stmmac-%x",
+priv->plat->bus_id);
snprintf(phy_id_fmt, MII_BUS_ID_SIZE + 3, PHY_ID_FMT, bus_id,
priv->plat->phy_addr);
@@ -871,9 +866,8 @@ static int stmmac_init_phy(struct net_device *dev)
}
/* If attached to a switch, there is no reason to poll phy handler */
- if (priv->plat->phy_bus_name)
- if (!strcmp(priv->plat->phy_bus_name, "fixed"))
- phydev->irq = PHY_IGNORE_INTERRUPT;
+ if (phydev->is_pseudo_fixed_link)
+ phydev->irq = PHY_IGNORE_INTERRUPT;
pr_debug("stmmac_init_phy: %s: attached to PHY (UID 0x%x)"
" Link = %d\n", dev->name, phydev->phy_id, phydev->link);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index af09ced..06704ca 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -198,29 +198,12 @@ int stmmac_mdio_register(struct net_device *ndev)
struct mii_bus *new_bus;
struct stmmac_priv *priv = netdev_priv(ndev);
struct stmmac_mdio_bus_data *mdio_bus_data = priv->plat->mdio_bus_data;
+ struct device_node *mdio_node = priv->plat->mdio_node;
int addr, found;
- struct device_node *mdio_node = NULL;
- struct device_node *child_node = NULL;
if (!mdio_bus_data)
return 0;
- if (IS_ENABLED(CONFIG_OF)) {
- for_each_child_of_node(priv->device->of_node, child_node) {
- if (of_device_is_compatible(child_node,
- "snps,dwmac-mdio")) {
- mdio_node = child_node;
- break;
- }
- }
-
- if (mdio_node) {
- netdev_dbg(ndev, "FOUND MDIO subnode\n");
- } else {
- netdev_warn(ndev, "No MDIO subnode found\n");
- }
- }
-
new_bus = mdiobus_alloc();
if (new_bus == NULL)
return -ENOMEM;
diff --git a/drivers/net/ethernet/stmicro
[PATCH (net.git) 2/3] Revert "stmmac: Fix 'eth0: No PHY found' regression"
This reverts commit 88f8b1bb41c6208f81b6a480244533ded7b59493.
due to problems on GeekBox and Banana Pi M1 board when
connected to a real transceiver instead of a switch via
fixed-link.
Signed-off-by: Giuseppe Cavallaro
Cc: Gabriel Fernandez
Cc: Andreas Färber
Cc: Frank Schäfer
Cc: Dinh Nguyen
Cc: David S. Miller
---
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 11 ++-
.../net/ethernet/stmicro/stmmac/stmmac_platform.c |9 +
include/linux/stmmac.h |1 -
3 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index ea76129..af09ced 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -199,12 +199,21 @@ int stmmac_mdio_register(struct net_device *ndev)
struct stmmac_priv *priv = netdev_priv(ndev);
struct stmmac_mdio_bus_data *mdio_bus_data = priv->plat->mdio_bus_data;
int addr, found;
- struct device_node *mdio_node = priv->plat->mdio_node;
+ struct device_node *mdio_node = NULL;
+ struct device_node *child_node = NULL;
if (!mdio_bus_data)
return 0;
if (IS_ENABLED(CONFIG_OF)) {
+ for_each_child_of_node(priv->device->of_node, child_node) {
+ if (of_device_is_compatible(child_node,
+ "snps,dwmac-mdio")) {
+ mdio_node = child_node;
+ break;
+ }
+ }
+
if (mdio_node) {
netdev_dbg(ndev, "FOUND MDIO subnode\n");
} else {
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index dcbd2a1..9cf181f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -146,7 +146,6 @@ stmmac_probe_config_dt(struct platform_device *pdev, const
char **mac)
struct device_node *np = pdev->dev.of_node;
struct plat_stmmacenet_data *plat;
struct stmmac_dma_cfg *dma_cfg;
- struct device_node *child_node = NULL;
plat = devm_kzalloc(&pdev->dev, sizeof(*plat), GFP_KERNEL);
if (!plat)
@@ -177,19 +176,13 @@ stmmac_probe_config_dt(struct platform_device *pdev,
const char **mac)
plat->phy_node = of_node_get(np);
}
- for_each_child_of_node(np, child_node)
- if (of_device_is_compatible(child_node, "snps,dwmac-mdio")) {
- plat->mdio_node = child_node;
- break;
- }
-
/* "snps,phy-addr" is not a standard property. Mark it as deprecated
* and warn of its use. Remove this when phy node support is added.
*/
if (of_property_read_u32(np, "snps,phy-addr", &plat->phy_addr) == 0)
dev_warn(&pdev->dev, "snps,phy-addr property is deprecated\n");
- if ((plat->phy_node && !of_phy_is_fixed_link(np)) || !plat->mdio_node)
+ if ((plat->phy_node && !of_phy_is_fixed_link(np)) || plat->phy_bus_name)
plat->mdio_bus_data = NULL;
else
plat->mdio_bus_data =
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 4bcf5a6..6e53fa8 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -114,7 +114,6 @@ struct plat_stmmacenet_data {
int interface;
struct stmmac_mdio_bus_data *mdio_bus_data;
struct device_node *phy_node;
- struct device_node *mdio_node;
struct stmmac_dma_cfg *dma_cfg;
int clk_csr;
int has_gmac;
--
1.7.4.4
[PATCH (net.git) 1/3] stmmac: fix TX normal DESC
This patch fixs a regression raised when test on chips that use
the normal descriptor layout. In fact, no len bits were set for
the TDES1 and no OWN bit inside the TDES0.
Signed-off-by: Giuseppe CAVALLARO
Tested-by: Andreas Färber
Cc: Fabrice Gasnier
---
drivers/net/ethernet/stmicro/stmmac/norm_desc.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
index e13228f..011386f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
@@ -199,11 +199,6 @@ static void ndesc_prepare_tx_desc(struct dma_desc *p, int
is_fs, int len,
{
unsigned int tdes1 = p->des1;
- if (mode == STMMAC_CHAIN_MODE)
- norm_set_tx_desc_len_on_chain(p, len);
- else
- norm_set_tx_desc_len_on_ring(p, len);
-
if (is_fs)
tdes1 |= TDES1_FIRST_SEGMENT;
else
@@ -217,10 +212,15 @@ static void ndesc_prepare_tx_desc(struct dma_desc *p, int
is_fs, int len,
if (ls)
tdes1 |= TDES1_LAST_SEGMENT;
- if (tx_own)
- tdes1 |= TDES0_OWN;
-
p->des1 = tdes1;
+
+ if (mode == STMMAC_CHAIN_MODE)
+ norm_set_tx_desc_len_on_chain(p, len);
+ else
+ norm_set_tx_desc_len_on_ring(p, len);
+
+ if (tx_own)
+ p->des0 |= TDES0_OWN;
}
static void ndesc_set_tx_ic(struct dma_desc *p)
--
1.7.4.4
Re: [PATCH 2/5] regulator: st-flashss: Add a regulator driver for flashss vsense.
On 4/13/2016 8:15 AM, Mark Brown wrote:
>+static void st_get_satinize_powerup_voltage(struct st_vsense *vsense)
>+{
>+ void __iomem *ioaddr = vsense->ioaddr;
>+ u32 value = readl_relaxed(ioaddr);
>+
>+ dev_dbg(vsense->dev, "Initial start-up value: (0x%08x)\n", value);
>+
>+ /* Sanitize voltage values forcing what is provided from start-up */
>+ if (value & TOP_VSENSE_CONFIG_LATCHED_PSW_EMMC)
>+ value |= TOP_VSENSE_CONFIG_REG_PSW_EMMC;
>+ else
>+ value &= ~TOP_VSENSE_CONFIG_REG_PSW_EMMC;
>+
>+ if (value & TOP_VSENSE_CONFIG_LATCHED_PSW_NAND)
>+ value |= TOP_VSENSE_CONFIG_REG_PSW_NAND;
>+ else
>+ value &= ~TOP_VSENSE_CONFIG_REG_PSW_NAND;
>+
>+ if (value & TOP_VSENSE_CONFIG_LATCHED_PSW_SPI)
>+ value |= TOP_VSENSE_CONFIG_REG_PSW_SPI;
>+ else
>+ value &= ~TOP_VSENSE_CONFIG_REG_PSW_SPI;
This looks like a very complicated way of writing
value &= TOP_VSENSE_CONFIG_LATCHED_PSW_SPI |
TOP_VSENSE_CONFIG_LATCHED_PSW_NAND |
TOP_VSENSE_CONFIG_REG_PSW_EMMC
or am I missing something? Why do we need to do this anyway, it's very
surprsing?
This functions is to sanitize the vsense voltages when the regulator
is probed and in some circumstances the reset value of this register
does not reflect the hw status/config. For example, by default, after
the reset, the bit 0 is set so the EMMC, inside the flash subsystem,
is supposed to operate at 3v3. But the latched bit 24 can be 0 on
a platform where it is actually set at 1v8.
So the bit 0 must be reset to keep this coherent and to allow MMC
framework to properly setup the Vdd when the framework starts.
Hoping this can help.
Regards
peppe
Re: Synopsys Ethernet QoS Driver
Hello Ozgur On 11/22/2016 9:38 AM, Ozgur Karatas wrote: Hello all, I think, ethtool and mdio don't work because the tool's not support to "QoS", right? Maybe, need a new API. I'm looking for dwceqos code but "tc" tools is very idea. I hope to be me always helpful. tools work but indeed should be extended to support more for QoS. This is another task we have to keep in mind, well spot. Peppe Regards, Ozgur 21.11.2016, 16:38, "Giuseppe CAVALLARO" : Hello Joao On 11/21/2016 2:48 PM, Joao Pinto wrote: Synopsys QoS IP is a separated hardware component, so it should be reusable by all implementations using it and so have its own "core driver" and platform + pci glue drivers. This is necessary for example in hardware validation, where you prototype an IP and instantiate its drivers and test it. Was there a strong reason to integrate QoS features directly in stmmac and not in synopsys/dwc_eth_qos.*? We decided to enhance the stmmac on supporting the QoS for several reasons; for example the common APIs that the driver already exposed and actually suitable for other SYNP chips. Then, PTP, EEE, S/RGMII, MMC could be shared among different chips with a minimal effort. This meant a lot of code already ready. For sure, the net-core, Ethtool, mdio parts were reused. Same for the glue logic files. For the latter, this helped to easily bring-up new platforms also because the stmmac uses the HW cap register to auto-configure many parts of the MAC core, DMA and modules. This helped many users, AFAIK. For validation purpose, this is my experience, the stmmac helped a lot because people used the same code to validate different HW and it was easy to switch to a platform to another one in order to verify / check if the support was ok or if a regression was introduced. This is important for complex supports like PTP or EEE. Hoping this can help. Do not hesitate to contact me for further details peppe
Re: Synopsys Ethernet QoS Driver
Hello Joao, Lars. On 11/22/2016 3:16 PM, Joao Pinto wrote: Ok, it makes sense. > Just for curiosity the target setup is the following: > https://www.youtube.com/watch?v=8V-LB5y2Cos > but instead of using internal drivers, we desire to use mainline drivers only. > > Thanks! Regarding this subject, I am thinking of making the following adaption: a) delete ethernet/synopsys b) rename ethernet/stmicro/stmmac to ethernet/synopsys and send you a patch for you to evaluate. Both agree with the approach? To have a new work base would be important, because I will add to the "new" structure some missing QoS features like Multichannel support, CBS and later TSN. IMO, we have to agree on a common strategy making the change for net-next; I imaged the following steps: - to port missing feature or fixes from ethernet/synopsys inside the stmmac taking care about the documentation too. - remove ethernet/synopsys - rename ethernet/stmicro/stmmac to ethernet/synopsys These latest two have some relevant impacts. This change should be propagated to all the platforms that are using: CONFIG_SYNOPSYS_DWC_ETH_QOS and CONFIG_STMMAC_ETH plus device-tree compatibility. - enhance the stmmac with new features and new glue (part of these can be anticipated for sure). what do you think? does it make sense? If yes, we can also understand how/who starts. Regards, Peppe Thanks.
Re: stmmac: GMAC_RGSMIIIS reports bogus values
On 1/27/2017 11:23 AM, Alexey Brodkin wrote: That's why my initial proposal was to ignore whatever we read from this register if we have MDIO bus instantiated already. sorry for my late reply, I agree with this approach, according to the HW and platform configuration the driver has to understand and then work to use either SMA or PCS module. Regards Peppe
Re: [PATCH 00/17] net: stmmac: misc fix
Hello Corentin On 1/31/2017 10:11 AM, Corentin Labbe wrote: Hello I am currently working on dwmac-sun8i glue driver for Allwinner H3/A83T/A64. This serie is the result of all minor problem found in the stmmac driver. thank for this effort, many changes are to tidy up some part of the code so I wonder if these should stay on top of net-next. There is on-going a thread to change something in the stmmac (where I missed more details and I tried to refresh all asap); so added on copy Joao. I will give you my feedback on some patches too. peppe Regards Corentin Labbe (17): net: stmmac: fix the typo on MAC_RNABLE_RX net: stmmac: Remove the bus_setup function pointer net: stmmac: fix some typos in comments net: stmmac: remove freesoftware address net: stmmac: remplace asm/io.h by linux/io.h net: stmmac: fix some code style problem net: stmmac: replace stmmac_mdio_busy_wait by readl_poll_timeout net: stmmac: Use readl_poll_timeout net: stmmac: replace ENOSYS by EINVAL net: stmmac: Correct the error message about invalid speed net: stmmac: Rewrite two test against NULL value net: stmmac: rename rx_crc to rx_crc_errors net: stmmac: Implement NAPI for TX net: stmmac: print phy information net: stmmac: remove dead code in stmmac_tx_clean net: stmmac: remove unused variable in sysfs_display_ring net: stmmac: replace unsigned by u32 drivers/net/ethernet/stmicro/stmmac/chain_mode.c | 4 -- drivers/net/ethernet/stmicro/stmmac/common.h | 8 +-- drivers/net/ethernet/stmicro/stmmac/descs.h| 4 -- drivers/net/ethernet/stmicro/stmmac/descs_com.h| 4 -- drivers/net/ethernet/stmicro/stmmac/dwmac100.h | 4 -- drivers/net/ethernet/stmicro/stmmac/dwmac1000.h| 4 -- .../net/ethernet/stmicro/stmmac/dwmac1000_core.c | 4 -- .../net/ethernet/stmicro/stmmac/dwmac1000_dma.c| 4 -- .../net/ethernet/stmicro/stmmac/dwmac100_core.c| 4 -- drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c | 4 -- drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c | 2 +- drivers/net/ethernet/stmicro/stmmac/dwmac_dma.h| 4 -- drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c| 28 -- drivers/net/ethernet/stmicro/stmmac/enh_desc.c | 6 +-- drivers/net/ethernet/stmicro/stmmac/mmc.h | 4 -- drivers/net/ethernet/stmicro/stmmac/mmc_core.c | 4 -- drivers/net/ethernet/stmicro/stmmac/norm_desc.c| 6 +-- drivers/net/ethernet/stmicro/stmmac/ring_mode.c| 4 -- drivers/net/ethernet/stmicro/stmmac/stmmac.h | 4 -- .../net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 6 +-- .../net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 4 -- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 63 ++ drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 52 +++--- drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 4 -- .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 6 +-- drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c | 4 -- drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h | 4 -- include/linux/stmmac.h | 1 - 28 files changed, 65 insertions(+), 185 deletions(-)
Re: [PATCH 02/17] net: stmmac: Remove the bus_setup function pointer
On 1/31/2017 10:11 AM, Corentin Labbe wrote:
The bus_setup function pointer is not used at all, this patch remove it.
indeed this was used and documented on some previous kernels where some
ST40/SH4 platforms (w/o DT).
It's ok to remove it in the new MAC generation; I do not think that
ST will re-use it on new development.
Peppe
Signed-off-by: Corentin Labbe
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4
include/linux/stmmac.h| 1 -
2 files changed, 5 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index e3f6389..bf2d8e6 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1671,10 +1671,6 @@ static int stmmac_hw_setup(struct net_device *dev, bool
init_ptp)
/* Copy the MAC addr into the HW */
priv->hw->mac->set_umac_addr(priv->hw, dev->dev_addr, 0);
- /* If required, perform hw setup of the bus. */
- if (priv->plat->bus_setup)
- priv->plat->bus_setup(priv->ioaddr);
-
/* PS and related bits will be programmed according to the speed */
if (priv->hw->pcs) {
int speed = priv->plat->mac_port_sel_speed;
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 266dab9..2d82df9 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -135,7 +135,6 @@ struct plat_stmmacenet_data {
int tx_fifo_size;
int rx_fifo_size;
void (*fix_mac_speed)(void *priv, unsigned int speed);
- void (*bus_setup)(void __iomem *ioaddr);
int (*init)(struct platform_device *pdev, void *priv);
void (*exit)(struct platform_device *pdev, void *priv);
void *bsp_priv;
Re: [PATCH 06/17] net: stmmac: fix some code style problem
On 1/31/2017 10:11 AM, Corentin Labbe wrote:
Checkpatch complains about some code style problem on stmmac_mdio.c.
This patch fix them.
Signed-off-by: Corentin Labbe
Acked-by: Giuseppe Cavallaro
---
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index 3fdc6ec..c24bef2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -152,9 +152,9 @@ int stmmac_mdio_reset(struct mii_bus *bus)
#ifdef CONFIG_OF
if (priv->device->of_node) {
-
if (data->reset_gpio < 0) {
struct device_node *np = priv->device->of_node;
+
if (!np)
return 0;
@@ -221,7 +221,7 @@ int stmmac_mdio_register(struct net_device *ndev)
return 0;
new_bus = mdiobus_alloc();
- if (new_bus == NULL)
+ if (!new_bus)
return -ENOMEM;
if (mdio_bus_data->irqs)
@@ -258,6 +258,7 @@ int stmmac_mdio_register(struct net_device *ndev)
found = 0;
for (addr = 0; addr < PHY_MAX_ADDR; addr++) {
struct phy_device *phydev = mdiobus_get_phy(new_bus, addr);
+
if (phydev) {
int act = 0;
char irq_num[4];
@@ -267,7 +268,7 @@ int stmmac_mdio_register(struct net_device *ndev)
* If an IRQ was provided to be assigned after
* the bus probe, do it here.
*/
- if ((mdio_bus_data->irqs == NULL) &&
+ if ((!mdio_bus_data->irqs) &&
(mdio_bus_data->probed_phy_irq > 0)) {
new_bus->irq[addr] =
mdio_bus_data->probed_phy_irq;
Re: [PATCH 09/17] net: stmmac: replace ENOSYS by EINVAL
On 1/31/2017 10:11 AM, Corentin Labbe wrote:
As said by checkpatch ENOSYS means 'invalid syscall nr' and nothing
else.
This patch replace ENOSYS by the more appropriate value EINVAL.
Signed-off-by: Corentin Labbe
Acked-by: Giuseppe Cavallaro
---
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index eff6282..485b1cd 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -353,7 +353,7 @@ void stmmac_remove_config_dt(struct platform_device *pdev,
struct plat_stmmacenet_data *
stmmac_probe_config_dt(struct platform_device *pdev, const char **mac)
{
- return ERR_PTR(-ENOSYS);
+ return ERR_PTR(-EINVAL);
}
void stmmac_remove_config_dt(struct platform_device *pdev,
Re: [PATCH 11/17] net: stmmac: Rewrite two test against NULL value
On 1/31/2017 10:11 AM, Corentin Labbe wrote:
This patch rewrite two test against NULL value with correct style.
Signed-off-by: Corentin Labbe
Acked-by: Giuseppe Cavallaro
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index b0154d5..2df36bd 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -700,7 +700,7 @@ static void stmmac_adjust_link(struct net_device *dev)
int new_state = 0;
unsigned int fc = priv->flow_ctrl, pause_time = priv->pause;
- if (phydev == NULL)
+ if (!phydev)
return;
spin_lock_irqsave(&priv->lock, flags);
@@ -1143,7 +1143,7 @@ static void dma_free_tx_skbufs(struct stmmac_priv *priv)
DMA_TO_DEVICE);
}
- if (priv->tx_skbuff[i] != NULL) {
+ if (priv->tx_skbuff[i]) {
dev_kfree_skb_any(priv->tx_skbuff[i]);
priv->tx_skbuff[i] = NULL;
priv->tx_skbuff_dma[i].buf = 0;
Re: [PATCH 10/17] net: stmmac: Correct the error message about invalid speed
On 1/31/2017 10:11 AM, Corentin Labbe wrote: Add 1000 as a valid speed in the error message about invalid speed in stmmac_adjust_link() Signed-off-by: Corentin Labbe --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index 98f544e..b0154d5 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -749,7 +749,7 @@ static void stmmac_adjust_link(struct net_device *dev) break; default: netif_warn(priv, link, priv->dev, - "Speed (%d) not 10/100\n", + "Speed (%d) not 10/100/1000\n", maybe, it could be "broken speed: %d" peppe phydev->speed); break; }
Re: [PATCH 12/17] net: stmmac: rename rx_crc to rx_crc_errors
On 1/31/2017 10:11 AM, Corentin Labbe wrote:
The ethtool stat counter rx_crc from stmmac is mis-named, the name
seems to speak about the number of RX CRC done, but in fact it is about
errors.
This patch rename it to rx_crc_errors, just like the same ifconfig
counter.
Signed-off-by: Corentin Labbe
Acked-by: Giuseppe Cavallaro
---
drivers/net/ethernet/stmicro/stmmac/common.h | 2 +-
drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/enh_desc.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/norm_desc.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h
b/drivers/net/ethernet/stmicro/stmmac/common.h
index 9da4877..b7ee15a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -67,7 +67,7 @@ struct stmmac_extra_stats {
unsigned long overflow_error;
unsigned long ipc_csum_error;
unsigned long rx_collision;
- unsigned long rx_crc;
+ unsigned long rx_crc_errors;
unsigned long dribbling_bit;
unsigned long rx_length;
unsigned long rx_mii;
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
index 8816515..843ec69 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
@@ -103,7 +103,7 @@ static int dwmac4_wrback_get_rx_status(void *data, struct
stmmac_extra_stats *x,
x->rx_mii++;
if (unlikely(rdes3 & RDES3_CRC_ERROR)) {
- x->rx_crc++;
+ x->rx_crc_errors++;
stats->rx_crc_errors++;
}
diff --git a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
index 8427643..323b59e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
@@ -221,7 +221,7 @@ static int enh_desc_get_rx_status(void *data, struct
stmmac_extra_stats *x,
x->rx_mii++;
if (unlikely(rdes0 & RDES0_CRC_ERROR)) {
- x->rx_crc++;
+ x->rx_crc_errors++;
stats->rx_crc_errors++;
}
ret = discard_frame;
diff --git a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
index 5a0d4b0..efb818e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
@@ -111,7 +111,7 @@ static int ndesc_get_rx_status(void *data, struct
stmmac_extra_stats *x,
stats->collisions++;
}
if (unlikely(rdes0 & RDES0_CRC_ERROR)) {
- x->rx_crc++;
+ x->rx_crc_errors++;
stats->rx_crc_errors++;
}
ret = discard_frame;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
index 69db8cb..6ca0a10 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
@@ -61,7 +61,7 @@ static const struct stmmac_stats stmmac_gstrings_stats[] = {
STMMAC_STAT(overflow_error),
STMMAC_STAT(ipc_csum_error),
STMMAC_STAT(rx_collision),
- STMMAC_STAT(rx_crc),
+ STMMAC_STAT(rx_crc_errors),
STMMAC_STAT(dribbling_bit),
STMMAC_STAT(rx_length),
STMMAC_STAT(rx_mii),
Re: [PATCH 14/17] net: stmmac: print phy information
On 1/31/2017 10:11 AM, Corentin Labbe wrote: When a PHY is found, printing which one was found (and which type/model) is a good information to know. Signed-off-by: Corentin Labbe --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index e53b727..3d52b8c 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -885,6 +885,7 @@ static int stmmac_init_phy(struct net_device *dev) netdev_dbg(priv->dev, "%s: attached to PHY (UID 0x%x) Link = %d\n", __func__, phydev->phy_id, phydev->link); + phy_attached_info(phydev); maybe we could remove the netdev_dbg above and just keep phy_attached_info(phydev); peppe return 0; }
Re: [PATCH 16/17] net: stmmac: remove unused variable in sysfs_display_ring
On 1/31/2017 10:11 AM, Corentin Labbe wrote:
The u64 x variable in sysfs_display_ring is unused.
This patch remove it.
Signed-off-by: Corentin Labbe
well spot
Acked-by: Giuseppe Cavallaro
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index b494bc2..f0ce780 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2890,9 +2890,7 @@ static void sysfs_display_ring(void *head, int size, int
extend_desc,
struct dma_desc *p = (struct dma_desc *)head;
for (i = 0; i < size; i++) {
- u64 x;
if (extend_desc) {
- x = *(u64 *) ep;
seq_printf(seq, "%d [0x%x]: 0x%x 0x%x 0x%x 0x%x\n",
i, (unsigned int)virt_to_phys(ep),
le32_to_cpu(ep->basic.des0),
@@ -2901,7 +2899,6 @@ static void sysfs_display_ring(void *head, int size, int
extend_desc,
le32_to_cpu(ep->basic.des3));
ep++;
} else {
- x = *(u64 *) p;
seq_printf(seq, "%d [0x%x]: 0x%x 0x%x 0x%x 0x%x\n",
i, (unsigned int)virt_to_phys(ep),
le32_to_cpu(p->des0), le32_to_cpu(p->des1),
Re: [PATCH 17/17] net: stmmac: replace unsigned by u32
On 1/31/2017 10:11 AM, Corentin Labbe wrote:
checkpatch complains about two unsigned without type after.
Since the value return is u32, it is simpler to replace it by u32 instead
of "unsigned int"
Signed-off-by: Corentin Labbe
Acked-by: Giuseppe Cavallaro
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index f0ce780..6260b6f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -187,7 +187,7 @@ static void print_pkt(unsigned char *buf, int len)
static inline u32 stmmac_tx_avail(struct stmmac_priv *priv)
{
- unsigned avail;
+ u32 avail;
if (priv->dirty_tx > priv->cur_tx)
avail = priv->dirty_tx - priv->cur_tx - 1;
@@ -199,7 +199,7 @@ static inline u32 stmmac_tx_avail(struct stmmac_priv *priv)
static inline u32 stmmac_rx_dirty(struct stmmac_priv *priv)
{
- unsigned dirty;
+ u32 dirty;
if (priv->dirty_rx <= priv->cur_rx)
dirty = priv->cur_rx - priv->dirty_rx;
Re: [PATCH 13/17] net: stmmac: Implement NAPI for TX
On 1/31/2017 10:11 AM, Corentin Labbe wrote:
The stmmac driver run TX completion under NAPI but without checking the
work done by the TX completion function.
This patch add work/budget to the TX completion function.
The visible effect is that it keep the driver longer under NAPI and
boost performance.
Under dwmac-sun8i the iperf goes from 140Mbit/s to 500Mbit/s.
Under dwmac-sunxi an iperf run use half less interrupts.
I think that this patch should be sent separately with more details
about the implementation you are adopting and results.
For example, in the timer callback you force 256 (it seems
DMA_TX_SIZE/2); do you think this should be tunable or fixed to
NAPI budget?
I'd like to understand if performance you get are for TCP traffic;
can you tell me what happens on unidirectional traffic?
Thx a lot for your effort, pls let me know
Regards
peppe
Signed-off-by: Corentin Labbe
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 2df36bd..e53b727 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1299,10 +1299,11 @@ static void stmmac_dma_operation_mode(struct
stmmac_priv *priv)
* @priv: driver private structure
* Description: it reclaims the transmit resources after transmission
completes.
*/
-static void stmmac_tx_clean(struct stmmac_priv *priv)
+static int stmmac_tx_clean(struct stmmac_priv *priv, int budget)
{
unsigned int bytes_compl = 0, pkts_compl = 0;
unsigned int entry = priv->dirty_tx;
+ int work = 0;
netif_tx_lock(priv->dev);
@@ -1369,6 +1370,9 @@ static void stmmac_tx_clean(struct stmmac_priv *priv)
priv->hw->desc->release_tx_desc(p, priv->mode);
entry = STMMAC_GET_ENTRY(entry, DMA_TX_SIZE);
+ work++;
+ if (work >= budget)
+ break;
}
priv->dirty_tx = entry;
@@ -1386,6 +1390,11 @@ static void stmmac_tx_clean(struct stmmac_priv *priv)
mod_timer(&priv->eee_ctrl_timer, STMMAC_LPI_T(eee_timer));
}
netif_tx_unlock(priv->dev);
+
+ if (work < budget)
+ work = 0;
+
+ return work;
}
static inline void stmmac_enable_dma_irq(struct stmmac_priv *priv)
@@ -1617,7 +1626,7 @@ static void stmmac_tx_timer(unsigned long data)
{
struct stmmac_priv *priv = (struct stmmac_priv *)data;
- stmmac_tx_clean(priv);
+ stmmac_tx_clean(priv, 256);
}
/**
@@ -2657,9 +2666,10 @@ static int stmmac_poll(struct napi_struct *napi, int
budget)
int work_done = 0;
priv->xstats.napi_poll++;
- stmmac_tx_clean(priv);
+ work_done += stmmac_tx_clean(priv, budget);
- work_done = stmmac_rx(priv, budget);
+ if (work_done < budget)
+ work_done += stmmac_rx(priv, budget - work_done);
if (work_done < budget) {
napi_complete(napi);
stmmac_enable_dma_irq(priv);
Re: [PATCH 00/17] net: stmmac: misc fix
On 1/31/2017 11:23 AM, Joao Pinto wrote: Hi Peppe, Às 10:00 AM de 1/31/2017, Giuseppe CAVALLARO escreveu: Hello Corentin On 1/31/2017 10:11 AM, Corentin Labbe wrote: Hello I am currently working on dwmac-sun8i glue driver for Allwinner H3/A83T/A64. This serie is the result of all minor problem found in the stmmac driver. thank for this effort, many changes are to tidy up some part of the code so I wonder if these should stay on top of net-next. There is on-going a thread to change something in the stmmac (where I missed more details and I tried to refresh all asap); so added on copy Joao. I submitted 2 suggestions that would rename folder stmicro to dwc and dwmac4* files to eqos. The second one is important, since there is no dwmc4/gmac4 core, in fact it is called eqos that will have 5.00 version very soon. Both suggestions were rejected and so I turned to developing features. I am available to discuss with you any improvement on these aspects if you think it makes sense. Currently I am developing the support for multi-queues / multi-channels which will enable in the future stmmac to be used in QAv and TSN applications. this is a really good point, so I am happy that you are looking for this supports that can stay on high priority and do not generate conflicts with this patch series. We will reopen the renaming story later... I hope to be more reactive on that and sorry for my absence. Regards Peppe Thanks, Joao I will give you my feedback on some patches too. peppe Regards Corentin Labbe (17): net: stmmac: fix the typo on MAC_RNABLE_RX net: stmmac: Remove the bus_setup function pointer net: stmmac: fix some typos in comments net: stmmac: remove freesoftware address net: stmmac: remplace asm/io.h by linux/io.h net: stmmac: fix some code style problem net: stmmac: replace stmmac_mdio_busy_wait by readl_poll_timeout net: stmmac: Use readl_poll_timeout net: stmmac: replace ENOSYS by EINVAL net: stmmac: Correct the error message about invalid speed net: stmmac: Rewrite two test against NULL value net: stmmac: rename rx_crc to rx_crc_errors net: stmmac: Implement NAPI for TX net: stmmac: print phy information net: stmmac: remove dead code in stmmac_tx_clean net: stmmac: remove unused variable in sysfs_display_ring net: stmmac: replace unsigned by u32 drivers/net/ethernet/stmicro/stmmac/chain_mode.c | 4 -- drivers/net/ethernet/stmicro/stmmac/common.h | 8 +-- drivers/net/ethernet/stmicro/stmmac/descs.h| 4 -- drivers/net/ethernet/stmicro/stmmac/descs_com.h| 4 -- drivers/net/ethernet/stmicro/stmmac/dwmac100.h | 4 -- drivers/net/ethernet/stmicro/stmmac/dwmac1000.h| 4 -- .../net/ethernet/stmicro/stmmac/dwmac1000_core.c | 4 -- .../net/ethernet/stmicro/stmmac/dwmac1000_dma.c| 4 -- .../net/ethernet/stmicro/stmmac/dwmac100_core.c| 4 -- drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c | 4 -- drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c | 2 +- drivers/net/ethernet/stmicro/stmmac/dwmac_dma.h| 4 -- drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c| 28 -- drivers/net/ethernet/stmicro/stmmac/enh_desc.c | 6 +-- drivers/net/ethernet/stmicro/stmmac/mmc.h | 4 -- drivers/net/ethernet/stmicro/stmmac/mmc_core.c | 4 -- drivers/net/ethernet/stmicro/stmmac/norm_desc.c| 6 +-- drivers/net/ethernet/stmicro/stmmac/ring_mode.c| 4 -- drivers/net/ethernet/stmicro/stmmac/stmmac.h | 4 -- .../net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 6 +-- .../net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 4 -- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 63 ++ drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 52 +++--- drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 4 -- .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 6 +-- drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c | 4 -- drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h | 4 -- include/linux/stmmac.h | 1 - 28 files changed, 65 insertions(+), 185 deletions(-)
Re: [PATCH 01/17] net: stmmac: fix the typo on MAC_RNABLE_RX
On 1/31/2017 10:11 AM, Corentin Labbe wrote:
the define MAC_RNABLE_RX have a typo, rename it to MAC_ENABLE_RX
Signed-off-by: Corentin Labbe
Acked-by: Giuseppe Cavallaro
---
drivers/net/ethernet/stmicro/stmmac/common.h| 2 +-
drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h
b/drivers/net/ethernet/stmicro/stmmac/common.h
index b13a144..0f90f91 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -340,7 +340,7 @@ struct dma_features {
/* Common MAC defines */
#define MAC_CTRL_REG 0x /* MAC Control */
#define MAC_ENABLE_TX 0x0008 /* Transmitter Enable */
-#define MAC_RNABLE_RX 0x0004 /* Receiver Enable */
+#define MAC_ENABLE_RX 0x0004 /* Receiver Enable */
/* Default LPI timers */
#define STMMAC_DEFAULT_LIT_LS 0x3E8
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
index 84e3e84..a414bde 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
@@ -261,9 +261,9 @@ void stmmac_set_mac(void __iomem *ioaddr, bool enable)
u32 value = readl(ioaddr + MAC_CTRL_REG);
if (enable)
- value |= MAC_RNABLE_RX | MAC_ENABLE_TX;
+ value |= MAC_ENABLE_RX | MAC_ENABLE_TX;
else
- value &= ~(MAC_ENABLE_TX | MAC_RNABLE_RX);
+ value &= ~(MAC_ENABLE_TX | MAC_ENABLE_RX);
writel(value, ioaddr + MAC_CTRL_REG);
}
Re: [PATCH 07/17] net: stmmac: replace stmmac_mdio_busy_wait by readl_poll_timeout
On 1/31/2017 10:11 AM, Corentin Labbe wrote:
The stmmac_mdio_busy_wait() function do the same job than
readl_poll_timeout().
So is is better to replace it.
Signed-off-by: Corentin Labbe
I just wonder if you also tested it, this impacts all the platforms
where SMA block is used
if yes, pls consider my:
Acked-by: Giuseppe Cavallaro
---
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 33 ---
1 file changed, 11 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index c24bef2..d9893cf 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -21,6 +21,7 @@
***/
#include
+#include
#include
#include
#include
@@ -38,22 +39,6 @@
#define MII_GMAC4_WRITE(1 << MII_GMAC4_GOC_SHIFT)
#define MII_GMAC4_READ (3 << MII_GMAC4_GOC_SHIFT)
-static int stmmac_mdio_busy_wait(void __iomem *ioaddr, unsigned int mii_addr)
-{
- unsigned long curr;
- unsigned long finish = jiffies + 3 * HZ;
-
- do {
- curr = jiffies;
- if (readl(ioaddr + mii_addr) & MII_BUSY)
- cpu_relax();
- else
- return 0;
- } while (!time_after_eq(curr, finish));
-
- return -EBUSY;
-}
-
/**
* stmmac_mdio_read
* @bus: points to the mii_bus structure
@@ -70,7 +55,7 @@ static int stmmac_mdio_read(struct mii_bus *bus, int phyaddr,
int phyreg)
struct stmmac_priv *priv = netdev_priv(ndev);
unsigned int mii_address = priv->hw->mii.addr;
unsigned int mii_data = priv->hw->mii.data;
-
+ u32 v;
int data;
u32 value = MII_BUSY;
@@ -82,12 +67,14 @@ static int stmmac_mdio_read(struct mii_bus *bus, int
phyaddr, int phyreg)
if (priv->plat->has_gmac4)
value |= MII_GMAC4_READ;
- if (stmmac_mdio_busy_wait(priv->ioaddr, mii_address))
+ if (readl_poll_timeout(priv->ioaddr + mii_address, v, !(v & MII_BUSY),
+ 100, 1))
return -EBUSY;
writel(value, priv->ioaddr + mii_address);
- if (stmmac_mdio_busy_wait(priv->ioaddr, mii_address))
+ if (readl_poll_timeout(priv->ioaddr + mii_address, v, !(v & MII_BUSY),
+ 100, 1))
return -EBUSY;
/* Read the data from the MII data register */
@@ -111,7 +98,7 @@ static int stmmac_mdio_write(struct mii_bus *bus, int
phyaddr, int phyreg,
struct stmmac_priv *priv = netdev_priv(ndev);
unsigned int mii_address = priv->hw->mii.addr;
unsigned int mii_data = priv->hw->mii.data;
-
+ u32 v;
u32 value = MII_BUSY;
value |= (phyaddr << priv->hw->mii.addr_shift)
@@ -126,7 +113,8 @@ static int stmmac_mdio_write(struct mii_bus *bus, int
phyaddr, int phyreg,
value |= MII_WRITE;
/* Wait until any existing MII operation is complete */
- if (stmmac_mdio_busy_wait(priv->ioaddr, mii_address))
+ if (readl_poll_timeout(priv->ioaddr + mii_address, v, !(v & MII_BUSY),
+ 100, 1))
return -EBUSY;
/* Set the MII address register to write */
@@ -134,7 +122,8 @@ static int stmmac_mdio_write(struct mii_bus *bus, int
phyaddr, int phyreg,
writel(value, priv->ioaddr + mii_address);
/* Wait until any existing MII operation is complete */
- return stmmac_mdio_busy_wait(priv->ioaddr, mii_address);
+ return readl_poll_timeout(priv->ioaddr + mii_address, v, !(v &
MII_BUSY),
+ 100, 1);
}
/**
Re: [PATCH 03/17] net: stmmac: fix some typos in comments
On 1/31/2017 10:11 AM, Corentin Labbe wrote:
This patch fix some typos in comments.
Signed-off-by: Corentin Labbe
Acked-by: Giuseppe Cavallaro
---
drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c | 6 +++---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 16
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 2 +-
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
index a414bde..3b1570d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
@@ -102,7 +102,7 @@ static void show_tx_process_state(unsigned int status)
pr_debug("- TX (Stopped): Reset or Stop command\n");
break;
case 1:
- pr_debug("- TX (Running):Fetching the Tx desc\n");
+ pr_debug("- TX (Running): Fetching the Tx desc\n");
break;
case 2:
pr_debug("- TX (Running): Waiting for end of tx\n");
@@ -136,7 +136,7 @@ static void show_rx_process_state(unsigned int status)
pr_debug("- RX (Running): Fetching the Rx desc\n");
break;
case 2:
- pr_debug("- RX (Running):Checking for end of pkt\n");
+ pr_debug("- RX (Running): Checking for end of pkt\n");
break;
case 3:
pr_debug("- RX (Running): Waiting for Rx pkt\n");
@@ -246,7 +246,7 @@ void stmmac_set_mac_addr(void __iomem *ioaddr, u8 addr[6],
unsigned long data;
data = (addr[5] << 8) | addr[4];
- /* For MAC Addr registers se have to set the Address Enable (AE)
+ /* For MAC Addr registers we have to set the Address Enable (AE)
* bit that has no effect on the High Reg 0 where the bit 31 (MO)
* is RO.
*/
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index bf2d8e6..ee71c07 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -216,7 +216,7 @@ static inline u32 stmmac_rx_dirty(struct stmmac_priv *priv)
/**
* stmmac_hw_fix_mac_speed - callback for speed selection
* @priv: driver private structure
- * Description: on some platforms (e.g. ST), some HW system configuraton
+ * Description: on some platforms (e.g. ST), some HW system configuration
* registers have to be set according to the link speed negotiated.
*/
static inline void stmmac_hw_fix_mac_speed(struct stmmac_priv *priv)
@@ -415,7 +415,7 @@ static void stmmac_get_rx_hwtstamp(struct stmmac_priv
*priv, struct dma_desc *p,
/**
* stmmac_hwtstamp_ioctl - control hardware timestamping.
* @dev: device pointer.
- * @ifr: An IOCTL specefic structure, that can contain a pointer to
+ * @ifr: An IOCTL specific structure, that can contain a pointer to
* a proprietary structure used to pass information to the driver.
* Description:
* This function configures the MAC to enable/disable both outgoing(TX)
@@ -1014,7 +1014,7 @@ static void stmmac_free_rx_buffers(struct stmmac_priv
*priv, int i)
* @dev: net device structure
* @flags: gfp flag.
* Description: this function initializes the DMA RX/TX descriptors
- * and allocates the socket buffers. It suppors the chained and ring
+ * and allocates the socket buffers. It supports the chained and ring
* modes.
*/
static int init_dma_desc_rings(struct net_device *dev, gfp_t flags)
@@ -2515,7 +2515,7 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit)
if (unlikely(status == discard_frame)) {
priv->dev->stats.rx_errors++;
if (priv->hwts_rx_en && !priv->extend_desc) {
- /* DESC2 & DESC3 will be overwitten by device
+ /* DESC2 & DESC3 will be overwritten by device
* with timestamp value, hence reinitialize
* them in stmmac_rx_refill() function so that
* device can reuse it.
@@ -2538,7 +2538,7 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit)
frame_len = priv->hw->desc->get_rx_frame_len(p, coe);
- /* If frame length is greather than skb buffer size
+ /* If frame length is greater than skb buffer size
* (preallocated during init) then the packet is
* ignored
*/
@@ -2744,7 +2744,7 @@ static netdev_features_t stmmac_fix_features(struct
net_device *dev,
/* Some GMAC devices have a bugged Jumbo frame support that
* needs to have the Tx COE disabled for oversized f
Re: [PATCH 07/17] net: stmmac: replace stmmac_mdio_busy_wait by readl_poll_timeout
On 1/31/2017 11:39 AM, Corentin Labbe wrote:
On Tue, Jan 31, 2017 at 11:13:49AM +0100, Giuseppe CAVALLARO wrote:
On 1/31/2017 10:11 AM, Corentin Labbe wrote:
The stmmac_mdio_busy_wait() function do the same job than
readl_poll_timeout().
So is is better to replace it.
Signed-off-by: Corentin Labbe
I just wonder if you also tested it, this impacts all the platforms
where SMA block is used
I have tested all patch in this series on my cubieboard2 (dwmac-sunxi) and my
opipc/pine64/bpim2+ (dwmac-sun8i)
(Yes I could have said that in cover letter).
So this code was tested on two different stmmac glue driver.
perfect :-) thx for the clarification and consider my Acked-by.
peppe
if yes, pls consider my:
Acked-by: Giuseppe Cavallaro
---
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 33 ---
1 file changed, 11 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index c24bef2..d9893cf 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -21,6 +21,7 @@
***/
#include
+#include
#include
#include
#include
@@ -38,22 +39,6 @@
#define MII_GMAC4_WRITE(1 << MII_GMAC4_GOC_SHIFT)
#define MII_GMAC4_READ (3 << MII_GMAC4_GOC_SHIFT)
-static int stmmac_mdio_busy_wait(void __iomem *ioaddr, unsigned int mii_addr)
-{
- unsigned long curr;
- unsigned long finish = jiffies + 3 * HZ;
-
- do {
- curr = jiffies;
- if (readl(ioaddr + mii_addr) & MII_BUSY)
- cpu_relax();
- else
- return 0;
- } while (!time_after_eq(curr, finish));
-
- return -EBUSY;
-}
-
/**
* stmmac_mdio_read
* @bus: points to the mii_bus structure
@@ -70,7 +55,7 @@ static int stmmac_mdio_read(struct mii_bus *bus, int phyaddr,
int phyreg)
struct stmmac_priv *priv = netdev_priv(ndev);
unsigned int mii_address = priv->hw->mii.addr;
unsigned int mii_data = priv->hw->mii.data;
-
+ u32 v;
int data;
u32 value = MII_BUSY;
@@ -82,12 +67,14 @@ static int stmmac_mdio_read(struct mii_bus *bus, int
phyaddr, int phyreg)
if (priv->plat->has_gmac4)
value |= MII_GMAC4_READ;
- if (stmmac_mdio_busy_wait(priv->ioaddr, mii_address))
+ if (readl_poll_timeout(priv->ioaddr + mii_address, v, !(v & MII_BUSY),
+ 100, 1))
return -EBUSY;
writel(value, priv->ioaddr + mii_address);
- if (stmmac_mdio_busy_wait(priv->ioaddr, mii_address))
+ if (readl_poll_timeout(priv->ioaddr + mii_address, v, !(v & MII_BUSY),
+ 100, 1))
return -EBUSY;
/* Read the data from the MII data register */
@@ -111,7 +98,7 @@ static int stmmac_mdio_write(struct mii_bus *bus, int
phyaddr, int phyreg,
struct stmmac_priv *priv = netdev_priv(ndev);
unsigned int mii_address = priv->hw->mii.addr;
unsigned int mii_data = priv->hw->mii.data;
-
+ u32 v;
u32 value = MII_BUSY;
value |= (phyaddr << priv->hw->mii.addr_shift)
@@ -126,7 +113,8 @@ static int stmmac_mdio_write(struct mii_bus *bus, int
phyaddr, int phyreg,
value |= MII_WRITE;
/* Wait until any existing MII operation is complete */
- if (stmmac_mdio_busy_wait(priv->ioaddr, mii_address))
+ if (readl_poll_timeout(priv->ioaddr + mii_address, v, !(v & MII_BUSY),
+ 100, 1))
return -EBUSY;
/* Set the MII address register to write */
@@ -134,7 +122,8 @@ static int stmmac_mdio_write(struct mii_bus *bus, int
phyaddr, int phyreg,
writel(value, priv->ioaddr + mii_address);
/* Wait until any existing MII operation is complete */
- return stmmac_mdio_busy_wait(priv->ioaddr, mii_address);
+ return readl_poll_timeout(priv->ioaddr + mii_address, v, !(v &
MII_BUSY),
+ 100, 1);
}
/**
Re: [PATCH 15/17] net: stmmac: remove dead code in stmmac_tx_clean
On 1/31/2017 10:11 AM, Corentin Labbe wrote:
Since commit cf32deec16e4 ("stmmac: add tx_skbuff_dma to save descriptors used by
PTP"),
the struct dma_desc *p in stmmac_tx_clean was not used at all.
This patch remove this dead code.
Signed-off-by: Corentin Labbe
Acked-by: Giuseppe Cavallaro
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 3d52b8c..b494bc2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1124,13 +1124,6 @@ static void dma_free_tx_skbufs(struct stmmac_priv *priv)
int i;
for (i = 0; i < DMA_TX_SIZE; i++) {
- struct dma_desc *p;
-
- if (priv->extend_desc)
- p = &((priv->dma_etx + i)->basic);
- else
- p = priv->dma_tx + i;
-
if (priv->tx_skbuff_dma[i].buf) {
if (priv->tx_skbuff_dma[i].map_as_page)
dma_unmap_page(priv->device,
Re: stmmac: GMAC_RGSMIIIS reports bogus values
Hello Alexey On 1/31/2017 2:24 PM, Alexey Brodkin wrote: Hi Giuseppe, On Tue, 2017-01-31 at 10:55 +0100, Giuseppe CAVALLARO wrote: On 1/27/2017 11:23 AM, Alexey Brodkin wrote: That's why my initial proposal was to ignore whatever we read from this register if we have MDIO bus instantiated already. sorry for my late reply, I agree with this approach, according to the HW and platform configuration the driver has to understand and then work to use either SMA or PCS module. I already submitted another solution which IMHO is much cleaner and appropriate, see David has it already in master tree here: http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=0a764db103376cf69d04449b10688f3516cc0b88 it's ok, thx for that Peppe -Alexey
Re: [PATCH V4 1/1] net: ethernet: Add TSE PCS support to dwmac-socfpga
Hello Tien Hock
On 6/21/2016 10:46 AM, th...@altera.com wrote:
From: Tien Hock Loh
This adds support for TSE PCS that uses SGMII adapter when the phy-mode of
the dwmac is set to sgmii
Signed-off-by: Tien Hock Loh
IIUC, you are keeping the two timers w/o looking.
Is there any motivation behind? I had understood you wanted
to review it.
Let me know
Regards
Peppe
---
v2:
- Refactored the TSE PCS out from the dwmac-socfpga.c file
- Added binding documentation for TSE PCS sgmii adapter
v3:
- Added missing license header for new source files
- Updated tse_pcs.h include headers
- Standardize if statements
v4:
- Reset SGMII adapter on speed change
- Do not enable SGMII adapter if speed is not supported
- On init, if PCS reset fails, do not enable adapter
123
---
.../devicetree/bindings/net/socfpga-dwmac.txt | 19 ++
drivers/net/ethernet/stmicro/stmmac/Makefile | 2 +-
drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c | 276 +
drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.h | 36 +++
.../net/ethernet/stmicro/stmmac/dwmac-socfpga.c| 149 +--
5 files changed, 460 insertions(+), 22 deletions(-)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c
create mode 100644 drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.h
diff --git a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
index 72d82d6..dd10f2f 100644
--- a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
+++ b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
@@ -17,9 +17,26 @@ Required properties:
Optional properties:
altr,emac-splitter: Should be the phandle to the emac splitter soft IP node if
DWMAC controller is connected emac splitter.
+phy-mode: The phy mode the ethernet operates in
+altr,sgmii_to_sgmii_converter: phandle to the TSE SGMII converter
+
+This device node has additional phandle dependency, the sgmii converter:
+
+Required properties:
+ - compatible : Should be altr,gmii-to-sgmii-2.0
+ - reg-names : Should be "eth_tse_control_port"
Example:
+gmii_to_sgmii_converter: phy@0x10240 {
+ compatible = "altr,gmii-to-sgmii-2.0";
+ reg = <0x0001 0x0240 0x0008>,
+ <0x0001 0x0200 0x0040>;
+ reg-names = "eth_tse_control_port";
+ clocks = <&sgmii_1_clk_0 &emac1 1 &sgmii_clk_125 &sgmii_clk_125>;
+ clock-names = "tse_pcs_ref_clk_clock_connection", "tse_rx_cdr_refclk";
+};
+
gmac0: ethernet@ff70 {
compatible = "altr,socfpga-stmmac", "snps,dwmac-3.70a", "snps,dwmac";
altr,sysmgr-syscon = <&sysmgr 0x60 0>;
@@ -30,4 +47,6 @@ gmac0: ethernet@ff70 {
mac-address = [00 00 00 00 00 00];/* Filled in by U-Boot */
clocks = <&emac_0_clk>;
clock-names = "stmmaceth";
+ phy-mode = "sgmii";
+ altr,gmii-to-sgmii-converter = <&gmii_to_sgmii_converter>;
};
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile
b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 0fb362d..0ff76e8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -11,7 +11,7 @@ obj-$(CONFIG_DWMAC_IPQ806X) += dwmac-ipq806x.o
obj-$(CONFIG_DWMAC_LPC18XX)+= dwmac-lpc18xx.o
obj-$(CONFIG_DWMAC_MESON) += dwmac-meson.o
obj-$(CONFIG_DWMAC_ROCKCHIP) += dwmac-rk.o
-obj-$(CONFIG_DWMAC_SOCFPGA)+= dwmac-socfpga.o
+obj-$(CONFIG_DWMAC_SOCFPGA)+= dwmac-socfpga.o altr_tse_pcs.o
obj-$(CONFIG_DWMAC_STI)+= dwmac-sti.o
obj-$(CONFIG_DWMAC_SUNXI) += dwmac-sunxi.o
obj-$(CONFIG_DWMAC_GENERIC)+= dwmac-generic.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c
b/drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c
new file mode 100644
index 000..40bfaac
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c
@@ -0,0 +1,276 @@
+/* Copyright Altera Corporation (C) 2016. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2,
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see
Re: [PATCH V4 1/1] net: ethernet: Add TSE PCS support to dwmac-socfpga
On 6/23/2016 3:38 AM, Tien Hock Loh wrote:
Hi Peppe,
On Wed, 2016-06-22 at 11:00 +0200, Giuseppe CAVALLARO wrote:
Hello Tien Hock
On 6/21/2016 10:46 AM, th...@altera.com wrote:
From: Tien Hock Loh
This adds support for TSE PCS that uses SGMII adapter when the phy-mode of
the dwmac is set to sgmii
Signed-off-by: Tien Hock Loh
IIUC, you are keeping the two timers w/o looking.
Is there any motivation behind? I had understood you wanted
to review it.
I've merged them into one timer, aneg_link_timer and one timer callback
(that invokes individually the auto_nego_timer_callback and
pcs_link_timer_callback) in the patch. Is that not what you were
expecting?
sorry, it is ok, you added the aneg_link_timer_callback
thx for the changes.
Acked-by: Giuseppe Cavallaro
Let me know
Regards
Peppe
---
v2:
- Refactored the TSE PCS out from the dwmac-socfpga.c file
- Added binding documentation for TSE PCS sgmii adapter
v3:
- Added missing license header for new source files
- Updated tse_pcs.h include headers
- Standardize if statements
v4:
- Reset SGMII adapter on speed change
- Do not enable SGMII adapter if speed is not supported
- On init, if PCS reset fails, do not enable adapter
123
---
.../devicetree/bindings/net/socfpga-dwmac.txt | 19 ++
drivers/net/ethernet/stmicro/stmmac/Makefile | 2 +-
drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c | 276 +
drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.h | 36 +++
.../net/ethernet/stmicro/stmmac/dwmac-socfpga.c| 149 +--
5 files changed, 460 insertions(+), 22 deletions(-)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c
create mode 100644 drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.h
diff --git a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
index 72d82d6..dd10f2f 100644
--- a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
+++ b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
@@ -17,9 +17,26 @@ Required properties:
Optional properties:
altr,emac-splitter: Should be the phandle to the emac splitter soft IP node if
DWMAC controller is connected emac splitter.
+phy-mode: The phy mode the ethernet operates in
+altr,sgmii_to_sgmii_converter: phandle to the TSE SGMII converter
+
+This device node has additional phandle dependency, the sgmii converter:
+
+Required properties:
+ - compatible : Should be altr,gmii-to-sgmii-2.0
+ - reg-names : Should be "eth_tse_control_port"
Example:
+gmii_to_sgmii_converter: phy@0x10240 {
+ compatible = "altr,gmii-to-sgmii-2.0";
+ reg = <0x0001 0x0240 0x0008>,
+ <0x0001 0x0200 0x0040>;
+ reg-names = "eth_tse_control_port";
+ clocks = <&sgmii_1_clk_0 &emac1 1 &sgmii_clk_125 &sgmii_clk_125>;
+ clock-names = "tse_pcs_ref_clk_clock_connection", "tse_rx_cdr_refclk";
+};
+
gmac0: ethernet@ff70 {
compatible = "altr,socfpga-stmmac", "snps,dwmac-3.70a", "snps,dwmac";
altr,sysmgr-syscon = <&sysmgr 0x60 0>;
@@ -30,4 +47,6 @@ gmac0: ethernet@ff70 {
mac-address = [00 00 00 00 00 00];/* Filled in by U-Boot */
clocks = <&emac_0_clk>;
clock-names = "stmmaceth";
+ phy-mode = "sgmii";
+ altr,gmii-to-sgmii-converter = <&gmii_to_sgmii_converter>;
};
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile
b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 0fb362d..0ff76e8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -11,7 +11,7 @@ obj-$(CONFIG_DWMAC_IPQ806X) += dwmac-ipq806x.o
obj-$(CONFIG_DWMAC_LPC18XX)+= dwmac-lpc18xx.o
obj-$(CONFIG_DWMAC_MESON) += dwmac-meson.o
obj-$(CONFIG_DWMAC_ROCKCHIP) += dwmac-rk.o
-obj-$(CONFIG_DWMAC_SOCFPGA)+= dwmac-socfpga.o
+obj-$(CONFIG_DWMAC_SOCFPGA)+= dwmac-socfpga.o altr_tse_pcs.o
obj-$(CONFIG_DWMAC_STI)+= dwmac-sti.o
obj-$(CONFIG_DWMAC_SUNXI) += dwmac-sunxi.o
obj-$(CONFIG_DWMAC_GENERIC)+= dwmac-generic.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c
b/drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c
new file mode 100644
index 000..40bfaac
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c
@@ -0,0 +1,276 @@
+/* Copyright Altera Corporation (C) 2016. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2,
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
Re: [PATCH v3 1/1] net: ethernet: Add TSE PCS support to dwmac-socfpga
Hello Tien Hock
On 6/9/2016 7:48 AM, Tien Hock Loh wrote:
[snip]
.../devicetree/bindings/net/socfpga-dwmac.txt | 4 +
drivers/net/ethernet/stmicro/stmmac/Makefile | 2 +-
.../net/ethernet/stmicro/stmmac/dwmac-socfpga.c| 140 +--
drivers/net/ethernet/stmicro/stmmac/tse_pcs.c | 261 +
drivers/net/ethernet/stmicro/stmmac/tse_pcs.h | 36 +++
5 files changed, 419 insertions(+), 24 deletions(-)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/tse_pcs.c
create mode 100644 drivers/net/ethernet/stmicro/stmmac/tse_pcs.h
I just wonder if it could make sense to rename the
tse_pcs.[hc] files or creating a sub-directory for altera devel.
It seems that tse_pcs.[hc] are common files but this support
is for Altera.
Anyway, I let you decide and I also ask you to update the stmmac.txt
file.
Yeah the PCS support for TSE is Altera. To avoid confusion, let's rename
them, would altr_tse_pcs.[hc] be good? I don't think creating a
sub-directory with only 2 files is necessary though.
ok for two files w/o sub-dir.
I see that stmmac.txt is generic, and other vendor's PCS support
documents their specific uses in their own *-dwmac.txt (eg.
rockchip-dwmac.txt). Is this not the case?
yes you can use this name convention. I let you decide.
[snip]
+
+ index = of_property_match_string(np_sgmii_adapter, "reg-names",
+"eth_tse_control_port");
reg-names looks to be specific and mandatory, IMO they should be
documented in the binding.
That's the binding for the adapter (the phandle to the sgmii adapter),
not the stmac binding itself. Do you mean I should document the sgmii
adapter as well?
no I just meant for the adapter binding, I had understood that
eth_tse_control_port and gmii_to_sgmii_adapter_avalon_slave
were not documented and these seem to be mandatory.
[snip]
+
+static void auto_nego_timer_callback(unsigned long data)
+{
+ u16 val = 0;
+ u16 speed = 0;
+ u16 duplex = 0;
+
+ struct tse_pcs *pcs = (struct tse_pcs *)data;
+ void __iomem *tse_pcs_base = pcs->tse_pcs_base;
+ void __iomem *sgmii_adapter_base = pcs->sgmii_adapter_base;
+
+ val = readw(tse_pcs_base + TSE_PCS_STATUS_REG);
+ val &= TSE_PCS_STATUS_AN_COMPLETED_MASK;
[snip]
ANE is completed but speed or duplex is NOK. Any failure to signalling?
I see that you then enable the adpter in any case.
Maybe we could try to restart ANE again or force it (reducing the speed)
I wonder what happens if, for some reason, there is some hw problem. In
that case the timer is always running signalling an invalid Parter
speed. Anyway, this is jus a question... I expect that this error will
always point us to a problem to debug further (if occurs).
Let me look at how we can handle the case. Perhaps we could do a restart
and register the timer again. I'm just worried it will go into an
infinite timer registering hogging up the kernel if the hardware really
fails. Maybe I can do a n-time retry here. Looking into this. Let me
know if you have any opinions on this.
I haven't been able to check for this behaviour though, negative testing
on this code isn't too easy to simulate.
yes and I expect this can occur on hw / conf problems. Take a look at
how the Physical Abstraction Layer manages this.
Indeed, we can try to restart ANE for a while and then just report the
failure (dev_err). Or we can try to fix other speed or duplex. But not
sure this is a good solution. We just mask a problem.
[snip]
+
+ setup_timer(&pcs->an_timer,
+ auto_nego_timer_callback,
+ (unsigned long)pcs);
+ mod_timer(&pcs->an_timer, jiffies +
+ msecs_to_jiffies(AUTONEGO_TIMER));
+ } else if (phy_dev->autoneg == AUTONEG_DISABLE) {
+ val = readw(tse_pcs_base + TSE_PCS_CONTROL_REG);
+ val &= ~TSE_PCS_CONTROL_AN_EN_MASK;
+ writew(val, tse_pcs_base + TSE_PCS_CONTROL_REG);
+
+ val = readw(tse_pcs_base + TSE_PCS_IF_MODE_REG);
+ val &= ~TSE_PCS_USE_SGMII_AN_MASK;
+ writew(val, tse_pcs_base + TSE_PCS_IF_MODE_REG);
+
+ val = readw(tse_pcs_base + TSE_PCS_IF_MODE_REG);
+ val &= ~TSE_PCS_SGMII_SPEED_MASK;
+
+ switch (speed) {
+ case 1000:
+ val |= TSE_PCS_SGMII_SPEED_1000;
+ break;
+ case 100:
+ val |= TSE_PCS_SGMII_SPEED_100;
+ break;
+ case 10:
+ val |= TSE_PCS_SGMII_SPEED_10;
+ break;
+ default:
+ return;
+ }
+ writew(val, tse_pcs_base + TSE_PCS_IF_MODE_REG);
+
+ tse_pcs_reset(tse_pcs_base, pcs);
+
+ setup_timer(&pcs->link_timer,
+
Re: [PATCH v3 1/1] net: ethernet: Add TSE PCS support to dwmac-socfpga
Hello Tien Hock On 6/10/2016 8:12 AM, Tien Hock Loh wrote: Yeah the PCS support for TSE is Altera. To avoid confusion, let's rename > > them, would altr_tse_pcs.[hc] be good? I don't think creating a > > sub-directory with only 2 files is necessary though. > > ok for two files w/o sub-dir. > > > > > I see that stmmac.txt is generic, and other vendor's PCS support > > documents their specific uses in their own *-dwmac.txt (eg. > > rockchip-dwmac.txt). Is this not the case? > > yes you can use this name convention. I let you decide. What I meant was we've documented the bindings in socfpga-dwmac.txt for platform specific bindings, and I won't be updating stmmac.txt because that is the generic driver binding. Agree? ok if you documented all in socfpga-dwmac.txt peppe
Re: [PATCH] net: stmmac: dwmac-rk: keep PHY up for WoL
Hello Vincent On 6/10/2016 1:00 AM, Vincent Palatin wrote: On Wed, Jun 8, 2016 at 5:17 PM, Andrew Lunn wrote: On Wed, Jun 08, 2016 at 03:25:38PM -0700, Vincent Palatin wrote: On Tue, Jun 7, 2016 at 12:23 AM, Giuseppe CAVALLARO wrote: Hello On 6/3/2016 7:29 PM, Vincent Palatin wrote: Do not shutdown the PHY if Wake-on-Lan is enabled, else it cannot wake us up. I do not understand why you need that. This is done inside the PHY layer and it is tested on our platforms he idea is: If the parent wants to Wake the system then the PHY should not power-down. I'm not sure I understand : you mean that this path is not called if WoL is enabled ? [ currently stmmac_pltfr_suspend() is calling priv->plat->exit() which is the rk_gmac_exit() code I'm modifying ] or the RK driver code should not power down the phy in its exit() callback ? Take a look at phy_suspend(). phy_suspend() sends (or not) the PowerDown command to the PHY through the MDIO bus, depending if WoL is disabled, but most of my question still stands as far as I can tell : I was trying to get a proper WoL support on the following setup : dwmac (inside a RK3288 SoC) connected to RTL8211 PHY The current upstream code for this case will call rk_gmac_exit() when the MAC suspends (after the PHY has already suspended). Effectively doing a phy_power_on(, false) which is calling regulator_disable() on the LDO defined by the 'phy-supply' attribute. So my reading is that the RK specific MAC code is turning off unconditionally the PHY power regulator. Unless I'm mistaken, either this code is incorrect for the WoL case or the naming 'phy-supply' is misleading and should be the MAC supply. ok now clear. And you are right. I can conclude that the patch is ok for me. I just ask you to resend it elaborating a bit the subject and surrounding the code with a comment. I do not know your SoC but indeed, when doing WoL, some parts of the MAC + PHY must be powered so IMO it is legal that you do not cut the power by invoking regulator. Peppe
Re: [PATCH 1/1] net: ethernet: Add SGMII support to dwmac-socfpga
Hello Loh Tien
On 5/31/2016 11:10 AM, Loh Tien Hock wrote:
Hi Peppe,
Sorry for the late reply.
no pbl at all.
I believe my patch's title is a little confusing. The patch is to
enable Altera TSE PCS SGMII support, not to add SGMII support to
stmmac (well that in a way tests SGMII for stmmac though)
ok
I went through the code and it seems like if we were to refactor PCS
defines (and codes) into common code it would bloat up the common
codes.
Would it be better if we create new PCS source files (eg.
altr_tse_pcs.c/.h)? This means the rest of the PCS supports should
also be refactored out as well for consistency purposes.
yes agree.
Just an info to better understand the case; after enabling the SGMII on
Altera, do you test in some way the PCS SGMII mode in the main layer?
Regards
Peppe
Thanks
On Fri, May 13, 2016 at 3:47 PM, Giuseppe CAVALLARO
wrote:
Hello Tien
On 5/13/2016 9:01 AM, th...@altera.com wrote:
From: Tien Hock Loh
Adds SGMII support for dwmac-socfpga to enable the SGMII PHY when phy-mode
of the dwmac is set to sgmii.
I wonder if part of this patch can be unified to the common code
reusing (or improving) existent PCS support (see, for example the
defines inside the common.h and dwmac1000.h header files).
I had added some code for RGMII but never tested the SGMII indeed.
what is your feeling about that?
Peppe
Signed-off-by: Tien Hock Loh
---
.../net/ethernet/stmicro/stmmac/dwmac-socfpga.c| 339
-
1 file changed, 329 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index 41f4c58..a59d590 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -40,6 +40,43 @@
#define EMAC_SPLITTER_CTRL_SPEED_100 0x3
#define EMAC_SPLITTER_CTRL_SPEED_1000 0x0
+#define TSE_PCS_CONTROL_AN_EN_MASK 0x1000
+#define TSE_PCS_CONTROL_REG0x00
+#define TSE_PCS_CONTROL_RESTART_AN_MASK0x0200
+#define TSE_PCS_IF_MODE_REG0x28
+#define TSE_PCS_LINK_TIMER_0_REG 0x24
+#define TSE_PCS_LINK_TIMER_1_REG 0x26
+#define TSE_PCS_SIZE 0x40
+#define TSE_PCS_STATUS_AN_COMPLETED_MASK 0x0020
+#define TSE_PCS_STATUS_LINK_MASK 0x0004
+#define TSE_PCS_STATUS_REG 0x02
+#define TSE_PCS_SGMII_SPEED_1000 0x8
+#define TSE_PCS_SGMII_SPEED_1000x4
+#define TSE_PCS_SGMII_SPEED_10 0x0
+#define TSE_PCS_SW_RST_MASK0x8000
+#define TSE_PCS_PARTNER_ABILITY_REG0x0A
+#define TSE_PCS_PARTNER_DUPLEX_FULL0x1000
+#define TSE_PCS_PARTNER_DUPLEX_HALF0x
+#define TSE_PCS_PARTNER_DUPLEX_MASK0x1000
+#define TSE_PCS_PARTNER_SPEED_MASK 0x0c00
+#define TSE_PCS_PARTNER_SPEED_1000 0x0800
+#define TSE_PCS_PARTNER_SPEED_100 0x0400
+#define TSE_PCS_PARTNER_SPEED_10 0x
+#define TSE_PCS_PARTNER_SPEED_1000 0x0800
+#define TSE_PCS_PARTNER_SPEED_100 0x0400
+#define TSE_PCS_PARTNER_SPEED_10 0x
+#define TSE_PCS_SGMII_SPEED_MASK 0x000C
+#define TSE_PCS_SGMII_LINK_TIMER_0 0x0D40
+#define TSE_PCS_SGMII_LINK_TIMER_1 0x0003
+#define TSE_PCS_SW_RESET_TIMEOUT 100
+#define TSE_PCS_USE_SGMII_AN_MASK 0x0002
+
+#define SGMII_ADAPTER_CTRL_REG 0x00
+#define SGMII_ADAPTER_DISABLE 0x0001
+#define SGMII_ADAPTER_ENABLE 0x
+#define LINK_TIMER 20
+#define AUTONEGO_TIMER 20
+
struct socfpga_dwmac {
int interface;
u32 reg_offset;
@@ -49,18 +86,17 @@ struct socfpga_dwmac {
struct reset_control *stmmac_rst;
void __iomem *splitter_base;
bool f2h_ptp_ref_clk;
+ void __iomem *tse_pcs_base;
+ void __iomem *sgmii_adapter_base;
+ struct timer_list an_timer;
+ struct timer_list link_timer;
};
-static void socfpga_dwmac_fix_mac_speed(void *priv, unsigned int speed)
+static void config_emac_splitter_speed(void __iomem *base, unsigned int
speed)
{
- struct socfpga_dwmac *dwmac = (struct socfpga_dwmac *)priv;
- void __iomem *splitter_base = dwmac->splitter_base;
u32 val;
- if (!splitter_base)
- return;
-
- val = readl(splitter_base + EMAC_SPLITTER_CTRL_REG);
+ val = readl(base + EMAC_SPLITTER_CTRL_REG);
Re: [PATCH (net.git) 2/3] stmmac: fix PTP support for GMAC4
Hello Rayagond !
On 10/27/2016 12:25 PM, Rayagond Kokatanur wrote:
+static int dwmac4_wrback_get_rx_timestamp_status(void *desc, u32 ats)
> {
> struct dma_desc *p = (struct dma_desc *)desc;
> + int ret = -EINVAL;
> +
> + /* Get the status from normal w/b descriptor */
> + if (likely(p->des3 & TDES3_RS1V)) {
> + if (likely(p->des1 & RDES1_TIMESTAMP_AVAILABLE)) {
> + int i = 0;
> +
> + /* Check if timestamp is OK from context descriptor */
> + do {
> + ret = dwmac4_rx_check_timestamp(desc);
Here, "desc" is not pointing to next descriptor (ie context
descriptor). Driver should check the context descriptor.
you are right and this is done by the caller: stmmac_get_rx_hwtstamp
Cheers
peppe
Re: [PATCH net-next 1/5] net: stmmac: Implement ethtool::nway_reset
On 11/15/2016 8:19 PM, Florian Fainelli wrote:
Utilize the generic phy_ethtool_nway_reset() helper function to
implement an autonegotiation restart.
Signed-off-by: Florian Fainelli
Acked-by: Giuseppe Cavallaro
---
drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
index 3fe9340b748f..0290d52330da 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
@@ -870,6 +870,7 @@ static const struct ethtool_ops stmmac_ethtool_ops = {
.get_regs = stmmac_ethtool_gregs,
.get_regs_len = stmmac_ethtool_get_regs_len,
.get_link = ethtool_op_get_link,
+ .nway_reset = phy_ethtool_nway_reset,
.get_pauseparam = stmmac_get_pauseparam,
.set_pauseparam = stmmac_set_pauseparam,
.get_ethtool_stats = stmmac_get_ethtool_stats,
Re: [PATCH 1/3] net: stmmac: replace all pr_xxx by their netdev_xxx counterpart
On 11/16/2016 8:09 PM, Corentin Labbe wrote:
From: LABBE Corentin
The stmmac driver use lots of pr_xxx functions to print information.
This is bad since we cannot know which device logs the information.
(moreover if two stmmac device are present)
Furthermore, it seems that it assumes wrongly that all logs will always
be subsequent by using a dev_xxx then some indented pr_xxx like this:
kernel: sun7i-dwmac 1c5.ethernet: no reset control found
kernel: Ring mode enabled
kernel: No HW DMA feature register supported
kernel: Normal descriptors
kernel: TX Checksum insertion supported
So this patch replace all pr_xxx by their netdev_xxx counterpart.
Excepts for some printing where netdev "cause" unpretty output like:
sun7i-dwmac 1c5.ethernet (unnamed net_device) (uninitialized): no reset
control found
In those case, I keep dev_xxx.
In the same time I remove some "stmmac:" print since
this will be a duplicate with that dev_xxx displays.
Signed-off-by: Corentin Labbe
Thanks for these changes.
Acked-by: Giuseppe Cavallaro
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 204 --
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 14 +-
2 files changed, 123 insertions(+), 95 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 8eb12353..791daf4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -305,7 +305,7 @@ bool stmmac_eee_init(struct stmmac_priv *priv)
*/
spin_lock_irqsave(&priv->lock, flags);
if (priv->eee_active) {
- pr_debug("stmmac: disable EEE\n");
+ netdev_dbg(priv->dev, "disable EEE\n");
del_timer_sync(&priv->eee_ctrl_timer);
priv->hw->mac->set_eee_timer(priv->hw, 0,
tx_lpi_timer);
@@ -334,7 +334,7 @@ bool stmmac_eee_init(struct stmmac_priv *priv)
ret = true;
spin_unlock_irqrestore(&priv->lock, flags);
- pr_debug("stmmac: Energy-Efficient Ethernet initialized\n");
+ netdev_dbg(priv->dev, "Energy-Efficient Ethernet
initialized\n");
}
out:
return ret;
@@ -456,8 +456,8 @@ static int stmmac_hwtstamp_ioctl(struct net_device *dev,
struct ifreq *ifr)
sizeof(struct hwtstamp_config)))
return -EFAULT;
- pr_debug("%s config flags:0x%x, tx_type:0x%x, rx_filter:0x%x\n",
-__func__, config.flags, config.tx_type, config.rx_filter);
+ netdev_dbg(priv->dev, "%s config flags:0x%x, tx_type:0x%x,
rx_filter:0x%x\n",
+ __func__, config.flags, config.tx_type, config.rx_filter);
/* reserved for future extensions */
if (config.flags)
@@ -756,8 +756,9 @@ static void stmmac_adjust_link(struct net_device *dev)
break;
default:
if (netif_msg_link(priv))
- pr_warn("%s: Speed (%d) not 10/100\n",
- dev->name, phydev->speed);
+ netdev_warn(priv->dev,
+ "Speed (%d) not 10/100\n",
+ phydev->speed);
break;
}
@@ -810,10 +811,10 @@ static void stmmac_check_pcs_mode(struct stmmac_priv
*priv)
(interface == PHY_INTERFACE_MODE_RGMII_ID) ||
(interface == PHY_INTERFACE_MODE_RGMII_RXID) ||
(interface == PHY_INTERFACE_MODE_RGMII_TXID)) {
- pr_debug("STMMAC: PCS RGMII support enable\n");
+ netdev_dbg(priv->dev, "PCS RGMII support enabled\n");
priv->hw->pcs = STMMAC_PCS_RGMII;
} else if (interface == PHY_INTERFACE_MODE_SGMII) {
- pr_debug("STMMAC: PCS SGMII support enable\n");
+ netdev_dbg(priv->dev, "PCS SGMII support enabled\n");
priv->hw->pcs = STMMAC_PCS_SGMII;
}
}
@@ -848,15 +849,15 @@ static int stmmac_init_phy(struct net_device *dev)
snprintf(phy_id_fmt, MII_BUS_ID_SIZE + 3, PHY_ID_FMT, bus_id,
priv->plat->phy_addr);
- pr_debug("stmmac_init_phy: trying to attach to %s\n",
-phy_id_fmt);
+
[PATCH (net.git) 1/2] stmmac: fix ptp init for gmac4
The gmac 4.x version has not extended descriptors
(that are available on 3.x instead of).
While initializing the PTP module, the advanced PTP was
enabled in case of extended descriptors. This cannot be
applied for 4.x version where only the hardware capability
register has to show if the feature is present.
Patch also adds some extra netdev_(debug/inof) to better
dump the configuration.
Signed-off-by: Giuseppe Cavallaro
Cc: Alexandre TORGUE
Cc: Rayagond Kokatanur
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 4c8c60a..e838850 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -650,20 +650,27 @@ static int stmmac_init_ptp(struct stmmac_priv *priv)
if (IS_ERR(priv->clk_ptp_ref)) {
priv->clk_ptp_rate = clk_get_rate(priv->stmmac_clk);
priv->clk_ptp_ref = NULL;
+ netdev_dbg(priv->dev, "PTP uses main clock\n");
} else {
clk_prepare_enable(priv->clk_ptp_ref);
priv->clk_ptp_rate = clk_get_rate(priv->clk_ptp_ref);
+ netdev_dbg(priv->dev, "PTP rate %d\n", priv->clk_ptp_rate);
}
priv->adv_ts = 0;
- if (priv->dma_cap.atime_stamp && priv->extend_desc)
+ /* Check if adv_ts can be enabled for dwmac 4.x core */
+ if (priv->plat->has_gmac4 && priv->dma_cap.atime_stamp)
+ priv->adv_ts = 1;
+ /* Dwmac 3.x core with extend_desc can support adv_ts */
+ else if (priv->extend_desc && priv->dma_cap.atime_stamp)
priv->adv_ts = 1;
- if (netif_msg_hw(priv) && priv->dma_cap.time_stamp)
- pr_debug("IEEE 1588-2002 Time Stamp supported\n");
+ if (priv->dma_cap.time_stamp)
+ netdev_info(priv->dev, "IEEE 1588-2002 Timestamp supported\n");
- if (netif_msg_hw(priv) && priv->adv_ts)
- pr_debug("IEEE 1588-2008 Advanced Time Stamp supported\n");
+ if (priv->adv_ts)
+ netdev_info(priv->dev,
+ "IEEE 1588-2008 Advanced Timestamp supported\n");
priv->hw->ptp = &stmmac_ptp;
priv->hwts_tx_en = 0;
--
2.7.4
