linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vinod Koul <vinod.koul@intel.com>
To: Sinan Kaya <okaya@codeaurora.org>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>,
	Dan Williams <dan.j.williams@intel.com>,
	"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
	timur@codeaurora.org, cov@codeaurora.org, jcm@redhat.com,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V2 2/3] dmaselftest: add memcpy selftest support functions
Date: Sun, 8 Nov 2015 19:23:53 +0530	[thread overview]
Message-ID: <20151108135352.GA22709@localhost> (raw)
In-Reply-To: <563D98E6.6070501@codeaurora.org>

On Sat, Nov 07, 2015 at 01:23:34AM -0500, Sinan Kaya wrote:
> 
> 
> On 11/5/2015 11:17 AM, Sinan Kaya wrote:
> >
> >
> >On 11/5/2015 7:05 AM, Vinod Koul wrote:
> >>On Wed, Nov 04, 2015 at 09:42:46PM -0500, Sinan Kaya wrote:
> >>>Here is what I proposed.
> >>>
> >>>- a common file that gets compiled into a module that wants to use
> >>>self-test with a public API. It can be called from driver's probe
> >>>routine.
> >>>- the test is independent of my implementation. It uses dmaengine
> >>>API and should be portable to most drivers.
> >>>- there *are* still drivers in the kernel that has selftest code
> >>>embedded inside them. I followed the design pattern from other
> >>>drivers thinking this must have been a good idea and it paid off for
> >>>me.
> >>>
> >>>As far as I understand, there is interest in doing more than this
> >>>and reusing the dmatest code for code duplication.
> >>
> >>the code that selftest uses to test will be very similar to dmatest code,
> >>both of these _should_ share this common code so that fixes get done for
> >>both!
> >>
> >
> >OK, I can move the code around and try to combine it if possible.
> >
> 
> I looked at this. IMO, merging selftest code and dmatest code is not
> a good idea.
> 
> Dmatest code has been well written and structured so that multiple
> DMA capabilities (XOR, PQ, MEMCPY) can be tested with the same code.
> 
> It supports threads and user space interaction.
> 
> The code I want to change (dmatest_func) is 3 levels deep in
> structure. My refactored code looked really ugly compared to the
> original code.

dmatest_func is still a bigger fn specific to dmatest. I was thinking that we
should have rather have two common functions
1) dmatest_do_dma() which does buffer allocation, invoking dmaengine APIs and
checking results, part of dmatest_func today

2) request_channels() would also be common along with cleanup routines

> >>>Facts:
> >>>- Dmatest can be actually configured to run during boot.
> >>>- Nobody besides the dma driver developer uses dmatest. This leaves
> >>>holes for regressions that are really hard to debug due to
> >>>interaction with the rest of the system.
> >>>- Dmatest doesn't exist in most distribution kernels.
> >>
> >>That doesn't mean it is not useful. This line of thought is not quite
> >>right.
> >>You are trying to say dmatest in not important and selftest is. Sorry but
> >>you are wrong, both are equally important and since both try to test
> >>and use
> >>similar routines (dmaengien API) they need to share the code and not
> >>duplicate it
> >>
> >>>If we want to do something else, I need clear directions. I can
> >>>remove the self test code completely from my driver. But, I need an
> >>>equivalent functionality.
> >>
> >>Add selftest to dmatest, we need both!
> >>
> >
> >OK, do you have any objections to compiling dmatest along with hidma in
> >the same module and calling a function from there ? or do you have
> >something else in your mind ?
Not the dmatest completely, that won't be right, but yes for the dmatest
core which is common b/w both. We cna put this is separate file to compile
along with driver if that is users requirement

-- 
~Vinod

  reply	other threads:[~2015-11-08 13:50 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1446444460-21600-1-git-send-email-okaya@codeaurora.org>
2015-11-02  6:07 ` [PATCH V2 1/3] dma: add Qualcomm Technologies HIDMA management driver Sinan Kaya
2015-11-02 15:57   ` Rob Herring
2015-11-02 16:20     ` Sinan Kaya
2015-11-02 17:26       ` Timur Tabi
2015-11-02 17:42         ` Rob Herring
2015-11-02 17:48           ` Timur Tabi
2015-11-02 18:25             ` Rob Herring
2015-11-02 18:30               ` Timur Tabi
2015-11-05 14:31                 ` Rob Herring
2015-11-05 14:43                   ` Timur Tabi
2015-11-02 18:49           ` Sinan Kaya
2015-11-02 22:00             ` Arnd Bergmann
2015-11-03  5:18     ` Sinan Kaya
2015-11-03 10:22   ` Andy Shevchenko
2015-11-04  0:47     ` Sinan Kaya
2015-11-02  6:07 ` [PATCH V2 2/3] dmaselftest: add memcpy selftest support functions Sinan Kaya
2015-11-03  4:15   ` Vinod Koul
2015-11-03  4:18     ` Sinan Kaya
2015-11-03  6:30       ` Vinod Koul
2015-11-03  7:44         ` Dan Williams
2015-11-03  8:22           ` Andy Shevchenko
2015-11-03 16:08             ` Vinod Koul
2015-11-05  2:42               ` Sinan Kaya
2015-11-05 12:05                 ` Vinod Koul
2015-11-05 16:17                   ` Sinan Kaya
2015-11-07  6:23                     ` Sinan Kaya
2015-11-08 13:53                       ` Vinod Koul [this message]
2015-11-13 20:20                         ` okaya
2015-11-03 15:51           ` Sinan Kaya
2015-11-03 16:06           ` Vinod Koul
2015-11-03 14:31       ` Timur Tabi
2015-11-03 16:10         ` Vinod Koul
2015-11-03 16:28           ` Sinan Kaya
2015-11-03 16:46             ` Timur Tabi
2015-11-03 16:57               ` Sinan Kaya
2015-11-03 16:48           ` Timur Tabi
2015-11-02  6:07 ` [PATCH V2 3/3] dma: add Qualcomm Technologies HIDMA channel driver Sinan Kaya
2015-11-03 10:10   ` Andy Shevchenko
2015-11-04  0:07     ` Sinan Kaya
2015-11-04 17:44       ` Andy Shevchenko
2015-11-05  2:22         ` Sinan Kaya

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151108135352.GA22709@localhost \
    --to=vinod.koul@intel.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=cov@codeaurora.org \
    --cc=dan.j.williams@intel.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=jcm@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=okaya@codeaurora.org \
    --cc=timur@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).