lkml.org 
[lkml]   [2005]   [Sep]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH] SPI subsystem
> 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/

\
 
 \ /
  Last update: 2005-09-16 20:45    [W:0.061 / U:22.696 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site