lkml.org 
[lkml]   [2005]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 2.6-git] SPI core refresh
    From
    Date
    On Thu, 2005-12-01 at 19:11 +0300, Vitaly Wool wrote:
    > Again, some advantages of our core compared to David's I'd like to mention
    >
    > - it can be compiled as a module
    > - it is priority inversion-free
    > - it can gain more performance with multiple controllers
    > - it's more adapted for use in real-time environments
    > - it's not so lightweight, but it leaves less effort for the bus driver developer.
    >
    > (As a response to the last bullet David claims that we limit the flexibility. It's not correct.
    > The core method for message retrieval is just a default one and can easily be overridden by the bus driver. It's a common practice, for instance, see MTD/NAND interface.)
    >
    > It's also been proven to work on SPI EEPROMs and SPI WiFi module (the latter was a really good survival test! :)).

    I have a question about your proposed core. But first a little
    background:

    My board has a 3 Cirrus Logic SPI devices (CS8415A, CS8405A and a
    CS4341) connected to a PXA255 NSSP port. I have implemented the PXA2xx
    NSSP SPI driver with DMA support using Davids framework and implemented
    an working CS8415A driver.

    Page 18 of the CS8415A data sheet discusses the SPI IO operation. Three
    paragraphs and 1 timing diagram.

    http://www.cirrus.com/en/pubs/proDatasheet/CS8415A_F4.pdf

    The critical things to get from the datasheet are:

    1) The chip has an internal register file pointer MAP which must be
    positioned before write and read register operations.

    2) The MAP has a auto-increment feature.

    3) Register writes can be performed in one chip select cycles while
    register reads MAY require a MAP write cycle first and thus require two
    chip select cycles.

    Now assume the CS8415A register operations will be generated from two
    different sources: "process context" and "interrupt context". This
    assumption forces a "guaranteed message order" requirement onto the IO
    Model because of the possibility that an "interrupt context" will move
    the MAP in between an "process context" write MAP message and read
    register message. If this is not clear, let me know because it is
    important.

    I'm using David's SPI IO model to enforce "guaranteed message order" by
    building multiple write/read transfers in a single SPI message which is
    guaranteed execute in the correct order.

    How do I accomplish the same with your core?

    -Stephen





    -
    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: 2005-12-01 19:07    [W:4.438 / U:0.120 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site