Re: [RFC][PATCH] SPI subsystem

From: David Brownell (david-b_at_pacbell.net)
Date: 09/16/05

  • Next message: Arjan van de Ven: "Re: mmap(2)ping of pci_alloc_consistent() allocated buffers on 2.4 kernels question/help"
    Date:	Fri, 16 Sep 2005 11:43:02 -0700
    To: linux-kernel@vger.kernel.org, basicmark@yahoo.com
    
    

    > Thinking about it, for blocking transfers the core
    > could call the adapters transfer routine and then
    > start a wait on completeion. When the message has been
    > sent the adapter would finish the completeion and the
    > call to the core would then return (I think this is
    > how the mmc core layer does it). How do you feel about
    > that sugguestion?

    It resembles some code in my patch, which you included in your reply.
    I've deleted the other parts; see at the end of this message.

    (By the way, you should trim down your email replies and stop re-wrapping
    things to 56-character borders... it breaks attribution prefixes as well
    as patches, and makes your posts hard to read.)

    > How would you feel about having a list head for
    > messages in the adapter structure? I think every
    > adapter driver would at least need this.

    It's just as simple to use:

            struct my_spi_controller {
                    struct spi_master master;
                    struct list_head queue;
                    ... register pointers
                    ... and other controller-private state
            };

    I prefer the information hiding approach. In this case, no code
    outside the controller driver ever has any business looking at that
    queue; they shouldn't even be able to see it. That way there will
    be no temptation to change it and break anything.

    > > As for MMC ... it'll be interesting to watch that
    > > play out; won't the mmc_block code need to change?
    >
    > I don't know, I would hope not. If the mmc core is
    > completely generic then I think I should only have to
    > write a driver like mmci and not have to change the
    > mmc_block or mmc core layers.

    I seem to recall MMC/SD card specs showing different commands are
    used in SPI mode than MMC/SD mode. I'd be (pleasantly) surprised if
    current mmc_block code already understood them. (As I recall, the
    specs from SanDisk were pretty informative.)

    - Dave

    > > +int spi_sync(struct spi_device *spi, struct spi_message *message)
    > > +{
    > > + DECLARE_COMPLETION(done);
    > > + int status;
    > > +
    > > + message->complete = spi_sync_complete;
    > > + message->context = &done;
    > > + status = spi_async(spi, message);
    > > + if (status == 0)
    > > + wait_for_completion(&done);
    > > + message->context = NULL;
    > > + return status;
    > > +}
    > > +EXPORT_SYMBOL(spi_sync);
    -
    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/


  • Next message: Arjan van de Ven: "Re: mmap(2)ping of pci_alloc_consistent() allocated buffers on 2.4 kernels question/help"

    Relevant Pages