On Mon, Nov 2, 2015 at 10:30 PM, Vinod Koul <vinod.koul@xxxxxxxxx> wrote:
On Mon, Nov 02, 2015 at 11:18:37PM -0500, Sinan Kaya wrote:
On 11/2/2015 11:15 PM, Vinod Koul wrote:
On Mon, Nov 02, 2015 at 01:07:38AM -0500, Sinan Kaya wrote:Dmatest is a standalone kernel module intended for stress testing
This patch adds supporting utility functions
for selftest. The intention is to share the self
test code between different drivers.
Supported test cases include:
1. dma_map_single
2. streaming DMA
3. coherent DMA
4. scatter-gather DMA
This seems quite similar to dmatest, any reason why you cannot use/enhance
that?
DMA engines from userspace with N number of threads and M size
combinations etc.
This one; on the other hand, is selftest to verify hardware is
working as expected during power up.
Almost all DMA engine drivers come with some sort of selftest code
called from probe. I followed the same design pattern.
which ones ?
I think the goal is to remove the duplicate self test code in all
drivers over time.
and what prevents us from having common selftest plus dmatest code. Most of
the code here to do selftest is _same_ dmaengine routine code used in
dmatest
We can have common code which is used for dmatest as well as selftest. I do
not want to see same code duplicated..
Originally ioatdma and iop-adma had local self tests before Haavard
created dmatest. I agree having the drivers also do a test each boot
is redundant, but then again dmatest is not automatic and I saw the
local self test catch an interrupt setup regression.
Maybe you could arrange for drivers to do a quick autorun through
dmatest on load if dmatest is enabled, but otherwise load without
testing? Just my 2 cents from a dmaengine spectator.