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.
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 ?
That part is tricky, you need to do so thru clients, spi/audio/serial etc
My selftest code actually attaches to all slave devices and issues a
memcpy command and then detaches from the slave devices.
Not everyone supports memcpy!
Right, last time I checked; you can request a DMA channel that supports
MEMCPY specifically.
--
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 dmaengine" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
