You're right the current version of the driver doesn't support RDY control.
Infact SPI_DEFAULT_CONTROL is defined with SPI_CONTROL_DRCTL_0.
Also setup function doesn't managed DRCTL changes.

Then you probably changes SPI_DEFAULT_CONTROL to use SPI_CONTROL_DRCTL_2.

Please do your suggestions for driver modification in order to release a driver patch.

- Andrea

-----Messaggio originale-----
Da: llandre [mailto:r&d2-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org]
Inviato: venerdì 10 agosto 2007 13.33
A: Andrea Paterniani
Cc: David Brownell; spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Oggetto: Re: [spi-devel-general] spi_async and heavy CPU occupation by
ksoftirqd


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

quoted

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

quoted

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

quoted

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.

quoted

quoted

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.

quoted

quoted

quoted

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/