On Fri, Mar 25, 2011 at 12:21 PM, Corentin Chary <[email protected]> wrote: > Ccing Dmitry and Matthew, they may want to comment that one. > > On Thu, Mar 24, 2011 at 11:02 PM, Andy Ross <[email protected]> wrote: >> Support the built-in accelerometer on the Lucid tablets as a standard >> 3-axis input device. >> >> Signed-off-by: Andy Ross <[email protected]> >> --- >> drivers/platform/x86/Kconfig | 9 ++- >> drivers/platform/x86/asus-laptop.c | 137 >> +++++++++++++++++++++++++++++++++++- >> 2 files changed, 141 insertions(+), 5 deletions(-) >> >> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig >> index b6f983e..43906f5 100644 >> --- a/drivers/platform/x86/Kconfig >> +++ b/drivers/platform/x86/Kconfig >> @@ -67,10 +67,11 @@ config ASUS_LAPTOP >> This is a driver for Asus laptops and the Pegatron Lucid >> tablet. It may also support some MEDION, JVC or VICTOR >> laptops. It makes all the extra buttons generate standard >> - ACPI events and input events. It also adds support for video >> - output switching, LCD backlight control, Bluetooth and Wlan >> - control, and most importantly, allows you to blink those >> - fancy LEDs. >> + ACPI events and input events, and on the Lucid the built-in >> + accelerometer appears as an input device. It also adds >> + support for video output switching, LCD backlight control, >> + Bluetooth and Wlan control, and most importantly, allows you >> + to blink those fancy LEDs. >> >> For more information and a userspace daemon for handling the extra >> buttons see <http://acpi4asus.sf.net>. >> diff --git a/drivers/platform/x86/asus-laptop.c >> b/drivers/platform/x86/asus-laptop.c >> index 6651d8c..9b07368 100644 >> --- a/drivers/platform/x86/asus-laptop.c >> +++ b/drivers/platform/x86/asus-laptop.c >> @@ -224,6 +224,14 @@ static char *display_get_paths[] = { >> #define PEGA_READ_ALS_H 0x02 >> #define PEGA_READ_ALS_L 0x03 >> >> +#define PEGA_ACCEL_NAME "pega_accel" >> +#define PEGA_ACCEL_DESC "Pegatron Lucid Tablet Accelerometer" >> +#define METHOD_XLRX "XLRX" >> +#define METHOD_XLRY "XLRY" >> +#define METHOD_XLRZ "XLRZ" >> +#define PEGA_ACC_CLAMP 512 /* 1G accel is reported as ~256, so clamp to 2G >> */ >> +#define PEGA_ACC_RETRIES 3 >> + >> /* >> * Define a specific led structure to keep the main structure clean >> */ >> @@ -249,6 +257,7 @@ struct asus_laptop { >> >> struct input_dev *inputdev; >> struct key_entry *keymap; >> + struct input_polled_dev *pega_accel_poll; >> >> struct asus_led mled; >> struct asus_led tled; >> @@ -262,6 +271,10 @@ struct asus_laptop { >> bool have_rsts; >> bool have_pega_lucid; >> int lcd_state; >> + bool pega_acc_live; >> + int pega_acc_x; >> + int pega_acc_y; >> + int pega_acc_z; >> >> struct rfkill *gps_rfkill; >> >> @@ -390,6 +403,99 @@ static int asus_pega_lucid_set(struct asus_laptop >> *asus, int unit, bool enable) >> return write_acpi_int(asus->handle, method, unit); >> } >> >> +static int pega_acc_axis(struct asus_laptop *asus, int curr, char *method) >> +{ >> + int i, delta; >> + unsigned long long val; >> + for (i = 0; i < PEGA_ACC_RETRIES; i++) { >> + acpi_evaluate_integer(asus->handle, method, NULL, &val); >> + >> + /* The output is noisy. From reading the ASL >> + * dissassembly, timeout errors are returned with 1's >> + * in the high word, and the lack of locking around >> + * thei hi/lo byte reads means that a transition >> + * between (for example) -1 and 0 could be read as >> + * 0xff00 or 0x00ff. */ >> + delta = abs(curr - (short)val); >> + if (delta < 128 && !(val & ~0xffff)) >> + break; >> + } >> + return clamp_val((short)val, -PEGA_ACC_CLAMP, PEGA_ACC_CLAMP); >> +} > > Wow :/ How long is an acpi_evaluate_integer call here ? > >> +static int asus_platform_probe(struct platform_device *pd) >> +{ >> + struct asus_laptop *asus = dev_get_drvdata(&pd->dev); >> + >> + /* This is instantiated during platform driver initialization >> + * becuase if it's done from underneath asus_acpi_add(), the >> + * resulting input device can be grabbed by an early userspace >> + * reader before ACPI initialization is finished and something >> + * oopses underneath the acpi_evaluate_integer() call out of >> + * pega_accel_poll(). Firmware bug? */ >> + pega_accel_probe(asus); >> + >> + return 0; >> +} > > When is asus_platform_probe called exactly ? Because I'd say it's > called during asus_platform_probe(), and that doesn't fix your issue > right ?
On Mon, Mar 28, 2011 at 7:43 AM, Dmitry Torokhov <[email protected]> wrote: > On Fri, Mar 25, 2011 at 12:21:20PM +0100, Corentin Chary wrote: >> Ccing Dmitry and Matthew, they may want to comment that one. >> >> On Thu, Mar 24, 2011 at 11:02 PM, Andy Ross <[email protected]> wrote: >> > +static int asus_platform_probe(struct platform_device *pd) >> > +{ >> > + struct asus_laptop *asus = dev_get_drvdata(&pd->dev); >> > + >> > + /* This is instantiated during platform driver initialization >> > + * becuase if it's done from underneath asus_acpi_add(), the >> > + * resulting input device can be grabbed by an early userspace >> > + * reader before ACPI initialization is finished and something >> > + * oopses underneath the acpi_evaluate_integer() call out of >> > + * pega_accel_poll(). Firmware bug? */ >> > + pega_accel_probe(asus); >> > + >> > + return 0; >> > +} >> >> When is asus_platform_probe called exactly ? Because I'd say it's >> called during asus_platform_probe(), and that doesn't fix your issue >> right ? I meant during *asus_platform_init()* (which is called by asus_acpi_add()), not *asus_platform_probe()* -- Corentin Chary http://xf.iksaif.net -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
