Re: spi_async and heavy CPU occupation by ksoftirqd

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

> 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/