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: Thu, 22 Dec 2005 08:40:33 -0800	[thread overview]
Message-ID: <200512220840.34152.david-b@pacbell.net> (raw)
In-Reply-To: <20051222180449.4335a8e6.vwool@ru.mvista.com>

On Thursday 22 December 2005 7:04 am, Vitaly Wool wrote:
> Hi David,
> 
> inlined is the small patch that adds set_clock function to the spi_bitbang structure.

This is actually not needed.  Clocks are set through the setup() method
in the spi_master, and controller drivers are (courtesy of the library
approach) free to provide their own.  Drivers for word-at-a-time hardware
would still need to call spi_bitbang_setup() in their own setup() code,
to set up the per-device controller_state, and spi_bitbang_cleanup() in
their own cleanup() code, to deallocate it.


> Currently SPI bus clock can be configured either in chipselect() (which is _wrong_)
> or in txrx_buf (also doesn't encourage me much). Making it a separate function adds
> readability for the code.   Also, it seems to be redundant to set clock on each
> transfer, so it's proposed to do per-message clock setting. If SPI bus clock
> setting involves some PLL reconfiguration it's definitely gonna save some time.  

Exactly why there's already spi_setup() in the common infrastruture,
and why the spi_bitbang_{setup,cleanup}() routines are exported for
simple drivers to shift-register level hardware.  The real "bang four
bits into protocol" style drivers won't need that since the bitbang
setup() calls calculate the delays used to satisfy those timings.
But hardware drivers -- for word-at-a-time or buffer-at-a-time style
usage -- would need that to set the clock dividers.

- Dave


/**
 * spi_setup -- setup SPI mode and clock rate
 * @spi: the device whose settings are being modified
 *
 * SPI protocol drivers may need to update the transfer mode if the
 * device doesn't work with the mode 0 default.  They may likewise need
 * to update clock rates or word sizes from initial values.  This function
 * changes those settings, and must be called from a context that can sleep.
 */
static inline int
spi_setup(struct spi_device *spi)
{
        return spi->master->setup(spi);
}



  reply	other threads:[~2005-12-22 16:40 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 [this message]
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
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=200512220840.34152.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