[PATCH 0/2] Arcam AV Control Plugin Updates

[PATCH 0/2] Arcam AV Control Plugin Updates

[Peter Stokes]

Hi,

The following patches provide minor updates to the Arcam AV control plug-in.

 * [PATCH 1/2] Remove incorrect usage of the static SHM ID variable
 * [PATCH 2/2] Refactor control specifications to facilitate addition of "numid" optimisation

Takashi,

I attempted to follow the pattern of your recent commits regarding the "numid" optimisations for external control plug-ins. 
Hopefully I've provided the correct behavior. Something that am not sure about is whether I should be calling 
the "snd_ctl_elem_id_set_numid()" function from "ctl_arcam_av.c" "arcam_av_read_event()" either in addition or instead of 
the calls to the "snd_ctl_elem_id_set_name()" function?

Thanks

Peter

Re: [PATCH 0/2] Arcam AV Control Plugin Updates

[Takashi Iwai]

At Sat, 21 Feb 2009 16:59:47 +0000,
Peter Stokes wrote:
> 
> Hi,
> 
> The following patches provide minor updates to the Arcam AV control plug-in.
> 
>  * [PATCH 1/2] Remove incorrect usage of the static SHM ID variable
>  * [PATCH 2/2] Refactor control specifications to facilitate addition of "numid" optimisation
> 
> Takashi,
> 
> I attempted to follow the pattern of your recent commits regarding the "numid" optimisations for external control plug-ins. 
> Hopefully I've provided the correct behavior.

Thanks, applied now.

> Something that am not sure about is whether I should be calling 
> the "snd_ctl_elem_id_set_numid()" function from "ctl_arcam_av.c" "arcam_av_read_event()" either in addition or instead of 
> the calls to the "snd_ctl_elem_id_set_name()" function?

Better to put both.  The find_elem() should fill the id fields as much as
possible in return.


Takashi

clarification on mmap

[Harsha, Priya]

Hi,

I have a question on mmap. If I give my .info to be _MMAP and _MMAP_VALID. Will ALSA framework internally take care of mmap-ing the kernel buffer that has been pre-allocated in the .probe call? Do I need to do anything special to mmap a kernel buffer into user space? Just accessing the runtime->dma_area would allow me to access user data right?

Thanks,
Harsha

Re: clarification on mmap

[Takashi Iwai]

At Mon, 23 Feb 2009 18:59:11 +0530,
Harsha, Priya wrote:
> 
> Hi,
> 
> I have a question on mmap. If I give my .info to be _MMAP and
> _MMAP_VALID. Will ALSA framework internally take care of mmap-ing
> the kernel buffer that has been pre-allocated in the .probe call? Do
> I need to do anything special to mmap a kernel buffer into user
> space? Just accessing the runtime->dma_area would allow me to access
> user data right? 

Yes.  The buffers allocated via preallocator are supposed to be
mmappable, so you can simply pass _MMAP* flag there.


Takashi

Re: clarification on mmap

[Harsha, Priya]

Thank you. Can I use .ack callback to know that the mmaped buffer has been filled by the user? How would I know how much the user has written into the buffer that time? Would I need to have the pointers calculated and tracked myself or is there a field in the structures that I can read and find out?

-----Original Message-----
From: Takashi Iwai [mailto:tiwai@suse.de] 
Sent: Monday, February 23, 2009 8:57 PM
To: Harsha, Priya
Cc: alsa-devel@alsa-project.org
Subject: Re: clarification on mmap

At Mon, 23 Feb 2009 18:59:11 +0530,
Harsha, Priya wrote:
> 
> Hi,
> 
> I have a question on mmap. If I give my .info to be _MMAP and
> _MMAP_VALID. Will ALSA framework internally take care of mmap-ing
> the kernel buffer that has been pre-allocated in the .probe call? Do
> I need to do anything special to mmap a kernel buffer into user
> space? Just accessing the runtime->dma_area would allow me to access
> user data right? 

Yes.  The buffers allocated via preallocator are supposed to be
mmappable, so you can simply pass _MMAP* flag there.


Takashi

Re: clarification on mmap

[Takashi Iwai]

