On 03/08/10 03:41, Barry Song wrote: > On Thu, Mar 4, 2010 at 8:33 PM, Jonathan Cameron <jic23@xxxxxxxxx> wrote: >> >> Hi Barry, >> >> Sorry for the slow reply, been busy with the whole ALS thing >> (see lkml if you are interested) and chasing down some rtc issues. >> >> On 03/03/10 03:26, Barry Song wrote: >>> 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. >> Makes sense, I guess for these we provide a sysfs type interface. >>> 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. >> Makes sense, though we probably need to be a little careful >> as not spi implementations are going to do this via dma. >>> 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) >> Probably a fifo rather than a ring buffer, but it doesn't change your >> point! At the moment I'm not seeing much shared functionality with the >> rest of IIO. Perhaps we treat DAC elements in a similar way to triggers? >> That is a device may register them without registering anything else. >> Will keep matters nice and slim if we have devices such as this one that >> don't have any inputs. The only disadvantage I can see is when we have >> interesting interactions between the dac's and inputs (such as a feedback >> channel). > It should be a hardware ring buffer because we must have allocated it > by consistent way ahead. The buffer has been ready and DMA link has > been built when we begin any transfer. Sorry, i don't understand > clearly about treating DACs as trigggers you said, here i think we > only need interrupts/callbacks to update playback pointers. I simply meant that one can treat them as effectively independant from the core iio_device structures seeing as there is almost no shared functionality. Thus a driver can register any of: iio_device (we may need to rename!), iio_trigger and iio_dac. In a similar way to the triggers a dac might be a child of an iio_device, but also might exist on it's own if none of the other functionality is needed (i.e. it is just a dac). >> >>> 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. >> The complexity I can see here is interacting with the underlying bus. >> It may be that we need to propose some changes to the spi infrastructure, >> it order to get the hooks you are referring to. I'm really not keen in >> reinventing the wheel and providing bus interfaces within IIO. >> If we have new buses or new requirements for existing bus subsystems, >> we should propose them separately. They will almost certainly be of use >> elsewhere anyway! > It maybe makes sense too to change current spi drivers. spi async mode > can help if we change blackfin sport spi > driver(http://blackfin.uclinux.org/gf/project/linux-kernel/scmsvn/?action=browse&path=%2Ftrunk%2Fdrivers%2Fspi%2Fbfin_sport_spi.c&view=markup&revision=8051) > to use linked DMA. DAC drivers only call spi_async and use the spi > completion callback to update playback pointer. And sport spi driver > manages the DMA link and keep the spi acccess running if there are > still spi messages. That sounds sensible (though I haven't looked at the specifics). If possible make sure you maintain support for devices not capable of using linked dma though. I would suggest putting together an example and proposing some suitable interfaces to be added to the spi core (we can tackle other buses as they come up!) > The performance should be better if current spi can be improved to > support block mode but not manage spi transfer by single spi message. > The same problem will happen to i2c bus if there are similar DACs using i2c bus. >> >> I've cc'd David and Grant to see if they have any initial comments on >> this or are aware of people doing similar stuff. (it's all a bit >> vague at the moment for a post to the spi mailing list). Maybe >> it is possible already to do this? Certainly looks like this is the >> first area to investigate to me. >> >> Thanks, >> >> Jonathan >> >> >>> >>> 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 >>>> >> -- 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
