From: James Courtier-Dutton <James@superbug.co.uk>
To: Harish K Harshan <harish@arl.amrita.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: DMA Transfer problem
Date: Tue, 24 Jan 2006 13:22:54 +0000 [thread overview]
Message-ID: <43D62A2E.10500@superbug.co.uk> (raw)
In-Reply-To: <43D62989.3070108@arl.amrita.edu>
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
next prev parent reply other threads:[~2006-01-24 13:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2006-01-30 16:37 ` Martin Drab
2006-01-30 17:06 ` linux-os (Dick Johnson)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43D62A2E.10500@superbug.co.uk \
--to=james@superbug.co.uk \
--cc=harish@arl.amrita.edu \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox