On Tue, Jun 7, 2011 at 11:59 PM, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: >> The discussion did take off a few months ago, but we didn't reach anywhere. >> Being able to queue request from the 'done' callback, the need of >> circular buffer >> API (possibly a free-running one too) and callbacks in irq-context, as >> they happen, >> were a few requirements for having fast peripherals with shallow fifo >> work without underruns. > > I can see why you have these concerns; the problem is the slave DMA > engine API was never properly documented. > > 1. The slave API does permit the done callback to submit new requests > Â already (and any DMA engine driver which doesn't allow that is broken.) > > Note that slave APIs _should_ permit several requests to be queued up > and as each finish, the next one should be started. ÂIn other words, > once DMA has started it should continue until there is no more work for > the DMA engine to perform. > > 2. Circular buffer support has been added - see device_prep_dma_cyclic(). > > However, 2 is not really a requirement for audio - you can queue several > single slave transfers (one per period) initially, and then you get > callbacks as each transfer completes. ÂIn the callback, you can submit > an additional buffer, and continue doing so causing DMA to never end. > > I believe that this is a saner approach than the circular buffer support, > and its what I tried to put together for the AMBA PL041 AACI DMA (but > unfortunately, ARMs platforms are totally broken when it comes to DMA.) > > This also removes the need for the callback to be in IRQ context. > > So I don't see that anything you've mentioned is a problem with the API > as it stands today - there may be issues with the way the DMA engine > driver has been implemented which cause it not to conform to what I've > said above, but those are driver bugs and not a fault of the API. Yes, after reading Vinod's mail, I did see that CYCLIC option has been added. Though I am still not sure how effective would that be for fast peripherals(please have a look at my reply to Mark's post), when doing callbacks from tasklets scheduled from irq-handlers is the norm with dma drivers of generic api. Playing regular audio is no problem, but playing pro quality over SPDIF with active multimedia h/w, sometimes is for some devices. Besides, people might have different work priorities atm. I don't think anybody believes we can do without common APIs. Btw, Samsung DMA API doesn't support the 'free-running' circular buffer either. But that was my planned TODO while I was there and I think someone is working on it(?) IMHO Samsung SoC team (not his majesty Mr Kyungmin Park) are justified if they are not so eager right now. Since I no more would have to spend sleepless nights over SPDIF underruns, I can side with what Kukjin Kim(Samsung maintainer) decides, who has to live with the results. Thanks, Jassi -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |