From: Stephen S. <st...@st...> - 2005-12-14 18:49:06
|
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). |