On Fri, Mar 25, 2011 at 12:21 PM, Corentin Chary <corentin.chary@xxxxxxxxx> wrote: > 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 ? On Mon, Mar 28, 2011 at 7:43 AM, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> 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 <andy.ross@xxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
