integration into ASoC

integration into ASoC

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 958 bytes --]

Hi Liam, Mark,

I have a sound IP that is part of an SoC that I'm willing to write a
driver for.

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. 

Should such a hardware block be handled into ASoC, and if yes, how?
If not, which other framework should be used?

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: integration into ASoC

[Lars-Peter Clausen]

On 03/07/2014 05:53 PM, Maxime Ripard wrote:
> Hi Liam, Mark,
>
> I have a sound IP that is part of an SoC that I'm willing to write a
> driver for.

Which SoC is this?

>
> 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. 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.

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.

>
> 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.

- Lars

Re: integration into ASoC

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 812 bytes --]

On Fri, Mar 07, 2014 at 06:12:33PM +0100, Lars-Peter Clausen wrote:
> On 03/07/2014 05:53 PM, Maxime Ripard wrote:

> >I have a sound IP that is part of an SoC that I'm willing to write a
> >driver for.

> Which SoC is this?

I'm going to guess it's the Allwinner stuff.

> >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.

Right, though one thing to consider here is if the device is typically
used with external components - some of these systems provide a line
output which is then connected to external speaker and headphone
amplifiers which can be things that have ASoC drivers.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: integration into ASoC

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 1092 bytes --]

On Sun, Mar 09, 2014 at 07:48:53AM +0000, Mark Brown wrote:
> On Fri, Mar 07, 2014 at 06:12:33PM +0100, Lars-Peter Clausen wrote:
> > On 03/07/2014 05:53 PM, Maxime Ripard wrote:
> 
> > >I have a sound IP that is part of an SoC that I'm willing to write a
> > >driver for.
> 
> > Which SoC is this?
> 
> I'm going to guess it's the Allwinner stuff.

Yep.

> > >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.
> 
> Right, though one thing to consider here is if the device is typically
> used with external components - some of these systems provide a line
> output which is then connected to external speaker and headphone
> amplifiers which can be things that have ASoC drivers.

Ah, yes. Good to know.

Thanks!

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: integration into ASoC

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 3080 bytes --]

Hi Lars,

On Fri, Mar 07, 2014 at 06:12:33PM +0100, Lars-Peter Clausen wrote:
> On 03/07/2014 05:53 PM, Maxime Ripard wrote:
> >Hi Liam, Mark,
> >
> >I have a sound IP that is part of an SoC that I'm willing to write a
> >driver for.
> 
> Which SoC is this?

Allwinner A31.

Unfortunately, the datasheet for this SoC is not public, but most of
the other Allwinner SoCs have an IP that behaves pretty much in the
same way.

You can find a datasheet for the A20 here:
http://dl.linux-sunxi.org/A20/A20%20User%20Manual%202013-03-22.pdf,
starting page 172.

The A31 has a slightly different IP, but from an architectural
standpoint, it's pretty much the same thing.

> >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).

> 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?

> >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.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: integration into ASoC

[Lars-Peter Clausen]

On 03/10/2014 10:50 AM, Maxime Ripard wrote:
> Hi Lars,
>
> On Fri, Mar 07, 2014 at 06:12:33PM +0100, Lars-Peter Clausen wrote:
>> On 03/07/2014 05:53 PM, Maxime Ripard wrote:
>>> Hi Liam, Mark,
>>>
>>> I have a sound IP that is part of an SoC that I'm willing to write a
>>> driver for.
>>
>> Which SoC is this?
>
> Allwinner A31.
>
> Unfortunately, the datasheet for this SoC is not public, but most of
> the other Allwinner SoCs have an IP that behaves pretty much in the
> same way.
>
> You can find a datasheet for the A20 here:
> http://dl.linux-sunxi.org/A20/A20%20User%20Manual%202013-03-22.pdf,
> starting page 172.
>
> The A31 has a slightly different IP, but from an architectural
> standpoint, it's pretty much the same thing.
>
>>> 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.

>
>> 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.

>
>>> 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.

- Lars

Re: integration into ASoC

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 3123 bytes --]

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

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: integration into ASoC

[Lars-Peter Clausen]

On 03/10/2014 05:43 PM, Maxime Ripard wrote:
>>>
>>>> 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?

Sure. I just had a quick peek at the datasheet and I think you should be 
able to get away with implementing this as a CODEC driver for now and use 
the dummy-dai for the CPU side in you DAI link.

- Lars