From: Russell King <rmk+alsa@arm.linux.org.uk>
To: "Gupta, Kshitij" <kshitij@ti.com>
Cc: Jaroslav Kysela <perex@suse.cz>, alsa-devel@lists.sourceforge.net
Subject: Re: buffer producer/consumer sync
Date: Tue, 9 Mar 2004 11:46:44 +0000 [thread overview]
Message-ID: <20040309114644.A5296@flint.arm.linux.org.uk> (raw)
In-Reply-To: <F509E6111989D311B63700805FA761DA09F29071@DBDE01>; from kshitij@ti.com on Tue, Mar 09, 2004 at 05:03:37PM +0530
On Tue, Mar 09, 2004 at 05:03:37PM +0530, Gupta, Kshitij wrote:
> I was referring to a ARM implementation in the ALSA tree for our
> ALSA driver development on OMAP 1610 (ARM 926)
> sound\arm\sa11xx-uda1341.c. Just wanted to know if sa11xx-uda1341.c is also
> affected by this problem.
sa11xx-uda1341 isn't a good driver to look at - it's very specific to
the iPAQ as it stands. I've been working on a properly modularised
driver which separates out the PCM DMA engine from the rest of the
code, which in turn makes it a lot easier to add support for different
platforms. IOW, I've done the job properly.
However, just as the iPAQ people (didn't) work with the rest of the
ARM community when they created their supposed generic sa11xx-uda1341
implementation, the rest of the ARM community didn't work with them
when creating our driver. And now various people are calling for
sa11xx-uda1341 to be deleted once my driver is merged. It's good when
communities fragment, isn't it? 8(
However, the problem I've been describing is a problem with the core
ALSA implementation and affects all hardware drivers on ARM, whether
they be PCI, ISA or ARM specific.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
next prev parent reply other threads:[~2004-03-09 11:46 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-09 11:33 buffer producer/consumer sync Gupta, Kshitij
2004-03-09 11:46 ` Russell King [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-03-31 5:02 Gupta, Kshitij
2004-03-31 7:31 ` Russell King
2004-03-31 7:44 ` Jaroslav Kysela
2004-03-31 7:53 ` Russell King
2004-03-31 8:10 ` Jaroslav Kysela
2004-03-31 8:11 ` Russell King
2004-03-31 8:29 ` Jaroslav Kysela
2004-03-31 8:53 ` Russell King
2004-03-31 9:07 ` Jaroslav Kysela
2004-03-31 9:10 ` Russell King
2004-03-31 9:22 ` Jaroslav Kysela
2004-03-31 9:27 ` Russell King
2004-03-31 11:31 ` James Courtier-Dutton
2004-03-09 10:40 Gupta, Kshitij
2004-03-09 9:51 Gupta, Kshitij
2004-03-09 9:53 ` Jaroslav Kysela
2004-03-09 10:18 ` Russell King
2004-03-09 10:23 ` Jaroslav Kysela
2004-03-09 10:43 ` Russell King
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=20040309114644.A5296@flint.arm.linux.org.uk \
--to=rmk+alsa@arm.linux.org.uk \
--cc=alsa-devel@lists.sourceforge.net \
--cc=kshitij@ti.com \
--cc=perex@suse.cz \
/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