Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933080Ab3FRUoa (ORCPT ); Tue, 18 Jun 2013 16:44:30 -0400 Received: from mail-la0-f42.google.com ([209.85.215.42]:52084 "EHLO mail-la0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932200Ab3FRUo3 (ORCPT ); Tue, 18 Jun 2013 16:44:29 -0400 MIME-Version: 1.0 In-Reply-To: References: <20130613172408.GA5561@intel.com> <20130618173406.GB5054@intel.com> Date: Tue, 18 Jun 2013 13:44:27 -0700 X-Google-Sender-Auth: 0O1_ftFfgEFySxSmSNIa4BBm5WQ Message-ID: Subject: Re: [PATCH] dmatest: masking tests for channel capabilities From: Dan Williams To: Andy Shevchenko Cc: Jubin Mehta , 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: 1861 Lines: 45 On Tue, Jun 18, 2013 at 1:01 PM, Andy Shevchenko wrote: > On Tue, Jun 18, 2013 at 10:16 PM, Dan Williams wrote: >> On Tue, Jun 18, 2013 at 10:34 AM, Jubin Mehta wrote: > >>> 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 > > Do you mean to enable write access to them? Yes. > >> 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. > > I'm not familiar neither with perf, nor with tracepoints. Could you > elaborate and show here the scheme how it should work? How we will get > results? In what form? > It would be very similar to what it does now except using generic functionality. At a high level you would have a tracepoint that emits something like: dma0chan0-copy0: #1: No errors with src_off=0x7bf dst_off=0x8ad len=0x3fea (0) ...and that message shows up in the ftrace buffer when it fires. These articles are a good starting point. https://lwn.net/Articles/379903/ https://lwn.net/Articles/383362/ -- 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/