linux-spi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ben Gamari <bgamari.foss-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: beagleboard <beagleboard-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>,
	linux-omap <linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	David Brownell
	<dbrownell-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>,
	Eric Miao <eric.miao-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>,
	Michael Henn
Subject: McSPI questions pertaining to GPIO chip select support
Date: Wed, 27 Jan 2010 23:10:26 -0500	[thread overview]
Message-ID: <1264651770-sup-5197__49645.0047860437$1264651881$gmane$org@ben-laptop> (raw)
In-Reply-To: <1264016711-sup-309@ben-laptop>

Hey all!

Recently I've been thinking about adding support to the McSPI driver for
using GPIO pins as chip selects. As a starting point, I've browsed the
driver source trying to identify what changes would be necessary to add
this support. It seems like the rough idea is,

  a) add a cs_gpio field to the device struct (omap2_mcspi)
  b) modify omap2_mcspi_force_cs() to use cs_gpio instead of the
     CHxCONF[FORCE] bit if cs_gpio is valid

Unfortunately, I'm having a bit of difficulty seeing how the existing
configuration works. In master mode, it seems that the controller is
configured in single forced channel mode (MCSPI_MODULECTRL_SINGLE).  As
far as I can tell, this means that the driver is responsible for
managing the chip selects through the MCSPI_CHxCONF[FORCE] bits. It
seems that this is ideal as little will need to be changed to
incorporate GPIO CS support.

Nevertheless, the timing of the various operations isn't making sense to
me. As far as I understand it, the callgraph is as follows,


omap2_mcspi_work():
  loop over messages
    omap2_mcspi_set_enable(1)
    loop over transfers:
      configure bus parameters
      if (!cs_active) cs = 1
      if (dma):
        omap2_mcspi_txrx_dma()
      else:
        omap2_mcspi_txrx_pio()
      if (cs_change) cs = 0
    end loop
  
    if (cs_active) cs = 0
    omap2_mcspi_set_enable(0)
  end loop


It seems that omap2_mcspi_set_enable() is called to enable the channel
(MCSPI_CHCTRLx[EN] is set) before force_cs() is called. If I'm
interpreting the hardware documentation correctly, the enable bit (among
other things) starts the SPI clock, meaning that the chip will begin
clocking out zeros to the device before CS is brought high.
Furthermore, even after CS is brought high, it seems there could be a
fair amount of time before the chip begins actually clocking out valid
data.

As I am writing this, it now occurs to me that perhaps the chip doesn't
start SPI_CLK until it has data to send. It seems that if this were the
case my concerns would be resolved. However, it is not at all clear that
this is the case from the documentation. When exactly does the
controller start the bus clock? Is this stated explicitly anywhere in
the documentation?

Any input you could offer would be greatly appreciated.
Thanks for your time.

- Ben


P.S. The more and more I think about it, it seems like my hypothesis is
the only logical behavior. It would be great if someone could confirm my
suspicions, however. It really seems like this should be in the
documentation either way.

P.P.S. I apologize if this is something someone familiar with SPI should
just know. My knowledge is a little spotty on this sort of thing.

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com

  parent reply	other threads:[~2010-01-28  4:10 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-20 19:47 (no subject) Ben Gamari
2010-01-21  0:04 ` Ben Dooks
2010-01-21  0:04 ` (no subject) Ben Dooks
2010-01-21  0:04 ` Ben Dooks
2010-01-22 15:53 ` Re: Ben Gamari
2010-01-28  4:10 ` Ben Gamari [this message]
     [not found] ` <1264651770-sup-5197@ben-laptop>
2010-01-28  4:15   ` McSPI questions pertaining to GPIO chip select support Bill Gatliff
2010-01-28  4:25     ` Ben Gamari
2010-01-28  4:27       ` Bill Gatliff
2010-01-28  4:33   ` jassi brar
     [not found]     ` <1b68c6791001272033q60dd31dbif4de285cd9bac83d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-01-29  0:32       ` Ben Gamari
2010-01-29  1:09         ` jassi brar
     [not found]           ` <1b68c6791001281709l7d11da30lee486632e85b99cb-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-01-29  1:58             ` Ben Gamari
2010-12-21 17:56       ` [RFC PATCH] GPIO chip select support for McSPI Ben Gamari
2010-12-21 17:56       ` [PATCH] mcspi: Add support for GPIO chip select lines Ben Gamari
     [not found]     ` <1292954195-20204-2-git-send-email-bgamari.foss@gmail.com>
2010-12-23 19:59       ` Tony Lindgren
2010-12-23 21:38       ` Grant Likely
2010-12-23 23:09         ` Ben Gamari
2010-12-24  0:37           ` Grant Likely
2010-12-24  2:27             ` Ben Gamari
2010-12-24  3:28               ` Grant Likely
2010-12-24  6:05                 ` Ben Gamari
2011-02-12  8:33                   ` Grant Likely
2011-02-13 22:07                     ` Ben Gamari
2011-08-30 10:14   ` McSPI questions pertaining to GPIO chip select support Raju Sana
2011-08-30 13:50     ` Ben Gamari
2011-08-30 13:50       ` [PATCH] mcspi: Add support for GPIO chip select lines Ben Gamari
2011-08-30 13:52       ` [PATCH] beagledaq: Hack in cs_gpios Ben Gamari
     [not found]         ` <1314712343-27367-1-git-send-email-bgamari.foss-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2011-09-05 12:42           ` Raju Sana

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='1264651770-sup-5197__49645.0047860437$1264651881$gmane$org@ben-laptop' \
    --to=bgamari.foss-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=beagleboard-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org \
    --cc=dbrownell-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=eric.miao-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org \
    --cc=linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --subject='Re: McSPI questions pertaining to GPIO chip select support' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).