Re: [PATCH/RFC] SPI core: turn transfers to be linked list

[David Brownell <david-b@pacbell.net>]

On Wednesday 21 December 2005 5:22 am, Vitaly Wool wrote:
> David Brownell wrote:
> 
> >>The list setting commands are pretty essential and will not add a lot to 
> >>the assembly code.
> >
> >I'm not totally averse to such changes, but you don't seem to be making
> >the best arguments.  Example:  they're clearly not "essential" because
> >transfer queues work today with the lists at the spi_message level.
> 
> One more reason for that that came out only recently: suppore we're 
> adding transfers to an already configured message (i. e. with some 
> transfers set up already). This 'chaning' may happen for some kinds of 
> devices.

What would those devices be?  Have you looked at how, say, 802.15.4
wireless stacks would need to work?  I'm thinking those will be
interesting for some embedded Linux folk.  There are probably at least
half a dozen such Zigbee-capable radio chips that hook up through SPI,
and they're not always hooked up to 8-bit CPUs!


By the way, I'd say the framework already chains transfers, and what
you're proposing is that drivers be able to do so more flexibly.


> And in case transfers is an array, we should either be apriory  
> aware of whether the chaining will take place or allocate an array large 
> enough to hold additional transfers. Neither of these look good to me, 
> and having a linked list of transfers will definitely solve this problem.

Well, that's the guts of the good example I was hoping you would share.
I'll be posting a refresh of this code soonish; maybe you can provide 
a complete patch, changing all the code over to use list-not-array?

My own reasons for liking the notion of spi_transfer list membership
are to enable such transfer shuffling within the controller drivers,
more than at the spi_device driver level.  If both layers will see some
benefits, then it's likely a good change.  ;)

- Dave
-
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/