As promised, I would investigate this and come back to the issue. See below.
Best rgds, --Geert --- In [email protected], "Geert Vancompernolle" <[EMAIL PROTECTED]> wrote: > > On the other hand, during the communication of my user program with > > the normal I2C devices (e.g. PCF8591) the RST line is not active, and > > therefore the DS1302 should sleep peacefully during this time. > > > I have no experience yet with the DS1302 (but I anyhow have to look > into this myself), so I cannot tell a lot about the RST line itself. > I've studied both the DS1302 datasheets and driver and what I've learned is that this is no I2C device at all! The only "relation" between this device and the I2C driver, is the fact that the DS1302 driver is calling the function i2c_init() in the I2C driver because the pins used by the DS1302 and the I2C driver are, as already said before, the same and they have to be configured correctly for both the DS1302 and the I2C driver. There's a static variable in the I2C driver, called "first", which is initialised to "1". Whenever there's a call to i2c_init() (be it an internal or external call), the variable will be set to "0" and the pin configuration will be done. The configuration will depend on some kernel configuration settings, as can be seen when looking at the I2C driver. Next time there's a call to i2c_init(), the variable "first" will now have a value of "0", so the function will return immediately because of the "if" condition and will simulate a correct initialisation by returning the value "0". In fact, the DS1302 is based on the bi-phase protocol, which only looks at the data during the rising edge of the clock pulse. The I2C protocol, on the other hand, must keep the data steady (high or low) during the whole clock pulse (and even a bit before and after). So, a complete different approach between the two protocols!!! Next to this, you will see that the DS1302 driver has its own start() and stop() function. That was misleading me a lot, since I only gave it a blink of an eye and I thought this was the start and stop of an I2C protocol... Wrong... The start() and stop() functions for the DS1302 are there to play with the CE line of the device (called RST in the driver) and the clock line... This is to indicate a write allowed/prohibited situation... > > Another aspect can be a race condition, where the kernel tries to > > access the I2C bus the same time my user program communicates with > > another device at the bus. Is this a real risk or is this avoided by > > any method in the I2C driver? > > As said before, I didn't experiment myself yet with a combination of > the two, being the DS1307 and all the other I2C devices. Maybe > someone else has? Now that I know the above, I think it's realistic that the pins used for both I2C and DS1302 can be accessed at the same time. This could be avoided by using a semaphore which "protects" the lines PB0 and PB1 from being changed by another call/process, while there's currently someone working on those pins. Only, I don't know where the best place is to do that. I still have to figure this out... > > > Does the kernel use the I2C driver for the DS1302 communication or > > has the kernel an independent driver for the RTC? > > There is indeed a separate driver for the DS1302. You can find this > one in the directory > ./devboard-R2_01/os/linux/arch/cris/arch/drivers/ds1302.c. > When looking into that driver, you will see that this one is > completely stand-alone. As said before, the DS1302 driver is NOT an I2C driver!!! Be careful about that... > > What happens if my user space program opens /dev/i2c and keeps it > > open indefinitely? Will this be a blocking point for the kernel to > > access the RTC? > > Shouldn't be, but I have to figure it out for myself too. I might be > doing this this weekend... Keeping a device open doesn't hamper you from manipulating the pins that are used in the I2C driver by another driver. So, if your I2C device is open, then the kernel can still access the pins PB0 and PB1. Just be careful about the possible race conditions! Best rgds, --Geert
