Ccing Dmitry and Matthew, they may want to comment that one. On Thu, Mar 24, 2011 at 11:02 PM, Andy Ross <andy.ross@xxxxxxxxxxxxx> wrote: > Support the built-in accelerometer on the Lucid tablets as a standard > 3-axis input device. > > Signed-off-by: Andy Ross <andy.ross@xxxxxxxxxxxxx> > --- > Â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 ? -- 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
