linux1394-devel

RE: Bus Reset

[Mark K. <mk...@co...>]

The Port Status Registers of a 1394a Phy provide the following indications:
 
Connected - Is the cable attached to another 1394 device?
Bias - Is that device providing TPBIAS?
Disabled - Is this port of our Phy enabled or disabled?
 
The use of these bits was envisioned as providing the information necessary
to answer the questions you posed Jeff.
 
I am unclear whether the Linux 1394 driver is taking advantage of these
features at this time. It is possible that another thread having to do with
the Sony OHCI implementation may be impacted by the state of these bits
also.
 
Cheers

-----Original Message-----
From: Jeff Mak [mailto:Jef...@ef...]
Sent: Tuesday, April 11, 2000 5:01 PM
To: 'lin...@li...'
Subject: Bus Reset



For OHCI driver, whenever the target node is power off, bus reset would be
generated.   For IEEE1394,  there are some power management i.e. the node is
self-powered and this has been implemented in my target node.   However, the
bus reset signal is still generated causing my linux box cannot communicate
with the target node anymore.    My question is how to distinguish a target
node from "power off" to "connection failed" i.e no bus reset would generate
under "power off" connection ?

Thanks, 
Jeff 

RE: Bus Reset

[Jeff M. <Jef...@ef...>]

Mark,

Thanks for the information you provided.  The bus reset interrupt would =
be
generated to the driver when the firewire detects there is a change in
condition, right?   In this case, I am thinking should it be controlled =
by
hardware side (Firewire card itself) rather than checking port status
register?

Thanks,
Jeff

-----Original Message-----
From: Mark Knecht [mailto:mk...@co...]
Sent: Wednesday, April 12, 2000 9:37 AM
To: Jeff Mak; 'lin...@li...'
Subject: RE: Bus Reset


The Port Status Registers of a 1394a Phy provide the following =
indications:
=A0
Connected - Is the cable attached to another 1394 device?
Bias - Is that device providing TPBIAS?
Disabled - Is this port of our Phy enabled or disabled?
=A0
The use of these bits was envisioned as providing the information =
necessary
to answer the questions you posed Jeff.
=A0
I am unclear whether the Linux 1394 driver is taking advantage of these
features at this time. It is possible that another thread having to do =
with
the Sony OHCI implementation may be impacted by the state of these bits
also.
=A0
Cheers

-----Original Message-----
From: Jeff Mak [mailto:Jef...@ef...]
Sent: Tuesday, April 11, 2000 5:01 PM
To: 'lin...@li...'
Subject: Bus Reset



For OHCI driver, whenever the target node is power off, bus reset would =
be
generated.=A0=A0 For IEEE1394,=A0 there are some power management i.e. =
the node is
self-powered and this has been implemented in my target node.=A0=A0 =
However, the
bus reset signal is still generated causing my linux box cannot =
communicate
with the target node anymore.=A0=A0=A0 My question is how to =
distinguish a target
node from "power off" to "connection failed" i.e no bus reset would =
generate
under "power off" connection ?

Thanks,=20
Jeff=20

RE: Bus Reset

[Mark K. <mk...@co...>]

Jeff,
   In general I agree with you, but it may in practice not be that simple...
 
   1394 OHCI requires the use of a 1394a Phy. The problem is that 1394a was
just approved within the last month, and while the spec has been stable for
some time, there is no guarantee that everyone's 1394a Phys are truly
compatible with the 1394a spec. There is usually a period of time where new
hardware is getting released and the market determines, over time, what
works and what doesn't. Keep in mind that much of the hardware we are
looking at today may not have been placed under significant enough scrutiny
to truly be deemed 'compliant'.
 
   This said, 1394a defines a new state called 'disabled'. If the Phy on
your card is somehow in the disabled state, then the spec says it is not
capable of detecting any signals. (Don't ask me how your Phy got into this
state! I'm just suggesting that if the driver isn't careful there could be a
problem here that is detectable and correctable in software that we would
not be addressing today.) If this is the case, then the answer to your
question is "No. There would not be a hardware reset". (At least the way I
read the spec....)
 
   Keep plugging away and I'm sure you'll find the clue that helps the code
