Hi Geert, thank you very much for your support. I have now my first I2C hardware connected, and it runs fine with your driver. I use your driver to control a PCA9532 16 bit I/O expander, which is dedicated to drive LEDs and has pulse-width modulation inside to control the brightness of the LEDs. So you can add the PCA9532 to your list of tested devices.
Because the PCA9532 has 9 registers, I use your new i2c_write function to write all registers in one transfer action. I think I understand now where my initial problems came from: When I tested the I2C driver without hardware, I alway got -1 as the return value of ioctl( fd_i2c, _IO( ETRAXI2C_IOCTYPE, I2C_WRITE ), &i2cdata_pca9532 ). Looking in your code this seems to correspond to EI2CBUSNFREE, but of course the bus was free all the time. Both SDA and SCL were terminated with a pull-up resistor. So I expected EI2CWADDRESS instead of EI2CBUSNFREE as the correct error message in case of a missing slave device. I tampered around with the code and manipulated the return values, but all I got was -1. This was the time were I thought my code changes would have no effect to the resulting fimage. As a last resort I used printk. I know this is not the best debugging style, but it worked. Your code produced a correct EI2CWADDRESS, but the return value of ioctl was -1 always. My impression is, that ioctl is not able to report your error codes from the kernel space to the user space. In the documentation I found in the Internet the only return values for ioctl are 0 and -1. Then I remembered, that you plan to write some High-Level drivers for your slave devices, and maybe you are calling the I2C driver from another module inside the kernel. In this case I would expect that the return values are visible from the calling kernel module. Is this assumption correct? Looking at your code I learnt a lot. Nevertheless there is something I do not understand. In i2c.c there is the following if-else clause: #ifdef CONFIG_ETRAX_I2C_USES_PB_NOT_PB_I2C In the if-clause there is a #define for reading SCL: #define i2c_scl_is_high() ( ( ( *R_PORT_PB_READ & ( 1 << SCLBIT ) ) ) >> SCLBIT ) In the else-clause there is no #define to read SCL. Maybe this can be a problem as soon as someone activates the kernel option CONFIG_ETRAX_I2C_USES_PB. In the near future I will add more slave devices to the bus and will report my test results to you. Planned are DS1302 and PCF8591. Again, thank you very much for your contribution of this driver. .................... Thomas Treyer Am 09.02.2007 um 19:24 schrieb Geert Vancompernolle: > --- In [email protected], Thomas Treyer <[EMAIL PROTECTED]> wrote: > > > > Hi Geert, > > > > in errno.h you defined all the different error values beginning with > > EI2CBUSNFREE 1 > > > > This confused me a little bit, because this overlaps with the error > > EINVAL, which is used by i2c_ioctl() also and has the value of 1 > > also. Maybe it would be better to shift the error numbers a little > > bit. What is your opinion? > > > Hi Thomas, > > First of all, and that's an important issue, the file is called > i2c_errno.h, not errno.h. > > If those constants would have been in the same header file, then I > would definitely agree with you. But since they're now in a separate > file and since they have an "unique" character (due to the addition of > a EI2C-prefix), I don't think that should be a problem. > > In fact, you're not supposed to know which value is assigned to > whatever #define, neither in errno.h, nor in i2c_errno.h (or in > another header file). You should only use the #defines. > > If you rely on the real value and tomorrow someone changes the value > of a #define for one good reason or another, then you're hanging. > > Therefore, I think it's perfectly legal to use the same value for > different #defines. If you do comparisons such as > > if ( EI2CRCVDATA == ioctl(....) ) > > then you should not face any problems. > > But that's my opinion. Anyone else the same or another meaning? > > Like I said in the very first message in this thread: all > suggestions/remarks are welcome. Yours is definitely one that can be > discussed about, but I think I will stick to the current situation for > reasons I gave above. > > Hope you agree with me? > > Best rgds, > > --Geert > > > [Non-text portions of this message have been removed]
