[alsa-devel] mapping externally allocated Scatter Gather DMA buffers

[Jaroslav Kysela]

On Fri, 12 Nov 2010, Manu Abraham wrote:

> On Thu, Nov 11, 2010 at 6:04 PM, Manu Abraham <abraham.manu at gmail.com> wrote:
>> On Thu, Nov 11, 2010 at 4:00 PM, Jaroslav Kysela <perex at perex.cz> wrote:
>>> On Thu, 11 Nov 2010, Manu Abraham wrote:
>>>
>>>> On Wed, Nov 10, 2010 at 11:35 PM, Jaroslav Kysela <perex at perex.cz> wrote:
>>
>>>>
>>>> I adapted the whole thing to make the buffersize divided amongst the
>>>> XS2D_BUFFERS (8):
>>>
>>> Probably yes.
>>>
>>>> I hope the mapping of the buffers is okay ? It looks thus, now ..
>>>
>>> From information you sent me about hw privately, I think that the
>>> period_bytes must be 4096 or multiple of this value with minumum count of
>>> periods 8 (or multiple of 8). Otherwise you get a non-continuous memory area
>>> (the hw uses only portion of system memory page, thus there'll be gaps). The
>>> problem is that we have MMAP_COMPLEX mode, but no application can handle
>>> (does not implement) this mmap mode and I'm not sure, if we can even
>>> describe the DMA buffer size layout for this case for your specific hw.
>>>
>>> I would use:
>>>
>>>        snd_pcm_hw_constraint_step(runtime, 0,
>>> SNDRV_PCM_HW_PARAM_PERIOD_BYTES,
>>>                                  4096);
>>>
>>>
>>>        snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_PERIODS,
>>>                                   8);
>>>
>>> And define periods_min = 8 (max to multiple 8 - choose your max limit) and
>>> period_bytes_min to 4096 (max to multiple 4096 - choose your max limit).
>>>
>>> Note that -EIO means that your driver does not called
>>> snd_pcm_period_elapsed() and/or the pointer callback returns wrong position
>>> to the audio ring buffer.
>>
>>
>>
>> Ok, modified it, also added in code to acquire the stream, It's a bit
>> more complete now.
>> The crazy part that I do see now, is that I see an inconsistent lock
>> state with the hda_intel
>> driver which is the soundcard on my system. But I don't understand why
>> the locking on it
>> has to become inconsistent on loading this driver.
>
>
> Ok, I found the reason: I was passing a single page for the
> page_table, which I guess corrupted the whole stack !!
>
> Eventually, I fixed the same. but ran into another issue ? Should
> trigger not sleep or something that way ?
> Currently, I see the issue as follows in the log, but if the
> ops->run() callback is commented out I don't get that
> weird message/error about lock states.
>
> Now, ops->run(), ie xs2dtl_run() is called with other other streams,
> such as an MPEG stream, where it doesn't
> show any issues.
>
> Any idea, why uncommenting ops->run() produces that message ? Should
> trigger not sleep ? Confused ...

Trigger must be fast without any sleeping. Only fast spinlocks are 
allowed. If you need sleep, just activate a tasklet and do the start job 
in the tasklet or a thread.

 						Jaroslav

-----
Jaroslav Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.