RE: [RPRWG] SPI-4.1 and SPI-4.2 PHY_LINK_STATUS signalFail reports
Sam,
From what I hear, it not an automatic "carry" and should
be resubmitted.
DVJ
David V. James
3180 South Ct
Palo Alto, CA 94306
Home: +1.650.494.0926
+1.650.856.9801
Cell: +1.650.954.6906
Fax: +1.360.242.5508
Base: dvj@xxxxxxxxxxxx
>> -----Original Message-----
>> From: Blakey, Sam [mailto:Sam.Blakey@xxxxxxx]
>> Sent: Friday, May 02, 2003 3:06 PM
>> To: 'Mike Takefman'; 'David V James'
>> Cc: 'Rhett Brikovskis (now)'; 'Harry Peng'; 'Rpr GroupOf Ieee'
>> Subject: RE: [RPRWG] SPI-4.1 and SPI-4.2 PHY_LINK_STATUS signalFail
>> reports
>>
>>
>> Hi,
>> See comment 861 from last meeting...
>>
>> Unfortunately the resolution didn't really solve the problem.
>>
>> At the time (my recollection), the solution was to leave it to the
>> implementers to worry about getting these signals across via interrupt or
>> whatever. However this was seen as part of the whole Ethernet
>> PHY issue and
>> was therefore carried.
>>
>> I can resubmit the same comment (unless that happens automatically for
>> comments that "carry" - Tom????).
>>
>> Sam
>>
>> > -----Original Message-----
>> > From: Mike Takefman [mailto:tak@xxxxxxxxx]
>> > Sent: Monday, April 28, 2003 6:46 AM
>> > To: David V James
>> > Cc: Rhett Brikovskis (now); Harry Peng; Rpr GroupOf Ieee
>> > Subject: Re: [RPRWG] SPI-4.1 and SPI-4.2 PHY_LINK_STATUS
>> > signalFail reports
>> >
>> >
>> >
>> > David,
>> >
>> > I am a bit confused. The SPI bus transfers packets
>> > between two chips. SignalFail is an indicator that
>> > comes out of framer chips in any number of ways, but
>> > most likely as an interrupt.
>> >
>> > I think we have to define how to use SF if available
>> > (S-PHYs) and calculate it if not available (E-PHYs).
>> >
>> > mike
>> >
>> > David V James wrote:
>> > >
>> > > All,
>> > >
>> > > I did not notice the definition of how signalFail is determined for
>> > > SPI-4.1 or SPI-4.2, in either our specification or the SPI
>> > reference
>> > > documents.
>> > >
>> > > Does anyone know what these should be?
>> > > Does anyone know why they are apparently not in
>> > > the RPR D2.2 specification?
>> > >
>> > > DVJ
>> > >
>> > > David V. James
>> > > 3180 South Ct
>> > > Palo Alto, CA 94306
>> > > Home: +1.650.494.0926
>> > > +1.650.856.9801
>> > > Cell: +1.650.954.6906
>> > > Fax: +1.360.242.5508
>> > > Base: dvj@xxxxxxxxxxxx
>> >
>> > --
>> > Michael Takefman tak@xxxxxxxxx
>> > Manager of Engineering, Cisco Systems
>> > Chair IEEE 802.17 Stds WG
>> > 2000 Innovation Dr, Ottawa, Canada, K2K 3E8
>> > voice: 613-254-3399 cell:613-220-6991
>> >
>>