On Wed, Jan 25, 2012 at 3:02 PM, Mark Brown <broo...@sirena.org.uk> wrote:
> On Tue, Jan 24, 2012 at 10:14:32PM +0100, Linus Walleij wrote:

>> This switches the PL022 worker to a kthread in order to get
>> hold of a mechanism to control the message pump priority. On
>> low-latency systems elevating the message kthread to realtime
>> priority give a real sleek response curve. This has been
>> confirmed by measurements. Realtime priority elevation for
>> a certain PL022 port can be requested from platform data.
> It really feels like we should be pulling this into the core - lots of
> drivers use a workqueue to drive data through the system and they're all
> going to have exactly the same issue.

That reads to me like the entire message queue and "transfer pump"
mechanism from the PL022 driver should be made into generic
code. That is the key ingredient from the PL022 driver that has
allowed us to get real nice throughput on it.

And that observation is correct, but a bit of upfront code.

If Grant is in on it I might give it a try.

I would make it an opt-in for SPI drivers to have a generic
message queue instead of treating messages in a one-by-one

So say I add to spi/Kconfig that SPI_MASTER:s can define
spi_alloc_queued_master() call with some new
#ifdef SPI_MASTER_QUEUE functions and fields
added to in the struct spi_master to handle this stuff,
and compile in the message pump so that these drivers
does not implement the .transfer() call, but instead
some more fine-grained ones would that fit the bill?

Linus Walleij

Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
spi-devel-general mailing list

Reply via email to