Patchwork RTC driver(Linux) for PT7C4338 chip.

login
register
mail settings
Submitter Priyanka Jain
Date March 3, 2011, 3:51 a.m.
Message ID <1299124299-26991-1-git-send-email-Priyanka.Jain@freescale.com>
Download mbox | patch
Permalink /patch/85222/
State New
Headers show

Comments

Priyanka Jain - March 3, 2011, 3:51 a.m.
PT7C4338 chip is being manufactured by Pericom Technology Inc.
It is a serial real-time clock which provides:
1)Low-power clock/calendar.
2)Programmable square-wave output.
It has 56 bytes of nonvolatile RAM.

Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
---
 PT7C4338 RTC driver is verified on Freescale P1010RDB. 
 Please pick this patch for 2.6.39

 drivers/rtc/Kconfig        |    9 ++
 drivers/rtc/Makefile       |    1 +
 drivers/rtc/rtc-pt7c4338.c |  215 ++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 225 insertions(+), 0 deletions(-)
 create mode 100644 drivers/rtc/rtc-pt7c4338.c
Wolfram Sang - March 3, 2011, 9:22 a.m.
Hi,

> +/*
> + * This file provides Date & Time support (no alarms) for PT7C4338 chip.
> + *
> + * This file is based on drivers/rtc/rtc-ds1307.c

Please explain why you can't use rtc-ds1307 directly (or with slight
modifications). I might have missed something but the register-set looks
identical to me?

Regards,

   Wolfram
Andrew Morton - March 9, 2011, 12:55 a.m.
On Thu, 3 Mar 2011 10:22:39 +0100
Wolfram Sang <w.sang@pengutronix.de> wrote:

> Hi,
> 
> > +/*
> > + * This file provides Date & Time support (no alarms) for PT7C4338 chip.
> > + *
> > + * This file is based on drivers/rtc/rtc-ds1307.c
> 
> Please explain why you can't use rtc-ds1307 directly (or with slight
> modifications). I might have missed something but the register-set looks
> identical to me?
> 

Was there an answer to this question?

Thanks.
Wolfram Sang - March 9, 2011, 6:46 a.m.
On Tue, Mar 08, 2011 at 04:55:31PM -0800, Andrew Morton wrote:
> On Thu, 3 Mar 2011 10:22:39 +0100
> Wolfram Sang <w.sang@pengutronix.de> wrote:
> 
> > Hi,
> > 
> > > +/*
> > > + * This file provides Date & Time support (no alarms) for PT7C4338 chip.
> > > + *
> > > + * This file is based on drivers/rtc/rtc-ds1307.c
> > 
> > Please explain why you can't use rtc-ds1307 directly (or with slight
> > modifications). I might have missed something but the register-set looks
> > identical to me?
> > 
> 
> Was there an answer to this question?

I didn't get one.
Jain Priyanka-B32167 - March 10, 2011, 3:23 a.m.
Dear Wolfram,

Though register-set looks identical but features were different. And also manufacturer is different.
But still it might be possible that we can reuse ds1307.c with some modification.
But if I look at the drivers present in drivers/rtc folder. Most of them looks similar but still there are different drivers for different chips.

Please suggest which way is more preferred: modifying existing drivers(of different manufacturer) or writing new driver. 

Thanks
Priyanka

> -----Original Message-----
> From: Wolfram Sang [mailto:w.sang@pengutronix.de]
> Sent: Thursday, March 03, 2011 2:53 PM
> To: rtc-linux@googlegroups.com
> Cc: linuxppc-dev@lists.ozlabs.org; a.zummo@towertech.it;
> p_gortmaker@yahoo.com; akpm@linux-foundation.org; Jain Priyanka-B32167
> Subject: Re: [rtc-linux] [PATCH] RTC driver(Linux) for PT7C4338 chip.
> 
> Hi,
> 
> > +/*
> > + * This file provides Date & Time support (no alarms) for PT7C4338
> chip.
> > + *
> > + * This file is based on drivers/rtc/rtc-ds1307.c
> 
> Please explain why you can't use rtc-ds1307 directly (or with slight
> modifications). I might have missed something but the register-set looks
> identical to me?
> 
> Regards,
> 
>    Wolfram
> 
> --
> Pengutronix e.K.                           | Wolfram Sang
> |
> Industrial Linux Solutions                 | http://www.pengutronix.de/
> |
Wolfram Sang - March 10, 2011, 8:54 a.m.
Hi Priyanka,

> Though register-set looks identical but features were different.

Can you tell what exactly is different?

> And also manufacturer is different.

That does not matter. If you look at ds_type, there are already
different manufacturers. They will be correctly distinguished by
i2c_device_id. The name of the driver itself is, well, just a name.

> But still it might be possible that we can reuse ds1307.c with some
> modification.

I agree. The driver already supports some variants. Adding one more
should not hurt. See 97f902b7be4dd6ba03c6aa8d3400783ed687ebd1 for an
example which added ds3231 support.

> But if I look at the drivers present in drivers/rtc folder. Most of
> them looks similar but still there are different drivers for different
> chips.

Yes, it probably could be cleaned up if somebody had the time/hardware.

> Please suggest which way is more preferred: modifying existing
> drivers(of different manufacturer) or writing new driver. 

Ususally avoiding code duplication is good, it reduces maintenance
burden. However, if adding the support turns out to make the original
code unreadable or hard to follow, a new driver might be justified. This
is why it is important to understand the differences of the chip as a
first step. (I have the feeling, that modifying is the way to go here,
though).

Regards,

   Wolfram
Jain Priyanka-B32167 - March 10, 2011, 11:06 a.m.
Hi Wolfram, 


> -----Original Message-----
> From: Wolfram Sang [mailto:w.sang@pengutronix.de]
> Sent: Thursday, March 10, 2011 2:24 PM
> To: Jain Priyanka-B32167
> Cc: rtc-linux@googlegroups.com; linuxppc-dev@lists.ozlabs.org;
> a.zummo@towertech.it; p_gortmaker@yahoo.com; akpm@linux-foundation.org
> Subject: Re: [rtc-linux] [PATCH] RTC driver(Linux) for PT7C4338 chip.
> 
> Hi Priyanka,
> 
> > Though register-set looks identical but features were different.
> 
> Can you tell what exactly is different?
I will check both the devices data sheets again in detail and will get back on this.
> 
> > And also manufacturer is different.
> 
> That does not matter. If you look at ds_type, there are already different
> manufacturers. They will be correctly distinguished by i2c_device_id. The
> name of the driver itself is, well, just a name.
> 
> > But still it might be possible that we can reuse ds1307.c with some
> > modification.
> 
> I agree. The driver already supports some variants. Adding one more
> should not hurt. See 97f902b7be4dd6ba03c6aa8d3400783ed687ebd1 for an
> example which added ds3231 support.
> 
> > But if I look at the drivers present in drivers/rtc folder. Most of
> > them looks similar but still there are different drivers for different
> > chips.
> 
> Yes, it probably could be cleaned up if somebody had the time/hardware.
> 
> > Please suggest which way is more preferred: modifying existing
> > drivers(of different manufacturer) or writing new driver.
> 
> Ususally avoiding code duplication is good, it reduces maintenance
> burden. However, if adding the support turns out to make the original
> code unreadable or hard to follow, a new driver might be justified. This
> is why it is important to understand the differences of the chip as a
> first step. (I have the feeling, that modifying is the way to go here,
> though).
> 

I will explore possibility of using ds1307 driver for this.


Thanks
Priyanka
Andrew Morton - May 25, 2011, 11:56 p.m.
On Thu, 10 Mar 2011 11:06:27 +0000
Jain Priyanka-B32167 <B32167@freescale.com> wrote:

> Hi Wolfram, 
> 
> 
> > -----Original Message-----
> > From: Wolfram Sang [mailto:w.sang@pengutronix.de]
> > Sent: Thursday, March 10, 2011 2:24 PM
> > To: Jain Priyanka-B32167
> > Cc: rtc-linux@googlegroups.com; linuxppc-dev@lists.ozlabs.org;
> > a.zummo@towertech.it; p_gortmaker@yahoo.com; akpm@linux-foundation.org
> > Subject: Re: [rtc-linux] [PATCH] RTC driver(Linux) for PT7C4338 chip.
> > 
> > Hi Priyanka,
> > 
> > > Though register-set looks identical but features were different.
> > 
> > Can you tell what exactly is different?
> I will check both the devices data sheets again in detail and will get back on this.
> > 
> > > And also manufacturer is different.
> > 
> > That does not matter. If you look at ds_type, there are already different
> > manufacturers. They will be correctly distinguished by i2c_device_id. The
> > name of the driver itself is, well, just a name.
> > 
> > > But still it might be possible that we can reuse ds1307.c with some
> > > modification.
> > 
> > I agree. The driver already supports some variants. Adding one more
> > should not hurt. See 97f902b7be4dd6ba03c6aa8d3400783ed687ebd1 for an
> > example which added ds3231 support.
> > 
> > > But if I look at the drivers present in drivers/rtc folder. Most of
> > > them looks similar but still there are different drivers for different
> > > chips.
> > 
> > Yes, it probably could be cleaned up if somebody had the time/hardware.
> > 
> > > Please suggest which way is more preferred: modifying existing
> > > drivers(of different manufacturer) or writing new driver.
> > 
> > Ususally avoiding code duplication is good, it reduces maintenance
> > burden. However, if adding the support turns out to make the original
> > code unreadable or hard to follow, a new driver might be justified. This
> > is why it is important to understand the differences of the chip as a
> > first step. (I have the feeling, that modifying is the way to go here,
> > though).
> > 
> 
> I will explore possibility of using ds1307 driver for this.
> 

Has there been any movement here?
Jain Priyanka-B32167 - May 26, 2011, 7:11 a.m.
Hi Andrew Morton,

I have added the support for pt7c4338 in Dallas driver rtc-ds1307.c as suggested by Wolfram Sang
And send the patch "Add support for pt7c4338 (rtc device) in rtc-ds1307 driver" for the same which will supersede the previous patch.

Please let me know if anything else is required.

Thanks
Priyanka


> -----Original Message-----
> From: Andrew Morton [mailto:akpm@linux-foundation.org]
> Sent: Thursday, May 26, 2011 5:26 AM
> To: Jain Priyanka-B32167
> Cc: Wolfram Sang; rtc-linux@googlegroups.com; linuxppc-
> dev@lists.ozlabs.org; a.zummo@towertech.it; p_gortmaker@yahoo.com
> Subject: Re: [rtc-linux] [PATCH] RTC driver(Linux) for PT7C4338 chip.
> 
> On Thu, 10 Mar 2011 11:06:27 +0000
> Jain Priyanka-B32167 <B32167@freescale.com> wrote:
> 
> > Hi Wolfram,
> >
> >
> > > -----Original Message-----
> > > From: Wolfram Sang [mailto:w.sang@pengutronix.de]
> > > Sent: Thursday, March 10, 2011 2:24 PM
> > > To: Jain Priyanka-B32167
> > > Cc: rtc-linux@googlegroups.com; linuxppc-dev@lists.ozlabs.org;
> > > a.zummo@towertech.it; p_gortmaker@yahoo.com;
> > > akpm@linux-foundation.org
> > > Subject: Re: [rtc-linux] [PATCH] RTC driver(Linux) for PT7C4338 chip.
> > >
> > > Hi Priyanka,
> > >
> > > > Though register-set looks identical but features were different.
> > >
> > > Can you tell what exactly is different?
> > I will check both the devices data sheets again in detail and will get
> back on this.
> > >
> > > > And also manufacturer is different.
> > >
> > > That does not matter. If you look at ds_type, there are already
> > > different manufacturers. They will be correctly distinguished by
> > > i2c_device_id. The name of the driver itself is, well, just a name.
> > >
> > > > But still it might be possible that we can reuse ds1307.c with
> > > > some modification.
> > >
> > > I agree. The driver already supports some variants. Adding one more
> > > should not hurt. See 97f902b7be4dd6ba03c6aa8d3400783ed687ebd1 for an
> > > example which added ds3231 support.
> > >
> > > > But if I look at the drivers present in drivers/rtc folder. Most
> > > > of them looks similar but still there are different drivers for
> > > > different chips.
> > >
> > > Yes, it probably could be cleaned up if somebody had the
> time/hardware.
> > >
> > > > Please suggest which way is more preferred: modifying existing
> > > > drivers(of different manufacturer) or writing new driver.
> > >
> > > Ususally avoiding code duplication is good, it reduces maintenance
> > > burden. However, if adding the support turns out to make the
> > > original code unreadable or hard to follow, a new driver might be
> > > justified. This is why it is important to understand the differences
> > > of the chip as a first step. (I have the feeling, that modifying is
> > > the way to go here, though).
> > >
> >
> > I will explore possibility of using ds1307 driver for this.
> >
> 
> Has there been any movement here?

Patch

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 10ba12c..6ff0901 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -324,6 +324,15 @@  config RTC_DRV_RX8025
 	  This driver can also be built as a module. If so, the module
 	  will be called rtc-rx8025.
 
+config RTC_DRV_PT7C4338
+	tristate "Pericom Technology Inc. PT7C4338 RTC"
+	help
+	  If you say yes here you get support for the Pericom Technology
+	  Inc. PT7C4338 RTC chip.
+
+	  This driver can also be built as a module. If so, the module
+	  will be called rtc-pt7c4338.
+
 endif # I2C
 
 comment "SPI RTC drivers"
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 5adbba7..4014607 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -70,6 +70,7 @@  obj-$(CONFIG_RTC_DRV_PCF50633)	+= rtc-pcf50633.o
 obj-$(CONFIG_RTC_DRV_PL030)	+= rtc-pl030.o
 obj-$(CONFIG_RTC_DRV_PL031)	+= rtc-pl031.o
 obj-$(CONFIG_RTC_DRV_PS3)	+= rtc-ps3.o
+obj-$(CONFIG_RTC_DRV_PT7C4338)	+= rtc-pt7c4338.o
 obj-$(CONFIG_RTC_DRV_PXA)	+= rtc-pxa.o
 obj-$(CONFIG_RTC_DRV_R9701)	+= rtc-r9701.o
 obj-$(CONFIG_RTC_DRV_RP5C01)	+= rtc-rp5c01.o
diff --git a/drivers/rtc/rtc-pt7c4338.c b/drivers/rtc/rtc-pt7c4338.c
new file mode 100644
index 0000000..fca52cd
--- /dev/null
+++ b/drivers/rtc/rtc-pt7c4338.c
@@ -0,0 +1,215 @@ 
+/*
+ * Copyright 2010 Freescale Semiconductor, Inc.
+ *
+ * Author:	Priyanka Jain <Priyanka.Jain@freescale.com>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+/*
+ * This file provides Date & Time support (no alarms) for PT7C4338 chip.
+ *
+ * This file is based on drivers/rtc/rtc-ds1307.c
+ *
+ * PT7C4338 chip is manufactured by Pericom Technology Inc.
+ * It is a serial real-time clock which provides
+ * 1)Low-power clock/calendar.
+ * 2)Programmable square-wave output.
+ * It has 56 bytes of nonvolatile RAM.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/i2c.h>
+#include <linux/rtc.h>
+#include <linux/bcd.h>
+
+/* RTC register addresses */
+#define PT7C4338_REG_SECONDS          0x00
+#define PT7C4338_REG_MINUTES          0x01
+#define PT7C4338_REG_HOURS            0x02
+#define PT7C4338_REG_AMPM             0x02
+#define PT7C4338_REG_DAY              0x03
+#define PT7C4338_REG_DATE             0x04
+#define PT7C4338_REG_MONTH            0x05
+#define PT7C4338_REG_YEAR             0x06
+#define PT7C4338_REG_CTRL_STAT        0x07
+
+/* RTC second register address bit */
+#define PT7C4338_SEC_BIT_CH           0x80	/*Clock Halt (in Register 0)*/
+
+/* RTC control and status register bits */
+#define PT7C4338_CTRL_STAT_BIT_RS0    0x1	/*Rate select 0*/
+#define PT7C4338_CTRL_STAT_BIT_RS1    0x2	/*Rate select 1*/
+#define PT7C4338_CTRL_STAT_BIT_SQWE   0x10	/*Square Wave Enable*/
+#define PT7C4338_CTRL_STAT_BIT_OSF    0x20	/*Oscillator Stop Flag*/
+#define PT7C4338_CTRL_STAT_BIT_OUT    0x80	/*Output Level Control*/
+
+static const struct i2c_device_id pt7c4338_id[] = {
+	{ "pt7c4338", 0 },
+	{ }
+};
+MODULE_DEVICE_TABLE(i2c, pt7c4338_id);
+
+struct pt7c4338{
+	struct i2c_client *client;
+	struct rtc_device *rtc;
+};
+
+static int pt7c4338_read_time(struct device *dev, struct rtc_time *time)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	int ret;
+	u8 buf[7];
+	u8 year, month, day, hour, minute, second;
+	u8 week, twelve_hr, am_pm;
+
+	ret = i2c_smbus_read_i2c_block_data(client,
+			PT7C4338_REG_SECONDS, 7, buf);
+	if (ret < 0)
+		return ret;
+	if (ret < 7)
+		return -EIO;
+
+	second = buf[0];
+	minute = buf[1];
+	hour = buf[2];
+	week = buf[3];
+	day = buf[4];
+	month = buf[5];
+	year = buf[6];
+
+	/* Extract additional information for AM/PM */
+	twelve_hr = hour & 0x40;
+	am_pm = hour & 0x20;
+
+	/* Write to rtc_time structure */
+	time->tm_sec = bcd2bin(second & 0x7f);
+	time->tm_min = bcd2bin(minute & 0x7f);
+	if (twelve_hr) {
+		/* Convert to 24 hr */
+		if (am_pm)
+			time->tm_hour = bcd2bin(hour & 0x10) + 12;
+		else
+			time->tm_hour = bcd2bin(hour & 0xBF);
+	} else {
+		time->tm_hour = bcd2bin(hour);
+	}
+
+	time->tm_wday = bcd2bin(week & 0x07) - 1;
+	time->tm_mday = bcd2bin(day & 0x3f);
+	time->tm_mon = bcd2bin(month & 0x1F) - 1;
+	/* assume 20YY not 19YY */
+	time->tm_year = bcd2bin(year) + 100;
+
+	return 0;
+}
+
+static int pt7c4338_set_time(struct device *dev, struct rtc_time *time)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	u8 buf[7];
+
+	/* Extract time from rtc_time and load into pt7c4338*/
+	buf[0] = bin2bcd(time->tm_sec);
+	buf[1] = bin2bcd(time->tm_min);
+	buf[2] = bin2bcd(time->tm_hour);
+	buf[3] = bin2bcd(time->tm_wday + 1); /* Day of the week */
+	buf[4] = bin2bcd(time->tm_mday); /* Date */
+	buf[5] = bin2bcd(time->tm_mon + 1);
+
+	/* assume 20YY not 19YY */
+	if (time->tm_year >= 100)
+		buf[6] = bin2bcd(time->tm_year - 100);
+	else
+		buf[6] = bin2bcd(time->tm_year);
+
+	return i2c_smbus_write_i2c_block_data(client,
+					PT7C4338_REG_SECONDS, 7, buf);
+}
+
+static const struct rtc_class_ops pt7c4338_rtc_ops = {
+	.read_time = pt7c4338_read_time,
+	.set_time = pt7c4338_set_time,
+};
+
+static int pt7c4338_probe(struct i2c_client *client,
+		const struct i2c_device_id *id)
+{
+	struct pt7c4338 *pt7c4338;
+	struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
+	int ret;
+
+	pt7c4338 = kzalloc(sizeof(struct pt7c4338), GFP_KERNEL);
+	if (!pt7c4338)
+		return -ENOMEM;
+
+	pt7c4338->client = client;
+	i2c_set_clientdata(client, pt7c4338);
+	pt7c4338->rtc = rtc_device_register(client->name, &client->dev,
+					&pt7c4338_rtc_ops, THIS_MODULE);
+	if (IS_ERR(pt7c4338->rtc)) {
+		ret = PTR_ERR(pt7c4338->rtc);
+		dev_err(&client->dev, "unable to register the class device\n");
+		goto out_free;
+	}
+
+	return 0;
+out_free:
+	i2c_set_clientdata(client, NULL);
+	kfree(pt7c4338);
+	return ret;
+}
+
+static int __devexit pt7c4338_remove(struct i2c_client *client)
+{
+	struct pt7c4338 *pt7c4338 = i2c_get_clientdata(client);
+
+	rtc_device_unregister(pt7c4338->rtc);
+	i2c_set_clientdata(client, NULL);
+	kfree(pt7c4338);
+	return 0;
+}
+
+static struct i2c_driver pt7c4338_driver = {
+	.driver = {
+		.name = "rtc-pt7c4338",
+		.owner = THIS_MODULE,
+	},
+	.probe = pt7c4338_probe,
+	.remove = __devexit_p(pt7c4338_remove),
+	.id_table = pt7c4338_id,
+};
+
+static int __init pt7c4338_init(void)
+{
+	return i2c_add_driver(&pt7c4338_driver);
+}
+
+static void __exit pt7c4338_exit(void)
+{
+	i2c_del_driver(&pt7c4338_driver);
+}
+
+module_init(pt7c4338_init);
+module_exit(pt7c4338_exit);
+
+MODULE_AUTHOR("Priyanka Jain <Priyanka.Jain@freescale.com>");
+MODULE_DESCRIPTION("pericom Technology Inc. PT7C4338 RTC Driver");
+MODULE_LICENSE("GPL");