From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stratos Karafotis Subject: Re: [PATCH v5 0/8] Introduce new cpufreq helper macros Date: Tue, 06 May 2014 20:55:22 +0300 Message-ID: <5369220A.3030207@semaphore.gr> References: <535AC247.3070907@semaphore.gr> <535FCDBD.6080500@semaphore.gr> <1621123.rMC9JtD3Mo@vostro.rjw.lan> Mime-Version: 1.0 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: Sender: cpufreq-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="utf-8" To: Geert Uytterhoeven , "Rafael J. Wysocki" Cc: Viresh Kumar , Jesper Nilsson , Hans-Christian Egtvedt , Dirk Brandewie , "linux-doc@vger.kernel.org" , "cpufreq@vger.kernel.org" , "linux-pm@vger.kernel.org" , LKML , Randy Dunlap , "David S. Miller" , Linus Walleij , Simon Horman , Sekhar Nori , Samuel Ortiz , Linux-sh list Hi all, On 06/05/2014 06:24 =CE=BC=CE=BC, Geert Uytterhoeven wrote: > Hi Stratos, >=20 > On Wed, Apr 30, 2014 at 12:26 AM, Rafael J. Wysocki wrote: >> On Tuesday, April 29, 2014 07:05:17 PM Stratos Karafotis wrote: >>> On 29/04/2014 07:17 =CF=80=CE=BC, Viresh Kumar wrote: >>>> On 26 April 2014 01:45, Stratos Karafotis = wrote: >>>>> This patch set introduces two freq_table helper macros which >>>>> can be used for iteration over cpufreq_frequency_table and >>>>> makes the necessary changes to cpufreq core and drivers that >>>>> use such an iteration procedure. >>>>> >>>>> The motivation was a usage of common procedure to iterate over >>>>> cpufreq_frequency_table across all drivers and cpufreq core. >>>>> >>>>> This was tested on a x86_64 platform. >>>>> Most files compiled successfully but unfortunately I was not >>>>> able to compile sh_sir.c pasemi_cpufreq.c and ppc_cbe_cpufreq.c >>>>> due to lack of cross compiler. >>>>> >>>>> Changelog >>>>> >>>>> v4 -> v5 >>>>> - Fix warnings in printk format specifier for 32 bit >>>>> architectures in freq_table.c, longhaul, pasemi, ppc_cb= e >>>> >>>> Doesn't look much has changed and so it stays as is: >>>> >>>> Acked-by: Viresh Kumar >>>> >>> >>> Thank you very much! >> >> I've applied the series to my bleeding-edge branch, will move it to = linux-next >> after build testing later this week. >=20 > This breaks if CONFIG_CPU_FREQ=3Dn, e.g. ARM/shmobile/koelsch/ > non-multiplatform: >=20 > drivers/built-in.o: In function `clk_round_parent': > clkdev.c:(.text+0xcf168): undefined reference to `cpufreq_next_valid' > drivers/built-in.o: In function `clk_rate_table_find': > clkdev.c:(.text+0xcf820): undefined reference to `cpufreq_next_valid' > make[3]: *** [vmlinux] Error 1 >=20 > drivers/sh/clk/core.c (pre-CCF shmobile clock core) calls > cpufreq_for_each_valid_entry(): >=20 > #define cpufreq_for_each_valid_entry(pos, table) \ > for (pos =3D table; cpufreq_next_valid(&pos); pos++) >=20 > but cpufreq_next_valid() in drivers/cpufreq/cpufreq.c is not > compiled in. My bad. I'm sorry for this. :( Rafael, A solution could be to make cpufreq_next_valid an inline function in cp= ufreq.h, but as Viresh mentioned this would be very inefficient because of multi= ple copies. So, maybe it's better to revert the 2 patches that don't depend on CONF= IG_CPU_FREQ: 4229e1c61a4a ("sh: clk: Use cpufreq_for_each_valid_entry macro for iter= ation") and 04ae58645afa ("irda: sh_sir: Use cpufreq_for_each_valid_entry macro for= iteration"). Do I need to send revert patches for the above? Thanks, Stratos From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stratos Karafotis Date: Tue, 06 May 2014 17:55:22 +0000 Subject: Re: [PATCH v5 0/8] Introduce new cpufreq helper macros Message-Id: <5369220A.3030207@semaphore.gr> List-Id: References: <535AC247.3070907@semaphore.gr> <535FCDBD.6080500@semaphore.gr> <1621123.rMC9JtD3Mo@vostro.rjw.lan> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: Geert Uytterhoeven , "Rafael J. Wysocki" Cc: Viresh Kumar , Jesper Nilsson , Hans-Christian Egtvedt , Dirk Brandewie , "linux-doc@vger.kernel.org" , "cpufreq@vger.kernel.org" , "linux-pm@vger.kernel.org" , LKML , Randy Dunlap , "David S. Miller" , Linus Walleij , Simon Horman , Sekhar Nori , Samuel Ortiz , Linux-sh list Hi all, On 06/05/2014 06:24 μμ, Geert Uytterhoeven wrote: > Hi Stratos, > > On Wed, Apr 30, 2014 at 12:26 AM, Rafael J. Wysocki wrote: >> On Tuesday, April 29, 2014 07:05:17 PM Stratos Karafotis wrote: >>> On 29/04/2014 07:17 πμ, Viresh Kumar wrote: >>>> On 26 April 2014 01:45, Stratos Karafotis wrote: >>>>> This patch set introduces two freq_table helper macros which >>>>> can be used for iteration over cpufreq_frequency_table and >>>>> makes the necessary changes to cpufreq core and drivers that >>>>> use such an iteration procedure. >>>>> >>>>> The motivation was a usage of common procedure to iterate over >>>>> cpufreq_frequency_table across all drivers and cpufreq core. >>>>> >>>>> This was tested on a x86_64 platform. >>>>> Most files compiled successfully but unfortunately I was not >>>>> able to compile sh_sir.c pasemi_cpufreq.c and ppc_cbe_cpufreq.c >>>>> due to lack of cross compiler. >>>>> >>>>> Changelog >>>>> >>>>> v4 -> v5 >>>>> - Fix warnings in printk format specifier for 32 bit >>>>> architectures in freq_table.c, longhaul, pasemi, ppc_cbe >>>> >>>> Doesn't look much has changed and so it stays as is: >>>> >>>> Acked-by: Viresh Kumar >>>> >>> >>> Thank you very much! >> >> I've applied the series to my bleeding-edge branch, will move it to linux-next >> after build testing later this week. > > This breaks if CONFIG_CPU_FREQ=n, e.g. ARM/shmobile/koelsch/ > non-multiplatform: > > drivers/built-in.o: In function `clk_round_parent': > clkdev.c:(.text+0xcf168): undefined reference to `cpufreq_next_valid' > drivers/built-in.o: In function `clk_rate_table_find': > clkdev.c:(.text+0xcf820): undefined reference to `cpufreq_next_valid' > make[3]: *** [vmlinux] Error 1 > > drivers/sh/clk/core.c (pre-CCF shmobile clock core) calls > cpufreq_for_each_valid_entry(): > > #define cpufreq_for_each_valid_entry(pos, table) \ > for (pos = table; cpufreq_next_valid(&pos); pos++) > > but cpufreq_next_valid() in drivers/cpufreq/cpufreq.c is not > compiled in. My bad. I'm sorry for this. :( Rafael, A solution could be to make cpufreq_next_valid an inline function in cpufreq.h, but as Viresh mentioned this would be very inefficient because of multiple copies. So, maybe it's better to revert the 2 patches that don't depend on CONFIG_CPU_FREQ: 4229e1c61a4a ("sh: clk: Use cpufreq_for_each_valid_entry macro for iteration") and 04ae58645afa ("irda: sh_sir: Use cpufreq_for_each_valid_entry macro for iteration"). Do I need to send revert patches for the above? Thanks, Stratos