I think Barry forgot to mention that this DAC is connect to the CPU via a 3 PIN serial port with SYNC clock enabled. This serial port controller has DMA master capability and output data at a given clock. The ring buffer slots and size is better to be configurable and its API should be able to trigger output start/stop to IIO driver based on data left in the ring. Sonic >-----Original Message----- >From: uclinux-dist-devel-bounces@xxxxxxxxxxxxxxxxxxxx >[mailto:uclinux-dist-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On >Behalf Of Barry Song >Sent: Wednesday, March 03, 2010 11:26 AM >To: J.I. Cameron >Cc: linux-iio@xxxxxxxxxxxxxxx; >uclinux-dist-devel@xxxxxxxxxxxxxxxxxxxx; manuel.stahl@xxxxxxxxxxxxxxxxx >Subject: Re: [Uclinux-dist-devel] IIO ring buffer > >DACs like >AD5624R/5644R/5664R(http://www.analog.com/en/digital-to-analog- >converters/da-converters/ad5624r/products/product.html) >have no clock input and internal buffer. Some users maybe use >it to get discrete analog signals, that means once one data is >written to AD5624R, one new analog signal is output, then we >don't need ring buffer. But some other users maybe want the >AD5624R to create continuous signals with a fixed frequency, >then we need use ring buffer with linked DMA to input data to >AD5624R with a constant rate. >This case is same with audio play. >To implement that, we need >1. Split ring buffer to some little fragments, one fragment is >a DMA block. >2. Ring buffer core layer must handle the play pointer and >user writing pointer, stop the DMA automatically when user >data under-run flows( valid data is less than one fragment in >ring buffer) 3. The DMA interrupt handler in the bottom driver >should update the play pointer by a ring buffer core API to >notify the play status. >4. The DMA should support linked mode, once one DMA block is >finished, another DMA fragment will be enabled by hardware >automatically except that it is disabled due to underflow. >Thanks >Barry > >On Tue, Mar 2, 2010 at 6:45 PM, J.I. Cameron <jic23@xxxxxxxxx> wrote: >> Hi Barry, >> >>> I know you are changing iio ring buffer. Here a problem to discuss >>> with you, there are maybe this kind of use cases: the DACs have no >>> internal clock and buffer, so we need an external bus with >continuous >>> DMA to "play" data flow with constant speed. It is very >similar with >>> alsa driver to play audio by I2S or AC97. ALSA framework is easy to >>> implement this kind of drivers. But our DACs are not audio cards. >>> Then in the iio ring buffer core, it seems we also need APIs like >>> trigger(), pointer(), snd_pcm_period_elapsed()... to get a common >>> framework. >> >> I have to admit I'm in general a little unclear on how one even goes >> about getting dma to occur at a constant speed. I'm afraid >I haven't >> had much time to work on improving the ring buffer (though I >will try >> and get a patch out for one particular bug sometime today - >if you get >> issues in the init function with spin locks). Hence, I >suggest that >> you propose any changes you would like to see in the core, >if possible >> with some code along side relevant data sheets so those of us not so >> familiar with this area can better understand how this would work. >> >> My short term plans for the buffering is to allow use of the new >> implementation of kfifo as it allows dma transfers to occur directly >> into the buffer. Obviously this will involve adding a few >new bits to the api. >> >> That internal api is certainly far from locked in stone and >as long as >> we can mend any driver broken by changes, feel free to propose any >> changes you like! >> >>> Of course, we can let users to handle blocking in write() callback >>> like OSS, but alsa-like APIs should be better. So what's >your opinion >>> for that? >>> If I begin to work on this, I am not sure how much is >needed to do to >>> merge into your new iio ring buffer codes. So if you have some new >>> codes for reference, it should be better. >> >> Sorry, no new code for now. All changes in my tree are driver based >> rather than core (and right now to messy to post publicly) >> >> Looking forward to seeing what you propose in further detail. >> >> Jonathan >> >_______________________________________________ >Uclinux-dist-devel mailing list >Uclinux-dist-devel@xxxxxxxxxxxxxxxxxxxx >https://blackfin.uclinux.org/mailman/listinfo/uclinux-dist-devel > -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
