[Sound-open-firmware] Design document - topology, scheduling et all

[Daniel Baluta]

On Mon, Feb 11, 2019 at 11:37 PM Daniel Baluta <daniel.baluta at gmail.com> wrote:
>
> On Mon, Feb 11, 2019 at 11:30 PM Pierre-Louis Bossart
> <pierre-louis.bossart at linux.intel.com> wrote:
> >
> >
> > On 2/11/19 2:58 PM, Daniel Baluta wrote:
> > > Hi all,
> > >
> > > First of all I'm now in the phase where I only need to implement the DMA driver
> > > for i.MX and create the topology file.
> > >
> > > Few questions:
> > >
> > > 1) Is there any simple scenario (topology file) where I could test
> > > that scheduling,
> > > ipc, pipelines, etc works without the DMA?
> >
> > DMA is a loaded term for intel folks, depending on the skews we use
> > either the same DMA controller for host memory <-> internal DSP memory
> > and internal memory <-> audio peripherals.
> >
> > Are you missing the first, the second or both? the information would
> > help provide guidance on what topologies you can try to use.

One question about buffer transfer between host <-> DSP. Please
correct me if I'm wrong.

It seems that buffer transfer between host <-> DSP is handled by the
host component.
Also, it looks that this is *always* done via DMA, right? (there is a
normal dma and a GW DMA,
not sure what's the difference).

On i.MX the memory between host and DSP is shared so there is no need
for such copy
(maybe perhaps some cache sync).

I'm now thinking how to handle this.

Is host component always connected to a buffer component? If so, then
the copy function of
host could just do a normal memory copy.

We can optimize this later, when we can point the source destination
buffer to the sink destination
buffer.

thanks,
Daniel.