Re: spi_async and heavy CPU occupation by ksoftirqd

[llandre <r&d2-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org>]

I think I found the cause.
Since I needed to enable the RDY control (SPI_CONTROL_DRCTL_2) as 
required by the SPI slave (Quantum QT510), the actual SPI transactions 
may occur after the driver wrote the TX FIFO (if (write(drv_data))).
Thus

while ((read(drv_data) == 0) && limit--);

waits until the actual transaction have been completed, that happens 
when the slave is ready to accept data.
So I'm afraid I need modify the MXL driver in order to support this case.

-- 
llandre

DAVE Electronics System House - R&D Department
web:   http://www.dave-tech.it
email: r&d2-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org


> Is there any logged error message?
> May be that limit reaches 0 but in this case an error is logged (trailing bytes read failed).
> 
> - Andrea
> 
> 
> 
> 
> 
>> -----Messaggio originale-----
>> Da: llandre [mailto:r&d2-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org]
>> Inviato: venerdì 10 agosto 2007 10.52
>> A: David Brownell
>> Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org; Andrea Paterniani
>> Oggetto: Re: [spi-devel-general] spi_async and heavy CPU occupation by
>> ksoftirqd
>>
>>
>>> That seems to be the most precise tool you have, unless you
>>> have access to the JTAG-style hardware tools giving access
>>> to the on-chip instruction trace buffers found in many ARMs.
>> Unfortunatley trace port is not available so I have to use the old
>> fashioned debug pin technique.
>>
>>>> or does the kernel provides some
>>>> tools to do that? Could oprofile come to help?
>>> Statistical profiling probably wouldn't help.  I'm not sure that
>>> anything like gprof is working in the kernel.  Folk that I know
>>> have done that level analysis tend to rely on hardware trace tools.
>> I see.
>>
>>>>> I'd expect that using spi_sync() wouldn't save much, but it might
>>>>> be worth verifying that.
>>>> Initially my driver used spi_sync. When I realized the huge CPU
>>>> occupation I modified it in order to use spi_async instead but, again,
>>>> nothing changed.
>>> And that should have been a HUGE clue that the way you were calling
>>> it wasn't a factor at all.
>> I moved the set/clear pin functions inside the iMXL master driver and I
>> found the problem is at line 804 inside the interrupt handler:
>>
>> 	qt510_debug_pin(1);
>> 	while ((read(drv_data) == 0) && limit--);
>> 	qt510_debug_pin(0);
>>
>> Usually the high pulse lasts about 10ms. Occasionally (about 1 time out
>> of 3) it lasts about 300 ms ! That would explain the ksoftirqd abnormal
>> CPU occupation.
>> I hope Andrea can come to help.
>>
>>
>>
>> --
>> llandre
>>
>> DAVE Electronics System House - R&D Department
>> web:   http://www.dave-tech.it
>> email: r&d2-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org
> 
> 
> 



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/