Writing I2C chip driver in combination with other structure
anish198519851985 at gmail.com
Tue Sep 4 11:39:45 EDT 2012
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
> 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,
> b) Shall I use some sysfs based interface on which application can do
> select sys call and can receive event ? for this nothing extra
> #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 ?
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
More information about the Kernelnewbies