From: Kumar Gala <galak@kernel.crashing.org>
To: David Brownell <david-b@pacbell.net>
Cc: Vitaly Wool <vitalywool@gmail.com>, Greg KH <greg@kroah.com>,
linux-kernel@vger.kernel.org,
spi-devel-general@lists.sourceforge.net
Subject: Re: [spi-devel-general] Re: [PATCH] spi: Added spi master driver for Freescale MPC83xx SPI controller
Date: Fri, 7 Apr 2006 12:04:29 -0500 [thread overview]
Message-ID: <CD0F0EAE-B3C0-4C03-BB90-99E65C16EC4F@kernel.crashing.org> (raw)
In-Reply-To: <200604070909.08266.david-b@pacbell.net>
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
next prev parent reply other threads:[~2006-04-07 17:04 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-06 18:30 Kumar Gala
2006-04-07 5:22 ` David Brownell
2006-04-07 9:16 ` [spi-devel-general] " Vitaly Wool
2006-04-07 16:09 ` David Brownell
2006-04-07 17:04 ` Kumar Gala [this message]
2006-04-08 1:25 ` David Brownell
2006-04-07 14:04 ` Kumar Gala
2006-04-07 15:54 ` David Brownell
2006-04-07 16:44 ` Kumar Gala
2006-04-10 17:38 ` [PATCH][UPDATE] " Kumar Gala
2006-04-10 19:01 ` David Brownell
2006-04-10 19:05 ` Kumar Gala
2006-04-10 19:17 ` [PATCH][2.16.17-rc1-mm2] " Kumar Gala
2006-04-10 20:03 ` [spi-devel-general] " Vitaly Wool
2006-04-10 20:22 ` Kumar Gala
2006-04-10 21:06 ` David Brownell
2006-04-10 21:10 ` Kumar Gala
2006-04-11 14:39 ` [PATCH][2.16.17-rc1-mm2][UPDATE] " Kumar Gala
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CD0F0EAE-B3C0-4C03-BB90-99E65C16EC4F@kernel.crashing.org \
--to=galak@kernel.crashing.org \
--cc=david-b@pacbell.net \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=spi-devel-general@lists.sourceforge.net \
--cc=vitalywool@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®