Re: [RFC][PATCH] SPI subsystem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux