Thread: Re: I need some info on driver development status
Brought to you by:
aeb,
bencollins
Menu
▾
▴
linux1394-devel
|
From: Sebastien R. <Seb...@sy...> - 2000-05-11 04:37:23
|
Daniel> At our institute we have a CXD3222 in our Vaio and I'm the unfortunate Daniel> person who has to get it running on Linux. I know you don't have Daniel> access to this particular chipset yourself but perhaps you can provide Daniel> me with a few hints on where to start hunting for problems. I'm using Daniel> the latest IEEE1394 from CVS on a 2.3.99-pre6-pre3-ac1 (hey, this Daniel> one's a must, isn't it? ;-), which has your mdelay() workaround for Daniel> the self-id problems added. The Vaio is linked to a Sony TRV900E Daniel> camcorder. Unfortunately for me the problem persists: I can Daniel> rmmod/insmod/reboot like crazy, but I won't receive a single Daniel> selfid. The only thing that looks unusual to me is an occasional Something wrong is happening during the bus reset phase, but there is not much I can do without the proper hardware to figure it out... I am starting to suspect that irqs are not detected properly... is the irq shared with other devices ? Another stuff to look at is the content of the phy registers (you might have to uncomment some code and add a few debug lines in the driver source for that), and see if there is something wrong (using the 1394 specs). Look also back in the mailing list. Someone suggested to loop in the irq_handler until the node id become valid... but I haven't done anything about that yet. Sorry I can't help much more for the moment. -- Sebastien Rougeaux RSISE, The Australian National University |
|
From: Daniel K. <dan...@st...> - 2000-05-11 10:52:22
|
On Thu, 11 May 2000, Sebastien Rougeaux wrote:
[No-go Sony CXD3222 w/ current OHCI driver]
> Something wrong is happening during the bus reset phase, but there is
> not much I can do without the proper hardware to figure it out...
> I am starting to suspect that irqs are not detected properly... is the
> irq shared with other devices ?
Indeed it is shared, and it has worried me before. It looks like Sony
saved a few lines and routes every PCI device to IRQ 9. Both CardBus
controllers are actually active. The rest of the stuff shouldn't generate
any interrupts.
> Another stuff to look at is the
> content of the phy registers (you might have to uncomment some
> code and add a few debug lines in the driver source for that), and see
> if there is something wrong (using the 1394 specs).
I had only access to the OHCI specs so far but 1394 is on its way. I'll
try to get my hands on the PHYs then.
> Look also back
> in the mailing list. Someone suggested to loop in the irq_handler until
> the node id become valid... but I haven't done anything about that yet.
Okay, I'll give it a try as well. Btw. is anyone else still seeing the
no-nodes-on-bus problem with the CXD3222 chipset (that's Sony's
OHCI-compliant chipset in latest Vaios)?
Sebastien, below is a patch against the current ohci driver from CVS which
you might want to consider. It does
* process only those events in the IRQ handler that we haven't masked.
* shut up interrupts from the card before freeing the IRQ.
* not go through all ifs in the IRQ handler when there are no events to
process.
I think they are correct, however testing is a bit tough when the driver
refuses to find any nodes on the bus. Well, my changes certainly didn't
make things worse for me. ;)
Regards,
Daniel.
Index: ohci1394.c
===================================================================
RCS file: /cvsroot/linux1394/ieee1394/ohci1394.c,v
retrieving revision 1.26
diff -u -r1.26 ohci1394.c
--- ohci1394.c 2000/04/25 09:46:32 1.26
+++ ohci1394.c 2000/05/11 09:31:44
@@ -1538,7 +1538,9 @@
do {
/* read the interrupt event register */
- event=reg_read(ohci, OHCI1394_IntEventSet);
+ event=reg_read(ohci, OHCI1394_IntEventClear);
+ if (!event)
+ return;
/* clear the interrupt event register */
reg_write(ohci, OHCI1394_IntEventClear, event);
@@ -1700,11 +1702,9 @@
"sequence");
#endif
}
- timeout--;
- } while (event && timeout);
+ } while (--timeout);
- if (event) PRINT(KERN_ERR, ohci->id,
- "irq_handler timeout event=0x%08x", event);
+ PRINT(KERN_ERR, ohci->id, "irq_handler timeout event=0x%08x", event);
}
/* Put the buffer back into the dma context */
@@ -2571,6 +2571,9 @@
free_dma_fbuf_ctx(&ohci->fbuf_context[i]);
}
#endif
+
+ /* Shut up card */
+ reg_write(ohci, OHCI1394_IntMaskClear, OHCI1394_masterIntEnable);
/* Free self-id buffer */
if (ohci->self_id_buffer)
--
GNU/Linux Audio Mechanics - http://www.glame.de
GPG Key ID 89BF7E2B - http://www.keyserver.net
|
|
From: Sebastien R. <Seb...@sy...> - 2000-05-11 11:41:18
|
>> Something wrong is happening during the bus reset phase, but there is not >> much I can do without the proper hardware to figure it out... I am >> starting to suspect that irqs are not detected properly... is the irq >> shared with other devices ? Daniel> Indeed it is shared, and it has worried me before. It looks like Sony Daniel> saved a few lines and routes every PCI device to IRQ 9. Both CardBus Daniel> controllers are actually active. The rest of the stuff shouldn't Daniel> generate any interrupts. Could you please add a debug message at the top of the irq handler, and verify that the irq handler is called when the driver is loaded. Something like this: /* read the interrupt event register */ event=reg_read(ohci, OHCI1394_IntEventSet); PRINT(KERN_INFO, ohci->id, "IntEvent: %08x",event); You should have something like this after `insmod ohci1394` ........ ohci1394_0: resetting bus on request and attempting to become root ieee1394: detected 1 ohci1394 adapter ohci1394_0: IntEvent: 00020010 ohci1394_0: IntEvent: 00020000 ohci1394_0: IntEvent: 00020000 ....... Daniel> Sebastien, below is a patch against the current ohci driver from CVS Daniel> which you might want to consider. It does Daniel> * process only those events in the IRQ handler that we haven't masked. Daniel> * shut up interrupts from the card before freeing the IRQ. * not go Daniel> through all ifs in the IRQ handler when there are no events to Daniel> process. Thanks, I will have a look at it. -- Sebastien Rougeaux RSISE, The Australian National University |
|
From: Daniel K. <dan...@st...> - 2000-05-12 18:09:05
|
On Thu, 11 May 2000, Sebastien Rougeaux wrote: [That's still about getting CXD3222 chips to work with ohci1394.o] > Could you please add a debug message at the top of the irq handler, > and verify that the irq handler is called when the driver is loaded. Taking today's ohci driver from CVS, I've run a few more tests in the meantime with more debugging output enabled. In particular I've added code to the irq handler that shows the contents of the IntEvent register masked and unmasked (raw), and the current mask itself. As you proposed, I also included a loop at the beginning of the irq handler to wait for NodeID to become valid. Each cycle has a suckin' udelay(10) in it, but hey, it's only for debugging. The good news is that with those two additions I actually see several PHY packets arriving. Even better, I see PHY activity when switching on and off the camcorder attached to the Vaio. The downside is that still I couldn't figure out how to convince the CXD3222 to handle some selfIDs. As an aside, even though the driver will now properly shut down the chipset when it is removed, a rmmod-insmod cycle without any other activity will inevitably hang the whole machine to the point where Alt-SysRq-b seems to be the only working key combination. I first suspected the irq handler but a few tests proved its innocence. I've never fiddled that much with DMA stuff before and am unsure if a misconfiguration there might lock a machine. Actually I had similar symptoms with an el-cheapo network card that was very picky about the way its MMIO PCI registers were accessed and would eventually mess up the whole PCI bus. Does anyone know of subtle access restrictions regarding the OHCI/IEEE registers? > You should have something like this after `insmod ohci1394` > > ........ > ohci1394_0: resetting bus on request and attempting to become root > ieee1394: detected 1 ohci1394 adapter > ohci1394_0: IntEvent: 00020010 > ohci1394_0: IntEvent: 00020000 > ohci1394_0: IntEvent: 00020000 > ....... Is this a true sequence you see or did you just leave out the null events? In section 6.1.1 of the OHCI specs it says that the controller is supposed to prevent the driver from clearing the bus reset bit until selfIDComplete is flagged, whereas the CXD3222 seems to happily take the ack. I've modified the irq handler to mask busReset and postpone the ack until reception of selfIDComplete in this case but wasn't really successful. Below I've attached a pile of debugging output - maybe some of the OHCI wizards can have a look at it and give me some more hints on what to try next to get this beast going. I'm now off for another night on the specs. Regards, Daniel. --[snip]-- insmod ohci module, camcorder is already turned on: ieee1394: registered ohci1394 driver, initializing now ohci1394: looking for Ohci1394 cards ohci1394_0: allocated interrupt 9 ohci1394_0: The 1st byte at offset 0x404 is: 0x31 ohci1394_0: remapped memory spaces reg 0xd086a000 ohci1394_0: soft reset finished ohci1394_0: max packet size = 2048 bytes ohci1394_0: 4 iso contexts available ohci1394_0: Receive DMA ctx=0 initialized ohci1394_0: Receive DMA ctx=1 initialized ohci1394_0: AT dma ctx=0 initialized ohci1394_0: AT dma ctx=1 initialized ohci1394_0: Receive DMA ctx=2 initialized ohci1394_0: request csr_rom address: C3258000 ohci1394_0: Cancel request received ohci1394_0: resetting bus on request and attempting to become root ieee1394: detected 1 ohci1394 adapter ohci1394_0: NodeID valid in 27. cycle ohci1394_0: IntEvent: 04020000 ohci1394_0: IntEvent (raw): 04d20000, IntMask: 840300bf ohci1394_0: PhyControl: 800101FF ohci1394_0: IntEvent: 00000000 ohci1394_0: IntEvent (raw): 00d00000, IntMask: 840300bf ohci1394_0: NodeID valid in 28. cycle ohci1394_0: IntEvent: 04020000 ohci1394_0: IntEvent (raw): 04d20000, IntMask: 840300bf ohci1394_0: PhyControl: 800101FF ohci1394_0: IntEvent: 00000000 ohci1394_0: IntEvent (raw): 00d00000, IntMask: 840300bf ohci1394_0: NodeID valid in 28. cycle ohci1394_0: IntEvent: 04020000 ohci1394_0: IntEvent (raw): 04d20000, IntMask: 840300bf ohci1394_0: PhyControl: 800101FF ohci1394_0: IntEvent: 00000000 ohci1394_0: IntEvent (raw): 00d00000, IntMask: 840300bf ohci1394_0: NodeID valid in 16. cycle ohci1394_0: IntEvent: 04020000 ohci1394_0: IntEvent (raw): 04d20000, IntMask: 840300bf ohci1394_0: PhyControl: 800101FF ohci1394_0: IntEvent: 00000000 ohci1394_0: IntEvent (raw): 00d00000, IntMask: 840300bf Turn off camcorder: ohci1394_0: NodeID valid in 16. cycle ohci1394_0: IntEvent: 04020000 ohci1394_0: IntEvent (raw): 04f20000, IntMask: 840300bf ohci1394_0: PhyControl: 80030600 ohci1394_0: IntEvent: 00000000 ohci1394_0: IntEvent (raw): 00f00000, IntMask: 840300bf Turn on again: ohci1394_0: IntEvent: 04020000 ohci1394_0: IntEvent (raw): 04f20000, IntMask: 840300bf ohci1394_0: PhyControl: 80070600 ohci1394_0: IntEvent: 00000000 ohci1394_0: IntEvent (raw): 00f00000, IntMask: 840300bf ohci1394_0: NodeID valid in 16. cycle ohci1394_0: IntEvent: 04020000 ohci1394_0: IntEvent (raw): 04f20000, IntMask: 840300bf ohci1394_0: PhyControl: 80070600 ohci1394_0: IntEvent: 00000000 ohci1394_0: IntEvent (raw): 00f00000, IntMask: 840300bf ohci1394_0: NodeID valid in 16. cycle ohci1394_0: IntEvent: 04020000 ohci1394_0: IntEvent (raw): 04f20000, IntMask: 840300bf ohci1394_0: PhyControl: 80010600 ohci1394_0: IntEvent: 00000000 ohci1394_0: IntEvent (raw): 00f00000, IntMask: 840300bf kobras@polaris:~ > cat /proc/ohci1394 IEEE-1394 OHCI Driver status report: bus number: 0x3ff Node ID: 0x0 ### Host data ### node_count: 0 node_id : 00000000 irm_id : 0000FFFF busmgr_id : 0000FFFF initialized in_bus_reset attempt_root ---Iso Receive DMA--- Current buf: 0 offset: 0 ---Async Receive DMA--- Ar req current buf: 0 offset: 0 AR resp current buf: 0 offset: 0 ---Async Transmit DMA--- AT req prg: 0 sent: 0 free: 32 branchAddrPtr: 00000000 AT req queue: first: 00000000 last: 00000000 AR resp prg: 0 sent: 0 free: 32 branchAddrPtr: 00000000 AT resp queue: first: 00000000 last: 00000000 ### HC Register dump ### Version : 01010000 GUID_ROM : 00000000 ATRetries : 00000822 CSRReadData : 00000000 CSRCompData : 00000000 CSRControl : 80000000 ConfigROMhdr: 04040000 BusID : 31333934 BusOptions : f07da002 GUIDHi : 08004603 GUIDLo : 002aee04 ConfigROMmap: 03258000 PtdWrAddrLo : 00000000 PtdWrAddrHi : 00000000 VendorID : 00000000 HCControl : 004e0000 SelfIDBuffer: 02a11000 SelfIDCount : 00010000 IRMuChMaskHi: 00000000 IRMuChMaskLo: 00000000 IntEvent : 00f00000 IntMask : 840300bf IsoXmIntEvnt: 00000000 IsoXmIntMask: 00000000 IsoRcvIntEvt: 00000000 IsoRcvIntMsk: 00000001 FairnessCtrl: 00000000 LinkControl : 00300200 NodeID : 8800ffc0 PhyControl : 86000600 IsoCyclTimer: 5b3a5219 AsRqFilterHi: 80000000 AsRqFilterLo: 00000000 PhyReqFiltHi: 00000000 PhyReqFiltLo: 00000000 PhyUpperBnd : 00000000 AsRqTrCxtCtl: 00000000 AsRqTrCmdPtr: 00000000 AsRsTrCtxCtl: 00000000 AsRsTrCmdPtr: 00000000 AsRqRvCtxCtl: 00008400 AsRqRvCmdPtr: 02cefa81 AsRsRvCtxCtl: 00008400 AsRsRvCmdPtr: 02cefc81 IntEvent : 00f00000 IsoRCtxCtl00: d0008400 IsoRCmdPtr00: 02cefe81 IsoRCxtMch00: f0000000 IsoRCtxCtl01: 00000000 IsoRCmdPtr01: 00000000 IsoRCxtMch01: 00000000 IsoRCtxCtl02: 00000000 IsoRCmdPtr02: 00000000 IsoRCxtMch02: 00000000 IsoRCtxCtl03: 00000000 IsoRCmdPtr03: 00000000 IsoRCxtMch03: 00000000 ### Phy Register dump ### offset: 1 val: 0x2c -> RHB: 0IBR: 0 Gap_count: 44 offset: 2 val: 0xe3 -> SPD: 3 E : 1 Ports : 3 offset: 3 val: 0x41 -> [port 0] TPA: 1 TPB: 0 | parent disconnected offset: 4 val: 0x88 -> [port 1] TPA: 2 TPB: 0 | child disconnected offset: 5 val: 0x03 -> [port 2] TPA: 0 TPB: 0 | parent disconnected offset: 6 val: 0x00 -> ENV: backplane Reg_count: 0 |
Thanks for helping keep SourceForge clean.
X