[alsa-devel] integration into ASoC

[Maxime Ripard]

On Mon, Mar 10, 2014 at 11:15:29AM +0100, Lars-Peter Clausen wrote:
> >>>This IP is made of a few registers to control the sampling rate, if
> >>>we're using mono/stereo, plus two fifos, one for playback, one for
> >>>capture, that can be seed with data. The data are then taken, go
> >>>through a DAC, and the outer interface of the IP are directly analog
> >>>signals (so the DAC/ADC are directly in the SoC, and the only
> >>>interface we have is plain registers).
> >>>
> >>> From what I understood from ASoC, you have mostly three components,
> >>>the DAI, the codec and the platform that plumbers the two first
> >>>together. Here, my understanding is that it's pretty much the whole
> >>>three in a single IP.
> >>
> >>The platform component usually takes care of transferring data from
> >>memory to your IP. It sounds as if this is still separate on your
> >>platform. Quite possibly you can use the generic dmaengine PCM
> >>driver.
> >
> >You really have two intertwined sets of registers, one for the FIFO
> >themselves (and you will obviously use DMA for that, I'll keep in mind
> >the dmaengine PCM driver), and the control registers, so you can't
> >really split it into two separate drivers (at least, not easily).
> 
> You'd configure the FIFOs from the CPU component driver, but the
> part that takes care of moving the audio data around is a separate
> component.

Ok.

> >
> >>Right now ASoC expects you to specify a DAI link for a PCM
> >>device. The DAI link connects the DAIs of two components typically
> >>the SoC side and a external CODEC. In your case you do not have the
> >>external CODEC. You can solve this by using a dummy CODEC or
> >>splitting things up and register both the CODEC and the CPU DAI from
> >>the same driver.
> >
> >That would probably be the best solution, yes.
> >
> >>But I'm currently working on a patchset that will eventually allow
> >>these kind of devices to be supported more naturally. It will allow
> >>to register them as one component that won't need the CODEC
> >>component to work.
> >
> >Great! Do you have a branch with that work somewhere?
> 
> Not yet. But I hope to get there in the next weeks.

Could you put me in Cc whenever you post them for feedback/testing?


> >>>Should such a hardware block be handled into ASoC, and if yes, how?
> >>>If not, which other framework should be used?
> >>
> >>It makes sense to use ASoC if there are components where the driver
> >>can be shared e.g. the DMA in your case. Otherwise you can also use
> >>plain old ALSA.
> >
> >The DMA controller this IP will use is a system-wide DMA master, so
> >I don't think this driver will provide something to other drivers.
> 
> That's what I meant. The DMA controller is not integrated into the
> sound core, so you'll have a dmaengine driver for the DMA controller
> and the part that can be shared with other drivers is the code that
> handles setting up the DMA transfers etc.

Ok. Thanks!

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20140310/314a897b/attachment.sig>