From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrii Tseglytskyi Subject: Re: cpufreq implementation for OMAP under xen hypervisor. Date: Tue, 2 Sep 2014 18:43:41 +0300 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: Ian Campbell , jinsong.liu@alibaba-inc.com, Oleksandr Dmytryshyn , jacob.shin@amd.com, Tim Deegan , Jan Beulich , xen-devel List-Id: xen-devel@lists.xenproject.org On Tue, Sep 2, 2014 at 4:00 AM, Stefano Stabellini wrote: > On Fri, 29 Aug 2014, Andrii Tseglytskyi wrote: >> Hi, >> >> Stefano, Ian, >> >> Could you please clarify the following point: >> >> I agree that decision about frequency change should be taken by Xen >> hypervisor. But what about hardware frequency changing? >> In general when frequency changed to bigger value (for example from 1 >> GHz to 1.5 GHz) for ARM kernels sequence looks like the following: >> >> 1) cpufreq governor decides that frequency should be changed. This >> decision is taken after analysing of CPU performance data taking in >> account governor policy. >> 2) cpufreq governor asks cpufreq driver about new frequency. >> 3) cpufreq driver compares current and target frequencies and asks >> cpufreq regulator about voltage change. >> 4) cpufreq regulator send i2c command to standalone microchip, which >> is responsible for voltage changing. >> 5) cpufreq driver asks clock framework about new frequency for CPU clock >> 6) clock framework performs frequency sanity checks, taking in account >> clock parents and clock divider settings, and call platform specific >> "set_frequency" callback. >> 7) platform specific callback performs proper HW registers >> configuration for newly selected frequency >> >> Also there are some special cases - for example for OMAP5+ when >> frequency is changed to 1.5 GHz+, two additional HW IPs should be >> triggered (ABB and DCC, if someone is familiar with OMAP5+ ) >> >> So, for generic ARM kernel we have 3 entities to change frequency: >> >> - cpufreq governor >> - cpufreq driver >> - cpufreq regulator >> >> + 2 additional IP for OMAP5+ >> - ABB >> - DCC >> >> Taking in account all above, it looks like it would be better to >> implement only Xen cpufreq governor. Xen will take a decision about >> new frequency, and kernel dom0 will perform other steps. Dom0 contains >> all generic and platform specific frameworks, needed for frequency >> changing. >> >> What do you think ? > > Keep in mind that the architecture must be able to handle the case where > dom0 has only 1 or 2 vcpus on a 4 or 8 cores system with multiple > physical cpus. > Could dom0 change the frequency of a physical core or a physical cpu is > not even running on? If that is not a problem, because cpus and > frequency changing are decoupled enough in Linux to allow it, then I am > OK with it. But I suspect they are not. > Not sure that I got your point correctly - dom0 will change frequency on physical CPU. And in case of OMAP - this changing affects on both ARM physical cpus - changing is coupled. In case of other ARM platforms - changing may be not coupled (I've heard that Snapdragon can change cpu freqs independently on each physical cpu) Regrads, Andrii -- Andrii Tseglytskyi | Embedded Dev GlobalLogic www.globallogic.com