Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933207Ab3FRTQL (ORCPT ); Tue, 18 Jun 2013 15:16:11 -0400 Received: from mail-lb0-f174.google.com ([209.85.217.174]:53637 "EHLO mail-lb0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932391Ab3FRTQJ (ORCPT ); Tue, 18 Jun 2013 15:16:09 -0400 MIME-Version: 1.0 In-Reply-To: <20130618173406.GB5054@intel.com> References: <20130613172408.GA5561@intel.com> <20130618173406.GB5054@intel.com> Date: Tue, 18 Jun 2013 12:16:07 -0700 X-Google-Sender-Auth: kWntvKUMJjNDI8fpgRhUnOOBIBU Message-ID: Subject: Re: [PATCH] dmatest: masking tests for channel capabilities From: Dan Williams To: Jubin Mehta Cc: Vinod Koul , Linux Kernel Mailing List , Andy Shevchenko , Dave Jiang , Jon Mason Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2414 Lines: 54 On Tue, Jun 18, 2013 at 10:34 AM, Jubin Mehta wrote: > On Mon, Jun 17, 2013 at 02:12:51PM -0700, Dan Williams wrote: >> [ apologies for the resend, gmail defaulted to html ] >> >> On Mon, Jun 17, 2013 at 2:10 PM, Dan Williams wrote: >> >> +Example to perform only MEMCPY and PQ mode tests (0x01 | 0x04 = 0x05): >> >> + >> >> + % modprobe dmatest >> >> + % echo dma0chan0 > /sys/kernel/debug/dmatest/channel >> >> + % echo 5 > /sys/kernel/debug/dmatest/cap_mask >> >> + % echo 1 > /sys/kernel/debug/dmatest/iterations >> >> + % echo 1 > /sys/kernel/debug/dmatest/run >> > >> > >> > Hmmm, I should have paid more attention when the debugfs support was >> > initially proposed for dmatest. As it is I see duplication and >> > configuration parameters getting out of sync with their module parameter >> > equivalents versus just having all configuration go through module >> > parameters. module_param_call() can be used for the more complex options. >> > Debugfs at this point looks like overkill for what amounts to some simple >> > configuration variables and a result line. >> > >> > -- >> > Dan >> > Would you like to have some changes regarding the configuration > process for the module parameters of the dmatest? Yes, as a first step I would like to see a clean up of the the configuration parameters to be available via /sys/module/dmatest/parameters rather than /sys/kernel/debug/dmatest As for "run" and "results" I see Andy's point that those are a bit awkward as parameters. However, we do have trace points as a more general mechanism for dumping events and data to userspace. If we had /sys/module/dmatest/parameters/run with a tracepoint for the result line does that get us everything we need for automation? I can see more tracepoints beng added to get some perf metrics out of the tests. Thoughts? > Any other comments with respect to the patch? How about a comma separated list of named capabilities (copy, xor, pq, xor_val, sg... etc) rather than a mask? If we are already not using the dma_transaction_type values might as well use something human readable. -- Dan -- 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/