embedded sound architecture question

embedded sound architecture question

[Joachim Förster]

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.

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

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

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?

Thanks for reading & your time,
 Joachim

Re: embedded sound architecture question

[John L. Utz III]

On Wed, 09 May 2007 22:47:34 +0200
"Joachim Förster" <mls.JOFT@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@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: embedded sound architecture question

[Joachim Förster]

On Wed, 2007-05-09 at 14:20 -0700, John L. Utz III wrote:
> On Wed, 09 May 2007 22:47:34 +0200
> "Joachim Förster" <mls.JOFT@gmx.de> wrote:
> > 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.

Hmmm, well is there a standard document for AC97 controllers, too? So
far, I know about the AC97 Codec standard, only. Anyway, just ignore the
"AC97" in front of "controller" - a custom controller for an AC97 Codec,
which uses the described way of operation and features. The/My question
is, if such a thing is reasonable and fits into ALSA/Linux.

> > 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.

So, not using MMAP mode is just a no-go ... ? I don't want to write a
driver which cannot be used with most ALSA applications out there.

 Joachim

Re: embedded sound architecture question

[Rask Ingemann Lambertsen]

On Wed, May 09, 2007 at 10:47:34PM +0200, Joachim Förster wrote:
[snip]
> 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.
[snip]
> 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?

   You can't assume that IO memory can be accessed just as if it was memory
on all architectures. However, in this case it seems that you can make sure
that this is so. I think you should ask on the kernel mailing list what you
should do designing the hardware to make sure it will work.
  
-- 
Rask Ingemann Lambertsen

embedded sound architecture question

[Lorenz Kolb]

On Wed, 2007-05-09 at 14:20 -0700, John L. Utz III wrote:
 > On Wed, 09 May 2007 22:47:34 +0200
 > "Joachim Förster" <mls.JOFT at gmx.de> wrote:
 > > 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.

Hi, I am the "Hardware-Guy" in the project.

And I am quite sure there is no limitation on what to built into the 
AC'97 controller (from a specs point of view)
The controller's job in the AC'97 standard is afaik mainly a parallel to 
serial conversion. As the codec's link is serial.
But I am not quite sure, if you do understand: we have complete control 
of what the hardware-part does. So our main idea is: presenting some 
sort of "dedicated" RAM to the system.
So what does memory mean for a system: it is a bunch of addresses 
offering both a read() and a write() (maybe also a burst_read() and 
burst_write()).
The only question is: will Linux-kernel be able to see our dedicated 
memory as memory and does this way make sense for ALSA.
It is not a question of "is this possible for a AC'97 controller?".
We are not building a simple/stupid AC'97 controller as it can be found 
on billions of mainboards, but in some parts it sticks to the rules of 
AC'97 (at least in case of the interface towards the codec, as the codec 
is an AC'97). So actually it is an AC'97 controller, as it drives an 
AC'97 codec.
So what are the benefits of the idea not using "normal" DMA?
Each write/read to memory normally "freezes" the CPU, either because the 
CPU does this read/write or because the Bus is occupied. Having an 
dedicated memory in the controller avoids this quite well. The CPU 
freezes only whenever it writes data to the controller's memory (or 
reads from it). Accessing the memory from the controller does not have 
an effect on the bus and thus neither cpu nor memory nor bus become 
occupied.
The main reason why we do not want to rely on the cpu is because it is 
for an embedded system. So we do not talk about giga-hertz. We talk 
about a system with a 100 MHz bus architecture and a PowerPC with 300 
MHz. And the system has more tasks than only playing some audio...
So the design goal is minimizing the system load while offering a 
maximum of features (with an affordable amount of logic).

Greetings,

Lorenz Kolb