Thread: I need some info on driver development status
Brought to you by:
aeb,
bencollins
From: Matt P. <mat...@ls...> - 2000-05-03 20:50:13
|
Dear Linux-1394 Zealots, I will be giving an overview presentation on 1394 and Linux at the 1394 Developer's Conference in San Jose, June 20-22. I want to give an update on the state of the 1394 driver development, supported protocols, and future plans. This will be a great opportunity to give the activity of the the this development group some extra credibility and maybe get some more development support. So, please, everybody who's doing anything, let me know where you're at, what you lack, where you're going, and when you might get there with your development activity. I'll share the compilation of what I get with the reflector. Now for the blatant marketing plug.....If you are in the Bay Area on June 20-22, maybe at the Fairmont Hotel, and you have $795 to spare to learn everything you ever wanted to know about 1394...then come to the Developer's Conference!! Here's the link for more information http://www.1394ta.org/Events/DevCon/index.html . It's well worth it. Best regards and I expect to hear from each and every one of you...... Matt -- /*********************** Matt Pujol 1394 Product Marketing Manager LSI Logic 2001 Danfield Court Fort Collins, Co 80525 970-206-5816 mat...@ls... ***********************/ |
From: Southwell <vi...@pt...> - 2000-05-03 22:19:40
|
Can someone please tell me what the current position is on IEEE 1394 = licensing issues as far as they affect the development and use of = firewire under Linux. I am finding the current licensing situation quite = confusing and am concerned to know that anyone using the IEEE 1394 = support will not be landing themselves into a potentially difficult = legal position.. Thanks=20 David S. ----- Original Message -----=20 From: Matt Pujol=20 To: lin...@li...=20 Sent: Wednesday, May 03, 2000 12:43 PM Subject: I need some info on driver development status Dear Linux-1394 Zealots,=20 I will be giving an overview presentation on 1394 and Linux at the = 1394 Developer's Conference in San Jose, June 20-22. I want to give an = update on the state of the 1394 driver development, supported protocols, = and future plans. This will be a great opportunity to give the activity = of the the this development group some extra credibility and maybe get = some more development support.=20 So, please, everybody who's doing anything, let me know where you're = at, what you lack, where you're going, and when you might get there with = your development activity. I'll share the compilation of what I get = with the reflector.=20 Now for the blatant marketing plug.....If you are in the Bay Area on = June 20-22, maybe at the Fairmont Hotel, and you have $795 to spare to = learn everything you ever wanted to know about 1394...then come to the = Developer's Conference!! Here's the link for more information = http://www.1394ta.org/Events/DevCon/index.html . It's well worth it.=20 Best regards and I expect to hear from each and every one of you...... = Matt=20 =20 --=20 /*********************** Matt Pujol 1394 Product Marketing Manager LSI Logic 2001 Danfield Court Fort Collins, Co 80525 970-206-5816 mat...@ls... ***********************/ =20 |
From: Sebastien R. <Seb...@sy...> - 2000-05-03 23:26:07
|
>>>>> "Matt" == Matt Pujol <mat...@ls...> writes: Matt> Dear Linux-1394 Zealots, Matt> I will be giving an overview presentation on 1394 and Linux at the 1394 Matt> Developer's Conference in San Jose, June 20-22. I want to give an Matt> update on the state of the 1394 driver development, supported protocols, Matt> and future plans. This will be a great opportunity to give the activity Matt> of the the this development group some extra credibility and maybe get Matt> some more development support. Matt> So, please, everybody who's doing anything, let me know where you're at, Matt> what you lack, where you're going, and when you might get there with Matt> your development activity. I'll share the compilation of what I get Matt> with the reflector. Hi Matt. Here is the status for the ohci1394 low-level driver: Implemented features: . Async Request Transmit . Async Response Receive . Async Request Receive . Async Response Transmit . Iso Receive Missing features: . Iso Transmit . Config ROM (not properly defined yet) . Compare/Swap using ohci registers and probably tons of other little things Knowns problems: . Stability (still very much alpha quality) . SONY CXD3222 chip (and probably others) is not working properly Main difficulty encountered: . Lack of time (I have plenty of other more important things to do). . Lack of documentation (You have to pay to get the doc on CSR architecture for example). . Lack of hardware (I only have two TI ohci development boards) Good luck with your presentation, -- Sebastien Rougeaux RSISE, The Australian National University |
From: Matt P. <ma...@ls...> - 2000-05-08 18:38:40
|
Ok, you 1394 Lover's of Penguin-based Software........ Your comrade-in-arms, Mr. Rougeaux, gave a nice, concise answer - and quite prompt, I might add. I'd like to thank him, and at the same time, I'd like to ask the rest of you for some info from these areas: SBP-2 A/VC - FCP and CMP IEC-61883 CIP header handling IP over 1394 DPP (I'll bet nobody has even thought about this one) DCAM - either still image or YUV cameras Any_Other_1394_Linux_Stuff_That's_Interesting Once again, a quick note on where you are in the development (milestones hit, functionality reached), where you plan to take it, where the source can be found, and when (or if) you plan to meet the next milestone. You folks really don't want me to beg, here. It won't be pretty. :-) Best Regards and thanks very much in advance, Matt_admirer_of_penguins -- /*********************** Matt Pujol Product Marketing Manager 1394 and USB CoreWare technologies LSI Logic 2001 Danfield Court Fort Collins, Co 80525 970-206-5816 mat...@ls... ***********************/ Sebastien Rougeaux wrote: > >>>>> "Matt" == Matt Pujol <mat...@ls...> writes: > > Matt> Dear Linux-1394 Zealots, > > Matt> I will be giving an overview presentation on 1394 and Linux at the 1394 > Matt> Developer's Conference in San Jose, June 20-22. I want to give an > Matt> update on the state of the 1394 driver development, supported protocols, > Matt> and future plans. This will be a great opportunity to give the activity > Matt> of the the this development group some extra credibility and maybe get > Matt> some more development support. > > Matt> So, please, everybody who's doing anything, let me know where you're at, > Matt> what you lack, where you're going, and when you might get there with > Matt> your development activity. I'll share the compilation of what I get > Matt> with the reflector. > > Hi Matt. > > Here is the status for the ohci1394 low-level driver: > > Implemented features: > > . Async Request Transmit > . Async Response Receive > . Async Request Receive > . Async Response Transmit > . Iso Receive > > Missing features: > > . Iso Transmit > . Config ROM (not properly defined yet) > . Compare/Swap using ohci registers > and probably tons of other little things > > Knowns problems: > > . Stability (still very much alpha quality) > . SONY CXD3222 chip (and probably others) is not working properly > > Main difficulty encountered: > > . Lack of time (I have plenty of other more important things to do). > . Lack of documentation (You have to pay to get the doc on CSR architecture > for example). > . Lack of hardware (I only have two TI ohci development boards) > > Good luck with your presentation, > > -- > Sebastien Rougeaux > RSISE, The Australian National University |
From: Daniel K. <dan...@st...> - 2000-05-13 16:28:32
|
Hi Sebastien! The OHCI irq handler uses reg_read() to determine whether it has to service an interrupt. reg_read() in turn relies on ohci->registers containing the controllers remapped MMIO space. add_card() however requests the irq long before the ioremap(), thus leaving a window open where we might access bogus memory locations. The race should only occur if the irq line is shared with other devices. Patch below that moves request_irq() to the very end of add_card(). Regards, Daniel. --[snip]-- Index: ohci1394.c =================================================================== RCS file: /cvsroot/linux1394/ieee1394/ohci1394.c,v retrieving revision 1.28 diff -u -r1.28 ohci1394.c --- ohci1394.c 2000/05/12 02:16:07 1.28 +++ ohci1394.c 2000/05/13 16:09:14 @@ -2185,13 +2185,6 @@ ohci->state = 0; - if (!request_irq(dev->irq, ohci_irq_handler, SA_SHIRQ, - OHCI1394_DRIVER_NAME, ohci)) { - PRINT(KERN_INFO, ohci->id, "allocated interrupt %d", dev->irq); - } else { - FAIL("failed to allocate shared interrupt %d", dev->irq); - } - /* csr_config rom allocation */ ohci->csr_config_rom = kmalloc(1024, GFP_KERNEL); if (ohci->csr_config_rom == NULL) { @@ -2269,6 +2262,13 @@ PRINT(KERN_INFO, ohci->id, "remapped memory spaces reg 0x%p", ohci->registers); + + if (!request_irq(dev->irq, ohci_irq_handler, SA_SHIRQ, + OHCI1394_DRIVER_NAME, ohci)) { + PRINT(KERN_INFO, ohci->id, "allocated interrupt %d", dev->irq); + } else { + FAIL("failed to allocate shared interrupt %d", dev->irq); + } return 0; #undef FAIL |
From: Sebastien R. <Seb...@sy...> - 2000-05-14 02:08:44
|
>>>>> "Daniel" == Daniel Kobras <dan...@st...> writes: Daniel> Hi Sebastien! The OHCI irq handler uses reg_read() to determine Daniel> whether it has to service an interrupt. reg_read() in turn relies on ohci-> registers containing the controllers remapped MMIO Daniel> space. add_card() however requests the irq long before the ioremap(), Daniel> thus leaving a window open where we might access bogus memory Daniel> locations. The race should only occur if the irq line is shared with Daniel> other devices. Patch below that moves request_irq() to the very end of Daniel> add_card(). Thanks for the patch. Any luck with the SONY chip ? -- Sebastien Rougeaux RSISE, The Australian National University |
From: Daniel K. <dan...@st...> - 2000-05-14 16:35:55
|
On Sun, 14 May 2000, Sebastien Rougeaux wrote: > Thanks for the patch. Any luck with the SONY chip ? Not as much as I'd like to. As I wrote on Friday, there's clearly life on the bus but that's about all I see. Anyway, I've found the cause - or a workaround at least - for the OHCI module hanging my machine when I insmod it the second time: First of all, stop_context() gives me runaway loops upon rmmod. On the next insmod, the chip will lock the machine (well, the PCI bus most probably) when isoRecvIntMask is set to 0x1. I'm not sure why, but I suspect that setting the mask activates the context. The associated program however is not yet initialized. So once again I moved a bit of code around to locations that looked sane to me. I also made sure all iso recv interrupts are cleared on initialization. reg_read()/reg_write() contain some #ifdef'd code to track down such PCI lock ups; maybe someone will find this useful one day. Regards, Daniel. --[snip]-- Index: ohci1394.c =================================================================== RCS file: /cvsroot/linux1394/ieee1394/ohci1394.c,v retrieving revision 1.29 diff -u -r1.29 ohci1394.c --- ohci1394.c 2000/05/14 02:21:11 1.29 +++ ohci1394.c 2000/05/14 16:13:27 @@ -1088,8 +1088,8 @@ reg_write(ohci, OHCI1394_LinkControlSet, 0x00300000); /* Clear interrupt registers */ - reg_write(ohci, OHCI1394_IntEventClear, 0xffffffff); reg_write(ohci, OHCI1394_IntMaskClear, 0xffffffff); + reg_write(ohci, OHCI1394_IntEventClear, 0xffffffff); /* Set up self-id dma buffer */ reg_write(ohci, OHCI1394_SelfIDBuffer, @@ -1156,6 +1156,18 @@ /* Clear the interrupt mask */ reg_write(ohci, OHCI1394_IsoRecvIntMaskClear, 0xffffffff); + reg_write(ohci, OHCI1394_IsoRecvIntEventClear, 0xffffffff); + + /* Initialize AR dma */ + initialize_dma_rcv_ctx(ohci->ar_req_context); + initialize_dma_rcv_ctx(ohci->ar_resp_context); + + /* Initialize AT dma */ + initialize_dma_trm_ctx(ohci->at_req_context); + initialize_dma_trm_ctx(ohci->at_resp_context); + + /* Initialize IR dma */ + initialize_dma_rcv_ctx(ohci->ir_context); /* Set up isoRecvIntMask to generate interrupts for context 0 (thanks to Michael Greger for seeing that I forgot this) */ @@ -1197,17 +1209,6 @@ /* Enable link */ reg_write(ohci, OHCI1394_HCControlSet, 0x00020000); - - /* Initialize AR dma */ - initialize_dma_rcv_ctx(ohci->ar_req_context); - initialize_dma_rcv_ctx(ohci->ar_resp_context); - - /* Initialize AT dma */ - initialize_dma_trm_ctx(ohci->at_req_context); - initialize_dma_trm_ctx(ohci->at_resp_context); - - /* Initialize IR dma */ - initialize_dma_rcv_ctx(ohci->ir_context); return 1; } Index: ohci1394.h =================================================================== RCS file: /cvsroot/linux1394/ieee1394/ohci1394.h,v retrieving revision 1.15 diff -u -r1.15 ohci1394.h --- ohci1394.h 2000/05/14 02:21:11 1.15 +++ ohci1394.h 2000/05/14 16:13:27 @@ -221,12 +221,38 @@ */ inline static void reg_write(const struct ti_ohci *ohci, int offset, u32 data) { +#ifdef OHCI1394_EXCESSIVE_DEBUG + printk(KERN_CRIT "ohci%d: Writing 0x%08x to register 0x%04x.\n", + ohci->id, data, offset); + /* To track down a lockup, other processes must be given a + * chance to display the printk output! + */ + if (!in_interrupt()) + schedule(); writel(data, ohci->registers + offset); + printk(KERN_CRIT "ohci%d: Write done.\n", ohci->id); +#else + writel(data, ohci->registers + offset); +#endif } inline static u32 reg_read(const struct ti_ohci *ohci, int offset) { - return readl(ohci->registers + offset); +#ifdef OHCI1394_EXCESSIVE_DEBUG + u32 tmp; + printk(KERN_CRIT "ohci%d: Reading from register 0x%04x.\n", + ohci->id, offset); + /* To track down a lockup, other processes must be given a + * chance to display the printk output! + */ + if (!in_interrupt()) + schedule(); + tmp = readl(ohci->registers + offset); + printk(KERN_CRIT "ohci%d: Read 0x%08x.\n", ohci->id, tmp); + return tmp; +#else + return readl(ohci->registers + offset); +#endif } /* This structure is not properly initialized ... it is taken from |