From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wolverine01.qualcomm.com ([199.106.114.254]:33602 "EHLO wolverine01.qualcomm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755285Ab0DXC5b (ORCPT ); Fri, 23 Apr 2010 22:57:31 -0400 Message-ID: <4BD25E1A.50505@codeaurora.org> Date: Fri, 23 Apr 2010 19:57:30 -0700 From: Saravana Kannan MIME-Version: 1.0 Subject: Re: CPUfreq - udelay() interaction issues References: <4BCFC3D0.5080904@codeaurora.org> <4BD0D9E5.3020606@codeaurora.org> <20100423184042.GA16190@Krystal> <20100423122259.49e0416a@infradead.org> In-Reply-To: <20100423122259.49e0416a@infradead.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-arm-msm-owner@vger.kernel.org List-ID: To: Arjan van de Ven Cc: Mathieu Desnoyers , cpufreq , linux-arm-msm , Dave Jones , Venkatesh Pallipadi , Thomas Renninger , linux-kernel@vger.kernel.org, Ingo Molnar , Peter Zijlstra Arjan van de Ven wrote: > so in reality, all hardware that does coordination between cores/etc > like this also has a tsc that is invariant of the actual P state. > If there are exceptions, those have a problem, but I can't think of any > right now. > Once the TSC is invariant of P state, udelay() is fine, since that goes > of the tsc, not of some delay loop kind of thing.... I assume you are talking specifically about x86. I want x86 to be correct, but also want ARM to be correct. So, at this point I might as well try to put in an arch independent fix. Thanks, Saravana