From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: cpufreq implementation for OMAP under xen hypervisor. Date: Tue, 30 Sep 2014 13:37:16 -0400 Message-ID: <20140930173716.GA8824@laptop.dumpdata.com> References: <20140910193149.GB2898@laptop.dumpdata.com> <20140926181327.GK5102@laptop.dumpdata.com> <20140929151829.GA31554@laptop.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline 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: Oleksandr Dmytryshyn Cc: Ian Campbell , Stefano Stabellini , jinsong.liu@alibaba-inc.com, Tim Deegan , xen-devel , Jan Beulich , jacob.shin@amd.com, Andrii Tseglytskyi List-Id: xen-devel@lists.xenproject.org On Tue, Sep 30, 2014 at 01:28:42PM +0300, Oleksandr Dmytryshyn wrote: > On Mon, Sep 29, 2014 at 6:18 PM, Konrad Rzeszutek Wilk > wrote: > > > > On Mon, Sep 29, 2014 at 12:45:36PM +0300, Oleksandr Dmytryshyn wrote: > > > On Fri, Sep 26, 2014 at 9:13 PM, Konrad Rzeszutek Wilk > > > wrote: > > > > > > > > > > The architecture looks sane to me. As Konrad pointed out, the difficulty > > > > > > here is to be able to upstream the changes to the Linux driver in 2), > > > > > > that you later in the thread identified as > > > > > > drivers/cpufreq/cpufreq-cpu0.c. > > > > > I'll write driver drivers/xen/xen-cpufreq.c and it replace original > > > > > drivers/cpufreq/cpufreq.c > > > > > And in the original cpufreq-cpu0 driver I'll chande only one string - > > > > > path in the device tree > > > > > with the settings for the CPUs opp: > > > > > string > > > > > np = of_find_node_by_path("/cpus/cpu@0"); > > > > > will changed to: > > > > > np = of_find_node_by_path("/cpus/cpu@0/private_data/cpu@0"); > > > > > > > > > > > If the changes are not invasive and you manage to upstream them in > > > > > > Linux, I am all for this solution. > > > > > In Linux kernel I should make few changes: > > > > > 1. Enable CONFIG_CPU_FREQ_TABLE > > > > > with disabled CONFIG_CPU_FREQ > > > > > 2. Enable CONFIG_GENERIC_CPUFREQ_CPU0 > > > > > with disabled CONFIG_CPU_FREQ > > > > > > > > > > I mean make those configs dependent on > > > > > CONFIG_CPU_FREQ or CONFIX_XEN_DOM0 > > > > > instead of > > > > > CONFIG_CPU_FREQ > > > > > > > > Gosh no. Please make it work runtime. > > > Sorry, Konrad, could You please explain what did You mean. > > > > Don't make XEN options disable other options. > > > > Distributions want one kernel that can satisfi a variety of platforms - not just specifc ones. > XEN option will not disable other options. On the contrary, it will > extend them. In my case XEN option > will allow to select more options. > > Please, see example > diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig > index cbcb21e..4531e04 100644 > --- a/drivers/cpufreq/Kconfig > +++ b/drivers/cpufreq/Kconfig > @@ -15,11 +15,15 @@ config CPU_FREQ > > If in doubt, say N. > > -if CPU_FREQ > +if CPU_FREQ || XEN_DOM0 > > config CPU_FREQ_TABLE > tristate > > @@ -184,6 +188,10 @@ config CPU_FREQ_GOV_CONSERVATIVE > > If in doubt, say N. > > +if CPU_FREQ || XEN_DOM0 > + Ah, then it is fine. Sorry for the misunderstanding. > config GENERIC_CPUFREQ_CPU0 > tristate "Generic CPU0 cpufreq driver" > depends on HAVE_CLK && REGULATOR && PM_OPP && OF