[rtc-linux] [PATCH 0/4] support control with using GPIO lines

[rtc-linux] [PATCH 0/4] support control with using GPIO lines

[Akinobu Mita]

This series adds support access to DS1302 with GPIO lines.

Recently rtc-ds1302 is rewritten using SPI 3wire mode.  This adds
another platform driver using GPIO while supporting both modes.

Thie series first fixes two problems I found while tesing, secondly
introduces the abstraction layer for the register access which enables
to share the most code between spi and platform driver, and adds
the platform driver using GPIO.

Akinobu Mita (4):
  rtc: ds1302: fix error check in set_time
  rtc: ds1302: fix write value for day of week register
  rtc: ds1302: add register access abstraction layer
  rtc: ds1302: support control with using GPIO lines

 .../devicetree/bindings/rtc/maxim-ds1302.txt       |  13 +
 drivers/rtc/Kconfig                                |  17 +-
 drivers/rtc/rtc-ds1302.c                           | 558 ++++++++++++++++++---
 3 files changed, 503 insertions(+), 85 deletions(-)

Cc: Sergey Yanovich <ynvich@gmail.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-- 
2.5.0

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[PATCH 0/4] support control with using GPIO lines

[Akinobu Mita]

This series adds support access to DS1302 with GPIO lines.

Recently rtc-ds1302 is rewritten using SPI 3wire mode.  This adds
another platform driver using GPIO while supporting both modes.

Thie series first fixes two problems I found while tesing, secondly
introduces the abstraction layer for the register access which enables
to share the most code between spi and platform driver, and adds
the platform driver using GPIO.

Akinobu Mita (4):
  rtc: ds1302: fix error check in set_time
  rtc: ds1302: fix write value for day of week register
  rtc: ds1302: add register access abstraction layer
  rtc: ds1302: support control with using GPIO lines

 .../devicetree/bindings/rtc/maxim-ds1302.txt       |  13 +
 drivers/rtc/Kconfig                                |  17 +-
 drivers/rtc/rtc-ds1302.c                           | 558 ++++++++++++++++++---
 3 files changed, 503 insertions(+), 85 deletions(-)

Cc: Sergey Yanovich <ynvich-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Alessandro Zummo <a.zummo-BfzFCNDTiLLj+vYz1yj4TQ@public.gmane.org>
Cc: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[rtc-linux] [PATCH 1/4] rtc: ds1302: fix error check in set_time

[Akinobu Mita]

The set_time callback for rtc-ds1302 doesn't write clock registers
because the error check for the return value from spi_write_then_read()
is not correct.  spi_write_then_read() which returns zero on success.

Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Sergey Yanovich <ynvich@gmail.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
 drivers/rtc/rtc-ds1302.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-ds1302.c b/drivers/rtc/rtc-ds1302.c
index 5cdc0f2..5e05653 100644
--- a/drivers/rtc/rtc-ds1302.c
+++ b/drivers/rtc/rtc-ds1302.c
@@ -54,7 +54,7 @@ static int ds1302_rtc_set_time(struct device *dev, struct rtc_time *time)
 
 	status = spi_write_then_read(spi, buf, 2,
 			NULL, 0);
-	if (!status)
+	if (status)
 		return status;
 
 	/* Write registers starting at the first time/date address. */
-- 
2.5.0

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[PATCH 1/4] rtc: ds1302: fix error check in set_time

[Akinobu Mita]

The set_time callback for rtc-ds1302 doesn't write clock registers
because the error check for the return value from spi_write_then_read()
is not correct.  spi_write_then_read() which returns zero on success.

Signed-off-by: Akinobu Mita <akinobu.mita-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Sergey Yanovich <ynvich-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Alessandro Zummo <a.zummo-BfzFCNDTiLLj+vYz1yj4TQ@public.gmane.org>
Cc: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
 drivers/rtc/rtc-ds1302.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-ds1302.c b/drivers/rtc/rtc-ds1302.c
index 5cdc0f2..5e05653 100644
--- a/drivers/rtc/rtc-ds1302.c
+++ b/drivers/rtc/rtc-ds1302.c
@@ -54,7 +54,7 @@ static int ds1302_rtc_set_time(struct device *dev, struct rtc_time *time)
 
 	status = spi_write_then_read(spi, buf, 2,
 			NULL, 0);
-	if (!status)
+	if (status)
 		return status;
 
 	/* Write registers starting at the first time/date address. */
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[rtc-linux] Re: [PATCH 1/4] rtc: ds1302: fix error check in set_time

[Alexandre Belloni]

On 10/04/2016 at 23:59:23 +0900, Akinobu Mita wrote :
> The set_time callback for rtc-ds1302 doesn't write clock registers
> because the error check for the return value from spi_write_then_read()
> is not correct.  spi_write_then_read() which returns zero on success.
> 
> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
> Cc: Sergey Yanovich <ynvich@gmail.com>
> Cc: Alessandro Zummo <a.zummo@towertech.it>
> Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> ---
>  drivers/rtc/rtc-ds1302.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
Applied, thanks.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 1/4] rtc: ds1302: fix error check in set_time

[Alexandre Belloni]

On 10/04/2016 at 23:59:23 +0900, Akinobu Mita wrote :
> The set_time callback for rtc-ds1302 doesn't write clock registers
> because the error check for the return value from spi_write_then_read()
> is not correct.  spi_write_then_read() which returns zero on success.
> 
> Signed-off-by: Akinobu Mita <akinobu.mita-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Sergey Yanovich <ynvich-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Alessandro Zummo <a.zummo-BfzFCNDTiLLj+vYz1yj4TQ@public.gmane.org>
> Cc: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
>  drivers/rtc/rtc-ds1302.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
Applied, thanks.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[rtc-linux] [PATCH 2/4] rtc: ds1302: fix write value for day of week register

[Akinobu Mita]

The valid range of day of week register for DS1302 is 1 to 7.  But the
set_time callback for rtc-ds1302 attempts to write the value of
tm->tm_wday which is in the range 0 to 6.  While the get_time callback
correctly decodes the register.

Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Sergey Yanovich <ynvich@gmail.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
 drivers/rtc/rtc-ds1302.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-ds1302.c b/drivers/rtc/rtc-ds1302.c
index 5e05653..454248f 100644
--- a/drivers/rtc/rtc-ds1302.c
+++ b/drivers/rtc/rtc-ds1302.c
@@ -66,7 +66,7 @@ static int ds1302_rtc_set_time(struct device *dev, struct rtc_time *time)
 	*bp++ = bin2bcd(time->tm_hour);
 	*bp++ = bin2bcd(time->tm_mday);
 	*bp++ = bin2bcd(time->tm_mon + 1);
-	*bp++ = time->tm_wday;
+	*bp++ = time->tm_wday + 1;
 	*bp++ = bin2bcd(time->tm_year % 100);
 	*bp++ = RTC_CMD_WRITE_DISABLE;
 
-- 
2.5.0

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[PATCH 2/4] rtc: ds1302: fix write value for day of week register

[Akinobu Mita]

The valid range of day of week register for DS1302 is 1 to 7.  But the
set_time callback for rtc-ds1302 attempts to write the value of
tm->tm_wday which is in the range 0 to 6.  While the get_time callback
correctly decodes the register.

Signed-off-by: Akinobu Mita <akinobu.mita-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Sergey Yanovich <ynvich-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Alessandro Zummo <a.zummo-BfzFCNDTiLLj+vYz1yj4TQ@public.gmane.org>
Cc: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
 drivers/rtc/rtc-ds1302.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-ds1302.c b/drivers/rtc/rtc-ds1302.c
index 5e05653..454248f 100644
--- a/drivers/rtc/rtc-ds1302.c
+++ b/drivers/rtc/rtc-ds1302.c
@@ -66,7 +66,7 @@ static int ds1302_rtc_set_time(struct device *dev, struct rtc_time *time)
 	*bp++ = bin2bcd(time->tm_hour);
 	*bp++ = bin2bcd(time->tm_mday);
 	*bp++ = bin2bcd(time->tm_mon + 1);
-	*bp++ = time->tm_wday;
+	*bp++ = time->tm_wday + 1;
 	*bp++ = bin2bcd(time->tm_year % 100);
 	*bp++ = RTC_CMD_WRITE_DISABLE;
 
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[rtc-linux] Re: [PATCH 2/4] rtc: ds1302: fix write value for day of week register

[Alexandre Belloni]

On 10/04/2016 at 23:59:24 +0900, Akinobu Mita wrote :
> The valid range of day of week register for DS1302 is 1 to 7.  But the
> set_time callback for rtc-ds1302 attempts to write the value of
> tm->tm_wday which is in the range 0 to 6.  While the get_time callback
> correctly decodes the register.
> 
> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
> Cc: Sergey Yanovich <ynvich@gmail.com>
> Cc: Alessandro Zummo <a.zummo@towertech.it>
> Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> ---
>  drivers/rtc/rtc-ds1302.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
Applied, thanks.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 2/4] rtc: ds1302: fix write value for day of week register

[Alexandre Belloni]

On 10/04/2016 at 23:59:24 +0900, Akinobu Mita wrote :
> The valid range of day of week register for DS1302 is 1 to 7.  But the
> set_time callback for rtc-ds1302 attempts to write the value of
> tm->tm_wday which is in the range 0 to 6.  While the get_time callback
> correctly decodes the register.
> 
> Signed-off-by: Akinobu Mita <akinobu.mita-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Sergey Yanovich <ynvich-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Alessandro Zummo <a.zummo-BfzFCNDTiLLj+vYz1yj4TQ@public.gmane.org>
> Cc: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
>  drivers/rtc/rtc-ds1302.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
Applied, thanks.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[rtc-linux] [PATCH 3/4] rtc: ds1302: add register access abstraction layer

[Akinobu Mita]

The rtc-ds1302 driver now implemented using SPI 3wire mode.
But I would like to access it with using three wires connected to GPIO
lines.

This adds abstraction layer for DS1302 register access in order to
prepare to support for using GPIO lines.  This enables to share common
code between SPI driver and GPIO driver.

Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Sergey Yanovich <ynvich@gmail.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
 drivers/rtc/rtc-ds1302.c | 224 ++++++++++++++++++++++++++++++++---------------
 1 file changed, 155 insertions(+), 69 deletions(-)

diff --git a/drivers/rtc/rtc-ds1302.c b/drivers/rtc/rtc-ds1302.c
index 454248f..1647848 100644
--- a/drivers/rtc/rtc-ds1302.c
+++ b/drivers/rtc/rtc-ds1302.c
@@ -7,6 +7,8 @@
  * This file is subject to the terms and conditions of the GNU General Public
  * License version 2. See the file "COPYING" in the main directory of
  * this archive for more details.
+ *
+ * Datasheet: https://datasheets.maximintegrated.com/en/ds/DS1302.pdf
  */
 
 #include <linux/bcd.h>
@@ -40,27 +42,58 @@
 #define	RTC_ADDR_MIN	0x01		/* Address of minute register */
 #define	RTC_ADDR_SEC	0x00		/* Address of second register */
 
