Thread: Re: [Linux1394-devel] Ohci compliance of CXD3222
Brought to you by:
aeb,
bencollins
From: Sebastien R. <Seb...@sy...> - 2000-04-09 09:02:23
|
>>>>> "Bart" == Bart Nabbe <ba...@cs...> writes: Bart> Hmm I thought I gave that in my previous posting, anyhow they are Bart> attached now. The other problem, for the Ti ohci card on reset I solve Bart> using a hack: I reload the drivers until I find the number of nodes I Bart> want on the bus.. This is often the second time.. So my ieee1394 script Bart> in init.d cycles until it finds the camera and life is good. The same Bart> strategy on the Sony chip set never ever find >0 nodes :(. According to your /proc/ohci1394 dump, the card is still in bus reset... which is normal since no self-id packet is received. I'll see what I can do about that. -- Sebastien Rougeaux RSISE, The Australian National University |
From: Sebastien R. <Seb...@sy...> - 2000-04-12 11:35:50
|
>>>>> "Bart" == Bart Nabbe <ba...@cs...> writes: Bart> Unfortunately that version did not resolve the problem, tried with Bart> different number of nodes on the bus while initializing. Same result as Bart> ever 0 nodes and it stays in reset. Bart> I attached the /proc/ohci and kernel messages for this version. Is there Bart> some code to tweak in the reset phase that might shine some light into Bart> this matter? From what I can see, the problem is that you are not receiving the self-id packets... I don't see anything obviously wrong with your register setting, except for the fact that your node id is 1 with the valid bit set (which should be zero if no other nodes are detected on the bus). I have noticed that my ohci card doesn't receive the self-id packets the first time it is initialized after rebooting the computer... have you tried to load/unload the ieee1394 modules a couple of times ? -- Sebastien Rougeaux RSISE, The Australian National University |
From: Sebastien R. <Seb...@sy...> - 2000-06-22 23:32:04
|
>>>>> "Bart" == Bart Nabbe <ba...@cs...> writes: Bart> Hej Sebastien, I did compile a recent snapshot as well for my xg19, and Bart> I can inquire the camera, set and read registers. However, the Bart> framegrab interface stopped working, (also on my Texas Instruments card) Bart> did you change anything? I did enable the framegrab interface in the Bart> include file. Yes, you have to set the attempt_root flag to 1 in the ohci1394.c file. Some people complained about this a week ago, so I removed it, then realized than the framegrabber won't work if the ohci card is not the root node. -- Sebastien Rougeaux RSISE, The Australian National University |
From: Gord P. <go...@sm...> - 2000-06-23 15:39:28
|
On Fri, 23 Jun 2000, Sebastien Rougeaux wrote: > Yes, you have to set the attempt_root flag to 1 in the ohci1394.c file. > Some people complained about this a week ago, so I removed it, then realized > than the framegrabber won't work if the ohci card is not the root node. There is also an interesting discovery I have made about the ohci card becoming the root node. If you have a FireWire hub (at least, with my OrangeLink one) connected to the bus, then the card will never become the root node for some reason. This then causes the bus to be useless (can't communicate with anything on it). So, with me being biased by this problem, I have to ask the question: why wouldn't we want the host controller to always attempt to become the root node? From what I understand, if there are multiple contenders for the root node (ie. say two PCs are hooked together), then only one will become root after the self-ID phase anyways, and everything should work fine even if they are both attempting to become root. Perhaps I missed a discussion on this in my hiatus from the list? Gord |
From: Andreas B. <and...@mu...> - 2000-06-23 21:46:44
|
On Fri, Jun 23, 2000 at 10:59:17AM -0400, Gord Peters wrote: > So, with me being biased by this problem, I have to ask the question: why > wouldn't we want the host controller to always attempt to become the root > node? From what I understand, if there are multiple contenders for the > root node (ie. say two PCs are hooked together), then only one will become > root after the self-ID phase anyways, and everything should work fine > even if they are both attempting to become root. Perhaps I missed a > discussion on this in my hiatus from the list? Another bus manager may have selected one node to become root based on some optimization decision derived from bus topology. Unconditionally attempting to become root would sabotage this and does not conform to 1394 for this reason. Our real problem is that we don't yet have bus management code in the subsystem which would deal with selecting root, among other things. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Bart N. <ba...@cs...> - 2000-06-23 22:06:33
|
Sorry for starting out such a bad subject header, However I'm in that state now. My Vaio XG19 is still streaming images from a Sony DFW digital camera.. /bart |