Message-ID: <9BF90A6D61BF154E973D03082989295CA22B3F803A@SAFEX1MAIL3.st.com>
Date:	Fri, 3 Dec 2010 12:20:40 +0100
From:	Matteo DAMENO <matteo.dameno@...com>
To:	Jonathan Cameron <jic23@....ac.uk>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Mohamed Ikbel Boulabiar <boulabiar@...il.com>,
	mems applications <mems.applications@...com>,
	"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Carmine IASCONE <carmine.iascone@...com>,
	Greg KH <gregkh@...e.de>,
	Guenter Roeck <guenter.roeck@...csson.com>,
	Matteo DAMENO <matteo.dameno@...com>,
	Jean Delvare <khali@...ux-fr.org>,
	Paolo BENDISCIOLI <paolo.bendiscioli@...com>
Subject: RE: [PATCH] input: misc: add lps001wp_prs driver


-----Original Message-----
> From: Jonathan Cameron [mailto:jic23@....ac.uk]
> Sent: Thursday, December 02, 2010 8:42 PM
> To: Matteo DAMENO
> Cc: Mohamed Ikbel Boulabiar; Dmitry Torokhov; mems applications; linux-
> input@...r.kernel.org; linux-kernel@...r.kernel.org; Carmine IASCONE; Greg
> KH; Guenter Roeck; Jean Delvare
> Subject: Re: [PATCH] input: misc: add lps001wp_prs driver
> 
> Sorry for my lack of response earlier in this thread. Looks
> like my linux-input subscription has died for some reason so
> I hadn't seen it until someone kindly cc'd me.
> 
> >> -----Original Message-----
> >> From: Mohamed Ikbel Boulabiar [mailto:boulabiar@...il.com]
> >> Sent: Tuesday, November 30, 2010 11:35 AM
> >> To: Dmitry Torokhov
> >> Cc: mems applications; linux-input@...r.kernel.org; linux-
> >> kernel@...r.kernel.org; Matteo DAMENO; Carmine IASCONE; mems
> >> Subject: Re: [PATCH] input: misc: add lps001wp_prs driver
> >>
> >> On Tue, Nov 30, 2010 at 7:09 AM, Dmitry Torokhov
> >> <dmitry.torokhov@...il.com> wrote:
> >>>> +      If you say yes here you get support for the
> >>>> +      STM LPS001D Barometer/Termometer on I2C bus.
> >>>
> >>> This does not belong to input subsystem, IIO is a better fit.
> >>
> >> According to this site:
> >> http://www.cnbc.com/id/40413317
> >> and its datasheet:
> >> http://www.findmems.com/wp-content/uploads/2010/11/LPS001WP-
> >> DATASHEET.pdf
> >>
> >> This sensors applications are:
> >> ■ Altimeter and barometer for portable devices
> >> ■ Smartphones
> >> ■ Indoor navigation
> >> ■ GPS applications
> >> ■ Weather station equipment
> >> ■ Sports watches
> >>
> >> "the same devices would be able to identify the precise location in
> >> all three dimensions, allowing, for example, a mobile phone to send a
> >> call to an emergency fire, medical or police service that identified
> >> not only the location of the building but also the particular floor."
> >> Identifying 3d location is similar to what many joystick are doing.
> >>
> >> Specially the indoor navigation information means an information about
> >> the user. And the information is very tied to the user.
> >> I don't know whether this can be used to map with virtual reality in a
> >> game, or where you use sensors data to give user informations when
> >> visiting a museum.
> >>
> >>
> >> Dmitry, is it possible to start putting similar drivers in a new
> >> drivers/input/sensors directory but which belongs to the input
> >> subsystem ? What do you think ?
> >>
> >
> > We agree with you.
> > It would be a good idea.
> > We are working on many device drivers that are matching your description
> and
> > we are ready to submit them.
> >
> > We are disoriented because every maintainer seems to bounce our
> submissions
> > because of inappropriate position for the device.
> >
> > IIO, input/misc, I2C (we didn't submit here because of deprecation stated
> in
> > Documentation).
> > Some one is also submitting our drivers with modifications
> > under Hwmon...
> If it's out of scope they are wasting their time so it will bounce anyway.
> Hwmon is now actively (very well) maintained so inappropriate drivers will
> get a reply quickly. (and if you are talking about the combined
> magnetometer
> and accelerometer driver submitted the other day, it already has!)
> 
> Note the big lis3* driver in there is getting kicked out to drivers/misc
> asap.
> No one seems quite sure why it went in there in the first place and it has
> been
> causing confusion ever since!  The presence of that driver is the main
> reason
> people new to these devices tend to think they should be in hwmon in the
> first
> place. (cc'd Guenter and Jean for their information)
> >
> > What to do?
> This is well within the scope of IIO, so we will be more than happy to take
> the driver and assist with any issues etc caused by the move. The other
> existing
> option is to put it in drivers/misc and wait for IIO to move out of staging
> or something else to come along. There are a few sensor drivers already
> there
> for exactly that reason.
> 
> Disadvantages of MISC:
> * Not a coherent location for drivers.  Whether things match in abi etc
> is more fluid and relies on a few people shouting when new drivers arrive.
> 
> Disadvantages of IIO:
> * User space interfaces aren't guaranteed to be stable. However, if you
> notify
> us that they need to be for a particular device we will support the current
> ones
> for a suitable period (and provide any new ones alongside).  Basically,
> it's
> taking a while to get the interfaces right though (except for new stuff) I
> think
> we are pretty close.
> * Kernel abi's probably change more than in the majority of the kernel.
> This isn't a problem if you are in tree though as we will obviously update
> the
> driver in sync with the changes.
> * One or two core elements are in need of work (the buffering code needs an
> easier to review implementation and the input bridge, in userspace needs
> some actual work beyond a proof of concept).
> 
> Conversely we have more flexibility to change things as and when we
> discover
> we got a decision wrong.  We have quite a lot of drivers so working
> on unifying interfaces is becoming easier all the time.  It's Direct
> Digital Synthesis (DDS) chips this week ;)  No merged altimeter drivers
> yet though so there will probably be some new abi elements to pin down.
> 
> Personally I don't really mind where drivers are physically located, just
> that
> we use consistent interfaces to user space where ever possible.  The
> location
> is easy to change (as it's controlled more or less by kernel developers),
> the interfaces less so as userspace applications depend on them.
> 
> Nice looking device by the way. I'll take a look at the driver shortly
> (can do a lot of review independent of the subsystem it is going in).
> 

Thank you Jonathan, 
I think that driver/misc/ could be a good place, at least at first: when
a more stable knowledge will be reached (we will try to  contribute) 
we could move them where useful.
We are going to submit all our drivers there.
Your reviews are really appreciated.
More, the are some feature to add to lps001wp.
The same applies for the accelerometer and magnetometer we are going to submit.

Please we need to know if we have to close the currently opened threads.


> Thanks,
> 
> Jonathan
> >
> > Matteo Dameno
> >
> >>
> >> i

Thanks,
Matteo

Powered by blists - more mailing lists