On Friday 07 April 2006 10:04 am, Kumar Gala wrote:
> > Well, not the _only_ way. The polling-type txrx_word() calls are
> > also full duplex. My point is more that it's bad/inefficient to
> > incur both IRQ _and_ task switch overheads per word, when it would
> > be a lot simpler to just have the IRQ handler do its normal job.
Not that you actually _need_ an IRQ handler to be correct, in any case.
> > (And that's even true if you've turned hard IRQ handlers into threads
> > for PREEMPT_RT or whatever. In that case the "IRQ overhead" is a
> > task switch, but you're still saving _additional_ task switches.)
>
> This makes more sense about what I'm doing that is wasteful.
> However, I'm not sure exactly where I should plug into things.
Only using interfaces below the line in spi_bitbang that says
it's the "SECOND PART".
> I think you are saying to continue using spi_bitbang_transfer &
> spi_bitbang_work, but have spi_bitbang_work call my own bitbang-
> >txrx_bufs().
Yes. Consider several different ways to implement that I/O loop:
- Interrupt plus two context switches per byte (what you have now),
no per-buffer context switch
- Interrupt per byte, plus one context switch pair per buffer
(what I've described)
- pure PIO per byte, no context switches (as if you polled
the registers rather than using an IRQ)
Any of them could be correct, but one of them is a lot worse in terms
of CPU overhead when you aim at tranfer rates of even just a few MBytes
per second. (It's the one with lots of needless context switching.)
That pure PIO model will sometimes be very appropriate; if the SPI clock
is fast enough, it can be less overhead than the IRQ driven one.
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
