[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.1005271852010.3032@localhost.localdomain>
Date: Thu, 27 May 2010 19:00:47 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
cc: Matthew Garrett <mjg59@...f.ucam.org>,
Arve Hjønnevåg <arve@...roid.com>,
Florian Mickler <florian@...kler.org>,
Vitaly Wool <vitalywool@...il.com>,
Peter Zijlstra <peterz@...radead.org>,
LKML <linux-kernel@...r.kernel.org>,
Paul@...p1.linux-foundation.org, felipe.balbi@...ia.com,
Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
Linux PM <linux-pm@...ts.linux-foundation.org>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010, Alan Cox wrote:
> That's all your need to do it right.
>
> In kernel yes your device driver probably does need to say things like
> 'Don't go below C6 for a moment' just as a high speed serial port might
> want to say 'Nothing over 10mS please'
>
> I can't speak for Thomas, but I'm certainly not arguing that you don't
> need something that looks more like the blocker side of the logic *in
> kernel*, because there is stuff that you want to express which isn't tied
> to the task.
I'm not opposed, but yes it needs to be expressed in quantifiable
terms, i.e. wakeup latency. That's just contributing to the global QoS
state of affairs even if it is not tied to a particular task.
And that allows the driver to be intelligent about it. The serial port
at 9600 has definitely different requirements than at 115200.
But that's quite a different concept than the big hammer approach of
the blockers.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists