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>