Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 Jan 2004 14:53:10 -0800 (PST)
From:      Nate Lawson <nate@root.org>
To:        Maxim Sobolev <sobomax@portaone.com>
Cc:        cvs-all@FreeBSD.ORG
Subject:   Re: cvs commit: src/sys/i386/i386 p4tcc.c src/sys/conf files.i386  options.i386 src/sys/i386/conf NOTES
Message-ID:  <20040120144950.S98057@root.org>
In-Reply-To: <400DA88B.4070901@portaone.com>
References:  <20040118210712.2B8C616A528@hub.freebsd.org> <20040118220400.M89515@root.org> <400BACBC.9090506@portaone.com> <20040120113536.P96919@root.org> <400DA88B.4070901@portaone.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 21 Jan 2004, Maxim Sobolev wrote:
> Nate Lawson wrote:
>
> > On Mon, 19 Jan 2004, Maxim Sobolev wrote:
> >
> >>Nate Lawson wrote:
> >>
> >>>On Sun, 18 Jan 2004, Maxim Sobolev wrote:
> >>>
> >>>
> >>>> FreeBSD src repository
> >>>>
> >>>> Modified files:
> >>>>   sys/conf             options.i386 files.i386
> >>>>   sys/i386/conf        NOTES
> >>>> Added files:
> >>>>   sys/i386/i386        p4tcc.c
> >>>> Log:
> >>>> Add new CPU_ENABLE_TCC option, from NOTES:
> >>>>
> >>>> CPU_ENABLE_TCC enables Thermal Control Circuitry (TCC) found in some
> >>>> Pentium(tm) 4 and (possibly) later CPUs. When enabled and detected,
> >>>> TCC allows to restrict power consumption by using machdep.cpuperf*
> >>>> sysctls. This operates independently of SpeedStep and is useful on
> >>>> systems where other mechanisms such as apm(4) or acpi(4) don't work.
> >>>>
> >>>> Given the fact that many, even modern, notebooks don't work properly
> >>>> with Intel ACPI, this is indeed very useful option for notebook owners.
> >>>>
> >>>> Obtained from:  OpenBSD
> >>>> MFC after:      2 weeks
> >>>
> >>>I can't seem to see where this was posted before committing.  Please
> >>>coordinate power/thermal management code with me.  I have an upcoming
> >>>cpufreq driver that will encapsulate all of these machdep CPU control
> >>>drivers, including SpeedStep and LongRun.  It's not dependent on ACPI
> >>>although ACPI can use it for passive cooling.  Also, your driver should
> >>>use /etc/power_profile to set a sysctl, not proliferate
> >>>performance/economy sysctls.  Drop me a private email and we can figure
> >>>out how to coordinate.
> >>
> >>Sorry, I did not know that you are working on this. Please feel free to
> >>take p4tcc support and integrate it into your framework.
> >
> >
> > When I merge in the cpufreq layer, I will convert existing drivers to use
> > it, including yours.  For instance, we already have a LongRun driver.  At
> > a minimum, I ask that you change the sysctl from "machdep.cpuperf.*" to
> > "machdep.p4tcc.*" or whatever since cpuperf is too generic a term for a
> > P4-only driver.  This will also make RELENG_4 less ambiguous if you MFC
> > it.  I hope to have cpufreq committed before 5.3 and thus the p4tcc
> > sysctls won't make it into a release.
>
> Ok, will do. BTW, I really dislike the way how LongRun power driver is
> plastered into identcpu.c - it really doesn't belong there. At the very
> least, it should be conditionalised in I686_CPU or whatever CPU class
> crusoe belongs. Also it should be opt-in, not mandatory, since it is
> uselless to 99.9% of our users anyway.

I agree.  If you have time to move it into its own .c file, I'd appreciate
it.  If not, that surgery will be part of my work eventually.  I'll be
repo-copying all the separate CPU speed drivers into sys/${ARCH}/cpufreq
once the machine-independent sys/dev/cpufreq is committed.  I'll post
patches once I have it working.  This work depends on cpus getting newbus
attachments, which is complicating things a little.

-Nate



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040120144950.S98057>