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

From: Stephen Street
Date: Wed Dec 14 2005 - 13:47:58 EST


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).

In general, the "pump_transfer" and "pump_message" tasklets should
mutually exclusive (anything else is a programming
mistake). I certainly could collapse the tasklets into a single one if
you think this would be better?

> + * 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).


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/