From: Mauro Carvalho Chehab <mchehab@redhat.com> To: <balbi@ti.com> Cc: Greg KH <gregkh@linuxfoundation.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Steven Rostedt <rostedt@goodmis.org>, Frederic Weisbecker <fweisbec@gmail.com>, Ingo Molnar <mingo@redhat.com>, <JBottomley@parallels.com>, <linux-scsi@vger.kernel.org>, <davem@davemloft.net>, <netdev@vger.kernel.org>, Doug Thompson <dougthompson@xmission.com>, <linux-edac@vger.kernel.org>, <rjw@sisk.pl>, <linux-pm@vger.kernel.org> Subject: Re: SYSFS "errors" Date: Mon, 18 Feb 2013 16:46:38 -0300 [thread overview] Message-ID: <20130218164638.7cb53baa@redhat.com> (raw) In-Reply-To: <20130218184633.GC10755@arwen.pp.htv.fi> Em Mon, 18 Feb 2013 20:46:33 +0200 Felipe Balbi <balbi@ti.com> escreveu: > Hi, On Mon, Feb 18, 2013 at 09:49:16AM -0800, Greg KH wrote: > > > Input/output error - /sys/devices/cpu/power/autosuspend_delay_ms > > > > The issue with this file is, if the power.use_autosuspend flag is not > > set for the device, then it can't be read or written to. This flag > > changes dynamically with the system state > > (__pm_runtime_use_autosuspend() can change it), so we can't just not > > show the file if the flag is not set properly, sorry. > > > > So the "error" is correct here, as is the 0644 file value. > > hmm... we could create the file at pm_runtime_enable() time and remove > it on pm_runtime_disable() time, no ? Addin Rafael to Cc ... > > > > > No such device - /sys/devices/system/edac/mc/mc0/sdram_scrub_rate > > > > Odd, go ask the edac developers > > will do ;-) Well, the question is missing ;) /me assumes that you want to talk about suspending/resume and EDAC, right? In general, memory controllers don't supports suspend, as far as I can tell. Still, I've seen a few ones that support, but the current drivers and/or the EDAC core currently doesn't offer any support to it, as such setup is done by the BIOS, when it detects the used DIMM banks. I suspect that, when the OS puts the machine on a suspend state, the BIOS may also suspend also the memory controller or put it into a low power consumption mode, but it does it without any help from the EDAC drivers. For most of what's there at EDAC, I don't think it is worth to add any PM support inside it. There are, however, two cases were we may need to add some support: 1) if user changed the SDRAM scrub rate before suspending, it makes sense to restore it after resume, on the memory controller drivers that support such feature (not all supports it); 2) hot-pluggable DIMMs. EDAC currently doesn't support. This could be needed on some future. In this case, the core may need to re-scan the memory controller, changing the memory properties. I've no idea if is there any real case needing it, nor what event would trigger the memory-controller re-scan. Resume is likely one of the candidates for it, on machines that support hot-pluggable memories. Regards, Mauro
WARNING: multiple messages have this Message-ID (diff)
From: Mauro Carvalho Chehab <mchehab@redhat.com> To: balbi@ti.com Cc: Greg KH <gregkh@linuxfoundation.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Steven Rostedt <rostedt@goodmis.org>, Frederic Weisbecker <fweisbec@gmail.com>, Ingo Molnar <mingo@redhat.com>, JBottomley@parallels.com, linux-scsi@vger.kernel.org, davem@davemloft.net, netdev@vger.kernel.org, Doug Thompson <dougthompson@xmission.com>, linux-edac@vger.kernel.org, rjw@sisk.pl, linux-pm@vger.kernel.org Subject: Re: SYSFS "errors" Date: Mon, 18 Feb 2013 16:46:38 -0300 [thread overview] Message-ID: <20130218164638.7cb53baa@redhat.com> (raw) In-Reply-To: <20130218184633.GC10755@arwen.pp.htv.fi> Em Mon, 18 Feb 2013 20:46:33 +0200 Felipe Balbi <balbi@ti.com> escreveu: > Hi, On Mon, Feb 18, 2013 at 09:49:16AM -0800, Greg KH wrote: > > > Input/output error - /sys/devices/cpu/power/autosuspend_delay_ms > > > > The issue with this file is, if the power.use_autosuspend flag is not > > set for the device, then it can't be read or written to. This flag > > changes dynamically with the system state > > (__pm_runtime_use_autosuspend() can change it), so we can't just not > > show the file if the flag is not set properly, sorry. > > > > So the "error" is correct here, as is the 0644 file value. > > hmm... we could create the file at pm_runtime_enable() time and remove > it on pm_runtime_disable() time, no ? Addin Rafael to Cc ... > > > > > No such device - /sys/devices/system/edac/mc/mc0/sdram_scrub_rate > > > > Odd, go ask the edac developers > > will do ;-) Well, the question is missing ;) /me assumes that you want to talk about suspending/resume and EDAC, right? In general, memory controllers don't supports suspend, as far as I can tell. Still, I've seen a few ones that support, but the current drivers and/or the EDAC core currently doesn't offer any support to it, as such setup is done by the BIOS, when it detects the used DIMM banks. I suspect that, when the OS puts the machine on a suspend state, the BIOS may also suspend also the memory controller or put it into a low power consumption mode, but it does it without any help from the EDAC drivers. For most of what's there at EDAC, I don't think it is worth to add any PM support inside it. There are, however, two cases were we may need to add some support: 1) if user changed the SDRAM scrub rate before suspending, it makes sense to restore it after resume, on the memory controller drivers that support such feature (not all supports it); 2) hot-pluggable DIMMs. EDAC currently doesn't support. This could be needed on some future. In this case, the core may need to re-scan the memory controller, changing the memory properties. I've no idea if is there any real case needing it, nor what event would trigger the memory-controller re-scan. Resume is likely one of the candidates for it, on machines that support hot-pluggable memories. Regards, Mauro
next prev parent reply other threads:[~2013-02-18 19:47 UTC|newest] Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-02-18 15:33 SYSFS "errors" Felipe Balbi 2013-02-18 15:50 ` Greg KH 2013-02-18 15:52 ` Felipe Balbi 2013-02-18 17:13 ` Greg KH 2013-02-18 17:27 ` Felipe Balbi 2013-02-18 17:45 ` Borislav Petkov 2013-02-18 18:47 ` Felipe Balbi 2013-02-18 19:40 ` Borislav Petkov 2013-02-18 20:04 ` Felipe Balbi 2013-02-18 17:49 ` Greg KH 2013-02-18 18:46 ` Felipe Balbi 2013-02-18 18:46 ` Felipe Balbi 2013-02-18 19:46 ` Mauro Carvalho Chehab [this message] 2013-02-18 19:46 ` Mauro Carvalho Chehab 2013-02-18 20:05 ` Felipe Balbi 2013-02-18 20:05 ` Felipe Balbi 2013-02-18 21:47 ` Mauro Carvalho Chehab 2013-02-18 21:47 ` Mauro Carvalho Chehab 2013-02-18 21:54 ` Greg KH 2013-02-18 22:13 ` Borislav Petkov 2013-02-18 22:26 ` Greg KH 2013-02-18 22:44 ` Borislav Petkov 2013-02-19 10:03 ` Mauro Carvalho Chehab 2013-02-19 10:11 ` Felipe Balbi 2013-02-19 10:11 ` Felipe Balbi 2013-02-19 11:11 ` Mauro Carvalho Chehab 2013-02-19 11:11 ` Mauro Carvalho Chehab 2013-02-19 11:43 ` Borislav Petkov 2013-02-19 12:16 ` Mauro Carvalho Chehab 2013-02-19 12:35 ` Borislav Petkov 2013-02-19 12:46 ` Mauro Carvalho Chehab 2013-02-19 13:06 ` Borislav Petkov 2013-02-19 13:15 ` Felipe Balbi 2013-02-19 13:15 ` Felipe Balbi 2013-02-19 13:28 ` Borislav Petkov 2013-02-19 13:38 ` Felipe Balbi 2013-02-19 13:38 ` Felipe Balbi 2013-02-19 13:50 ` Mauro Carvalho Chehab 2013-02-19 13:50 ` Mauro Carvalho Chehab 2013-02-19 13:55 ` Borislav Petkov 2013-02-19 13:50 ` Borislav Petkov 2013-02-19 13:58 ` Hannes Reinecke 2013-02-19 14:10 ` Borislav Petkov 2013-02-19 14:14 ` Mauro Carvalho Chehab 2013-02-19 14:19 ` Felipe Balbi 2013-02-19 14:19 ` Felipe Balbi 2013-02-19 14:35 ` Mauro Carvalho Chehab 2013-02-19 14:50 ` Borislav Petkov 2013-02-19 14:53 ` Felipe Balbi 2013-02-19 14:53 ` Felipe Balbi 2013-02-19 13:42 ` Mauro Carvalho Chehab 2013-02-18 21:48 ` Alan Stern 2013-02-18 21:48 ` Alan Stern 2013-02-18 21:57 ` Felipe Balbi 2013-02-18 21:57 ` Felipe Balbi 2013-02-19 7:41 ` Alexander Stein 2013-02-19 10:12 ` Felipe Balbi
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20130218164638.7cb53baa@redhat.com \ --to=mchehab@redhat.com \ --cc=JBottomley@parallels.com \ --cc=balbi@ti.com \ --cc=davem@davemloft.net \ --cc=dougthompson@xmission.com \ --cc=fweisbec@gmail.com \ --cc=gregkh@linuxfoundation.org \ --cc=linux-edac@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=linux-scsi@vger.kernel.org \ --cc=mingo@redhat.com \ --cc=netdev@vger.kernel.org \ --cc=rjw@sisk.pl \ --cc=rostedt@goodmis.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.