lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