> -----Original Message-----
> From: David Brownell [mailto:[EMAIL PROTECTED]
> Sent: den 2 december 2008 19:17
> To: [EMAIL PROTECTED]
> Cc: 'Peter Korsgaard'; [email protected]
> Subject: Re: [spi-devel-general] Performance of spi_mpc83xx.c sucks.
>
> On Tuesday 02 December 2008, Joakim Tjernlund wrote:
> > > > The question is if the poll code I sent is good, even for longer
> > > > transfers?
> > > > Perhaps some sort of LOWLAT flag could be used for transfers that
> > > > really need them?
> > >
> > > So long as you do the polling with IRQs enabled, I'd keep it simple and
> > > just always poll. Â YMMV of course, but most devices seem to prefer more
> > > like 10 MHz clocks than 1 MHz ones.
> >
> > Sorry for the delay, forgot about this.
> >
> > Won't polling for long periods starve user space?
>
> If your system is that I/O bound, use DMA ... :)
:), I wish I had the time to do such a driver.
>
> > How to overcome this?
> > Why use a kernel thread(mpc83xx_spi.0) to do the work?
> > Would it not be better if the polling was in process context?
>
> Using a kernel thread, like the not-so-well-named bitbang
> utilities will do for you, *does* ensure the polling is
> done in a process context. If it's interruptible, as I
> suggested, it should also be pre-emptible ... so if its
> activity (polling) gets to be serious overhead, some other
> task can be scheduled.
Oh, so the kernel thread actually gets pre-empted(is that a word?)
once it has consumed its "time slice"? Do I need to turn on
pre-empt support in the kernel for this?
Jocke
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
spi-devel-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/spi-devel-general