[FEATURE] Improve host input DMA start flow

[tlissows]

Is your feature request related to a problem? Please describe. Observing the problem of host-input DMA not starting of DMA traffic when using comp_host component from host-zephyr.c. An example of affected scenario is the following two-item pipeline configured for capture direction (scenario driven by existing test_02_uaol_capture.py script):

dai_uaol_output >>> host_input

In the example, the intel_adsp_hda_host_in Zephyr DMA device is used in direction DMA_DIR_LMEM_TO_HMEM. It looks, from behavior, that starting (or not) of DMA transfer is related to the order of two actions: setting of DGHISXCS.FIFORDY bit by SOF/Zephyr FW, and setting of ISDXCTL_B0.RUN bit by host SW:

• setting RUN=1 by SW followed by setting FIFORDY=1 by FW - is not working sequence,
• setting FIFORDY=1 by FW followed by setting RUN=1 by SW - is working sequence.

With the existing version of SOF/Zephyr FW and python scripts, not working sequence occurs. This is because FIFORDY bit is set by Zephyr function intel_adsp_hda_enable(), which is called by dma_start() API function for intel_adsp_hda_host_in device. SOF calls to dma_start() within host_zephyr_trigger() when COMP_TRIGGER_START arrives. On the other hand, python script sets RUN bit after setting the pipeline to PAUSED state, but prior to the subsequent pipeline starting.

Describe the solution you'd like The issue could be fixed on FW side by preponed setting of FIFORDY bit (at the latest when component is entering PAUSED state). This solution is known from closed firmware, however it could not be confirmed in FAS if it is compliant with required/recommended flow.

Describe alternatives you've considered The issue could also be fixed on the script side by postponed setting of the RUN bit (until TRIGGER_START sent). This was used to on-hand confirm that inversed sequence really works.

[lgirdwood]

Adding @plbossart @ranj063 and @ujfalusi for alignment with driver DMA flow.

[pblaszko]

HDA DMA programming sequence in pipeline flows, coming from closed-source FW (obligatory to work properly with closed-source driver):

1. Pipeline create and start:

• SW: Set PPCTL=1 (Decoupled Mode)
• SW: allocates DMA buffer
• SW: programs HDA Stream RESET
• SW: HDA Configure Stream(BDL, CTL etc.)
• IPC: Create Pipeline(): No gateway programming here. A pipeline does not own/know the gateway, the Copier (one of the pipeline's child modules) does
• IPC: Init Instance (For Each Module) For a Copier attached to a gateway, FW: a. Buffer addr and size programmed b. GEN=0 c. FIFORDY=1
• IPC: Bind Module (For each Module within Pipeline): No DMA programming
• SW: Set DMA RUN = 1 and Poll untill it reflects 1
• IPC: Set Pipe State(PAUSE): FW: if coming from UNINITIALIZED state, then no DMA programming
• IPC: Set Pipe State (RUN): FW Set GEN=1

2. Pause/Resume:

• IPC: Set Pipe State(PAUSE): FW: if coming from RUN state, then no DMA programming
• SW: Stop DMA
• SW: RUN DMA
• IPC: Set Pipe State(RUN): FW: Set GEN=1

3. Reset (XRUN):

• IPC: Set Pipe State(PAUSE): FW: if coming from RUN state, then no DMA programming
• SW: Set DMA RUN = 0 and Poll untill it reflects 0
• IPC: Set Pipe State(RESET): FW: a. GEN=0 b. FIFORDY=0
• SW: HDA Stream RESET
• SW: HDA Stream Configure(BDL, CTL etc.)
• SW: start Host DMA
• IPC: Set Pipe State(PAUSE): FW: if coming from RESET state then FIFORDY=1
• IPC: Set Pipe State (RUN): FW: Set GEN=1

4. Pipeline close:

• IPC: Set Pipe State(PAUSE): FW: if coming from RUN state, then no DMA programming
• SW: Set DMA RUN = 0 and Poll until it reflects 0
• IPC: Set Pipe State(RESET): FW: a. GEN=0 b. FIFORDY=0
• SW: HDA Stream RESET
• SW: Release the DMA channel, Set PPCTL=0
• IPC: Unbind (For each module within pipeline): No gateway programming here (Unbind IPC is optional for modules inside the same pipeline)
• IPC: Delete Instance (For each module within pipeline): FW: a. GEN = 0 b. FIFORDY = 0 c. Buffer addr and size set to 0 (IPC delete instance is optional, but if not called by SW, FW will execute this during DeletePipeline)
• IPC: Delete Pipeline: FW: if modules are already deleted, then no DMA programming; otherwise, call procedures to delete instances

[fkwasowi]

Setting the FIFORD bit to 1 in Zephyr/SOF (already in the dma_config() or dma_init() function) before setting the RUN bit did not solve the problem.

[lgirdwood]

@plbossart @ranj063 @ujfalusi pls see above - is kernel aligned ?

[plbossart]

I don't understand the ask at all

a) what doesn't work? Is this the USB offload or capturing from any interface? The latter seems surprising, we've been doing this for a long time.

b) what is the suggested solution? the last comment https://github.com/thesofproject/sof/issues/7407#issuecomment-1511068304 seems to suggest that playing with the FIFORDY before setting the RUN bit doesn't solve the problem.

I also don't get how this is a feature and not a bug. What are we trying to improve?

[lgirdwood]

@tlissows any update ? Will move to TBD milestone until direction is aligned.

[lgirdwood]

@mwasko @mmaka1 @marcinszkudlinski is there anything to be done here before v2.7 ?