Enabling external i2C RTC

GoogleGroups
1

Hi guys,

Trying to get the PCF8583 working through the expansion header --
using the driver that Russell King originally wrote. i2c is ticking
along nicely, have enabled what appears to be the correct CONFIG
options in my defconfig (have enabled PCF8583 and disabled RTC on
twl4030)

I figure next step is to patch board-omap3beagle.c to add the RTC
device?

Or is there some cunning kernel boot command I can invoke to save the
trouble?

Right now with the PCF8583 built in through bitbake, I have no rtc
entries in /dev -- so clearly I need to enable the device, but my
question is where and what's the best approach?

Regards,

~Akram

2

Have managed to get things working with this RTC.

Am attaching small patch text to show what has been done as far as
code changes to board-omap3beagle.c
It was necessary to slow speed of 2nd bus from 400 down to 100kHz due
to clock specification. After that, very simple addition of i2c board
info structure and things are working great. Clock was not
initialised on first boot, but after issue a single hwclock -s
command, things are ticking over nicely!

regards,

~Akram

--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -213,13 +213,17 @@
     .platform_data = &beagle_twldata,
   },
};

3

Hi,

Thu, 16 Apr 2009, Akram wrote:

Have managed to get things working with this RTC.

Am attaching small patch text to show what has been done as far as
code changes to board-omap3beagle.c

Thank you for sharing this information. I was just about to add an RTC chip to my Beagle expansion board and this will definitely ease my work.

One thing still troubles me for which I haven't yet found an answer. I'm currently using I2C2 bus in userspace on Beagle with open(), read(), write() and some ioctl(). I have several devices attached to that bus. Now if I connect an RTC (DS1338C) to the same I2C bus and enable it, will some driver reserve that bus for itself or can I still use the same bus from userspace?

4

Hi,

Thu, 16 Apr 2009, Akram wrote:

> Have managed to get things working with this RTC.
> Am attaching small patch text to show what has been done as far as
> code changes to board-omap3beagle.c

I made the same change for the DS1338. The only difference is that I
didn't remove the twl4030 rtc. I did change the default device for
the rtc from /dev/rtc0 to /dev/rtc (as configured in Angstrom.) /dev/
rtc is a symbolic link, and I set it to point to the device node where
the DS1338 ended up, which in my case was /dev/rtc0.

I.e. I changed
RTC_HCTOSYS_DEVICE="rtc0"
to
RTC_HCTOSYS_DEVICE="rtc"

via make menuconfig

Thank you for sharing this information. I was just about to add an RTC chip to
my Beagle expansion board and this will definitely ease my work.

One thing still troubles me for which I haven't yet found an answer. I'm
currently usingI2C2bus in userspace on Beagle with open(), read(), write()
and some ioctl(). I have several devices attached to that bus. Now if I
connect an RTC (DS1338C) to the same I2C bus and enable it, will some driver
reserve that bus for itself or can I still use the same bus from userspace?

For the DS1338C, enable I2C2_OMAP_BEAGLE and RTC_DRV_DS1307 in your
kernel.
The code for the driver is in drivers/rtc/rtc-ds1307.c

And in Akram's patch replace this
I2C_BOARD_INFO("pcf8583", 0x51)
with
I2C_BOARD_INFO("ds1338",0x68)

When I get time, I will integrate my changes with Akram's and post a
combined patch.

I will note the DS1307/1338 driver does support the nvram on the part,
but I have not tried that out yet.

On your concern about using the bus from user space. I have not used
my own code to access I2C2, but I am using i2c_tools, and what I see
is that I am able to access I2C2, but I could no longer access the RTC
address (0x68) from user space once I integrated the DS1338 into the
kernel. I now get
  root@beagleboard:~# i2cdump -y -r 0-7 2 0x68 b
  Error: Could not set address to 0x68: Device or resource busy
  root@beagleboard:~# i2cdump -y -r 0-7 2 0x55 b
       0 1 2 3 4 5 6 7 8 9 a b c d e f
0123456789abcdef
  00: XX XX XX XX XX XX XX XX
XXXXXXXX

I do not have another device on the I2C2 bus, so accessing 0x55 times
out.

-Preston

5

Here is my change integrated with Akram's. I actually kept the I2C2
bus at 400kHz on my system, but here I left it at 100 as set in
Akram's patch. [Retrieving the time from the DS1338 takes just over
250us at 400kHz, so going to 100kHz will bump that out to about 1ms,
which is not a problem.] I also added some configuration ifdef's.

-Preston

--- orig/board-omap3beagle.c
+++ board-omap3beagle.c
@@ -214,12 +214,28 @@
        },
};

+#ifdef CONFIG_I2C2_OMAP_BEAGLE
+static struct i2c_board_info __initdata beagle_i2c2_boardinfo[] = {
+#ifdef CONFIG_RTC_DRV_PCF8583
+ {
+ I2C_BOARD_INFO("pcf8583", 0x51),
+ },
+#endif
+#ifdef CONFIG_RTC_DRV_DS1307
+ {
+ I2C_BOARD_INFO("ds1338", 0x68),
+ },
+#endif
+};
+#endif

6

Hi,

Fri, 17 Apr 2009, Preston Wilson wrote:

On your concern about using the bus from user space. I have not used
my own code to access I2C2, but I am using i2c_tools, and what I see
is that I am able to access I2C2, but I could no longer access the RTC
address (0x68) from user space once I integrated the DS1338 into the
kernel. I now get
root@beagleboard:~# i2cdump -y -r 0-7 2 0x68 b
Error: Could not set address to 0x68: Device or resource busy
root@beagleboard:~# i2cdump -y -r 0-7 2 0x55 b
      0 1 2 3 4 5 6 7 8 9 a b c d e f
0123456789abcdef
00: XX XX XX XX XX XX XX XX
XXXXXXXX

I do not have another device on the I2C2 bus, so accessing 0x55 times
out.

Great, this looks promising. Thank you for posting this info.