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:
> >> +/*
> >> + * find_tick_valid_state - select a state where tick does not stop
> >> + * @dev: cpuidle device for this cpu
> &
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 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 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
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
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
_CPU_FREQ_PMAC) += pmac32-cpufreq.o
> obj-$(CONFIG_CPU_FREQ_PMAC64)+= pmac64-cpufreq.o
> obj-$(CONFIG_PPC_PASEMI_CPUFREQ) += pasemi-cpufreq.o
> diff --git a/drivers/cpufreq/ppc-corenet-cpufreq.c
> b/drivers/cpufreq/qoriq-cpufreq.c
> similarity index 100%
;
> Signed-off-by: Tang Yuantian
> Acked-by: Viresh Kumar
That doesn't apply for me on top of 4.0-rc3. Can you please rebase and
resubmit?
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
Linuxppc-dev mail
0..7cb4b766cf948d3f 100644
> --- a/drivers/cpufreq/ppc-corenet-cpufreq.c
> +++ b/drivers/cpufreq/ppc-corenet-cpufreq.c
> @@ -22,6 +22,8 @@
> #include
> #include
>
> +#include /* for get_hard_smp_processor_id() in UP configs */
> +
> /**
> * struct cpu_data - per
On Wednesday, February 18, 2015 10:13:23 AM Preeti U Murthy wrote:
>
> On 02/17/2015 11:23 PM, Rafael J. Wysocki wrote:
> > On Tuesday, February 17, 2015 01:29:10 PM Preeti U Murthy wrote:
> >> Hi Rafael,
> >
> > Hi,
> >
> >> Can you please
aiting to be pulled:
> [PATCH] driver/cpuidle-powernv: Avoid endianness conversions while parsing DT
OK, have you posted it already?
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
Linuxppc-dev mai
> 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!
> ---
>
&
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
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
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
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 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
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
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!
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
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
On Wednesday, April 02, 2014 03:23:28 PM Benjamin Herrenschmidt wrote:
> On Wed, 2014-04-02 at 00:03 +0200, Rafael J. Wysocki wrote:
> > > Rafael, are you going to take these or should I send them to Linus ?
> > >
> > > (I'd rather you take them :-)
> &
On Tuesday, April 01, 2014 08:46:49 PM Benjamin Herrenschmidt wrote:
> On Tue, 2014-04-01 at 12:43 +0530, Gautham R. Shenoy wrote:
> > From: "Gautham R. Shenoy"
> >
> > Enable CPUFreq for PowerNV. Select "performance", "powersave",
> > "userspace" and "ondemand" governors. Choose "ondemand" to be
de
> conversions (to use this model).
>
> This patchset has been hosted in the below git tree. It applies cleanly on
> v3.14-rc6.
>
> git://github.com/srivatsabhat/linux.git cpuhp-registration-fixes-v3
So to me, this is a useful patchset and it addresses a real problem. It ha
On Friday, February 14, 2014 10:19:41 AM Yijing Wang wrote:
> On 2014/2/14 7:54, Rafael J. Wysocki wrote:
> > On Thursday, February 13, 2014 09:13:58 PM Yijing Wang wrote:
> >> Replace list_for_each() + pci_bus_b() with the simpler
> >> list_for_each_entry().
> >
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
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
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
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
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
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);
> +
> +
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
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
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
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.
___
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
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
>
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
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 +-
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
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 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
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
>
--
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
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)
> -{
> -
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
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.
>
&
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
, 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
>
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
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
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
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 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
; 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 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
> ---
>
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
>
> 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.
_
@@ -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 =
rename arch/powerpc/platforms/powermac/cpufreq_64.c =>
> >>>>>>> drivers/cpufreq/pmac64-cpufreq.c (100%)
> >>>>>>
> >>>>>> Hi Deepthi,
> >>>>>>
> >>>>>> Can you help testing this
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.
.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
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
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 %
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
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 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 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 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 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 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 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
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: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
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 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 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 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 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 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:
> > > >
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 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
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
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)
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
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 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
+/*
> + * 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_
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
om the ACPI developers?
This particular series is in my tree waiting for the v3.8 merge window.
There's a new one sent yesterday and this one is pending a review. I'm
not sure if the $subject patchset depends on it, though.
It looks like there are too
r;
> - s64 usec_delta;
> int cpu = smp_processor_id();
>
> cstate = (((eax) >> MWAIT_SUBSTATE_SIZE) & MWAIT_CSTATE_MASK) + 1;
> @@ -297,8 +295,6 @@ static int intel_idle(struct cpuidle_device *dev,
> if (!(lapic_timer_reliable_states & (1 << (cstate
> clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu);
>
> - kt_before = ktime_get_real();
> -
> stop_critical_timings();
> if (!need_resched()) {
>
> @@ -310,17 +306,9 @@ static int intel_idle(struct cpuidle_device *dev,
>
> start_critical_timings();
>
> - kt_after = ktime_get_real();
> - usec_delta = ktime_to_us(ktime_sub(kt_after, kt_before));
> -
> - local_irq_enable();
> -
> if (!(lapic_timer_reliable_states & (1 << (cstate
> clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu);
>
> - /* Update cpuidle counters */
> - dev->last_residency = (int)usec_delta;
> -
> return index;
> }
>
>
--
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
ktime_t kt_before, kt_after;
> - s64 usec_delta;
> int cpu = smp_processor_id();
>
> cstate = (((eax) >> MWAIT_SUBSTATE_SIZE) & MWAIT_CSTATE_MASK) + 1;
> @@ -297,8 +295,6 @@ static int intel_idle(struct cpuidle_device *dev,
> if (!(lapic_timer_
On Sunday, July 15, 2012, Andreas Schwab wrote:
> This breaks resume on the iBook G4 (PowerBook6,7). Apparently during or
> before noirq resume the system is hanging by the same amount of time as
> the system was sleeping.
I'm able to reproduce this problem on Toshiba Portege R500 with similar
sy
On Tuesday, April 26, 2011, Hans-Christian Egtvedt wrote:
> On Sun, 2011-04-17 at 23:13 +0200, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > Convert some AVR32 architecture's code to using struct syscore_ops
> > objects for power management inste
On Monday, April 18, 2011, Mike Frysinger wrote:
> On Sun, Apr 17, 2011 at 17:11, Rafael J. Wysocki wrote:
> > Convert some Blackfin architecture's code to using struct syscore_ops
> > objects for power management instead of sysdev classes and sysdevs.
> >
> > This
On Monday, April 18, 2011, Ralf Baechle wrote:
> This patch breaks the Alchemy kernel compile; below patch on top of it fixes
> that again.
>
> Signed-off-by: Ralf Baechle
Thanks! If you don't mind, I'd like to fold your patch into [10/14].
Rafael
> ---
> arch/mips/alchemy/common/irq.c |
From: Rafael J. Wysocki
Since suspend, resume and shutdown operations in struct sysdev_class
and struct sysdev_driver are not used any more, remove them. Also
drop sysdev_suspend(), sysdev_resume() and sysdev_shutdown() used
for executing those operations and modify all of their users
From: Rafael J. Wysocki
Replace sysdev classes and struct sys_device objects used for "core"
power management by the PXA platform code with struct syscore_ops
objects that are simpler.
This reduces the code size and the kernel memory footprint. It also
is necessary for removi
201 - 300 of 328 matches
Mail list logo
