Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932507AbbKCPwR (ORCPT ); Tue, 3 Nov 2015 10:52:17 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:53655 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754810AbbKCPv6 (ORCPT ); Tue, 3 Nov 2015 10:51:58 -0500 Subject: Re: [PATCH V2 2/3] dmaselftest: add memcpy selftest support functions To: Dan Williams , Vinod Koul References: <1446444460-21600-1-git-send-email-okaya@codeaurora.org> <1446444460-21600-3-git-send-email-okaya@codeaurora.org> <20151103041528.GS21326@localhost> <5638359D.9080507@codeaurora.org> <20151103063009.GT21326@localhost> Cc: "dmaengine@vger.kernel.org" , timur@codeaurora.org, cov@codeaurora.org, jcm@redhat.com, "linux-kernel@vger.kernel.org" From: Sinan Kaya Message-ID: <5638D81B.2010303@codeaurora.org> Date: Tue, 3 Nov 2015 10:51:55 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2929 Lines: 87 On 11/3/2015 2:44 AM, Dan Williams wrote: > On Mon, Nov 2, 2015 at 10:30 PM, Vinod Koul 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: >>>>> 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? >>>> >>> Dmatest is a standalone kernel module intended for stress testing >>> 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. I see the following files still have some sort of self test code in them. ioat\dma.c ioat\dma_v2.c ioat\dma_v3.c iop-adma.c mv_xor.c > > 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. > I'm on the same boat. Almost all kernel configurations that I have seen do not have dmatest enabled. Dmatest is considered debug only and is not included into the kernel binaries. I have no problem for moving the code from one location to the other but I still want to be able to run self-test code in mission mode before enabling DMA as today. I'm open to suggestions. -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/