public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: spi-devel-general@lists.sourceforge.net
Cc: Kumar Gala <galak@kernel.crashing.org>,
	linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [spi-devel-general] Re: question on spi_bitbang
Date: Fri, 31 Mar 2006 12:36:02 -0800	[thread overview]
Message-ID: <200603311236.02665.david-b@pacbell.net> (raw)
In-Reply-To: <3E572FEF-093B-4359-9FC4-45D00B33C993@kernel.crashing.org>

On Friday 31 March 2006 12:00 pm, Kumar Gala wrote:

> My confusion is about the order of which various things occur.  setup 
> (), chipselect() and transfer() vs what's happening in bitbang_work 
> ().  I don't see how we handle the fact that two different devices  
> may require setup() to be called when we switch between them.

In your case, it sounds like setup() will just store data, and you'll
want a different method to actually grab that data and use it to stuff
your controller registers before actually transferring data.  The
transfer() method just queues transfers (and maybe kicks them off).

Remember that setup() is generally a one-time thing.  Fancier hardware
will use it to store clock, mode, wordsize, and other parameters into
a hardware register so that starting a transfer is very quick.  In your
case, there's no such register, so starting transfers is slower.


One thing to keep in mind is that while I believe the spi_bitbang code
ought to support controllers like the one you're working with, I don't
know that anyone has done that yet.  So patches might be necessary.

At the top of <linux/spi/spi_bitbang.h> are verbal sketches of three
types of "bitbang" drivers.  Implementations of two of them now seem
to be working (word-at-a-time with GPIO bitbanging, "spi_butterfly"
being one of a few examples; and transfer-at-a-time, "omap_uwire").
Your hardware would be of the third type.



> >> It sounds like with the new patch, I'll end up setting txrx_word[] to
> >> the same function for all modes.
> >
> > Yes, it does sound like that.  If that works for you, I'd like to see
> > that go into 2.6.17 kernels.
> 
> I'm not sure I understand what you'd like to see go into 2.6.17.

The patch allowing the per-transfer overrides, which you were going to
grab from the MM tree.

That would support SPI drivers for things like bitmapped displays, some
of which need oddball things like 9-bit commands followed by 8-bit data.

- Dave


  reply	other threads:[~2006-03-31 20:36 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-31 17:31 question on spi_bitbang Kumar Gala
2006-03-31 18:11 ` David Brownell
2006-03-31 18:19   ` [spi-devel-general] " Stephen Street
2006-03-31 19:16     ` David Brownell
2006-03-31 19:07   ` Kumar Gala
2006-03-31 19:17     ` Kumar Gala
2006-03-31 19:32     ` [spi-devel-general] " David Brownell
2006-03-31 20:00       ` Kumar Gala
2006-03-31 20:36         ` David Brownell [this message]
2006-03-31 20:52           ` Kumar Gala
2006-03-31 21:15             ` David Brownell
2006-03-31 22:11               ` Kumar Gala
2006-03-31 22:20                 ` David Brownell
2006-03-31 23:58                   ` 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=200603311236.02665.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=galak@kernel.crashing.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=spi-devel-general@lists.sourceforge.net \
    /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