+struct ds1302 {
+	const struct ds1302_ops *ops;
+	struct device *dev;
+};
+
+struct ds1302_ops {
+	int (*readbyte)(struct ds1302 *, u8);
+	int (*writebyte)(struct ds1302 *, u8, u8);
+	int (*readburst)(struct ds1302 *, u8, u8 *, int);
+	int (*writeburst)(struct ds1302 *, u8, const u8 *, int);
+};
+
+static int ds1302_readbyte(struct ds1302 *ds1302, u8 addr)
+{
+	return ds1302->ops->readbyte(ds1302, addr);
+}
+
+static int ds1302_writebyte(struct ds1302 *ds1302, u8 addr, u8 val)
+{
+	return ds1302->ops->writebyte(ds1302, addr, val);
+}
+
+static int ds1302_readburst(struct ds1302 *ds1302, u8 addr, u8 *buf, int size)
+{
+	if (addr != RTC_CLCK_BURST)
+		return -EINVAL;
+
+	return ds1302->ops->readburst(ds1302, addr, buf, size);
+}
+
+static int ds1302_writeburst(struct ds1302 *ds1302, u8 addr, const u8 *buf,
+			     int size)
+{
+	if (addr != RTC_CLCK_BURST)
+		return -EINVAL;
+
+	return ds1302->ops->writeburst(ds1302, addr, buf, size);
+}
+
 static int ds1302_rtc_set_time(struct device *dev, struct rtc_time *time)
 {
-	struct spi_device	*spi = dev_get_drvdata(dev);
-	u8		buf[1 + RTC_CLCK_LEN];
+	struct ds1302	*ds1302 = dev_get_drvdata(dev);
+	u8		buf[RTC_CLCK_LEN];
 	u8		*bp = buf;
 	int		status;
 
 	/* Enable writing */
-	bp = buf;
-	*bp++ = RTC_ADDR_CTRL << 1 | RTC_CMD_WRITE;
-	*bp++ = RTC_CMD_WRITE_ENABLE;
-
-	status = spi_write_then_read(spi, buf, 2,
-			NULL, 0);
+	status = ds1302_writebyte(ds1302, RTC_ADDR_CTRL, RTC_CMD_WRITE_ENABLE);
 	if (status)
 		return status;
 
 	/* Write registers starting at the first time/date address. */
-	bp = buf;
-	*bp++ = RTC_CLCK_BURST << 1 | RTC_CMD_WRITE;
-
 	*bp++ = bin2bcd(time->tm_sec);
 	*bp++ = bin2bcd(time->tm_min);
 	*bp++ = bin2bcd(time->tm_hour);
@@ -70,23 +103,16 @@ static int ds1302_rtc_set_time(struct device *dev, struct rtc_time *time)
 	*bp++ = bin2bcd(time->tm_year % 100);
 	*bp++ = RTC_CMD_WRITE_DISABLE;
 
-	/* use write-then-read since dma from stack is nonportable */
-	return spi_write_then_read(spi, buf, sizeof(buf),
-			NULL, 0);
+	return ds1302_writeburst(ds1302, RTC_CLCK_BURST, buf, sizeof(buf));
 }
 
 static int ds1302_rtc_get_time(struct device *dev, struct rtc_time *time)
 {
-	struct spi_device	*spi = dev_get_drvdata(dev);
-	u8		addr = RTC_CLCK_BURST << 1 | RTC_CMD_READ;
+	struct ds1302	*ds1302 = dev_get_drvdata(dev);
 	u8		buf[RTC_CLCK_LEN - 1];
 	int		status;
 
-	/* Use write-then-read to get all the date/time registers
-	 * since dma from stack is nonportable
-	 */
-	status = spi_write_then_read(spi, &addr, sizeof(addr),
-			buf, sizeof(buf));
+	status = ds1302_readburst(ds1302, RTC_CLCK_BURST, buf, sizeof(buf));
 	if (status < 0)
 		return status;
 
@@ -108,94 +134,155 @@ static struct rtc_class_ops ds1302_rtc_ops = {
 	.set_time	= ds1302_rtc_set_time,
 };
 
-static int ds1302_probe(struct spi_device *spi)
+static int ds1302_probe(struct ds1302 *ds1302)
 {
 	struct rtc_device	*rtc;
-	u8		addr;
-	u8		buf[4];
-	u8		*bp = buf;
 	int		status;
 
-	/* Sanity check board setup data.  This may be hooked up
-	 * in 3wire mode, but we don't care.  Note that unless
-	 * there's an inverter in place, this needs SPI_CS_HIGH!
-	 */
-	if (spi->bits_per_word && (spi->bits_per_word != 8)) {
-		dev_err(&spi->dev, "bad word length\n");
-		return -EINVAL;
-	} else if (spi->max_speed_hz > 2000000) {
-		dev_err(&spi->dev, "speed is too high\n");
-		return -EINVAL;
-	} else if (spi->mode & SPI_CPHA) {
-		dev_err(&spi->dev, "bad mode\n");
-		return -EINVAL;
-	}
+	dev_set_drvdata(ds1302->dev, ds1302);
 
-	addr = RTC_ADDR_CTRL << 1 | RTC_CMD_READ;
-	status = spi_write_then_read(spi, &addr, sizeof(addr), buf, 1);
+	status = ds1302_readbyte(ds1302, RTC_ADDR_CTRL);
 	if (status < 0) {
-		dev_err(&spi->dev, "control register read error %d\n",
+		dev_err(ds1302->dev, "control register read error %d\n",
 				status);
 		return status;
 	}
 
-	if ((buf[0] & ~RTC_CMD_WRITE_DISABLE) != 0) {
-		status = spi_write_then_read(spi, &addr, sizeof(addr), buf, 1);
+	if (status & ~RTC_CMD_WRITE_DISABLE) {
+		status = ds1302_readbyte(ds1302, RTC_ADDR_CTRL);
 		if (status < 0) {
-			dev_err(&spi->dev, "control register read error %d\n",
+			dev_err(ds1302->dev, "control register read error %d\n",
 					status);
 			return status;
 		}
 
-		if ((buf[0] & ~RTC_CMD_WRITE_DISABLE) != 0) {
-			dev_err(&spi->dev, "junk in control register\n");
+		if (status & ~RTC_CMD_WRITE_DISABLE) {
+			dev_err(ds1302->dev, "junk in control register\n");
 			return -ENODEV;
 		}
 	}
-	if (buf[0] == 0) {
-		bp = buf;
-		*bp++ = RTC_ADDR_CTRL << 1 | RTC_CMD_WRITE;
-		*bp++ = RTC_CMD_WRITE_DISABLE;
-
-		status = spi_write_then_read(spi, buf, 2, NULL, 0);
+	if (status == 0) {
+		status = ds1302_writebyte(ds1302, RTC_ADDR_CTRL,
+					  RTC_CMD_WRITE_DISABLE);
 		if (status < 0) {
-			dev_err(&spi->dev, "control register write error %d\n",
-					status);
+			dev_err(ds1302->dev,
+				"control register write error %d\n", status);
 			return status;
 		}
 
-		addr = RTC_ADDR_CTRL << 1 | RTC_CMD_READ;
-		status = spi_write_then_read(spi, &addr, sizeof(addr), buf, 1);
+		status = ds1302_readbyte(ds1302, RTC_ADDR_CTRL);
 		if (status < 0) {
-			dev_err(&spi->dev,
+			dev_err(ds1302->dev,
 					"error %d reading control register\n",
 					status);
 			return status;
 		}
 
-		if (buf[0] != RTC_CMD_WRITE_DISABLE) {
-			dev_err(&spi->dev, "failed to detect chip\n");
+		if (status != RTC_CMD_WRITE_DISABLE) {
+			dev_err(ds1302->dev, "failed to detect chip\n");
 			return -ENODEV;
 		}
 	}
 
-	spi_set_drvdata(spi, spi);
-
-	rtc = devm_rtc_device_register(&spi->dev, "ds1302",
+	rtc = devm_rtc_device_register(ds1302->dev, "ds1302",
 			&ds1302_rtc_ops, THIS_MODULE);
 	if (IS_ERR(rtc)) {
 		status = PTR_ERR(rtc);
-		dev_err(&spi->dev, "error %d registering rtc\n", status);
+		dev_err(ds1302->dev, "error %d registering rtc\n", status);
 		return status;
 	}
 
 	return 0;
 }
 
-static int ds1302_remove(struct spi_device *spi)
+static int ds1302_spi_readbyte(struct ds1302 *ds1302, u8 addr)
 {
-	spi_set_drvdata(spi, NULL);
-	return 0;
+	struct spi_device *spi = to_spi_device(ds1302->dev);
+	int err;
+	u8 buf;
+
+	addr = addr << 1 | RTC_CMD_READ;
+	err = spi_write_then_read(spi, &addr, sizeof(addr), &buf, 1);
+	if (err)
+		return err;
+
+	return buf;
+}
+
+static int ds1302_spi_writebyte(struct ds1302 *ds1302, u8 addr, u8 val)
+{
+	struct spi_device *spi = to_spi_device(ds1302->dev);
+	u8 buf[2] = {
+		addr << 1 | RTC_CMD_WRITE,
+		val,
+	};
+
+	return spi_write_then_read(spi, buf, sizeof(buf), NULL, 0);
+}
+
+static int ds1302_spi_readburst(struct ds1302 *ds1302, u8 addr, u8 *buf,
+				int size)
+{
+	struct spi_device *spi = to_spi_device(ds1302->dev);
+
+	addr = addr << 1 | RTC_CMD_READ;
+
+	/* Use write-then-read to get all the date/time registers
+	 * since dma from stack is nonportable
+	 */
+	return spi_write_then_read(spi, &addr, sizeof(addr), buf, size);
+}
+
+static int ds1302_spi_writeburst(struct ds1302 *ds1302, u8 addr, const u8 *buf,
+				 int size)
+{
+	struct spi_device *spi = to_spi_device(ds1302->dev);
+	u8 write_buf[RTC_CLCK_LEN + 1];
+
+	if (size + 1 > sizeof(write_buf))
+		return -EINVAL;
+
+	write_buf[0] = addr << 1 | RTC_CMD_WRITE;
+	memcpy(write_buf + 1, buf, size);
+
+	/* use write-then-read since dma from stack is nonportable */
+	return spi_write_then_read(spi, write_buf, size + 1, NULL, 0);
+}
+
+static const struct ds1302_ops ds1302_spi_ops = {
+	.readbyte = ds1302_spi_readbyte,
+	.writebyte = ds1302_spi_writebyte,
+	.readburst = ds1302_spi_readburst,
+	.writeburst = ds1302_spi_writeburst,
+};
+
+static int ds1302_spi_probe(struct spi_device *spi)
+{
+	struct ds1302		*ds1302;
+
+	/* Sanity check board setup data.  This may be hooked up
+	 * in 3wire mode, but we don't care.  Note that unless
+	 * there's an inverter in place, this needs SPI_CS_HIGH!
+	 */
+	if (spi->bits_per_word && (spi->bits_per_word != 8)) {
+		dev_err(&spi->dev, "bad word length\n");
+		return -EINVAL;
+	} else if (spi->max_speed_hz > 2000000) {
+		dev_err(&spi->dev, "speed is too high\n");
+		return -EINVAL;
+	} else if (spi->mode & SPI_CPHA) {
+		dev_err(&spi->dev, "bad mode\n");
+		return -EINVAL;
+	}
+
+	ds1302 = devm_kzalloc(&spi->dev, sizeof(*ds1302), GFP_KERNEL);
+	if (!ds1302)
+		return -ENOMEM;
+
+	ds1302->ops = &ds1302_spi_ops;
+	ds1302->dev = &spi->dev;
+
+	return ds1302_probe(ds1302);
 }
 
 #ifdef CONFIG_OF
@@ -209,8 +296,7 @@ MODULE_DEVICE_TABLE(of, ds1302_dt_ids);
 static struct spi_driver ds1302_driver = {
 	.driver.name	= "rtc-ds1302",
 	.driver.of_match_table = of_match_ptr(ds1302_dt_ids),
-	.probe		= ds1302_probe,
-	.remove		= ds1302_remove,
+	.probe		= ds1302_spi_probe,
 };
 
 module_spi_driver(ds1302_driver);
-- 
2.5.0

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[PATCH 3/4] rtc: ds1302: add register access abstraction layer

[Akinobu Mita]

The rtc-ds1302 driver now implemented using SPI 3wire mode.
But I would like to access it with using three wires connected to GPIO
lines.

This adds abstraction layer for DS1302 register access in order to
prepare to support for using GPIO lines.  This enables to share common
code between SPI driver and GPIO driver.

Signed-off-by: Akinobu Mita <akinobu.mita-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Sergey Yanovich <ynvich-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Alessandro Zummo <a.zummo-BfzFCNDTiLLj+vYz1yj4TQ@public.gmane.org>
Cc: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
 drivers/rtc/rtc-ds1302.c | 224 ++++++++++++++++++++++++++++++++---------------
 1 file changed, 155 insertions(+), 69 deletions(-)

diff --git a/drivers/rtc/rtc-ds1302.c b/drivers/rtc/rtc-ds1302.c
index 454248f..1647848 100644
--- a/drivers/rtc/rtc-ds1302.c
+++ b/drivers/rtc/rtc-ds1302.c
@@ -7,6 +7,8 @@
  * This file is subject to the terms and conditions of the GNU General Public
  * License version 2. See the file "COPYING" in the main directory of
  * this archive for more details.
+ *
+ * Datasheet: https://datasheets.maximintegrated.com/en/ds/DS1302.pdf
  */
 
 #include <linux/bcd.h>
@@ -40,27 +42,58 @@
 #define	RTC_ADDR_MIN	0x01		/* Address of minute register */
 #define	RTC_ADDR_SEC	0x00		/* Address of second register */
 
+struct ds1302 {
+	const struct ds1302_ops *ops;
+	struct device *dev;
+};
+
+struct ds1302_ops {
+	int (*readbyte)(struct ds1302 *, u8);
+	int (*writebyte)(struct ds1302 *, u8, u8);
+	int (*readburst)(struct ds1302 *, u8, u8 *, int);
+	int (*writeburst)(struct ds1302 *, u8, const u8 *, int);
+};
+
+static int ds1302_readbyte(struct ds1302 *ds1302, u8 addr)
+{
+	return ds1302->ops->readbyte(ds1302, addr);
+}
+
+static int ds1302_writebyte(struct ds1302 *ds1302, u8 addr, u8 val)
+{
+	return ds1302->ops->writebyte(ds1302, addr, val);
+}
+
+static int ds1302_readburst(struct ds1302 *ds1302, u8 addr, u8 *buf, int size)
+{
+	if (addr != RTC_CLCK_BURST)
+		return -EINVAL;
+
+	return ds1302->ops->readburst(ds1302, addr, buf, size);
+}
+
+static int ds1302_writeburst(struct ds1302 *ds1302, u8 addr, const u8 *buf,
+			     int size)
+{
+	if (addr != RTC_CLCK_BURST)
+		return -EINVAL;
+
+	return ds1302->ops->writeburst(ds1302, addr, buf, size);
+}
+
 static int ds1302_rtc_set_time(struct device *dev, struct rtc_time *time)
 {
-	struct spi_device	*spi = dev_get_drvdata(dev);
-	u8		buf[1 + RTC_CLCK_LEN];
+	struct ds1302	*ds1302 = dev_get_drvdata(dev);
+	u8		buf[RTC_CLCK_LEN];
 	u8		*bp = buf;
 	int		status;
 
 	/* Enable writing */
-	bp = buf;
-	*bp++ = RTC_ADDR_CTRL << 1 | RTC_CMD_WRITE;
-	*bp++ = RTC_CMD_WRITE_ENABLE;
-
-	status = spi_write_then_read(spi, buf, 2,
-			NULL, 0);
+	status = ds1302_writebyte(ds1302, RTC_ADDR_CTRL, RTC_CMD_WRITE_ENABLE);
 	if (status)
 		return status;
 
 	/* Write registers starting at the first time/date address. */
-	bp = buf;
-	*bp++ = RTC_CLCK_BURST << 1 | RTC_CMD_WRITE;
-
 	*bp++ = bin2bcd(time->tm_sec);
 	*bp++ = bin2bcd(time->tm_min);
 	*bp++ = bin2bcd(time->tm_hour);
@@ -70,23 +103,16 @@ static int ds1302_rtc_set_time(struct device *dev, struct rtc_time *time)
 	*bp++ = bin2bcd(time->tm_year % 100);
 	*bp++ = RTC_CMD_WRITE_DISABLE;
 
-	/* use write-then-read since dma from stack is nonportable */
-	return spi_write_then_read(spi, buf, sizeof(buf),
-			NULL, 0);
+	return ds1302_writeburst(ds1302, RTC_CLCK_BURST, buf, sizeof(buf));
 }
 
 static int ds1302_rtc_get_time(struct device *dev, struct rtc_time *time)
 {
-	struct spi_device	*spi = dev_get_drvdata(dev);
-	u8		addr = RTC_CLCK_BURST << 1 | RTC_CMD_READ;
+	struct ds1302	*ds1302 = dev_get_drvdata(dev);
 	u8		buf[RTC_CLCK_LEN - 1];
 	int		status;
 
-	/* Use write-then-read to get all the date/time registers
-	 * since dma from stack is nonportable
-	 */
-	status = spi_write_then_read(spi, &addr, sizeof(addr),
-			buf, sizeof(buf));
+	status = ds1302_readburst(ds1302, RTC_CLCK_BURST, buf, sizeof(buf));
 	if (status < 0)
 		return status;
 
@@ -108,94 +134,155 @@ static struct rtc_class_ops ds1302_rtc_ops = {
 	.set_time	= ds1302_rtc_set_time,
 };
 
-static int ds1302_probe(struct spi_device *spi)
+static int ds1302_probe(struct ds1302 *ds1302)
 {
 	struct rtc_device	*rtc;
-	u8		addr;
-	u8		buf[4];
-	u8		*bp = buf;
 	int		status;
 
-	/* Sanity check board setup data.  This may be hooked up
-	 * in 3wire mode, but we don't care.  Note that unless
-	 * there's an inverter in place, this needs SPI_CS_HIGH!
-	 */
-	if (spi->bits_per_word && (spi->bits_per_word != 8)) {
-		dev_err(&spi->dev, "bad word length\n");
-		return -EINVAL;
-	} else if (spi->max_speed_hz > 2000000) {
-		dev_err(&spi->dev, "speed is too high\n");
-		return -EINVAL;
-	} else if (spi->mode & SPI_CPHA) {
-		dev_err(&spi->dev, "bad mode\n");
-		return -EINVAL;
-	}
+	dev_set_drvdata(ds1302->dev, ds1302);
 
-	addr = RTC_ADDR_CTRL << 1 | RTC_CMD_READ;
-	status = spi_write_then_read(spi, &addr, sizeof(addr), buf, 1);
+	status = ds1302_readbyte(ds1302, RTC_ADDR_CTRL);
 	if (status < 0) {
-		dev_err(&spi->dev, "control register read error %d\n",
+		dev_err(ds1302->dev, "control register read error %d\n",
 				status);
 		return status;
 	}
 
-	if ((buf[0] & ~RTC_CMD_WRITE_DISABLE) != 0) {
-		status = spi_write_then_read(spi, &addr, sizeof(addr), buf, 1);
+	if (status & ~RTC_CMD_WRITE_DISABLE) {
+		status = ds1302_readbyte(ds1302, RTC_ADDR_CTRL);
 		if (status < 0) {
-			dev_err(&spi->dev, "control register read error %d\n",
+			dev_err(ds1302->dev, "control register read error %d\n",
 					status);
 			return status;
 		}
 
-		if ((buf[0] & ~RTC_CMD_WRITE_DISABLE) != 0) {
-			dev_err(&spi->dev, "junk in control register\n");
+		if (status & ~RTC_CMD_WRITE_DISABLE) {
+			dev_err(ds1302->dev, "junk in control register\n");
 			return -ENODEV;
 		}
 	}
-	if (buf[0] == 0) {
-		bp = buf;
-		*bp++ = RTC_ADDR_CTRL << 1 | RTC_CMD_WRITE;
-		*bp++ = RTC_CMD_WRITE_DISABLE;
-
-		status = spi_write_then_read(spi, buf, 2, NULL, 0);
+	if (status == 0) {
+		status = ds1302_writebyte(ds1302, RTC_ADDR_CTRL,
+					  RTC_CMD_WRITE_DISABLE);
 		if (status < 0) {
-			dev_err(&spi->dev, "control register write error %d\n",
-					status);
+			dev_err(ds1302->dev,
+				"control register write error %d\n", status);
 			return status;
 		}
 
-		addr = RTC_ADDR_CTRL << 1 | RTC_CMD_READ;
-		status = spi_write_then_read(spi, &addr, sizeof(addr), buf, 1);
+		status = ds1302_readbyte(ds1302, RTC_ADDR_CTRL);
 		if (status < 0) {
-			dev_err(&spi->dev,
+			dev_err(ds1302->dev,
 					"error %d reading control register\n",
 					status);
 			return status;
 		}
 
-		if (buf[0] != RTC_CMD_WRITE_DISABLE) {
-			dev_err(&spi->dev, "failed to detect chip\n");
+		if (status != RTC_CMD_WRITE_DISABLE) {
+			dev_err(ds1302->dev, "failed to detect chip\n");
 			return -ENODEV;
 		}
 	}
 
-	spi_set_drvdata(spi, spi);
-
-	rtc = devm_rtc_device_register(&spi->dev, "ds1302",
+	rtc = devm_rtc_device_register(ds1302->dev, "ds1302",
 			&ds1302_rtc_ops, THIS_MODULE);
 	if (IS_ERR(rtc)) {
 		status = PTR_ERR(rtc);
-		dev_err(&spi->dev, "error %d registering rtc\n", status);
+		dev_err(ds1302->dev, "error %d registering rtc\n", status);
 		return status;
 	}
 
 	return 0;
 }
 
-static int ds1302_remove(struct spi_device *spi)
+static int ds1302_spi_readbyte(struct ds1302 *ds1302, u8 addr)
 {
-	spi_set_drvdata(spi, NULL);
-	return 0;
+	struct spi_device *spi = to_spi_device(ds1302->dev);
+	int err;
+	u8 buf;
+
+	addr = addr << 1 | RTC_CMD_READ;
+	err = spi_write_then_read(spi, &addr, sizeof(addr), &buf, 1);
+	if (err)
+		return err;
+
+	return buf;
+}
+
+static int ds1302_spi_writebyte(struct ds1302 *ds1302, u8 addr, u8 val)
+{
+	struct spi_device *spi = to_spi_device(ds1302->dev);
+	u8 buf[2] = {
+		addr << 1 | RTC_CMD_WRITE,
+		val,
+	};
+
+	return spi_write_then_read(spi, buf, sizeof(buf), NULL, 0);
+}
+
+static int ds1302_spi_readburst(struct ds1302 *ds1302, u8 addr, u8 *buf,
+				int size)
+{
+	struct spi_device *spi = to_spi_device(ds1302->dev);
+
+	addr = addr << 1 | RTC_CMD_READ;
+
+	/* Use write-then-read to get all the date/time registers
+	 * since dma from stack is nonportable
+	 */
+	return spi_write_then_read(spi, &addr, sizeof(addr), buf, size);
+}
+
+static int ds1302_spi_writeburst(struct ds1302 *ds1302, u8 addr, const u8 *buf,
+				 int size)
+{
+	struct spi_device *spi = to_spi_device(ds1302->dev);
+	u8 write_buf[RTC_CLCK_LEN + 1];
+
+	if (size + 1 > sizeof(write_buf))
+		return -EINVAL;
+
+	write_buf[0] = addr << 1 | RTC_CMD_WRITE;
+	memcpy(write_buf + 1, buf, size);
+
+	/* use write-then-read since dma from stack is nonportable */
+	return spi_write_then_read(spi, write_buf, size + 1, NULL, 0);
+}
+
+static const struct ds1302_ops ds1302_spi_ops = {
+	.readbyte = ds1302_spi_readbyte,
+	.writebyte = ds1302_spi_writebyte,
+	.readburst = ds1302_spi_readburst,
+	.writeburst = ds1302_spi_writeburst,
+};
+
+static int ds1302_spi_probe(struct spi_device *spi)
+{
+	struct ds1302		*ds1302;
+
+	/* Sanity check board setup data.  This may be hooked up
+	 * in 3wire mode, but we don't care.  Note that unless
+	 * there's an inverter in place, this needs SPI_CS_HIGH!
+	 */
+	if (spi->bits_per_word && (spi->bits_per_word != 8)) {
+		dev_err(&spi->dev, "bad word length\n");
+		return -EINVAL;
+	} else if (spi->max_speed_hz > 2000000) {
+		dev_err(&spi->dev, "speed is too high\n");
+		return -EINVAL;
+	} else if (spi->mode & SPI_CPHA) {
+		dev_err(&spi->dev, "bad mode\n");
+		return -EINVAL;
+	}
+
+	ds1302 = devm_kzalloc(&spi->dev, sizeof(*ds1302), GFP_KERNEL);
+	if (!ds1302)
+		return -ENOMEM;
+
+	ds1302->ops = &ds1302_spi_ops;
+	ds1302->dev = &spi->dev;
+
+	return ds1302_probe(ds1302);
 }
 
 #ifdef CONFIG_OF
@@ -209,8 +296,7 @@ MODULE_DEVICE_TABLE(of, ds1302_dt_ids);
 static struct spi_driver ds1302_driver = {
 	.driver.name	= "rtc-ds1302",
 	.driver.of_match_table = of_match_ptr(ds1302_dt_ids),
-	.probe		= ds1302_probe,
-	.remove		= ds1302_remove,
+	.probe		= ds1302_spi_probe,
 };
 
 module_spi_driver(ds1302_driver);
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[rtc-linux] [PATCH 4/4] rtc: ds1302: support control with using GPIO lines

[Akinobu Mita]

This adds support control with GPIO lines connected to the DS1302
which can communicate with three wires.

Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Sergey Yanovich <ynvich@gmail.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
 .../devicetree/bindings/rtc/maxim-ds1302.txt       |  13 +
 drivers/rtc/Kconfig                                |  17 +-
 drivers/rtc/rtc-ds1302.c                           | 340 ++++++++++++++++++++-
 3 files changed, 351 insertions(+), 19 deletions(-)

diff --git a/Documentation/devicetree/bindings/rtc/maxim-ds1302.txt b/Documentation/devicetree/bindings/rtc/maxim-ds1302.txt
index ba470c5..d489753 100644
--- a/Documentation/devicetree/bindings/rtc/maxim-ds1302.txt
+++ b/Documentation/devicetree/bindings/rtc/maxim-ds1302.txt
@@ -27,6 +27,12 @@ Required SPI properties:
 - spi-cs-high: DS-1302 has active high chip select line. This is
   required unless inverted in hardware.
 
+Required properties when using GPIO lines:
+
+- gpio-ce: GPIO connected to CE pin
+- gpio-io: GPIO connected to I/O pin
+- gpio-reset: GPIO connected to SCLK pin
+
 Example:
 
 spi@901c {
@@ -44,3 +50,10 @@ spi@901c {
 		spi-cs-high;
 	};
 };
+
+	rtc: ds1302 {
+		compatible = "maxim,ds1302";
+		gpio-ce = <&gpio2 6 GPIO_ACTIVE_HIGH>;
+		gpio-io = <&gpio2 7 GPIO_ACTIVE_HIGH>;
+		gpio-sclk = <&gpio2 8 GPIO_ACTIVE_HIGH>;
+	};
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index a86a562..734dc1b 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -636,15 +636,6 @@ config RTC_DRV_M41T94
 	  This driver can also be built as a module. If so, the module
 	  will be called rtc-m41t94.
 
-config RTC_DRV_DS1302
-	tristate "Dallas/Maxim DS1302"
-	depends on SPI
-	help
-	  If you say yes here you get support for the Dallas DS1302 RTC chips.
-
-	  This driver can also be built as a module. If so, the module
-	  will be called rtc-ds1302.
-
 config RTC_DRV_DS1305
 	tristate "Dallas/Maxim DS1305/DS1306"
 	help
@@ -1639,6 +1630,14 @@ config RTC_DRV_XGENE
 	  This driver can also be built as a module, if so, the module
 	  will be called "rtc-xgene".
 
+config RTC_DRV_DS1302
+	tristate "Dallas/Maxim DS1302"
+	help
+	  If you say yes here you get support for the Dallas DS1302 RTC chips.
+
+	  This driver can also be built as a module. If so, the module
+	  will be called rtc-ds1302.
+
 comment "HID Sensor RTC drivers"
 
 config RTC_DRV_HID_SENSOR_TIME
diff --git a/drivers/rtc/rtc-ds1302.c b/drivers/rtc/rtc-ds1302.c
index 1647848..778f39a 100644
--- a/drivers/rtc/rtc-ds1302.c
+++ b/drivers/rtc/rtc-ds1302.c
@@ -19,6 +19,10 @@
 #include <linux/of.h>
 #include <linux/rtc.h>
 #include <linux/spi/spi.h>
+#include <linux/delay.h>
+#include <linux/platform_device.h>
+#include <linux/of_gpio.h>
+#include <linux/gpio/consumer.h>
 
 #define DRV_NAME	"rtc-ds1302"
 #define DRV_VERSION	"1.0.0"
@@ -195,6 +199,16 @@ static int ds1302_probe(struct ds1302 *ds1302)
 	return 0;
 }
 
+#ifdef CONFIG_OF
+static const struct of_device_id ds1302_dt_ids[] = {
+	{ .compatible = "maxim,ds1302", },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, ds1302_dt_ids);
+#endif
+
+#if IS_ENABLED(CONFIG_SPI_MASTER)
+
 static int ds1302_spi_readbyte(struct ds1302 *ds1302, u8 addr)
 {
 	struct spi_device *spi = to_spi_device(ds1302->dev);
@@ -285,21 +299,327 @@ static int ds1302_spi_probe(struct spi_device *spi)
 	return ds1302_probe(ds1302);
 }
 
-#ifdef CONFIG_OF
-static const struct of_device_id ds1302_dt_ids[] = {
-	{ .compatible = "maxim,ds1302", },
-	{ /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(of, ds1302_dt_ids);
-#endif
-
-static struct spi_driver ds1302_driver = {
+static struct spi_driver ds1302_spi_driver = {
 	.driver.name	= "rtc-ds1302",
 	.driver.of_match_table = of_match_ptr(ds1302_dt_ids),
 	.probe		= ds1302_spi_probe,
 };
 
-module_spi_driver(ds1302_driver);
+static int ds1302_spi_register_driver(void)
+{
+	return spi_register_driver(&ds1302_spi_driver);
+}
+
+static void ds1302_spi_unregister_driver(void)
+{
+	spi_unregister_driver(&ds1302_spi_driver);
+}
+
+#else
+
+static int ds1302_spi_register_driver(void)
+{
+	return 0;
+}
+
+static void ds1302_spi_unregister_driver(void)
+{
+}
+
+#endif
+
+/*
+ * ds1302 driver using three GPIO lines
+ *
+ * The information to implement this is gleaned from
+ * http://playground.arduino.cc/Main/DS1302
+ */
+struct ds1302_gpio {
+	struct gpio_desc *gpiod_ce;
+	struct gpio_desc *gpiod_io;
+	struct gpio_desc *gpiod_sclk;
+
+	struct ds1302 ds1302;
+};
+
+static struct ds1302_gpio *to_ds1302_gpio(struct ds1302 *ds1302)
+{
+	return container_of(ds1302, struct ds1302_gpio, ds1302);
+}
+
+static int ds1302_gpio_reset(struct ds1302 *ds1302)
+{
+	struct ds1302_gpio *gpio = to_ds1302_gpio(ds1302);
+	int ret;
+
+	ret = gpiod_direction_output(gpio->gpiod_ce, 0);
+	if (ret)
+		return ret;
+
+	ret = gpiod_direction_output(gpio->gpiod_io, 0);
+	if (ret)
+		return ret;
+
+	return gpiod_direction_output(gpio->gpiod_sclk, 0);
+}
+
+static void ds1302_gpio_chip_enable(struct ds1302 *ds1302, int enable)
+{
+	struct ds1302_gpio *gpio = to_ds1302_gpio(ds1302);
+
+	gpiod_set_value(gpio->gpiod_ce, enable);
+	if (enable) {
+		/*
+		 * tCC (CE to CLK Setup): 4us
+		 */
+		udelay(4);
+	} else {
+		/*
+		 * tCWH (CE Inactive Time): 4us
+		 */
+		udelay(4);
+	}
+}
+
+static int ds1302_gpio_sendbits(struct ds1302 *ds1302, u8 val)
+{
+	struct ds1302_gpio *gpio = to_ds1302_gpio(ds1302);
+	int i;
+
+	for (i = 0; i < 8; i++, val >>= 1) {
+		gpiod_set_value(gpio->gpiod_sclk, 0);
+		/* tCL (CLK Low Time): 1000ns */
+		udelay(1);
+
+		gpiod_set_value(gpio->gpiod_io, val & 0x1);
+		/* tDC (Data to CLK Setup): 200ns */
+		udelay(1);
+
+		gpiod_set_value(gpio->gpiod_sclk, 1);
+		/*
+		 * tCH (CLK High Time): 1000ns
+		 * tCDH (CLK to Data Hold): 800ns
+		 */
+		udelay(1);
+	}
+
+	return 0;
+}
+
+static unsigned int ds1302_gpio_recvbits(struct ds1302 *ds1302)
+{
+	unsigned int val;
+	int i;
+	struct ds1302_gpio *gpio = to_ds1302_gpio(ds1302);
+
+	for (i = 0, val = 0; i < 8; i++) {
+		int bit;
+
+		gpiod_set_value(gpio->gpiod_sclk, 0);
+		/*
+		 * tCL (CLK Low Time): 1000ns
+		 * tCDD (CLK to Data Delay): 800ns
+		 */
+		udelay(1);
+
+		bit = gpiod_get_value(gpio->gpiod_io);
+		if (bit < 0)
+			return bit;
+		val |= bit << i;
+
+		gpiod_set_value(gpio->gpiod_sclk, 1);
+		/* tCH (CLK High Time): 1000ns */
+		udelay(1);
+	}
+
+	return val;
+}
+
+static int ds1302_gpio_readburst(struct ds1302 *ds1302, u8 addr, u8 *buf,
+				 int size)
+{
+	int i;
+	int ret;
+	struct ds1302_gpio *gpio = to_ds1302_gpio(ds1302);
+
+	ret = ds1302_gpio_reset(ds1302);
+	if (ret)
+		return ret;
+
+	ds1302_gpio_chip_enable(ds1302, true);
+
+	ds1302_gpio_sendbits(ds1302, ((addr & 0x3f) << 1) | RTC_CMD_READ);
+
+	ret = gpiod_direction_input(gpio->gpiod_io);
+	if (ret)
+		return ret;
+
+	for (i = 0; i < size; i++) {
+		ret = ds1302_gpio_recvbits(ds1302);
+		if (ret < 0)
+			break;
+		 buf[i] = ret;
+	}
+
+	ds1302_gpio_chip_enable(ds1302, false);
+
+	return ret < 0 ? ret : 0;
+}
+
+static int ds1302_gpio_readbyte(struct ds1302 *ds1302, u8 addr)
+{
+	u8 val;
+	int err;
+
+	err = ds1302_gpio_readburst(ds1302, addr, &val, 1);
+	if (err)
+		return err;
+
+	return val;
+}
+
+static int ds1302_gpio_writeburst(struct ds1302 *ds1302, u8 addr, const u8 *buf,
+				  int size)
+{
+	int err;
+	int i;
+
+	err = ds1302_gpio_reset(ds1302);
+	if (err)
+		return err;
+
+	ds1302_gpio_chip_enable(ds1302, true);
+
+	ds1302_gpio_sendbits(ds1302, ((addr & 0x3f) << 1) | RTC_CMD_WRITE);
+
+	for (i = 0; i < size; i++) {
+		err = ds1302_gpio_sendbits(ds1302, buf[i]);
+		if (err)
+			break;
+	}
+
+	ds1302_gpio_chip_enable(ds1302, false);
+
+	return err;
+}
+
+static int ds1302_gpio_writebyte(struct ds1302 *ds1302, u8 addr, u8 val)
+{
+	return ds1302_gpio_writeburst(ds1302, addr, &val, 1);
+}
+
+static const struct ds1302_ops ds1302_gpio_ops = {
+	.readbyte = ds1302_gpio_readbyte,
+	.writebyte = ds1302_gpio_writebyte,
+	.readburst = ds1302_gpio_readburst,
+	.writeburst = ds1302_gpio_writeburst,
+};
+
+static struct gpio_desc *ds1302_gpiod_request(struct device *dev,
+						const char *name)
+{
+	int gpio;
+	int ret;
+
+	if (!dev->of_node)
+		return ERR_PTR(-ENODEV);
+
+	gpio = of_get_named_gpio(dev->of_node, name, 0);
+	if (!gpio_is_valid(gpio))
+		return ERR_PTR(gpio);
+
+	ret = devm_gpio_request_one(dev, gpio, 0, name);
+	if (ret)
+		return ERR_PTR(ret);
+
+	return gpio_to_desc(gpio);
+}
+
+static struct ds1302 *ds1302_gpio_init(struct device *dev)
+{
+	struct ds1302_gpio *ds1302_gpio;
+	struct gpio_desc *gpiod;
+
+	ds1302_gpio = devm_kzalloc(dev, sizeof(*ds1302_gpio), GFP_KERNEL);
+	if (!ds1302_gpio)
+		return ERR_PTR(-ENOMEM);
+
+	ds1302_gpio->ds1302.ops = &ds1302_gpio_ops;
+	ds1302_gpio->ds1302.dev = dev;
+
+	gpiod = ds1302_gpiod_request(dev, "gpio-ce");
+	if (IS_ERR(gpiod))
+		return ERR_CAST(gpiod);
+	ds1302_gpio->gpiod_ce = gpiod;
+
+	gpiod = ds1302_gpiod_request(dev, "gpio-io");
+	if (IS_ERR(gpiod))
+		return ERR_CAST(gpiod);
+	ds1302_gpio->gpiod_io = gpiod;
+
+	gpiod = ds1302_gpiod_request(dev, "gpio-sclk");
+	if (IS_ERR(gpiod))
+		return ERR_CAST(gpiod);
+	ds1302_gpio->gpiod_sclk = gpiod;
+
+	return &ds1302_gpio->ds1302;
+}
+
+static int ds1302_gpio_probe(struct platform_device *pdev)
+ {
+	struct ds1302 *ds1302;
+
+	ds1302 = ds1302_gpio_init(&pdev->dev);
+	if (IS_ERR(ds1302))
+		return PTR_ERR(ds1302);;
+
+	return ds1302_probe(ds1302);
+}
+
+static struct platform_driver ds1302_gpio_driver = {
+	.probe = ds1302_gpio_probe,
+	.driver		= {
+		.name	= "rtc-ds1302",
+		.of_match_table = of_match_ptr(ds1302_dt_ids),
+	},
+};
+
+static int ds1302_gpio_register_driver(void)
+{
+	return platform_driver_register(&ds1302_gpio_driver);
+}
+
+static void ds1302_gpio_unregister_driver(void)
+{
+	return platform_driver_unregister(&ds1302_gpio_driver);
+}
+
+static int __init ds1302_init(void)
+{
+	int ret;
+
+	ret = ds1302_spi_register_driver();
+	if (ret) {
+		pr_err("Failed to register ds1302 spi driver: %d\n", ret);
+		return ret;
+	}
+
+	ret = ds1302_gpio_register_driver();
+        if (ret) {
+		pr_err("Failed to register ds1302 gpio driver: %d\n", ret);
+		ds1302_spi_unregister_driver();
+	}
+
+	return ret;
+}
+module_init(ds1302_init)
+
+static void __exit ds1302_exit(void)
+{
+	ds1302_spi_unregister_driver();
+	ds1302_gpio_unregister_driver();
+}
+module_exit(ds1302_exit)
 
 MODULE_DESCRIPTION("Dallas DS1302 RTC driver");
 MODULE_VERSION(DRV_VERSION);
-- 
2.5.0

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[PATCH 4/4] rtc: ds1302: support control with using GPIO lines

[Akinobu Mita]

This adds support control with GPIO lines connected to the DS1302
which can communicate with three wires.

Signed-off-by: Akinobu Mita <akinobu.mita-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Sergey Yanovich <ynvich-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Alessandro Zummo <a.zummo-BfzFCNDTiLLj+vYz1yj4TQ@public.gmane.org>
Cc: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
 .../devicetree/bindings/rtc/maxim-ds1302.txt       |  13 +
 drivers/rtc/Kconfig                                |  17 +-
 drivers/rtc/rtc-ds1302.c                           | 340 ++++++++++++++++++++-
 3 files changed, 351 insertions(+), 19 deletions(-)

diff --git a/Documentation/devicetree/bindings/rtc/maxim-ds1302.txt b/Documentation/devicetree/bindings/rtc/maxim-ds1302.txt
index ba470c5..d489753 100644
--- a/Documentation/devicetree/bindings/rtc/maxim-ds1302.txt
+++ b/Documentation/devicetree/bindings/rtc/maxim-ds1302.txt
@@ -27,6 +27,12 @@ Required SPI properties:
 - spi-cs-high: DS-1302 has active high chip select line. This is
   required unless inverted in hardware.
 
+Required properties when using GPIO lines:
+
+- gpio-ce: GPIO connected to CE pin
+- gpio-io: GPIO connected to I/O pin
+- gpio-reset: GPIO connected to SCLK pin
+
 Example:
 
 spi@901c {
@@ -44,3 +50,10 @@ spi@901c {
 		spi-cs-high;
 	};
 };
+
+	rtc: ds1302 {
+		compatible = "maxim,ds1302";
+		gpio-ce = <&gpio2 6 GPIO_ACTIVE_HIGH>;
+		gpio-io = <&gpio2 7 GPIO_ACTIVE_HIGH>;
+		gpio-sclk = <&gpio2 8 GPIO_ACTIVE_HIGH>;
+	};
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index a86a562..734dc1b 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -636,15 +636,6 @@ config RTC_DRV_M41T94
 	  This driver can also be built as a module. If so, the module
 	  will be called rtc-m41t94.
 
-config RTC_DRV_DS1302
-	tristate "Dallas/Maxim DS1302"
-	depends on SPI
-	help
-	  If you say yes here you get support for the Dallas DS1302 RTC chips.
-
-	  This driver can also be built as a module. If so, the module
-	  will be called rtc-ds1302.
-
 config RTC_DRV_DS1305
 	tristate "Dallas/Maxim DS1305/DS1306"
 	help
@@ -1639,6 +1630,14 @@ config RTC_DRV_XGENE
 	  This driver can also be built as a module, if so, the module
 	  will be called "rtc-xgene".
 
+config RTC_DRV_DS1302
+	tristate "Dallas/Maxim DS1302"
+	help
+	  If you say yes here you get support for the Dallas DS1302 RTC chips.
+
+	  This driver can also be built as a module. If so, the module
+	  will be called rtc-ds1302.
+
 comment "HID Sensor RTC drivers"
 
 config RTC_DRV_HID_SENSOR_TIME
diff --git a/drivers/rtc/rtc-ds1302.c b/drivers/rtc/rtc-ds1302.c
index 1647848..778f39a 100644
--- a/drivers/rtc/rtc-ds1302.c
+++ b/drivers/rtc/rtc-ds1302.c
@@ -19,6 +19,10 @@
 #include <linux/of.h>
 #include <linux/rtc.h>
 #include <linux/spi/spi.h>
+#include <linux/delay.h>
+#include <linux/platform_device.h>
+#include <linux/of_gpio.h>
+#include <linux/gpio/consumer.h>
 
 #define DRV_NAME	"rtc-ds1302"
 #define DRV_VERSION	"1.0.0"
@@ -195,6 +199,16 @@ static int ds1302_probe(struct ds1302 *ds1302)
 	return 0;
 }
 
+#ifdef CONFIG_OF
+static const struct of_device_id ds1302_dt_ids[] = {
+	{ .compatible = "maxim,ds1302", },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, ds1302_dt_ids);
+#endif
+
+#if IS_ENABLED(CONFIG_SPI_MASTER)
+
 static int ds1302_spi_readbyte(struct ds1302 *ds1302, u8 addr)
 {
 	struct spi_device *spi = to_spi_device(ds1302->dev);
@@ -285,21 +299,327 @@ static int ds1302_spi_probe(struct spi_device *spi)
 	return ds1302_probe(ds1302);
 }
 
-#ifdef CONFIG_OF
-static const struct of_device_id ds1302_dt_ids[] = {
-	{ .compatible = "maxim,ds1302", },
-	{ /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(of, ds1302_dt_ids);
-#endif
-
-static struct spi_driver ds1302_driver = {
+static struct spi_driver ds1302_spi_driver = {
 	.driver.name	= "rtc-ds1302",
 	.driver.of_match_table = of_match_ptr(ds1302_dt_ids),
 	.probe		= ds1302_spi_probe,
 };
 
-module_spi_driver(ds1302_driver);
+static int ds1302_spi_register_driver(void)
+{
+	return spi_register_driver(&ds1302_spi_driver);
+}
+
+static void ds1302_spi_unregister_driver(void)
+{
+	spi_unregister_driver(&ds1302_spi_driver);
+}
+
+#else
+
+static int ds1302_spi_register_driver(void)
+{
+	return 0;
+}
+
+static void ds1302_spi_unregister_driver(void)
+{
+}
+
+#endif
+
+/*
+ * ds1302 driver using three GPIO lines
+ *
+ * The information to implement this is gleaned from
+ * http://playground.arduino.cc/Main/DS1302
+ */
+struct ds1302_gpio {
+	struct gpio_desc *gpiod_ce;
+	struct gpio_desc *gpiod_io;
+	struct gpio_desc *gpiod_sclk;
+
+	struct ds1302 ds1302;
+};
+
+static struct ds1302_gpio *to_ds1302_gpio(struct ds1302 *ds1302)
+{
+	return container_of(ds1302, struct ds1302_gpio, ds1302);
+}
+
+static int ds1302_gpio_reset(struct ds1302 *ds1302)
+{
+	struct ds1302_gpio *gpio = to_ds1302_gpio(ds1302);
+	int ret;
+
+	ret = gpiod_direction_output(gpio->gpiod_ce, 0);
+	if (ret)
+		return ret;
+
+	ret = gpiod_direction_output(gpio->gpiod_io, 0);
+	if (ret)
+		return ret;
+
+	return gpiod_direction_output(gpio->gpiod_sclk, 0);
+}
+
+static void ds1302_gpio_chip_enable(struct ds1302 *ds1302, int enable)
+{
+	struct ds1302_gpio *gpio = to_ds1302_gpio(ds1302);
+
+	gpiod_set_value(gpio->gpiod_ce, enable);
+	if (enable) {
+		/*
+		 * tCC (CE to CLK Setup): 4us
+		 */
+		udelay(4);
+	} else {
+		/*
+		 * tCWH (CE Inactive Time): 4us
+		 */
+		udelay(4);
+	}
+}
+
+static int ds1302_gpio_sendbits(struct ds1302 *ds1302, u8 val)
+{
+	struct ds1302_gpio *gpio = to_ds1302_gpio(ds1302);
+	int i;
+
+	for (i = 0; i < 8; i++, val >>= 1) {
+		gpiod_set_value(gpio->gpiod_sclk, 0);
+		/* tCL (CLK Low Time): 1000ns */
+		udelay(1);
+
+		gpiod_set_value(gpio->gpiod_io, val & 0x1);
+		/* tDC (Data to CLK Setup): 200ns */
+		udelay(1);
+
+		gpiod_set_value(gpio->gpiod_sclk, 1);
+		/*
+		 * tCH (CLK High Time): 1000ns
+		 * tCDH (CLK to Data Hold): 800ns
+		 */
+		udelay(1);
+	}
+
+	return 0;
+}
+
+static unsigned int ds1302_gpio_recvbits(struct ds1302 *ds1302)
+{
+	unsigned int val;
+	int i;
+	struct ds1302_gpio *gpio = to_ds1302_gpio(ds1302);
+
+	for (i = 0, val = 0; i < 8; i++) {
+		int bit;
+
+		gpiod_set_value(gpio->gpiod_sclk, 0);
+		/*
+		 * tCL (CLK Low Time): 1000ns
+		 * tCDD (CLK to Data Delay): 800ns
+		 */
+		udelay(1);
+
+		bit = gpiod_get_value(gpio->gpiod_io);
+		if (bit < 0)
+			return bit;
+		val |= bit << i;
+
+		gpiod_set_value(gpio->gpiod_sclk, 1);
+		/* tCH (CLK High Time): 1000ns */
+		udelay(1);
+	}
+
+	return val;
+}
+
+static int ds1302_gpio_readburst(struct ds1302 *ds1302, u8 addr, u8 *buf,
+				 int size)
+{
+	int i;
+	int ret;
+	struct ds1302_gpio *gpio = to_ds1302_gpio(ds1302);
+
+	ret = ds1302_gpio_reset(ds1302);
+	if (ret)
+		return ret;
+
+	ds1302_gpio_chip_enable(ds1302, true);
+
+	ds1302_gpio_sendbits(ds1302, ((addr & 0x3f) << 1) | RTC_CMD_READ);
+
+	ret = gpiod_direction_input(gpio->gpiod_io);
+	if (ret)
+		return ret;
+
+	for (i = 0; i < size; i++) {
+		ret = ds1302_gpio_recvbits(ds1302);
+		if (ret < 0)
+			break;
+		 buf[i] = ret;
+	}
+
+	ds1302_gpio_chip_enable(ds1302, false);
+
+	return ret < 0 ? ret : 0;
+}
+
+static int ds1302_gpio_readbyte(struct ds1302 *ds1302, u8 addr)
+{
+	u8 val;
+	int err;
+
+	err = ds1302_gpio_readburst(ds1302, addr, &val, 1);
+	if (err)
+		return err;
+
+	return val;
+}
+
+static int ds1302_gpio_writeburst(struct ds1302 *ds1302, u8 addr, const u8 *buf,
+				  int size)
+{
+	int err;
+	int i;
+
+	err = ds1302_gpio_reset(ds1302);
+	if (err)
+		return err;
+
+	ds1302_gpio_chip_enable(ds1302, true);
+
+	ds1302_gpio_sendbits(ds1302, ((addr & 0x3f) << 1) | RTC_CMD_WRITE);
+
+	for (i = 0; i < size; i++) {
+		err = ds1302_gpio_sendbits(ds1302, buf[i]);
+		if (err)
+			break;
+	}
+
+	ds1302_gpio_chip_enable(ds1302, false);
+
+	return err;
+}
+
+static int ds1302_gpio_writebyte(struct ds1302 *ds1302, u8 addr, u8 val)
+{
+	return ds1302_gpio_writeburst(ds1302, addr, &val, 1);
+}
+
+static const struct ds1302_ops ds1302_gpio_ops = {
+	.readbyte = ds1302_gpio_readbyte,
+	.writebyte = ds1302_gpio_writebyte,
+	.readburst = ds1302_gpio_readburst,
+	.writeburst = ds1302_gpio_writeburst,
+};
+
+static struct gpio_desc *ds1302_gpiod_request(struct device *dev,
+						const char *name)
+{
+	int gpio;
+	int ret;
+
+	if (!dev->of_node)
+		return ERR_PTR(-ENODEV);
+
+	gpio = of_get_named_gpio(dev->of_node, name, 0);
+	if (!gpio_is_valid(gpio))
+		return ERR_PTR(gpio);
+
+	ret = devm_gpio_request_one(dev, gpio, 0, name);
+	if (ret)
+		return ERR_PTR(ret);
+
+	return gpio_to_desc(gpio);
+}
+
+static struct ds1302 *ds1302_gpio_init(struct device *dev)
+{
+	struct ds1302_gpio *ds1302_gpio;
+	struct gpio_desc *gpiod;
+
+	ds1302_gpio = devm_kzalloc(dev, sizeof(*ds1302_gpio), GFP_KERNEL);
+	if (!ds1302_gpio)
+		return ERR_PTR(-ENOMEM);
+
+	ds1302_gpio->ds1302.ops = &ds1302_gpio_ops;
+	ds1302_gpio->ds1302.dev = dev;
+
+	gpiod = ds1302_gpiod_request(dev, "gpio-ce");
+	if (IS_ERR(gpiod))
+		return ERR_CAST(gpiod);
+	ds1302_gpio->gpiod_ce = gpiod;
+
+	gpiod = ds1302_gpiod_request(dev, "gpio-io");
+	if (IS_ERR(gpiod))
+		return ERR_CAST(gpiod);
+	ds1302_gpio->gpiod_io = gpiod;
+
+	gpiod = ds1302_gpiod_request(dev, "gpio-sclk");
+	if (IS_ERR(gpiod))
+		return ERR_CAST(gpiod);
+	ds1302_gpio->gpiod_sclk = gpiod;
+
+	return &ds1302_gpio->ds1302;
+}
+
+static int ds1302_gpio_probe(struct platform_device *pdev)
+ {
+	struct ds1302 *ds1302;
+
+	ds1302 = ds1302_gpio_init(&pdev->dev);
+	if (IS_ERR(ds1302))
+		return PTR_ERR(ds1302);;
+
+	return ds1302_probe(ds1302);
+}
+
+static struct platform_driver ds1302_gpio_driver = {
+	.probe = ds1302_gpio_probe,
+	.driver		= {
+		.name	= "rtc-ds1302",
+		.of_match_table = of_match_ptr(ds1302_dt_ids),
+	},
+};
+
+static int ds1302_gpio_register_driver(void)
+{
+	return platform_driver_register(&ds1302_gpio_driver);
+}
+
+static void ds1302_gpio_unregister_driver(void)
+{
+	return platform_driver_unregister(&ds1302_gpio_driver);
+}
+
+static int __init ds1302_init(void)
+{
+	int ret;
+
+	ret = ds1302_spi_register_driver();
+	if (ret) {
+		pr_err("Failed to register ds1302 spi driver: %d\n", ret);
+		return ret;
+	}
+
+	ret = ds1302_gpio_register_driver();
+        if (ret) {
+		pr_err("Failed to register ds1302 gpio driver: %d\n", ret);
+		ds1302_spi_unregister_driver();
+	}
+
+	return ret;
+}
+module_init(ds1302_init)
+
+static void __exit ds1302_exit(void)
+{
+	ds1302_spi_unregister_driver();
+	ds1302_gpio_unregister_driver();
+}
+module_exit(ds1302_exit)
 
 MODULE_DESCRIPTION("Dallas DS1302 RTC driver");
 MODULE_VERSION(DRV_VERSION);
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[rtc-linux] Re: [PATCH 0/4] support control with using GPIO lines

[Alexandre Belloni]

Hi,

On 10/04/2016 at 23:59:22 +0900, Akinobu Mita wrote :
> This series adds support access to DS1302 with GPIO lines.
> 
> Recently rtc-ds1302 is rewritten using SPI 3wire mode.  This adds
> another platform driver using GPIO while supporting both modes.
> 
> Thie series first fixes two problems I found while tesing, secondly
> introduces the abstraction layer for the register access which enables
> to share the most code between spi and platform driver, and adds
> the platform driver using GPIO.
> 

Well, isn't spi-gpio fitting for that use case? I'd like to avoid open
coding gpio bitbanging in the driver.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 0/4] support control with using GPIO lines

[Alexandre Belloni]

Hi,

On 10/04/2016 at 23:59:22 +0900, Akinobu Mita wrote :
> This series adds support access to DS1302 with GPIO lines.
> 
> Recently rtc-ds1302 is rewritten using SPI 3wire mode.  This adds
> another platform driver using GPIO while supporting both modes.
> 
> Thie series first fixes two problems I found while tesing, secondly
> introduces the abstraction layer for the register access which enables
> to share the most code between spi and platform driver, and adds
> the platform driver using GPIO.
> 

Well, isn't spi-gpio fitting for that use case? I'd like to avoid open
coding gpio bitbanging in the driver.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[rtc-linux] Re: [PATCH 0/4] support control with using GPIO lines

[Sergei Ianovich]

On Sun, 2016-04-10 at 17:12 +0200, Alexandre Belloni wrote:
> Hi,
>=20
> On 10/04/2016 at 23:59:22 +0900, Akinobu Mita wrote :
> >=20
> > This series adds support access to DS1302 with GPIO lines.
> >=20
> > Recently rtc-ds1302 is rewritten using SPI 3wire mode.=C2=A0=C2=A0This =
adds
> > another platform driver using GPIO while supporting both modes.
> >=20
> > Thie series first fixes two problems I found while tesing, secondly
> > introduces the abstraction layer for the register access which
> > enables
> > to share the most code between spi and platform driver, and adds
> > the platform driver using GPIO.
> >=20
> Well, isn't spi-gpio fitting for that use case? I'd like to avoid
> open
> coding gpio bitbanging in the driver.

No, unfortunately. I've investigated this possibility for my platform.
spi-gpio doesn't support LSB-first and 3-wire options. Adding support
there is a very big change. The best way to add GPIO support is to
create spi-gpio-3wire with LSB-first support.

--=20
--=20
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---=20
You received this message because you are subscribed to the Google Groups "=
rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 0/4] support control with using GPIO lines

[Sergei Ianovich]

On Sun, 2016-04-10 at 17:12 +0200, Alexandre Belloni wrote:
> Hi,
> 
> On 10/04/2016 at 23:59:22 +0900, Akinobu Mita wrote :
> > 
> > This series adds support access to DS1302 with GPIO lines.
> > 
> > Recently rtc-ds1302 is rewritten using SPI 3wire mode.  This adds
> > another platform driver using GPIO while supporting both modes.
> > 
> > Thie series first fixes two problems I found while tesing, secondly
> > introduces the abstraction layer for the register access which
> > enables
> > to share the most code between spi and platform driver, and adds
> > the platform driver using GPIO.
> > 
> Well, isn't spi-gpio fitting for that use case? I'd like to avoid
> open
> coding gpio bitbanging in the driver.

No, unfortunately. I've investigated this possibility for my platform.
spi-gpio doesn't support LSB-first and 3-wire options. Adding support
there is a very big change. The best way to add GPIO support is to
create spi-gpio-3wire with LSB-first support.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[rtc-linux] Re: [PATCH 0/4] support control with using GPIO lines

[Alexandre Belloni]

[Adding Mark]

On 10/04/2016 at 18:23:01 +0300, Sergei Ianovich wrote :
> On Sun, 2016-04-10 at 17:12 +0200, Alexandre Belloni wrote:
> > Hi,
> >=20
> > On 10/04/2016 at 23:59:22 +0900, Akinobu Mita wrote :
> > >=20
> > > This series adds support access to DS1302 with GPIO lines.
> > >=20
> > > Recently rtc-ds1302 is rewritten using SPI 3wire mode.=C2=A0=C2=A0Thi=
s adds
> > > another platform driver using GPIO while supporting both modes.
> > >=20
> > > Thie series first fixes two problems I found while tesing, secondly
> > > introduces the abstraction layer for the register access which
> > > enables
> > > to share the most code between spi and platform driver, and adds
> > > the platform driver using GPIO.
> > >=20
> > Well, isn't spi-gpio fitting for that use case? I'd like to avoid
> > open
> > coding gpio bitbanging in the driver.
>=20
> No, unfortunately. I've investigated this possibility for my platform.
> spi-gpio doesn't support LSB-first and 3-wire options. Adding support
> there is a very big change. The best way to add GPIO support is to
> create spi-gpio-3wire with LSB-first support.

Mark, do you have nay opinion on that?


--=20
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

--=20
--=20
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---=20
You received this message because you are subscribed to the Google Groups "=
rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 0/4] support control with using GPIO lines

[Alexandre Belloni]

[Adding Mark]

On 10/04/2016 at 18:23:01 +0300, Sergei Ianovich wrote :
> On Sun, 2016-04-10 at 17:12 +0200, Alexandre Belloni wrote:
> > Hi,
> > 
> > On 10/04/2016 at 23:59:22 +0900, Akinobu Mita wrote :
> > > 
> > > This series adds support access to DS1302 with GPIO lines.
> > > 
> > > Recently rtc-ds1302 is rewritten using SPI 3wire mode.  This adds
> > > another platform driver using GPIO while supporting both modes.
> > > 
> > > Thie series first fixes two problems I found while tesing, secondly
> > > introduces the abstraction layer for the register access which
> > > enables
> > > to share the most code between spi and platform driver, and adds
> > > the platform driver using GPIO.
> > > 
> > Well, isn't spi-gpio fitting for that use case? I'd like to avoid
> > open
> > coding gpio bitbanging in the driver.
> 
> No, unfortunately. I've investigated this possibility for my platform.
> spi-gpio doesn't support LSB-first and 3-wire options. Adding support
> there is a very big change. The best way to add GPIO support is to
> create spi-gpio-3wire with LSB-first support.

Mark, do you have nay opinion on that?


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[rtc-linux] Re: [PATCH 0/4] support control with using GPIO lines

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]

On Sun, Apr 10, 2016 at 05:38:55PM +0200, Alexandre Belloni wrote:
> On 10/04/2016 at 18:23:01 +0300, Sergei Ianovich wrote :

> > No, unfortunately. I've investigated this possibility for my platform.
> > spi-gpio doesn't support LSB-first and 3-wire options. Adding support
> > there is a very big change. The best way to add GPIO support is to
> > create spi-gpio-3wire with LSB-first support.

> Mark, do you have nay opinion on that?

Three wire doesn't seem like it should be invasive, LSB is going to be a
lot more invasive though it seems reasonable to just do the reversal in
the driver for whatever device this is and let the SPI controller run
normally.  Or we could do that in the core with a pass over the data.

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH 0/4] support control with using GPIO lines

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 725 bytes --]

On Sun, Apr 10, 2016 at 05:38:55PM +0200, Alexandre Belloni wrote:
> On 10/04/2016 at 18:23:01 +0300, Sergei Ianovich wrote :

> > No, unfortunately. I've investigated this possibility for my platform.
> > spi-gpio doesn't support LSB-first and 3-wire options. Adding support
> > there is a very big change. The best way to add GPIO support is to
> > create spi-gpio-3wire with LSB-first support.

> Mark, do you have nay opinion on that?

Three wire doesn't seem like it should be invasive, LSB is going to be a
lot more invasive though it seems reasonable to just do the reversal in
the driver for whatever device this is and let the SPI controller run
normally.  Or we could do that in the core with a pass over the data.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[rtc-linux] Re: [PATCH 0/4] support control with using GPIO lines

[Akinobu Mita]

Sorry for the late reply.

2016-04-12 10:25 GMT+09:00 Mark Brown <broonie@kernel.org>:
> On Sun, Apr 10, 2016 at 05:38:55PM +0200, Alexandre Belloni wrote:
>> On 10/04/2016 at 18:23:01 +0300, Sergei Ianovich wrote :
>
>> > No, unfortunately. I've investigated this possibility for my platform.
>> > spi-gpio doesn't support LSB-first and 3-wire options. Adding support
>> > there is a very big change. The best way to add GPIO support is to
>> > create spi-gpio-3wire with LSB-first support.
>
>> Mark, do you have nay opinion on that?
>
> Three wire doesn't seem like it should be invasive, LSB is going to be a
> lot more invasive though it seems reasonable to just do the reversal in
> the driver for whatever device this is and let the SPI controller run
> normally.  Or we could do that in the core with a pass over the data.

I've added 3wire support to spi-gpio and added the bit reversal logic
to ds1302 driver if the spi mode is not LSB first.  But the register
read command doesn't work.  I think there is no suitable SPI mode that
can communicate with DS1302.  The reason is as follows.

For the read data transfer, the address/command byte is sent on the
rising edge of the first eight SCLK cycles and the read data byte is
transmitted on the falling edge of the next eight SCL cycles.

But in the latter read data byte data phase, I/O pin is tri-stated
upon each rising edge of SCLK.
(Please see DATA OUTPUT section and Figure 6. Timing Diagram: Read Data
Transfer in https://datasheets.maximintegrated.com/en/ds/DS1302.pdf)

So if the SPI mode 0 (CPOL=0 CPHA=0) is selected, the address/command
byte phase is ok but the read data byte is unavailable because each
bit is retrieved while SCLK is high.  Similarly there is no suitable
SPI mode for DS1302.

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 0/4] support control with using GPIO lines

[Akinobu Mita]

Sorry for the late reply.

2016-04-12 10:25 GMT+09:00 Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
> On Sun, Apr 10, 2016 at 05:38:55PM +0200, Alexandre Belloni wrote:
>> On 10/04/2016 at 18:23:01 +0300, Sergei Ianovich wrote :
>
>> > No, unfortunately. I've investigated this possibility for my platform.
>> > spi-gpio doesn't support LSB-first and 3-wire options. Adding support
>> > there is a very big change. The best way to add GPIO support is to
>> > create spi-gpio-3wire with LSB-first support.
>
>> Mark, do you have nay opinion on that?
>
> Three wire doesn't seem like it should be invasive, LSB is going to be a
> lot more invasive though it seems reasonable to just do the reversal in
> the driver for whatever device this is and let the SPI controller run
> normally.  Or we could do that in the core with a pass over the data.

I've added 3wire support to spi-gpio and added the bit reversal logic
to ds1302 driver if the spi mode is not LSB first.  But the register
read command doesn't work.  I think there is no suitable SPI mode that
can communicate with DS1302.  The reason is as follows.

For the read data transfer, the address/command byte is sent on the
rising edge of the first eight SCLK cycles and the read data byte is
transmitted on the falling edge of the next eight SCL cycles.

But in the latter read data byte data phase, I/O pin is tri-stated
upon each rising edge of SCLK.
(Please see DATA OUTPUT section and Figure 6. Timing Diagram: Read Data
Transfer in https://datasheets.maximintegrated.com/en/ds/DS1302.pdf)

So if the SPI mode 0 (CPOL=0 CPHA=0) is selected, the address/command
byte phase is ok but the read data byte is unavailable because each
bit is retrieved while SCLK is high.  Similarly there is no suitable
SPI mode for DS1302.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[rtc-linux] Re: [PATCH 0/4] support control with using GPIO lines

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]

On Wed, Apr 27, 2016 at 04:53:18AM +0900, Akinobu Mita wrote:

> For the read data transfer, the address/command byte is sent on the
> rising edge of the first eight SCLK cycles and the read data byte is
> transmitted on the falling edge of the next eight SCL cycles.

That's an innovative and exciting hardware design :/  Definitely doesn't
seem to correspond too closely to any SPI mode I can think of.

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH 0/4] support control with using GPIO lines

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 405 bytes --]

On Wed, Apr 27, 2016 at 04:53:18AM +0900, Akinobu Mita wrote:

> For the read data transfer, the address/command byte is sent on the
> rising edge of the first eight SCLK cycles and the read data byte is
> transmitted on the falling edge of the next eight SCL cycles.

That's an innovative and exciting hardware design :/  Definitely doesn't
seem to correspond too closely to any SPI mode I can think of.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[rtc-linux] Re: [PATCH 0/4] support control with using GPIO lines

[Sergei Ianovich]

On Wed, 2016-04-27 at 14:50 +0100, Mark Brown wrote:
> On Wed, Apr 27, 2016 at 04:53:18AM +0900, Akinobu Mita wrote:
>=20
> >=20
> > For the read data transfer, the address/command byte is sent on the
> > rising edge of the first eight SCLK cycles and the read data byte
> > is
> > transmitted on the falling edge of the next eight SCL cycles.
> That's an innovative and exciting hardware design :/=C2=A0=C2=A0Definitel=
y
> doesn't
> seem to correspond too closely to any SPI mode I can think of.

DS1302 uses the standard MicroWire half-duplex transfer timing. The
timing can be handled by eg. PXA270 built-in SPI controller with proper
configuration.

--=20
--=20
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---=20
You received this message because you are subscribed to the Google Groups "=
rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 0/4] support control with using GPIO lines

[Sergei Ianovich]

On Wed, 2016-04-27 at 14:50 +0100, Mark Brown wrote:
> On Wed, Apr 27, 2016 at 04:53:18AM +0900, Akinobu Mita wrote:
> 
> > 
> > For the read data transfer, the address/command byte is sent on the
> > rising edge of the first eight SCLK cycles and the read data byte
> > is
> > transmitted on the falling edge of the next eight SCL cycles.
> That's an innovative and exciting hardware design :/  Definitely
> doesn't
> seem to correspond too closely to any SPI mode I can think of.

DS1302 uses the standard MicroWire half-duplex transfer timing. The
timing can be handled by eg. PXA270 built-in SPI controller with proper
configuration.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[rtc-linux] Re: [PATCH 0/4] support control with using GPIO lines

[Akinobu Mita]

2016-04-27 23:03 GMT+09:00 Sergei Ianovich <ynvich@gmail.com>:
> On Wed, 2016-04-27 at 14:50 +0100, Mark Brown wrote:
>> On Wed, Apr 27, 2016 at 04:53:18AM +0900, Akinobu Mita wrote:
>>
>> >
>> > For the read data transfer, the address/command byte is sent on the
>> > rising edge of the first eight SCLK cycles and the read data byte
>> > is
>> > transmitted on the falling edge of the next eight SCL cycles.
>> That's an innovative and exciting hardware design :/  Definitely
>> doesn't
>> seem to correspond too closely to any SPI mode I can think of.
>
> DS1302 uses the standard MicroWire half-duplex transfer timing. The
> timing can be handled by eg. PXA270 built-in SPI controller with proper
> configuration.

Thanks for clarification about the hardware.

I feel that using spi-gpio to communicate with DS1302 is difficult
because we need to introduce different timing option to spi-gpio
(spi-bitbang) for the I/O pin which is tri-stated upon each rising
edge of SCLK, as I said in the last email.

So I think that the way like the patch 3 and 4 in this series showed
is reasonable.  And rtc-ds2404, rtc-moxart, and rtc-v3020 do something
similar.

If there is no complaint, I'll resend patch 3 and 4 with small fixes.

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 0/4] support control with using GPIO lines

[Akinobu Mita]

2016-04-27 23:03 GMT+09:00 Sergei Ianovich <ynvich-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> On Wed, 2016-04-27 at 14:50 +0100, Mark Brown wrote:
>> On Wed, Apr 27, 2016 at 04:53:18AM +0900, Akinobu Mita wrote:
>>
>> >
>> > For the read data transfer, the address/command byte is sent on the
>> > rising edge of the first eight SCLK cycles and the read data byte
>> > is
>> > transmitted on the falling edge of the next eight SCL cycles.
>> That's an innovative and exciting hardware design :/  Definitely
>> doesn't
>> seem to correspond too closely to any SPI mode I can think of.
>
> DS1302 uses the standard MicroWire half-duplex transfer timing. The
> timing can be handled by eg. PXA270 built-in SPI controller with proper
> configuration.

Thanks for clarification about the hardware.

I feel that using spi-gpio to communicate with DS1302 is difficult
because we need to introduce different timing option to spi-gpio
(spi-bitbang) for the I/O pin which is tri-stated upon each rising
edge of SCLK, as I said in the last email.

So I think that the way like the patch 3 and 4 in this series showed
is reasonable.  And rtc-ds2404, rtc-moxart, and rtc-v3020 do something
similar.

If there is no complaint, I'll resend patch 3 and 4 with small fixes.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[rtc-linux] Re: [PATCH 0/4] support control with using GPIO lines

[Alexandre Belloni]

Hi,

On 29/04/2016 at 14:40:25 +0900, Akinobu Mita wrote :
> So I think that the way like the patch 3 and 4 in this series showed
> is reasonable.  And rtc-ds2404, rtc-moxart, and rtc-v3020 do something
> similar.
> 
> If there is no complaint, I'll resend patch 3 and 4 with small fixes.

Are you still planning to send a new version? I understand you had some
fixes.

Thanks!

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 0/4] support control with using GPIO lines

[Alexandre Belloni]

Hi,

On 29/04/2016 at 14:40:25 +0900, Akinobu Mita wrote :
> So I think that the way like the patch 3 and 4 in this series showed
> is reasonable.  And rtc-ds2404, rtc-moxart, and rtc-v3020 do something
> similar.
> 
> If there is no complaint, I'll resend patch 3 and 4 with small fixes.

Are you still planning to send a new version? I understand you had some
fixes.

Thanks!

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.

[rtc-linux] Re: [PATCH 0/4] support control with using GPIO lines

[Akinobu Mita]

2016-06-26 9:55 GMT+09:00 Alexandre Belloni
<alexandre.belloni@free-electrons.com>:
> Hi,
>
> On 29/04/2016 at 14:40:25 +0900, Akinobu Mita wrote :
>> So I think that the way like the patch 3 and 4 in this series showed
>> is reasonable.  And rtc-ds2404, rtc-moxart, and rtc-v3020 do something
>> similar.
>>
>> If there is no complaint, I'll resend patch 3 and 4 with small fixes.
>
> Are you still planning to send a new version? I understand you had some
> fixes.

I'll be sending the updated patches.  The update contains white space fixes
reported by checkpatch.pl and simplification for ds1302_ops.

-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 0/4] support control with using GPIO lines

[Akinobu Mita]

2016-06-26 9:55 GMT+09:00 Alexandre Belloni
<alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>:
> Hi,
>
> On 29/04/2016 at 14:40:25 +0900, Akinobu Mita wrote :
>> So I think that the way like the patch 3 and 4 in this series showed
>> is reasonable.  And rtc-ds2404, rtc-moxart, and rtc-v3020 do something
>> similar.
>>
>> If there is no complaint, I'll resend patch 3 and 4 with small fixes.
>
> Are you still planning to send a new version? I understand you had some
> fixes.

I'll be sending the updated patches.  The update contains white space fixes
reported by checkpatch.pl and simplification for ds1302_ops.

-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.

[rtc-linux] Re: [PATCH 0/4] support control with using GPIO lines

[Rob Herring]

On Sun, Apr 10, 2016 at 06:23:01PM +0300, Sergei Ianovich wrote:
> On Sun, 2016-04-10 at 17:12 +0200, Alexandre Belloni wrote:
> > Hi,
> >=20
> > On 10/04/2016 at 23:59:22 +0900, Akinobu Mita wrote :
> > >=20
> > > This series adds support access to DS1302 with GPIO lines.
> > >=20
> > > Recently rtc-ds1302 is rewritten using SPI 3wire mode.=C2=A0=C2=A0Thi=
s adds
> > > another platform driver using GPIO while supporting both modes.
> > >=20
> > > Thie series first fixes two problems I found while tesing, secondly
> > > introduces the abstraction layer for the register access which
> > > enables
> > > to share the most code between spi and platform driver, and adds
> > > the platform driver using GPIO.
> > >=20
> > Well, isn't spi-gpio fitting for that use case? I'd like to avoid
> > open
> > coding gpio bitbanging in the driver.

And I'd like to avoid a custom binding...

> No, unfortunately. I've investigated this possibility for my platform.
> spi-gpio doesn't support LSB-first and 3-wire options. Adding support
> there is a very big change. The best way to add GPIO support is to
> create spi-gpio-3wire with LSB-first support.

None of this is a concern of the binding.

Rob

--=20
--=20
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---=20
You received this message because you are subscribed to the Google Groups "=
rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 0/4] support control with using GPIO lines

[Rob Herring]

On Sun, Apr 10, 2016 at 06:23:01PM +0300, Sergei Ianovich wrote:
> On Sun, 2016-04-10 at 17:12 +0200, Alexandre Belloni wrote:
> > Hi,
> > 
> > On 10/04/2016 at 23:59:22 +0900, Akinobu Mita wrote :
> > > 
> > > This series adds support access to DS1302 with GPIO lines.
> > > 
> > > Recently rtc-ds1302 is rewritten using SPI 3wire mode.  This adds
> > > another platform driver using GPIO while supporting both modes.
> > > 
> > > Thie series first fixes two problems I found while tesing, secondly
> > > introduces the abstraction layer for the register access which
> > > enables
> > > to share the most code between spi and platform driver, and adds
> > > the platform driver using GPIO.
> > > 
> > Well, isn't spi-gpio fitting for that use case? I'd like to avoid
> > open
> > coding gpio bitbanging in the driver.

And I'd like to avoid a custom binding...

> No, unfortunately. I've investigated this possibility for my platform.
> spi-gpio doesn't support LSB-first and 3-wire options. Adding support
> there is a very big change. The best way to add GPIO support is to
> create spi-gpio-3wire with LSB-first support.

None of this is a concern of the binding.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html