On Tue, 2005-12-13 at 17:06 +0300, Vitaly Wool wrote: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.
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).
Okay, not a major issue though. Change mutexes to spin_lock_irq/spin_unlock_irq and it's callable from an interrupt context, right?+ * 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).