[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <331ABD5ECB02734CA317220B2BBEABC13177DFF6@DBDE01.ent.ti.com>
Date: Thu, 19 Jan 2012 05:30:52 +0000
From: "AnilKumar, Chimata" <anilkumar@...com>
To: Arnd Bergmann <arnd@...db.de>, Jonathan Cameron <jic23@....ac.uk>,
"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>
CC: "greg@...ah.com" <greg@...ah.com>,
"eric.piel@...mplin-utc.net" <eric.piel@...mplin-utc.net>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"broonie@...nsource.wolfsonmicro.com"
<broonie@...nsource.wolfsonmicro.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
"Nori, Sekhar" <nsekhar@...com>,
Dmitry Torokhov <dmitry.torokhov@...il.com>
Subject: RE: [PATCH] lis3lv02d: Add STMicroelectronics lis33ldlh digital
Hi Arnd,
On Wed, Jan 18, 2012 at 22:41:15, Arnd Bergmann wrote:
> On Wednesday 18 January 2012, Jonathan Cameron wrote:
> > Arnd Bergmann <arnd@...db.de> wrote:
> >
> > >Any opinions where they should live? input, iio or a new subsystem?
> > >
> > Personal thought is that straight 3d devices very directed at input
> > should go there. Iio has a few wrinkles left for the in kernel
> > interfaces needed for a bridge to input. For starters the pull
> > and push data interfaces have not merged yet (in staging) and we
> > have not started on in kernel acess to non data events yet(thresholds).
> > Still happy to take them when we can support usecases fully.
>
> Ok, thanks for the information, sounds all reasonable. I think we
> can definitely say no to new accelerometer drivers in drivers/misc
> then and refer them to iio and input.
>
> In case of lis33ldlh, I would like to see it move out at some point
> once the necessary parts of iio have graduated out of staging.
> Hopefully it won't be a large amount of work to convert it to
> a different internal API.
>
> AnilKumar, what are the existing users of the driver? Is it still
> possible to convert them to use iio without causing problems for
> people that rely on this driver, or do we have to keep supporting the
> current interface?
Android userspace running on TI AM335x EVM is using the interface
provided by lis3lv02d. They were asking some more interfaces from
lis3lvo2d driver.
There are multiple ways we can interface accelerometer to Android layers,
which is implemented on hardware abstraction layer (HAL) in Andriod.
1) Interrupt mode
2) Polling mode
2a) Kernel polling
2b) Timer polling
Based on the interfaces provided by the lis3lv02d as well as
lis331dlh (H/W not supporting the interrupts) they were implementing
the kernel polling mechanism.
So implementation on HAL is like this if accelerometer interface is
opened then kernel will start polling this driver periodically and
pass events to input subsystem. (It's a little bit over head)
Generally the device should be open but kernel should only poll
when an app that uses accelerometer is started.
The biggest requirement for them (Andriod people) is to allow user to
enable / disable accelerometer from user space and to configure
the accelerometer polling frequency.
Today there is no option in lis3lvo2d driver to provide this kind
of functionalities
>
> Arnd
>
Regards
AnilKumar
Powered by blists - more mailing lists