Re: [PATCH 8/9] PCI: hotplug: Embed hotplug_slot

struct. The "private" pointer in struct hotplug_slot thereby becomes > unused, so drop it. > > Signed-off-by: Lukas Wunner > Cc: Rafael J. Wysocki > Cc: Len Brown > Cc: Scott Murray > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: Michael Ellerman

Re: [PATCH 7/9] PCI: hotplug: Drop hotplug_slot_info

> once on probe. That seems unlikely to me, still maintainers should > review the changes carefully for this possibility. I'm not aware of any case in which it will break anything, so Reviewed-by: Rafael J. Wysocki but if that happens, it may be necessary to add the execution of the control methods in question directly to the initialization part.

Re: [PATCH 6/9] PCI: hotplug: Constify hotplug_slot_ops

const. It can be > converted to __write_rarely once that's mainlined: > http://www.openwall.com/lists/kernel-hardening/2016/11/16/3 > > Signed-off-by: Lukas Wunner > Cc: Rafael J. Wysocki > Cc: Len Brown > Cc: Scott Murray > Cc: Benjamin Herrenschmidt > Cc: Paul Macker

Re: [PATCH RFC 1/2] drivers/base: export lock_device_hotplug/unlock_device_hotplug

On Fri, Aug 17, 2018 at 10:56 AM David Hildenbrand wrote: > > On 17.08.2018 10:41, Greg Kroah-Hartman wrote: > > On Fri, Aug 17, 2018 at 09:59:00AM +0200, David Hildenbrand wrote: > >> From: Vitaly Kuznetsov > >> > >> Well require to call add_memory()/add_memory_resource() with > >>

Re: [PATCH RFC 1/2] drivers/base: export lock_device_hotplug/unlock_device_hotplug

On Fri, Aug 17, 2018 at 10:41 AM Greg Kroah-Hartman wrote: > > On Fri, Aug 17, 2018 at 09:59:00AM +0200, David Hildenbrand wrote: > > From: Vitaly Kuznetsov > > > > Well require to call add_memory()/add_memory_resource() with > > device_hotplug_lock held, to avoid a lock inversion. Allow

Re: [PATCH RFC 2/2] mm/memory_hotplug: fix online/offline_pages called w.o. mem_hotplug_lock

On Fri, Aug 17, 2018 at 9:59 AM David Hildenbrand wrote: > > There seem to be some problems as result of 30467e0b3be ("mm, hotplug: > fix concurrent memory hot-add deadlock"), which tried to fix a possible > lock inversion reported and discussed in [1] due to the two locks > a)

Re: [PATCHv3 0/4] drivers/base: bugfix for supplier<-consumer ordering in device_kset

On Mon, Jul 9, 2018 at 10:40 AM, Pingfan Liu wrote: > On Mon, Jul 9, 2018 at 3:48 PM Rafael J. Wysocki wrote: >> >> On Mon, Jul 9, 2018 at 8:48 AM, Pingfan Liu wrote: >> > On Sun, Jul 8, 2018 at 4:25 PM Rafael J. Wysocki wrote: [cut] >> >> I simpl

Re: [PATCHv3 0/4] drivers/base: bugfix for supplier<-consumer ordering in device_kset

On Mon, Jul 9, 2018 at 8:48 AM, Pingfan Liu wrote: > On Sun, Jul 8, 2018 at 4:25 PM Rafael J. Wysocki wrote: >> >> On Sat, Jul 7, 2018 at 6:24 AM, Pingfan Liu wrote: >> > On Fri, Jul 6, 2018 at 9:55 PM Pingfan Liu wrote: >> >> >> >>

Re: [PATCHv3 0/4] drivers/base: bugfix for supplier<-consumer ordering in device_kset

