Re: [spi-devel-general] Re: [PATCH] spi: Added spi master driver for Freescale MPC83xx SPI controller

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Apr 7, 2006, at 11:09 AM, David Brownell wrote:

On Friday 07 April 2006 2:16 am, Vitaly Wool wrote:
Hi,

I guess I'm surprised you're not using txrx_buffers() and having
that whole thing be IRQ driven, so the per-word cost eliminates
the task scheduling.  You already paid for IRQ handling ... why
not have it store the rx byte into the buffer, and write the tx
byte froom the other buffer?  That'd be cheaper than what you're
doing now ... in both time and code.  Only wake up a task at
the end of a given spi_transfer().

I might be completely wrong here, but I was asking myself this very
question, and it looks like that's the way to implement full duplex
transfers.

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.

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

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().

- kumar
-
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]
  Powered by Linux