At Mon, 23 Feb 2009 22:21:24 +0530,
Harsha, Priya wrote:
> 
> Thank you. Can I use .ack callback to know that the mmaped buffer
> has been filled by the user?

Not really.  It's just for explicit read/write modes.

> How would I know how much the user has
> written into the buffer that time?

You can check appl_ptr at any time.  This corresponds to the position
the app has filled.


Takashi

> Would I need to have the pointers
> calculated and tracked myself or is there a field in the structures
> that I can read and find out? 
> 
> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@suse.de] 
> Sent: Monday, February 23, 2009 8:57 PM
> To: Harsha, Priya
> Cc: alsa-devel@alsa-project.org
> Subject: Re: clarification on mmap
> 
> At Mon, 23 Feb 2009 18:59:11 +0530,
> Harsha, Priya wrote:
> > 
> > Hi,
> > 
> > I have a question on mmap. If I give my .info to be _MMAP and
> > _MMAP_VALID. Will ALSA framework internally take care of mmap-ing
> > the kernel buffer that has been pre-allocated in the .probe call? Do
> > I need to do anything special to mmap a kernel buffer into user
> > space? Just accessing the runtime->dma_area would allow me to access
> > user data right? 
> 
> Yes.  The buffers allocated via preallocator are supposed to be
> mmappable, so you can simply pass _MMAP* flag there.
> 
> 
> Takashi
> 

Re: clarification on mmap

[Harsha, Priya]

Thanks Takashi. Then what would be the best way to know when the mmaped buffer has been filled. So that I can take action to send it to the hardware? 

Should I use the runtime->control->appl_ptr or runtime->status->appl_ptr to get the position the app has filled?

-----Original Message-----
From: Takashi Iwai [mailto:tiwai@suse.de] 
Sent: Tuesday, February 24, 2009 12:55 AM
To: Harsha, Priya
Cc: alsa-devel@alsa-project.org
Subject: Re: clarification on mmap

At Mon, 23 Feb 2009 22:21:24 +0530,
Harsha, Priya wrote:
> 
> Thank you. Can I use .ack callback to know that the mmaped buffer
> has been filled by the user?

Not really.  It's just for explicit read/write modes.

> How would I know how much the user has
> written into the buffer that time?

You can check appl_ptr at any time.  This corresponds to the position
the app has filled.


Takashi

> Would I need to have the pointers
> calculated and tracked myself or is there a field in the structures
> that I can read and find out? 
> 
> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@suse.de] 
> Sent: Monday, February 23, 2009 8:57 PM
> To: Harsha, Priya
> Cc: alsa-devel@alsa-project.org
> Subject: Re: clarification on mmap
> 
> At Mon, 23 Feb 2009 18:59:11 +0530,
> Harsha, Priya wrote:
> > 
> > Hi,
> > 
> > I have a question on mmap. If I give my .info to be _MMAP and
> > _MMAP_VALID. Will ALSA framework internally take care of mmap-ing
> > the kernel buffer that has been pre-allocated in the .probe call? Do
> > I need to do anything special to mmap a kernel buffer into user
> > space? Just accessing the runtime->dma_area would allow me to access
> > user data right? 
> 
> Yes.  The buffers allocated via preallocator are supposed to be
> mmappable, so you can simply pass _MMAP* flag there.
> 
> 
> Takashi
> 

Re: clarification on mmap

[Harsha, Priya]

I have another question on the same. 

What are the runtime->transfer_ack_begin and transfer_ack_end used for? Will this help me understand when the runtime->dma_area are updated be it MMAPed buffer or not.

Thanks,
Harsha


-----Original Message-----
From: alsa-devel-bounces@alsa-project.org [mailto:alsa-devel-bounces@alsa-project.org] On Behalf Of Harsha, Priya
Sent: Tuesday, February 24, 2009 10:24 AM
To: Takashi Iwai
Cc: alsa-devel@alsa-project.org
Subject: Re: [alsa-devel] clarification on mmap

Thanks Takashi. Then what would be the best way to know when the mmaped buffer has been filled. So that I can take action to send it to the hardware? 

Should I use the runtime->control->appl_ptr or runtime->status->appl_ptr to get the position the app has filled?

