headers
Lennert Buytenhek | 1 Jul 2007 01:17

Re: [PATCH] b44: power down PHY when interface down

On Sun, Jul 01, 2007 at 12:24:40AM +0200, Michael Buesch wrote:

> > > Hm, I was going to measure the real power advantage with a
> > > PCI-extender card. But my B44B0 card doesn't seem to work in
> > > that extender card. It works perfectly fine sticked directly into
> > > the motherboard, though, and other cards like a BCM4318 work in
> > > the extender, too.
> > > Not sure what this is.
> > > The extender has an application note about nonworking cards in the
> > > extender and a too big resistor on the board IDSEL pin being the
> > > cause of this.
> > 
> > Does the card show up in lspci at all?
> 
> No it doesn't.

Right, so it sounds like it might be this issue.

> > Does the extender board have a PCI-PCI bridge on it?  (If not,
> > there's not really any reason to resistively couple the IDSEL
> > line to the host, since the host should take care of that.)
> 
> There's no bridge. It just decouples all voltage lines, so you can
> drive it from external supply and/or measure voltages and current.
> On the PCB it looks like the the IDSEL line is rather directly
> routed to the host IDSEL. It just goes through one of the bus
> isolation chips. So I guess (just my guess) that this chip has some
> resistance and if the total resistance of the chip + the IDSEL
> resistor on the mainboard goes above some threshold it doesn't work
> anymore for some cards. In the application note they write
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dhananjay Phadke | 1 Jul 2007 03:49
Picon

Re: [PATCH 3/3] NetXen: Graceful teardown of interface and hardware upon module unload

This stage is safe to bail out on signal. It's initializing about a
hundred registers
and trying to guaranty by retrying, so can get stretched too much on faulty h/w.

-Dhananjay

On 7/1/07, Jeff Garzik <jeff <at> garzik.org> wrote:
> While strictly this is true, I strongly urge the use of
> non-interruptible sleeps when used in hardware-related delays.  Very
> rarely does one really want to care about signals for such cases.
>
>         Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
dhananjay.phadke | 1 Jul 2007 04:43
Picon

RESEND [PATCH 0/3] NetXen: Bug fixes for multiport and blade adapters

Resending with changes suggested.

--

-- 
Dhananjay Phadke
NetXen Inc.

 drivers/net/netxen/netxen_nic.h          |  177 +++++++++++++++++++++++++++---
 drivers/net/netxen/netxen_nic_hdr.h      |    2 +
 drivers/net/netxen/netxen_nic_hw.c       |   39 +++++--
 drivers/net/netxen/netxen_nic_init.c     |   64 +++++++----
 drivers/net/netxen/netxen_nic_main.c     |  177 +++++++++++++++++++-----------
 drivers/net/netxen/netxen_nic_phan_reg.h |   14 +++
 6 files changed, 357 insertions(+), 116 deletions(-)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 4 comments |
headers
dhananjay.phadke | 1 Jul 2007 04:43
Picon

RESEND [PATCH 2/3] NetXen: Support per PCI-function interrupt mask registers

This patch updates the various access routines to access different
control and status settings present in different register locations.
This will fix problems related to working of different ports in
multi Port card.

Signed-off by: Dhananjay Phadke <dhananjay <at> netxen.com>
Signed-off by: Milan Bag <mbag <at> netxen.com>

