Message-id: <4A125265.6040509@samsung.com>
Date:	Tue, 19 May 2009 15:32:05 +0900
From:	Kim Kyuwon <q1.kim@...sung.com>
To:	Jonathan Cameron <jic23@....ac.uk>
Cc:	felipe.balbi@...ia.com, Kim Kyuwon <chammoru@...il.com>,
	ext Mohamed Ikbel Boulabiar <boulabiar@...il.com>,
	Trilok Soni <soni.trilok@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Jean Delvare <khali@...ux-fr.org>,
	"Zhang, Xing Z" <xing.z.zhang@...el.com>,
	"Gross, Mark" <mark.gross@...el.com>,
	jketreno <jketreno@...ux.intel.com>,
	"Trisal, Kalhan" <kalhan.trisal@...el.com>
Subject: Re: [RFC] Add Input IOCTL for accelerometer devices

Hello Jonathan,

Jonathan Cameron wrote:
>>>> Yeah, let's try to define the best way to expose accelerometers with
>>>> linux kernel and avoid a sysfs hell. Better sooner than later.
>>> Felipe,
>>> Can I ask why did you say "avoid a sysfs hell"?. I have thought Kernel
>>> developers prefer sysfs to IOCTL lately.
>> For sure sysfs is prefered, but I meant that without a proper
>> abstraction or definition of how to export the device, each device
>> driver write will export sysfs nodes as they want and that's really bad
>> since we create the 'userland interface'. If it's messed up from the
>> beginning, it's gonna be like that for ages.
> This was very much one of the thinks IIO was designed to address.
> One thing to keep in mind is that the framework
> was not intended to replace input / hwmon if they are the appropriate places
> for a given driver. In fact one of the conclusions of the discussions linked
> above was that, in cases where an accelerometer (or other sensor) serves
> different purposes in different devices it may make sense to actually provide
> more than one kernel driver. (obviously sharing code where appropriate.

I can't understand this:
"in cases where an accelerometer (or other sensor) serves different 
purposes in different devices it may make sense to actually provide more 
than one kernel driver. (obviously sharing code where appropriate."
Was the conclusion "Make a framework(iio) which can do various functions?"

>>> input_allocate_polled_device, ...) and macros(ABS_X,  ABS_Y, ...)of
>>> Input subsystem are useful to accelerometer too. If we create another
>>> APIs and Macros for accelerometers, I think It's another duplicate
>>> work and result.
> beware of the fact that x,y,z aren't exactly cleanly defined for a given
> sensor!
>> for sure
> Agreed.  If you know a given accelerometer is only going to be used for
> input then that's where the driver belongs.  However, these chips are
> generally capable of a lot more and it tends to be annoying specific.
> Take for example things like calibration offsets, and for the really fun
> cases on chip event driven ring buffers?  These really don't fit into
> your classic input cases.

I can't understand why you inserted ring buffers related stuffs in iio. 
  Please let me understand in easy words. And please note that in 
/Documentation/SubmittingPatches

644 4) Don't over-design.
645
646 Don't try to anticipate nebulous future cases which may or may not
647 be useful:  "Make it as simple as you can, and no simpler."

>>> In conclusion,
>>> We need the inheritance concept in the object-oriented programming.
>>> Accelerometer device sometimes can be hwmon device, sometimes input
>>> device.
> I'd also argue the problem here is that you are going to end up with a
> large class of similar devices.  If you start directly adding accelerometers
> to Input then the same arguement applies to magnetometers, bend sensors,
> gyroscopes etc.

I already answer this issue in previous mail that I sent.

 > Also beware that many accelerometers are going to be wired
> up to adc's (rather than providing digital outputs) so you'll need some
> framework to specify this connectivity. (open area in IIO to and the moment).

I can't understand. Why we should make accelerometer(or sensor) 
framework relate to ADC? My two accelerometer are not in this cases. If 
really sensors are related to ADC, it's better make this as library or 
application. Why don't we to be simple. Please let me understand in easy 
words.

Let me ask a few question in conclusion.

1) Does your iio subsystem have all functions which attached kxsd9 
driver has? i.e.
a. works in polling mode
b. works in interrupt mode
c. provide an interface to user space in order setting a few parameters 
and read x, y, z variances.

2) How long will it take to your iio subsystem is merged into mainline?
I have quick review of you iio subsytem. Sorry but I think it' somewhat 
complicated and have a lot of functions which are still not needed. And 
it seems like your coding style doesn't look like Linux coding style 
that I'm familiar with.

I just hope we can add some accelerometer feature into mainline kernel 
as soon as possible ;)

Regards,
Kyuwon

View attachment "kxsd9.c" of type "text/plain" (14412 bytes)

Powered by blists - more mailing lists