-----Original Message-----
From: Takashi Iwai [mailto:tiwai@suse.de] 
Sent: Tuesday, February 24, 2009 12:55 AM
To: Harsha, Priya
Cc: alsa-devel@alsa-project.org
Subject: Re: clarification on mmap

At Mon, 23 Feb 2009 22:21:24 +0530,
Harsha, Priya wrote:
> 
> Thank you. Can I use .ack callback to know that the mmaped buffer
> has been filled by the user?

Not really.  It's just for explicit read/write modes.

> How would I know how much the user has
> written into the buffer that time?

You can check appl_ptr at any time.  This corresponds to the position
the app has filled.


Takashi

> Would I need to have the pointers
> calculated and tracked myself or is there a field in the structures
> that I can read and find out? 
> 
> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@suse.de] 
> Sent: Monday, February 23, 2009 8:57 PM
> To: Harsha, Priya
> Cc: alsa-devel@alsa-project.org
> Subject: Re: clarification on mmap
> 
> At Mon, 23 Feb 2009 18:59:11 +0530,
> Harsha, Priya wrote:
> > 
> > Hi,
> > 
> > I have a question on mmap. If I give my .info to be _MMAP and
> > _MMAP_VALID. Will ALSA framework internally take care of mmap-ing
> > the kernel buffer that has been pre-allocated in the .probe call? Do
> > I need to do anything special to mmap a kernel buffer into user
> > space? Just accessing the runtime->dma_area would allow me to access
> > user data right? 
> 
> Yes.  The buffers allocated via preallocator are supposed to be
> mmappable, so you can simply pass _MMAP* flag there.
> 
> 
> Takashi
> 
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: clarification on mmap

[Takashi Iwai]

At Tue, 24 Feb 2009 10:43:54 +0530,
Harsha, Priya wrote:
> 
> I have another question on the same. 
> 
> What are the runtime->transfer_ack_begin and transfer_ack_end used
> for?

I don't know, too, why these were introduced :)  It's nowhere used.
We should remove them, I think.

> Will this help me understand when the runtime->dma_area are
> updated be it MMAPed buffer or not.

No, they are callbacks called from snd_pcm_period_elapsed().
And snd_pcm_period_elapsed() is the function the driver must call to
update the buffer.


Takashi

> 
> Thanks,
> Harsha
> 
> 
> -----Original Message-----
> From: alsa-devel-bounces@alsa-project.org [mailto:alsa-devel-bounces@alsa-project.org] On Behalf Of Harsha, Priya
> Sent: Tuesday, February 24, 2009 10:24 AM
> To: Takashi Iwai
> Cc: alsa-devel@alsa-project.org
> Subject: Re: [alsa-devel] clarification on mmap
> 
> Thanks Takashi. Then what would be the best way to know when the mmaped buffer has been filled. So that I can take action to send it to the hardware? 
> 
> Should I use the runtime->control->appl_ptr or runtime->status->appl_ptr to get the position the app has filled?
> 
> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@suse.de] 
> Sent: Tuesday, February 24, 2009 12:55 AM
> To: Harsha, Priya
> Cc: alsa-devel@alsa-project.org
> Subject: Re: clarification on mmap
> 
> At Mon, 23 Feb 2009 22:21:24 +0530,
> Harsha, Priya wrote:
> > 
> > Thank you. Can I use .ack callback to know that the mmaped buffer
> > has been filled by the user?
> 
> Not really.  It's just for explicit read/write modes.
> 
> > How would I know how much the user has
> > written into the buffer that time?
> 
> You can check appl_ptr at any time.  This corresponds to the position
> the app has filled.
> 
> 
> Takashi
> 
> > Would I need to have the pointers
> > calculated and tracked myself or is there a field in the structures
> > that I can read and find out? 
> > 
> > -----Original Message-----
> > From: Takashi Iwai [mailto:tiwai@suse.de] 
> > Sent: Monday, February 23, 2009 8:57 PM
> > To: Harsha, Priya
> > Cc: alsa-devel@alsa-project.org
> > Subject: Re: clarification on mmap
> > 
> > At Mon, 23 Feb 2009 18:59:11 +0530,
> > Harsha, Priya wrote:
> > > 
> > > Hi,
> > > 
> > > I have a question on mmap. If I give my .info to be _MMAP and
> > > _MMAP_VALID. Will ALSA framework internally take care of mmap-ing
> > > the kernel buffer that has been pre-allocated in the .probe call? Do
> > > I need to do anything special to mmap a kernel buffer into user
> > > space? Just accessing the runtime->dma_area would allow me to access
> > > user data right? 
> > 
> > Yes.  The buffers allocated via preallocator are supposed to be
> > mmappable, so you can simply pass _MMAP* flag there.
> > 
> > 
> > Takashi
> > 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 

