On 7/19/2019 10:34 AM, Vinod Koul wrote:
On 05-07-19, 11:45, Sameer Pujar wrote:
Hi Vinod,
What are your final thoughts regarding this?
Hi sameer,
Sorry for the delay in replying
On this, I am inclined to think that dma driver should not be involved.
The ADMAIF needs this configuration and we should take the path of
dma_router for this piece and add features like this to it
Hi Vinod,
The configuration is needed by both ADMA and ADMAIF. The size is
configurable
on ADMAIF side. ADMA needs to know this info and program accordingly.
Not sure if dma_router can help to achieve this.
I checked on dma_router. It would have been useful when a configuration
exported
via ADMA, had to be applied to ADMAIF. Please correct me if I am wrong here.
Thanks,
Sameer.
Where does ADMAIF driver reside in kernel, who configures it for normal
dma txns..?
Not yet, we are in the process of upstreaming ADMAIF driver.
To describe briefly, audio subsystem is using ALSA SoC(ASoC) layer.
ADMAIF is
registered as platform driver and exports DMA functionality. It
registers PCM
devices for each Rx/Tx ADMAIF channel. During PCM playback/capture
operations,
ALSA callbacks configure DMA channel using API dmaengine_slave_config().
RFC patch proposed, is to help populate FIFO_SIZE value as well during
above
call, since ADMA requires it.
Also it wold have helped the long discussion if that part was made clear
rather than talking about peripheral all this time :(
Thought it was clear, though should have avoided using 'peripheral' in
the
discussions. Sorry for the confusion.
