Re: [PATCH] spi: Driver for GPIO controlled SPI multiplexer

[Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>]

On Sun, 3 Mar 2013 15:42:39 +0800, Mark Brown <broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org> wrote:
> On Sat, Mar 02, 2013 at 05:32:44PM +0000, Grant Likely wrote:
> 
> > Mark commented on this too, but I disagree with him on one point; it
> > will actually be simpler if you finish up the transfer in the callback,
> > and that it really should be implemented that way from day one.
> 
> > xfer_complete and xfer_complete_wq can be dropped, and
> > child_mesg_complete, child_mesg_context and child_mesg_dev will move
> > into struct spi_mux_gpio.
> 
> I agree with this, I was just thinking that the waitqueue looked like a
> first stage in allowing multiple in flight transfers on the parent.
> Unless I'm missing something, I didn't think too deeply about
> implementing that, it's just that it's going to be needed at some point
> as it's so important for performance.

Alright, I'll bite. How? What's the scenario where the driver will need
to manage the wait queue directly? The point of the transfer_one_message
interface was pull queue management into the core and allow the driver
to get the next message just when it needs it.

g.

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb