Re: mapping externally allocated Scatter Gather DMA buffers
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
On Fri, 12 Nov 2010, Manu Abraham wrote:
On Thu, Nov 11, 2010 at 6:04 PM, Manu Abraham <abraham.manu@xxxxxxxxx> wrote:On Thu, Nov 11, 2010 at 4:00 PM, Jaroslav Kysela <perex@xxxxxxxx> wrote:On Thu, 11 Nov 2010, Manu Abraham wrote:On Wed, Nov 10, 2010 at 11:35 PM, Jaroslav Kysela <perex@xxxxxxxx> 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@xxxxxxxx> Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
_______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel