From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> To: "Ducrot Bruno" <ducrot@poupinou.org> Cc: <cpufreq@www.linux.org.uk>, <linux-kernel@vger.kernel.org>, "linux-acpi" <linux-acpi@intel.com>, "Mallick, Asit K" <asit.k.mallick@intel.com>, "Nakajima, Jun" <jun.nakajima@intel.com>, "Dominik Brodowski" <linux@brodo.de> Subject: RE: [PATCH] 1/3 Dynamic cpufreq governor and updates to ACPI P-state driver Date: Tue, 21 Oct 2003 10:15:31 -0700 [thread overview] Message-ID: <88056F38E9E48644A0F562A38C64FB6007791A@scsmsx403.sc.intel.com> (raw) > -----Original Message----- > From: Ducrot Bruno [mailto:ducrot@poupinou.org] > > There is already a patch from Dominik Brodowski for the apci > p-state which IMHO > is better at least by design. Are you referring to cleanup of ACPI P-state driver by Dominik? That patch is indeed nice and clean. But that is mostly orthogonal to this patch. I mean, - SMP awareness in P-state driver - P-state coordination between HT siblings will still be required even after Dominik's patch. Though exact location of these changes will change when applied over Dominik's patch. There is a small overlap in handling MSR based P-state transitions, but that is a real minor change in my patch and I am reusing most of the existing IO based transitions code for MSR based ones. > Your do not handle correctly > other processors > than Intel. I am sorry. I do not understand this comment. - Major part of Patch 1 is adding SMP awareness, which has nothing specific to Intel at all. - A part of patch 1 adds MSR based transition capability. This is based on ACPI spec. It will work any processor that is ACPI compatible and again there are no specific checks for Intel here. > But the HT stuff may be interresting, though. Thanks. -Venkatesh
WARNING: multiple messages have this Message-ID (diff)
From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> To: Ducrot Bruno <ducrot@poupinou.org> Cc: cpufreq@www.linux.org.uk, "Nakajima, Jun" <jun.nakajima@intel.com>, linux-acpi <linux-acpi@intel.com>, "Mallick, Asit K" <asit.k.mallick@intel.com>, linux-kernel@vger.kernel.org, Dominik Brodowski <linux@brodo.de> Subject: RE: [PATCH] 1/3 Dynamic cpufreq governor and updates to ACPI P-state driver Date: Tue, 21 Oct 2003 10:15:31 -0700 [thread overview] Message-ID: <88056F38E9E48644A0F562A38C64FB6007791A@scsmsx403.sc.intel.com> (raw) > -----Original Message----- > From: Ducrot Bruno [mailto:ducrot@poupinou.org] > > There is already a patch from Dominik Brodowski for the apci > p-state which IMHO > is better at least by design. Are you referring to cleanup of ACPI P-state driver by Dominik? That patch is indeed nice and clean. But that is mostly orthogonal to this patch. I mean, - SMP awareness in P-state driver - P-state coordination between HT siblings will still be required even after Dominik's patch. Though exact location of these changes will change when applied over Dominik's patch. There is a small overlap in handling MSR based P-state transitions, but that is a real minor change in my patch and I am reusing most of the existing IO based transitions code for MSR based ones. > Your do not handle correctly > other processors > than Intel. I am sorry. I do not understand this comment. - Major part of Patch 1 is adding SMP awareness, which has nothing specific to Intel at all. - A part of patch 1 adds MSR based transition capability. This is based on ACPI spec. It will work any processor that is ACPI compatible and again there are no specific checks for Intel here. > But the HT stuff may be interresting, though. Thanks. -Venkatesh
next reply other threads:[~2003-10-21 17:15 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-10-21 17:15 Pallipadi, Venkatesh [this message] 2003-10-21 17:15 ` [PATCH] 1/3 Dynamic cpufreq governor and updates to ACPI P-state driver Pallipadi, Venkatesh 2003-10-21 17:55 ` Ducrot Bruno 2003-10-21 17:55 ` Ducrot Bruno 2003-10-21 19:57 ` Dominik Brodowski -- strict thread matches above, loose matches on Subject: below -- 2003-10-22 18:40 Grover, Andrew 2003-10-22 18:40 ` Grover, Andrew 2003-10-21 18:57 Pallipadi, Venkatesh 2003-10-21 18:57 ` Pallipadi, Venkatesh 2003-10-22 9:17 ` Ducrot Bruno 2003-10-22 9:17 ` Ducrot Bruno 2003-10-21 2:56 Pallipadi, Venkatesh 2003-10-21 2:56 ` Pallipadi, Venkatesh 2003-10-21 13:01 ` Ducrot Bruno 2003-10-21 13:01 ` Ducrot Bruno
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=88056F38E9E48644A0F562A38C64FB6007791A@scsmsx403.sc.intel.com \ --to=venkatesh.pallipadi@intel.com \ --cc=asit.k.mallick@intel.com \ --cc=cpufreq@www.linux.org.uk \ --cc=ducrot@poupinou.org \ --cc=jun.nakajima@intel.com \ --cc=linux-acpi@intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@brodo.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.