Hi!
During ELCE 2017 Lars, Alexey and me had a chat with regards to DMA
subsystem. There were IIRC few topics. Let me summarize what was being
discussed and the next steps.
(Lars, Alexey, please correct me if / where I'm wrong)
DesignWare DMA driver (AHB)
---------------------------
I have a lot of stuff to do besides this one driver. Moreover, it looks
like there is nothing (features) anticipated to be done to the driver
from me since Intel switched to its own DMA engine, IDMA, which looks
like DW DMA, though 64-bit (though 32-bit version of it, that present in
few Intel SoCs, had been embedded to DesignWare DMA driver already).
Thus, I would like to step down from co-maintainer to just a designated
reviewer for the driver. Synopsys may take over, and Alexey has a
candidate in his mind.
I also think Viresh can do the same. Viresh?
That said, we will keep an eye on driver changes.
The proposed change is a patch from Synopsys against MAINTAINERS data
base from the potential (co-)maintainer of the driver where Viresh and
me are moved under R: and new maintainer under M: records respectively.
DesignWare DMA driver (AXI)
---------------------------
There were some issues with the code, though it looks like the lack of
explanation in commit message why it's done one way than other.
We agreed with Alexey that next version of the patch will clarify it.
DMA error reporting
-------------------
There was (still is?) an issue with good error reporting to a user, in
particularly DW DMA (AXI) [see above] needs it. As far as I understood
current situation is much better. Caller could register a callback which
will be called on error condition. The enum provides plain integer error
codes where just few now are registered and there is enough room to add
more on demand.
Per channel DMA parameters structure and sg_list (re-)split
-----------------------------------------------------------
Potentially some of DMA controllers may have different configuration
options on per channel basis. Inside struct device we have embedded
struct dma_parms which provides two fields: 1) maximum segment size, and
2) alignment boundary. API to set and retrieve these parameters is
bound to struct device. We might need something similar for struct
dma_chan.
(That's why I stopped doing my patch series with sg_list split for DMA
controller drivers)
Some frameworks (SPI core, for example) are already using this to
prepare sg_list accordingly.
The benefit of the change is to decrease latency for DMA setup when
sg_list is prepared without actual knowledge about DMA channel
parameters.
Alexey shared opinion that there is no rush to implement it because
there is no example of such device in practice.
Lars has different view on this, pointing to flexibility of the drivers
(drivers know for sure all limitations and advantages of certain DMA
controller) and necessity to do at least a check since not all
subsystems are supporting mentioned API.
--
Andy Shevchenko <andriy.shevchenko@xxxxxxxxx>
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo��.n��������+%������w��{.n��������)�)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
