Blackfin arch use stmmac on its reference board bf609-ezkit, the stmmac ip
version is 3.61a.
But the spec seems a little different, some register addr and define are not
the same with current code.
This patch add the support for blackfin arch following the spec.
Signed-off-by: Bob Liu <redacted>
---
drivers/net/ethernet/stmicro/stmmac/dwmac100.h | 29 ++++++++++++++++++++
.../net/ethernet/stmicro/stmmac/dwmac100_core.c | 6 +++-
drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c | 3 ++
drivers/net/ethernet/stmicro/stmmac/dwmac_dma.h | 5 +++
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +
5 files changed, 44 insertions(+), 1 deletions(-)
After wake up from mem, ping fails to work.
This patch fix the resume function in stmmac driver.
Signed-off-by: Bob Liu <redacted>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
@@ -1952,6 +1952,15 @@ int stmmac_resume(struct net_device *ndev)priv->hw->mac->pmt(priv->ioaddr,0);netif_device_attach(ndev);+priv->dirty_tx=0;+priv->cur_tx=0;+priv->cur_rx=0;+priv->dirty_rx=0;++/* DMA initialization and SW reset */+priv->hw->dma->init(priv->ioaddr,priv->plat->pbl,+priv->dma_tx_phy,priv->dma_rx_phy);+priv->hw->mac->core_init(priv->ioaddr);/* Enable the MAC and DMA */stmmac_set_mac(priv->ioaddr,true);
Module can't be compiled and installed in current Makefile.
Signed-off-by: Bob Liu <redacted>
---
drivers/net/ethernet/stmicro/stmmac/Makefile | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
From: Ben Hutchings <hidden> Date: 2012-05-22 11:56:16
On Tue, 2012-05-22 at 15:38 +0800, Bob Liu wrote:
Module can't be compiled and installed in current Makefile.
[...]
That's because CONFIG_STMMAC_PLATFORM and CONFIG_STMMAC_PCI are wrongly
declared as tristate in Kconfig. Change them to bool and it should work
again.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
From: Giuseppe CAVALLARO <hidden> Date: 2012-05-22 12:37:06
Hello Bob Liu
On 5/22/2012 9:38 AM, Bob Liu wrote:
Blackfin arch use stmmac on its reference board bf609-ezkit, the stmmac ip
version is 3.61a.
But the spec seems a little different, some register addr and define are not
the same with current code.
This patch add the support for blackfin arch following the spec.
The 3.61a is supported and you have to point to the dw1000.h header file.
To support this GMAC generation you only need to pass from the platform
the field has_gmac (see stmmac.txt).
Also the 3.61a has the HW cap registers so many internal fields (e.g. rx
coe, enhanced descr ...) will be fixed at run-time (although you can
pass them from the platform).
Your patch adds the GMAC SPEC in the old MAC 10/100.
Also I am reluctant to have specific ifdef <ARCH> within the code.
I do think the driver already has all the platform fields to run on your
board. If you need extra conf pls feel free to enhance the
plat_stmmacenet_data.
Peppe
From: Giuseppe CAVALLARO <hidden> Date: 2012-05-22 12:51:54
On 5/22/2012 9:38 AM, Bob Liu wrote:
Module can't be compiled and installed in current Makefile.
I've just seen that I can generate the stmmac.ko on ARM and also on x86
with my configuration.
Can you post here you build failure?
In the meantime I'll test the module on ARM soon.
peppe
quoted hunk
Signed-off-by: Bob Liu <redacted>
---
drivers/net/ethernet/stmicro/stmmac/Makefile | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
Hi Peppe,
On Tue, May 22, 2012 at 8:51 PM, Giuseppe CAVALLARO
[off-list ref] wrote:
On 5/22/2012 9:38 AM, Bob Liu wrote:
quoted
Module can't be compiled and installed in current Makefile.
I've just seen that I can generate the stmmac.ko on ARM and also on x86
with my configuration.
Can you post here you build failure?
In the meantime I'll test the module on ARM soon.
Yes, stmmac.ko can be generated, but stmmac_platform.c won't be built.
which cause net device can't be probed.
peppe
quoted
Signed-off-by: Bob Liu <redacted>
---
drivers/net/ethernet/stmicro/stmmac/Makefile | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
From: Giuseppe CAVALLARO <hidden> Date: 2012-05-23 06:06:02
This patches fixes the driver when built as dyn module.
In fact the platform part cannot be built and the probe fails
(thanks to Bob Liu that reported this bug).
The patch also makes the selection of Platform and PCI parts
mutually exclusive.
Reported-by: Bob Liu <redacted>
Signed-off-by: Giuseppe Cavallaro <redacted>
Reviewed-by: Ben Hutchings <redacted>
cc: Rayagond Kokatanur <redacted>
---
drivers/net/ethernet/stmicro/stmmac/Kconfig | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
@@ -12,10 +12,12 @@ config STMMAC_ETHifSTMMAC_ETH+choice+prompt"STMMAC bus support"+configSTMMAC_PLATFORM-tristate"STMMAC platform bus support"+bool"Platform bus support"depends onSTMMAC_ETH-defaulty---help---Thisselectstheplatformspecificbussupportforthestmmacdevicedriver.Thisisthedriverused
@@ -26,7 +28,7 @@ config STMMAC_PLATFORMIfunsure,sayN.configSTMMAC_PCI-tristate"STMMAC support on PCI bus (EXPERIMENTAL)"+bool"PCI bus support (EXPERIMENTAL)"depends onSTMMAC_ETH&&PCI&&EXPERIMENTAL---help---ThisistoselecttheSynopsysDWMACavailableonPCIdevices,
@@ -36,6 +38,7 @@ config STMMAC_PCID1215994AVIRTEXFPGAboard.Ifunsure,sayN.+endchoiceconfigSTMMAC_DEBUG_FSbool"Enable monitoring via sysFS "
From: Giuseppe CAVALLARO <hidden> Date: 2012-05-23 06:09:04
On 5/23/2012 7:09 AM, Bob Liu wrote:
Hi Peppe,
On Tue, May 22, 2012 at 8:51 PM, Giuseppe CAVALLARO
[off-list ref] wrote:
quoted
On 5/22/2012 9:38 AM, Bob Liu wrote:
quoted
Module can't be compiled and installed in current Makefile.
I've just seen that I can generate the stmmac.ko on ARM and also on x86
with my configuration.
Can you post here you build failure?
In the meantime I'll test the module on ARM soon.
Yes, stmmac.ko can be generated, but stmmac_platform.c won't be built.
which cause net device can't be probed.
Yes you are perfectly right!
I've just sent a patch following Ben's advice.
Also not clear if/how to build this as a system which supports both PCI
and platform versions of the driver. So the patch makes them mutually
exclusive.
Thanks a lot
peppe
quoted
peppe
quoted
Signed-off-by: Bob Liu <redacted>
---
drivers/net/ethernet/stmicro/stmmac/Makefile | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
Hi Peppe,
On 5/22/12, Giuseppe CAVALLARO [off-list ref] wrote:
Hello Bob Liu
On 5/22/2012 9:38 AM, Bob Liu wrote:
quoted
Blackfin arch use stmmac on its reference board bf609-ezkit, the stmmac
ip
version is 3.61a.
But the spec seems a little different, some register addr and define are
not
the same with current code.
This patch add the support for blackfin arch following the spec.
The 3.61a is supported and you have to point to the dw1000.h header file.
To support this GMAC generation you only need to pass from the platform
the field has_gmac (see stmmac.txt).
Also the 3.61a has the HW cap registers so many internal fields (e.g. rx
coe, enhanced descr ...) will be fixed at run-time (although you can
pass them from the platform).
Your patch adds the GMAC SPEC in the old MAC 10/100.
Also I am reluctant to have specific ifdef <ARCH> within the code.
I do think the driver already has all the platform fields to run on your
board. If you need extra conf pls feel free to enhance the
plat_stmmacenet_data.
Thank you for your reply.
I tried to use driver dwmac1000 by setting .has_gmac = 1 today.
Ping can finish with no error but when rcp a file or telnet it will hang.
Using below patch without setting .has_gmac, everything works fine.
Any ideas? Thank you.
From: Giuseppe CAVALLARO <hidden> Date: 2012-05-23 08:22:05
Hello Bob Liu
On 5/23/2012 9:58 AM, Bob Liu wrote:
Hi Peppe,
On 5/22/12, Giuseppe CAVALLARO [off-list ref] wrote:
quoted
Hello Bob Liu
On 5/22/2012 9:38 AM, Bob Liu wrote:
quoted
Blackfin arch use stmmac on its reference board bf609-ezkit, the stmmac
ip
version is 3.61a.
But the spec seems a little different, some register addr and define are
not
the same with current code.
This patch add the support for blackfin arch following the spec.
The 3.61a is supported and you have to point to the dw1000.h header file.
To support this GMAC generation you only need to pass from the platform
the field has_gmac (see stmmac.txt).
Also the 3.61a has the HW cap registers so many internal fields (e.g. rx
coe, enhanced descr ...) will be fixed at run-time (although you can
pass them from the platform).
Your patch adds the GMAC SPEC in the old MAC 10/100.
Also I am reluctant to have specific ifdef <ARCH> within the code.
I do think the driver already has all the platform fields to run on your
board. If you need extra conf pls feel free to enhance the
plat_stmmacenet_data.
Thank you for your reply.
I tried to use driver dwmac1000 by setting .has_gmac = 1 today.
Ping can finish with no error but when rcp a file or telnet it will hang.
Hmm this should be debugged ... maybe you can verify the tx / rx
checksum. I mean if your IP has these modules or if, for somereason, the
HW cap register is not present and there are not properly fixed
Using below patch without setting .has_gmac, everything works fine.
With your patch (that added the dwmac1000 into the dwmac100) you are
indeed using the MAC100 setting where by default there is no HW
checksumming ;-)
From: Giuseppe CAVALLARO <hidden> Date: 2012-05-23 08:27:20
On 5/23/2012 10:21 AM, Giuseppe CAVALLARO wrote:
Hello Bob Liu
On 5/23/2012 9:58 AM, Bob Liu wrote:
quoted
Hi Peppe,
On 5/22/12, Giuseppe CAVALLARO [off-list ref] wrote:
quoted
Hello Bob Liu
On 5/22/2012 9:38 AM, Bob Liu wrote:
quoted
Blackfin arch use stmmac on its reference board bf609-ezkit, the stmmac
ip
version is 3.61a.
But the spec seems a little different, some register addr and define are
not
the same with current code.
This patch add the support for blackfin arch following the spec.
The 3.61a is supported and you have to point to the dw1000.h header file.
To support this GMAC generation you only need to pass from the platform
the field has_gmac (see stmmac.txt).
Also the 3.61a has the HW cap registers so many internal fields (e.g. rx
coe, enhanced descr ...) will be fixed at run-time (although you can
pass them from the platform).
Your patch adds the GMAC SPEC in the old MAC 10/100.
Also I am reluctant to have specific ifdef <ARCH> within the code.
I do think the driver already has all the platform fields to run on your
board. If you need extra conf pls feel free to enhance the
plat_stmmacenet_data.
Thank you for your reply.
I tried to use driver dwmac1000 by setting .has_gmac = 1 today.
Ping can finish with no error but when rcp a file or telnet it will hang.
Hmm this should be debugged ... maybe you can verify the tx / rx
checksum. I mean if your IP has these modules or if, for somereason, the
HW cap register is not present and there are not properly fixed
quoted
Using below patch without setting .has_gmac, everything works fine.
With your patch (that added the dwmac1000 into the dwmac100) you are
indeed using the MAC100 setting where by default there is no HW
checksumming ;-)
platform fields to use are: tx_coe and rx_coe.
Peppe
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: David Miller <davem@davemloft.net> Date: 2012-05-23 18:01:55
From: Giuseppe CAVALLARO <redacted>
Date: Wed, 23 May 2012 08:05:42 +0200
This patches fixes the driver when built as dyn module.
In fact the platform part cannot be built and the probe fails
(thanks to Bob Liu that reported this bug).
The patch also makes the selection of Platform and PCI parts
mutually exclusive.
Reported-by: Bob Liu <redacted>
Signed-off-by: Giuseppe Cavallaro <redacted>
Reviewed-by: Ben Hutchings <redacted>
We have drivers which support both OF (which is implemented as
platform bus) and PCI at the same time. For example,
drivers/net/ethernet/sun/niu.c
I do not see why stmmac cannot support both at the same time as well.
I absolutely do not want such segregation unless it is absolutely
necessary. Because it means that no matter what is choosen, a piece
of code is disabled and therefore not getting build and/or runtime
validation.
From: Giuseppe CAVALLARO <hidden> Date: 2012-05-28 05:45:11
On 5/23/2012 8:01 PM, David Miller wrote:
From: Giuseppe CAVALLARO <redacted>
Date: Wed, 23 May 2012 08:05:42 +0200
quoted
This patches fixes the driver when built as dyn module.
In fact the platform part cannot be built and the probe fails
(thanks to Bob Liu that reported this bug).
The patch also makes the selection of Platform and PCI parts
mutually exclusive.
Reported-by: Bob Liu <redacted>
Signed-off-by: Giuseppe Cavallaro <redacted>
Reviewed-by: Ben Hutchings <redacted>
We have drivers which support both OF (which is implemented as
platform bus) and PCI at the same time. For example,
drivers/net/ethernet/sun/niu.c
I do not see why stmmac cannot support both at the same time as well.
I absolutely do not want such segregation unless it is absolutely
necessary. Because it means that no matter what is choosen, a piece
of code is disabled and therefore not getting build and/or runtime
validation.
Ok, I'll review it and resend all the patches asap.
Regards
Peppe
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html