On 11/3/2015 11:08 AM, Vinod Koul wrote:
On Tue, Nov 03, 2015 at 10:22:25AM +0200, Andy Shevchenko wrote:
On Tue, Nov 3, 2015 at 9:44 AM, Dan Williams <dan.j.williams@xxxxxxxxx> wrote:
On Mon, Nov 2, 2015 at 10:30 PM, Vinod Koul <vinod.koul@xxxxxxxxx> wrote:
On Mon, Nov 02, 2015 at 11:18:37PM -0500, Sinan Kaya wrote:
On 11/2/2015 11:15 PM, Vinod Koul wrote:
On Mon, Nov 02, 2015 at 01:07:38AM -0500, Sinan Kaya wrote:
This one; on the other hand, is selftest to verify hardware is
working as expected during power up.
I prefer to have such nice case by run time parameter (let's say
common to all DMA Engine drivers)
We can have common code which is used for dmatest as well as selftest. I do
not want to see same code duplicated..
First thought was to merge this to dmatest, however, some DMA
controllers doesn't have a memcpy capability.
The tests should be based on capablity of memcpy
How would we test them?
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.
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.
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.
>
> 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.
--
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
