[alsa-devel] embedded sound architecture question

[John L. Utz III]

On Wed, 09 May 2007 22:47:34 +0200
"Joachim Förster" <mls.JOFT at gmx.de> wrote:

> Hi ALSA devs,
> 
> I'm going to write an ALSA driver for a not yet existing AC97
> controller, which is going to be "written" (VHDL), too (at the same
> time). Platform/Board is a Xilinx ML403 with Virtex-4 FPGA, PowerPC
> 405 architecture, OPB/OCP bus, AC97 Codec LM4550.

that kinda sounds like fun! i wish i could do vhdl in my job too.

> Before presenting my question, I have to say, that I'm a beginner with
> ALSA/Linux driver development.

in november of 06, so was i. i am still :-)

> My question is: Does the architecture described below make sense/is
> reasonable with ALSA and Linux?

i think you might have to answer an earlier question first; 'does it
make sense to call this an ac97 controller?' I dont recall seeing a
ring buffer as part of the ac97 standard. i'd suggest that you take the
time to flesh out completely how the ring buffer is supposed to replace
dma and ram while still presenting an ac97 set of verbs because i am
stuck with the gut feeling that you will some important things will
have to be really different.

but again, i am a beginner so my gut feeling could be wrong.

or, i could be correct, but that the folks that are porting alsa to dma
free architectures have already figured out a robust and standard
solution that you could adopt - i'll be curious to see what others
say...

> The problem is, that there is no DMA controller and implementing an
> OPB master device which would be able to do DMA itself is not an
> option at this time.
> So our thoughts were: Integrate the "DMA ring buffer" (which is
> usually somewhere in main memory/RAM) into the AC97 controller. Make
> ALSA access this HW buffer as if it was in main memory. This way, the
> device (AC97 controller) has "direct access" to its buffer "memory" -
> this could be called "fake DMA".
> The AC97 controller would have tell us where it is while playing and
> firing interrupts after one period, so that we don't write to values
> which are in the current period, instead update the area where of the
> past played periods etc. ... The buffer should be a "ring buffer",
> right?
> 
> Mapping this "IO memory" into kernel space should be possible with
> io_remap_page_range(), right?
> I would have to implement the mmap() callback in my driver, to setup
> the given VMA (with the above function), right?
> So, ALSA library/applications will be able to use MMAP mode, which is
> what we want to achieve?
> [We don't want copy()/silence(). An intermediate buffer with
> ack()/tasklet/workqueue + FIFO in HW would be an alternative.]
> 
> I read, that many applications don't work, if MMAP mode is not
> supported and classic read/write (copy()/silence()) is used, only. Is
> there a black list of apps, which don't work?

i doubt seriously that such a thing exists, how could it? new apps are
written everyday, old apps in binary only form get 'shimmed' forward
with comaptibility libraries to work in newer operating systems.

> Thanks for reading & your time,

good luck!

johnu

>  Joachim
> 
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>