Re: clarification on mmap

[Takashi Iwai]

At Tue, 24 Feb 2009 10:24:19 +0530,
Harsha, Priya wrote:
> 
> Thanks Takashi. Then what would be the best way to know when the
> mmaped buffer has been filled. So that I can take action to send it
> to the hardware? 

In the current ALSA design, mmap transfer is completely asynchronous.
The driver doesn't take care when app_ptr is updated.  It's checked
only when the hw_ptr is updated in snd_pcm_period_elapsed().  So, in
general, what the card driver needs is to provide the ISR calling
snd_pcm_period_elapsed() appropriately and, if possible, to provide
the accurate PCM pointer callback to give the updated hw_ptr.

In mmap mode, other any transfer to the hardware is supposed to be
done by the hardware (DMA) more or less automatically.  If you need to
do it by yourself, mmap isn't always the right answer.

> Should I use the runtime->control->appl_ptr or
> runtime->status->appl_ptr to get the position the app has filled? 

appl_ptr exists only in runtime->control.


HTH,

Takashi

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@suse.de] 
> Sent: Tuesday, February 24, 2009 12:55 AM
> To: Harsha, Priya
> Cc: alsa-devel@alsa-project.org
> Subject: Re: clarification on mmap
> 
> At Mon, 23 Feb 2009 22:21:24 +0530,
> Harsha, Priya wrote:
> > 
> > Thank you. Can I use .ack callback to know that the mmaped buffer
> > has been filled by the user?
> 
> Not really.  It's just for explicit read/write modes.
> 
> > How would I know how much the user has
> > written into the buffer that time?
> 
> You can check appl_ptr at any time.  This corresponds to the position
> the app has filled.
> 
> 
> Takashi
> 
> > Would I need to have the pointers
> > calculated and tracked myself or is there a field in the structures
> > that I can read and find out? 
> > 
> > -----Original Message-----
> > From: Takashi Iwai [mailto:tiwai@suse.de] 
> > Sent: Monday, February 23, 2009 8:57 PM
> > To: Harsha, Priya
> > Cc: alsa-devel@alsa-project.org
> > Subject: Re: clarification on mmap
> > 
> > At Mon, 23 Feb 2009 18:59:11 +0530,
> > Harsha, Priya wrote:
> > > 
> > > Hi,
> > > 
> > > I have a question on mmap. If I give my .info to be _MMAP and
> > > _MMAP_VALID. Will ALSA framework internally take care of mmap-ing
> > > the kernel buffer that has been pre-allocated in the .probe call? Do
> > > I need to do anything special to mmap a kernel buffer into user
> > > space? Just accessing the runtime->dma_area would allow me to access
> > > user data right? 
> > 
> > Yes.  The buffers allocated via preallocator are supposed to be
> > mmappable, so you can simply pass _MMAP* flag there.
> > 
> > 
> > Takashi
> > 
> 

Re: clarification on mmap

[Harsha, Priya]

The exact issue I am facing is - if the data is mmaped or not I would want to know that the dma_area is filled and how much is filled so that I can setup the dma to transfer it to the hardware.

Can you suggest a way to do this?

Will the following help?

1. If the data is not mmaped, can I setup the transfer in .ack call to transfer the data copied from dma_area to hardware?
2. If the data is mmaped; In the .pointer call back, I get the exact hw pointer of how much has been played out. Here can I setup another transfer from dma_area?
3. How can I know internally in the driver if the application has mmaped the buffer or using the method of sending user buffers?

Thanks,
Harsha


-----Original Message-----
From: Takashi Iwai [mailto:tiwai@suse.de] 
Sent: Tuesday, February 24, 2009 12:16 PM
To: Harsha, Priya
Cc: alsa-devel@alsa-project.org
Subject: Re: clarification on mmap

