Subject: Re: kern/10194: tlp doesn't handle Davicom DM9102
To: Matthew Orgass <darkstar@pgh.net>
From: Jason R Thorpe <thorpej@zembu.com>
List: tech-net
Date: 05/25/2000 14:52:04
On Thu, May 25, 2000 at 12:47:01PM -0000, Matthew Orgass wrote:

 >  removed from the setup packet.  I use the SROM info to configure the MII,
 >  which needs a hack in mii.c since the 21140 MII setup code assumes that
 >  phynos are sequential starting at 0 (the 9102 PHY is 1), even though there
 >  is no reason to assume this from the MII probe code.  I think the MII
 >  probe should be changed to just probe for the desired PHY.  Also, there is
 >  a strange bit of code where SROM GPR entries are explicitly set to be 4
 >  bytes, even though they are actually longer.  This looks completely bogus
 >  (since it then goes on to read more then 4 bytes), but I just skipped it
 >  for the 9102 (whose GPR entries are themselves bogus and need to be
 >  skipped). 

Is that really true about the `first' PHY being at offset 1?

The DM9102A has both HomePNA and 10/100 interfaces.  You select the
HomePNA PHY by clearing OPMODE_PS, and the 10/100 interface by setting
OPMODE_PS (on older DM9102 chips, you must always set OPMODE_PS).

So, it's quite likely that some of those bogus GPR bits are actually
a description of the HomePNA portion, and that the HomePNA PHY is
actually offset 0.

I planned on handling this board by punting on the ISV SROM parsing
(since there is no GPIO stuff to deal with, and you always have MII),
and special casing the DM9102A HomePNA PHY.

 >    Also, the receive process does not want to stop in tlp_idle while
 >  waiting for a packet.  This doesn't seem to be a big problem since
 >  switching between auto (at 100baseTX) and 10baseT still works while it is
 >  running (but between 10baseT and 100baseTX does not).

Hm.  Interesting.  I wonder why the halt fails.  That's kind of annoying,
since you're supposed to halt the receive process to load a new receive
filter.  Oh well.  I guess I could suppress the warning on the DM9102.

 >    It also seems to switch over to store & forward mode fairly quickly (it
 >  doesn't have a 160/1024 mode, which I'm sure is part of the problem) so it
 >  may be worth either allowing a few more underruns or just putting it in
 >  S&F mode to begin with. 

Just doing S/F mode at the beginning seems reasonable, esp. since we
can't use MRL/MRM on that chip.

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>