lkml.org 
[lkml]   [2006]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: question on spi_bitbang
    Date

    On Mar 31, 2006, at 1:07 PM, Kumar Gala wrote:

    >
    > On Mar 31, 2006, at 12:11 PM, David Brownell wrote:
    >
    >> On Friday 31 March 2006 9:31 am, Kumar Gala wrote:
    >>> I'm looking at using spi_bitbang for a SPI driver and was trying to
    >>> understand were the right point is to handle MODE switches.
    >>>
    >>> There are 4 function pointers provided for each mode.
    >>
    >> That's if you are indeed "bit banging", or your controller is the
    >> type that's basically a wrapper around a shift register: each
    >> txrx_word() function transfers (or bitbangs) a 1-32 bit word in
    >> the relevant SPI mode (0-3).
    >>
    >> There's also a higher level txrx_bufs() routine for buffer-at-a-time
    >> access, better suited to DMA, FIFOs, and half-duplex hardware.
    >
    > My controller is just a shift register that I can set the
    > characteristics of (bit length for example, reverse data).
    >
    >>> My controller
    >>> HW has a mode register which allows setting clock polarity and clock
    >>> phase. I assume what I want is in my chipselect() function is to
    >>> set
    >>> my mode register and have the four function pointers set to the same
    >>> function.
    >>
    >> I don't know how your particular hardware works, but if you have a
    >> real SPI controller it would probably be more natural to have your
    >> setup() function handle that mode register earlier, out of the main
    >> transfer loop ... unless that mode register is shared among all
    >> chipselects, in which case you'd use the setup_transfer() call for
    >> that, inside the transfer loop. (That call hasn't yet been merged
    >> into the mainline kernel yet; it's in the MM tree.)
    >
    > The mode register is shared between chipselects so I'll go pull the
    > patches from -mm for setup_transfer(). That sounds like the right
    > place for setting my mode register.

    Now that I look at setup_transfer() more I dont think its what I
    want. It's only going to get called if the transfer is different
    from the spi_device() settings. I would seem I would want to
    configure all of my settings in chipselect().

    >> The chipselect() call should only affect the chipselect signal and,
    >> when you're activating a chip, its initial clock polarity. Though
    >> if you're not using the latest from the MM tree, that's also your
    >> hook for ensuring that the SPI mode is set up right.
    >
    > Why deal with just clock polarity and not clock phase as well in
    > chipselect()?
    >
    > It sounds like with the new patch, I'll end up setting txrx_word[]
    > to the same function for all modes.
    >
    > - kumar
    > -
    > To unsubscribe from this list: send the line "unsubscribe linux-
    > kernel" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html
    > Please read the FAQ at http://www.tux.org/lkml/

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-03-31 21:19    [W:0.027 / U:31.256 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site