"Adam J. Richter" wrote:
> On Tue, 1 Aug 2000, Donald Becker wrote:
> >On Mon, 31 Jul 2000, Adam J. Richter wrote:
> [...]
> >The pci-scan code handles activating the card from ACPI D3 state (typically
> >caused by warm-booting from a Windows version that uses Wake-On-LAN),
> >enabling the memory and I/O regions, and setting the bus-master bit.
> >I'm guessing that the "teamF1" people didn't know the requirements.
>
> I don't know ACPI other than having a vague understanding that
> there is no ACPI BIOS on the hardware platform on which this driver
> must work.
At this point we are really talking about PCI Power Management not
ACPI. If we needed ACPI for driver power management, tons of existing
installations using APM or swsusp would be sunk.
> The only calls to udelay(2000) that I see are when the hardware
> is being reset, a hopefully a rare event. However, I agree it would be
> good to determine if those 2ms delays can be eliminated.
Definitely attempt to remove the delay. However, see if sleeping is
possible in lieu of calling udelay.
> natsemi.c (Don's driver) - This driver used {read,write}{b,w,l}
> to memory addresses that apparently mapped into IO ports, which the
> 2.4.0-testX kernels discourage strongly by printing a warning every
> time it happens. (I guess this ability is going to be removed.)
> Changing the code to use {in,out}{b,w,l} has not worked as far as I
> can tell, even though the IO addresses appear to be correct, and I
> have verified that porting the TeamF1 routine for reading the mac
> address into this driver works (and in this style of this driver), so
> the board is alive.
Sounds like things got fubar'd in your conversion. This MMIO stuff
hasn't changed since 2.2.x; it sounds like the driver might be picking
the wrong PCI base address register to read for its ioaddr.
It shouldn't take long at all to port Donald's new natsemi.c to 2.4.x,
so I might do it. (I've done the ports for several of the other PCI net
drivers in the 2.4.x kernel)
Jeff
-- Jeff Garzik | Building 1024 | Yossarian lives. MandrakeSoft, Inc. |- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:16 EST