* DMA Transfer problem @ 2006-01-24 5:00 Harish K Harshan 2006-01-24 12:59 ` James Courtier-Dutton 0 siblings, 1 reply; 6+ messages in thread From: Harish K Harshan @ 2006-01-24 5:00 UTC (permalink / raw) To: linux-kernel Hello, Im having problems with DMA transfer on Linux, for an ADC card. The card is AxiomTek AX5621H, and can use DMA channels 1 and 3. I tried both the channels, but the DMA transfers are irregular (i.e.) at different speeds (which of course is not acceptable, since that application is time critical). The device driver (which I wrote) seems to work fine for all the other systems I tried it on. But this problem occurs only on one particular model of computer (Chino-Laxsons Pentium-4 boards). I tried another system with the same configuration, but the same resulted. After some time of execution, I get the kernel panic screen, which says the CPU context is corrupt. Please help me with this problem, as I need to get this driver working somehow on the P4 systems. I tried the Redhat-9 kernel (2.4.20-8) and the debian kernel too (2.2.20).... gave the same results. Thanks in advance, Harish. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: DMA Transfer problem 2006-01-24 5:00 DMA Transfer problem Harish K Harshan @ 2006-01-24 12:59 ` James Courtier-Dutton 2006-01-24 13:20 ` Harish K Harshan 0 siblings, 1 reply; 6+ messages in thread From: James Courtier-Dutton @ 2006-01-24 12:59 UTC (permalink / raw) To: Harish K Harshan; +Cc: linux-kernel Harish K Harshan wrote: > Hello, > > Im having problems with DMA transfer on Linux, for an ADC card. The > card is AxiomTek AX5621H, and can use DMA channels 1 and 3. I tried > both the channels, but the DMA transfers are irregular (i.e.) at > different speeds (which of course is not acceptable, since that > application is time critical). The device driver (which I wrote) seems > to work fine for all the other systems I tried it on. But this problem > occurs only on one particular model of computer (Chino-Laxsons > Pentium-4 boards). I tried another system with the same configuration, > but the same resulted. After some time of execution, I get the kernel > panic screen, which says the CPU context is corrupt. Please help me > with this problem, as I need to get this driver working somehow on the > P4 systems. I tried the Redhat-9 kernel (2.4.20-8) and the debian > kernel too (2.2.20).... gave the same results. > Could an ADC card be treated as a ALSA sound card PCM device. That card seems to have features very similar to a sound card. Sample rate. Variable gain. Multi-channels. ADC DMA I only suggest this, because it could result in a driver that is much easier to implement as ALSA supplies a lot of generalised support code at the kernel level. James ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: DMA Transfer problem 2006-01-24 12:59 ` James Courtier-Dutton @ 2006-01-24 13:20 ` Harish K Harshan 2006-01-24 13:22 ` James Courtier-Dutton 2006-01-30 16:37 ` Martin Drab 0 siblings, 2 replies; 6+ messages in thread From: Harish K Harshan @ 2006-01-24 13:20 UTC (permalink / raw) To: James Courtier-Dutton; +Cc: linux-kernel Thank You, James, But the problem with sound card drivers are that they dont have a configurable clock on them, do they??? and as far as i know, this ADC card involves a lot of register writings for the counter ICs that help configuring the clock speed for the DMA transfer.... First we set the control properties, which involves the IRQ, start channel, stop channel, etc (the card is an 8-channel ADC), (the jumper settings configure the DMA channels that should be used, 1 or 3). Now we initialize the DMA controller, so that it throws an interrupt once the transfer of DMA_COUNT samples of data. The interrupt service routine for this interrupt can handle the data transfer to the user program. Roughly thats how the driver works... Now, the problem is that, when running on the Chino-Laxsons board PCs, the DMA transfers take varying time to complete (say, if one transfer takes one second, the next might take one and a half), but this is not supposed to (and doesnt) happen on any other machines we tested on. Its absolutely synchronous with the clock, and theres the minimal drift. Can anyone suggest why this could be happening on this particular board??? And another interesting thing is that, this card seems to work fine with the Windows driver available to it (provided by the company.). I need help on this very urgently. If anybody has had any such experience, and solved it, please let me know. Thanks in advance, Harish. James Courtier-Dutton wrote: > Harish K Harshan wrote: > >> Hello, >> >> Im having problems with DMA transfer on Linux, for an ADC card. The >> card is AxiomTek AX5621H, and can use DMA channels 1 and 3. I tried >> both the channels, but the DMA transfers are irregular (i.e.) at >> different speeds (which of course is not acceptable, since that >> application is time critical). The device driver (which I wrote) >> seems to work fine for all the other systems I tried it on. But this >> problem occurs only on one particular model of computer >> (Chino-Laxsons Pentium-4 boards). I tried another system with the >> same configuration, but the same resulted. After some time of >> execution, I get the kernel panic screen, which says the CPU context >> is corrupt. Please help me with this problem, as I need to get this >> driver working somehow on the P4 systems. I tried the Redhat-9 kernel >> (2.4.20-8) and the debian kernel too (2.2.20).... gave the same results. >> > Could an ADC card be treated as a ALSA sound card PCM device. > That card seems to have features very similar to a sound card. > Sample rate. > Variable gain. > Multi-channels. > ADC > DMA > > I only suggest this, because it could result in a driver that is much > easier to implement as ALSA supplies a lot of generalised support code > at the kernel level. > > James > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: DMA Transfer problem 2006-01-24 13:20 ` Harish K Harshan @ 2006-01-24 13:22 ` James Courtier-Dutton 2006-01-30 16:37 ` Martin Drab 1 sibling, 0 replies; 6+ messages in thread From: James Courtier-Dutton @ 2006-01-24 13:22 UTC (permalink / raw) To: Harish K Harshan; +Cc: linux-kernel Harish K Harshan wrote: > Thank You, James, > > But the problem with sound card drivers are that they dont have a > configurable clock on them, do they??? and as far as i know, this ADC > card involves a lot of register writings for the counter ICs that help > configuring the clock speed for the DMA transfer.... It depends which clock you are referring to. Sound cards can set the sample rate. Sound cards also set "period" sizes, so that once enough samples have been captured by the sound card hardware, the hardware initiates a DMA transfer. Could this "period" be the "clock speed" setting you are talking about? > First we set the control properties, which involves the IRQ, start > channel, stop channel, etc (the card is an 8-channel ADC), (the jumper > settings configure the DMA channels that should be used, 1 or 3). Now > we initialize the DMA controller, so that it throws an interrupt once > the transfer of DMA_COUNT samples of data. The interrupt service > routine for this interrupt can handle the data transfer to the user > program. Roughly thats how the driver works... Now, the problem is > that, when running on the Chino-Laxsons board PCs, the DMA transfers > take varying time to complete (say, if one transfer takes one second, > the next might take one and a half), but this is not supposed to (and > doesnt) happen on any other machines we tested on. Its absolutely > synchronous with the clock, and theres the minimal drift. Can anyone > suggest why this could be happening on this particular board??? And > another interesting thing is that, this card seems to work fine with > the Windows driver available to it (provided by the company.). I need > help on this very urgently. If anybody has had any such experience, > and solved it, please let me know. > So, the "DMA_COUNT" sounds like what ALSA refers to as the period. All the rest, IRQ, start/stop are handled but the current ALSA sound card drivers. The DMA channel to use would have to be a kernel module option if they use jumpers. James ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: DMA Transfer problem 2006-01-24 13:20 ` Harish K Harshan 2006-01-24 13:22 ` James Courtier-Dutton @ 2006-01-30 16:37 ` Martin Drab 2006-01-30 17:06 ` linux-os (Dick Johnson) 1 sibling, 1 reply; 6+ messages in thread From: Martin Drab @ 2006-01-30 16:37 UTC (permalink / raw) To: Harish K Harshan; +Cc: James Courtier-Dutton, linux-kernel On Tue, 24 Jan 2006, Harish K Harshan wrote: > Thank You, James, > > But the problem with sound card drivers are that they dont have a > configurable clock on them, do they??? and as far as i know, this ADC card > involves a lot of register writings for the counter ICs that help configuring > the clock speed for the DMA transfer.... First we set the control properties, > which involves the IRQ, start channel, stop channel, etc (the card is an > 8-channel ADC), (the jumper settings configure the DMA channels that should be > used, 1 or 3). Now we initialize the DMA controller, so that it throws an > interrupt once the transfer of DMA_COUNT samples of data. The interrupt > service routine for this interrupt can handle the data transfer to the user > program. Roughly thats how the driver works... Now, the problem is that, when > running on the Chino-Laxsons board PCs, the DMA transfers take varying time to > complete (say, if one transfer takes one second, the next might take one and a I'm not really sure what do you mean by that, but there may be lots of reasons for this. Bad bus latencies, other devices blocking the bus, bad chipset, bad PCI/DMA controller on the device (this happend to me with an AMCC S5933 MatchMaker PCI chip, since it has about 16 HW construction bugs within it which makes it nearly impossible to reliably use it with any reaonably new chipset - with very old chipsets the bugs didn't demonstrate themselfs that much), etc. And you may also consider a hard real-time system if it's really time critical and intensive. Martin ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: DMA Transfer problem 2006-01-30 16:37 ` Martin Drab @ 2006-01-30 17:06 ` linux-os (Dick Johnson) 0 siblings, 0 replies; 6+ messages in thread From: linux-os (Dick Johnson) @ 2006-01-30 17:06 UTC (permalink / raw) To: Martin Drab; +Cc: Harish K Harshan, James Courtier-Dutton, linux-kernel On Mon, 30 Jan 2006, Martin Drab wrote: > On Tue, 24 Jan 2006, Harish K Harshan wrote: > >> Thank You, James, >> >> But the problem with sound card drivers are that they dont have a >> configurable clock on them, do they??? and as far as i know, this ADC card >> involves a lot of register writings for the counter ICs that help configuring >> the clock speed for the DMA transfer.... First we set the control properties, >> which involves the IRQ, start channel, stop channel, etc (the card is an >> 8-channel ADC), (the jumper settings configure the DMA channels that should be >> used, 1 or 3). Now we initialize the DMA controller, so that it throws an >> interrupt once the transfer of DMA_COUNT samples of data. The interrupt >> service routine for this interrupt can handle the data transfer to the user >> program. Roughly thats how the driver works... Now, the problem is that, when >> running on the Chino-Laxsons board PCs, the DMA transfers take varying time to >> complete (say, if one transfer takes one second, the next might take one and a > > I'm not really sure what do you mean by that, but there may be lots of > reasons for this. Bad bus latencies, other devices blocking the bus, bad > chipset, bad PCI/DMA controller on the device (this happend to me with > an AMCC S5933 MatchMaker PCI chip, since it has about 16 HW construction > bugs within it which makes it nearly impossible to reliably use it with > any reaonably new chipset - with very old chipsets the bugs didn't > demonstrate themselfs that much), etc. And you may also consider a hard > real-time system if it's really time critical and intensive. > > Martin If you are configuring a bus-master for DMA transfer across the PCI/Bus, you need to make sure that all the messages got to the device. The PCI/Bus is a FIFO. If you are writing a lot of stuff to your board, it may wait, depending upon where it is "parked" for more data to be written. To make sure that everything gets to your hardware NOW, execute a dummy READ in your hardware's address space immediately after the last instruction that is supposed to start the DMA. Also, you need to make that READ in some way that the 'C' compiler won't delete it as an unnecessary instruction, i.e., (void)readl(addr) may not work! You need to make an assignment to something that could get accessed like junk = readl(status), where junk is global! The "volatile-ness" of the readl() macro won't protect you from having the instruction deleted entirely when the 'C' compiler determines that the code "does nothing"! Cheers, Dick Johnson Penguin : Linux version 2.6.13.4 on an i686 machine (5589.66 BogoMips). Warning : 98.36% of all statistics are fiction. . **************************************************************** The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-01-30 17:06 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-01-24 5:00 DMA Transfer problem Harish K Harshan 2006-01-24 12:59 ` James Courtier-Dutton 2006-01-24 13:20 ` Harish K Harshan 2006-01-24 13:22 ` James Courtier-Dutton 2006-01-30 16:37 ` Martin Drab 2006-01-30 17:06 ` linux-os (Dick Johnson)
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).