Re: adding an external dsp under soc-dsp framework

Re: adding an external dsp under soc-dsp framework

[Mark Brown]

On Mon, Aug 06, 2012 at 06:11:33PM +0300, Ziv Haziz wrote:

> ok thanks. This means that I need to introduce two codecs and make a dai
> link between them?
>  It doesn't really fits the dai structure - how do you suggest to do it?

No, if they're part of the same physical chip then they should be
handled internally to the device.

> ok - finger crossed you will publish an agreed interface soon -
> currently I saw in codeaurora kernel an implementation of exposing mixer
> controls, so currently this is the only option yes?

That's not upstream, standard Linux has no support for Slimbus at all.

Re: adding an external dsp under soc-dsp framework

[ziv haziz]

Mark Brown <broonie <at> opensource.wolfsonmicro.com> writes:

> 
> On Mon, Aug 06, 2012 at 06:11:33PM +0300, Ziv Haziz wrote:
> 
> > ok thanks. This means that I need to introduce two codecs and make a dai
> > link between them?
> >  It doesn't really fits the dai structure - how do you suggest to do it?
> 
> No, if they're part of the same physical chip then they should be
> handled internally to the device.
it is a seperated chipset, only digital interfaces which should come between the 
cpu and the codec.

Re: adding an external dsp under soc-dsp framework

[Mark Brown]

On Mon, Aug 06, 2012 at 06:43:02PM +0000, ziv haziz wrote:
> Mark Brown <broonie <at> opensource.wolfsonmicro.com> writes:
> > On Mon, Aug 06, 2012 at 06:11:33PM +0300, Ziv Haziz wrote:

Don't drop people from CCs.

> > > ok thanks. This means that I need to introduce two codecs and make a dai
> > > link between them?
> > >  It doesn't really fits the dai structure - how do you suggest to do it?

> > No, if they're part of the same physical chip then they should be
> > handled internally to the device.

> it is a seperated chipset, only digital interfaces which should come between the 
> cpu and the codec.

In that case what you're saying above with a DAI link is exactly what
you're supposed to do, I don't see any structural problem here?

Re: adding an external dsp under soc-dsp framework

[Mark Brown]

On Wed, Aug 08, 2012 at 11:21:20AM +0300, Ziv Haziz wrote:

> >I n that case what you're saying above with a DAI link is exactly what
> > you're supposed to do, I don't see any structural problem here?

> Creating two dai links will create two separated devices which must be
> open for setting configurations, but the dsp-codec dai cannot be started
> (or I will get an  error). This means changing the codec driver to
> enable everything not from trigger callback.

> Is it possible to have a dai link without a platform for data transfer?
> I saw in the plumbers agenda you are going to talk on codec-codec
> interface - do you have any preliminary suggestion?

This is already supported in mainline, look at littlemill for one
example user.

Alternatively for older kernels you can easily support this from
userspace by just not starting the DMA, this has been deployed for some
considerable time on many systems (OpenMoko is one long standing
mainline example).

Re: adding an external dsp under soc-dsp framework

[Mark Brown]

On Wed, Aug 08, 2012 at 10:49:19PM +0300, Ziv Haziz wrote:

> Looking at the littlemill driver on kernel 3.4.7 the device name
> "Baseband" and his dai link doesn't contain platform device can be
> triggered without side effects?

Yes, this is the most common case for DAI links that don't involve a CPU
in modern smartphones.

adding an external dsp under soc-dsp framework

[ziv haziz]

i plan on adding an external dsp which has slimbus interface under soc-dsp 
framwork.
currently i would like to make the following type of connection:
CPU->DSP->Codec and as the dsp is an external one
(physically seperated from both the CPU and the Codec)
i have a difficulty defining how to represent it:
do i need to make two entities of the dsp:
- one for the BE connection and one for the FE connection 
and add some internal routing using mixer controls? this will 
create two devices in the user space which the user application should open? 
- or is there a way to make one device which is composed of all three blocks?

last small question: as slimbus ports id should be passed how do you suggest a 
device should share his slimbus port id?

Re: adding an external dsp under soc-dsp framework

[Mark Brown]

On Mon, Aug 06, 2012 at 12:53:40PM +0000, ziv haziz wrote:

Always CC maintainers on patches.

> i plan on adding an external dsp which has slimbus interface under soc-dsp 
> framwork.

You shouldn't be doing this.  The soc-pcm code is *purely* about
managing the interdependencies between the data DMAed from memory and
the external interfaces on a SoC, if you're an off-SoC device then you
should be providing a CODEC driver.  This is why you're having trouble
working out how to fit your driver into the frameworks - they're not
designed to do what you're trying to do.

> last small question: as slimbus ports id should be passed how do you suggest a 
> device should share his slimbus port id?

Well, the bigger blocker here is that we don't have any Slimbus support
in the kernel at the minute.  I'm hoping to help push that along at the
KS/LPC/LinuxCon conferences at the end of this month.