[FEATURE] Improve host input DMA start flow

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.

@plbossart

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

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

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.

@plbossart

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

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 #7407 (comment) 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?

@tlissows

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

@mwasko

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

Navigation Menu

Repository navigation

[FEATURE] Improve host input DMA start flow #7407

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[FEATURE] Improve host input DMA start flow #7407

Description

Activity

lgirdwood commented on Apr 6, 2023

pblaszko commented on Apr 12, 2023

fkwasowi commented on Apr 17, 2023

lgirdwood commented on Apr 24, 2023

plbossart commented on Apr 24, 2023

lgirdwood commented on May 10, 2023

lgirdwood commented on Jul 4, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions