[PATCH] sony-laptop: printk more info in sony_pic_call[123]
Signed-off-by: Mattia Dongili [EMAIL PROTECTED] --- drivers/misc/sony-laptop.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/misc/sony-laptop.c b/drivers/misc/sony-laptop.c index b0f6803..4211ca7 100644 --- a/drivers/misc/sony-laptop.c +++ b/drivers/misc/sony-laptop.c @@ -1451,7 +1451,7 @@ static u8 sony_pic_call1(u8 dev) outb(dev, spic_dev.cur_ioport-io1.minimum + 4); v1 = inb_p(spic_dev.cur_ioport-io1.minimum + 4); v2 = inb_p(spic_dev.cur_ioport-io1.minimum); - dprintk(sony_pic_call1: 0x%.4x\n, (v2 8) | v1); + dprintk(sony_pic_call1(0x%.2x): 0x%.4x\n, dev, (v2 8) | v1); return v2; } @@ -1466,7 +1466,7 @@ static u8 sony_pic_call2(u8 dev, u8 fn) ITERATIONS_LONG); outb(fn, spic_dev.cur_ioport-io1.minimum); v1 = inb_p(spic_dev.cur_ioport-io1.minimum); - dprintk(sony_pic_call2: 0x%.4x\n, v1); + dprintk(sony_pic_call2(0x%.2x - 0x%.2x): 0x%.4x\n, dev, fn, v1); return v1; } @@ -1481,7 +1481,7 @@ static u8 sony_pic_call3(u8 dev, u8 fn, u8 v) wait_on_command(inb_p(spic_dev.cur_ioport-io1.minimum + 4) 2, ITERATIONS_LONG); outb(v, spic_dev.cur_ioport-io1.minimum); v1 = inb_p(spic_dev.cur_ioport-io1.minimum); - dprintk(sony_pic_call3: 0x%.4x\n, v1); + dprintk(sony_pic_call3(0x%.2x - 0x%.2x - 0x%.2x): 0x%.4x\n, dev, fn, v, v1); return v1; } -- 1.5.3.7 - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] sony-laptop: bump version to 0.6
Signed-off-by: Mattia Dongili [EMAIL PROTECTED] --- drivers/misc/sony-laptop.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/misc/sony-laptop.c b/drivers/misc/sony-laptop.c index 3d3843a..84430b4 100644 --- a/drivers/misc/sony-laptop.c +++ b/drivers/misc/sony-laptop.c @@ -73,7 +73,7 @@ if (debug) printk(KERN_WARNING DRV_PFX msg); \ } while (0) -#define SONY_LAPTOP_DRIVER_VERSION 0.5 +#define SONY_LAPTOP_DRIVER_VERSION 0.6 #define SONY_NC_CLASS sony-nc #define SONY_NC_HIDSNY5001 -- 1.5.3.7 - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] sony-laptop: refactor model types
Create mini drivers and allow callbacks for each model
to be specified.
Following patches will make use of this feature to handle
specific cases instead of just executing code and hope
not to break other models.
Signed-off-by: Mattia Dongili [EMAIL PROTECTED]
---
drivers/misc/sony-laptop.c | 182
1 files changed, 100 insertions(+), 82 deletions(-)
diff --git a/drivers/misc/sony-laptop.c b/drivers/misc/sony-laptop.c
index 550f9d9..3d3843a 100644
--- a/drivers/misc/sony-laptop.c
+++ b/drivers/misc/sony-laptop.c
@@ -1194,18 +1194,33 @@ struct sony_pic_irq {
struct list_headlist;
};
+struct sonypi_eventtypes {
+ u8 data;
+ unsigned long mask;
+ struct sonypi_event * events;
+};
+
+struct device_ctrl {
+ int model;
+ int (*handle_irq)(void);
+ u16 evport_offset;
+ u8 has_camera;
+ u8 has_bluetooth;
+ u8 has_wwan;
+ struct sonypi_eventtypes*event_types;
+};
+
struct sony_pic_dev {
- int model;
- u16 evport_offset;
- u8 camera_power;
- u8 bluetooth_power;
- u8 wwan_power;
+ struct device_ctrl *control;
struct acpi_device *acpi_dev;
struct sony_pic_irq *cur_irq;
struct sony_pic_ioport *cur_ioport;
struct list_headinterrupts;
struct list_headioports;
struct mutexlock;
+ u8 camera_power;
+ u8 bluetooth_power;
+ u8 wwan_power;
};
static struct sony_pic_dev spic_dev = {
@@ -1370,74 +1385,92 @@ static struct sonypi_event sonypi_batteryev[] = {
{ 0, 0 }
};
-static struct sonypi_eventtypes {
- int model;
- u8 data;
- unsigned long mask;
- struct sonypi_event * events;
-} sony_pic_eventtypes[] = {
- { SONYPI_DEVICE_TYPE1, 0, 0x, sonypi_releaseev },
- { SONYPI_DEVICE_TYPE1, 0x70, SONYPI_MEYE_MASK, sonypi_meyeev },
- { SONYPI_DEVICE_TYPE1, 0x30, SONYPI_LID_MASK, sonypi_lidev },
- { SONYPI_DEVICE_TYPE1, 0x60, SONYPI_CAPTURE_MASK, sonypi_captureev },
- { SONYPI_DEVICE_TYPE1, 0x10, SONYPI_JOGGER_MASK, sonypi_joggerev },
- { SONYPI_DEVICE_TYPE1, 0x20, SONYPI_FNKEY_MASK, sonypi_fnkeyev },
- { SONYPI_DEVICE_TYPE1, 0x30, SONYPI_BLUETOOTH_MASK, sonypi_blueev },
- { SONYPI_DEVICE_TYPE1, 0x40, SONYPI_PKEY_MASK, sonypi_pkeyev },
- { SONYPI_DEVICE_TYPE1, 0x30, SONYPI_MEMORYSTICK_MASK,
sonypi_memorystickev },
- { SONYPI_DEVICE_TYPE1, 0x40, SONYPI_BATTERY_MASK, sonypi_batteryev },
-
- { SONYPI_DEVICE_TYPE2, 0, 0x, sonypi_releaseev },
- { SONYPI_DEVICE_TYPE2, 0x38, SONYPI_LID_MASK, sonypi_lidev },
- { SONYPI_DEVICE_TYPE2, 0x11, SONYPI_JOGGER_MASK, sonypi_joggerev },
- { SONYPI_DEVICE_TYPE2, 0x61, SONYPI_CAPTURE_MASK, sonypi_captureev },
- { SONYPI_DEVICE_TYPE2, 0x21, SONYPI_FNKEY_MASK, sonypi_fnkeyev },
- { SONYPI_DEVICE_TYPE2, 0x31, SONYPI_BLUETOOTH_MASK, sonypi_blueev },
- { SONYPI_DEVICE_TYPE2, 0x08, SONYPI_PKEY_MASK, sonypi_pkeyev },
- { SONYPI_DEVICE_TYPE2, 0x11, SONYPI_BACK_MASK, sonypi_backev },
- { SONYPI_DEVICE_TYPE2, 0x21, SONYPI_HELP_MASK, sonypi_helpev },
- { SONYPI_DEVICE_TYPE2, 0x21, SONYPI_ZOOM_MASK, sonypi_zoomev },
- { SONYPI_DEVICE_TYPE2, 0x20, SONYPI_THUMBPHRASE_MASK,
sonypi_thumbphraseev },
- { SONYPI_DEVICE_TYPE2, 0x31, SONYPI_MEMORYSTICK_MASK,
sonypi_memorystickev },
- { SONYPI_DEVICE_TYPE2, 0x41, SONYPI_BATTERY_MASK, sonypi_batteryev },
- { SONYPI_DEVICE_TYPE2, 0x31, SONYPI_PKEY_MASK, sonypi_pkeyev },
-
- { SONYPI_DEVICE_TYPE3, 0, 0x, sonypi_releaseev },
- { SONYPI_DEVICE_TYPE3, 0x21, SONYPI_FNKEY_MASK, sonypi_fnkeyev },
- { SONYPI_DEVICE_TYPE3, 0x31, SONYPI_WIRELESS_MASK, sonypi_wlessev },
- { SONYPI_DEVICE_TYPE3, 0x31, SONYPI_MEMORYSTICK_MASK,
sonypi_memorystickev },
- { SONYPI_DEVICE_TYPE3, 0x41, SONYPI_BATTERY_MASK, sonypi_batteryev },
- { SONYPI_DEVICE_TYPE3, 0x31, SONYPI_PKEY_MASK, sonypi_pkeyev },
- { 0 }
+static struct sonypi_eventtypes type1_events[] = {
+ { 0, 0x, sonypi_releaseev },
+ { 0x70, SONYPI_MEYE_MASK, sonypi_meyeev },
+ { 0x30, SONYPI_LID_MASK, sonypi_lidev },
+ { 0x60, SONYPI_CAPTURE_MASK, sonypi_captureev },
+ { 0x10, SONYPI_JOGGER_MASK, sonypi_joggerev },
+ { 0x20, SONYPI_FNKEY_MASK, sonypi_fnkeyev },
+ { 0x30, SONYPI_BLUETOOTH_MASK, sonypi_blueev },
+ { 0x40, SONYPI_PKEY_MASK,
[PATCH] sony-laptop: add Type4 model
Recent Vaio models (UX, SZ and presumably TZ and others) add more
events and a slightly different handling of Fn key events for
additional hotkeys (s1, s2, zoom-in/out, etc.).
Signed-off-by: Mattia Dongili [EMAIL PROTECTED]
---
drivers/misc/sony-laptop.c | 284 ++--
include/linux/sonypi.h |2 +
2 files changed, 172 insertions(+), 114 deletions(-)
diff --git a/drivers/misc/sony-laptop.c b/drivers/misc/sony-laptop.c
index 84430b4..4089751 100644
--- a/drivers/misc/sony-laptop.c
+++ b/drivers/misc/sony-laptop.c
@@ -146,68 +146,70 @@ struct sony_laptop_keypress {
* and input layer indexes in the keymap
*/
static int sony_laptop_input_index[] = {
- -1, /* no event */
- -1, /* SONYPI_EVENT_JOGDIAL_DOWN */
- -1, /* SONYPI_EVENT_JOGDIAL_UP */
- -1, /* SONYPI_EVENT_JOGDIAL_DOWN_PRESSED */
- -1, /* SONYPI_EVENT_JOGDIAL_UP_PRESSED */
- -1, /* SONYPI_EVENT_JOGDIAL_PRESSED */
- -1, /* SONYPI_EVENT_JOGDIAL_RELEASED */
-0, /* SONYPI_EVENT_CAPTURE_PRESSED */
-1, /* SONYPI_EVENT_CAPTURE_RELEASED */
-2, /* SONYPI_EVENT_CAPTURE_PARTIALPRESSED */
-3, /* SONYPI_EVENT_CAPTURE_PARTIALRELEASED */
-4, /* SONYPI_EVENT_FNKEY_ESC */
-5, /* SONYPI_EVENT_FNKEY_F1 */
-6, /* SONYPI_EVENT_FNKEY_F2 */
-7, /* SONYPI_EVENT_FNKEY_F3 */
-8, /* SONYPI_EVENT_FNKEY_F4 */
-9, /* SONYPI_EVENT_FNKEY_F5 */
- 10, /* SONYPI_EVENT_FNKEY_F6 */
- 11, /* SONYPI_EVENT_FNKEY_F7 */
- 12, /* SONYPI_EVENT_FNKEY_F8 */
- 13, /* SONYPI_EVENT_FNKEY_F9 */
- 14, /* SONYPI_EVENT_FNKEY_F10 */
- 15, /* SONYPI_EVENT_FNKEY_F11 */
- 16, /* SONYPI_EVENT_FNKEY_F12 */
- 17, /* SONYPI_EVENT_FNKEY_1 */
- 18, /* SONYPI_EVENT_FNKEY_2 */
- 19, /* SONYPI_EVENT_FNKEY_D */
- 20, /* SONYPI_EVENT_FNKEY_E */
- 21, /* SONYPI_EVENT_FNKEY_F */
- 22, /* SONYPI_EVENT_FNKEY_S */
- 23, /* SONYPI_EVENT_FNKEY_B */
- 24, /* SONYPI_EVENT_BLUETOOTH_PRESSED */
- 25, /* SONYPI_EVENT_PKEY_P1 */
- 26, /* SONYPI_EVENT_PKEY_P2 */
- 27, /* SONYPI_EVENT_PKEY_P3 */
- 28, /* SONYPI_EVENT_BACK_PRESSED */
- -1, /* SONYPI_EVENT_LID_CLOSED */
- -1, /* SONYPI_EVENT_LID_OPENED */
- 29, /* SONYPI_EVENT_BLUETOOTH_ON */
- 30, /* SONYPI_EVENT_BLUETOOTH_OFF */
- 31, /* SONYPI_EVENT_HELP_PRESSED */
- 32, /* SONYPI_EVENT_FNKEY_ONLY */
- 33, /* SONYPI_EVENT_JOGDIAL_FAST_DOWN */
- 34, /* SONYPI_EVENT_JOGDIAL_FAST_UP */
- 35, /* SONYPI_EVENT_JOGDIAL_FAST_DOWN_PRESSED */
- 36, /* SONYPI_EVENT_JOGDIAL_FAST_UP_PRESSED */
- 37, /* SONYPI_EVENT_JOGDIAL_VFAST_DOWN */
- 38, /* SONYPI_EVENT_JOGDIAL_VFAST_UP */
- 39, /* SONYPI_EVENT_JOGDIAL_VFAST_DOWN_PRESSED */
- 40, /* SONYPI_EVENT_JOGDIAL_VFAST_UP_PRESSED */
- 41, /* SONYPI_EVENT_ZOOM_PRESSED */
- 42, /* SONYPI_EVENT_THUMBPHRASE_PRESSED */
- 43, /* SONYPI_EVENT_MEYE_FACE */
- 44, /* SONYPI_EVENT_MEYE_OPPOSITE */
- 45, /* SONYPI_EVENT_MEMORYSTICK_INSERT */
- 46, /* SONYPI_EVENT_MEMORYSTICK_EJECT */
- -1, /* SONYPI_EVENT_ANYBUTTON_RELEASED */
- -1, /* SONYPI_EVENT_BATTERY_INSERT */
- -1, /* SONYPI_EVENT_BATTERY_REMOVE */
- -1, /* SONYPI_EVENT_FNKEY_RELEASED */
- 47, /* SONYPI_EVENT_WIRELESS_ON */
- 48, /* SONYPI_EVENT_WIRELESS_OFF */
+ -1, /* 0 no event */
+ -1, /* 1 SONYPI_EVENT_JOGDIAL_DOWN */
+ -1, /* 2 SONYPI_EVENT_JOGDIAL_UP */
+ -1, /* 3 SONYPI_EVENT_JOGDIAL_DOWN_PRESSED */
+ -1, /* 4 SONYPI_EVENT_JOGDIAL_UP_PRESSED */
+ -1, /* 5 SONYPI_EVENT_JOGDIAL_PRESSED */
+ -1, /* 6 SONYPI_EVENT_JOGDIAL_RELEASED */
+0, /* 7 SONYPI_EVENT_CAPTURE_PRESSED */
+1, /* 8 SONYPI_EVENT_CAPTURE_RELEASED */
+2, /* 9 SONYPI_EVENT_CAPTURE_PARTIALPRESSED */
+3, /* 10 SONYPI_EVENT_CAPTURE_PARTIALRELEASED */
+4, /* 11 SONYPI_EVENT_FNKEY_ESC */
+5, /* 12 SONYPI_EVENT_FNKEY_F1 */
+6, /* 13 SONYPI_EVENT_FNKEY_F2 */
+7, /* 14 SONYPI_EVENT_FNKEY_F3 */
+8, /* 15 SONYPI_EVENT_FNKEY_F4 */
+9, /* 16 SONYPI_EVENT_FNKEY_F5 */
+ 10, /* 17 SONYPI_EVENT_FNKEY_F6 */
+ 11, /* 18 SONYPI_EVENT_FNKEY_F7 */
+ 12, /* 19 SONYPI_EVENT_FNKEY_F8 */
+ 13, /* 20 SONYPI_EVENT_FNKEY_F9 */
+ 14, /* 21 SONYPI_EVENT_FNKEY_F10 */
+ 15, /* 22 SONYPI_EVENT_FNKEY_F11 */
+ 16, /* 23 SONYPI_EVENT_FNKEY_F12 */
+ 17, /* 24 SONYPI_EVENT_FNKEY_1 */
+ 18, /* 25
Re: [Bugme-new] [Bug 9721] New: wake on lan fails with sky2 module
Rafael J. Wysocki wrote: Since it seems to be 100% reproducible, it would be very helpful if you could use git-bisect to identify the offending commit. allright, bisect found the offending commit, here's what i've done: first i started bisect with the following command (since i assumed it is a net-driver problem): git-bisect start 'v2.6.24-rc6' 'v2.6.23' '--' 'drivers/net/' after building many kernels and saying good/bad if wol worked/didn't work etc. it identified the following commit: # bad: [ac93a3946b676025fa55356180e8321639744b31] sky2: enable PCI config writes and refs/bisect/bad gives: 14:16:53 /usr/src/linux-2.6/.git # cat refs/bisect/bad ac93a3946b676025fa55356180e8321639744b31 need some more info? - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9721] New: wake on lan fails with sky2 module
supersud501 wrote: Rafael J. Wysocki wrote: Since it seems to be 100% reproducible, it would be very helpful if you could use git-bisect to identify the offending commit. allright, bisect found the offending commit, here's what i've done: first i started bisect with the following command (since i assumed it is a net-driver problem): git-bisect start 'v2.6.24-rc6' 'v2.6.23' '--' 'drivers/net/' after building many kernels and saying good/bad if wol worked/didn't work etc. it identified the following commit: # bad: [ac93a3946b676025fa55356180e8321639744b31] sky2: enable PCI config writes and refs/bisect/bad gives: 14:16:53 /usr/src/linux-2.6/.git # cat refs/bisect/bad ac93a3946b676025fa55356180e8321639744b31 need some more info? i just checked it: commented out the passage of the commit in kernel 2.6.24-rc7-git4 and compiled it: wol WORKS. so this one line is causing my wol-disturbance... but i noticed another bug on 2.6.24-rc7-git with sky2: dmesg shows a lot of lines every 5 seconds: [...] [ 357.400462] sky2 :02:00.0: error interrupt status=0xc000 [ 362.442039] printk: 41 messages suppressed. [ 362.442043] sky2 :02:00.0: error interrupt status=0x8000 [ 367.439151] printk: 18 messages suppressed. [ 367.439156] sky2 :02:00.0: error interrupt status=0x8000 [ 372.436267] printk: 30 messages suppressed. [ 372.436271] sky2 :02:00.0: error interrupt status=0x8000 [ 377.350236] printk: 19 messages suppressed. [...] since i do not notice any errors (yet) i'll wait till next rc, maybe it will be gone then... but i'm happy wol works again on 2.6.24 :) - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Lenovo ThinkPads need acpi_osi=Linux
On Sat 2008-01-12 04:16:08, Len Brown wrote: On Friday 11 January 2008 21:23, Henrique de Moraes Holschuh wrote: While helping a user find out what happened to his mute key, I found out that the Lenovo BIOSes need the OSI string Linux defined to behave properly in Linux. Lenovo has been attempting to make things a bit easier for Linux on their ThinkPads, by disabling the more obnoxious behaviours of the firmware (used by their Windows drivers) when in Linux. It looks like they used the OSI string for that. It is probably worthwhile to give a head's up: regressions involving thinkpads and 2.6.23+ should probably have a 'please test with acpi_osi=Linux' step added if there is any chance ACPI AML code, BIOS or SMBIOS code, or EC behaviour could be involved. The most concrete example I have right now of changed behaviour is the Mute key on the T61, which just plain disappears if acpi_osi=!Linux (2.6.23 default). I have also seen some hacked DSDTs around (mostly for older T4x models) which used the Linux OSI string to fix or work around AML weirdness. Those would break in 2.6.23 (and 2.6.24?) as well. Now, what should we do about it? Add a quirk to always define the Linux OSI string on ThinkPads (based on DMI information)? All IBM ones (which won't have BIOS revisions anymore, anyway) deal well with it, and Lenovo ones seem to benefit from it. We could also ask Lenovo to change the BIOS to stop paying attention to that OSI string, but they will likely want/need a trigger for the AML code to know it should change behaviour anyway, and the OSI string *does* look like the proper thing to use IMHO. I don't know if we could get them to arrive to a behaviour that is acceptable both to us, and also to their Windows drivers... I discussed this with Lenovo a few months ago and made it clear that Linux will unlikely default to answer yes to OSI(Linux) in the future -- for all the reasons I stated when I disabled it. However, they told me they wanted to use OSI(Linux) to enable the backlight (via video re-post) on S3 resume, and the problem at hand was a distro kernel which still had OSI(Linux), so that is what they did. I was unaware that they're using it for anything else, and the fact that they are lends further support to the case that as an OS interface string Linux is too vague to be meaningful. They seemed open to looking for another string, say Needs S3 video re-post. However, we didn't agree on such a string, and so it isn't in Linux or the Lenovo BIOS. I think until we have native Linux graphics driver for (fast) backlight restore, we need to add a DMI to enable OSI(Linux) for the offending Lenovo models. We'll need to have some coordination with the graphics guys so that they can turn this off from user-space when they don't need it. The reason it shoudl be turned off is that backlight enabling backlight from a native graphics driver is much faster than running through the video BIOS POST. So if we keep the OSI(Linux) video BIOS POST workaround in place permanently, it would put Linux at a permanent performance disadvantage to Windows. Hmm, they should not need to do anything. When linux calls video BIOS with lcall (acpi_sleep=s3_bios), they should turn on backlight and put video into text mode. They should also make sure mode setting works after that. I don't see how ACPI fits into this picture, and I think it can work well without ACPI tricks. -- (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-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9721] New: wake on lan fails with sky2 module
On Sun, 13 Jan 2008 16:08:38 +0100 supersud501 [EMAIL PROTECTED] wrote: supersud501 wrote: Rafael J. Wysocki wrote: Since it seems to be 100% reproducible, it would be very helpful if you could use git-bisect to identify the offending commit. allright, bisect found the offending commit, here's what i've done: first i started bisect with the following command (since i assumed it is a net-driver problem): git-bisect start 'v2.6.24-rc6' 'v2.6.23' '--' 'drivers/net/' after building many kernels and saying good/bad if wol worked/didn't work etc. it identified the following commit: # bad: [ac93a3946b676025fa55356180e8321639744b31] sky2: enable PCI config writes and refs/bisect/bad gives: 14:16:53 /usr/src/linux-2.6/.git # cat refs/bisect/bad ac93a3946b676025fa55356180e8321639744b31 need some more info? i just checked it: commented out the passage of the commit in kernel 2.6.24-rc7-git4 and compiled it: wol WORKS. so this one line is causing my wol-disturbance... So simply reverting this: commit ac93a3946b676025fa55356180e8321639744b31 Author: Stephen Hemminger [EMAIL PROTECTED] Date: Mon Nov 5 15:52:08 2007 -0800 sky2: enable PCI config writes On some boards, PCI configuration space access is turned off by default. The 2.6.24 driver doesn't turn it on, and should have. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] Signed-off-by: Jeff Garzik [EMAIL PROTECTED] diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c index c27c7d6..4f41a94 100644 --- a/drivers/net/sky2.c +++ b/drivers/net/sky2.c @@ -2791,6 +2791,9 @@ static void sky2_reset(struct sky2_hw *hw) sky2_write8(hw, B0_CTST, CS_RST_SET); sky2_write8(hw, B0_CTST, CS_RST_CLR); + /* allow writes to PCI config */ + sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON); + /* clear PCI errors, if any */ pci_read_config_word(pdev, PCI_STATUS, status); status |= PCI_STATUS_ERROR_BITS; fixes this regression? If so, we should revert that change. but i noticed another bug on 2.6.24-rc7-git with sky2: dmesg shows a lot of lines every 5 seconds: [...] [ 357.400462] sky2 :02:00.0: error interrupt status=0xc000 [ 362.442039] printk: 41 messages suppressed. [ 362.442043] sky2 :02:00.0: error interrupt status=0x8000 [ 367.439151] printk: 18 messages suppressed. [ 367.439156] sky2 :02:00.0: error interrupt status=0x8000 [ 372.436267] printk: 30 messages suppressed. [ 372.436271] sky2 :02:00.0: error interrupt status=0x8000 [ 377.350236] printk: 19 messages suppressed. [...] since i do not notice any errors (yet) i'll wait till next rc, maybe it will be gone then... That's not good. is this new behaviour? - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9721] New: wake on lan fails with sky2 module
Andrew Morton wrote: So simply reverting this: commit ac93a3946b676025fa55356180e8321639744b31 Author: Stephen Hemminger [EMAIL PROTECTED] Date: Mon Nov 5 15:52:08 2007 -0800 sky2: enable PCI config writes On some boards, PCI configuration space access is turned off by default. The 2.6.24 driver doesn't turn it on, and should have. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] Signed-off-by: Jeff Garzik [EMAIL PROTECTED] diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c index c27c7d6..4f41a94 100644 --- a/drivers/net/sky2.c +++ b/drivers/net/sky2.c @@ -2791,6 +2791,9 @@ static void sky2_reset(struct sky2_hw *hw) sky2_write8(hw, B0_CTST, CS_RST_SET); sky2_write8(hw, B0_CTST, CS_RST_CLR); + /* allow writes to PCI config */ + sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON); + /* clear PCI errors, if any */ pci_read_config_word(pdev, PCI_STATUS, status); status |= PCI_STATUS_ERROR_BITS; fixes this regression? If so, we should revert that change. yes, it does. but i noticed another bug on 2.6.24-rc7-git with sky2: dmesg shows a lot of lines every 5 seconds: [...] [ 357.400462] sky2 :02:00.0: error interrupt status=0xc000 [ 362.442039] printk: 41 messages suppressed. [ 362.442043] sky2 :02:00.0: error interrupt status=0x8000 [ 367.439151] printk: 18 messages suppressed. [ 367.439156] sky2 :02:00.0: error interrupt status=0x8000 [ 372.436267] printk: 30 messages suppressed. [ 372.436271] sky2 :02:00.0: error interrupt status=0x8000 [ 377.350236] printk: 19 messages suppressed. [...] since i do not notice any errors (yet) i'll wait till next rc, maybe it will be gone then... That's not good. is this new behaviour? at least on 2.6.23.12 i doesn't happen, so it's now for me in 2.6.24-rc7-git4 (but again, not testet in earlier versions of 2.6.24). since i do not feel any sideeffects yet after using it for ~6 hours (besides a really long dmesg-output), it's just a little bit annoying. if there's a way to identify the source of the problem besides of bisecting, just say so and i will take a look into it the next days. if bisecting is the only (time-consuming) way you have to wait at least until the next weekend :) - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9721] New: wake on lan fails with sky2 module
On Sun, 13 Jan 2008 21:27:40 +0100 supersud501 [EMAIL PROTECTED] wrote: Andrew Morton wrote: So simply reverting this: commit ac93a3946b676025fa55356180e8321639744b31 Author: Stephen Hemminger [EMAIL PROTECTED] Date: Mon Nov 5 15:52:08 2007 -0800 sky2: enable PCI config writes On some boards, PCI configuration space access is turned off by default. The 2.6.24 driver doesn't turn it on, and should have. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] Signed-off-by: Jeff Garzik [EMAIL PROTECTED] diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c index c27c7d6..4f41a94 100644 --- a/drivers/net/sky2.c +++ b/drivers/net/sky2.c @@ -2791,6 +2791,9 @@ static void sky2_reset(struct sky2_hw *hw) sky2_write8(hw, B0_CTST, CS_RST_SET); sky2_write8(hw, B0_CTST, CS_RST_CLR); + /* allow writes to PCI config */ + sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON); + /* clear PCI errors, if any */ pci_read_config_word(pdev, PCI_STATUS, status); status |= PCI_STATUS_ERROR_BITS; fixes this regression? If so, we should revert that change. yes, it does. OK, thanks. I queued up the revert and shall wait to hear from Stephen/David/Jeff on this. but i noticed another bug on 2.6.24-rc7-git with sky2: dmesg shows a lot of lines every 5 seconds: [...] [ 357.400462] sky2 :02:00.0: error interrupt status=0xc000 [ 362.442039] printk: 41 messages suppressed. [ 362.442043] sky2 :02:00.0: error interrupt status=0x8000 [ 367.439151] printk: 18 messages suppressed. [ 367.439156] sky2 :02:00.0: error interrupt status=0x8000 [ 372.436267] printk: 30 messages suppressed. [ 372.436271] sky2 :02:00.0: error interrupt status=0x8000 [ 377.350236] printk: 19 messages suppressed. [...] since i do not notice any errors (yet) i'll wait till next rc, maybe it will be gone then... That's not good. is this new behaviour? at least on 2.6.23.12 i doesn't happen, so it's now for me in 2.6.24-rc7-git4 (but again, not testet in earlier versions of 2.6.24). since i do not feel any sideeffects yet after using it for ~6 hours (besides a really long dmesg-output), it's just a little bit annoying. if there's a way to identify the source of the problem besides of bisecting, just say so and i will take a look into it the next days. if bisecting is the only (time-consuming) way you have to wait at least until the next weekend :) 2.6.23 also has this warning in sky2_err_intr() but it doesn't trigger there. Rafael, I think we'd have to class this as a post-2.6.23 regression. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9721] New: wake on lan fails with sky2 module
On Sunday, 13 of January 2008, Andrew Morton wrote: 2.6.23 also has this warning in sky2_err_intr() but it doesn't trigger there. Rafael, I think we'd have to class this as a post-2.6.23 regression. Yes, it's been being tracked already. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9721] New: wake on lan fails with sky2 module
I wonder if commit 84cd2dfb04d23a961c5f537baa243fa54d0987ac sky2: remove check for PCI wakeup setting from BIOS has anything to do with it, btw. supersud501, can you please check if the bug is still present in the current Linus' tree? - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9721] New: wake on lan fails with sky2 module
Rafael J. Wysocki wrote: I wonder if commit 84cd2dfb04d23a961c5f537baa243fa54d0987ac sky2: remove check for PCI wakeup setting from BIOS has anything to do with it, btw. supersud501, can you please check if the bug is still present in the current Linus' tree? I checked it (after git pulling the dir), and it still doesn't work. but the dmesg-output wasn't filled with those errors i reported before anymore. after removing that one commit (enable PCI config writes) wol works again, but the dmesg output is filled too! so that seems to be the source of the full dmesg-output. here a little bit more of the dmesg-output (but maybe i should open a new bug report?) [...] rmmod sky2 --- [ 1182.964000] sky2 eth0: disabling interface [ 1183.255862] ACPI: PCI interrupt for device :02:00.0 disabled modprobe syk2 -- [ 1192.951021] ACPI: PCI Interrupt :02:00.0[A] - GSI 19 (level, low) - IRQ 19 [ 1192.951034] PCI: Setting latency timer of device :02:00.0 to 64 [ 1192.951618] sky2 :02:00.0: v1.20 addr 0xf89fc000 irq 19 Yukon-EC (0xb6) rev 2 [ 1192.951636] sky2 :02:00.0: ignoring stuck error report bit [ 1192.952425] sky2 eth0: addr 00:18:f3:fe:93:11 ifdown eth0 ifup eth0 -- [ 1207.425171] sky2 eth0: enabling interface [ 1209.806138] printk: 97 messages suppressed. [ 1209.806143] sky2 :02:00.0: error interrupt status=0x8010 [ 1209.807184] sky2 eth0: Link is up at 100 Mbps, full duplex, flow control rx [ 1209.807502] sky2 :02:00.0: error interrupt status=0x8000 [ 1210.621117] sky2 :02:00.0: error interrupt status=0xc000 [ 1210.660325] sky2 :02:00.0: error interrupt status=0x8000 [ 1210.996873] sky2 :02:00.0: error interrupt status=0xc000 [ 1211.645470] printk: 1 messages suppressed. [ 1211.645474] sky2 :02:00.0: error interrupt status=0xc000 [ 1216.656564] printk: 328 messages suppressed. [ 1216.656569] sky2 :02:00.0: error interrupt status=0x8000 [ 1221.653677] printk: 17 messages suppressed. [ 1221.653681] sky2 :02:00.0: error interrupt status=0x8000 -- every 5 sec a new error [...] - and i noticed one more thing (i thought would just happen occasionally): everytime wol does not work (sending the magic packet does nothing), i have to cut off my pc completely from power because otherwise (powering it up by power button) it hangs endless on hard-disk-dedection (s-ata). other users with my mobo report same issues from time to time, but mine seems to be 100% reproducable. reenabling wol by removing the commit fixes this problem, too. the next new bug report i think. - btw, if anyone could tell me a way to rebuild only some modules (so i get the .ko file directly and can replace it by hand in /lib/modules/...) i could hack around a little bit too in sky2.c (or so) without the need to reinstall the whole kernel in order to test it... - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Lenovo ThinkPads need acpi_osi=Linux
On Sun, 13 Jan 2008, Pavel Machek wrote: The reason it shoudl be turned off is that backlight enabling backlight from a native graphics driver is much faster than running through the video BIOS POST. So if we keep the OSI(Linux) video BIOS POST workaround in place permanently, it would put Linux at a permanent performance disadvantage to Windows. Hmm, they should not need to do anything. When linux calls video BIOS with lcall (acpi_sleep=s3_bios), they should turn on backlight and put video into text mode. They should also make sure mode setting works after that. IMHO, in that case, we should probably be whitelist-enabling that on thinkpads (and allow for acpi_sleep=none to override it), or letting userspace change it at runtime. I don't see how ACPI fits into this picture, and I think it can work well without ACPI tricks. It fits because Lenovo did it in ACPI (or used to do it in ACPI, whatever). We can ask them to not do it, I suppose. But without some sort of autodetection on our part, I doubt they will remove it. -- 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-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Lenovo ThinkPads need acpi_osi=Linux
A bit more on this issue. I have received a report that on a X61, it actually works the opposite from the T61 and you need acpi_osi=!Linux to get the mute key to work. Well, I am asking the users to track down exactly *where* the mute key is comming from in each case (ACPI or keyboard controller). When I have the results, I will send an update to this thread. -- 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-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Lenovo ThinkPads need acpi_osi=Linux
On Sun, Jan 13, 2008 at 09:41:29PM -0200, Henrique de Moraes Holschuh wrote: On Sun, 13 Jan 2008, Pavel Machek wrote: When linux calls video BIOS with lcall (acpi_sleep=s3_bios), they should turn on backlight and put video into text mode. They should also make sure mode setting works after that. IMHO, in that case, we should probably be whitelist-enabling that on thinkpads (and allow for acpi_sleep=none to override it), or letting userspace change it at runtime. No. This breaks on the R50e, at least - I suspect it'd also have problems on any nvidia based machines, but I don't have one to hand at the moment. It can be set at runtime already. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Lenovo ThinkPads need acpi_osi=Linux
On Mon, Jan 14, 2008 at 12:35:54AM +, Matthew Garrett wrote: No. This breaks on the R50e, at least - I suspect it'd also have problems on any nvidia based machines, but I don't have one to hand at the moment. It can be set at runtime already. Just to clarify this further, in the relatively near-term future we're not going to want the low-level ACPI code to do anything video-related on a lot of hardware. The in-kernel modesetting code for Intel machines will be able to handle this significantly more effectively. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Reset ACPI backlight on resume
Some machines seem to need the backlight brightness to be reset on
resume. Add support for doing so to the video module.
Signed-off-by: Matthew Garrett [EMAIL PROTECTED]
---
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index b8ce6dc..09a85eb 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -74,6 +74,7 @@ MODULE_LICENSE(GPL);
static int acpi_video_bus_add(struct acpi_device *device);
static int acpi_video_bus_remove(struct acpi_device *device, int type);
+static int acpi_video_resume(struct acpi_device *device);
static const struct acpi_device_id video_device_ids[] = {
{ACPI_VIDEO_HID, 0},
@@ -88,6 +89,7 @@ static struct acpi_driver acpi_video_bus = {
.ops = {
.add = acpi_video_bus_add,
.remove = acpi_video_bus_remove,
+ .resume = acpi_video_resume,
},
};
@@ -1896,6 +1900,25 @@ static void acpi_video_device_notify(acpi_handle handle,
u32 event, void *data)
}
static int instance;
+static int acpi_video_resume(struct acpi_device *device)
+{
+ struct acpi_video_bus *video;
+ struct acpi_video_device *video_device;
+ int i;
+
+ if (!device || !acpi_driver_data(device))
+ return -EINVAL;
+
+ video = acpi_driver_data(device);
+
+ for (i=0; ivideo-attached_count; i++) {
+ video_device = video-attached_array[i].bind_info;
+ if (video_device video_device-backlight)
+ acpi_video_set_brightness(video_device-backlight);
+ }
+ return AE_OK;
+}
+
static int acpi_video_bus_add(struct acpi_device *device)
{
acpi_status status;
--
Matthew Garrett | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
