Re: [PATCH/RFC] SPI: add async message handing library to David Brownell's core

[Vitaly Wool <vwool@ru.mvista.com>]

Stephen Street wrote:

> On Tue, 2005-12-13 at 17:06 +0300, Vitaly Wool wrote:
>  
>
> > Greetings,
> >
> > This thingie hasn't been thoroughly tested yet, but it's lightweight
> > and easy to understand so I don't think solving the problems that 
> > may arise will take long. Though I haven't actually done that yet, 
> > I'm sure that Stephen's PXA SSP driver will become easier to understand 
> > and less in footprint and will work faster when it's rewritten using 
> > this library. (Yes, I do expect performance improvement here as the 
> > current implementation schedules multiple tasklets, so 
> > scheduling penalty is high.)
> >    
>
> Is this really true?  Is tasklet scheduling "harder" than kernal thread
> scheduling?  A close look at my PXA SSP SPI implementation will reveal
> that my design is nearly lock-less and callable from any execution
> context (i.e. interrupt context).
>  
It's harder in your case because the tasklet is created each time it's 
scheduled again, as far as I see it in your impleemntation.
Each SPI controller thread is created only once so it's more lightweight 
than what you do.

> > + * spi_queue - (internal) queue the message to be processed asynchronously
> > + * @spi: SPI device to perform transfer to/from
> > + * @msg: message to be sent
> > + * Description:
> > + * 	This function queues the message to SPI controller's queue.
> > + */
> > +static int spi_queue(struct spi_device *spi, struct spi_message *msg)
> > +{
> > +	struct threaded_async_data *td = spi->master->context;
> > +	int rc = 0;
> > +
> > +	if (!td) {
> > +		rc = -EINVAL;
> > +		goto out;
> > +	}
> > +
> > +	msg->spi = spi;
> > +	down(&td->lock);
> > +	list_add_tail(&msg->queue, &td->msgs);
> > +	dev_dbg(spi->dev.parent, "message has been queued\n");
> > +	up(&td->lock);
> > +	wake_up_interruptible(&td->wq);
> > +
> > +out:
> > +	return rc;
> > +}
> > +
> >    
>
> This can not be invoke this from "interrupt context" which is a
> requirement for my SPI devices (CS8415A, CS8405A, CS4341).
>
>
>  
Okay, not a major issue though. Change mutexes to 
spin_lock_irq/spin_unlock_irq and it's callable from an interrupt 
context, right?

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