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@xxxxxxxxxxxxxxxxx > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
