>>
>> 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.
>>
>>
>>
>> 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.
>>
>>
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
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
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
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
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
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
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
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
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 wrote:
On Mon, Nov 2, 2015 at 10:30 PM, Vinod Koul wrote:
On Mon, Nov 02, 2015 at 11:18:37PM -0500, Sinan Kaya wrote:
On 11/2/2015 11:15
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 wrote:
On Mon, Nov 2, 2015 at 10:30 PM, Vinod Koul wrote:
On Mon, Nov 02, 2015 at
On 11/3/2015 11:46 AM, Timur Tabi wrote:
Sinan Kaya wrote:
1. Bug in ARM64 DMA subsystem.
2. Bug in IOMMU driver.
3. Bug in another newly introduced driver. The new driver would hog the
CPU and won't allow HIDMA interrupts to execute. Therefore, the test
times out.
Which driver?
Some other
Vinod Koul wrote:
Failing politely would be right thing to do. If DMA starts sending data to
anywhere in system memory due to bug or wrong addresses we can't do
anything to prevent that
My point is that I have a hard time believing that a DMA failure would
likely result the driver politely
Sinan Kaya wrote:
1. Bug in ARM64 DMA subsystem.
2. Bug in IOMMU driver.
3. Bug in another newly introduced driver. The new driver would hog the
CPU and won't allow HIDMA interrupts to execute. Therefore, the test
times out.
Which driver?
Wouldn't these problems already be exposed by dmatest?
On 11/3/2015 11:10 AM, Vinod Koul wrote:
On Tue, Nov 03, 2015 at 08:31:57AM -0600, Timur Tabi wrote:
Sinan Kaya wrote:
Almost all DMA engine drivers come with some sort of selftest code
called from probe. I followed the same design pattern.
As others have said, it appears that's outdated.
On Tue, Nov 03, 2015 at 08:31:57AM -0600, Timur Tabi wrote:
> Sinan Kaya wrote:
> >
> >Almost all DMA engine drivers come with some sort of selftest code
> >called from probe. I followed the same design pattern.
>
> As others have said, it appears that's outdated.
>
> Is there a real possibility
On Tue, Nov 03, 2015 at 10:22:25AM +0200, Andy Shevchenko wrote:
> On Tue, Nov 3, 2015 at 9:44 AM, Dan Williams wrote:
> > On Mon, Nov 2, 2015 at 10:30 PM, Vinod Koul 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
On Mon, Nov 02, 2015 at 11:44:23PM -0800, Dan Williams wrote:
> Originally ioatdma and iop-adma had local self tests before Haavard
> created dmatest. I agree having the drivers also do a test each boot
> is redundant, but then again dmatest is not automatic and I saw the
> local self test catch
On 11/3/2015 2:44 AM, Dan Williams wrote:
On Mon, Nov 2, 2015 at 10:30 PM, Vinod Koul 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 patch adds supporting
Sinan Kaya wrote:
Almost all DMA engine drivers come with some sort of selftest code
called from probe. I followed the same design pattern.
As others have said, it appears that's outdated.
Is there a real possibility that the hardware could fail the test
without trashing the system? It
On Tue, Nov 3, 2015 at 9:44 AM, Dan Williams wrote:
> On Mon, Nov 2, 2015 at 10:30 PM, Vinod Koul 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
On Tue, Nov 3, 2015 at 9:44 AM, Dan Williams wrote:
> On Mon, Nov 2, 2015 at 10:30 PM, Vinod Koul 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
On 11/3/2015 2:44 AM, Dan Williams wrote:
On Mon, Nov 2, 2015 at 10:30 PM, Vinod Koul 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 patch
On 11/3/2015 11:46 AM, Timur Tabi wrote:
Sinan Kaya wrote:
1. Bug in ARM64 DMA subsystem.
2. Bug in IOMMU driver.
3. Bug in another newly introduced driver. The new driver would hog the
CPU and won't allow HIDMA interrupts to execute. Therefore, the test
times out.
Which driver?
Some other
Sinan Kaya wrote:
Almost all DMA engine drivers come with some sort of selftest code
called from probe. I followed the same design pattern.
As others have said, it appears that's outdated.
Is there a real possibility that the hardware could fail the test
without trashing the system? It
On 11/3/2015 11:10 AM, Vinod Koul wrote:
On Tue, Nov 03, 2015 at 08:31:57AM -0600, Timur Tabi wrote:
Sinan Kaya wrote:
Almost all DMA engine drivers come with some sort of selftest code
called from probe. I followed the same design pattern.
As others have said, it appears that's outdated.
On Tue, Nov 03, 2015 at 10:22:25AM +0200, Andy Shevchenko wrote:
> On Tue, Nov 3, 2015 at 9:44 AM, Dan Williams wrote:
> > On Mon, Nov 2, 2015 at 10:30 PM, Vinod Koul wrote:
> >> On Mon, Nov 02, 2015 at 11:18:37PM -0500, Sinan Kaya wrote:
> >>> On
On Mon, Nov 02, 2015 at 11:44:23PM -0800, Dan Williams wrote:
> Originally ioatdma and iop-adma had local self tests before Haavard
> created dmatest. I agree having the drivers also do a test each boot
> is redundant, but then again dmatest is not automatic and I saw the
> local self test catch
On Tue, Nov 03, 2015 at 08:31:57AM -0600, Timur Tabi wrote:
> Sinan Kaya wrote:
> >
> >Almost all DMA engine drivers come with some sort of selftest code
> >called from probe. I followed the same design pattern.
>
> As others have said, it appears that's outdated.
>
> Is there a real possibility
Sinan Kaya wrote:
1. Bug in ARM64 DMA subsystem.
2. Bug in IOMMU driver.
3. Bug in another newly introduced driver. The new driver would hog the
CPU and won't allow HIDMA interrupts to execute. Therefore, the test
times out.
Which driver?
Wouldn't these problems already be exposed by dmatest?
Vinod Koul wrote:
Failing politely would be right thing to do. If DMA starts sending data to
anywhere in system memory due to bug or wrong addresses we can't do
anything to prevent that
My point is that I have a hard time believing that a DMA failure would
likely result the driver politely
On Mon, Nov 2, 2015 at 10:30 PM, Vinod Koul 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 patch adds supporting utility functions
>> >>for selftest.
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 patch adds supporting utility functions
> >>for selftest. The intention is to share the self
> >>test code between
On 11/2/2015 11:15 PM, Vinod Koul wrote:
On Mon, Nov 02, 2015 at 01:07:38AM -0500, Sinan Kaya wrote:
This patch adds supporting utility functions
for selftest. The intention is to share the self
test code between different drivers.
Supported test cases include:
1. dma_map_single
2. streaming
On Mon, Nov 02, 2015 at 01:07:38AM -0500, Sinan Kaya wrote:
> This patch adds supporting utility functions
> for selftest. The intention is to share the self
> test code between different drivers.
>
> Supported test cases include:
> 1. dma_map_single
> 2. streaming DMA
> 3. coherent DMA
> 4.
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 patch adds supporting utility functions
> >>for selftest. The intention is to share the self
> >>test code between
On Mon, Nov 2, 2015 at 10:30 PM, Vinod Koul 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 patch adds supporting utility
On Mon, Nov 02, 2015 at 01:07:38AM -0500, Sinan Kaya wrote:
> This patch adds supporting utility functions
> for selftest. The intention is to share the self
> test code between different drivers.
>
> Supported test cases include:
> 1. dma_map_single
> 2. streaming DMA
> 3. coherent DMA
> 4.
On 11/2/2015 11:15 PM, Vinod Koul wrote:
On Mon, Nov 02, 2015 at 01:07:38AM -0500, Sinan Kaya wrote:
This patch adds supporting utility functions
for selftest. The intention is to share the self
test code between different drivers.
Supported test cases include:
1. dma_map_single
2. streaming
This patch adds supporting utility functions
for selftest. The intention is to share the self
test code between different drivers.
Supported test cases include:
1. dma_map_single
2. streaming DMA
3. coherent DMA
4. scatter-gather DMA
Signed-off-by: Sinan Kaya
---
drivers/dma/dmaengine.h |
This patch adds supporting utility functions
for selftest. The intention is to share the self
test code between different drivers.
Supported test cases include:
1. dma_map_single
2. streaming DMA
3. coherent DMA
4. scatter-gather DMA
Signed-off-by: Sinan Kaya
---
42 matches
Mail list logo