[Fwd: [alsa-devel] embedded sound architecture question]

[Fwd: [alsa-devel] embedded sound architecture question]

[Joachim Förster]

Hi,

I posted the following question/mail to the ALSA development mailing
list and somebody suggested posting it to the LKML, but I thought,
perhaps it is better to ask you, the Linux PPC embedded experts first,
since it is right about that topic.

It would be nice if somebody can say, if the described architecture
makes sense and will work or if it is a complete no-go.

-------- Forwarded Message --------
From: Joachim Förster <mls.JOFT@gmx.de>
To: alsa-devel@alsa-project.org
Subject: [alsa-devel] embedded sound architecture question
Date: Wed, 09 May 2007 22:47:34 +0200

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

[snip]

Thanks for reading & your time,
 Joachim

RE: [Fwd: [alsa-devel] embedded sound architecture question]

[Leonid]

ALSA middle layer is VERY sensitive to timing and it's extremely =
important how HW device behaves (I mean PCM part of driver, MIDI is =
quite simple). Recording ("capturing") poses even more problems than =
replaying.=20

Last but not least, different applications tend to deal differently with =
ALSA and one should have really good understanding of what's going on to =
configure everything properly.

I must admit that I'm not ALSA expert myself, but I was involved in =
writing ALSA Linux driver for some chip which didn't have one. During =
this process I realized that this is not a miracle nobody before =
bothered to write driver for that chip since it was rather laborious =
task. =20

You are in better situation - you kind of can create your HW yourself. =
If I were you, I would chose one of sound cards which have ALSA drivers =
implemented (the list can be found on ALSA site) and mimicked their =
behavior in your VHDL.

Thanks,

Leonid.

-----Original Message-----
From: linuxppc-embedded-bounces+leonid=3Da-k-a.net@ozlabs.org =
[mailto:linuxppc-embedded-bounces+leonid=3Da-k-a.net@ozlabs.org] On =
Behalf Of Joachim F=F6rster
Sent: Sunday, May 13, 2007 8:15 AM
To: linuxppc-embedded@ozlabs.org
Subject: [Fwd: [alsa-devel] embedded sound architecture question]

Hi,

I posted the following question/mail to the ALSA development mailing
list and somebody suggested posting it to the LKML, but I thought,
perhaps it is better to ask you, the Linux PPC embedded experts first,
since it is right about that topic.

It would be nice if somebody can say, if the described architecture
makes sense and will work or if it is a complete no-go.

-------- Forwarded Message --------
From: Joachim F=F6rster <mls.JOFT@gmx.de>
To: alsa-devel@alsa-project.org
Subject: [alsa-devel] embedded sound architecture question
Date: Wed, 09 May 2007 22:47:34 +0200

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

[snip]

Thanks for reading & your time,
 Joachim


_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: [Fwd: [alsa-devel] embedded sound architecture question]

[Lorenz Kolb]

Hi leonid,

To be precise, I am the guy in question, who has to do the hardware-part and
You guessed it: The board is an ML403.
So what are the problems:
- DMA (whenever an DMA transfer is issued the CPU is put to soem sort of
"freeze", as the bus is occupied, whenever the CPU writes to memory it is
also busy: that solution is not really good, occupying the CPU some sort of
twice)
+ possible solution: some sort of multiport memory controller (or our idea:
own memory directly attached to the ac'97 controller) using BRAM.

> If I were you, I would chose one of sound cards which have ALSA
> drivers implemented (the list can be found on ALSA site) and
> mimicked their behavior in your VHDL.

Actually a bunch of theses drivers rely on PCI or ISA.
The few left do all require DMA, what is only an option, if it is some sort
of faked DMA, so the CPU writes directly into the controller's memory as we
intend to stay as independent as possible from Xilinx' IP Cores.
The question was: is that a good (and practicable) idea?

Greetings,

Lorenz Kolb

Re: [Fwd: [alsa-devel] embedded sound architecture question]

[Sylvain Munaut]

Hi,

>> If I were you, I would chose one of sound cards which have ALSA
>> drivers implemented (the list can be found on ALSA site) and
>> mimicked their behavior in your VHDL.
>>     
>
> Actually a bunch of theses drivers rely on PCI or ISA.
> The few left do all require DMA, what is only an option, if it is some sort
> of faked DMA, so the CPU writes directly into the controller's memory as we
> intend to stay as independent as possible from Xilinx' IP Cores.
> The question was: is that a good (and practicable) idea?
>   

If you can spare the BRAM, that sounds good to me.

I'm not an alsa expert but I'm working on a driver right now. And alsa
provide you a hook so you can allocate your memory buffer your self.
So as long as your control maps it's memory somewhere in the
cpu address space you should be fine.

What you need is :
 - Be able to ask the hardware where is is "read pointer".
 - Be able to ask the hardware to generate an interrupt every 'n' samples.

And that should do it.

You also need to make the controller build the AC97 frames itself
(e.g. for the control slots, a separate set of registers), and also
preferrably
supporting multiple sample format so the CPU needs to do a minimum of
conversion.


        Sylvain

Re: [Fwd: [alsa-devel] embedded sound architecture question]

[Joachim Förster]

Hi Sylvain,

thank you very much for your mail,

On Tue, 2007-05-15 at 09:09 +0200, Sylvain Munaut wrote:
> I'm not an alsa expert but I'm working on a driver right now. And alsa
> provide you a hook so you can allocate your memory buffer your self.
> So as long as your control maps it's memory somewhere in the
> cpu address space you should be fine.

By "hook", do you mean the prepare()/hw_params() callbacks?

I noticed that there is an (undocumented?) mmap() callback, too, so I
think, I have to implement that one and call something like
io_remap_pfn_range() to "connect" the device's memory to the VMA
(virtual memory area) which is provided as an argument to the mmap()
callback, right?

In our case, we are not going to allocate any memory like a typical ALSA
driver does (with DMA) (in prepare()/hw_params() callback), because the
device's IO memory will "be there" - we just have to "announce"/map it
into kernel space, right? Or is this interpretation wrong?

 Joachim

Re: [Fwd: [alsa-devel] embedded sound architecture question]

[Sylvain Munaut]

Joachim Förster wrote:
> Hi Sylvain,
>
> thank you very much for your mail,
>
> On Tue, 2007-05-15 at 09:09 +0200, Sylvain Munaut wrote:
>   
>> I'm not an alsa expert but I'm working on a driver right now. And alsa
>> provide you a hook so you can allocate your memory buffer your self.
>> So as long as your control maps it's memory somewhere in the
>> cpu address space you should be fine.
>>     
>
> By "hook", do you mean the prepare()/hw_params() callbacks?
>   
hw_params and hw_free yes.

I personally use snd_pcm_lib_malloc_pages to allocate the buffer, but
you'll have to write your own, and in the same call back configure the
period rate for you hw to generate interrupt.

> I noticed that there is an (undocumented?) mmap() callback, too, so I
> think, I have to implement that one and call something like
> io_remap_pfn_range() to "connect" the device's memory to the VMA
> (virtual memory area) which is provided as an argument to the mmap()
> callback, right?
>   
Sorry, no idea ... but it's likely that you need to handle the mapping
of this
zone in userspace by yourself ...
> In our case, we are not going to allocate any memory like a typical ALSA
> driver does (with DMA) (in prepare()/hw_params() callback), because the
> device's IO memory will "be there" - we just have to "announce"/map it
> into kernel space, right? Or is this interpretation wrong?
>   
No I think that should work.

You need a quite a few BRAMs though ... buffers are often 128k at the
minimum, so that's 64 brams ....

Sylvain