Writing I2C chip driver in combination with other structure

[anish kumar]

On Fri, 2012-07-20 at 16:24 +0530, aurum spark wrote:
> Hi All,
> 
> I have written and seen lot of code of i2c drivers for input subsystem
> devices and much familiar with that. Now I have started writing driver
> for one chip that is not exactly type of input device. So, little bit
> confused about how should be the driver architecture so that it will
> be a clean code yet simple.  Following text and diagram explains short
> functional description of chip.
> 
> 
> Chip Interface :-
> ==========
> 
> 
>         ======                   =======
>         |             |                    |   I2C         |
>         |             | ----- I2C ---  |  Device    |
>         |    ARM  | ----- Bus --  |  With rw    | ------------ Input Connect
>         |             |                    |   regs       |
>         |             | ---------------|                 |
>         ======     INTR       =======
> 
> So above picture depicts how chip is interfaced to ARM CPU. This chip
> has some registers which are rw and can be used to read certain
> information from chip or to program it. This chip is capable of giving
> intterupt to CPU. This chip has one input which it like some cable
> connection. It detects when this cable is connected and raises the
> interrupt.
> 
> Functionality Expected in Driver:-
> ===================
> 
> 1. Driver should communicate with chip over I2C.
> 2. Driver should report event to user space upon receiving interrupt
> from I2C device.
> 3. Driver should be capable of programming I2C chip @ the time of
> initialization as well should be capable of changing registers as and
> when Linux User Space application wants to.
> 
> What I have thought of:-
> ==============
> 
> #1 definitely makes this as i2c client driver(chip driver)
> 
> #2 Here I have few options
> 
>  a) Shall I use input subsystem mechanism to report interrupt as an
> event to user space ? In this case it's combination of I2C + input
> subsystem. Then application can read something over i2c and decide
> next flow,
> 
>                                      OR
> 
>  b) Shall I use some sysfs based interface on which application can do
> select sys call and can receive event ? for this nothing extra
> required.
> 
> #3 Since approach in #2 is not fixed here also there are multiple options
> a) This  can be written as I2C client + char driver so that it can
> have ioctls to send commands to i2c chip based on applications demand.
What does this chip do and why does it need to do I2C transaction based
on application demand?
> b) We can provide sysfs interface to user space to send commands to
> i2c device as and when required at runtime.
> 
> 
> As per my thoughts I am not sure shall I make this as input device
> just to report one event upon getting interrupt from device. Also will
> it be ok to have this as char driver in combination with i2c chip
> driver ?
> Please guide me and take me to correct source or documentation or to
> source code of some driver for this kind of device. Does i2c support
> ops like fbops ?
> 
> 
> Regards,
>  ~/Aurum
> 
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies