Advantech RSB-4210 Evaluation Kit Manual de usuario descargar pdf (Pagina 69)

61 RSB-4210 User Manual

Chapter 3 Software Functionality

3.11.2.2 Implementation details

For the interested, here's the code flow which happens inside the kernel when you

use the /dev interface to I2C:

1. Your program opens /dev/i2c-N and calls ioctl() on it, as described in section "C

example" above.

2. These open() and ioctl() calls are handled by the i2c-dev kernel driver: see i2c-

dev.c:i2cdev_open() and i2c-dev.c:i2cdev_ioctl(), respectively. You can think of

i2c-dev as a generic I2C chip driver that can be programmed from user-space.

3. Some ioctl() calls are for administrative tasks and are handled by i2c-dev

directly. Examples include I2C_SLAVE (set the address of the device you want

to access) and I2C_PEC (enable or disable SMBus error checking on future

transactions.)

4. Other ioctl() calls are converted to in-kernel function calls by i2c-dev. Examples

include I2C_FUNCS, which queries the I2C adapter functionality using

i2c.h:i2c_get_functionality(), and I2C_SMBUS, which performs an SMBus trans-

action using i2c-core.c:i2c_smbus_xfer().

The i2c-dev driver is responsible for checking all the parameters that come from

user-space for validity. After this point, there is no difference between these calls

that came from user-space through i2c-dev and calls that would have been per-

formed by kernel I2C chip drivers directly. This means that I2C bus drivers don't

need to implement anything special to support access from user-space.

5. These i2c-core.c/i2c.h functions are wrappers to the actual implementation of

your I2C bus driver. Each adapter must declare callback functions implementing

these standard calls. i2c.h:i2c_get_functionality() calls i2c_adapter.algo->func-

tionality(), while i2c-core.c:i2c_smbus_xfer() calls either adapter.algo-

>smbus_xfer() if it is implemented, or if not,

i2c-core.c:i2c_smbus_xfer_emulated() which in turn calls

i2c_adapter.algo->master_xfer().

After your I2C bus driver has processed these requests, execution runs up the call

chain, with almost no processing done, except by i2c-dev to package the returned

data, if any, in suitable format for the ioctl.

More detail please reference "source/linux-2.6.35.3/Documentation/i2c/dev-inter-

face"

3.11.3 UART

3.11.3.1 Driver Interface

open() Called when a device is opened. May sleep

close() Called when a device is closed. At the point of return from this

call the driver must make no further ldisc calls of any kind. May

sleep

write() Called to write bytes to the device. May notsleep. May occur in

parallel in special cases. Because this includes panic paths driv-

ers generally shouldn't try and do clever locking here.

put_char() Stuff a single character onto the queue. Thedriver is guaran-

teed following up calls to flush_chars.

flush_chars() Ask the kernel to write put_char queue

write_room() Return the number of characters tht can be stuffed into the port

buffers without overflow (or less).The ldisc is responsible for

being intelligent about multi-threading of write_room/write calls

ioctl() Called when an ioctl may be for the driver

1 2 ... 64 65 66 67 68 69 70 71 72 73 74 ... 103 104

Comentarios a estos manuales

Sin comentarios

Advantech RSB-4210 Evaluation Kit Manual de usuario Pagina 69

Comentarios a estos manuales

Relacionado con productos y manuales para Barebones Servidor Advantech RSB-4210 Evaluation Kit