public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Vitaly Wool <vwool@ru.mvista.com>
Cc: linux-kernel@vger.kernel.org, spi-devel-general@sourceforge.net
Subject: Re: [PATCH 2.6-git] SPI: add set_clock() to bitbang
Date: Fri, 23 Dec 2005 00:28:03 -0800	[thread overview]
Message-ID: <200512230028.03682.david-b@pacbell.net> (raw)
In-Reply-To: <43ABA27C.6020309@ru.mvista.com>


> >>No, suppose there're two devices behind the same SPI bus that have 
> >>different clock constraints. As active SPI device change may well happen 
> >>when each new message is processed, we'll need to set up clocks again 
> >>for each message. Right?
> >
> >Clock is coupled to chipselect/device.  When the bus controller
> >switches to the other device, it updates the clock accordingly.
> 
> Yeah, but chipselect is called on per-transfer basis what is likely to 
> be redundant for clock setting.

This is basic SPI protocol stuff ... chipselect activates once at
the start of a series ("message") of transfers, and deactivates
when the series completes.  It is NOT "per transfer" ... normally
it's active between transfers, as a basic protocol requirement.

There are exceptions related to cs_change, mostly so chipselect can
be dropped temporarily ... e.g. to terminate a protocol operation,
so the next one in that group can start; EEPROMs work that way.
But most devices keep chipselect active during the whole series
of transfers that make up a message.


> Per-message clock configuration is enough AFAIS.

It doesn't need to be reconfigured even that often; it's basically
once-per-device, except in rather exceptional case.

The controller does need to update its clock rate whenever it
starts talking to a different device, though.  Some devices max
out at 1 MHz, while others are happy at 40 MHz ... so when the
chipselect to one of those goes active, SCK has to match.


> >How exactly that's done is system-specific.  Many controllers
> >just have a register per chipselect, listing stuff like SPI mode,
> >clock divisor, and word size.  So switching to that chipselect
> >kicks those in automatically ... devices ignore the clock unless
> >they've been selected.
> 
> Hmm, usually clocks are configured for the bus not device.

Not a chance.  The clock is activated to talk to a given device;
and there's no requirement that all devices on the bus use the
same clock rate.  (If one chipselect gives access to a linked series
of devices, clearly they'll all need to be clocked alike.  But
that's not a bus, it's just a compound device ... like a big shift
register.)

I did my homework when putting that API together, and looked at
quite a few SPI controllers.  **Not one** of them forces all
their chipselets to use the same clock rate.

The closest thing to your description is the SSP hardware on PXA,
which doesn't _have_ the notion of device selection.  Chipselects
for SPI are layered on top of SSP, using GPIOs ... and, you may
have noticed in Stephen's PXA driver, updating the clock (and SPI
mode, etc) whenever the software starts talking to a new device.

- Dave


  reply	other threads:[~2005-12-23  8:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-22 15:04 [PATCH 2.6-git] SPI: add set_clock() to bitbang Vitaly Wool
2005-12-22 16:40 ` David Brownell
2005-12-22 21:23   ` Vitaly Wool
2005-12-22 21:37     ` David Brownell
2005-12-22 21:42       ` Vitaly Wool
2005-12-23  0:37         ` David Brownell
2005-12-23  7:08           ` Vitaly Wool
2005-12-23  8:28             ` David Brownell [this message]
2005-12-23  8:38               ` Vitaly Wool

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=200512230028.03682.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=spi-devel-general@sourceforge.net \
    --cc=vwool@ru.mvista.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