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
next prev parent 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).