Re: [GIT PATCH] ACPI patches for 2.6.21 - part II (resend)
On Tue, Mar 06, 2007 at 10:09:59PM +0100, Pavel Machek wrote: > Hi! > > > > > commit 4465857d5f99079bae00621626adf74ed8256296 > > > > Author: Mattia Dongili <[EMAIL PROTECTED]> > > > > Date: Sat Jan 13 23:04:39 2007 +0100 > > > > > > > > sony_acpi: Add lanpower and audiopower controls > > > > > > > > audiopower works well on my SZ72B so it's not marked has "debug" > > > > while lanpower > > > > has at least one report of not resuming power happily so morked as > > > > "debug" > > > > > > > > Signed-off-by: Mattia Dongili <[EMAIL PROTECTED]> > > > > Signed-off-by: Len Brown <[EMAIL PROTECTED]> > > > > > > What is interface to these? It would be nice to automagically disable > > > audiopower when sound device is closed, and automagically power down > > > lan on ifconfig ... down. > > > > the audiopower is basically a _PS3/_PS0 switch for the device, while the > > lanpower plays with the embedded controller to powerdown/powerup. > > > > Now, unfortunately those methods are attached to a fake device in the > > DSDT and afaict there's no way to tell which real device they are > > playing with (except by inspecting the method implementations). > > > Well of course iff there's only _one_ sound card and _one_ nic you can > > easily guess it :) > > Hmm... you are on sony notebook... right? That means it is very likely > it has just one sound card, and just one ethernet, no? I was thinking about hotpluggable audio/nic (pcmcia, usb). Anyway I have a sky2 and ipw3945 and yes, just one sound card :) -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21 - part II (resend)
Hi! > > > commit 4465857d5f99079bae00621626adf74ed8256296 > > > Author: Mattia Dongili <[EMAIL PROTECTED]> > > > Date: Sat Jan 13 23:04:39 2007 +0100 > > > > > > sony_acpi: Add lanpower and audiopower controls > > > > > > audiopower works well on my SZ72B so it's not marked has "debug" > > > while lanpower > > > has at least one report of not resuming power happily so morked as > > > "debug" > > > > > > Signed-off-by: Mattia Dongili <[EMAIL PROTECTED]> > > > Signed-off-by: Len Brown <[EMAIL PROTECTED]> > > > > What is interface to these? It would be nice to automagically disable > > audiopower when sound device is closed, and automagically power down > > lan on ifconfig ... down. > > the audiopower is basically a _PS3/_PS0 switch for the device, while the > lanpower plays with the embedded controller to powerdown/powerup. > > Now, unfortunately those methods are attached to a fake device in the > DSDT and afaict there's no way to tell which real device they are > playing with (except by inspecting the method implementations). > Well of course iff there's only _one_ sound card and _one_ nic you can > easily guess it :) Hmm... you are on sony notebook... right? That means it is very likely it has just one sound card, and just one ethernet, no? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21 - part II (resend)
On Tue, Mar 06, 2007 at 01:17:53PM +, Matthew Garrett wrote: > On Tue, Mar 06, 2007 at 01:22:13PM +0100, Mattia Dongili wrote: > > > the audiopower is basically a _PS3/_PS0 switch for the device, while the > > lanpower plays with the embedded controller to powerdown/powerup. > > > > Now, unfortunately those methods are attached to a fake device in the > > DSDT and afaict there's no way to tell which real device they are > > playing with (except by inspecting the method implementations). > > Well of course iff there's only _one_ sound card and _one_ nic you can > > easily guess it :) > > > > Is there some way to hook into drivers for such kind of runtime power > > management? > > Before worrying, I think it would make more sense to instrument the > benefit gained against doing more "traditional" runtime management - > that is, simply shutting down the ethernet chipset or doing ac97 power > management. It's trivial to add those to the existing drivers, and if Can't tell about chipset specific management, but as far as ACPI is concerned, this Sony specific stuff is a nice way of hiding features behind an undocumented device. Eg: the sound card _PS3 is empty and only available through that AZPW method.[1] So I guess that the platform_pci_set_power_state for ACPI D3 is basically a no-op there. > the additional benefit of using the Sony-specific methods is small then > it's probably not really worth working out how to add it in. Yep, will try to get some measurement (by means of the acpi battery status, no better way currently available here) but given the above I suspect there's some benefit. > Plus, implementing the generic support benefits more people :) Yes, of course. [1]: if you want to make a an idea, one such DSDT is available here: http://oioio.altervista.org/linux/DSDT.sz72b.dsl sony-laptop basically exposes the Device(SNC) and AZPW/GAZP for the audio (an hda) and LNPW/GLNP for the nic (a sky2). Now see the audio device Device(HDEF) and its _PS0 and _PS3. PS: did I disappear from the Cc list? ;) -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21 - part II (resend)
On Tue, Mar 06, 2007 at 01:22:13PM +0100, Mattia Dongili wrote: > the audiopower is basically a _PS3/_PS0 switch for the device, while the > lanpower plays with the embedded controller to powerdown/powerup. > > Now, unfortunately those methods are attached to a fake device in the > DSDT and afaict there's no way to tell which real device they are > playing with (except by inspecting the method implementations). > Well of course iff there's only _one_ sound card and _one_ nic you can > easily guess it :) > > Is there some way to hook into drivers for such kind of runtime power > management? Before worrying, I think it would make more sense to instrument the benefit gained against doing more "traditional" runtime management - that is, simply shutting down the ethernet chipset or doing ac97 power management. It's trivial to add those to the existing drivers, and if the additional benefit of using the Sony-specific methods is small then it's probably not really worth working out how to add it in. Plus, implementing the generic support benefits more people :) -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21 - part II (resend)
On Tue, Jan 01, 2002 at 04:57:52AM +, Pavel Machek wrote: > Hi! > > > commit 4465857d5f99079bae00621626adf74ed8256296 > > Author: Mattia Dongili <[EMAIL PROTECTED]> > > Date: Sat Jan 13 23:04:39 2007 +0100 > > > > sony_acpi: Add lanpower and audiopower controls > > > > audiopower works well on my SZ72B so it's not marked has "debug" while > > lanpower > > has at least one report of not resuming power happily so morked as > > "debug" > > > > Signed-off-by: Mattia Dongili <[EMAIL PROTECTED]> > > Signed-off-by: Len Brown <[EMAIL PROTECTED]> > > What is interface to these? It would be nice to automagically disable > audiopower when sound device is closed, and automagically power down > lan on ifconfig ... down. the audiopower is basically a _PS3/_PS0 switch for the device, while the lanpower plays with the embedded controller to powerdown/powerup. Now, unfortunately those methods are attached to a fake device in the DSDT and afaict there's no way to tell which real device they are playing with (except by inspecting the method implementations). Well of course iff there's only _one_ sound card and _one_ nic you can easily guess it :) Is there some way to hook into drivers for such kind of runtime power management? PS: lanpower currently seems to be a little too invasive (or it's just ACPI that reacts badly) because switching off lanpower also disables the pic link and never comes back. I need to better diagnose what's happening and report to linux-acpi. -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21 - part II (resend)
On Tue, Jan 01, 2002 at 04:57:52AM +, Pavel Machek wrote: Hi! commit 4465857d5f99079bae00621626adf74ed8256296 Author: Mattia Dongili [EMAIL PROTECTED] Date: Sat Jan 13 23:04:39 2007 +0100 sony_acpi: Add lanpower and audiopower controls audiopower works well on my SZ72B so it's not marked has debug while lanpower has at least one report of not resuming power happily so morked as debug Signed-off-by: Mattia Dongili [EMAIL PROTECTED] Signed-off-by: Len Brown [EMAIL PROTECTED] What is interface to these? It would be nice to automagically disable audiopower when sound device is closed, and automagically power down lan on ifconfig ... down. the audiopower is basically a _PS3/_PS0 switch for the device, while the lanpower plays with the embedded controller to powerdown/powerup. Now, unfortunately those methods are attached to a fake device in the DSDT and afaict there's no way to tell which real device they are playing with (except by inspecting the method implementations). Well of course iff there's only _one_ sound card and _one_ nic you can easily guess it :) Is there some way to hook into drivers for such kind of runtime power management? PS: lanpower currently seems to be a little too invasive (or it's just ACPI that reacts badly) because switching off lanpower also disables the pic link and never comes back. I need to better diagnose what's happening and report to linux-acpi. -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21 - part II (resend)
On Tue, Mar 06, 2007 at 01:22:13PM +0100, Mattia Dongili wrote: the audiopower is basically a _PS3/_PS0 switch for the device, while the lanpower plays with the embedded controller to powerdown/powerup. Now, unfortunately those methods are attached to a fake device in the DSDT and afaict there's no way to tell which real device they are playing with (except by inspecting the method implementations). Well of course iff there's only _one_ sound card and _one_ nic you can easily guess it :) Is there some way to hook into drivers for such kind of runtime power management? Before worrying, I think it would make more sense to instrument the benefit gained against doing more traditional runtime management - that is, simply shutting down the ethernet chipset or doing ac97 power management. It's trivial to add those to the existing drivers, and if the additional benefit of using the Sony-specific methods is small then it's probably not really worth working out how to add it in. Plus, implementing the generic support benefits more people :) -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21 - part II (resend)
On Tue, Mar 06, 2007 at 01:17:53PM +, Matthew Garrett wrote: On Tue, Mar 06, 2007 at 01:22:13PM +0100, Mattia Dongili wrote: the audiopower is basically a _PS3/_PS0 switch for the device, while the lanpower plays with the embedded controller to powerdown/powerup. Now, unfortunately those methods are attached to a fake device in the DSDT and afaict there's no way to tell which real device they are playing with (except by inspecting the method implementations). Well of course iff there's only _one_ sound card and _one_ nic you can easily guess it :) Is there some way to hook into drivers for such kind of runtime power management? Before worrying, I think it would make more sense to instrument the benefit gained against doing more traditional runtime management - that is, simply shutting down the ethernet chipset or doing ac97 power management. It's trivial to add those to the existing drivers, and if Can't tell about chipset specific management, but as far as ACPI is concerned, this Sony specific stuff is a nice way of hiding features behind an undocumented device. Eg: the sound card _PS3 is empty and only available through that AZPW method.[1] So I guess that the platform_pci_set_power_state for ACPI D3 is basically a no-op there. the additional benefit of using the Sony-specific methods is small then it's probably not really worth working out how to add it in. Yep, will try to get some measurement (by means of the acpi battery status, no better way currently available here) but given the above I suspect there's some benefit. Plus, implementing the generic support benefits more people :) Yes, of course. [1]: if you want to make a an idea, one such DSDT is available here: http://oioio.altervista.org/linux/DSDT.sz72b.dsl sony-laptop basically exposes the Device(SNC) and AZPW/GAZP for the audio (an hda) and LNPW/GLNP for the nic (a sky2). Now see the audio device Device(HDEF) and its _PS0 and _PS3. PS: did I disappear from the Cc list? ;) -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21 - part II (resend)
Hi! commit 4465857d5f99079bae00621626adf74ed8256296 Author: Mattia Dongili [EMAIL PROTECTED] Date: Sat Jan 13 23:04:39 2007 +0100 sony_acpi: Add lanpower and audiopower controls audiopower works well on my SZ72B so it's not marked has debug while lanpower has at least one report of not resuming power happily so morked as debug Signed-off-by: Mattia Dongili [EMAIL PROTECTED] Signed-off-by: Len Brown [EMAIL PROTECTED] What is interface to these? It would be nice to automagically disable audiopower when sound device is closed, and automagically power down lan on ifconfig ... down. the audiopower is basically a _PS3/_PS0 switch for the device, while the lanpower plays with the embedded controller to powerdown/powerup. Now, unfortunately those methods are attached to a fake device in the DSDT and afaict there's no way to tell which real device they are playing with (except by inspecting the method implementations). Well of course iff there's only _one_ sound card and _one_ nic you can easily guess it :) Hmm... you are on sony notebook... right? That means it is very likely it has just one sound card, and just one ethernet, no? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21 - part II (resend)
On Tue, Mar 06, 2007 at 10:09:59PM +0100, Pavel Machek wrote: Hi! commit 4465857d5f99079bae00621626adf74ed8256296 Author: Mattia Dongili [EMAIL PROTECTED] Date: Sat Jan 13 23:04:39 2007 +0100 sony_acpi: Add lanpower and audiopower controls audiopower works well on my SZ72B so it's not marked has debug while lanpower has at least one report of not resuming power happily so morked as debug Signed-off-by: Mattia Dongili [EMAIL PROTECTED] Signed-off-by: Len Brown [EMAIL PROTECTED] What is interface to these? It would be nice to automagically disable audiopower when sound device is closed, and automagically power down lan on ifconfig ... down. the audiopower is basically a _PS3/_PS0 switch for the device, while the lanpower plays with the embedded controller to powerdown/powerup. Now, unfortunately those methods are attached to a fake device in the DSDT and afaict there's no way to tell which real device they are playing with (except by inspecting the method implementations). Well of course iff there's only _one_ sound card and _one_ nic you can easily guess it :) Hmm... you are on sony notebook... right? That means it is very likely it has just one sound card, and just one ethernet, no? I was thinking about hotpluggable audio/nic (pcmcia, usb). Anyway I have a sky2 and ipw3945 and yes, just one sound card :) -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21 - part II (resend)
Hi! > commit 4465857d5f99079bae00621626adf74ed8256296 > Author: Mattia Dongili <[EMAIL PROTECTED]> > Date: Sat Jan 13 23:04:39 2007 +0100 > > sony_acpi: Add lanpower and audiopower controls > > audiopower works well on my SZ72B so it's not marked has "debug" while > lanpower > has at least one report of not resuming power happily so morked as "debug" > > Signed-off-by: Mattia Dongili <[EMAIL PROTECTED]> > Signed-off-by: Len Brown <[EMAIL PROTECTED]> What is interface to these? It would be nice to automagically disable audiopower when sound device is closed, and automagically power down lan on ifconfig ... down. (Sorry for time machine) Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21 - part II (resend)
Hi! commit 4465857d5f99079bae00621626adf74ed8256296 Author: Mattia Dongili [EMAIL PROTECTED] Date: Sat Jan 13 23:04:39 2007 +0100 sony_acpi: Add lanpower and audiopower controls audiopower works well on my SZ72B so it's not marked has debug while lanpower has at least one report of not resuming power happily so morked as debug Signed-off-by: Mattia Dongili [EMAIL PROTECTED] Signed-off-by: Len Brown [EMAIL PROTECTED] What is interface to these? It would be nice to automagically disable audiopower when sound device is closed, and automagically power down lan on ifconfig ... down. (Sorry for time machine) Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Thu, 2007-02-22 at 15:53 +, Pavel Machek wrote: > Hi! > > > > > the old /proc/acpi/ interfaces with cleaner interfaces in sysfs -- > > > > non-ACPI-specific generic ones whenever possible. This effort > > > > is not complete, but it has been in -mm for a long time and > > > > I believe that it is time to push it upstream to benefit > > > > from broader exposure and testing. > > > > > > Does it still include completely broken alarm interface? Can't find it > > > in changelogs, so hopefully not. > > > > No. See discussion on linux-acpi. > > David Brownell's RTC driver will provide the new RTC interface in sysfs. > > /proc/acpi/alarm will go away when the rest of /proc/acpi goes away. > > I guess I should say 'sorry for a flame'. I've seen a discussion > (linux-pm or somewhere), but did not see the decision to drop the > offending patch. > Hi, Pavel, Both the patches that duplicate "alarm" and "wakeup" attributes in sysfs are dropped. "alarm" attribute can be replaced by the new RTC driver. And the "wakeup" attribute are in the wish list now. You can get more details from the original mail. http://marc.theaimsgroup.com/?l=linux-acpi=116910315512529=2 Thanks, Rui - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Thu, 2007-02-22 at 15:53 +, Pavel Machek wrote: Hi! the old /proc/acpi/ interfaces with cleaner interfaces in sysfs -- non-ACPI-specific generic ones whenever possible. This effort is not complete, but it has been in -mm for a long time and I believe that it is time to push it upstream to benefit from broader exposure and testing. Does it still include completely broken alarm interface? Can't find it in changelogs, so hopefully not. No. See discussion on linux-acpi. David Brownell's RTC driver will provide the new RTC interface in sysfs. /proc/acpi/alarm will go away when the rest of /proc/acpi goes away. I guess I should say 'sorry for a flame'. I've seen a discussion (linux-pm or somewhere), but did not see the decision to drop the offending patch. Hi, Pavel, Both the patches that duplicate alarm and wakeup attributes in sysfs are dropped. alarm attribute can be replaced by the new RTC driver. And the wakeup attribute are in the wish list now. You can get more details from the original mail. http://marc.theaimsgroup.com/?l=linux-acpim=116910315512529w=2 Thanks, Rui - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
Hi! > > > the old /proc/acpi/ interfaces with cleaner interfaces in sysfs -- > > > non-ACPI-specific generic ones whenever possible. This effort > > > is not complete, but it has been in -mm for a long time and > > > I believe that it is time to push it upstream to benefit > > > from broader exposure and testing. > > > > Does it still include completely broken alarm interface? Can't find it > > in changelogs, so hopefully not. > > No. See discussion on linux-acpi. > David Brownell's RTC driver will provide the new RTC interface in sysfs. > /proc/acpi/alarm will go away when the rest of /proc/acpi goes away. I guess I should say 'sorry for a flame'. I've seen a discussion (linux-pm or somewhere), but did not see the decision to drop the offending patch. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
Hi! the old /proc/acpi/ interfaces with cleaner interfaces in sysfs -- non-ACPI-specific generic ones whenever possible. This effort is not complete, but it has been in -mm for a long time and I believe that it is time to push it upstream to benefit from broader exposure and testing. Does it still include completely broken alarm interface? Can't find it in changelogs, so hopefully not. No. See discussion on linux-acpi. David Brownell's RTC driver will provide the new RTC interface in sysfs. /proc/acpi/alarm will go away when the rest of /proc/acpi goes away. I guess I should say 'sorry for a flame'. I've seen a discussion (linux-pm or somewhere), but did not see the decision to drop the offending patch. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
Hi! > > > > Not including another /proc/acpi/ibm -like nightmare, is it? > > > > > > Don't worry, I am already on my way to kill /proc/acpi/ibm... :-) > > > > Great, thanks! > > Pavel > > None of the platform/hwmon/led driver model code landed there yet, but it > should be available at: > > http://repo.or.cz/w/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git queue/waiting > > eventually. Note, I push a lot to that branch, and it is a stgit head, so > it gets rewond if a change that makes sense in an earlier patch shows up. Great... if you want some testing, just mail me patch against mainline or whatever... (I don't think I can handle stgit). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
Hi! Not including another /proc/acpi/ibm -like nightmare, is it? Don't worry, I am already on my way to kill /proc/acpi/ibm... :-) Great, thanks! Pavel None of the platform/hwmon/led driver model code landed there yet, but it should be available at: http://repo.or.cz/w/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git queue/waiting eventually. Note, I push a lot to that branch, and it is a stgit head, so it gets rewond if a change that makes sense in an earlier patch shows up. Great... if you want some testing, just mail me patch against mainline or whatever... (I don't think I can handle stgit). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Sun, 11 Feb 2007, Pavel Machek wrote: > > > Not including another /proc/acpi/ibm -like nightmare, is it? > > > > Don't worry, I am already on my way to kill /proc/acpi/ibm... :-) > > Great, thanks! > Pavel None of the platform/hwmon/led driver model code landed there yet, but it should be available at: http://repo.or.cz/w/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git queue/waiting eventually. Note, I push a lot to that branch, and it is a stgit head, so it gets rewond if a change that makes sense in an earlier patch shows up. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
Hi! > > Not including another /proc/acpi/ibm -like nightmare, is it? > > Don't worry, I am already on my way to kill /proc/acpi/ibm... :-) Great, thanks! Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
Hi! Not including another /proc/acpi/ibm -like nightmare, is it? Don't worry, I am already on my way to kill /proc/acpi/ibm... :-) Great, thanks! Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Sun, 11 Feb 2007, Pavel Machek wrote: Not including another /proc/acpi/ibm -like nightmare, is it? Don't worry, I am already on my way to kill /proc/acpi/ibm... :-) Great, thanks! Pavel None of the platform/hwmon/led driver model code landed there yet, but it should be available at: http://repo.or.cz/w/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git queue/waiting eventually. Note, I push a lot to that branch, and it is a stgit head, so it gets rewond if a change that makes sense in an earlier patch shows up. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Saturday 10 February 2007 18:39:27 Henrique de Moraes Holschuh wrote: > On Sat, 10 Feb 2007, Ismail Dönmez wrote: > > Hmmf looks like a userspace bug, but it certainly did work before ACPI > > update. > > Well, I don't know if this is the case here, but after reading the userland > code that people use on most applets to read /proc/acpi/ibm, I was upset > and disgusted for days. > > Some userland code *deserves* to be broken with extreme prejudice. Must be because there is no unified way to read this info ;) Userspace is honestly not guilty here. Regards, ismail - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Saturday 10 February 2007 17:52:13 Ismail Dönmez wrote: > On Saturday 10 February 2007 14:07:13 Holger Macht wrote: > > On Sat 10. Feb - 10:27:14, Ismail Dönmez wrote: > > > On Wednesday 07 February 2007 21:18:50 Len Brown wrote: > > > > Hi Linus, > > > > > > > > please pull from: > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git > > > > release > > > > > > > > ACPICA Core version 2070126 simplifies the ACPI table manager > > > > code by consolidating multiple table definitions into one. > > > > It also saves memory by mapping the tables where the BIOS provides > > > > them rather than copying them into the kernel. > > > > > > This breaks kpowersave, now it always says laptop is plugged in and > > > does not show any battery status. Any /proc changes in this release? > > > > kpowersave just reflects what HAL thinks, and HAL reflects what the > > kernel thinks. So please post the content of > > /proc/acpi/ac_adapter/AC/state when AC is not plugged in to figure out if > > it's just a userland bug or a kernel issue. > > [~]> cat /proc/acpi/ac_adapter/ADP1/state > state: off-line > > > Hmmf looks like a userspace bug, but it certainly did work before ACPI > update. Hmm whats this ADP1 and there is no /proc/acpi/ac_adapter/AC around... Regards, ismail - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Sat, 10 Feb 2007, Ismail Dönmez wrote: > Hmmf looks like a userspace bug, but it certainly did work before ACPI update. Well, I don't know if this is the case here, but after reading the userland code that people use on most applets to read /proc/acpi/ibm, I was upset and disgusted for days. Some userland code *deserves* to be broken with extreme prejudice. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Saturday 10 February 2007 14:07:13 Holger Macht wrote: > On Sat 10. Feb - 10:27:14, Ismail Dönmez wrote: > > On Wednesday 07 February 2007 21:18:50 Len Brown wrote: > > > Hi Linus, > > > > > > please pull from: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git > > > release > > > > > > ACPICA Core version 2070126 simplifies the ACPI table manager > > > code by consolidating multiple table definitions into one. > > > It also saves memory by mapping the tables where the BIOS provides them > > > rather than copying them into the kernel. > > > > This breaks kpowersave, now it always says laptop is plugged in and does > > not show any battery status. Any /proc changes in this release? > > kpowersave just reflects what HAL thinks, and HAL reflects what the kernel > thinks. So please post the content of /proc/acpi/ac_adapter/AC/state when > AC is not plugged in to figure out if it's just a userland bug or a kernel > issue. [~]> cat /proc/acpi/ac_adapter/ADP1/state state: off-line Hmmf looks like a userspace bug, but it certainly did work before ACPI update. Regards, ismail - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Sat 10. Feb - 10:27:14, Ismail Dönmez wrote: > On Wednesday 07 February 2007 21:18:50 Len Brown wrote: > > Hi Linus, > > > > please pull from: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git > > release > > > > ACPICA Core version 2070126 simplifies the ACPI table manager > > code by consolidating multiple table definitions into one. > > It also saves memory by mapping the tables where the BIOS provides them > > rather than copying them into the kernel. > > This breaks kpowersave, now it always says laptop is plugged in and does not > show any battery status. Any /proc changes in this release? kpowersave just reflects what HAL thinks, and HAL reflects what the kernel thinks. So please post the content of /proc/acpi/ac_adapter/AC/state when AC is not plugged in to figure out if it's just a userland bug or a kernel issue. Regards, Holger - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Wednesday 07 February 2007 21:18:50 Len Brown wrote: > Hi Linus, > > please pull from: > > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git > release > > ACPICA Core version 2070126 simplifies the ACPI table manager > code by consolidating multiple table definitions into one. > It also saves memory by mapping the tables where the BIOS provides them > rather than copying them into the kernel. This breaks kpowersave, now it always says laptop is plugged in and does not show any battery status. Any /proc changes in this release? Regards, ismail - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Wednesday 07 February 2007 21:18:50 Len Brown wrote: Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release ACPICA Core version 2070126 simplifies the ACPI table manager code by consolidating multiple table definitions into one. It also saves memory by mapping the tables where the BIOS provides them rather than copying them into the kernel. This breaks kpowersave, now it always says laptop is plugged in and does not show any battery status. Any /proc changes in this release? Regards, ismail - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Sat 10. Feb - 10:27:14, Ismail Dönmez wrote: On Wednesday 07 February 2007 21:18:50 Len Brown wrote: Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release ACPICA Core version 2070126 simplifies the ACPI table manager code by consolidating multiple table definitions into one. It also saves memory by mapping the tables where the BIOS provides them rather than copying them into the kernel. This breaks kpowersave, now it always says laptop is plugged in and does not show any battery status. Any /proc changes in this release? kpowersave just reflects what HAL thinks, and HAL reflects what the kernel thinks. So please post the content of /proc/acpi/ac_adapter/AC/state when AC is not plugged in to figure out if it's just a userland bug or a kernel issue. Regards, Holger - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Saturday 10 February 2007 14:07:13 Holger Macht wrote: On Sat 10. Feb - 10:27:14, Ismail Dönmez wrote: On Wednesday 07 February 2007 21:18:50 Len Brown wrote: Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release ACPICA Core version 2070126 simplifies the ACPI table manager code by consolidating multiple table definitions into one. It also saves memory by mapping the tables where the BIOS provides them rather than copying them into the kernel. This breaks kpowersave, now it always says laptop is plugged in and does not show any battery status. Any /proc changes in this release? kpowersave just reflects what HAL thinks, and HAL reflects what the kernel thinks. So please post the content of /proc/acpi/ac_adapter/AC/state when AC is not plugged in to figure out if it's just a userland bug or a kernel issue. [~] cat /proc/acpi/ac_adapter/ADP1/state state: off-line Hmmf looks like a userspace bug, but it certainly did work before ACPI update. Regards, ismail - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Sat, 10 Feb 2007, Ismail Dönmez wrote: Hmmf looks like a userspace bug, but it certainly did work before ACPI update. Well, I don't know if this is the case here, but after reading the userland code that people use on most applets to read /proc/acpi/ibm, I was upset and disgusted for days. Some userland code *deserves* to be broken with extreme prejudice. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Saturday 10 February 2007 17:52:13 Ismail Dönmez wrote: On Saturday 10 February 2007 14:07:13 Holger Macht wrote: On Sat 10. Feb - 10:27:14, Ismail Dönmez wrote: On Wednesday 07 February 2007 21:18:50 Len Brown wrote: Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release ACPICA Core version 2070126 simplifies the ACPI table manager code by consolidating multiple table definitions into one. It also saves memory by mapping the tables where the BIOS provides them rather than copying them into the kernel. This breaks kpowersave, now it always says laptop is plugged in and does not show any battery status. Any /proc changes in this release? kpowersave just reflects what HAL thinks, and HAL reflects what the kernel thinks. So please post the content of /proc/acpi/ac_adapter/AC/state when AC is not plugged in to figure out if it's just a userland bug or a kernel issue. [~] cat /proc/acpi/ac_adapter/ADP1/state state: off-line Hmmf looks like a userspace bug, but it certainly did work before ACPI update. Hmm whats this ADP1 and there is no /proc/acpi/ac_adapter/AC around... Regards, ismail - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Saturday 10 February 2007 18:39:27 Henrique de Moraes Holschuh wrote: On Sat, 10 Feb 2007, Ismail Dönmez wrote: Hmmf looks like a userspace bug, but it certainly did work before ACPI update. Well, I don't know if this is the case here, but after reading the userland code that people use on most applets to read /proc/acpi/ibm, I was upset and disgusted for days. Some userland code *deserves* to be broken with extreme prejudice. Must be because there is no unified way to read this info ;) Userspace is honestly not guilty here. Regards, ismail - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Friday 09 February 2007 18:09, Pavel Machek wrote: > Hi! > > > Per your request, and the request of the distros, we've changed > > how ACPICA Core releases are integrated into Linux so that each > > upstream (CVS) check-in appears as a single git commit. > > While this process is not yet perfect, it should be vastly better > > than previous "code drops" in allowing git bisect to work, > > and allowing distros to cherry-pick individual fixes. > > > > The "bay" driver is new (and marked EXPERIMENTAL) -- adding initial > > hot-plug support for ACPI controlled drive bays such as the > > IBM ultrabay or the Dell Module Bay. > > Could you describe userland interface it uses? /proc? Will it be > usable for bays on notebooks not using acpi? No, Not until somebody finds one and writes code to support it. > > The "asus-laptop" driver is also new. Consistent with msi-laptop, > > it uses ACPI in platform-specific ways, but strives to avoid > > exposing ACPI-specific implementation details to the user. > > asus-laptop is mutually exclusive with asus_acpi, which it will > > replace over time. > > Not including another /proc/acpi/ibm -like nightmare, is it? No. See discussion on linux-acpi. I've prohibited new files under /proc/acpi/ for quite some time now. > > the old /proc/acpi/ interfaces with cleaner interfaces in sysfs -- > > non-ACPI-specific generic ones whenever possible. This effort > > is not complete, but it has been in -mm for a long time and > > I believe that it is time to push it upstream to benefit > > from broader exposure and testing. > > Does it still include completely broken alarm interface? Can't find it > in changelogs, so hopefully not. No. See discussion on linux-acpi. David Brownell's RTC driver will provide the new RTC interface in sysfs. /proc/acpi/alarm will go away when the rest of /proc/acpi goes away. thanks, -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Fri, Feb 09, 2007 at 05:24:10PM -0800, Kristen Carlson Accardi wrote: > The user interface for the Bay driver is via sysfs - it is a platform > driver Though, ideally, in the long run it'll be tied into the PATA/SATA interface that it's associated with. That involves a little more magic, though :) -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Fri, 09 Feb 2007, Pavel Machek wrote: > Not including another /proc/acpi/ibm -like nightmare, is it? Don't worry, I am already on my way to kill /proc/acpi/ibm... :-) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Fri, 9 Feb 2007 23:09:29 + Pavel Machek <[EMAIL PROTECTED]> wrote: > Hi! > > > Per your request, and the request of the distros, we've changed > > how ACPICA Core releases are integrated into Linux so that each > > upstream (CVS) check-in appears as a single git commit. > > While this process is not yet perfect, it should be vastly better > > than previous "code drops" in allowing git bisect to work, > > and allowing distros to cherry-pick individual fixes. > > > > The "bay" driver is new (and marked EXPERIMENTAL) -- adding initial > > hot-plug support for ACPI controlled drive bays such as the > > IBM ultrabay or the Dell Module Bay. > > Could you describe userland interface it uses? /proc? Will it be > usable for bays on notebooks not using acpi? The user interface for the Bay driver is via sysfs - it is a platform driver, so once you load it you will find 2 files created under /sys/devices/platform/bay.X, "eject" and "present". When the user writes 1 to the "eject" file, the driver will call the ACPI eject routine - this normally blinks leds and does whatever the system vendor thinks is necessary to safely eject the device. The "present" file will query the driver to determine if the device is present or not (note, not good for poll(), it's on my todo list...). Depending on the system implementation, when the user presses the eject button on the laptop for the bay device, the driver will inform user space via a CHANGE uevent. User space is then responsible for doing whatever needs to be done to cleanup and safely eject the drive, the driver will not call the ACPI eject routine without user space initiation. The driver currently only handles module bays that use ACPI to send eject notifications or need "something" done before ejecting (i.e. _EJ0 in ACPI). The bay driver will also register with the dock driver if the bay is on the dock device (such as with the IBM X60) so that when the dock station is ejected, the bay driver is notified with the eject request as well. This notification will be passed to user space via the CHANGE uevent. Kristen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
Hi! > Per your request, and the request of the distros, we've changed > how ACPICA Core releases are integrated into Linux so that each > upstream (CVS) check-in appears as a single git commit. > While this process is not yet perfect, it should be vastly better > than previous "code drops" in allowing git bisect to work, > and allowing distros to cherry-pick individual fixes. > > The "bay" driver is new (and marked EXPERIMENTAL) -- adding initial > hot-plug support for ACPI controlled drive bays such as the > IBM ultrabay or the Dell Module Bay. Could you describe userland interface it uses? /proc? Will it be usable for bays on notebooks not using acpi? > The "asus-laptop" driver is also new. Consistent with msi-laptop, > it uses ACPI in platform-specific ways, but strives to avoid > exposing ACPI-specific implementation details to the user. > asus-laptop is mutually exclusive with asus_acpi, which it will > replace over time. Not including another /proc/acpi/ibm -like nightmare, is it? > the old /proc/acpi/ interfaces with cleaner interfaces in sysfs -- > non-ACPI-specific generic ones whenever possible. This effort > is not complete, but it has been in -mm for a long time and > I believe that it is time to push it upstream to benefit > from broader exposure and testing. Does it still include completely broken alarm interface? Can't find it in changelogs, so hopefully not. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
Hi! Per your request, and the request of the distros, we've changed how ACPICA Core releases are integrated into Linux so that each upstream (CVS) check-in appears as a single git commit. While this process is not yet perfect, it should be vastly better than previous code drops in allowing git bisect to work, and allowing distros to cherry-pick individual fixes. The bay driver is new (and marked EXPERIMENTAL) -- adding initial hot-plug support for ACPI controlled drive bays such as the IBM ultrabay or the Dell Module Bay. Could you describe userland interface it uses? /proc? Will it be usable for bays on notebooks not using acpi? The asus-laptop driver is also new. Consistent with msi-laptop, it uses ACPI in platform-specific ways, but strives to avoid exposing ACPI-specific implementation details to the user. asus-laptop is mutually exclusive with asus_acpi, which it will replace over time. Not including another /proc/acpi/ibm -like nightmare, is it? the old /proc/acpi/ interfaces with cleaner interfaces in sysfs -- non-ACPI-specific generic ones whenever possible. This effort is not complete, but it has been in -mm for a long time and I believe that it is time to push it upstream to benefit from broader exposure and testing. Does it still include completely broken alarm interface? Can't find it in changelogs, so hopefully not. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Fri, 9 Feb 2007 23:09:29 + Pavel Machek [EMAIL PROTECTED] wrote: Hi! Per your request, and the request of the distros, we've changed how ACPICA Core releases are integrated into Linux so that each upstream (CVS) check-in appears as a single git commit. While this process is not yet perfect, it should be vastly better than previous code drops in allowing git bisect to work, and allowing distros to cherry-pick individual fixes. The bay driver is new (and marked EXPERIMENTAL) -- adding initial hot-plug support for ACPI controlled drive bays such as the IBM ultrabay or the Dell Module Bay. Could you describe userland interface it uses? /proc? Will it be usable for bays on notebooks not using acpi? The user interface for the Bay driver is via sysfs - it is a platform driver, so once you load it you will find 2 files created under /sys/devices/platform/bay.X, eject and present. When the user writes 1 to the eject file, the driver will call the ACPI eject routine - this normally blinks leds and does whatever the system vendor thinks is necessary to safely eject the device. The present file will query the driver to determine if the device is present or not (note, not good for poll(), it's on my todo list...). Depending on the system implementation, when the user presses the eject button on the laptop for the bay device, the driver will inform user space via a CHANGE uevent. User space is then responsible for doing whatever needs to be done to cleanup and safely eject the drive, the driver will not call the ACPI eject routine without user space initiation. The driver currently only handles module bays that use ACPI to send eject notifications or need something done before ejecting (i.e. _EJ0 in ACPI). The bay driver will also register with the dock driver if the bay is on the dock device (such as with the IBM X60) so that when the dock station is ejected, the bay driver is notified with the eject request as well. This notification will be passed to user space via the CHANGE uevent. Kristen - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Fri, 09 Feb 2007, Pavel Machek wrote: Not including another /proc/acpi/ibm -like nightmare, is it? Don't worry, I am already on my way to kill /proc/acpi/ibm... :-) -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Fri, Feb 09, 2007 at 05:24:10PM -0800, Kristen Carlson Accardi wrote: The user interface for the Bay driver is via sysfs - it is a platform driver Though, ideally, in the long run it'll be tied into the PATA/SATA interface that it's associated with. That involves a little more magic, though :) -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Friday 09 February 2007 18:09, Pavel Machek wrote: Hi! Per your request, and the request of the distros, we've changed how ACPICA Core releases are integrated into Linux so that each upstream (CVS) check-in appears as a single git commit. While this process is not yet perfect, it should be vastly better than previous code drops in allowing git bisect to work, and allowing distros to cherry-pick individual fixes. The bay driver is new (and marked EXPERIMENTAL) -- adding initial hot-plug support for ACPI controlled drive bays such as the IBM ultrabay or the Dell Module Bay. Could you describe userland interface it uses? /proc? Will it be usable for bays on notebooks not using acpi? No, Not until somebody finds one and writes code to support it. The asus-laptop driver is also new. Consistent with msi-laptop, it uses ACPI in platform-specific ways, but strives to avoid exposing ACPI-specific implementation details to the user. asus-laptop is mutually exclusive with asus_acpi, which it will replace over time. Not including another /proc/acpi/ibm -like nightmare, is it? No. See discussion on linux-acpi. I've prohibited new files under /proc/acpi/ for quite some time now. the old /proc/acpi/ interfaces with cleaner interfaces in sysfs -- non-ACPI-specific generic ones whenever possible. This effort is not complete, but it has been in -mm for a long time and I believe that it is time to push it upstream to benefit from broader exposure and testing. Does it still include completely broken alarm interface? Can't find it in changelogs, so hopefully not. No. See discussion on linux-acpi. David Brownell's RTC driver will provide the new RTC interface in sysfs. /proc/acpi/alarm will go away when the rest of /proc/acpi goes away. thanks, -Len - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Wednesday 07 February 2007 16:55, Al Boldi wrote: > Len Brown wrote: > > ACPICA Core version 2070126 simplifies the ACPI table manager > > code by consolidating multiple table definitions into one. > > It also saves memory by mapping the tables where the BIOS provides them > > rather than copying them into the kernel. > > Thanks for the update, but does it fix the ISA VGA STR-regression in 2.6.20? Unlikely. But I'm not aware of an ISA VGA STR-regression in 2.6.20, so I can't really say. In general, VGA STR issues are related to the BIOS and video drivers and have nothing to do with ACPI support itself. > Also, is there some dependency that requires a display card to be present for > STR to work? ACPI doesn't care if you have VGA or not. -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
Len Brown wrote: > ACPICA Core version 2070126 simplifies the ACPI table manager > code by consolidating multiple table definitions into one. > It also saves memory by mapping the tables where the BIOS provides them > rather than copying them into the kernel. Thanks for the update, but does it fix the ISA VGA STR-regression in 2.6.20? Also, is there some dependency that requires a display card to be present for STR to work? Thanks! -- Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
Len Brown wrote: ACPICA Core version 2070126 simplifies the ACPI table manager code by consolidating multiple table definitions into one. It also saves memory by mapping the tables where the BIOS provides them rather than copying them into the kernel. Thanks for the update, but does it fix the ISA VGA STR-regression in 2.6.20? Also, is there some dependency that requires a display card to be present for STR to work? Thanks! -- Al - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Wednesday 07 February 2007 16:55, Al Boldi wrote: Len Brown wrote: ACPICA Core version 2070126 simplifies the ACPI table manager code by consolidating multiple table definitions into one. It also saves memory by mapping the tables where the BIOS provides them rather than copying them into the kernel. Thanks for the update, but does it fix the ISA VGA STR-regression in 2.6.20? Unlikely. But I'm not aware of an ISA VGA STR-regression in 2.6.20, so I can't really say. In general, VGA STR issues are related to the BIOS and video drivers and have nothing to do with ACPI support itself. Also, is there some dependency that requires a display card to be present for STR to work? ACPI doesn't care if you have VGA or not. -Len - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