Index: netdev-2.6/drivers/net/netxen/netxen_nic.h
===================================================================
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic.h
+++ netdev-2.6/drivers/net/netxen/netxen_nic.h
 <at>  <at>  -937,6 +937,7  <at>  <at>  struct netxen_adapter {
 	struct netxen_ring_ctx *ctx_desc;
 	struct pci_dev *ctx_desc_pdev;
 	dma_addr_t ctx_desc_phys_addr;
+	int intr_scheme;
 	int (*enable_phy_interrupts) (struct netxen_adapter *);
 	int (*disable_phy_interrupts) (struct netxen_adapter *);
 	void (*handle_phy_intr) (struct netxen_adapter *);
 <at>  <at>  -1080,37 +1081,103  <at>  <at>  struct net_device_stats *netxen_nic_get_
 
 static inline void netxen_nic_disable_int(struct netxen_adapter *adapter)
 {
-	/*
-	 * ISR_INT_MASK: Can be read from window 0 or 1.
-	 */
-	writel(0x7ff, PCI_OFFSET_SECOND_RANGE(adapter, ISR_INT_MASK));
+	uint32_t	mask = 0x7ff;
+	int count = 0;
(Continue reading)

Permalink | Reply | 1 comment |
headers
dhananjay.phadke | 1 Jul 2007 04:43
Picon

RESEND [PATCH 1/3] NetXen: Fix issue of MSI not working correctly

NetXen driver uses PCI function 0 to provide the functionality of MSI.
The patch makes driver check the bus master bit for function 0 and
enable it after the card initialization.

Signed-off-by: Dhananjay Phadke<dhananjay <at> netxen.com>
Signed-off-by: Milan Bag <mbag <at> netxen.com>
Signed-off-by: Wen Xiong <wenxiong <at> us.ibm.com>

Index: netdev-2.6/drivers/net/netxen/netxen_nic_main.c
===================================================================
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic_main.c
+++ netdev-2.6/drivers/net/netxen/netxen_nic_main.c
 <at>  <at>  -336,11 +336,9  <at>  <at>  netxen_nic_probe(struct pci_dev *pdev, c
 	if (pci_using_dac)
 		netdev->features |= NETIF_F_HIGHDMA;

-	if (pci_enable_msi(pdev)) {
+	if (pci_enable_msi(pdev))
 		adapter->flags &= ~NETXEN_NIC_MSI_ENABLED;
-		printk(KERN_WARNING "%s: unable to allocate MSI interrupt"
-		       " error\n", netxen_nic_driver_name);
-	} else
+	else
 		adapter->flags |= NETXEN_NIC_MSI_ENABLED;

 	netdev->irq = pdev->irq;
 <at>  <at>  -355,13 +353,6  <at>  <at>  netxen_nic_probe(struct pci_dev *pdev, c
 	/* initialize the adapter */
 	netxen_initialize_adapter_hw(adapter);
(Continue reading)

Permalink | Reply | 0 comments |
headers
dhananjay.phadke | 1 Jul 2007 04:43
Picon

RESEND [PATCH 3/3] NetXen: Graceful teardown of interface and hardware upon module unload

These changes allow driver close routine to be called during module unload,
to clean-up buffers and other software resources, flush queues etc. Also,
hardware is reset to pristine state. 

Signed-off-by: Dhananjay Phadke <dhananjay <at> netxen.com>
Signed-off-by: Milan Bag <mbag <at> netxen.com>
Signed-off-by: Wen Xiong <wenxiong <at> us.ibm.com>

Index: netdev-2.6/drivers/net/netxen/netxen_nic.h
===================================================================
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic.h
+++ netdev-2.6/drivers/net/netxen/netxen_nic.h
 <at>  <at>  -952,6 +952,24  <at>  <at>  struct netxen_adapter {
 	int (*stop_port) (struct netxen_adapter *);
 };				/* netxen_adapter structure */

+/*
+ * NetXen dma watchdog control structure
+ *
+ *	Bit 0		: enabled => R/O: 1 watchdog active, 0 inactive
+ *	Bit 1		: disable_request => 1 req disable dma watchdog
+ *	Bit 2		: enable_request =>  1 req enable dma watchdog
+ *	Bit 3-31	: unused
+ */
+
+#define netxen_set_dma_watchdog_disable_req(config_word) \
+	_netxen_set_bits(config_word, 1, 1, 1)
+#define netxen_set_dma_watchdog_enable_req(config_word) \
+	_netxen_set_bits(config_word, 2, 1, 1)
+#define netxen_get_dma_watchdog_enabled(config_word) \
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Garzik | 1 Jul 2007 05:27
Favicon

Re: [PATCH 3/3] NetXen: Graceful teardown of interface and hardware upon module unload

Dhananjay Phadke wrote:
> This stage is safe to bail out on signal. It's initializing about a
> hundred registers
> and trying to guaranty by retrying, so can get stretched too much on 
> faulty h/w.

This implies that you have -add- code to check for and handle signals at 
each delay point.  Don't bother.  Too much code bloat for negligable gain.

It is better just to remove the _interruptible, for many reasons.

	Jeff

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Kyle Moffett | 1 Jul 2007 06:51
Picon

Re: PM policy, hotplug, power saving (was Re: [PATCH] b44: power down PHY when interface down)

On Jun 30, 2007, at 12:42:06, Jeff Garzik wrote:
> Definitely matters.  Switch renegotiation can take a while, and you  
> must take into account the common case of interface bouncing  
> (immediate down, then up).
>
> Hoards actively complained the few times we experimented with this,  
> because of e.g. DHCP's habit of bouncing the interface, which  
> resulted in PHY power bouncing, which resulted in negotiation,  
> which resulted in an excrutiating wait on various broken or stupid  
> switches.
>
> Overall, this may be classed with other problems of a similar  
> sort:  we can power down a PHY, but that removes hotplug capability  
> and extends partner/link negotiation time.
>
> Like SATA, we actually want to support BOTH -- active hotplug and  
> PHY power-down -- and so this wanders into power management policy.
>
> Give me a knob, and we can program plenty of ethernet|SATA|USB|...  
> drivers to power down the PHY and save power.

With some buggy switches and other hardware you actually *want* to  
bounce the link to get them to properly renegotiate.  I can also see  
wanting to power off and on a single-PoE-port NIC to restart whatever  
device is at the other end, although I don't know if any such devices  
exist.  Currently the tg3 driver turns the PHY off and on during down/ 
up on a few of my systems, which I use to make a buggy no-name switch  
recognize STP changes properly.

Cheers,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Buesch | 1 Jul 2007 11:27
Picon
Favicon

Re: RESEND [PATCH 2/3] NetXen: Support per PCI-function interrupt mask registers

On Sunday 01 July 2007 04:43:27 dhananjay.phadke <at> gmail.com wrote:
> This patch updates the various access routines to access different
> control and status settings present in different register locations.
> This will fix problems related to working of different ports in
> multi Port card.
> 
> Signed-off by: Dhananjay Phadke <dhananjay <at> netxen.com>
> Signed-off by: Milan Bag <mbag <at> netxen.com>
> 
> Index: netdev-2.6/drivers/net/netxen/netxen_nic.h
> ===================================================================
> --- netdev-2.6.orig/drivers/net/netxen/netxen_nic.h
> +++ netdev-2.6/drivers/net/netxen/netxen_nic.h
>  <at>  <at>  -937,6 +937,7  <at>  <at>  struct netxen_adapter {
>  	struct netxen_ring_ctx *ctx_desc;
>  	struct pci_dev *ctx_desc_pdev;
>  	dma_addr_t ctx_desc_phys_addr;
> +	int intr_scheme;
>  	int (*enable_phy_interrupts) (struct netxen_adapter *);
>  	int (*disable_phy_interrupts) (struct netxen_adapter *);
>  	void (*handle_phy_intr) (struct netxen_adapter *);
>  <at>  <at>  -1080,37 +1081,103  <at>  <at>  struct net_device_stats *netxen_nic_get_
>  
>  static inline void netxen_nic_disable_int(struct netxen_adapter *adapter)
>  {
> -	/*
> -	 * ISR_INT_MASK: Can be read from window 0 or 1.
> -	 */
> -	writel(0x7ff, PCI_OFFSET_SECOND_RANGE(adapter, ISR_INT_MASK));
> +	uint32_t	mask = 0x7ff;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Buesch | 1 Jul 2007 12:23
Picon
Favicon

Re: [PATCH] b44: power down PHY when interface down

On Sunday 01 July 2007 01:17:34 Lennert Buytenhek wrote:
> More or less.  You can't add the resistances like that, since the
> bus isolation chip buffers the IDSEL signal, but it is correct that
> if the host's IDSEL resistor is larger than a certain value, the
> combination of the resistive coupling of IDSEL plus the extra buffer
> in the isolator might be causing the IDSEL input on the 'guest' PCI
> board to assert too late (or not assert at all), causing config
> accesses to fail.
> 
> (This also depends on the specific 'guest' PCI board used, as you
> noted, due to differing IDSEL trace lengths/capacitances and input
> pin capacitances on different PCI boards.  Also, it might work at
> 33 MHz but not work at 66 MHz, etc.)

It doesn't work on any of my boards :(

> If you feel adventurous, you could try to hack around this by
> figuring out which AD[31:16] line this PCI slot's IDSEL line is
> resistively coupled to (depends on the slot), and then adding
> another parallel resistor on the board itself to make the bus
> isolator's input buffer charge faster.  Note that this does
> increase the load on that specific AD[] line, which might cause
> other funny effects.

Well, but how to find out to which address line it's connected to?
Pretty hard to follow the PCB traces, especially since it's
multilayered.

--

-- 
Greetings Michael.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane