Hi. I am an owner of a BenQ Joybook S53W laptop which unfortunately includes a hardware SRS Wow! sound-butchering feature. It is on by default, and BenQ supplies a windows app to turn it on or off. Having examined this app/driver, it looks like it accesses an embedded controller with command/status port 0x6c and data port 0x68. Linux detects EC0 on 0x62 and 0x66 and there appears to be no info on this second controller in the DSDT (there is no ECDT). I have tried to replicate what the windows app/driver does in linux, which involves disabling interrupts and then waiting for bits 1 and 2 of the status port to be set before writing a command like 0x53 to the command port, waiting again, then writing to the data port. When I do this under linux, the status bits are never set - the status register just has a value of 0x04. If I boot with acpi=off bits 1 and 2 do seem to be set when needed, so the commands appear to succeed (although they are not having the desired effect, AFAICT). So, my questions are: Is linux acpi initialising this second EC in some way? Or is Windows perhaps initialising it in a way linux isn't? Is it likely that I need to enable the chip by writing to some other register? Does anyone have any ideas how I could proceed? Please CC me on reply. Thanks! Ashley Milsted PS: The Windows app does essentially this: spin_lock; cli; while !(inb 0x6c & 1); //with max-loops 65535 while !(inb 0x6c & 2); //with max-loops 65535 outb 0x6c, 0x53 //turn SRS effect off while !(inb 0x6c & 2); //with max-loops 65535 while !(inb 0x6c & 1); //with max-loops 65535 while !(inb 0x6c & 2); //with max-loops 65535 outb 0x68, 0x00 //turn SRS Effect off while !(inb 0x6c & 2); //with max-loops 65535 sti; spin_unlock; -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