At Tue, 24 Feb 2009 10:24:19 +0530,
Harsha, Priya wrote:
> 
> Thanks Takashi. Then what would be the best way to know when the
> mmaped buffer has been filled. So that I can take action to send it
> to the hardware? 

In the current ALSA design, mmap transfer is completely asynchronous.
The driver doesn't take care when app_ptr is updated.  It's checked
only when the hw_ptr is updated in snd_pcm_period_elapsed().  So, in
general, what the card driver needs is to provide the ISR calling
snd_pcm_period_elapsed() appropriately and, if possible, to provide
the accurate PCM pointer callback to give the updated hw_ptr.

In mmap mode, other any transfer to the hardware is supposed to be
done by the hardware (DMA) more or less automatically.  If you need to
do it by yourself, mmap isn't always the right answer.

> Should I use the runtime->control->appl_ptr or
> runtime->status->appl_ptr to get the position the app has filled? 

appl_ptr exists only in runtime->control.


HTH,

Takashi

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@suse.de] 
> Sent: Tuesday, February 24, 2009 12:55 AM
> To: Harsha, Priya
> Cc: alsa-devel@alsa-project.org
> Subject: Re: clarification on mmap
> 
> At Mon, 23 Feb 2009 22:21:24 +0530,
> Harsha, Priya wrote:
> > 
> > Thank you. Can I use .ack callback to know that the mmaped buffer
> > has been filled by the user?
> 
> Not really.  It's just for explicit read/write modes.
> 
> > How would I know how much the user has
> > written into the buffer that time?
> 
> You can check appl_ptr at any time.  This corresponds to the position
> the app has filled.
> 
> 
> Takashi
> 
> > Would I need to have the pointers
> > calculated and tracked myself or is there a field in the structures
> > that I can read and find out? 
> > 
> > -----Original Message-----
> > From: Takashi Iwai [mailto:tiwai@suse.de] 
> > Sent: Monday, February 23, 2009 8:57 PM
> > To: Harsha, Priya
> > Cc: alsa-devel@alsa-project.org
> > Subject: Re: clarification on mmap
> > 
> > At Mon, 23 Feb 2009 18:59:11 +0530,
> > Harsha, Priya wrote:
> > > 
> > > Hi,
> > > 
> > > I have a question on mmap. If I give my .info to be _MMAP and
> > > _MMAP_VALID. Will ALSA framework internally take care of mmap-ing
> > > the kernel buffer that has been pre-allocated in the .probe call? Do
> > > I need to do anything special to mmap a kernel buffer into user
> > > space? Just accessing the runtime->dma_area would allow me to access
> > > user data right? 
> > 
> > Yes.  The buffers allocated via preallocator are supposed to be
> > mmappable, so you can simply pass _MMAP* flag there.
> > 
> > 
> > Takashi
> > 
> 

Re: clarification on mmap

[Takashi Iwai]

At Tue, 24 Feb 2009 13:15:53 +0530,
Harsha, Priya wrote:
> 
> The exact issue I am facing is - if the data is mmaped or not I
> would want to know that the dma_area is filled and how much is
> filled so that I can setup the dma to transfer it to the hardware.
> 
> Can you suggest a way to do this?
> 
> Will the following help?
> 
> 1. If the data is not mmaped, can I setup the transfer in .ack call
> to transfer the data copied from dma_area to hardware? 
> 2. If the data is mmaped; In the .pointer call back, I get the exact
> hw pointer of how much has been played out. Here can I setup another
> transfer from dma_area? 
> 3. How can I know internally in the driver if the application has
> mmaped the buffer or using the method of sending user buffers? 

Well, before going further into your questions, let's make the
hardware design ALSA PCM framework assumes.

First off, the hardware is supposed to transfer the data from the
given buffer (RAM) to the hardware in the background (e.g. DMA).
Usually, the driver sets up the transfer in prepare callback, give a
go at trigger callback, then the hardware will keep feeding the data
from the given ring-buffer to the hardware continuously without any
action.

