On Thu, 2005-08-18 at 20:59 +0400, Stas Sergeev wrote:
> The only limitation would be that when the
> speaker driver is enabled in the config,
> the ability to manually select the CONFIG_HZ
> will be lost, but maybe it is not that bad
> at all
CONFIG_HZ is just a short term hack to placate people
Hello.
Lee Revell wrote:
should set CONFIG_HZ to the value I
need at compile-time, and just remove
all the timer reprogramming from the
driver in a hope the dynamic-tick patch
will slow it down itself when necessary?
The current implementations don't allow HZ to go higher than CONFIG_HZ
but tha
On Wed, 2005-08-17 at 21:41 +0400, Stas Sergeev wrote:
> I guess now I realized how you (and Nish)
> assume I could use it: is it that I
> should set CONFIG_HZ to the value I
> need at compile-time, and just remove
> all the timer reprogramming from the
> driver in a hope the dynamic-tick patch
> w
Hello.
Lee Revell wrote:
Lots of things aren't doable with the current timer API, hence all the
recent work on dynamic tick.
I've found only this about the dynamic
tick:
http://lwn.net/Articles/138969/
and it seems that it is intended only
to slow down the interrupts when there
is no work to d
On Wed, 2005-08-17 at 20:21 +0400, Stas Sergeev wrote:
> perhaps allowing a single higher frequency, or allowing just any
> frequency, is pretty much the same task, and doesn't
> look achievable within the currently existing
> timer API anyway
Lots of things aren't doable with the current timer AP
Hello.
Lee Revell wrote:
Wow, your driver implements bass and treble controls by varying the
frequency of the timer interrupt. That's a neat hack, but I'd expect it
to raise a few eyebrows if it's submitted for mainline...
I realized that some time ago, and now,
even though the code it still t
Hello.
Nish Aravamudan wrote:
[PATCH] i386: Selectable Frequency of the Timer Interrupt
but it doesn't look like it ended up
with some patch applied, or where is it?
This thread resulted in CONFIG_HZ. You get to choose between 100, 250
or 1000. It was not meant to allow runtime HZ modifications
On Wed, 2005-08-17 at 00:21 +0400, Stas Sergeev wrote:
> 1. It needs the higher interrupt frequency.
> Since there seem to be no API to change
> the timer frequency at runtime, the driver
> does this itself. Now I have googled out
> the thread
Wow, your driver implements bass and treble controls
On 8/16/05, Stas Sergeev <[EMAIL PROTECTED]> wrote:
> Hello.
>
> john stultz wrote:
> > Interesting. Could you explain why the soft-timer interface doesn't<>
> > suffice?
> I'll try to explain why *I think*
> it doesn't suffice, please correct
> me if my assumptions are wrong.
>
> There are two (
Hello.
john stultz wrote:
Interesting. Could you explain why the soft-timer interface doesn't<>
suffice?
I'll try to explain why *I think*
it doesn't suffice, please correct
me if my assumptions are wrong.
There are two (bad) things about the
PC-Speaker driver:
1. It needs the higher interrupt
On Sat, 2005-08-13 at 17:36 +0400, Stas Sergeev wrote:
> Hello.
>
> Right now it seems like the only interface
> for registering the timer hooks is that one
> of kernel/profile.c, and it is very limited.
> The arch-specific timer hooks are provided
> in an arch-specific headers as a static
> funct
Hello.
Right now it seems like the only interface
for registering the timer hooks is that one
of kernel/profile.c, and it is very limited.
The arch-specific timer hooks are provided
in an arch-specific headers as a static
functions.
Since my driver needs the timer hook, I
thought it might be a go
12 matches
Mail list logo