On Sat, Jul 7, 2018 at 6:24 AM, Pingfan Liu wrote: > On Fri, Jul 6, 2018 at 9:55 PM Pingfan Liu wrote: >> >> On Fri, Jul 6, 2018 at 4:47 PM Rafael J. Wysocki wrote: >> > >> > On Fri, Jul 6, 2018 at 10:36 AM, Lukas Wunner wrote: >> > > [cc += Kisho

Re: [PATCHv3 2/4] drivers/base: utilize device tree info to shutdown devices

On Friday, July 6, 2018 5:02:15 AM CEST Pingfan Liu wrote: > On Thu, Jul 5, 2018 at 6:13 PM Rafael J. Wysocki wrote: > > > > On Tuesday, July 3, 2018 8:50:40 AM CEST Pingfan Liu wrote: > > > commit 52cdbdd49853 ("driver core: correct device's shutdown order

Re: [PATCHv3 0/4] drivers/base: bugfix for supplier<-consumer ordering in device_kset

On Fri, Jul 6, 2018 at 10:36 AM, Lukas Wunner wrote: > [cc += Kishon Vijay Abraham] > > On Thu, Jul 05, 2018 at 11:18:28AM +0200, Rafael J. Wysocki wrote: >> OK, so calling devices_kset_move_last() from really_probe() clearly is >> a mistake. >> >> I'm n

Re: [PATCHv3 2/4] drivers/base: utilize device tree info to shutdown devices

ut all out-of-order item in > "affected range". To avoid such complicated code, this patch suggests > to utilize the info in device tree, instead of using the order of > devices_kset during shutdown. It iterates the device tree, and firstly > shutdown a device's children and

Re: [PATCHv3 0/4] drivers/base: bugfix for supplier<-consumer ordering in device_kset

On Thu, Jul 5, 2018 at 4:44 AM, Pingfan Liu wrote: > On Wed, Jul 4, 2018 at 6:23 PM Rafael J. Wysocki wrote: >> >> On Wednesday, July 4, 2018 4:47:07 AM CEST Pingfan Liu wrote: >> > On Tue, Jul 3, 2018 at 10:36 PM Rafael J. Wysocki >> > wrote: >> > &g

Re: [PATCH v3 0/2] powernv/cpuidle Device-tree parsing cleanup

On Tuesday, July 3, 2018 11:20:54 AM CEST Akshay Adiga wrote: > > Device-tree parsed multiple time in powernv cpuidle and powernv > hotplug code. > > First to identify supported flags. Second time, to identify deepest_state > and first deep state. Third time, during cpuidle init to find the

Re: [PATCHv3 0/4] drivers/base: bugfix for supplier<-consumer ordering in device_kset

On Wednesday, July 4, 2018 4:47:07 AM CEST Pingfan Liu wrote: > On Tue, Jul 3, 2018 at 10:36 PM Rafael J. Wysocki wrote: > > > > On Tuesday, July 3, 2018 8:50:38 AM CEST Pingfan Liu wrote: > > > commit 52cdbdd49853 ("driver core: correct device's shutdown order

Re: [PATCHv3 3/4] drivers/base: clean up the usage of devices_kset_move_last()

On Wednesday, July 4, 2018 6:40:09 AM CEST Pingfan Liu wrote: > On Tue, Jul 3, 2018 at 10:28 PM Rafael J. Wysocki wrote: > > > > On Tuesday, July 3, 2018 8:50:41 AM CEST Pingfan Liu wrote: > > > Clean up the referring to the code in commit 52cdbdd49853 ("driver

Re: [PATCHv3 0/4] drivers/base: bugfix for supplier<-consumer ordering in device_kset

On Tuesday, July 3, 2018 8:50:38 AM CEST Pingfan Liu wrote: > commit 52cdbdd49853 ("driver core: correct device's shutdown order") > places an assumption of supplier<-consumer order on the process of probe. > But it turns out to break down the parent <- child order in some scene. > E.g in pci, a

Re: [PATCHv3 3/4] drivers/base: clean up the usage of devices_kset_move_last()

On Tuesday, July 3, 2018 8:50:41 AM CEST Pingfan Liu wrote: > Clean up the referring to the code in commit 52cdbdd49853 ("driver core: > correct device's shutdown order"). So later we can revert it safely. > > Cc: Greg Kroah-Hartman > Cc: Rafael J. Wysocki >

Re: [trivial PATCH V2] treewide: Align function definition open/close braces

drew Morton picks this up. > > V2: Remove fs/xfs/libxfs/xfs_alloc.c as it's updated and remerge the rest > > arch/x86/include/asm/atomic64_32.h | 2 +- > drivers/acpi/custom_method.c | 2 +- > drivers/acpi/fan.c | 2 +- For the ACPI changes: Acked-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Re: Linux 4.16: Reported regressions as of Monday, 2018-02-26 (Was: Linux 4.16-rc3)

On Monday, February 26, 2018 11:25:09 AM CET Thorsten Leemhuis wrote: > On 26.02.2018 04:05, Linus Torvalds wrote: > > We're on the normal schedule for 4.16 and everything still looks very > > regular. > > Hi! Find below my second regression report for Linux 4.16. It lists 8 > regressions I'm

Re: [PATCH] cpufreq: powernv: Check negative value returned by cpufreq_table_find_index_dl()

On Mon, Feb 12, 2018 at 11:33 AM, Shilpasri G Bhat wrote: > Hi, > > On 02/12/2018 03:59 PM, Viresh Kumar wrote: >> On 12-02-18, 15:51, Shilpasri G Bhat wrote: >>> This patch fixes the below Coverity warning: >>> >>> *** CID 182816: Memory - illegal accesses

Re: [PATCH] cpufreq: powernv: Check negative value returned by cpufreq_table_find_index_dl()

On Wed, Feb 21, 2018 at 2:13 PM, Michael Ellerman <m...@ellerman.id.au> wrote: > "Rafael J. Wysocki" <raf...@kernel.org> writes: > >> On Wed, Feb 21, 2018 at 6:54 AM, Viresh Kumar <viresh.ku...@linaro.org> >> wrote: >>> On 21-02-18, 16:3

Re: [PATCH] cpufreq: powernv: Check negative value returned by cpufreq_table_find_index_dl()

On Wed, Feb 21, 2018 at 11:02 AM, Viresh Kumar <viresh.ku...@linaro.org> wrote: > On 21-02-18, 10:27, Rafael J. Wysocki wrote: >> To be precise, ->init() should fail as that's where the table is >> created. The registration fails as a result then. >> >>

Re: [PATCH] cpufreq: powernv: Check negative value returned by cpufreq_table_find_index_dl()

On Wed, Feb 21, 2018 at 6:54 AM, Viresh Kumar wrote: > On 21-02-18, 16:39, Michael Ellerman wrote: >> Viresh Kumar writes: > >> > AFAICT, you will get -1 here only if the freq table had no valid >> > frequencies (or the freq table is empty). Why

Re: [PATCH v3] cpufreq: powernv: Add support of frequency domain

On Monday, January 22, 2018 9:17:34 AM CET Abhishek Goel wrote: > Frequency-domain indicates group of CPUs that would share same frequency. > It is detected using device-tree node "frequency-domain-indicator". > frequency-domain-indicator is a bitmask which will have different value > depending

Re: [v3 PATCH 2/3] powernv-cpufreq: Fix pstate_to_idx() to handle non-continguous pstates

On Wednesday, January 10, 2018 9:55:45 AM CET Gautham R Shenoy wrote: > Hi Rafael, > > On Wed, Jan 03, 2018 at 11:47:58PM +1100, Balbir Singh wrote: > > On Wed, Jan 3, 2018 at 11:07 PM, Rafael J. Wysocki <r...@rjwysocki.net> > > wrote: > > > On Monday, Decemb

Re: [v3 PATCH 2/3] powernv-cpufreq: Fix pstate_to_idx() to handle non-continguous pstates

On Monday, December 18, 2017 9:38:20 AM CET Gautham R Shenoy wrote: > Hi Balbir, > > On Sun, Dec 17, 2017 at 02:15:25PM +1100, Balbir Singh wrote: > > On Wed, Dec 13, 2017 at 5:57 PM, Gautham R. Shenoy > > wrote: > > > From: "Gautham R. Shenoy"

Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT

On Sat, Dec 23, 2017 at 12:57 AM, Dan Williams wrote: > On Fri, Dec 22, 2017 at 3:22 PM, Ross Zwisler > wrote: >> On Fri, Dec 22, 2017 at 02:53:42PM -0800, Dan Williams wrote: >>> On Thu, Dec 21, 2017 at 12:31 PM, Brice Goglin

Re: [trivial PATCH] treewide: Align function definition open/close braces

t raid6_calls raid6_sse2x2 = { > raid6_sse22_gen_syndrome, > @@ -366,9 +366,9 @@ static void raid6_sse24_gen_syndrome(int disks, size_t > bytes, void **ptrs) > kernel_fpu_end(); > } > > - static void raid6_sse24_xor_syndrome(int disks, int start, int stop, > +static void raid6_sse24_xor_syndrome(int disks, int start, int stop, >size_t bytes, void **ptrs) > - { > +{ > u8 **dptr = (u8 **)ptrs; > u8 *p, *q; > int d, z, z0; > @@ -471,7 +471,7 @@ static void raid6_sse24_gen_syndrome(int disks, size_t > bytes, void **ptrs) > } > asm volatile("sfence" : : : "memory"); > kernel_fpu_end(); > - } > +} > > > const struct raid6_calls raid6_sse2x4 = { > diff --git a/sound/soc/fsl/fsl_dma.c b/sound/soc/fsl/fsl_dma.c > index 0c11f434a374..ec619f51d336 100644 > --- a/sound/soc/fsl/fsl_dma.c > +++ b/sound/soc/fsl/fsl_dma.c > @@ -879,7 +879,7 @@ static const struct snd_pcm_ops fsl_dma_ops = { > }; > > static int fsl_soc_dma_probe(struct platform_device *pdev) > - { > +{ > struct dma_object *dma; > struct device_node *np = pdev->dev.of_node; > struct device_node *ssi_np; > > -- Acked-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com> for the ACPI part. Thanks!

Re: [v2 PATCH] cpufreq: powernv: Correctly parse the sign of pstates on POWER8 vs POWER9

On Fri, Dec 8, 2017 at 12:47 PM, Michael Ellerman <m...@ellerman.id.au> wrote: > "Rafael J. Wysocki" <raf...@kernel.org> writes: > >> On Thu, Dec 7, 2017 at 6:59 AM, Gautham R. Shenoy >> <e...@linux.vnet.ibm.com> wrote: >>> From: "Gau

Re: [v2 PATCH] cpufreq: powernv: Correctly parse the sign of pstates on POWER8 vs POWER9

On Thu, Dec 7, 2017 at 6:59 AM, Gautham R. Shenoy wrote: > From: "Gautham R. Shenoy" > > On POWERNV platform, Pstates are 8-bit values. On POWER8 they are > negatively numbered while on POWER9 they are positively > numbered. Thus, on POWER9, the

Re: Linux 4.14: Reported regressions as of Sunday, 2017-10-08

On Sunday, October 8, 2017 2:37:41 PM CEST Thorsten Leemhuis wrote: > Hi! Find below my second regression report for Linux 4.14. It lists 8 > regressions I'm currently aware of. One regression was fixed since last > weeks report. One was in there that shouldn't have been there. > > As always: Are

Re: [PATCH 03/13] timer: Remove init_timer_on_stack() in favor of timer_setup_on_stack()

-to-one mapping > of parent structure to timer, those are switched to using timer_setup() > instead. All related callbacks were adjusted to use from_timer(). > > Cc: "Rafael J. Wysocki" <r...@rjwysocki.net> > Cc: Pavel Machek <pa...@ucw.cz> > Cc: Len Br

Re: [PATCH V3 0/9] cpufreq: transition-latency cleanups

On Wednesday, July 19, 2017 03:42:40 PM Viresh Kumar wrote: > Hi Rafael, > > This series tries to cleanup the code around transition-latency and its > users. Some of the old legacy code, which may not make much sense now, > is dropped as well. And some code consolidation is also done across >

Re: [1/3] cpuidle: powerpc: cpuidle set polling before enabling irqs

On Fri, Jun 30, 2017 at 5:45 AM, Michael Ellerman <m...@ellerman.id.au> wrote: > "Rafael J. Wysocki" <raf...@kernel.org> writes: > >> On Thu, Jun 29, 2017 at 2:21 PM, Michael Ellerman >> <patch-notificati...@ellerman.id.au> wrote: >>> On

Re: [1/3] cpuidle: powerpc: cpuidle set polling before enabling irqs

On Thu, Jun 29, 2017 at 2:21 PM, Michael Ellerman wrote: > On Wed, 2017-06-14 at 13:02:39 UTC, Nicholas Piggin wrote: >> local_irq_enable can cause interrupts to be taken which could >> take significant amount of processing time. The idle process >> should set

Re: [PATCH] kernel/power/suspend: use CONFIG_HAVE_SET_MEMORY for include condition

led on powerpc. We don't yet have ARCH_HAS_SET_MEMORY and ppc32 > >> saw a build failure. > >> > >> fixes(50327dd kernel/power/snapshot.c: use set_memory.h header) > >> > >> I've only done a basic compile test with a config that has > >> hiberna

Re: [PATCH v2 1/2] powerpc/powernv/cpuidle: Pass correct drv->cpumask for registration

On Thu, Mar 23, 2017 at 4:22 PM, Vaidyanathan Srinivasan wrote: > drv->cpumask defaults to cpu_possible_mask in __cpuidle_driver_init(). > On PowerNV platform cpu_present could be less than cpu_possible in cases > where firmware detects the cpu, but it is not available

Re: [PATCH v2 2/2] cpuidle: Validate cpu_dev in cpuidle_add_sysfs

On Thu, Mar 23, 2017 at 4:22 PM, Vaidyanathan Srinivasan wrote: > If a given cpu is not in cpu_present and cpu hotplug > is disabled, arch can skip setting up the cpu_dev. > > Arch cpuidle driver should pass correct cpu mask > for registration, but failing to do so by

Re: [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

On Fri, Feb 17, 2017 at 8:11 AM, Joe Perches wrote: > There are ~4300 uses of pr_warn and ~250 uses of the older > pr_warning in the kernel source tree. > > Make the use of pr_warn consistent across all kernel files. > > This excludes all files in tools/ as there is a separate >

Re: [PATCH v6 3/5] cpuidle:powernv: Add helper function to populate powernv idle states.

On Mon, Jan 30, 2017 at 4:47 AM, Michael Ellerman wrote: > "Gautham R. Shenoy" writes: > >> From: "Gautham R. Shenoy" >> >> In the current code for powernv_add_idle_states, there is a lot of code >> duplication while

Re: [PATCH] cpuidle/powernv: staticise powernv_idle_driver

On Tue, Nov 22, 2016 at 6:08 AM, Andrew Donnellan wrote: > powernv_idle_driver isn't exported, it can be made static. Found by sparse. > > Signed-off-by: Andrew Donnellan Applied. Thanks, Rafael

Re: [PATCH v2] cpufreq, powernv: Disable preemption while checking CPU throttling state throttling state

On Tue, Nov 22, 2016 at 2:07 PM, Denis Kirjanov wrote: > With preemption turned on we can read incorrect throttling state while being > switched > to CPU on a different chip. > The following BUG_() was hit while running the 4.8-rc5 kernel compiled > with

Re: [PATCH -next] powernv: cpufreq: Fix uninitialized lpstate_idx in gpstates_timer_handler

On Monday, November 14, 2016 05:29:27 PM Akshay Adiga wrote: > lpstate_idx remains uninitialized in the case when elapsed_time > is greater than MAX_RAMP_DOWN_TIME. At the end of rampdown > global pstate should be equal to local pstate. > > Fixes: 20b15b766354 ("cpufreq: powernv: Use PMCR to

Re: [PATCH v2 0/3] powernv:stop: Use psscr_val, mask provided by firmware

On Thursday, October 27, 2016 02:05:04 PM Gautham R. Shenoy wrote: > From: "Gautham R. Shenoy" > > Hi, > > This is the second iteration of the patchset to use the psscr_val and > psscr_mask provided by the firmware for each of the stop states. > > The previous version

Re: [PATCH] cpufreq: powernv: Fix crash in gpstate_timer_handler

On Wednesday, August 10, 2016 02:28:47 PM Michael Ellerman wrote: > Viresh Kumar writes: > > > On 04-08-16, 20:59, Akshay Adiga wrote: > >> 'commit 09ca4c9b5958 ("cpufreq: powernv: Replacing pstate_id with > >> frequency table index")' changes calc_global_pstate() to use

Re: [PATCH v2] cpufreq: powernv: Replacing pstate_id with frequency table index

On Monday, July 11, 2016 11:47:53 AM Viresh Kumar wrote: > On 30-06-16, 11:53, Akshay Adiga wrote: > > Refactoring code to use frequency table index instead of pstate_id. > > This abstraction will make the code independent of the pstate values. > > > > - No functional changes > > - The highest

Re: [PATCH V5 2/2] cpufreq: Reuse new freq-table helpers

On Monday, June 27, 2016 09:59:34 AM Viresh Kumar wrote: > This patch migrates few users of cpufreq tables to the new helpers that > work on sorted freq-tables. > > Signed-off-by: Viresh Kumar Applied, thanks! ___

Re: [PATCH v5] cpuidle: Fix last_residency division

On Mon, Jul 4, 2016 at 8:10 AM, Balbir Singh wrote: > > > On 02/07/16 00:24, Shreyas B. Prabhu wrote: >> Snooze is a poll idle state in powernv and pseries platforms. Snooze >> has a timeout so that if a cpu stays in snooze for more than target >> residency of the next

Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks

On Friday, July 01, 2016 01:55:46 AM Scott Wood wrote: > On Thu, 2016-06-30 at 15:29 +0200, Rafael J. Wysocki wrote: > > On Thursday, June 30, 2016 05:46:42 AM Scott Wood wrote: > > > > > > On 06/29/2016 10:02 PM, Yuantian Tang wrote: > > > > >

Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks

On Thursday, June 30, 2016 05:46:42 AM Scott Wood wrote: > On 06/29/2016 10:02 PM, Yuantian Tang wrote: > >> -Original Message- > >> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > >> Sent: Thursday, June 30, 2016 10:24 AM > >> To: Yuantian Tang

Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks

On Thursday, June 30, 2016 01:47:09 AM Yuantian Tang wrote: > > -Original Message- > > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > > Sent: Thursday, June 30, 2016 9:47 AM > > To: Yuantian Tang <yuantian.t...@nxp.com> > > Cc: Scott Wood &

Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks

On Wednesday, June 29, 2016 05:50:26 AM Yuantian Tang wrote: > Hi, > > This patch is acked by clock maintainer. If no comments from anyone else, we > will merge it in next week. There is a cpufreq commit depending on it. Are you going to handle that one too? Thanks, Rafael

Re: [PATCH] cpuidle/powernv: Fix snooze timeout

On Wed, Jun 22, 2016 at 9:36 PM, Shreyas B. Prabhu wrote: > Snooze is a poll idle state in powernv and pseries platforms. Snooze > has a timeout so that if a cpu stays in snooze for more than target > residency of the next available idle state, then it would exit

Re: [PATCH v6 09/11] cpuidle/powernv: Use CPUIDLE_STATE_MAX instead of MAX_POWERNV_IDLE_STATES

On Monday, June 13, 2016 05:01:50 PM Daniel Lezcano wrote: > On Wed, Jun 08, 2016 at 11:54:29AM -0500, Shreyas B. Prabhu wrote: > > Use cpuidle's CPUIDLE_STATE_MAX macro instead of powernv specific > > MAX_POWERNV_IDLE_STATES. > > > > Cc: Rafael J. Wysocki <rafa

Re: [PATCH V3 8/9] cpufreq: Keep policy->freq_table sorted in ascending order

On Tuesday, June 07, 2016 09:58:07 AM Viresh Kumar wrote: > On 06-06-16, 23:56, Rafael J. Wysocki wrote: > > Since you are adding new code, you can write it so it doesn't do > > unnecessary checks from the start. > > Hmm, I will do all that in this series o

Re: [PATCH V3 8/9] cpufreq: Keep policy->freq_table sorted in ascending order

On Mon, Jun 6, 2016 at 6:25 PM, Viresh Kumar <viresh.ku...@linaro.org> wrote: > On 6 June 2016 at 18:27, Rafael J. Wysocki <raf...@kernel.org> wrote: >> On Mon, Jun 6, 2016 at 2:24 PM, Viresh Kumar <viresh.ku...@linaro.org> wrote: >>> On 6 June 2016 at 17:40, R

Re: [PATCH V3 8/9] cpufreq: Keep policy->freq_table sorted in ascending order

On Mon, Jun 6, 2016 at 2:24 PM, Viresh Kumar <viresh.ku...@linaro.org> wrote: > On 6 June 2016 at 17:40, Rafael J. Wysocki <r...@rjwysocki.net> wrote: >> On Monday, June 06, 2016 09:22:31 AM Viresh Kumar wrote: > >>> I agree with that, though that requires larger

Re: [PATCH V3 8/9] cpufreq: Keep policy->freq_table sorted in ascending order

On Monday, June 06, 2016 09:22:31 AM Viresh Kumar wrote: > On 03-06-16, 16:48, Steve Muckle wrote: > > On Fri, Jun 03, 2016 at 07:05:14PM +0530, Viresh Kumar wrote: > > ... > > > @@ -468,20 +469,15 @@ unsigned int acpi_cpufreq_fast_switch(struct > > > cpufreq_policy *policy, > > > struct

Re: [RFC PATCH] Increase in idle power with schedutil

On Thu, May 19, 2016 at 1:40 PM, Peter Zijlstra <pet...@infradead.org> wrote: > On Wed, May 18, 2016 at 11:11:51PM +0200, Rafael J. Wysocki wrote: >> On Wed, May 18, 2016 at 2:53 PM, Shilpasri G Bhat >> <shilpa.b...@linux.vnet.ibm.com> wrote: >> > This patch

Re: [RFC PATCH] cpufreq: powernv: Add fast_switch callback

On Wed, May 18, 2016 at 2:53 PM, Shilpasri G Bhat wrote: > Add fast_switch driver callback to support frequency update in > interrupt context while using schedutil governor. Changing frequency > in interrupt context will remove the jitter on the workloads which can

Re: [RFC PATCH] Increase in idle power with schedutil

On Wed, May 18, 2016 at 2:53 PM, Shilpasri G Bhat wrote: > This patch adds driver callback for fast_switch and below observations > on schedutil governor are done with this patch. > > In POWER8 there is a regression observed with schedutil compared to > ondemand.

Re: [PATCH-next v2 0/2] cpufreq: powernv: Fixes for Global pstate management

On Monday, May 09, 2016 09:02:04 PM Viresh Kumar wrote: > On 03-05-16, 20:49, Akshay Adiga wrote: > > Fixes are based on patch https://patchwork.ozlabs.org/patch/612058/ which > > is in Rafael's linux-next. > > > > - Patch [1] fixes WARN_ON in powernv_target_index() > > - Patch [2] Deleting any

Re: [PATCH v3 0/2] cpufreq: powernv: Ramp-down global pstate slower than local-pstate

On Tuesday, April 19, 2016 03:27:59 PM Akshay Adiga wrote: > The frequency transition latency from pmin to pmax is observed to be in few > millisecond granurality. And it usually happens to take a performance penalty > during sudden frequency rampup requests. > > This patch set solves this

Re: [PATCH V3 1/2] cpufreq: qoriq: Remove __exit macro from .exit callback

On Tuesday, April 19, 2016 02:41:51 PM Viresh Kumar wrote: > On 19-04-16, 17:00, Jia Hongtao wrote: > > .exit callback (qoriq_cpufreq_cpu_exit()) is also used during suspend. > > So __exit macro should be removed or the function will be discarded. > > > > Signed-off-by: Jia Hongtao

Re: [PATCH 2/2] cpufreq: qoriq: Don't show cooling device messages if THERMAL_OF undefined

On Monday, April 18, 2016 04:03:45 PM Viresh Kumar wrote: > On 18-04-16, 15:59, Jia Hongtao wrote: > > When THERMAL_OF is undefined the cooling device messages should not be > > shown. -ENOSYS is returned from of_cpufreq_cooling_register() when > > THERMAL_OF is undefined. > > > > Signed-off-by:

Re: [PATCH v13] cpufreq: powernv: Add sysfs attributes to show throttle stats

On Tuesday, March 22, 2016 07:55:07 PM Viresh Kumar wrote: > On 22-03-16, 18:57, Shilpasri G Bhat wrote: > > Create sysfs attributes to export throttle information in > > /sys/devices/system/cpu/cpuX/cpufreq/throttle_stats directory. The > > newly added sysfs files are as follows: > > > >

Re: [PATCH] cpufreq: powernv: Define per_cpu chip pointer to optimize hot-path

On Monday, March 21, 2016 12:52:55 PM Viresh Kumar wrote: > On 18-03-16, 20:28, Shilpasri G Bhat wrote: > > From: Michael Neuling > > > > "cpufreq: powernv: Remove cpu_to_chip_id() from hot-path" introduced > > If the patch is already committed, you should provide its commit

Re: [PATCH v8 3/6] cpufreq: powernv: Remove cpu_to_chip_id() from hot-path

On Fri, Mar 18, 2016 at 5:11 AM, Michael Neuling wrote: > On Fri, 2016-03-18 at 15:04 +1100, Michael Neuling wrote: > >> On Wed, 2016-02-03 at 01:11 +0530, Shilpasri G Bhat wrote: >> > >> > cpu_to_chip_id() does a DT walk through to find out the chip id by >> > taking a

Re: [PATCH V3] cpufreq: qoriq: Register cooling device based on device tree

On Mon, Feb 29, 2016 at 11:05 AM, Arnd Bergmann wrote: > On Friday 26 February 2016 18:41:06 Li Yang wrote: >> >> > >> >> > It would be perfect if this it true. But I tried with the following >> >> > change, it just makes QORIQ_CPUFREQ non-selectable if THERMAL=m. >> >> > >> >> >

Re: [PATCH v10 1/2] cpufreq: powernv: Fix bugs in powernv_cpufreq_{init/exit}

On Friday, February 26, 2016 04:15:00 PM Viresh Kumar wrote: > On 26-02-16, 16:06, Shilpasri G Bhat wrote: > > Unregister the notifiers if cpufreq_driver_register() fails in > > powernv_cpufreq_init(). Re-arrange the unregistration and cleanup routines > > in powernv_cpufreq_exit() to free all the

Re: [PATCH v8 0/6] cpufreq: powernv: Redesign the presentation of throttle notification and solve bug-fixes in the driver

Hi, On Tue, Feb 2, 2016 at 8:41 PM, Shilpasri G Bhat wrote: > In POWER8, OCC(On-Chip-Controller) can throttle the frequency of the > CPU when the chip crosses its thermal and power limits. Currently, > powernv-cpufreq driver detects and reports this event as a

Re: [PATCH V3] cpufreq: qoriq: Register cooling device based on device tree

On Thursday, November 26, 2015 05:21:11 PM Jia Hongtao wrote: > Register the qoriq cpufreq driver as a cooling device, based on the > thermal device tree framework. When temperature crosses the passive trip > point cpufreq is used to throttle CPUs. > > Signed-off-by: Jia Hongtao

Re: [PATCH v6 22/22] of/platform: Defer probes of registered devices

On Thursday, October 22, 2015 04:27:10 PM Scott Wood wrote: > On Thu, 2015-10-22 at 15:04 +0200, Tomeu Vizoso wrote: > > On 22 October 2015 at 00:51, Scott Wood wrote: > > > On Wed, 2015-10-21 at 08:44 -0500, Rob Herring wrote: > > > > On Wed, Oct 21, 2015 at 12:54 AM,

Re: [PATCH v2] cpufreq : powernv: Report Pmax throttling if capped below nominal frequency

On Monday, September 14, 2015 03:58:09 PM Viresh Kumar wrote: > On 14-09-15, 14:01, Shilpasri G Bhat wrote: > > Log a 'critical' message if the max frequency is reduced below nominal > > frequency. We already log 'info' message if the max frequency is > > capped below turbo frequency. CPU should

Re: [PATCH v3 5/5] cpufreq: qoriq: Don't look at clock implementation details

On Tuesday, September 22, 2015 12:46:54 PM Viresh Kumar wrote: > On 19-09-15, 23:29, Scott Wood wrote: > > Get the CPU clock's potential parent clocks from the clock interface > > itself, rather than manually parsing the clocks property to find a > > phandle, looking at the clock-names property of

Re: [PATCH v3 5/5] cpufreq: qoriq: Don't look at clock implementation details

On Friday, September 25, 2015 04:17:07 PM Scott Wood wrote: > On Fri, 2015-09-25 at 23:42 +0200, Rafael J. Wysocki wrote: > > On Tuesday, September 22, 2015 12:46:54 PM Viresh Kumar wrote: > > > On 19-09-15, 23:29, Scott Wood wrote: > > > > Get the CPU clock'

Re: [PATCH] tick/idle/powerpc: Do not register idle states with CPUIDLE_FLAG_TIMER_STOP set in periodic mode

On Thursday, June 25, 2015 09:05:49 AM Preeti U Murthy wrote: On 06/25/2015 05:36 AM, Rafael J. Wysocki wrote: On Thu, Jun 25, 2015 at 12:06 AM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Wed, 2015-06-24 at 15:50 +0200, Rafael J. Wysocki wrote: 4.2 material I suppose

Re: [PATCH] tick/idle/powerpc: Do not register idle states with CPUIDLE_FLAG_TIMER_STOP set in periodic mode

J. Wysocki, Intel Open Source Technology Center. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] tick/idle/powerpc: Do not register idle states with CPUIDLE_FLAG_TIMER_STOP set in periodic mode

On Thu, Jun 25, 2015 at 12:10 AM, Michael Ellerman mich...@ellerman.id.au wrote: On 24 June 2015 23:50:40 GMT+10:00, Rafael J. Wysocki r...@rjwysocki.net wrote: On Wednesday, June 24, 2015 01:48:01 AM Preeti U Murthy wrote: On some archs, the local clockevent device stops in deep cpuidle

Re: [PATCH] tick/idle/powerpc: Do not register idle states with CPUIDLE_FLAG_TIMER_STOP set in periodic mode

On Thu, Jun 25, 2015 at 12:06 AM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Wed, 2015-06-24 at 15:50 +0200, Rafael J. Wysocki wrote: 4.2 material I suppose? And stable. Without this, if you configure without TICK_ONESHOT, the machine will hang. OK, which -stable? All of them

Re: [PATCH] cpufreq: qoriq: optimize the CPU frequency switching time

+--- 1 file changed, 21 insertions(+), 11 deletions(-) Acked-by: Viresh Kumar viresh.ku...@linaro.org Queued up for 4.2, thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ Linuxppc

Re: [PATCH 2/2] PCI: pciehp: Convert pciehp to be builtin only, not modular

AM, Bjorn Helgaas bhelg...@google.com wrote: Convert pciehp to be builtin only, with no module option. Signed-off-by: Bjorn Helgaas bhelg...@google.com Acked-by: Rafael J. Wysocki rafael.j.wyso...@intel.com --- drivers/pci/pcie/Kconfig |5 + 1 file changed, 1

Re: [PATCH 0/3] cpuidle: updates related to tick_broadcast_enter() failures

On Wednesday, May 13, 2015 05:13:27 PM Kevin Hilman wrote: On Wed, May 13, 2015 at 5:16 PM, Rafael J. Wysocki r...@rjwysocki.net wrote: On Wednesday, May 13, 2015 03:59:55 PM Kevin Hilman wrote: Rafael J. Wysocki r...@rjwysocki.net writes: [...] Second, quite honestly, I don't see

Re: [PATCH 0/3] cpuidle: updates related to tick_broadcast_enter() failures

On Wednesday, May 13, 2015 03:59:55 PM Kevin Hilman wrote: Rafael J. Wysocki r...@rjwysocki.net writes: [...] Second, quite honestly, I don't see a connection to genpd here. The connection with genpd is because the *reason* the timer was shutdown/stopped is because it shares power

Re: [PATCH 0/3] cpuidle: updates related to tick_broadcast_enter() failures

On Tuesday, May 12, 2015 10:41:35 AM Daniel Lezcano wrote: On 05/12/2015 01:31 AM, Rafael J. Wysocki wrote: On Monday, May 11, 2015 07:40:41 PM Daniel Lezcano wrote: On 05/10/2015 01:15 AM, Rafael J. Wysocki wrote: On Saturday, May 09, 2015 10:33:05 PM Rafael J. Wysocki wrote: On Saturday

Re: [PATCH 0/3] cpuidle: updates related to tick_broadcast_enter() failures

On Monday, May 11, 2015 10:51:02 AM Preeti U Murthy wrote: On 05/10/2015 04:45 AM, Rafael J. Wysocki wrote: On Saturday, May 09, 2015 10:33:05 PM Rafael J. Wysocki wrote: On Saturday, May 09, 2015 10:11:41 PM Rafael J. Wysocki wrote: On Saturday, May 09, 2015 11:19:16 AM Preeti U Murthy

Re: [PATCH 0/3] cpuidle: updates related to tick_broadcast_enter() failures

On Monday, May 11, 2015 04:13:37 PM Sudeep Holla wrote: On 10/05/15 00:15, Rafael J. Wysocki wrote: On Saturday, May 09, 2015 10:33:05 PM Rafael J. Wysocki wrote: On Saturday, May 09, 2015 10:11:41 PM Rafael J. Wysocki wrote: On Saturday, May 09, 2015 11:19:16 AM Preeti U Murthy wrote

Re: [PATCH 0/3] cpuidle: updates related to tick_broadcast_enter() failures

On Monday, May 11, 2015 07:40:41 PM Daniel Lezcano wrote: On 05/10/2015 01:15 AM, Rafael J. Wysocki wrote: On Saturday, May 09, 2015 10:33:05 PM Rafael J. Wysocki wrote: On Saturday, May 09, 2015 10:11:41 PM Rafael J. Wysocki wrote: On Saturday, May 09, 2015 11:19:16 AM Preeti U Murthy

[PATCH 3/3] cpuidle: Select a different state on tick_broadcast_enter() failures

From: Rafael J. Wysocki rafael.j.wyso...@intel.com If tick_broadcast_enter() fails in cpuidle_enter_state(), try to find another idle state to enter instead of invoking default_idle_call() immediately and returning -EBUSY which should increase the chances of saving some energy in those cases

[PATCH 0/3] cpuidle: updates related to tick_broadcast_enter() failures

On Saturday, May 09, 2015 10:33:05 PM Rafael J. Wysocki wrote: On Saturday, May 09, 2015 10:11:41 PM Rafael J. Wysocki wrote: On Saturday, May 09, 2015 11:19:16 AM Preeti U Murthy wrote: Hi Rafael, On 05/08/2015 07:48 PM, Rafael J. Wysocki wrote: [cut] + /* Take

[PATCH 2/3] sched / idle: Call default_idle_call() from cpuidle_enter_state()

From: Rafael J. Wysocki rafael.j.wyso...@intel.com The check of the cpuidle_enter() return value against -EBUSY made in call_cpuidle() will not be necessary any more if cpuidle_enter_state() calls default_idle_call() directly when it is about to return -EBUSY, so make that happen and eliminate

[PATCH 1/3] sched / idle: Call idle_set_state() from cpuidle_enter_state()

From: Rafael J. Wysocki rafael.j.wyso...@intel.com Introduce a wrapper function around idle_set_state() called sched_idle_set_state() that will pass this_rq() to it as the first argument and make cpuidle_enter_state() call the new function before and after entering the target state. At the same

Re: [PATCH V3] cpuidle: Handle tick_broadcast_enter() failure gracefully

On Saturday, May 09, 2015 10:11:41 PM Rafael J. Wysocki wrote: On Saturday, May 09, 2015 11:19:16 AM Preeti U Murthy wrote: Hi Rafael, On 05/08/2015 07:48 PM, Rafael J. Wysocki wrote: [cut] +/* Take note of the planned idle state. */ +idle_set_state

Re: [PATCH V3] cpuidle: Handle tick_broadcast_enter() failure gracefully

On Saturday, May 09, 2015 11:19:16 AM Preeti U Murthy wrote: Hi Rafael, On 05/08/2015 07:48 PM, Rafael J. Wysocki wrote: +/* + * find_tick_valid_state - select a state where tick does not stop + * @dev: cpuidle device for this cpu + * @drv: cpuidle driver for this cpu + */ +static

Re: [PATCH V3] cpuidle: Handle tick_broadcast_enter() failure gracefully

On Saturday, May 09, 2015 08:46:20 PM Rafael J. Wysocki wrote: On Saturday, May 09, 2015 11:19:16 AM Preeti U Murthy wrote: Hi Rafael, On 05/08/2015 07:48 PM, Rafael J. Wysocki wrote: +/* + * find_tick_valid_state - select a state where tick does not stop + * @dev: cpuidle device

Re: [PATCH V3] cpuidle: Handle tick_broadcast_enter() failure gracefully

On Saturday, May 09, 2015 11:19:16 AM Preeti U Murthy wrote: Hi Rafael, On 05/08/2015 07:48 PM, Rafael J. Wysocki wrote: [cut] + /* Take note of the planned idle state. */ + idle_set_state(smp_processor_id(), target_state); And I wouldn't do this either. The behavior here

Re: [PATCH V3] cpuidle: Handle tick_broadcast_enter() failure gracefully

On Friday, May 08, 2015 01:05:32 PM Preeti U Murthy wrote: When a CPU has to enter an idle state where tick stops, it makes a call to tick_broadcast_enter(). The call will fail if this CPU is the broadcast CPU. Today, under such a circumstance, the arch cpuidle code handles this CPU. This is

Re: [PATCH v3 4/6] cpufreq: powernv: Call throttle_check() on receiving OCC_THROTTLE

On Friday, May 08, 2015 09:16:44 AM Preeti U Murthy wrote: On 05/08/2015 02:29 AM, Rafael J. Wysocki wrote: On Thursday, May 07, 2015 05:49:22 PM Preeti U Murthy wrote: On 05/05/2015 02:11 PM, Preeti U Murthy wrote: On 05/05/2015 12:03 PM, Shilpasri G Bhat wrote: Hi Preeti, On 05/05

Re: [PATCH V3] cpuidle: Handle tick_broadcast_enter() failure gracefully

On Friday, May 08, 2015 04:18:02 PM Rafael J. Wysocki wrote: On Friday, May 08, 2015 01:05:32 PM Preeti U Murthy wrote: When a CPU has to enter an idle state where tick stops, it makes a call to tick_broadcast_enter(). The call will fail if this CPU is the broadcast CPU. Today, under

<    1   2   3   4   >