The driver sets up the "period".  It's the time the driver is woken
up, and usually triggered by a hardware IRQ.  The ISR will then call
snd_pcm_period_elapsed() so that PCM core will work the rest of the
job (updating hwptr, waking up the sleepers, etc).  Meanwhile, PCM
core will ask the driver to return the current transfer position in
the ring buffer via pointer callback.  The driver is responsible for
that.

That's all.  In this implementation case, there is no difference
between the RW and the mmap transfers.  The difference is handled in
the PCM core.

Note that there is no need to refer to appl_ptr in the driver side
because the DMA transfer is done continuously in the ring buffer.

If your hardware behaves differently, there need some workarounds to
adapt that.  For example, usb-audio has an intermediate buffer to
handle URBs continuously.

If you need to feed the sample data to the hardware manually, e.g. via
loop, the above model doesn't work because the (mmapped) data can be
written at any moment on the ring buffer.  You can fake it, but it's
not that perfect.

Now, please make clear how your hardware works, and what is required
in addition to that...


Takashi

> 
> Thanks,
> Harsha
> 
> 
> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@suse.de] 
> Sent: Tuesday, February 24, 2009 12:16 PM
> To: Harsha, Priya
> Cc: alsa-devel@alsa-project.org
> Subject: Re: clarification on mmap
> 
> At Tue, 24 Feb 2009 10:24:19 +0530,
> Harsha, Priya wrote:
> > 
> > Thanks Takashi. Then what would be the best way to know when the
> > mmaped buffer has been filled. So that I can take action to send it
> > to the hardware? 
> 
> In the current ALSA design, mmap transfer is completely asynchronous.
> The driver doesn't take care when app_ptr is updated.  It's checked
> only when the hw_ptr is updated in snd_pcm_period_elapsed().  So, in
> general, what the card driver needs is to provide the ISR calling
> snd_pcm_period_elapsed() appropriately and, if possible, to provide
> the accurate PCM pointer callback to give the updated hw_ptr.
> 
> In mmap mode, other any transfer to the hardware is supposed to be
> done by the hardware (DMA) more or less automatically.  If you need to
> do it by yourself, mmap isn't always the right answer.
> 
> > Should I use the runtime->control->appl_ptr or
> > runtime->status->appl_ptr to get the position the app has filled? 
> 
> appl_ptr exists only in runtime->control.
> 
> 
> HTH,
> 
> Takashi
> 
> > -----Original Message-----
> > From: Takashi Iwai [mailto:tiwai@suse.de] 
> > Sent: Tuesday, February 24, 2009 12:55 AM
> > To: Harsha, Priya
> > Cc: alsa-devel@alsa-project.org
> > Subject: Re: clarification on mmap
> > 
> > At Mon, 23 Feb 2009 22:21:24 +0530,
> > Harsha, Priya wrote:
> > > 
> > > Thank you. Can I use .ack callback to know that the mmaped buffer
> > > has been filled by the user?
> > 
> > Not really.  It's just for explicit read/write modes.
> > 
> > > How would I know how much the user has
> > > written into the buffer that time?
> > 
> > You can check appl_ptr at any time.  This corresponds to the position
> > the app has filled.
> > 
> > 
> > Takashi
> > 
> > > Would I need to have the pointers
> > > calculated and tracked myself or is there a field in the structures
> > > that I can read and find out? 
> > > 
> > > -----Original Message-----
> > > From: Takashi Iwai [mailto:tiwai@suse.de] 
> > > Sent: Monday, February 23, 2009 8:57 PM
> > > To: Harsha, Priya
> > > Cc: alsa-devel@alsa-project.org
> > > Subject: Re: clarification on mmap
> > > 
> > > At Mon, 23 Feb 2009 18:59:11 +0530,
> > > Harsha, Priya wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > I have a question on mmap. If I give my .info to be _MMAP and
> > > > _MMAP_VALID. Will ALSA framework internally take care of mmap-ing
> > > > the kernel buffer that has been pre-allocated in the .probe call? Do
> > > > I need to do anything special to mmap a kernel buffer into user
> > > > space? Just accessing the runtime->dma_area would allow me to access
> > > > user data right? 
> > > 
> > > Yes.  The buffers allocated via preallocator are supposed to be
> > > mmappable, so you can simply pass _MMAP* flag there.
> > > 
> > > 
> > > Takashi
> > > 
> > 
>