Lowered my SPI clock down to 1MHz (from 50MHz (in steps of 10MHz).
At 1Mhz the driver stops starving the rest of the kernel.

What is interesting is that due to the low duty cycle of the SPI port
the transfer rate at 1MHz and 50Mhz is almost the same.

I suggest that the driver simply limits max frequency to 1Mhz.

This (very limited) SPI pherperial does not handle any more anyways.

rg
kd


Grant Likely wrote:
On Tue, Jun 23, 2009 at 8:40 AM, Kári Davíðsson<kari.davids...@marel.com> wrote:
Hi,

I have been testing this driver a little bit (on 2.6.29.3)

What happens for me is that the driver starves the system while sending
data over the SPI interface.

I think the problem is in the function (interrupt handler)
mpc52xx_spi_irq() that calls the function mpc52xx_spi_fsm_process()
which again is an loop that iterates over the whole data to be sent.

Hmmm, the state machine is supposed to yield after each byte sent, but
on fast transfers I could see it becoming ready to run again
immediately.

Unfortunately it is not an easy problem.  The SPI device can only
handle 1 byte at a time.  Maybe it would be better for CPU fairness if
all the work was done in a thread.  I didn't originally because I
didn't want to introduce a huge amount of scheduling overhead every
time a byte was transfered, and I wanted to keep transfers fast.  I
need to think about this some more.

g.

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Reply via email to