New style I2C driver for KXSD9 accelerometer

New style I2C driver for KXSD9 accelerometer

[varun mahajan]

[-- Attachment #1.1: Type: text/plain, Size: 2123 bytes --]

Hi,
 
I m implementing a driver for accelerometer KXSD9 in linux kernel 2.6.24.7 for OMAP-3430. KXSD9 sensor will be connected to the i2c bus so it will be an i2c client.
 
I m implementing a new style driver, so following are the steps that I m following:
 
1. Putting the device info (busnum, address, irq) in the board specific initialization code. From this the i2c-core will create a client for my device when the corresponding bus adapter (i2c_adapter) is registered.
 
2. I m implementing the following i2c_driver for my device
 
struct i2c_driver KXSD9_i2c_driver =
{
            .driver = {
                        .name = "KXSD9_driver",
            },
            
            .probe = KXSD9_probe, /* this will do the device initialization */
            .remove = KXSD9_remove,
 
            .shutdown = KXSD9_shutdown,
            .suspend = KXSD9_suspend,
            .resume = KXSD9_resume,
};
 
3. My requirement is that I need to export the file operations (specific ioctl commands) to the user space. I am not sure how it has to be done from this driver????
 
I thought of the following approach:
Registering a misc device to export the file operations
 
int __init KXSD9_driver_init()
{
           /*Provide /dev interface to user space and export the file   
             operations */
           misc_register(&KXSD9_misc_device);
 
           /*Request the IRQ and install the interrupt handler*/
           request_irq(.. KXSD9_IRQ . .);
 
           /*Add the i2c_driver*/
           i2c_add_driver(&KXSD9_i2c_driver);
}
 
Is this the correct way of doing it???????? Or the file operations should be exported using some other method in case of i2c_drivers????
 
Your reply will be highly helpful… Thanks in advance….
 
Varun


      Download prohibited? No problem. CHAT from any browser, without download. Go to http://in.webmessenger.yahoo.com/

[-- Attachment #1.2: Type: text/html, Size: 8719 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: New style I2C driver for KXSD9 accelerometer

[Jonathan Cameron]

Hi,

First question is whether you are interested in getting this into mainline?

The reason for asking is that at current time, how you code up the driver
is very dependent on what you want it for. See discussions of industrialio
on lkml for more on this.
 
> I m implementing a driver for accelerometer KXSD9 in linux kernel
> 2.6.24.7 for OMAP-3430. KXSD9 sensor will be connected to the i2c bus so
> it will be an i2c client.

Interesting looking chip. I hadn't come across that one before! I'll see if
I can get hold of one to have a play.
> 
> I m implementing a new style driver, so following are the steps that I m
> following:
> 
> 3. My requirement is that I need to export the file operations (specific
> ioctl commands) to the user space. I am not sure how it has to be done
> from this driver????
What sort of commands are we talking about?  In the vast majority of cases
it's preferable to do things like setting offsets etc via a sysfs interface
and only use character devices for high speed reading and passing events
up to userspace. 
> 
>  
> 
> I thought of the following approach:
> 
> Registering a misc device to export the file operations
> 
>  
> 
> int __init KXSD9_driver_init()
> 
> {
> 
>            /*Provide /dev interface to user space and export the file  
> 
>              operations */
> 
>            misc_register(&KXSD9_misc_device);
> 
>  
> 
>            /*Request the IRQ and install the interrupt handler*/
> 
>            request_irq(.. KXSD9_IRQ . .);
> 
>  
> 
>            /*Add the i2c_driver*/
> 
>            i2c_add_driver(&KXSD9_i2c_driver);
> 
> }
> 
>  
> 
> Is this the correct way of doing it???????? Or the file operations
> should be exported using some other method in case of i2c_drivers????
The key thing about init functions is that they are typically run once when
the driver module is inserted (or on initial boot up if the driver is built 
into the kernel)  If you want a unified character device for all such
accelerometers this would probably be the right place to do it.
(in this case we basically mean a single major number)

You would then need to add some registration code to the probe function
so that each accelerometer present is allocated a separate minor number,
thus allowing you to distinguish between them.

You could also take the more general approach used in iio (cribbed from
the input subsystem) to allow all accelerometer like sensors to share
a common major number then switch the file operations when the individual
character devices are opened to the set relevant to a particular
sensor.

Alternatively whilst I'm always in favour of people writing properly
structured drivers useful to anyone else with the same device,
you could just hard code all of the above into a driver along the lines
of exactly what you have suggested perhaps with a few to cleaning it
up and integrating with more general subsystems at a later date.

If you are interested in iio drop me an email and I'll send you a much
cleaner patch set that has yet been posted. (few bits to clean up yet
before I do a proper posting of a patch set).  Unfortunately it might
be a bit tricky to back port to 2.6.24 as I think there have been a
few changes in i2c since then.

Cheers

Re: New style I2C driver for KXSD9 accelerometer

[Trilok Soni]

Hi Varun,

On Fri, Sep 19, 2008 at 8:21 PM, varun mahajan <invincible_6-/E1597aS9LQxFYw1CcD5bw@public.gmane.org> wrote:
> Hi,
>
>
>
> I m implementing a driver for accelerometer KXSD9 in linux kernel 2.6.24.7
> for OMAP-3430. KXSD9 sensor will be connected to the i2c bus so it will be
> an i2c client.

You could implement this under input subsystem itself, like how openmoko
did it.

http://wiki.openmoko.org/wiki/Technical:Accelerometer_Fundamentals
http://wiki.openmoko.org/wiki/Accelerometer_data_retrieval
https://svn.openmoko.org/trunk/src/target/kernel/patches/lis302dl.patch


-- 
---Trilok Soni
http://triloksoni.wordpress.com
http://www.linkedin.com/in/triloksoni

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: New style I2C driver for KXSD9 accelerometer

[Ben Dooks]

On Mon, Sep 22, 2008 at 10:38:40AM -0700, Trilok Soni wrote:
> Hi Varun,
> 
> On Fri, Sep 19, 2008 at 8:21 PM, varun mahajan <invincible_6-/E1597aS9LQxFYw1CcD5bw@public.gmane.org> wrote:
> > Hi,
> >
> >
> >
> > I m implementing a driver for accelerometer KXSD9 in linux kernel 2.6.24.7
> > for OMAP-3430. KXSD9 sensor will be connected to the i2c bus so it will be
> > an i2c client.
> 
> You could implement this under input subsystem itself, like how openmoko
> did it.

That argument has been had on linux-kernel already, I liked it but the
input subsystem is aparently not good enough for input devices. There
is quite extensive discussion about this if you want to have a look
in the linux-kernel archives.

> http://wiki.openmoko.org/wiki/Technical:Accelerometer_Fundamentals
> http://wiki.openmoko.org/wiki/Accelerometer_data_retrieval
> https://svn.openmoko.org/trunk/src/target/kernel/patches/lis302dl.patch

I've an Bosch SMB380 driver as well, but until someone gets this
sorted out there's not much we can do. I belive one of the posters
to this thread has proposed an alternative, but I have no idea what
the current state of affairs is wrt to getting this or anything
else merged.

-- 
Ben (ben-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: New style I2C driver for KXSD9 accelerometer

[Jonathan Cameron]

Hi Ben,
>>>
>>>
>>>
>>> I m implementing a driver for accelerometer KXSD9 in linux kernel 2.6.24.7
>>> for OMAP-3430. KXSD9 sensor will be connected to the i2c bus so it will be
>>> an i2c client.
>> You could implement this under input subsystem itself, like how openmoko
>> did it.
> 
> That argument has been had on linux-kernel already, I liked it but the
> input subsystem is aparently not good enough for input devices. There
> is quite extensive discussion about this if you want to have a look
> in the linux-kernel archives.

The conclusion of that discussion and some subsequent ones around
particular drivers came down to the first question I asked. Basically
it depends on what you want to do with it.  If it is indeed being used as
an input device, at least for the time being, the input subsystem is going
to be the place to put it. (though the input guys aren't overly keen)
An alternative that has been proposed is to temporarily put any such drivers
in misc on the basis that they can then get swept up when a suitable
alternative hits the mainline.  This is what is happening with those
accelerometer that have yet another purpose (free fall detection and disk
parking).

My particular applications and the reason for sparking the original discussion
are concentrated around measurement of various things including acceleration
with a view to use within various realtime algorithms. I'm not trying to drive
a gui.  Hence the requirements are quite different (things like ring buffer
handling, high accuracy flexible timing of sampling etc).  

There was a suggestion that it might be possible to make dual mode drivers
that work for both purposes but at them moment this is someway down the line
and I'm not personally convinced it will necessarily be a good idea (too many
compromises may be necessary to fit both frameworks).  Possibly we are looking
at a shared code situation rather than actually sharing the whole driver.
 
>> http://wiki.openmoko.org/wiki/Technical:Accelerometer_Fundamentals
>> http://wiki.openmoko.org/wiki/Accelerometer_data_retrieval
>> https://svn.openmoko.org/trunk/src/target/kernel/patches/lis302dl.patch
> 
> I've an Bosch SMB380 driver as well, but until someone gets this
> sorted out there's not much we can do.

Cool, is the driver available somewhere? (I wouldn't mind taking a look)

> I belive one of the posters
> to this thread has proposed an alternative, but I have no idea what
> the current state of affairs is wrt to getting this or anything
> else merged.

That'll be me I guess ;( (and industrialio as it's currently called - I'm
still hoping someone comes up with a better name). Anyhow I'll give a
quick update here as it may be a week or two before I've cleaned up
the code enough to send out another patch set.

Things have gotten a bit hectic for me over the last few weeks (project
deadlines) so work has slowed somewhat.  

Based on feedback to the previous patch set I posted, I've been mostly
concerned with breaking the structure down considerably so as to end up
with a larger set of more focussed elements.

The current plan is to have a core module that handles registration etc
(and things like chrdev and sysfs allocations)  This is really just
a fairly slim management layer that all device drivers will utilize.
Then there is a generic ring buffer framework.  Ring buffers are either
separate modules implementing certain core functionality which can then
be used by a driver, or driver specific implementations (for example
for a hardware ring buffer on the actual sensor - e.g. VTI's
accelerometers).  Further modules (and this is the bit I haven't finished)
handle timers to allow varying degrees of control over when readings are
taken.  Currently the only implementation in here uses a periodic interrupt
capable rtc.  Whilst this works there aren't many drivers that support that
functionality and in any case there may not be a suitable rtc available.
Hence alternative timer functionality is needed.

Thus any given driver can use any of the above functionality. In a sense,
other than the core code, the majority of the modules are really about
sharing functionality across a range of similar drivers.

Current test drivers are max1363 and similar adc's, ST lis3l02dq (I think
that's very similar to the openmoko chip, but just happens to be what
I have) VTI SCA3000 accelerometers (way more complex accelerometer with
hardware ring buffering) and Analog ADIS16350 (imu with accels and gyros).

As a quick summary for those who haven't been following the previous
discussions, the drivers can provide any (some sysfs elements are obligatory)
or all of:

1) Sysfs control interfaces and direct reading from the device (or last
   ring buffer element if appropriate)
2) Chrdev event interface (things like motion detection etc as implemented
   in the hardware)
3) Chrdev ring buffer event interface.
4) Chrdev ring buffer access interface (this may be talking to in kernel
   ring buffer or directly to hardware).

Once things have firmed up a bit I'll get a git repository up so that
people can keep a closer track on what is going on.

Timescale wise, it isn't going to be ready for the next merge window, but
I would hope to get it into linux-next not long after that.  There are
some controversial elements that I may be able to separate out so we can
get something that is usable in the kernel and do the fancy stuff later!

If anyone wants a look I'm happy to send patches offlist.

Cheers

Re: [i2c] New style I2C driver for KXSD9 accelerometer

[Jonathan Cameron]

Jonathan Cameron wrote:
> Hi Ben,
>>>>
>>>>
>>>> I m implementing a driver for accelerometer KXSD9 in linux kernel 2.6.24.7
>>>> for OMAP-3430. KXSD9 sensor will be connected to the i2c bus so it will be
>>>> an i2c client.

Hi again Varun, 

I was wondering if you have made any progress with a driver for the KXSD9?

I now have an spi based driver for this under Industrial I/O which does the
basics. Obviously I'm not terribly keen in replicating work you have already
done!  At the moment it doesn't handle the motion detector interrupt but
that should be straight forward.

>From your previous emails I believe you were working on i2c support?

Whilst the differences look fairly trivial, I'll need to make up a suitable
cable to work on that option.

Thanks,

Jonathan