[Sound-open-firmware] Design document - topology, scheduling et all
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? It is my first time using topology and I'm still yet to get around the m4 topology description.
2) Is there any design document for the SOF architecture. I'm still yet to understand how components and scheduler interact.
thanks, Daniel.
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:
- 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.
It is my first time using topology and I'm still yet to get around the m4 topology description.
In simple cases it may be easier to work directly with an alsaconf format. M4 is mostly there for reuse of configurations, it's not always readable or concise...
- Is there any design document for the SOF architecture. I'm still
yet to understand how components and scheduler interact.
Mostly by the definition of priorities and rates.
On Mon, Feb 11, 2019 at 11:30 PM Pierre-Louis Bossart pierre-louis.bossart@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:
- 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.
Both for the moment.
host memory <-> internal DSP memory, I don't think we have something like this. Both host and DSP have access to a big chunk of shared SDRAM.
internal memory <-> audio peripheral, we have a DMA controller here but I would expect to take me some time to write the driver for this.
It is my first time using topology and I'm still yet to get around the m4 topology description.
In simple cases it may be easier to work directly with an alsaconf format. M4 is mostly there for reuse of configurations, it's not always readable or concise...
Good to know. Will try.
- Is there any design document for the SOF architecture. I'm still
yet to understand how components and scheduler interact.
Mostly by the definition of priorities and rates.
Thanks!
On Mon, Feb 11, 2019 at 11:37 PM Daniel Baluta daniel.baluta@gmail.com wrote:
On Mon, Feb 11, 2019 at 11:30 PM Pierre-Louis Bossart pierre-louis.bossart@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:
- 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.
participants (2)
-
Daniel Baluta -
Pierre-Louis Bossart