From: Francois Romieu <romieu@fr.zoreil.com>
To: Grant Grundler <grantgrundler@gmail.com>
Cc: netdev@vger.kernel.org, David Miller <davem@davemloft.net>
Subject: [PATCH net-next] dmfe: enforce consistent timing delay.
Date: Tue, 17 Apr 2012 23:11:40 +0200 [thread overview]
Message-ID: <20120417211140.GA12909@electric-eye.fr.zoreil.com> (raw)
The driver does not always use the same timing for what looks like
the same operations.
- DCR0
Use the same udelay everywhere for reset. Upper bound is 100 us.
- DCR9
Use 5us delay for srom clock. 1us delay for phy_write_1bit (writes
PHY_DATA_[01]) are not changed as they stay withing a 2,5MHz MDIO
clock range.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
---
I noticed those while staring at the driver.
Grant, regarding your previous remarks, I do not see where the problem
could be with posted writes MMIO accesses:
- the driver has always used the first (#0) bar register. It's hardcoded.
The driver still uses this same bar register.
- the driver has never checked whether bar #0 was related to I/O or
memory space. It assumed an I/O decoder and issued out* instructions.
- the DM9102 datasheet states BAR #0 is an IO only BAR. No idea for the
DM9132, 9100 and 9009 though.
My changes have replaced in/out* accesses with ioread/write* - mostly
to help detecting places where type checking would have uncloaked a
forgotten net_device.base_addr.
Thus, if someone has a dmfe device including a MMIO space decoder behind
bar #0, iowrite* will now emit memory write instructions where the driver
previously used I/O operations. It may not work very well due to posted
writes issues, sure. However I wonder on which platform - if any - the
former MMIO space + I/O accesses (!) combo would have behaved correctly.
?
drivers/net/ethernet/dec/tulip/dmfe.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/dec/tulip/dmfe.c b/drivers/net/ethernet/dec/tulip/dmfe.c
index 0ef5b68..4d6fe60 100644
--- a/drivers/net/ethernet/dec/tulip/dmfe.c
+++ b/drivers/net/ethernet/dec/tulip/dmfe.c
@@ -767,7 +767,7 @@ static int dmfe_stop(struct DEVICE *dev)
/* Reset & stop DM910X board */
dw32(DCR0, DM910X_RESET);
- udelay(5);
+ udelay(100);
phy_write(ioaddr, db->phy_addr, 0, 0x8000, db->chip_id);
/* free interrupt */
@@ -1601,7 +1601,9 @@ static u16 read_srom_word(void __iomem *ioaddr, int offset)
int i;
dw32(DCR9, CR9_SROM_READ);
+ udelay(5);
dw32(DCR9, CR9_SROM_READ | CR9_SRCS);
+ udelay(5);
/* Send the Read Command 110b */
srom_clk_write(ioaddr, SROM_DATA_1);
@@ -1615,6 +1617,7 @@ static u16 read_srom_word(void __iomem *ioaddr, int offset)
}
dw32(DCR9, CR9_SROM_READ | CR9_SRCS);
+ udelay(5);
for (i = 16; i > 0; i--) {
dw32(DCR9, CR9_SROM_READ | CR9_SRCS | CR9_SRCLK);
@@ -1626,6 +1629,7 @@ static u16 read_srom_word(void __iomem *ioaddr, int offset)
}
dw32(DCR9, CR9_SROM_READ);
+ udelay(5);
return srom_data;
}
--
1.7.7.6
next reply other threads:[~2012-04-17 21:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-17 21:11 Francois Romieu [this message]
2012-04-17 21:45 ` [PATCH net-next] dmfe: enforce consistent timing delay Grant Grundler
2012-04-18 2:59 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120417211140.GA12909@electric-eye.fr.zoreil.com \
--to=romieu@fr.zoreil.com \
--cc=davem@davemloft.net \
--cc=grantgrundler@gmail.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox