From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexey Starikovskiy Subject: Re: [PATCH 8/8] acpi-cpufreq: skip duplicate frequencies Date: Fri, 04 Aug 2006 12:24:31 +0400 Message-ID: <44D3043F.3060504@linux.intel.com> References: Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: cpufreq-bounces@lists.linux.org.uk Errors-To: cpufreq-bounces+glkc-cpufreq=m.gmane.org+glkc-cpufreq=m.gmane.org@lists.linux.org.uk Content-Type: text/plain; charset="us-ascii" To: "Pallipadi, Venkatesh" Cc: cpufreq@lists.linux.org.uk, Dave Jones Pallipadi, Venkatesh wrote: >>> I guess we should compact the whole table rather than adding INVALID >>> entries. With INVALID entries, we may end up running some redundant >>> loops table_verify table_target functions later. >>> >>> Thanks, >>> Venki >>> >> there can be inconsistency then BIOS issues notifies, if we >> change number of P-states. >> Keeping them INVALID is safer. >> > > But, BIOS notification only checks the perf->states structure and does > not depend on frequency table. Right? > Also, if notification depends on freq table, we will still have a issue > with this patch and number_of_P-states_change notification. > Say we have - 3 GHz, 3 GHz, 3 GHz, 2 GHz as P0, P1, P2, and P3 reported > by BIOS. And it says P2 as the highest frequency through notify. This > patch would have made P1 and P2 frequency as INVALID. BIOS knows that there are 4 P-states, 3 of them being equal (it populated these values after all). So if it says we need to set limit to upper 2 equal states -- it is BIOS bug (feature).