[Fwd: REXX CB81]

Mon May 3 03:33:15 1999

Dies ist eine mehrteilige Nachricht im MIME-Format.
--------------969C84BBACF6E3626C5D9127
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

--------------969C84BBACF6E3626C5D9127
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Return-Path: <owner-linux-tulip@beowulf.gsfc.nasa.gov>
X-Flags: 0000
Delivered-To: GMX delivery to stephan_bauer@gmx.de
Received: from pop.gmx.net
	by localhost with POP3 (fetchmail-5.0.1)
	for root@localhost (single-drop); Fri, 30 Apr 1999 12:55:06 +0200 (CEST)
Received: (qmail 14306 invoked by uid 0); 30 Apr 1999 09:50:22 -0000
Received: from beowulf.gsfc.nasa.gov (128.183.38.90)
  by mx1.gmx.net with SMTP; 30 Apr 1999 09:50:22 -0000
Received: (from majordomo@localhost)
	by beowulf.gsfc.nasa.gov (8.8.7/8.8.7) id DAA21540
	for linux-tulip-list; Fri, 30 Apr 1999 03:19:06 -0400
Received: from oxide.rlem.titech.ac.jp (oxide.rlem.titech.ac.jp [131.112.143.7])
	by beowulf.gsfc.nasa.gov (8.8.7/8.8.7) with ESMTP id DAA21537
	for <linux-tulip@beowulf.gsfc.nasa.gov>; Fri, 30 Apr 1999 03:19:04 -0400
Received: (from mlippmaa@localhost)
	by oxide.rlem.titech.ac.jp (8.8.8+Sun/8.8.8) id QAA07881
	for linux-tulip@beowulf.gsfc.nasa.gov; Fri, 30 Apr 1999 16:17:37 +0900 (JST)
Date: Mon May  3 03:33:15 1999
From: Mikk Lippmaa <mlippmaa@oxide.rlem.titech.ac.jp>
Message-Id: <199904300717.QAA07881@oxide.rlem.titech.ac.jp>
Subject: REXX CB81
Content-Type: text
Sender: owner-linux-tulip@beowulf.gsfc.nasa.gov
Precedence: bulk
To: stephan_bauer@gmx.de

I have a Ratoc Systems REX-CB81 CardBus 100Base-Tx/10Base-T card
which I am trying to get working under the 2.2.5 kernel in a Sony VAIO 505RS.
The card has a 21143-TD chip,
a serial EEPROM (8 bit address length), and a TDK PHY chip (TSC78Q2120).
I did get the card working, (at least on a 10BaseT link), but
the driver (0.90z) needed some modifications. I have a couple of
questions:

1. In parse_eeprom, at the end of the media leaf data parsing there
   is a diagnostic line:

      printk(KERN_INFO "%s:  MII interface PHY %d, setup/reset "
            "sequences %d/%d long, capabilities %2.2x %2.2x.\n",
            dev->name, bp[0], bp[1], bp[1 + bp[1]*2],
            bp[5 + bp[2 + bp[1]*2]*2], bp[4 + bp[2 + bp[1]*2]*2]);

  Shouldn't this be:

      printk(KERN_INFO "%s:  MII interface PHY %d, setup/reset "
            "sequences %d/%d long, capabilities %2.2x %2.2x.\n",
            dev->name, bp[0], bp[1], bp[2 + bp[1]*2],
            bp[4 + bp[2 + bp[1]*2]*2], bp[3 + bp[2 + bp[1]*2]*2]);

  as the relevant type 3 block in the EEPROM (at least in this card is):

      00   (PHY number)  <--- bp points here
      00   (GPR sequence length)
      03   (Reset sequence length)
      0708 (Reset sequence)
      0000       "
      0200       "
      0078 (Media capabilities)
      e001 (Nway advertisment)

2. This block (the reset sequence) also shows another more serious problem.
   The gep pins are programmed so that gep0, gep1, and gep2 are outputs and
   gep3 is an input. The reset sequence ends by driving gep1 high and gep0
   low. Apparently, in this card the gep0 and gep1 are used to power down
   the PHY and to reset the PHY, respectively (why, I wonder). At the moment
   the tulip driver starts to look for MII xcvrs before sending the reset sequence.
   In my case this means that the PHY is either powered down or in continuous
   reset state, and never responds.

   Sending the reset sequence by adding the lines

    outl(0x08070000, ioaddr + CSR15);
    outl(0x00000000, ioaddr + CSR15);
    outl(0x00020000, ioaddr + CSR15);

   before the MII detection loop will solve the problem. The MII is found.
   The proper(?) way would, of course, be to send the sequence from the EEPROM,
   as is done when the card is finally reset in tulip_open. 
   The sequene should also remember what the gep bits are at the end of the 
   reset sequence, i.e. something like this:

        for (i = 0; i < reset_length; i++)
            outl(get_u16(&reset_sequence[i]) << 16, ioaddr + CSR15);
   tp->gepibits = (get_u16(&reset_sequence[reset_length-1]) << 16) & 0x000f0000;

   Later, whenever CSR15 is programmed, the code could look like this

   outl(((whatever) & 0xfff0ffff) | tp->gepbits, ioaddr + CSR15);

   At the moment, problems occur in tulip_open. The chip reset in the beginning
   will reset the gep bits and the MII gets killed. I had to add the above
   sequence of outls to CSR15 just after the call to tulip_init_ring.

   outls had to be modified to include the gep bit states also later in
   tulip open where CSR13, 14, and 15 get reprogrammed. 

   After these modifications the card senses a 10BaseT link and appears to
   work correctly. However, the driver has several places where CSR15 is
   potentially clobbered. I haven't tried to force link negotiation, for example.

   So, the question really is: can the gep bit state memory be added to the driver
   or will this break something else? Is it possible to put in if()s for a
   specific card, or am I destined to patch the driver whenever I want to
   upgrade?

Mikk Lippmaa (mlippmaa@oxide.rlem.titech.ac.jp)

--------------969C84BBACF6E3626C5D9127--