You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
host.c has host HDA GW and DW DMA specific logic surrounded by ifdefs. This logic should be abstracted and pushed down into the DMA drivers (using new DMA ops). host.c should also support a buffer interface direct to host memories .
@dbaluta When using HDA DMA for host transfers we don't have access to the host buffer from DSP side, so we don't need host sgl. Local sgl is just the pointer to the config sgl.
@dbaluta we only have access to the host buffer after copying to DSP with HDA DMA. The Intel HDA DMA is programmed by both FW and driver; driver programs host address, FW programs DSP address, I dont remember who enables the copy though.
host.c has host HDA GW and DW DMA specific logic surrounded by ifdefs. This logic should be abstracted and pushed down into the DMA drivers (using new DMA ops). host.c should also support a buffer interface direct to host memories .
Here I am working on creating a new object host_copier which will expose mostly the same operations as host object (params, trigger, copy, prepare, etc). But I still cannot wrap my mind around on how to split the functionality.
For the moment it makes sense that
dma_buffer member of host_data to stay in host.c
dma pointer to be pushed into specific host_copier instance
dma_sg_config config member of host_data it should be pushed into specific host_copier.
... together with host and local members of host_data.
I've thought about pushing the specific ops as you said in DMA drivers but I think it makes more sense to create a special object host_copier which will contain an instance to a dma channel (if we use DMA).
@dbaluta yes, I think special object is probably the way to go atm. I guess your DSP can memcpy() directly from host -> DSP and schedule this based on the pipeline copy() callback. Another alternative is a dummy DMA driver that does just memcpy() ?
@michalgrodzicki@mengdonglin lets make this P1 for v1.4 as it cleans up our DMA logic a lot. @tlauda has already made a start, but lets track with this feature.
Activity
dbaluta commentedon Mar 4, 2019
Hi @mmaka1,
Any idea in commit b39b17d ("comp: host: hda/dw-dma flow unification") why host and local sgl are no longer used for HDA DMA?
tlauda commentedon Apr 12, 2019
@dbaluta When using HDA DMA for host transfers we don't have access to the host buffer from DSP side, so we don't need host sgl. Local sgl is just the pointer to the config sgl.
dbaluta commentedon Apr 18, 2019
@tlauda if we don't have acess to host buffer from DSP how do we copy the data?
lgirdwood commentedon Apr 18, 2019
@dbaluta we only have access to the host buffer after copying to DSP with HDA DMA. The Intel HDA DMA is programmed by both FW and driver; driver programs host address, FW programs DSP address, I dont remember who enables the copy though.
dbaluta commentedon Apr 18, 2019
@lgirdwood thanks, make sense.
dbaluta commentedon Apr 18, 2019
Here I am working on creating a new object host_copier which will expose mostly the same operations as host object (params, trigger, copy, prepare, etc). But I still cannot wrap my mind around on how to split the functionality.
For the moment it makes sense that
... together with host and local members of host_data.
I've thought about pushing the specific ops as you said in DMA drivers but I think it makes more sense to create a special object host_copier which will contain an instance to a dma channel (if we use DMA).
lgirdwood commentedon Apr 19, 2019
@dbaluta yes, I think special object is probably the way to go atm. I guess your DSP can memcpy() directly from host -> DSP and schedule this based on the pipeline copy() callback. Another alternative is a dummy DMA driver that does just memcpy() ?
dbaluta commentedon Apr 21, 2019
@lgirdwood yes, I can directly memcpy from host -> DSP. For the moment I'm going with the dummy DMA driver that just does memcpy().
lgirdwood commentedon Jun 7, 2019
@michalgrodzicki @mengdonglin lets make this P1 for v1.4 as it cleans up our DMA logic a lot. @tlauda has already made a start, but lets track with this feature.