* Re: [PATCH v9 06/10] ata: zpodd: check zero power ready status
From: James Bottomley @ 2012-11-26 13:17 UTC (permalink / raw)
To: Aaron Lu
Cc: Rafael J. Wysocki, Tejun Heo, Jeff Garzik, Alan Stern, Jeff Wu,
Aaron Lu, linux-ide, linux-pm, linux-scsi, linux-acpi
In-Reply-To: <50B327FB.3020701@intel.com>
On Mon, 2012-11-26 at 16:27 +0800, Aaron Lu wrote:
> Well, ZPREADY is not a power state that we can program the ODD to
> enter(figure 234 and table 323 of the SPEC), it servers more like an
> information provided by ODD to host so that host does not need to do TUR
> and then examine the sense code to decide if zero power ready status is
> satisfied but simply query ODD if its current power state is ZPREADY.
> So it's not that we program the device to go into ZPREADY power state
> and the ODD's power will be omitted.
>
> The benefit of a ZPREADY capable ODD is that, when we need to decide if
> the ODD is in a zero power ready status, we can simply query the ODD by
> issuing a GET_EVENT_STATUS_NOTIFICATION and check the returned power
> class events, if it is in ZPREADY power state, then we can omit the
> power. To support ZPREADY, we just need some change to the zpready
> funtion, which currently uses sense code to check ZP ready status.
>
> So this is my understanding of ZPREADY, and I don't see it as a total
> different thing with ZPODD, it just changes the way how host senses the
> zero power ready status. But if I was wrong, please kindly let me know,
> thanks.
My understanding is that a ZPREADY device may be capable of internal
power down, meaning it doesn't necessarily need the host to omit the
power. It depends what the difference is between Sleep and Off is
(they're deliberately left as implementation defined in the standard, Ch
16, but the conditions of sleep are pretty onerous, so it sounds like
most of the mechanics are powered down).
However, if you want to work it similarly to ZPODD, then the timeouts
automatically transitions to ZPREADY, the device issues an event, we
trap the event at the low level and omit power.
I'm also curious about driving sleep from autopm, since mode page timers
don't control the sleep transition.
James
^ permalink raw reply
* Re: [alsa-devel] [PATCH] usb: add USB_QUIRK_RESET_RESUME for M-Audio 49
From: Takashi Iwai @ 2012-11-26 13:04 UTC (permalink / raw)
To: Clemens Ladisch
Cc: Jonathan Nieder, Steffen Müller, alsa-devel, Olivier MATZ,
linux-pm, linux-usb, Oliver Neukum, stable, David Banks,
Ralf Lang
In-Reply-To: <50B36213.9090007@ladisch.de>
At Mon, 26 Nov 2012 13:35:31 +0100,
Clemens Ladisch wrote:
>
> Takashi Iwai wrote:> At Sun, 25 Nov 2012 23:01:27 +0100,
> > Clemens Ladisch wrote:
> >>
> >> Jonathan Nieder wrote:
> >>> Some USB MIDI keyboards fail to operate after a USB autosuspend.
> >>
> >> Make that *all* USB MIDI devices with input ports.
> >>
> >> This is not a bug in the device, but one of the many bugs introduced
> >> with the autosuspend code in <http://git.kernel.org/linus/88a8516a2128>.
> >>
> >> That patch does not handle input at all, i.e., when the driver wants to
> >> read from the device, it just doesn't take it out of suspend mode.
> >>
> >>> A workaround is to disable USB autosuspend for these devices by
> >>> putting AUTOSUSPEND_USBID_BLACKLIST="0763:2027" (resp. 0763:019b) in
> >>> /etc/laptop-mode/conf.d/usb-autosuspend.conf. In the spirit of commit
> >>> 166cb70e97bd ("usb: add USB_QUIRK_RESET_RESUME for M-Audio 88es"),
> >>> reset the device on resume so this workaround is not needed any more.
> >>
> >> It is not feasible to add the IDs of all USB MIDI devices.
> >>
> >> I'm working on a fix that adds proper power management for input ports,
> >> but this requires the driver to be reorganized a little ...
> >
> > Doesn't a simple patch like below work?
>
> > +static int substream_open(struct snd_rawmidi_substream *substream, int open)
> > {
> > + if (open && umidi->opened++ == 0) {
> > + err = usb_autopm_get_interface(umidi->iface);
> >
> > static int snd_usbmidi_input_open(struct snd_rawmidi_substream *substream)
> > {
> > + return substream_open(substream, 1);
>
> No, because the input URBs are submitted before the userspace device is
> opened. (And usb_autopm_get_interface() cannot be called from the USB
> probe callback.)
Ah, right. What's the reason of submitting input urbs for the all
time from the beginning? For loopback?
If it has to be running, the easiest fix would be the patch like
below. This will turn off the autopm essentially, but better than
breakage.
Takashi
---
diff --git a/sound/usb/midi.c b/sound/usb/midi.c
index eeefbce..66acccb 100644
--- a/sound/usb/midi.c
+++ b/sound/usb/midi.c
@@ -175,6 +175,7 @@ struct snd_usb_midi_in_endpoint {
u8 seen_f5;
u8 error_resubmit;
int current_port;
+ bool autopm_reference;
};
static void snd_usbmidi_do_output(struct snd_usb_midi_out_endpoint* ep);
@@ -2065,6 +2066,8 @@ void snd_usbmidi_input_stop(struct list_head* p)
if (ep->in)
for (j = 0; j < INPUT_URBS; ++j)
usb_kill_urb(ep->in->urbs[j]);
+ if (ep->autopm_reference)
+ usb_autopm_put_interface(umidi->iface);
}
}
@@ -2074,6 +2077,8 @@ static void snd_usbmidi_input_start_ep(struct snd_usb_midi_in_endpoint* ep)
if (!ep)
return;
+ ep->autopm_reference =
+ usb_autopm_get_interface(ep->umidi->iface) >= 0;
for (i = 0; i < INPUT_URBS; ++i) {
struct urb* urb = ep->urbs[i];
urb->dev = ep->umidi->dev;
^ permalink raw reply related
* Re: [alsa-devel] [PATCH] usb: add USB_QUIRK_RESET_RESUME for M-Audio 49
From: Clemens Ladisch @ 2012-11-26 12:35 UTC (permalink / raw)
To: Takashi Iwai
Cc: Jonathan Nieder, Steffen Müller, alsa-devel, Olivier MATZ,
linux-pm, linux-usb, Oliver Neukum, stable, David Banks,
Ralf Lang
In-Reply-To: <s5hlidoiu5y.wl%tiwai@suse.de>
Takashi Iwai wrote:> At Sun, 25 Nov 2012 23:01:27 +0100,
> Clemens Ladisch wrote:
>>
>> Jonathan Nieder wrote:
>>> Some USB MIDI keyboards fail to operate after a USB autosuspend.
>>
>> Make that *all* USB MIDI devices with input ports.
>>
>> This is not a bug in the device, but one of the many bugs introduced
>> with the autosuspend code in <http://git.kernel.org/linus/88a8516a2128>.
>>
>> That patch does not handle input at all, i.e., when the driver wants to
>> read from the device, it just doesn't take it out of suspend mode.
>>
>>> A workaround is to disable USB autosuspend for these devices by
>>> putting AUTOSUSPEND_USBID_BLACKLIST="0763:2027" (resp. 0763:019b) in
>>> /etc/laptop-mode/conf.d/usb-autosuspend.conf. In the spirit of commit
>>> 166cb70e97bd ("usb: add USB_QUIRK_RESET_RESUME for M-Audio 88es"),
>>> reset the device on resume so this workaround is not needed any more.
>>
>> It is not feasible to add the IDs of all USB MIDI devices.
>>
>> I'm working on a fix that adds proper power management for input ports,
>> but this requires the driver to be reorganized a little ...
>
> Doesn't a simple patch like below work?
> +static int substream_open(struct snd_rawmidi_substream *substream, int open)
> {
> + if (open && umidi->opened++ == 0) {
> + err = usb_autopm_get_interface(umidi->iface);
>
> static int snd_usbmidi_input_open(struct snd_rawmidi_substream *substream)
> {
> + return substream_open(substream, 1);
No, because the input URBs are submitted before the userspace device is
opened. (And usb_autopm_get_interface() cannot be called from the USB
probe callback.)
Regards,
Clemens
^ permalink raw reply
* Re: [PATCHv9 1/3] Runtime Interpreted Power Sequences
From: Alex Courbot @ 2012-11-26 11:49 UTC (permalink / raw)
To: Thierry Reding
Cc: Grant Likely, Alexandre Courbot,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Stephen Warren, Arnd Bergmann,
linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
Mark Brown, Mark Zhang, Rob Herring,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Anton Vorontsov,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
David Woodhouse,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <20121122214021.GA14771-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
On Friday 23 November 2012 05:40:21 Thierry Reding wrote:
> On Thu, Nov 22, 2012 at 01:39:41PM +0000, Grant Likely wrote:
> [...]
>
> > I do think that each sequence should be contained within a single
> > property, but I'm open to other suggestions.
>
> IIRC a very early prototype did implement something like that. However
> because of the resource issues this had to be string based, so that the
> sequences looked somewhat like (Alex, correct me if I'm wrong):
>
> power-on = <"REGULATOR", "power", 1, "GPIO", "enable", 1>;
You're right. Back when the burning sun of July was beating down a little bit
too hard on my head.
https://lkml.org/lkml/2012/7/9/30
> Instead we could possibly have something like:
>
> power-on = <0 ® 1,
> 1 &gpio 42 0 1>;
>
> Where the first cell in each entry defines the type (0 = regulator, 1 =
> GPIO) and the rest would be a regular OF specifier for the given type of
> resource along with some defined parameter such as enable/disable,
> voltage, delay in ms, ... I don't know if that sounds any better. It
> looks sort of cryptic but it is more "in the spirit of" DT, right Grant?
>
> Writing this down, it seems to me like even that proposal was already
> discussed at some point. Again, Alex may remember better.
The idea that we had was to use preprocessor support in DTC to use macros
instead of strings for the step type. We also thought about using phandles
directly in there as well, but this would require some more API support.
Anyway, at the current point we are not even sure whether we want or need
power seqs in the DT - so let's keep this topic on hold for a while. We can
still introduce the feature without DT support, and if it eventually turns out
during this winter that expressing power seqs in the DT makes sense, we will
have plenty of archives to read in front of the fire.
Alex.
^ permalink raw reply
* Re: Re: [PULL REQUEST for Rafael] PM / devfreq: pull request-3 bugfixes
From: MyungJoo Ham @ 2012-11-26 10:33 UTC (permalink / raw)
To: Rafael J. Wysocki, linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, myungjoo.ham@gmail.com,
sachin.kamat@linaro.org
> On Monday, November 26, 2012 03:41:22 PM MyungJoo Ham wrote:
> > Dear Rafael,
> >
> > sorry for the inconviences; I forgot that I've updated the tag name
> > according to the date modified.
> >
> > Please use "pull_req_20121122" tag instead of "pull_req_20121121" though
> > I've pushed pull_req_20121121 tag again, which points to the same
> > commit with pull_req_20121122 tag.
> >
> >
> > "remove compiler error" patch in this set should resolve the "build failure"
> > message sent by Stephen as well.
>
> It looks like you rebased it on top of linux-next, didn't you?
>
> Please don't do that, linux-next is evolving and the commit hashes in there
> are changing over time.
>
> I've merged your previous pull request into my pm-devfreq branch and pushed
> it out. Please rebase your new material on top of my pm-devfreq branch and
> resubmit.
>
> Thanks,
> Rafael
I've just rebased the tree and sent the pull-request message.
Sorry for all the mess invoked.
I'll remember to base on the topic branch next time.
Thank you.
Cheers,
MyungJoo.
^ permalink raw reply
* [PULL REQUEST for Rafael] PM / devfreq: rebased on pm-devfreq
From: MyungJoo Ham @ 2012-11-26 10:31 UTC (permalink / raw)
To: rjw; +Cc: linux-kernel, linux-pm, myungjoo.ham
In-Reply-To: <1562412.gSBZdyfWN8@vostro.rjw.lan>
Rafael,
Here goes the pull request rebased on your pm-devfreq branch.
Sorry for all the confusion and mess invoked.
Cheers,
MyungJoo
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The following changes since commit 1a1357ea176670867f347419c3345e2becc07338:
PM / devfreq: make devfreq_class static (2012-11-15 00:35:06 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git tags/pull_req_20121126
Jonghwa Lee (1):
PM / devfreq: Add sysfs node for representing frequency transition information.
MyungJoo Ham (2):
PM / devfreq: remove compiler error when a governor is module
PM / devfreq: missing rcu_read_lock() added for find_device_opp()
Nishanth Menon (9):
PM / devfreq: documentation cleanups for devfreq header
PM / devfreq: Add sysfs node to expose available frequencies
PM / devfreq: export update_devfreq
PM / devfreq: provide hooks for governors to be registered
PM / devfreq: register governors with devfreq framework
PM / devfreq: map devfreq drivers to governor using name
PM / devfreq: governors: add GPL module license and allow module build
PM / devfreq: allow sysfs governor node to switch governor
PM / devfreq: Add sysfs node to expose available governors
Sachin Kamat (3):
PM / devfreq: Use devm_* functions in exynos4_bus.c
PM / devfreq: Fix incorrect argument in error message
PM / devfreq: Fix return value in devfreq_remove_governor()
Sangho Yi (1):
PM / devfreq: exynos4_bus.c: Fixed an alignment of the func call args.
Documentation/ABI/testing/sysfs-class-devfreq | 29 ++-
drivers/devfreq/Kconfig | 8 +-
drivers/devfreq/devfreq.c | 413 ++++++++++++++++++++++++-
drivers/devfreq/exynos4_bus.c | 45 +--
drivers/devfreq/governor.h | 4 +
drivers/devfreq/governor_performance.c | 22 ++-
drivers/devfreq/governor_powersave.c | 22 ++-
drivers/devfreq/governor_simpleondemand.c | 22 ++-
drivers/devfreq/governor_userspace.c | 22 ++-
include/linux/devfreq.h | 95 +++---
10 files changed, 581 insertions(+), 101 deletions(-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAEBAgAGBQJQs0NoAAoJEBOhurvWBoCK2hIQAJuTMnRiWb2BkU30ENAug1FC
oNvoFBTVA2J9vTp1Q1qtoPj+ualfg++auzt4e5U2rbAthQYpB1LYDvc/ycEpGkG0
C+V3aleb9SK0TnqWp/s2i/KLWK1fTxbMGi2nDdCwwglbn59OlY6fVTyUA+jGzk3r
AwpxSCnLhi7jhtbgSWhiQh2F5gehNXGtU6CsK0OebP2VlVK5ZFw6X3eqacfact/h
kabXBsS+jJlrA90+jFFqQ4nSyU69Kgou/+de3rzrMOFYEv+uoGNmzRofh1BRaWM+
ueyKdfF/oUJWmL8fvhMY556xrTBuGpI5btSmfYxSz+VFiDzV8HduIi8ThaVKMmGu
MR77kgFSy0NkasCQ2l6q7LYIRoFJX/MQWnQpxvpZKOi5aqEgWsdCY75juRN3wOGm
kCGecK2Rq/tTj3EzIS2brUPQJPcM1YS4QHKFYq3Oucnpbk6Ym1ojIYxTB7no7fKW
7OhVOf3IHA3C0VMg8DiN9SoOW8ILU3EvknP6BguRRVf+iFjtUWqCoaNj14BOSjUx
Ol/606xgVa6xEsDG1NeoYiEov/lmYDpHG/tnh2g5gF/YrKjbQsvT7uqSBbeFJO2u
ybI2hz37OulNvur4ORFWTCOyNqknX9t+OIFFyQjdGmaPwjnJ+IZ5kWqBwPaHxd3x
Y/8iwxoohO4ROW1pBln0
=5A1F
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH 5/5] Do not use cpu_to_node() to find an offlined cpu's node.
From: Wen Congyang @ 2012-11-26 10:20 UTC (permalink / raw)
To: linux-kernel, linux-mm, linux-pm, linux-acpi, x86
Cc: Yasuaki Ishimatsu, David Rientjes, Jiang Liu, Minchan Kim,
KOSAKI Motohiro, Andrew Morton, Mel Gorman, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra, Tang Chen,
Rafael J. Wysocki, Len Brown, Lai Jiangshan, Wen Congyang
In-Reply-To: <1353925227-1877-1-git-send-email-wency@cn.fujitsu.com>
From: Tang Chen <tangchen@cn.fujitsu.com>
If a cpu is offline, its nid will be set to -1, and cpu_to_node(cpu) will
return -1. As a result, cpumask_of_node(nid) will return NULL. In this case,
find_next_bit() in for_each_cpu will get a NULL pointer and cause panic.
Here is a call trace:
[ 609.824017] Call Trace:
[ 609.824017] <IRQ>
[ 609.824017] [<ffffffff810b0721>] select_fallback_rq+0x71/0x190
[ 609.824017] [<ffffffff810b086e>] ? try_to_wake_up+0x2e/0x2f0
[ 609.824017] [<ffffffff810b0b0b>] try_to_wake_up+0x2cb/0x2f0
[ 609.824017] [<ffffffff8109da08>] ? __run_hrtimer+0x78/0x320
[ 609.824017] [<ffffffff810b0b85>] wake_up_process+0x15/0x20
[ 609.824017] [<ffffffff8109ce62>] hrtimer_wakeup+0x22/0x30
[ 609.824017] [<ffffffff8109da13>] __run_hrtimer+0x83/0x320
[ 609.824017] [<ffffffff8109ce40>] ? update_rmtp+0x80/0x80
[ 609.824017] [<ffffffff8109df56>] hrtimer_interrupt+0x106/0x280
[ 609.824017] [<ffffffff810a72c8>] ? sd_free_ctl_entry+0x68/0x70
[ 609.824017] [<ffffffff8167cf39>] smp_apic_timer_interrupt+0x69/0x99
[ 609.824017] [<ffffffff8167be2f>] apic_timer_interrupt+0x6f/0x80
There is a hrtimer process sleeping, whose cpu has already been offlined.
When it is waken up, it tries to find another cpu to run, and get a -1 nid.
As a result, cpumask_of_node(-1) returns NULL, and causes ernel panic.
This patch fixes this problem by judging if the nid is -1.
If nid is not -1, a cpu on the same node will be picked.
Else, a online cpu on another node will be picked.
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Jiang Liu <liuj97@gmail.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
---
kernel/sched/core.c | 28 +++++++++++++++++++---------
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 2d8927f..4e6404e 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1106,18 +1106,28 @@ EXPORT_SYMBOL_GPL(kick_process);
*/
static int select_fallback_rq(int cpu, struct task_struct *p)
{
- const struct cpumask *nodemask = cpumask_of_node(cpu_to_node(cpu));
+ int nid = cpu_to_node(cpu);
+ const struct cpumask *nodemask = NULL;
enum { cpuset, possible, fail } state = cpuset;
int dest_cpu;
- /* Look for allowed, online CPU in same node. */
- for_each_cpu(dest_cpu, nodemask) {
- if (!cpu_online(dest_cpu))
- continue;
- if (!cpu_active(dest_cpu))
- continue;
- if (cpumask_test_cpu(dest_cpu, tsk_cpus_allowed(p)))
- return dest_cpu;
+ /*
+ * If the node that the cpu is on has been offlined, cpu_to_node()
+ * will return -1. There is no cpu on the node, and we should
+ * select the cpu on the other node.
+ */
+ if (nid != -1) {
+ nodemask = cpumask_of_node(nid);
+
+ /* Look for allowed, online CPU in same node. */
+ for_each_cpu(dest_cpu, nodemask) {
+ if (!cpu_online(dest_cpu))
+ continue;
+ if (!cpu_active(dest_cpu))
+ continue;
+ if (cpumask_test_cpu(dest_cpu, tsk_cpus_allowed(p)))
+ return dest_cpu;
+ }
}
for (;;) {
--
1.8.0
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH 4/5] cpu-hotplug,memory-hotplug: clear cpu_to_node() when offlining the node
From: Wen Congyang @ 2012-11-26 10:20 UTC (permalink / raw)
To: linux-kernel, linux-mm, linux-pm, linux-acpi, x86
Cc: Yasuaki Ishimatsu, David Rientjes, Jiang Liu, Minchan Kim,
KOSAKI Motohiro, Andrew Morton, Mel Gorman, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra, Tang Chen,
Rafael J. Wysocki, Len Brown, Lai Jiangshan, Wen Congyang
In-Reply-To: <1353925227-1877-1-git-send-email-wency@cn.fujitsu.com>
When the node is offlined, there is no memory/cpu on the node. If a
sleep task runs on a cpu of this node, it will be migrated to the
cpu on the other node. So we can clear cpu-to-node mapping.
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Jiang Liu <liuj97@gmail.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
---
mm/memory_hotplug.c | 30 +++++++++++++++++++++++++++++-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index b7c30bb..5ae86d7 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1669,6 +1669,34 @@ static int check_cpu_on_node(void *data)
return 0;
}
+static void unmap_cpu_on_node(void *data)
+{
+#ifdef CONFIG_ACPI_NUMA
+ struct pglist_data *pgdat = data;
+ int cpu;
+
+ for_each_possible_cpu(cpu)
+ if (cpu_to_node(cpu) == pgdat->node_id)
+ numa_clear_node(cpu);
+#endif
+}
+
+static int check_and_unmap_cpu_on_node(void *data)
+{
+ int ret = check_cpu_on_node(data);
+
+ if (ret)
+ return ret;
+
+ /*
+ * the node will be offlined when we come here, so we can clear
+ * the cpu_to_node() now.
+ */
+
+ unmap_cpu_on_node(data);
+ return 0;
+}
+
/* offline the node if all memory sections of this node are removed */
void try_offline_node(int nid)
{
@@ -1695,7 +1723,7 @@ void try_offline_node(int nid)
return;
}
- if (stop_machine(check_cpu_on_node, NODE_DATA(nid), NULL))
+ if (stop_machine(check_and_unmap_cpu_on_node, NODE_DATA(nid), NULL))
return;
/*
--
1.8.0
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH 3/5] cpu-hotplug, memory-hotplug: try offline the node when hotremoving a cpu
From: Wen Congyang @ 2012-11-26 10:20 UTC (permalink / raw)
To: linux-kernel, linux-mm, linux-pm, linux-acpi, x86
Cc: Yasuaki Ishimatsu, David Rientjes, Jiang Liu, Minchan Kim,
KOSAKI Motohiro, Andrew Morton, Mel Gorman, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra, Tang Chen,
Rafael J. Wysocki, Len Brown, Lai Jiangshan, Wen Congyang
In-Reply-To: <1353925227-1877-1-git-send-email-wency@cn.fujitsu.com>
The node will be offlined when all memory/cpu on the node is hotremoved.
So we should try offline the node when hotremoving a cpu on the node.
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Jiang Liu <liuj97@gmail.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
---
drivers/acpi/processor_driver.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index a4352b8..7fc728c7 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -44,6 +44,7 @@
#include <linux/moduleparam.h>
#include <linux/cpuidle.h>
#include <linux/slab.h>
+#include <linux/memory_hotplug.h>
#include <asm/io.h>
#include <asm/cpu.h>
@@ -634,6 +635,7 @@ static int acpi_processor_remove(struct acpi_device *device, int type)
per_cpu(processors, pr->id) = NULL;
per_cpu(processor_device_array, pr->id) = NULL;
+ try_offline_node(cpu_to_node(pr->id));
free:
free_cpumask_var(pr->throttling.shared_cpu_map);
--
1.8.0
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH 2/5] memory-hotplug: export the function try_offline_node()
From: Wen Congyang @ 2012-11-26 10:20 UTC (permalink / raw)
To: linux-kernel, linux-mm, linux-pm, linux-acpi, x86
Cc: Yasuaki Ishimatsu, David Rientjes, Jiang Liu, Minchan Kim,
KOSAKI Motohiro, Andrew Morton, Mel Gorman, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra, Tang Chen,
Rafael J. Wysocki, Len Brown, Lai Jiangshan, Wen Congyang
In-Reply-To: <1353925227-1877-1-git-send-email-wency@cn.fujitsu.com>
The node will be offlined when all memory/cpu on the node
have been hotremoved. So we need the function try_offline_node()
in cpu-hotplug path.
If the memory-hotplug is disabled, and cpu-hotplug is enabled
1. no memory no the node
we don't online the node, and cpu's node is the nearest node.
2. the node contains some memory
the node has been onlined, and cpu's node is still needed
to migrate the sleep task on the cpu to the same node.
So we do nothing in try_offline_node() in this case.
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Jiang Liu <liuj97@gmail.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
---
include/linux/memory_hotplug.h | 2 ++
mm/memory_hotplug.c | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index ad2dd17..48ece75 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -187,6 +187,7 @@ extern void get_page_bootmem(unsigned long ingo, struct page *page,
void lock_memory_hotplug(void);
void unlock_memory_hotplug(void);
+extern void try_offline_node(int nid);
#else /* ! CONFIG_MEMORY_HOTPLUG */
/*
@@ -221,6 +222,7 @@ static inline void register_page_bootmem_info_node(struct pglist_data *pgdat)
static inline void lock_memory_hotplug(void) {}
static inline void unlock_memory_hotplug(void) {}
+static inline void try_offline_node(int nid) {}
#endif /* ! CONFIG_MEMORY_HOTPLUG */
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 52db031..b7c30bb 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1670,7 +1670,7 @@ static int check_cpu_on_node(void *data)
}
/* offline the node if all memory sections of this node are removed */
-static void try_offline_node(int nid)
+void try_offline_node(int nid)
{
pg_data_t *pgdat = NODE_DATA(nid);
unsigned long start_pfn = NODE_DATA(nid)->node_start_pfn;
@@ -1720,6 +1720,7 @@ static void try_offline_node(int nid)
arch_refresh_nodedata(nid, NULL);
arch_free_nodedata(pgdat);
}
+EXPORT_SYMBOL(try_offline_node);
int __ref remove_memory(int nid, u64 start, u64 size)
{
--
1.8.0
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH 1/5] cpu_hotplug: clear apicid to node when the cpu is hotremoved
From: Wen Congyang @ 2012-11-26 10:20 UTC (permalink / raw)
To: linux-kernel, linux-mm, linux-pm, linux-acpi, x86
Cc: Yasuaki Ishimatsu, David Rientjes, Jiang Liu, Minchan Kim,
KOSAKI Motohiro, Andrew Morton, Mel Gorman, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra, Tang Chen,
Rafael J. Wysocki, Len Brown, Lai Jiangshan, Wen Congyang
In-Reply-To: <1353925227-1877-1-git-send-email-wency@cn.fujitsu.com>
When a cpu is hotpluged, we call acpi_map_cpu2node() in _acpi_map_lsapic()
to store the cpu's node and apicid's node. But we don't clear the cpu's node
in acpi_unmap_lsapic() when this cpu is hotremove. If the node is also
hotremoved, we will get the following messages:
[ 1646.771485] kernel BUG at include/linux/gfp.h:329!
[ 1646.828729] invalid opcode: 0000 [#1] SMP
[ 1646.877872] Modules linked in: ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat xt_CHECKSUM iptable_mangle bridge stp llc sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables binfmt_misc dm_mirror dm_region_hash dm_log dm_mod vhost_net macvtap macvlan tun uinput iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm crc32c_intel microcode pcspkr i2c_i801 i2c_core lpc_ich mfd_core ioatdma e1000e i7core_edac edac_core sg acpi_memhotplug igb dca sd_mod crc_t10dif megaraid_sas mptsas mptscsih mptbase scsi_transport_sas scsi_mod
[ 1647.588773] Pid: 3126, comm: init Not tainted 3.6.0-rc3-tangchen-hostbridge+ #13 FUJITSU-SV PRIMEQUEST 1800E/SB
[ 1647.711545] RIP: 0010:[<ffffffff811bc3fd>] [<ffffffff811bc3fd>] allocate_slab+0x28d/0x300
[ 1647.810492] RSP: 0018:ffff88078a049cf8 EFLAGS: 00010246
[ 1647.874028] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
[ 1647.959339] RDX: 0000000000000001 RSI: 0000000000000001 RDI: 0000000000000246
[ 1648.044659] RBP: ffff88078a049d38 R08: 00000000000040d0 R09: 0000000000000001
[ 1648.129953] R10: 0000000000000000 R11: 0000000000000b5f R12: 00000000000052d0
[ 1648.215259] R13: ffff8807c1417300 R14: 0000000000030038 R15: 0000000000000003
[ 1648.300572] FS: 00007fa9b1b44700(0000) GS:ffff8807c3800000(0000) knlGS:0000000000000000
[ 1648.397272] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1648.465985] CR2: 00007fa9b09acca0 CR3: 000000078b855000 CR4: 00000000000007e0
[ 1648.551265] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1648.636565] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 1648.721838] Process init (pid: 3126, threadinfo ffff88078a048000, task ffff8807bb6f2650)
[ 1648.818534] Stack:
[ 1648.842548] ffff8807c39d7fa0 ffffffff000040d0 00000000000000bb 00000000000080d0
[ 1648.931469] ffff8807c1417300 ffff8807c39d7fa0 ffff8807c1417300 0000000000000001
[ 1649.020410] ffff88078a049d88 ffffffff811bc4a0 ffff8807c1410c80 0000000000000000
[ 1649.109464] Call Trace:
[ 1649.138713] [<ffffffff811bc4a0>] new_slab+0x30/0x1b0
[ 1649.199075] [<ffffffff811bc978>] __slab_alloc+0x358/0x4c0
[ 1649.264683] [<ffffffff810b71c0>] ? alloc_fair_sched_group+0xd0/0x1b0
[ 1649.341695] [<ffffffff811be7d4>] kmem_cache_alloc_node_trace+0xb4/0x1e0
[ 1649.421824] [<ffffffff8109d188>] ? hrtimer_init+0x48/0x100
[ 1649.488414] [<ffffffff810b71c0>] ? alloc_fair_sched_group+0xd0/0x1b0
[ 1649.565402] [<ffffffff810b71c0>] alloc_fair_sched_group+0xd0/0x1b0
[ 1649.640297] [<ffffffff810a8bce>] sched_create_group+0x3e/0x110
[ 1649.711040] [<ffffffff810bdbcd>] sched_autogroup_create_attach+0x4d/0x180
[ 1649.793260] [<ffffffff81089614>] sys_setsid+0xd4/0xf0
[ 1649.854694] [<ffffffff8167a029>] system_call_fastpath+0x16/0x1b
[ 1649.926483] Code: 89 c4 e9 73 fe ff ff 31 c0 89 de 48 c7 c7 45 de 9e 81 44 89 45 c8 e8 22 05 4b 00 85 db 44 8b 45 c8 0f 89 4f ff ff ff 0f 0b eb fe <0f> 0b 90 eb fd 0f 0b eb fe 89 de 48 c7 c7 45 de 9e 81 31 c0 44
[ 1650.161454] RIP [<ffffffff811bc3fd>] allocate_slab+0x28d/0x300
[ 1650.232348] RSP <ffff88078a049cf8>
[ 1650.274029] ---[ end trace adf84c90f3fea3e5 ]---
The reason is that: the cpu's node is not NUMA_NO_NODE, we will call
alloc_pages_exact_node() to alloc memory on the node, but the node
is offlined.
If the node is onlined, we still need cpu's node. For example:
a task on the cpu is sleeped when the cpu is hotremoved. We will
choose another cpu to run this task when it is waked up. If we
know the cpu's node, we will choose the cpu on the same node first.
So we should clear cpu-to-node mapping when the node is offlined.
This patch only clears apicid-to-node mapping when the cpu is hotremoved.
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Jiang Liu <liuj97@gmail.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
---
arch/x86/kernel/acpi/boot.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index e651f7a..f4030fe 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -691,6 +691,10 @@ EXPORT_SYMBOL(acpi_map_lsapic);
int acpi_unmap_lsapic(int cpu)
{
+#ifdef CONFIG_ACPI_NUMA
+ set_apicid_to_node(per_cpu(x86_cpu_to_apicid, cpu), NUMA_NO_NODE);
+#endif
+
per_cpu(x86_cpu_to_apicid, cpu) = -1;
set_cpu_present(cpu, false);
num_processors--;
--
1.8.0
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH 0/5] cpu-hotplug,memory-hotplug: bug fix for offlining node
From: Wen Congyang @ 2012-11-26 10:20 UTC (permalink / raw)
To: linux-kernel, linux-mm, linux-pm, linux-acpi, x86
Cc: Yasuaki Ishimatsu, David Rientjes, Jiang Liu, Minchan Kim,
KOSAKI Motohiro, Andrew Morton, Mel Gorman, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra, Tang Chen,
Rafael J. Wysocki, Len Brown, Lai Jiangshan, Wen Congyang
This patchset is based on the following patchset:
https://lkml.org/lkml/2012/11/1/93
The following patch in mm tree can be dropped now:
cpu_hotplug-unmap-cpu2node-when-the-cpu-is-hotremoved.patch
Tang Chen (1):
Do not use cpu_to_node() to find an offlined cpu's node.
Wen Congyang (4):
cpu_hotplug: clear apicid to node when the cpu is hotremoved
memory-hotplug: export the function try_offline_node()
cpu-hotplug, memory-hotplug: try offline the node when hotremoving a
cpu
cpu-hotplug,memory-hotplug: clear cpu_to_node() when offlining the
node
arch/x86/kernel/acpi/boot.c | 4 ++++
drivers/acpi/processor_driver.c | 2 ++
include/linux/memory_hotplug.h | 2 ++
kernel/sched/core.c | 28 +++++++++++++++++++---------
mm/memory_hotplug.c | 33 +++++++++++++++++++++++++++++++--
5 files changed, 58 insertions(+), 11 deletions(-)
--
1.8.0
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PULL REQUEST for Rafael] PM / devfreq: pull request-3 bugfixes
From: Rafael J. Wysocki @ 2012-11-26 10:06 UTC (permalink / raw)
To: linux-pm; +Cc: MyungJoo Ham, linux-kernel, myungjoo.ham, sachin.kamat
In-Reply-To: <1353912082-8550-1-git-send-email-myungjoo.ham@samsung.com>
On Monday, November 26, 2012 03:41:22 PM MyungJoo Ham wrote:
> Dear Rafael,
>
> sorry for the inconviences; I forgot that I've updated the tag name
> according to the date modified.
>
> Please use "pull_req_20121122" tag instead of "pull_req_20121121" though
> I've pushed pull_req_20121121 tag again, which points to the same
> commit with pull_req_20121122 tag.
>
>
> "remove compiler error" patch in this set should resolve the "build failure"
> message sent by Stephen as well.
It looks like you rebased it on top of linux-next, didn't you?
Please don't do that, linux-next is evolving and the commit hashes in there
are changing over time.
I've merged your previous pull request into my pm-devfreq branch and pushed
it out. Please rebase your new material on top of my pm-devfreq branch and
resubmit.
Thanks,
Rafael
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> The following changes since commit f928d1ce87ad5bd2152cb522de75de03be29e18b:
>
> Merge branch 'pm-cpufreq-next' into linux-next (2012-11-22 00:23:28 +0100)
> , which is HEAD of Rafael's linux-pm.git linux-next branch on 2012-11-22.
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git tags/pull_req_20121122
>
> MyungJoo Ham (2):
> PM / devfreq: remove compiler error when a governor is module
> PM / devfreq: missing rcu_read_lock() added for find_device_opp()
>
> Sachin Kamat (2):
> PM / devfreq: Fix incorrect argument in error message
> PM / devfreq: Fix return value in devfreq_remove_governor()
>
> drivers/devfreq/devfreq.c | 30 ++++++++++++++++++++++--------
> include/linux/devfreq.h | 2 +-
> 2 files changed, 23 insertions(+), 9 deletions(-)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQIcBAEBAgAGBQJQsw0gAAoJEBOhurvWBoCKFzsP/1uIw/V8sF7/Bi6yYEQVxIxF
> nrgH0BtjSMKyyEG+RJU5fz1xxkfzVIhLHeMzzTDHYG/sY7xwb+eeHWE+PFP6elvm
> NSCOqFf/olNM1dDrUsPpGPtn2Fmfl1wyAOXhdH1lHwQYyDyCgWgQtsqIck1UaLo2
> 6vn9GSl/e/DfpVtg1Wdc63ggtAFk8srZKlU3RQk/Nh/GFMTmdxtG6hibjuM88FjT
> hfFETgaZYPfX+rz36XMa/7pMQQHcrl56K8r3Pu1/RhkM8lVCwlB4tV0Y2sBGfHuL
> 2f0mbX+owjR4YuHS1QMI31Io9FB/F5KzVUdEKE73g2yalCa8ygJfMvJgQqbMYKpA
> IfxyoEvIzbH/T6+cMCQ0WaQ9Buf4KSjmmzL8MSiZB9Ny4Jw5ETg8bZjEU7cR7RWz
> i1grMqyfsjySu/N+slyY7SlvKK+58DytR2WvFvz4ba58dsqEjOoL2ovFz+W3KdlE
> 6V8DGpi2bODbejm6pXx5K6x+VqrByMYCrRpSvmSpYG9PUWpUfjFQMMPgH/uTEXR6
> dJ0H8Hv5+xtUa9sHu9A6nVVSlFgukEVN5BjIEySuX+gj5mIywwN2ZXyIp0TeAis6
> SWUBFflIbjW9JuIP1hwdcrdRsgJ/RyoQZ2XqPVZEQKJgV6C+k38ShOO9Q3YAfJHq
> sO3Gz4WUsME2nkswuwgb
> =SPXQ
> -----END PGP SIGNATURE-----
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@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.
^ permalink raw reply
* Re: [alsa-devel] [PATCH] usb: add USB_QUIRK_RESET_RESUME for M-Audio 49
From: Takashi Iwai @ 2012-11-26 9:35 UTC (permalink / raw)
To: Clemens Ladisch
Cc: Jonathan Nieder, Steffen Müller,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Olivier MATZ,
linux-pm-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
Oliver Neukum, stable-u79uwXL29TY76Z2rM5mHXA, David Banks,
Ralf Lang
In-Reply-To: <50B29537.7060007-P6GI/4k7KOmELgA04lAiVw@public.gmane.org>
At Sun, 25 Nov 2012 23:01:27 +0100,
Clemens Ladisch wrote:
>
> Jonathan Nieder wrote:
> > Some USB MIDI keyboards fail to operate after a USB autosuspend.
>
> Make that *all* USB MIDI devices with input ports.
>
> This is not a bug in the device, but one of the many bugs introduced
> with the autosuspend code in <http://git.kernel.org/linus/88a8516a2128>.
>
> That patch does not handle input at all, i.e., when the driver wants to
> read from the device, it just doesn't take it out of suspend mode.
>
> > A workaround is to disable USB autosuspend for these devices by
> > putting AUTOSUSPEND_USBID_BLACKLIST="0763:2027" (resp. 0763:019b) in
> > /etc/laptop-mode/conf.d/usb-autosuspend.conf. In the spirit of commit
> > 166cb70e97bd ("usb: add USB_QUIRK_RESET_RESUME for M-Audio 88es"),
> > reset the device on resume so this workaround is not needed any more.
>
> It is not feasible to add the IDs of all USB MIDI devices.
>
> I'm working on a fix that adds proper power management for input ports,
> but this requires the driver to be reorganized a little ...
Doesn't a simple patch like below work?
(It even reduces more lines! :)
Takashi
---
diff --git a/sound/usb/midi.c b/sound/usb/midi.c
index eeefbce..2e0fabc 100644
--- a/sound/usb/midi.c
+++ b/sound/usb/midi.c
@@ -148,7 +148,6 @@ struct snd_usb_midi_out_endpoint {
struct snd_usb_midi_out_endpoint* ep;
struct snd_rawmidi_substream *substream;
int active;
- bool autopm_reference;
uint8_t cable; /* cable number << 4 */
uint8_t state;
#define STATE_UNKNOWN 0
@@ -1033,29 +1032,35 @@ static void update_roland_altsetting(struct snd_usb_midi* umidi)
snd_usbmidi_input_start(&umidi->list);
}
-static void substream_open(struct snd_rawmidi_substream *substream, int open)
+static int substream_open(struct snd_rawmidi_substream *substream, int open)
{
struct snd_usb_midi* umidi = substream->rmidi->private_data;
struct snd_kcontrol *ctl;
+ int err = 0;
mutex_lock(&umidi->mutex);
- if (open) {
- if (umidi->opened++ == 0 && umidi->roland_load_ctl) {
+ if (open && umidi->opened++ == 0) {
+ err = usb_autopm_get_interface(umidi->iface);
+ if (err == -EACCES)
+ err = 0;
+ if (!err && umidi->roland_load_ctl) {
ctl = umidi->roland_load_ctl;
ctl->vd[0].access |= SNDRV_CTL_ELEM_ACCESS_INACTIVE;
snd_ctl_notify(umidi->card,
SNDRV_CTL_EVENT_MASK_INFO, &ctl->id);
update_roland_altsetting(umidi);
}
- } else {
- if (--umidi->opened == 0 && umidi->roland_load_ctl) {
+ } else if (!open && --umidi->opened == 0) {
+ if (umidi->roland_load_ctl) {
ctl = umidi->roland_load_ctl;
ctl->vd[0].access &= ~SNDRV_CTL_ELEM_ACCESS_INACTIVE;
snd_ctl_notify(umidi->card,
SNDRV_CTL_EVENT_MASK_INFO, &ctl->id);
}
+ usb_autopm_put_interface(umidi->iface);
}
mutex_unlock(&umidi->mutex);
+ return err;
}
static int snd_usbmidi_output_open(struct snd_rawmidi_substream *substream)
@@ -1076,25 +1081,17 @@ static int snd_usbmidi_output_open(struct snd_rawmidi_substream *substream)
snd_BUG();
return -ENXIO;
}
- err = usb_autopm_get_interface(umidi->iface);
- port->autopm_reference = err >= 0;
- if (err < 0 && err != -EACCES)
- return -EIO;
+ err = substream_open(substream, 1);
+ if (err < 0)
+ return err;
substream->runtime->private_data = port;
port->state = STATE_UNKNOWN;
- substream_open(substream, 1);
return 0;
}
static int snd_usbmidi_output_close(struct snd_rawmidi_substream *substream)
{
- struct snd_usb_midi* umidi = substream->rmidi->private_data;
- struct usbmidi_out_port *port = substream->runtime->private_data;
-
- substream_open(substream, 0);
- if (port->autopm_reference)
- usb_autopm_put_interface(umidi->iface);
- return 0;
+ return substream_open(substream, 0);
}
static void snd_usbmidi_output_trigger(struct snd_rawmidi_substream *substream, int up)
@@ -1147,14 +1144,12 @@ static void snd_usbmidi_output_drain(struct snd_rawmidi_substream *substream)
static int snd_usbmidi_input_open(struct snd_rawmidi_substream *substream)
{
- substream_open(substream, 1);
- return 0;
+ return substream_open(substream, 1);
}
static int snd_usbmidi_input_close(struct snd_rawmidi_substream *substream)
{
- substream_open(substream, 0);
- return 0;
+ return substream_open(substream, 0);
}
static void snd_usbmidi_input_trigger(struct snd_rawmidi_substream *substream, int up)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v9 06/10] ata: zpodd: check zero power ready status
From: Aaron Lu @ 2012-11-26 8:27 UTC (permalink / raw)
To: James Bottomley
Cc: Rafael J. Wysocki, Tejun Heo, Jeff Garzik, Alan Stern, Jeff Wu,
Aaron Lu, linux-ide, linux-pm, linux-scsi, linux-acpi
In-Reply-To: <1353915142.2523.36.camel@dabdike>
On 11/26/2012 03:32 PM, James Bottomley wrote:
> On Mon, 2012-11-26 at 13:09 +0800, Aaron Lu wrote:
>> On 11/26/2012 01:03 PM, James Bottomley wrote:
>>> On Mon, 2012-11-26 at 01:33 +0100, Rafael J. Wysocki wrote:
>>>> On Monday, November 19, 2012 03:06:51 PM James Bottomley wrote:
>>>>>> I really think we need a way for (auto)pm and event polling to talk to
>>>>>> each other so that autopm can tell event poll to sod off while pm is
>>>>>> in effect. Trying to solve this from inside libata doesn't seem
>>>>>> right. The problem, again, seems to be figuring out which hardware
>>>>>> device maps to which block device. Hmmm... Any good ideas?
>>>>>
>>>>> I've asked the PM people several times about this, because it's a real
>>>>> problem for almost everything: PM needs some type of top to bottom
>>>>> stack view, which the layering isolation we have within storage really
>>>>> doesn't cope with well. No real suggestion has been forthcoming.
>>>>
>>>> Actually, I think that the particular case in question is really special
>>>> and the fact that there's the pollig loop that user space is involved in
>>>> doesn't make things more stratightforward.
>>>>
>>>> And PM really doesn't need to see things top to bottom, but the polling
>>>> needs to know what happens in the PM land. We need to be able to tell it
>>>> "from now on tell user space that there are no events here". The question
>>>> is where to put that information so that it's accessible to all parts of the
>>>> stack involved.
>>>
>>> Right, open to suggestions ...
>>>
>>>>> The reason I think it should be emulated (in the acpi layer, not libata,
>>>>> but as long as it's not in SCSI, I'm not so fussed where it ends up) is
>>>>> because ZPODD is the software equivalent of ZPREADY, which will be done
>>>>> in hardware and will be effectively invisible to autopm in the same way
>>>>> that SCSI (and ATA) power management is mostly invisible. If we
>>>>> currently do ZPREADY emulation in the low layer (i.e. ZPODD has exact
>>>>> ZPREADY emulation), we won't care (except for flipping the sofware bit)
>>>>> whether the device support ZPODD or ZPREADY and it will all just
>>>>> work(tm). The industry expectation is that ZPODD is just a transition
>>>>> state between current power management and ZPREADY.
>>>>
>>>> Well, if you poll a ZPREADY-capable drive, it will go off and on in cycles
>>>> transparently, but still it won't save as much energy as it can. We'll need
>>>> to do something about the polling in that case too, it seems.
>>>
>>> No: with ZPREADY, the device effectively lies to the poll. The Spec
>>> says that when it powers off the mechanical pieces, it must reply from
>>> firmware to a certain preset emulations of SCSI commands and not wake
>>> from power off. These commands include TEST UNIT READY and a few
>>> others, so the device will happily reply to polls while being off (it
>>> replies with the original state before power was lost). When you issue
>>> actual medium access commands, or manually insert or remove media it
>>> will wake up.
>>>
>>> That's why I think ZPODD should emulate this behaviour.
>>
>> I suppose you are refering to section 15.3.5?
>
> That's the recommendation for emulating ZPREADY in ZPODD devices, yes.
>
>> I don't think the SPEC says what the host software _must_ do, it's
>> informative. And I agree that when possible, we should emulate the
>> command without powering up the ODD, but if we can eliminate the noise,
>> wouldn't that be better?
>
> The way I look at it is we currently have no real power management for
> actual SCSI devices, we rely on the internal timers of the device to
> effect power management for us. ZPREADY fits right into this scheme (as
> I think it was designed to) so it seems odd to me that we would
> introduce a software PM based scheme for ZPODD, which is an interim spec
> until everything supports ZPREADY, and then go back to doing nothing for
> ZPREADY.
>
> I'm amenable to a proposal that we *shouldn't* be doing nothing for SCSI
> PM and perhaps it should be plumbed into software PM, but it looks odd
> to me to have sofware PM for ZPODD but not for at least ZPREADY and
> probably for SCSI PM as well.
Well, ZPREADY is not a power state that we can program the ODD to
enter(figure 234 and table 323 of the SPEC), it servers more like an
information provided by ODD to host so that host does not need to do TUR
and then examine the sense code to decide if zero power ready status is
satisfied but simply query ODD if its current power state is ZPREADY.
So it's not that we program the device to go into ZPREADY power state
and the ODD's power will be omitted.
The benefit of a ZPREADY capable ODD is that, when we need to decide if
the ODD is in a zero power ready status, we can simply query the ODD by
issuing a GET_EVENT_STATUS_NOTIFICATION and check the returned power
class events, if it is in ZPREADY power state, then we can omit the
power. To support ZPREADY, we just need some change to the zpready
funtion, which currently uses sense code to check ZP ready status.
So this is my understanding of ZPREADY, and I don't see it as a total
different thing with ZPODD, it just changes the way how host senses the
zero power ready status. But if I was wrong, please kindly let me know,
thanks.
-Aaron
>
> If we elect to do nothing about ZPREADY and SCSI PM, then I think ZPODD
> should be implemented in a way that emulates ZPREADY (i.e. as section
> 15.3.5 recommends).
>
> James
>
>
^ permalink raw reply
* Re: [PATCH v9 06/10] ata: zpodd: check zero power ready status
From: James Bottomley @ 2012-11-26 7:32 UTC (permalink / raw)
To: Aaron Lu
Cc: Rafael J. Wysocki, Tejun Heo, Jeff Garzik, Alan Stern, Jeff Wu,
Aaron Lu, linux-ide, linux-pm, linux-scsi, linux-acpi
In-Reply-To: <50B2F96D.9080405@intel.com>
On Mon, 2012-11-26 at 13:09 +0800, Aaron Lu wrote:
> On 11/26/2012 01:03 PM, James Bottomley wrote:
> > On Mon, 2012-11-26 at 01:33 +0100, Rafael J. Wysocki wrote:
> >> On Monday, November 19, 2012 03:06:51 PM James Bottomley wrote:
> >>>> I really think we need a way for (auto)pm and event polling to talk to
> >>>> each other so that autopm can tell event poll to sod off while pm is
> >>>> in effect. Trying to solve this from inside libata doesn't seem
> >>>> right. The problem, again, seems to be figuring out which hardware
> >>>> device maps to which block device. Hmmm... Any good ideas?
> >>>
> >>> I've asked the PM people several times about this, because it's a real
> >>> problem for almost everything: PM needs some type of top to bottom
> >>> stack view, which the layering isolation we have within storage really
> >>> doesn't cope with well. No real suggestion has been forthcoming.
> >>
> >> Actually, I think that the particular case in question is really special
> >> and the fact that there's the pollig loop that user space is involved in
> >> doesn't make things more stratightforward.
> >>
> >> And PM really doesn't need to see things top to bottom, but the polling
> >> needs to know what happens in the PM land. We need to be able to tell it
> >> "from now on tell user space that there are no events here". The question
> >> is where to put that information so that it's accessible to all parts of the
> >> stack involved.
> >
> > Right, open to suggestions ...
> >
> >>> The reason I think it should be emulated (in the acpi layer, not libata,
> >>> but as long as it's not in SCSI, I'm not so fussed where it ends up) is
> >>> because ZPODD is the software equivalent of ZPREADY, which will be done
> >>> in hardware and will be effectively invisible to autopm in the same way
> >>> that SCSI (and ATA) power management is mostly invisible. If we
> >>> currently do ZPREADY emulation in the low layer (i.e. ZPODD has exact
> >>> ZPREADY emulation), we won't care (except for flipping the sofware bit)
> >>> whether the device support ZPODD or ZPREADY and it will all just
> >>> work(tm). The industry expectation is that ZPODD is just a transition
> >>> state between current power management and ZPREADY.
> >>
> >> Well, if you poll a ZPREADY-capable drive, it will go off and on in cycles
> >> transparently, but still it won't save as much energy as it can. We'll need
> >> to do something about the polling in that case too, it seems.
> >
> > No: with ZPREADY, the device effectively lies to the poll. The Spec
> > says that when it powers off the mechanical pieces, it must reply from
> > firmware to a certain preset emulations of SCSI commands and not wake
> > from power off. These commands include TEST UNIT READY and a few
> > others, so the device will happily reply to polls while being off (it
> > replies with the original state before power was lost). When you issue
> > actual medium access commands, or manually insert or remove media it
> > will wake up.
> >
> > That's why I think ZPODD should emulate this behaviour.
>
> I suppose you are refering to section 15.3.5?
That's the recommendation for emulating ZPREADY in ZPODD devices, yes.
> I don't think the SPEC says what the host software _must_ do, it's
> informative. And I agree that when possible, we should emulate the
> command without powering up the ODD, but if we can eliminate the noise,
> wouldn't that be better?
The way I look at it is we currently have no real power management for
actual SCSI devices, we rely on the internal timers of the device to
effect power management for us. ZPREADY fits right into this scheme (as
I think it was designed to) so it seems odd to me that we would
introduce a software PM based scheme for ZPODD, which is an interim spec
until everything supports ZPREADY, and then go back to doing nothing for
ZPREADY.
I'm amenable to a proposal that we *shouldn't* be doing nothing for SCSI
PM and perhaps it should be plumbed into software PM, but it looks odd
to me to have sofware PM for ZPODD but not for at least ZPREADY and
probably for SCSI PM as well.
If we elect to do nothing about ZPREADY and SCSI PM, then I think ZPODD
should be implemented in a way that emulates ZPREADY (i.e. as section
15.3.5 recommends).
James
^ permalink raw reply
* [PULL REQUEST for Rafael] PM / devfreq: pull request-3 bugfixes
From: MyungJoo Ham @ 2012-11-26 6:41 UTC (permalink / raw)
To: rjw; +Cc: linux-kernel, linux-pm, myungjoo.ham, sachin.kamat
In-Reply-To: <3622510.QVzP2QoHuh@vostro.rjw.lan>
Dear Rafael,
sorry for the inconviences; I forgot that I've updated the tag name
according to the date modified.
Please use "pull_req_20121122" tag instead of "pull_req_20121121" though
I've pushed pull_req_20121121 tag again, which points to the same
commit with pull_req_20121122 tag.
"remove compiler error" patch in this set should resolve the "build failure"
message sent by Stephen as well.
Cheers,
MyungJoo
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The following changes since commit f928d1ce87ad5bd2152cb522de75de03be29e18b:
Merge branch 'pm-cpufreq-next' into linux-next (2012-11-22 00:23:28 +0100)
, which is HEAD of Rafael's linux-pm.git linux-next branch on 2012-11-22.
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git tags/pull_req_20121122
MyungJoo Ham (2):
PM / devfreq: remove compiler error when a governor is module
PM / devfreq: missing rcu_read_lock() added for find_device_opp()
Sachin Kamat (2):
PM / devfreq: Fix incorrect argument in error message
PM / devfreq: Fix return value in devfreq_remove_governor()
drivers/devfreq/devfreq.c | 30 ++++++++++++++++++++++--------
include/linux/devfreq.h | 2 +-
2 files changed, 23 insertions(+), 9 deletions(-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAEBAgAGBQJQsw0gAAoJEBOhurvWBoCKFzsP/1uIw/V8sF7/Bi6yYEQVxIxF
nrgH0BtjSMKyyEG+RJU5fz1xxkfzVIhLHeMzzTDHYG/sY7xwb+eeHWE+PFP6elvm
NSCOqFf/olNM1dDrUsPpGPtn2Fmfl1wyAOXhdH1lHwQYyDyCgWgQtsqIck1UaLo2
6vn9GSl/e/DfpVtg1Wdc63ggtAFk8srZKlU3RQk/Nh/GFMTmdxtG6hibjuM88FjT
hfFETgaZYPfX+rz36XMa/7pMQQHcrl56K8r3Pu1/RhkM8lVCwlB4tV0Y2sBGfHuL
2f0mbX+owjR4YuHS1QMI31Io9FB/F5KzVUdEKE73g2yalCa8ygJfMvJgQqbMYKpA
IfxyoEvIzbH/T6+cMCQ0WaQ9Buf4KSjmmzL8MSiZB9Ny4Jw5ETg8bZjEU7cR7RWz
i1grMqyfsjySu/N+slyY7SlvKK+58DytR2WvFvz4ba58dsqEjOoL2ovFz+W3KdlE
6V8DGpi2bODbejm6pXx5K6x+VqrByMYCrRpSvmSpYG9PUWpUfjFQMMPgH/uTEXR6
dJ0H8Hv5+xtUa9sHu9A6nVVSlFgukEVN5BjIEySuX+gj5mIywwN2ZXyIp0TeAis6
SWUBFflIbjW9JuIP1hwdcrdRsgJ/RyoQZ2XqPVZEQKJgV6C+k38ShOO9Q3YAfJHq
sO3Gz4WUsME2nkswuwgb
=SPXQ
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH] MAINTAINERS: Add maintainers for exynos thermal driver
From: Jonghwa Lee @ 2012-11-26 6:30 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, linux-pm, Len Brown, Zhang Rui, Durgadoss R,
Rafael J. Wysocki, Amit Dinel Kachhap, MyungJoo Ham,
Kyungmin Park, Chanwoo Choi, Jonghwa Lee
Add Amit and I as maintainers for exynos thermal driver.
Signed-off-by: Jonghwa Lee <jonghwa3.lee@samsung.com>
---
MAINTAINERS | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 59203e7..e839fb8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2960,6 +2960,13 @@ S: Maintained
F: drivers/video/exynos/exynos_mipi*
F: include/video/exynos_mipi*
+EXYNOS THERMAL DRIVER
+M: Jonghwa Lee <jonghwa3.lee@samsung.com>
+M: Amit Daniel Kachhap <amit.kachhap@linaro.org>
+L: linux-pm@vger.kernel.org
+S: Maintained
+F: drivers/thermal/exynos_thermal.c
+
F71805F HARDWARE MONITORING DRIVER
M: Jean Delvare <khali@linux-fr.org>
L: lm-sensors@lm-sensors.org
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH 0/2] ACPI / platform: Put devices enumerated via ACPI into D0 before probing drivers
From: Mika Westerberg @ 2012-11-26 6:31 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: LKML, Greg Kroah-Hartman, Linux PM list, ACPI Devel Maling List,
Zhang Rui, Svahn, Kai, Huang Ying, Lan, Tianyu, Zheng, Lv,
Aaron Lu, Grant Likely
In-Reply-To: <1672179.qgDUs0YdYu@vostro.rjw.lan>
On Sun, Nov 25, 2012 at 03:54:14PM +0100, Rafael J. Wysocki wrote:
> The following two patches are meant to work around a problem where some
> devices may be in the ACPI D3cold power state (power off) before their
> drivers' .probe() routines are called, but those routines assume devices
> to be operational. They also allow ACPI PM to be used going forward with
> the devices in question.
We have such machines here. I've tested the series on one of them and it
solves the problem - drivers can now access device registers right from the
start.
> [1/2] - Allow ACPI PM attach/detach routines to change device power states.
> [2/2] - Call the ACPI PM attach/detach routines in the platform probe and
> remove/shutdown callbacks (and change power states of devices as
> necessary).
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
^ permalink raw reply
* Re: [RESEND PATCH] MAINTAINERS: Add maintainers for exynos thermal driver
From: Zhang Rui @ 2012-11-26 6:22 UTC (permalink / raw)
To: Jonghwa Lee
Cc: linux-pm, linux-kernel, Len Brown, Durgadoss R, Rafael J. Wysocki,
Amit Dinel Kachhap, MyungJoo Ham, Kyungmin Park, Chanwoo Choi
In-Reply-To: <1353905151-20735-1-git-send-email-jonghwa3.lee@samsung.com>
please send this patch to Linus and cc the list.
thanks,
rui
On Mon, 2012-11-26 at 13:45 +0900, Jonghwa Lee wrote:
> Add Amit and I as maintainers for exynos thermal driver.
>
> Signed-off-by: Jonghwa Lee <jonghwa3.lee@samsung.com>
> ---
> MAINTAINERS | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 59203e7..e839fb8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2960,6 +2960,13 @@ S: Maintained
> F: drivers/video/exynos/exynos_mipi*
> F: include/video/exynos_mipi*
>
> +EXYNOS THERMAL DRIVER
> +M: Jonghwa Lee <jonghwa3.lee@samsung.com>
> +M: Amit Daniel Kachhap <amit.kachhap@linaro.org>
> +L: linux-pm@vger.kernel.org
> +S: Maintained
> +F: drivers/thermal/exynos_thermal.c
> +
> F71805F HARDWARE MONITORING DRIVER
> M: Jean Delvare <khali@linux-fr.org>
> L: lm-sensors@lm-sensors.org
^ permalink raw reply
* Re: [PATCH v9 06/10] ata: zpodd: check zero power ready status
From: Aaron Lu @ 2012-11-26 5:09 UTC (permalink / raw)
To: James Bottomley
Cc: Rafael J. Wysocki, Tejun Heo, Jeff Garzik, Alan Stern, Jeff Wu,
Aaron Lu, linux-ide, linux-pm, linux-scsi, linux-acpi
In-Reply-To: <1353906191.2523.25.camel@dabdike>
On 11/26/2012 01:03 PM, James Bottomley wrote:
> On Mon, 2012-11-26 at 01:33 +0100, Rafael J. Wysocki wrote:
>> On Monday, November 19, 2012 03:06:51 PM James Bottomley wrote:
>>>> I really think we need a way for (auto)pm and event polling to talk to
>>>> each other so that autopm can tell event poll to sod off while pm is
>>>> in effect. Trying to solve this from inside libata doesn't seem
>>>> right. The problem, again, seems to be figuring out which hardware
>>>> device maps to which block device. Hmmm... Any good ideas?
>>>
>>> I've asked the PM people several times about this, because it's a real
>>> problem for almost everything: PM needs some type of top to bottom
>>> stack view, which the layering isolation we have within storage really
>>> doesn't cope with well. No real suggestion has been forthcoming.
>>
>> Actually, I think that the particular case in question is really special
>> and the fact that there's the pollig loop that user space is involved in
>> doesn't make things more stratightforward.
>>
>> And PM really doesn't need to see things top to bottom, but the polling
>> needs to know what happens in the PM land. We need to be able to tell it
>> "from now on tell user space that there are no events here". The question
>> is where to put that information so that it's accessible to all parts of the
>> stack involved.
>
> Right, open to suggestions ...
>
>>> The reason I think it should be emulated (in the acpi layer, not libata,
>>> but as long as it's not in SCSI, I'm not so fussed where it ends up) is
>>> because ZPODD is the software equivalent of ZPREADY, which will be done
>>> in hardware and will be effectively invisible to autopm in the same way
>>> that SCSI (and ATA) power management is mostly invisible. If we
>>> currently do ZPREADY emulation in the low layer (i.e. ZPODD has exact
>>> ZPREADY emulation), we won't care (except for flipping the sofware bit)
>>> whether the device support ZPODD or ZPREADY and it will all just
>>> work(tm). The industry expectation is that ZPODD is just a transition
>>> state between current power management and ZPREADY.
>>
>> Well, if you poll a ZPREADY-capable drive, it will go off and on in cycles
>> transparently, but still it won't save as much energy as it can. We'll need
>> to do something about the polling in that case too, it seems.
>
> No: with ZPREADY, the device effectively lies to the poll. The Spec
> says that when it powers off the mechanical pieces, it must reply from
> firmware to a certain preset emulations of SCSI commands and not wake
> from power off. These commands include TEST UNIT READY and a few
> others, so the device will happily reply to polls while being off (it
> replies with the original state before power was lost). When you issue
> actual medium access commands, or manually insert or remove media it
> will wake up.
>
> That's why I think ZPODD should emulate this behaviour.
I suppose you are refering to section 15.3.5?
I don't think the SPEC says what the host software _must_ do, it's
informative. And I agree that when possible, we should emulate the
command without powering up the ODD, but if we can eliminate the noise,
wouldn't that be better?
-Aaron
>
> James
>
>
^ permalink raw reply
* Re: [PATCH v9 06/10] ata: zpodd: check zero power ready status
From: James Bottomley @ 2012-11-26 5:03 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Tejun Heo, Aaron Lu, Jeff Garzik, Alan Stern, Jeff Wu, Aaron Lu,
linux-ide, linux-pm, linux-scsi, linux-acpi
In-Reply-To: <35648985.61QNrr0Knq@vostro.rjw.lan>
On Mon, 2012-11-26 at 01:33 +0100, Rafael J. Wysocki wrote:
> On Monday, November 19, 2012 03:06:51 PM James Bottomley wrote:
> > > I really think we need a way for (auto)pm and event polling to talk to
> > > each other so that autopm can tell event poll to sod off while pm is
> > > in effect. Trying to solve this from inside libata doesn't seem
> > > right. The problem, again, seems to be figuring out which hardware
> > > device maps to which block device. Hmmm... Any good ideas?
> >
> > I've asked the PM people several times about this, because it's a real
> > problem for almost everything: PM needs some type of top to bottom
> > stack view, which the layering isolation we have within storage really
> > doesn't cope with well. No real suggestion has been forthcoming.
>
> Actually, I think that the particular case in question is really special
> and the fact that there's the pollig loop that user space is involved in
> doesn't make things more stratightforward.
>
> And PM really doesn't need to see things top to bottom, but the polling
> needs to know what happens in the PM land. We need to be able to tell it
> "from now on tell user space that there are no events here". The question
> is where to put that information so that it's accessible to all parts of the
> stack involved.
Right, open to suggestions ...
> > The reason I think it should be emulated (in the acpi layer, not libata,
> > but as long as it's not in SCSI, I'm not so fussed where it ends up) is
> > because ZPODD is the software equivalent of ZPREADY, which will be done
> > in hardware and will be effectively invisible to autopm in the same way
> > that SCSI (and ATA) power management is mostly invisible. If we
> > currently do ZPREADY emulation in the low layer (i.e. ZPODD has exact
> > ZPREADY emulation), we won't care (except for flipping the sofware bit)
> > whether the device support ZPODD or ZPREADY and it will all just
> > work(tm). The industry expectation is that ZPODD is just a transition
> > state between current power management and ZPREADY.
>
> Well, if you poll a ZPREADY-capable drive, it will go off and on in cycles
> transparently, but still it won't save as much energy as it can. We'll need
> to do something about the polling in that case too, it seems.
No: with ZPREADY, the device effectively lies to the poll. The Spec
says that when it powers off the mechanical pieces, it must reply from
firmware to a certain preset emulations of SCSI commands and not wake
from power off. These commands include TEST UNIT READY and a few
others, so the device will happily reply to polls while being off (it
replies with the original state before power was lost). When you issue
actual medium access commands, or manually insert or remove media it
will wake up.
That's why I think ZPODD should emulate this behaviour.
James
^ permalink raw reply
* [RESEND PATCH] MAINTAINERS: Add maintainers for exynos thermal driver
From: Jonghwa Lee @ 2012-11-26 4:45 UTC (permalink / raw)
To: linux-pm
Cc: linux-kernel, Len Brown, Zhang Rui, Durgadoss R,
Rafael J. Wysocki, Amit Dinel Kachhap, MyungJoo Ham,
Kyungmin Park, Chanwoo Choi, Jonghwa Lee
Add Amit and I as maintainers for exynos thermal driver.
Signed-off-by: Jonghwa Lee <jonghwa3.lee@samsung.com>
---
MAINTAINERS | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 59203e7..e839fb8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2960,6 +2960,13 @@ S: Maintained
F: drivers/video/exynos/exynos_mipi*
F: include/video/exynos_mipi*
+EXYNOS THERMAL DRIVER
+M: Jonghwa Lee <jonghwa3.lee@samsung.com>
+M: Amit Daniel Kachhap <amit.kachhap@linaro.org>
+L: linux-pm@vger.kernel.org
+S: Maintained
+F: drivers/thermal/exynos_thermal.c
+
F71805F HARDWARE MONITORING DRIVER
M: Jean Delvare <khali@linux-fr.org>
L: lm-sensors@lm-sensors.org
--
1.7.4.1
^ permalink raw reply related
* [PATCH] MAINTAINERS: Add maintainers for exynos thermal driver
From: Jonghwa Lee @ 2012-11-26 4:17 UTC (permalink / raw)
To: linux-pm
Cc: linux-kernel, Len Brown, Zhang Rui, Durgadoss R,
Rafael J. Wysocki, Amit Dinel Kachhap, MyungJoo Ham,
Kyungmin Park, Chanwoo Choi, Jonghwa Lee
Add Amit and I as maintainers for exynos thermal driver.
Signed-off-by: Jonghwa Lee <jonghwa3.lee@samsung.com>
---
MAINTAINERS | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 59203e7..cceedca 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2960,6 +2960,13 @@ S: Maintained
F: drivers/video/exynos/exynos_mipi*
F: include/video/exynos_mipi*
+EXYNOS THREMAL DRIVER
+M: Amit Daniel Kachhap <amit.kachhap@linaro.org>
+M: Jonghwa Lee <jonghwa3.lee@samsung.com>
+L: linux-pm@vger.kernel.org
+S: Maintained
+F: drivers/thermal/exynos_thermal.c
+
F71805F HARDWARE MONITORING DRIVER
M: Jean Delvare <khali@linux-fr.org>
L: lm-sensors@lm-sensors.org
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH 2/3] thermal: rcar: add rcar_zone_to_priv() macro
From: Zhang Rui @ 2012-11-26 2:59 UTC (permalink / raw)
To: Kuninori Morimoto; +Cc: Simon, Magnus, linux-pm, Kuninori Morimoto
In-Reply-To: <87fw3xw0um.wl%kuninori.morimoto.gx@renesas.com>
On Sun, 2012-11-25 at 18:32 -0800, Kuninori Morimoto wrote:
> This patch adds rcar_zone_to_priv()
> which is a helper macro for gettign private data.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
applied.
thanks,
rui
> ---
> drivers/thermal/rcar_thermal.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
> index f2678ff..90db951 100644
> --- a/drivers/thermal/rcar_thermal.c
> +++ b/drivers/thermal/rcar_thermal.c
> @@ -44,6 +44,7 @@ struct rcar_thermal_priv {
> };
>
> #define MCELSIUS(temp) ((temp) * 1000)
> +#define rcar_zone_to_priv(zone) (zone->devdata)
>
> /*
> * basic functions
> @@ -98,7 +99,7 @@ static void rcar_thermal_bset(struct rcar_thermal_priv *priv, u32 reg,
> static int rcar_thermal_get_temp(struct thermal_zone_device *zone,
> unsigned long *temp)
> {
> - struct rcar_thermal_priv *priv = zone->devdata;
> + struct rcar_thermal_priv *priv = rcar_zone_to_priv(zone);
> int val, min, max, tmp;
>
> tmp = -200; /* default */
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox