R: spi_async and heavy CPU occupation by ksoftirqd

["Andrea Paterniani" <a.paterniani-03BXCEkGbFHYGGNLXY5/rw@public.gmane.org>]

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