guys (I'm a hardware guy) get the problem resolved.
 
With best regards,
Mark
 
 

-----Original Message-----
From: Jeff Mak [mailto:Jef...@ef...]
Sent: Wednesday, April 12, 2000 11:07 AM
To: 'Mark Knecht'; 'lin...@li...'
Subject: RE: Bus Reset



Mark, 

Thanks for the information you provided.  The bus reset interrupt would be
generated to the driver when the firewire detects there is a change in
condition, right?   In this case, I am thinking should it be controlled by
hardware side (Firewire card itself) rather than checking port status
register?

Thanks, 
Jeff 

-----Original Message----- 
From: Mark Knecht [ mailto:mk...@co...] 
Sent: Wednesday, April 12, 2000 9:37 AM 
To: Jeff Mak; 'lin...@li...' 
Subject: RE: Bus Reset 


The Port Status Registers of a 1394a Phy provide the following indications: 
  
Connected - Is the cable attached to another 1394 device? 
Bias - Is that device providing TPBIAS? 
Disabled - Is this port of our Phy enabled or disabled? 
  
The use of these bits was envisioned as providing the information necessary 
to answer the questions you posed Jeff. 
  
I am unclear whether the Linux 1394 driver is taking advantage of these 
features at this time. It is possible that another thread having to do with 
the Sony OHCI implementation may be impacted by the state of these bits 
also. 
  
Cheers 

-----Original Message----- 
From: Jeff Mak [ mailto:Jef...@ef...] 
Sent: Tuesday, April 11, 2000 5:01 PM 
To: 'lin...@li...' 
Subject: Bus Reset 



For OHCI driver, whenever the target node is power off, bus reset would be 
generated.   For IEEE1394,  there are some power management i.e. the node is

self-powered and this has been implemented in my target node.   However, the

bus reset signal is still generated causing my linux box cannot communicate 
with the target node anymore.    My question is how to distinguish a target 
node from "power off" to "connection failed" i.e no bus reset would generate

under "power off" connection ? 

Thanks, 
Jeff 

Re: Bus Reset

[Jeff M. <Jef...@ef...>]

Sebastien

As you are the writer of OHCI driver, I think you are the best one in
answering my queries:

I am making use of raw1394 (dev_open) to connect to the other node through
OHCI kernel driver, when there is a change in power status at PHY of the
other node, a bus reset would be generated from the hardware.  Is it true
that the connection in between would be lost?   In other words, can I send
any other command to the target node using the same handle?  I know that
this is not OHCI specific question but since I am using OHCI kernel driver
written by you, I believe you may have some experience on that.

The reason why I ask this question is:  I am currently trying  to talk to a
target node which has a "wake up" feature.   In other words, if the target
node is idle for period of time, it will try to shutdown itself until it
receives a "wake up" command from my linux box.   However, when the target
node is idle and auto shutoff.   Bus reset would be generated causing I
cannot get the respond from the target node anymore using the same
raw1394_handle.   I have tried to deactivate the bus reset event on
interrupt of OHCI driver but it is not working.   I believe deactivating the
interrupt event mask on bus reset is just ignore the bus reset on kernel
driver side.  

I suppose if the target node get the power from the firewire bus  and my
firewire card is a power supplier, there shouldn't be any bus reset even if
the target node is in power off mode.   Is my understanding correct?    I
know that this is IEEE1394 specific and if you have any suggestion, please
let me know.


Cheers,
Jeff

Re: Bus Reset

[Sebastien R. <Seb...@sy...>]

>>>>> "Jeff" == Jeff Mak <Jef...@ef...> writes:

Jeff> I am making use of raw1394 (dev_open) to connect to the other node
Jeff> through OHCI kernel driver, when there is a change in power status at
Jeff> PHY of the other node, a bus reset would be generated from the hardware.
Jeff> Is it true that the connection in between would be lost?  In other
Jeff> words, can I send any other command to the target node using the same
Jeff> handle?  I know that this is not OHCI specific question but since I am
Jeff> using OHCI kernel driver written by you, I believe you may have some
Jeff> experience on that.

I don't think bus reset are handled properly yet in the current version
of the linux ieee1394 driver. If a bus reset occurs, the node numbers on 
the bus are re-assigned, and I don't think that libraw is designed to deal 
with that situation (I might be wrong though). Especially, the ohci driver
receives a specific phy packet that indicates precisely when the bus 
configuration has been modified, but this packet is currently being 
discarded since the subsystem doesn't accept it... I have to talk to 
Andreas about that.

Jeff> The reason why I ask this question is: I am currently trying to talk to
Jeff> a target node which has a "wake up" feature.  In other words, if the
Jeff> target node is idle for period of time, it will try to shutdown itself
Jeff> until it receives a "wake up" command from my linux box.  However, when
Jeff> the target node is idle and auto shutoff.  Bus reset would be generated
Jeff> causing I cannot get the respond from the target node anymore using the
Jeff> same raw1394_handle.  I have tried to deactivate the bus reset event on
Jeff> interrupt of OHCI driver but it is not working.  I believe deactivating
Jeff> the interrupt event mask on bus reset is just ignore the bus reset on
Jeff> kernel driver side.

Do you mean that everytime the node goes in 'sleep' mode, a bus reset is
generated ???

Jeff> I suppose if the target node get the power from the firewire bus and my
Jeff> firewire card is a power supplier, there shouldn't be any bus reset even
Jeff> if the target node is in power off mode.  Is my understanding correct?
Jeff> I know that this is IEEE1394 specific and if you have any suggestion,
Jeff> please let me know.

Sorry I don't know about that particular point of the ieee1394 standard.

-- 
Sebastien Rougeaux
RSISE, The Australian National University

Re: Bus Reset

[Andreas B. <and...@mu...>]

On Sun, Apr 16, 2000 at 09:24:13PM -0700, Jeff Mak wrote:
> Sebastien
> 
> As you are the writer of OHCI driver, I think you are the best one in
> answering my queries:
> 
> I am making use of raw1394 (dev_open) to connect to the other node through
> OHCI kernel driver, when there is a change in power status at PHY of the
> other node, a bus reset would be generated from the hardware.  Is it true
> that the connection in between would be lost?   In other words, can I send
> any other command to the target node using the same handle?

Yes.  You can register a bus reset handler with the libraw handle and
should do so if you need to find out whenever something changes.  I'm
currently working on GUID collection and using that for requests, but
I don't think this applies to your problem.

> The reason why I ask this question is:  I am currently trying  to talk to a
> target node which has a "wake up" feature.   In other words, if the target
> node is idle for period of time, it will try to shutdown itself until it
> receives a "wake up" command from my linux box.   However, when the target
> node is idle and auto shutoff.   Bus reset would be generated causing I
> cannot get the respond from the target node anymore using the same
> raw1394_handle.

If the target has its link layer shut down (I guess it has) it can not
process any requests.  It needs a link-on phy packet.  Sending phy
packets is not implemented yet.

>   I have tried to deactivate the bus reset event on
> interrupt of OHCI driver but it is not working.   I believe deactivating the
> interrupt event mask on bus reset is just ignore the bus reset on kernel
> driver side.

Ignoring a bus reset can only cause harm and will not help you there.

> I suppose if the target node get the power from the firewire bus  and my
> firewire card is a power supplier, there shouldn't be any bus reset even if
> the target node is in power off mode.   Is my understanding correct?    I
> know that this is IEEE1394 specific and if you have any suggestion, please
> let me know.

A bus reset is created whenever a node is added, removed, powered up
or powered down.  Anything that would change SelfID information, in
short.

-- 
 Andreas E. Bombe <and...@mu...>    DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/    http://linux1394.sourceforge.net/

RE: Bus Reset

[Jeff M. <Jef...@ef...>]

Sebastien,

Thanks for prompt response.  Yes, the bus reset signal would generate
whenever the target node is in "sleep" mode.

Jeff

-----Original Message-----
From: Sebastien Rougeaux [mailto:Seb...@sy...]
Sent: Sunday, April 16, 2000 9:52 PM
To: Jef...@ef...
Cc: lin...@li...
Subject: Re: Bus Reset


>>>>> "Jeff" == Jeff Mak <Jef...@ef...> writes:

Jeff> I am making use of raw1394 (dev_open) to connect to the other node
Jeff> through OHCI kernel driver, when there is a change in power status at
Jeff> PHY of the other node, a bus reset would be generated from the
hardware.
Jeff> Is it true that the connection in between would be lost?  In other
Jeff> words, can I send any other command to the target node using the same
Jeff> handle?  I know that this is not OHCI specific question but since I am
Jeff> using OHCI kernel driver written by you, I believe you may have some
Jeff> experience on that.

I don't think bus reset are handled properly yet in the current version
of the linux ieee1394 driver. If a bus reset occurs, the node numbers on 
the bus are re-assigned, and I don't think that libraw is designed to deal 
with that situation (I might be wrong though). Especially, the ohci driver
receives a specific phy packet that indicates precisely when the bus 
configuration has been modified, but this packet is currently being 
discarded since the subsystem doesn't accept it... I have to talk to 
Andreas about that.

Jeff> The reason why I ask this question is: I am currently trying to talk
to
Jeff> a target node which has a "wake up" feature.  In other words, if the
Jeff> target node is idle for period of time, it will try to shutdown itself
Jeff> until it receives a "wake up" command from my linux box.  However,
when
Jeff> the target node is idle and auto shutoff.  Bus reset would be
generated
Jeff> causing I cannot get the respond from the target node anymore using
the
Jeff> same raw1394_handle.  I have tried to deactivate the bus reset event
on
Jeff> interrupt of OHCI driver but it is not working.  I believe
deactivating
Jeff> the interrupt event mask on bus reset is just ignore the bus reset on
Jeff> kernel driver side.

Do you mean that everytime the node goes in 'sleep' mode, a bus reset is
generated ???

Jeff> I suppose if the target node get the power from the firewire bus and
my
Jeff> firewire card is a power supplier, there shouldn't be any bus reset
even
Jeff> if the target node is in power off mode.  Is my understanding correct?
Jeff> I know that this is IEEE1394 specific and if you have any suggestion,
Jeff> please let me know.

Sorry I don't know about that particular point of the ieee1394 standard.

-- 
Sebastien Rougeaux
RSISE, The Australian National University