hat should not call
cpuidle_select().
What's needed here seems to be a fallback mechanism like "choose the
deepest state shallower than X and such that it won't stop the tick".
You don't really need to run a full governor for that.
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
s during an OCC reset cycle. So I am setting 'throttled' to false on
> >> OCC_ACTIVE and re-verifying if it actually is the case by invoking
> >> *throttle_check().
> >
> > Alright like I pointed in the previous reply, a comment to in
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
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
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
> > broadc
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
> &
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_st
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);
&g
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]
>
> > >>
> > &g
From: Rafael J. Wysocki
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.
Signed-off-by: Rafael J
From: Rafael J. Wysocki
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 time, remove direct
From: Rafael J. Wysocki
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 the
check.
Signed-off-by
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, Ra
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
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,
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
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
On Wednesday, May 13, 2015 03:59:55 PM Kevin Hilman wrote:
> "Rafael J. Wysocki" 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/s
On Wednesday, May 13, 2015 05:13:27 PM Kevin Hilman wrote:
> On Wed, May 13, 2015 at 5:16 PM, Rafael J. Wysocki wrote:
> > On Wednesday, May 13, 2015 03:59:55 PM Kevin Hilman wrote:
> >> "Rafael J. Wysocki" writes:
> >>
> >> [...]
> >>
>
l 25, 2013 at 10:57 AM, Bjorn Helgaas
> > > wrote:
> > >> Convert pciehp to be builtin only, with no module option.
> > >>
> > >> Signed-off-by: Bjorn Helgaas
> > >> Acked-by: Rafael J. Wysocki
> > >> ---
> > >> d
27;ve queued up the two patches for 3.18, thanks!
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
change the
> > frequency. So instead of returning EBUSY we return 0 to stop the
> > governor from changing the frequency without alerting a failure to
> > do the same on reboot, as this is not an errorneaos condition.
>
> Acked-by: Viresh Kumar
Queued up for 3.18, thanks!
h 1 - Moves parameters required discover idle states to a location
> >> common to both cpuidle driver and powernv core code
> >> Patch 2 - Populates idle state details from device tree
> >> Patch 3 - Enables cpus to run guest after waking up from fastsleep/winkle
> >>
&g
On Tuesday, September 30, 2014 01:42:05 PM Shreyas B Prabhu wrote:
> Hi Rafael,
>
> On Tuesday 30 September 2014 04:58 AM, Rafael J. Wysocki wrote:
> > On Monday, September 29, 2014 03:53:06 PM Shreyas B Prabhu wrote:
> >> Hi,
> >> Any updates on this patch se
L3 cache is not flushed.
>
> This series overcomes above problem in kernel.
>
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michael Ellerman
> Cc: Rafael J. Wysocki
> Cc: linux...@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: Srivatsa S. Bhat
On Monday, October 06, 2014 10:28:05 PM Guenter Roeck wrote:
> Poweroff handlers may now be installed with register_poweroff_handler.
> Use the new API function have_kernel_poweroff to determine if a poweroff
> handler has been installed.
>
> Cc: Rafael J. Wysocki
> Cc: Pavel
On Monday, October 06, 2014 10:28:46 PM Guenter Roeck wrote:
> No users of pm_power_off are left, so it is safe to remove the function.
>
> Cc: Rafael J. Wysocki
> Cc: Pavel Machek
> Cc: Len Brown
> Signed-off-by: Guenter Roeck
ACK
> ---
> include/linux/pm.h
hose,
> call do_kernel_poweroff from machine_power_off instead.
ACK
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
> Cc: linux...@vger.kernel.org
> Cc: Rafael J. Wysocki
> Cc: devicet...@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Signed-off-by: Preeti U. Murthy
> Signed-off-by: Shreyas B. Prabhu
Applied, thanks!
> ---
>
&
g.powerpc | 10 +
> > drivers/cpufreq/Makefile | 1 +
> > drivers/cpufreq/ppc-corenet-cpufreq.c | 380
> > ++
> > 3 files changed, 391 insertions(+)
> > create mode 100644 drivers/cpufreq/ppc-corenet-cpufreq.
rename arch/powerpc/platforms/powermac/cpufreq_64.c =>
> >>>>>>> drivers/cpufreq/pmac64-cpufreq.c (100%)
> >>>>>>
> >>>>>> Hi Deepthi,
> >>>>>>
> >>>>>> Can you help testing this
@@ -285,7 +285,7 @@ static int g5_pfunc_switch_freq(int speed_mode)
> pmf_call_one(pfunc_slewing_done, &args);
> if (done)
> break;
> - msleep(1);
> + usleep_range(500, 500);
> }
> if (done =
>
> return 0;
> }
> +EXPORT_SYMBOL_GPL(cpuidle_idle_call);
>
> /**
> * cpuidle_install_idle_handler - installs the cpuidle idle loop handler
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
_
tered == 0)
> return;
>
> @@ -448,8 +449,6 @@ void cpuidle_unregister_device(struct cpuidle_device *dev)
> cpuidle_coupled_unregister_device(dev);
>
> cpuidle_resume_and_unlock();
> -
> - module_put(drv->owner);
> }
>
> EXPOR
On Thursday, July 25, 2013 11:57:20 AM Bjorn Helgaas wrote:
> Convert CONFIG_HOTPLUG_PCI from tristate to bool. This only affects
> the hotplug core; several of the hotplug drivers can still be modules.
>
> Signed-off-by: Bjorn Helgaas
Acked-by: Rafael J. Wysocki
> ---
>
; u8 bResultCode;
> } __attribute__((packed));
>
> diff --git a/include/media/tveeprom.h b/include/media/tveeprom.h
> index 4a1191a..f7119ee 100644
> --- a/include/media/tveeprom.h
> +++ b/include/media/tveeprom.h
> @@ -12,6 +12,8 @@ enum tveeprom_audio_processor {
> TVEEPROM_AUDPROC_OTHER,
> };
>
> +#include
> +
> struct tveeprom {
> u32 has_radio;
> /* If has_ir == 0, then it is unknown what the IR capabilities are,
> @@ -40,7 +42,7 @@ struct tveeprom {
> u32 revision;
> u32 serial_number;
> char rev_str[5];
> - u8 MAC_address[6];
> + u8 MAC_address[ETH_ALEN];
> };
>
> void tveeprom_hauppauge_analog(struct i2c_client *c, struct tveeprom *tvee,
> diff --git a/include/net/irda/irlan_common.h b/include/net/irda/irlan_common.h
> index 0af8b8d..550c2d6 100644
> --- a/include/net/irda/irlan_common.h
> +++ b/include/net/irda/irlan_common.h
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -161,7 +162,7 @@ struct irlan_provider_cb {
> int access_type; /* Access type */
> __u16 send_arb_val;
>
> - __u8 mac_address[6]; /* Generated MAC address for peer device */
> + __u8 mac_address[ETH_ALEN]; /* Generated MAC address for peer device */
> };
>
> /*
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Monday, July 29, 2013 12:34:24 PM Joe Perches wrote:
> On Mon, 2013-07-29 at 13:59 +0200, Rafael J. Wysocki wrote:
> > On Sunday, July 28, 2013 10:29:04 PM Joe Perches wrote:
> > > It's convenient to have ethernet mac addresses use
> > > ETH_ALEN to be able t
use the refcount is not zero.
>
> Funny, that means the module format was *never* used at all as it does
> not work.
>
> I am wondering if we shouldn't just remove the module support for
> cpuidle. Rafael ?
That would be the simplest thing to do and possibly the most correct one too,
but I need to double check how inte_idle/ACPI idle interactions depend on that.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Tuesday, July 30, 2013 03:33:44 PM Rafael J. Wysocki wrote:
> On Tuesday, July 30, 2013 01:19:46 PM Daniel Lezcano wrote:
> > On 07/30/2013 12:48 PM, Wang Dongsheng-B40534 wrote:
> > >
> > >
> > >> -Original Message-
> > >> Fro
> > Signed-off-by: Tang Yuantian
> > ---
> > drivers/cpufreq/qoriq-cpufreq.c | 32 +---
> > 1 file changed, 21 insertions(+), 11 deletions(-)
>
> Acked-by: Viresh Kumar
Queued up for 4.2, thanks!
--
I speak only for myself.
Rafael J. Wysocki, Intel Ope
unsigned int)latency_ns[i]) / 1000;
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Thu, Jun 25, 2015 at 12:10 AM, Michael Ellerman
wrote:
>
>
> On 24 June 2015 23:50:40 GMT+10:00, "Rafael J. Wysocki"
> wrote:
>>On Wednesday, June 24, 2015 01:48:01 AM Preeti U Murthy wrote:
>>> On some archs, the local clockevent device stops in dee
On Thu, Jun 25, 2015 at 12:06 AM, Benjamin Herrenschmidt
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 th
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
> > wrote:
> >> On Wed, 2015-06-24 at 15:50 +0200, Rafael J. Wysocki wrote:
> >>> 4
On Tuesday, August 13, 2013 01:44:23 PM Rob Herring wrote:
> On Tue, Aug 13, 2013 at 10:40 AM, Sudeep KarkadaNagesha
> wrote:
> > Adding PowerPC list
> >
> > On 13/08/13 14:00, Rafael J. Wysocki wrote:
> >> On Monday, August 12, 2013 02:27:47 PM Sudeep KarkadaN
ws 1 (online).
>
> This patch fixes _debug_hotplug_cpu() to update dev->offline when CPU
> online/offline operation succeeded.
>
> Signed-off-by: Toshi Kani
Acked-by: Rafael J. Wysocki
> ---
> arch/x86/kernel/topology.c |7 +--
> 1 file changed, 5 insertio
, this config option
> is no longer required for the serialization. This patch disables
> this config option on x86 and revert the changes made by commit
> d7c53c9e.
>
> Signed-off-by: Toshi Kani
Acked-by: Rafael J. Wysocki
> ---
> arch/x86/Kconfig |4
>
gt; Signed-off-by: Toshi Kani
Acked-by: Rafael J. Wysocki
> ---
> arch/x86/kernel/topology.c |2 ++
> drivers/base/cpu.c | 16 ++--
> 2 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kernel/topology.c b/arch/x86/kernel/t
ing and is only enabled on powerpc.
>
> This patch removes the cpu_hotplug_driver_lock() interface. As
> a result, ARCH_CPU_PROBE_RELEASE only enables / disables the cpu
> probe & release interface as intended. There is no functional change
> in this patch.
>
&
from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
I speak only for myself.
Rafael J. Wysocki, Intel Open
of_node_put(node);
> - irq_dispose_mapping(info.irq);
> - continue;
> - }
> - }
> -}
> -EXPORT_SYMBOL(of_i2c_register_devices);
> -
> -static int of_dev_node_match(struct device *dev, void *data)
> -{
> -
return np;
> - }
> - }
> - }
> + if (__of_find_n_match_cpu_property(cpun,
> + "ibm,ppc-interrupt-server#s", cpu, thread))
> + return cpun;
> +
> + if (__of_find_n_match_cpu_property(cpun, "reg", cpu, thread))
> + return cpun;
> }
> return NULL;
> }
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
u->dev.offline_disabled = !cpu->hotpluggable;
> cpu->dev.offline = !cpu_online(num);
> + cpu->dev.of_node = of_get_cpu_node(num, NULL);
> #ifdef CONFIG_ARCH_HAS_CPU_AUTOPROBE
> cpu->dev.bus->uevent = arch_cpu_uevent;
> #endif
>
--
On Thursday, August 22, 2013 02:57:56 PM Sudeep KarkadaNagesha wrote:
> Hi Rafael,
>
> Here is the v2 of the pull request for cpu of_node updates for v3.12
> It includes ACK for all the new changes since v1(mainly from Ben for
> PPC). Currently there's trivial conflict with today's linux-next in 3
On Thursday, August 29, 2013 11:15:10 AM Toshi Kani wrote:
> On Sun, 2013-08-18 at 03:02 +0200, Rafael J. Wysocki wrote:
> > On Saturday, August 17, 2013 01:46:55 PM Toshi Kani wrote:
> > > lock_device_hotplug() was recently introduced to serialize CPU & Memory
> >
On Friday, August 30, 2013 11:44:06 AM Yasuaki Ishimatsu wrote:
> (2013/08/30 9:22), Toshi Kani wrote:
> > lock_device_hotplug() was recently introduced to serialize CPU & Memory
> > online/offline and hotplug operations, along with sysfs online interface
> > restructure (commit 4f3549d7). With th
ystem/cpu/cpu0/online still
> shows 1 (online).
>
> This patch fixes _debug_hotplug_cpu() to update dev->offline when CPU
> online/offline operation succeeded.
>
> Signed-off-by: Toshi Kani
> Acked-by: Rafael J. Wysocki
> ---
> arch/x86/kernel/topology.c |7 +-
misleading and is only enabled on powerpc.
>
> This patch removes the cpu_hotplug_driver_lock() interface. As
> a result, ARCH_CPU_PROBE_RELEASE only enables / disables the cpu
> probe & release interface as intended. There is no functional change
> in this patch.
>
&g
pcie_ports_auto is true, so we end up with capabilities set to 0.
>
> in
> | commit fe31e69740eddc7316071ed5165fed6703c8cd12
> | Author: Rafael J. Wysocki
> | Date: Sun Dec 19 15:57:16 2010 +0100
> |
> |PCI/PCIe: Clear Root PME Status bits early during system resume
>
cpufreq.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
t; > No changes except rebasing. Any chance to get these into v3.13?
>
> BTW. Ack from me, Rafael feel free to merge these.
Queued up for 3.13, sorry for the delay.
Thanks!
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
On 10/31/2013 3:18 AM, Chen Gang wrote:
Hello Maintainers
It is removed by "bcc8edb driver core: remove dev_attrs from struct
class" in Oct 5 2013. But "75d2364 PowerCap: Add class driver" still
use it in Oct 11 2013.
The related error (for powerpc with allmodconfig):
CC drivers/powerc
st be
> first */
> +#define SHP_ACPI_RES_DEL_VALIDATE_ORDER 10
> +
> +/* Delete Execute order values */
> +#define SHP_ACPI_BUS_DEL_EXECUTE_ORDER 100
> +
> +/* Delete Commit order values */
> +#define SHP_ACPI_BUS_DEL_COMMIT_ORDER
+/*
> + * Externs
> + */
> +typedef int (*shp_func)(struct shp_request *req, int rollback);
> +extern int shp_register_handler(enum shp_phase phase, shp_func func, u32
> order);
> +extern int shp_unregister_handler(enum shp_phase phase, shp_func func);
> +extern int shp_
On Monday, January 14, 2013 08:53:53 AM Toshi Kani wrote:
> On Fri, 2013-01-11 at 22:25 +0100, Rafael J. Wysocki wrote:
> > On Thursday, January 10, 2013 04:40:20 PM Toshi Kani wrote:
> > > Added include/acpi/sys_hotplug.h, which is ACPI-specific system
> > > device hot
On Monday, January 14, 2013 08:33:48 AM Toshi Kani wrote:
> On Fri, 2013-01-11 at 22:23 +0100, Rafael J. Wysocki wrote:
> > On Thursday, January 10, 2013 04:40:19 PM Toshi Kani wrote:
> > > Added include/linux/sys_hotplug.h, which defines the system device
> > > hotplu
On Monday, January 14, 2013 11:42:09 AM Toshi Kani wrote:
> On Mon, 2013-01-14 at 19:47 +0100, Rafael J. Wysocki wrote:
> > On Monday, January 14, 2013 08:53:53 AM Toshi Kani wrote:
> > > On Fri, 2013-01-11 at 22:25 +0100, Rafael J. Wysocki wrote:
> > > > On Thursday
ire list of devices attached to the request object? Wouldn't
it be more convenient if they were called only for the types of devices
they have declared to handle? [That would reduce some code duplication,
for example.]
(6) Why is it convenient to use order values (priorities)
platform devices and I don't
see why we can't do that for the other types of devices too.
The only missing piece I see is a way to handle the "eject" problem, i.e.
when we try do eject a device at the top of a subtree and need to tear down
the entire subtree below it, but if that's going to lead to a system crash,
for example, we want to cancel the eject. It seems to me that we'll need some
help from the driver core here.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Friday, February 01, 2013 08:23:12 AM Greg KH wrote:
> On Thu, Jan 31, 2013 at 09:54:51PM +0100, Rafael J. Wysocki wrote:
> > > > But, again, I'm going to ask why you aren't using the existing cpu /
> > > > memory / bridge / node devices that we have in the
do care about you creating new
> > driver core pieces that duplicate the existing functionality of what we
> > have today.
> >
> > In short, I like Rafael's proposal better, and I fail to see how
> > anything you have stated here would matter in how
On Saturday, February 02, 2013 03:58:01 PM Greg KH wrote:
> On Fri, Feb 01, 2013 at 11:12:59PM +0100, Rafael J. Wysocki wrote:
> > On Friday, February 01, 2013 08:23:12 AM Greg KH wrote:
> > > On Thu, Jan 31, 2013 at 09:54:51PM +0100, Rafael J. Wysocki wrote:
> > > >
On Saturday, February 02, 2013 09:15:37 PM Rafael J. Wysocki wrote:
> On Saturday, February 02, 2013 03:58:01 PM Greg KH wrote:
[...]
>
> > I know it's more complicated with these types of devices, and I think we
> > are getting closer to the correct solution, I just don
On Saturday, February 02, 2013 09:15:37 PM Rafael J. Wysocki wrote:
> On Saturday, February 02, 2013 03:58:01 PM Greg KH wrote:
> > On Fri, Feb 01, 2013 at 11:12:59PM +0100, Rafael J. Wysocki wrote:
> > > On Friday, February 01, 2013 08:23:12 AM Greg KH wrote:
> > > >
On Sunday, February 03, 2013 07:24:47 PM Greg KH wrote:
> On Sat, Feb 02, 2013 at 11:18:20PM +0100, Rafael J. Wysocki wrote:
> > On Saturday, February 02, 2013 09:15:37 PM Rafael J. Wysocki wrote:
> > > On Saturday, February 02, 2013 03:58:01 PM Greg KH wrote:
> > [...]
&g
On Sunday, February 03, 2013 07:23:49 PM Greg KH wrote:
> On Sat, Feb 02, 2013 at 09:15:37PM +0100, Rafael J. Wysocki wrote:
> > On Saturday, February 02, 2013 03:58:01 PM Greg KH wrote:
> > > On Fri, Feb 01, 2013 at 11:12:59PM +0100, Rafael J. Wysocki wrote:
> > > >
On Monday, February 04, 2013 04:48:10 AM Greg KH wrote:
> On Sun, Feb 03, 2013 at 09:44:39PM +0100, Rafael J. Wysocki wrote:
> > > Yes, but those are just remove events and we can only see how destructive
> > > they
> > > were after the removal. The point is to be
On Monday, February 04, 2013 09:19:09 AM Toshi Kani wrote:
> On Mon, 2013-02-04 at 15:21 +0100, Rafael J. Wysocki wrote:
> > On Monday, February 04, 2013 04:48:10 AM Greg KH wrote:
> > > On Sun, Feb 03, 2013 at 09:44:39PM +0100, Rafael J. Wysocki wrote:
> > > > &g
iver involved, and the driver core, there
> > is no difference. That was one of the primary goals of the driver core
> > creation so many years ago.
> >
> > > Today, the unbind operation to an ACPI cpu/memory devices causes
> > > hot-unplug (offline) operation to them, which is one of the major issues
> > > for us since unbind cannot fail. This patchset addresses this issue by
> > > making the unbind operation of ACPI cpu/memory devices to do the
> > > unbinding only. ACPI drivers no longer control cpu and memory as they
> > > are supposed to be controlled by their drivers, cpu and memory modules.
> >
> > I think that's the problem right there, solve that, please.
>
> We cannot eliminate the ACPI drivers since we have to scan ACPI. But we
> can limit the ACPI drivers to do the scanning stuff only. This is
> precisely the intend of this patchset. The real stuff, removing actual
> devices, is done by the system device drivers/modules.
In case you haven't realized that yet, the $subject patchset has no future.
Let's just talk about how we can get what we need in more general terms.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Monday, February 04, 2013 09:02:46 AM Toshi Kani wrote:
> On Mon, 2013-02-04 at 14:41 +0100, Rafael J. Wysocki wrote:
> > On Sunday, February 03, 2013 07:23:49 PM Greg KH wrote:
> > > On Sat, Feb 02, 2013 at 09:15:37PM +0100, Rafael J. Wysocki wrote:
> > > > On Sat
On Monday, February 04, 2013 06:33:52 AM Greg KH wrote:
> On Mon, Feb 04, 2013 at 03:21:22PM +0100, Rafael J. Wysocki wrote:
> > On Monday, February 04, 2013 04:48:10 AM Greg KH wrote:
> > > On Sun, Feb 03, 2013 at 09:44:39PM +0100, Rafael J. Wysocki wrote:
> > > > &g
On Monday, February 04, 2013 12:46:24 PM Toshi Kani wrote:
> On Mon, 2013-02-04 at 20:48 +0100, Rafael J. Wysocki wrote:
> > On Monday, February 04, 2013 09:02:46 AM Toshi Kani wrote:
> > > On Mon, 2013-02-04 at 14:41 +0100, Rafael J. Wysocki wrote:
> > > > On Sunday,
On Monday, February 04, 2013 01:34:18 PM Toshi Kani wrote:
> On Mon, 2013-02-04 at 21:12 +0100, Rafael J. Wysocki wrote:
> > On Monday, February 04, 2013 12:46:24 PM Toshi Kani wrote:
> > > On Mon, 2013-02-04 at 20:48 +0100, Rafael J. Wysocki wrote:
> > > > On Monday,
On Monday, February 04, 2013 01:59:27 PM Toshi Kani wrote:
> On Mon, 2013-02-04 at 20:45 +0100, Rafael J. Wysocki wrote:
> > On Monday, February 04, 2013 09:46:18 AM Toshi Kani wrote:
> > > On Mon, 2013-02-04 at 04:46 -0800, Greg KH wrote:
> > > > On Sun, Feb 03, 2
On Monday, February 04, 2013 03:13:29 PM Toshi Kani wrote:
> On Mon, 2013-02-04 at 21:07 +0100, Rafael J. Wysocki wrote:
> > On Monday, February 04, 2013 06:33:52 AM Greg KH wrote:
> > > On Mon, Feb 04, 2013 at 03:21:22PM +0100, Rafael J. Wysocki wrote:
> > > > On M
On Monday, February 04, 2013 04:04:47 PM Greg KH wrote:
> On Tue, Feb 05, 2013 at 12:52:30AM +0100, Rafael J. Wysocki wrote:
> > You'd probably never try to hot-remove a disk before unmounting filesystems
> > mounted from it or failing it as a RAID component and nobody sane wan
On Monday, February 04, 2013 04:04:47 PM Greg KH wrote:
> On Tue, Feb 05, 2013 at 12:52:30AM +0100, Rafael J. Wysocki wrote:
> > You'd probably never try to hot-remove a disk before unmounting filesystems
> > mounted from it or failing it as a RAID component and nobody sane wan
On Tuesday, February 05, 2013 10:39:48 AM Greg KH wrote:
> On Tue, Feb 05, 2013 at 12:11:17PM +0100, Rafael J. Wysocki wrote:
> > On Monday, February 04, 2013 04:04:47 PM Greg KH wrote:
> > > On Tue, Feb 05, 2013 at 12:52:30AM +0100, Rafael J. Wysocki wrote:
> > > > Y
gt; +++ b/arch/blackfin/mach-common/cpufreq.c
> @@ -164,7 +164,7 @@ static int bfin_target(struct cpufreq_policy *policy,
> ret = cpu_set_cclk(policy->cpu, freqs.new * 1000);
> if (ret != 0) {
> WARN_ONCE(ret, "cpufreq set freq failed %
rs.
Whatever is not ready (i.e. ACKed in this particular case) before that time,
won't be taken.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists
.owner = THIS_MODULE,
> + .flags = CPUFREQ_CONST_LOOPS,
> +};
> +
> +static struct of_device_id mpc85xx_jog_ids[] = {
> + { .compatible = "fsl,mpc8536-guts", },
> + { .compatible = "fsl,p1022-guts", },
> + {}
> +};
> +
> +static int __init mpc85xx_jog_init(void)
> +{
> + struct device_node *np;
> + unsigned int svr;
> +
> + np = of_find_matching_node(NULL, mpc85xx_jog_ids);
> + if (!np)
> + return -ENODEV;
> +
> + guts = of_iomap(np, 0);
> + if (!guts) {
> + of_node_put(np);
> + return -ENODEV;
> + }
> +
> + sysfreq = fsl_get_sys_freq();
> +
> + if (of_device_is_compatible(np, "fsl,mpc8536-guts")) {
> + svr = mfspr(SPRN_SVR);
> + if ((svr & 0x7fff) == 0x10) {
> + pr_err("MPC8536 Rev 1.0 does not support
> cpufreq(JOG).\n");
> + of_node_put(np);
> + return -ENODEV;
> + }
> + mpc85xx_freqs = mpc8536_freqs_table;
> + set_pll = mpc8536_set_pll;
> + max_pll[0] = get_pll(0);
> +
> + } else if (of_device_is_compatible(np, "fsl,p1022-guts")) {
> + mpc85xx_freqs = p1022_freqs_table;
> + set_pll = p1022_set_pll;
> + max_pll[0] = get_pll(0);
> + max_pll[1] = get_pll(1);
> + }
> +
> + pr_info("Freescale MPC85xx cpufreq(JOG) driver\n");
> +
> + of_node_put(np);
> + return cpufreq_register_driver(&mpc85xx_cpufreq_driver);
> +}
> +
> +device_initcall(mpc85xx_jog_init);
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
atform specific -- but your patch
> doesn't address that. You still have the driver itself interpret what
> "standby" and "mem" mean.
>
> As for "in analogy with ACPI suspend operations", can someone familiar
> with ACPI explain what is meant?
AC
idle.c | 140
> +---
> include/linux/cpuidle.h | 1 -
> 7 files changed, 51 insertions(+), 194 deletions(-)
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
like to know why exactly the change is needed in the first place.
Thanks!
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
fsl_pci_pme_probe(phb);
> +#endif
> +}
> +
> +static int fsl_pci_probe(struct platform_device *pdev)
> +{
> + int ret;
> + struct device_node *node;
> +
> + node = pdev->dev.of_node;
> + ret = fsl_add_bridge(pdev, fsl_pci_primary == node);
> +
> +
ot on one of my test machines with intel_idle, so I'm
not sure how well it has been tested.
I've dropped it entirely for now. If I have the time, I will try to identify
the root cause of the failure, but that may not happen before the merge w
On Saturday, January 11, 2014 01:37:29 AM Rafael J. Wysocki wrote:
> On Friday, December 20, 2013 07:47:22 PM Bartlomiej Zolnierkiewicz wrote:
> > Hi,
> >
> > Some cpuidle drivers assume that cpuidle core will handle cases where
> > device->state_count is sm
Murthy
The cpuidle changes in this patch look reasonable to me, but I guess you'd
like it to go in via tip along with the rest of the series, so
Acked-by: Rafael J. Wysocki
> ---
>
> drivers/cpuidle/cpuidle.c | 38 +++---
> 1 file changed, 2
nd exit since a decision on an idle state could not be taken. Similarly
> when the call to broadcast framework fails, we skip tracing idle statistics
> because we are in no further position to take a decision on an alternative
> idle state to enter into.
>
> Signed-off-by: Preeti
n = pci_bus_max_busnr(pci_bus_b(tmp));
> + list_for_each_entry(tmp, &bus->children, node) {
> + n = pci_bus_max_busnr(tmp);
> if (n > max)
> max = n;
> }
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Sour
1 - 100 of 331 matches
Mail list logo
