rtc: support DS1302 RTC on ICP DAS LP-8x4x

PATCH In review Sergei Ianovich 3 participants 13 messages Dec 15, 2015 – Mar 28, 2016 1 message not in the archive

Subsystems (3)

Device tree bindings SuperH Real time clock (RTC)

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Sergei Ianovich

author

2015-12-15 17:45 UTC #1 lore raw

PATCH v5 1/1 rtc: support DS1302 RTC on ICP DAS LP-8x4x

Signed-off-by Sergei Ianovich <[email protected]>

CC Alexandre Belloni <[email protected]>

---
v4..v5
* drop THIS_MODULE from struct platform driver
* use "dallas" for vendor name per vendor-prefixes.txt

v3..v4
* move DTS bindings to a different patch

v2..v3
* use usleep_range instead of custom nsleep
* number change (07/16 -> 09/21)

v0..v2
* use device tree
* use devm helpers where possible

 .../devicetree/bindings/rtc/rtc-ds1302.txt         |  14 +++
 drivers/rtc/Kconfig                                |   2 +-
 drivers/rtc/rtc-ds1302.c                           | 100 ++++++++++++++++++++-
 3 files changed, 113 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/rtc/rtc-ds1302.txt

Documentation/devicetree/bindings/rtc/rtc-ds1302.txt new file +14 -0

new file mode 100644
index 0000000..810613b
@@ -0,0 +1,14 @@
+* Dallas Semiconductor DS-1302 RTC
+
+Simple device which could be used to store date/time between reboots.
+
+Required properties:
+- compatible : Should be "dallas,rtc-ds1302"
+- reg : Should be address and size of IO memory region
+
+Examples:
+
+rtc@40900000 {
+	compatible = "dallas,rtc-ds1302";
+	reg = <0x1700901c 0x1>;
+};

drivers/rtc/Kconfig +1 -1

index 2a52424..cf36483 100644
@@ -803,7 +803,7 @@ config RTC_DRV_DS1286
 
 config RTC_DRV_DS1302
 	tristate "Dallas DS1302"
-	depends on SH_SECUREEDGE5410
+	depends on SH_SECUREEDGE5410 || (ARCH_PXA && HIGH_RES_TIMERS)
 	help
 	  If you say yes here you get support for the Dallas DS1302 RTC chips.

drivers/rtc/rtc-ds1302.c +98 -2

124 lines not on this page · raw message

Signature · 1 line

2.6.2

Rob Herring

maintainer

2015-12-20 03:38 UTC #2 lore raw

On Tue, Dec 15, 2015 at 08:45:23PM +0300, Sergei Ianovich wrote:

Nothing in this is specific to ICP, so the subject should be updated.

Quoted 30 lines

Signed-off-by Sergei Ianovich <[email protected]>
CC Alexandre Belloni <[email protected]>
---
v4..v5
* drop THIS_MODULE from struct platform driver
* use "dallas" for vendor name per vendor-prefixes.txt
v3..v4
* move DTS bindings to a different patch
v2..v3
* use usleep_range instead of custom nsleep
* number change (07/16 -> 09/21)
v0..v2
* use device tree
* use devm helpers where possible
 .../devicetree/bindings/rtc/rtc-ds1302.txt         |  14 +++
 drivers/rtc/Kconfig                                |   2 +-
 drivers/rtc/rtc-ds1302.c                           | 100 ++++++++++++++++++++-
 3 files changed, 113 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/rtc/rtc-ds1302.txt
Documentation/devicetree/bindings/rtc/rtc-ds1302.txt new file +0 -0
new file mode 100644
index 0000000..810613b

Documentation/devicetree/bindings/rtc/rtc-ds1302.txt line 7

Quoted 7 lines

Documentation/devicetree/bindings/rtc/rtc-ds1302.txt new file +7 -0

@@ -0,0 +1,14 @@
+* Dallas Semiconductor DS-1302 RTC
+
+Simple device which could be used to store date/time between reboots.
+
+Required properties:
+- compatible : Should be "dallas,rtc-ds1302"
+- reg : Should be address and size of IO memory region

This device is a SPI (or SPI like?) interface. So you have some sort of of FPGA logic in between the cpu and ds1302. The DT should have a node for the controller and then the ds1302 as a child of it. A full blown SPI driver may be overkill here, but that's a separate discussion from the DT binding.

Rob

Quoted 7 lines

Documentation/devicetree/bindings/rtc/rtc-ds1302.txt new file +7 -0
+
+Examples:
+
+rtc@40900000 {
+	compatible = "dallas,rtc-ds1302";
+	reg = <0x1700901c 0x1>;
+};

Sergei Ianovich

author

2015-12-20 12:14 UTC #3 lore raw

Quoted 44 lines · Rob Herring

On Tue, Dec 15, 2015 at 08:45:23PM +0300, Sergei Ianovich wrote:
Nothing in this is specific to ICP, so the subject should be updated.
Quoted 40 lines
Signed-off-by Sergei Ianovich <[email protected]>
CC Alexandre Belloni <[email protected]>
---
   v4..v5
   * drop THIS_MODULE from struct platform driver
   * use "dallas" for vendor name per vendor-prefixes.txt
   v3..v4
   * move DTS bindings to a different patch
   v2..v3
   * use usleep_range instead of custom nsleep
   * number change (07/16 -> 09/21)
   v0..v2
   * use device tree
   * use devm helpers where possible
.../devicetree/bindings/rtc/rtc-ds1302.txt         |  14 +++ drivers/rtc/Kconfig                                |   2 +- drivers/rtc/rtc-ds1302.c                           | 100
++++++++++++++++++++-
 3 files changed, 113 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/rtc/rtc- ds1302.txt
Documentation/devicetree/bindings/rtc/rtc-ds1302.txt new file +3 -0
new file mode 100644
index 0000000..810613b
@@ -0,0 +1,14 @@
+* Dallas Semiconductor DS-1302 RTC
+
+Simple device which could be used to store date/time between
reboots.
Documentation/devicetree/bindings/rtc/rtc-ds1302.txt new file +3 -0
+
+Required properties:
+- compatible : Should be "dallas,rtc-ds1302"

Quoted 8 lines

Quoted 1 line
+- reg : Should be address and size of IO memory region
This device is a SPI (or SPI like?) interface. So you have some sort of
of FPGA logic in between the cpu and ds1302. The DT should have a node for the controller and then the ds1302 as a child of it. A full blown SPI driver may be overkill here, but that's a separate discussion from the DT binding.

Below is the quote from the actual DT of LP-8x4x:

Quoted 7 lines

fpga@5 {
compatible = "simple-bus"; #address-cells = <1>; #size-cells = <1>; ranges = <0 5 0x3000000 0x10000>; interrupt-parent = <&fpgairq>;

Quoted 5 lines

                        rtc@901c {
                                compatible = "dallas,rtc-ds1302"; reg = <0x901c 0x1>; status = "okay";
                        };

You are right about the topology. ds1302 is a half-duplex SPI device. Does this mean I should rewrite the driver to handle the chip as a slave SPI device, and then provide a master SPI functionality at the FPGA?

Rob Herring

maintainer

2015-12-22 18:16 UTC #4 lore raw

Quoted 2 lines · Sergei Ianovich

Quoted 1 line · Rob Herring
On Tue, Dec 15, 2015 at 08:45:23PM +0300, Sergei Ianovich wrote:

[...]

Quoted 23 lines

Quoted 14 lines
Quoted 14 lines
Documentation/devicetree/bindings/rtc/rtc-ds1302.txt new file +3 -0
new file mode 100644
index 0000000..810613b
@@ -0,0 +1,14 @@
+* Dallas Semiconductor DS-1302 RTC
+
+Simple device which could be used to store date/time between
reboots.
Documentation/devicetree/bindings/rtc/rtc-ds1302.txt new file +3 -0
+
+Required properties:
+- compatible : Should be "dallas,rtc-ds1302"
Quoted 8 lines
Quoted 1 line
+- reg : Should be address and size of IO memory region
This device is a SPI (or SPI like?) interface. So you have some sort of
of FPGA logic in between the cpu and ds1302. The DT should have a node for the controller and then the ds1302 as a child of it. A full blown SPI driver may be overkill here, but that's a separate discussion from the DT binding.

Quoted 10 lines

Below is the quote from the actual DT of LP-8x4x:

Quoted 9 lines

                fpga@5 {
                        compatible = "simple-bus";
                        #address-cells = <1>;
                        #size-cells = <1>;
                        ranges = <0 5 0x3000000 0x10000>;
                        interrupt-parent = <&fpgairq>;

                        rtc@901c {
                                compatible = "dallas,rtc-ds1302";

This node should have a LP-8x4x specific compatible and then have a child node for ds1302 that follows the SPI binding.

Quoted 7 lines

Quoted 3 lines
                                reg = <0x901c 0x1>;
                                status = "okay";
                        };
You are right about the topology. ds1302 is a half-duplex SPI device. Does this mean I should rewrite the driver to handle the chip as a slave SPI device, and then provide a master SPI functionality at the FPGA?

Well, the binding should reflect that, whether the driver needs to be re-written is somewhat a separate question. That should probably have been done for the DS1302 driver originally and it is not too fair for the 2nd person to fix it. You could just have a single driver bound to the controller node which is aware of the DS1302 being the slave device (ignoring that part of the DT for now).

Rob

Alexandre Belloni

2015-12-24 11:04 UTC #5 lore raw

Hi,

Quoted 7 lines · Rob Herring

Well, the binding should reflect that, whether the driver needs to be re-written is somewhat a separate question. That should probably have been done for the DS1302 driver originally and it is not too fair for the 2nd person to fix it. You could just have a single driver bound to the controller node which is aware of the DS1302 being the slave device (ignoring that part of the DT for now).

I agree with Rob here. I won't require that you fix the driver but it would be better to have a proper DT binding from the beginning so that when the driver is fixed it will still work with the previous device trees.

Signature · 7 lines

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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Sergei Ianovich

author

2015-12-24 11:07 UTC #6 lore raw

Quoted 13 lines · Alexandre Belloni

Quoted 11 lines · Rob Herring
Well, the binding should reflect that, whether the driver needs to be
re-written is somewhat a separate question. That should probably have
been done for the DS1302 driver originally and it is not too fair for
the 2nd person to fix it. You could just have a single driver bound to
the controller node which is aware of the DS1302 being the slave device (ignoring that part of the DT for now).

Quoted 4 lines

I agree with Rob here. I won't require that you fix the driver but it would be better to have a proper DT binding from the beginning so that when the driver is fixed it will still work with the previous device trees.

No problem. I'll fix the driver. That's how it should be done.

What should be done with SECUREEDGE support?

Sergei Ianovich

author

2016-02-22 01:41 UTC #7 lore raw

PATCH v6 1/1 rtc: rewrite DS1302 using SPI

In reply to a message not in the archive

DS1302 is half-duplex SPI device. The driver respects this fact now.

Pin configurations should be implemented using SPI subsystem.

Signed-off-by Sergei Ianovich <[email protected]>

CC Alexandre Belloni <[email protected]>

CC Rob Herring <[email protected]>

---
v5..v6
* rewrite the driver as an SPI slave device
* use "maxim" for vendor name per Kconfig
* stop touching device RAM in device presence test
* only return time from device if valid
* use burst mode for reading/writing time
* droppped charging control. I cannot test it, and it looks broken

v4..v5
* drop THIS_MODULE from struct platform driver
* use "dallas" for vendor name per vendor-prefixes.txt

v3..v4
* move DTS bindings to a different patch

v2..v3
* use usleep_range instead of custom nsleep
* number change (07/16 -> 09/21)

v0..v2
* use device tree
* use devm helpers where possible

 .../devicetree/bindings/rtc/rtc-ds1302.txt         |  46 +++
 drivers/rtc/Kconfig                                |  15 +-
 drivers/rtc/rtc-ds1302.c                           | 348 ++++++++++-----------
 3 files changed, 212 insertions(+), 197 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/rtc/rtc-ds1302.txt

Documentation/devicetree/bindings/rtc/rtc-ds1302.txt new file +46 -0

new file mode 100644
index 0000000..b6c0973
@@ -0,0 +1,46 @@
+* Maxim/Dallas Semiconductor DS-1302 RTC
+
+Simple device which could be used to store date/time between reboots.
+
+The device uses the standard MicroWire half-duplex transfer timing.
+Master output is set on low clock and sensed by the RTC on the rising
+edge. Master input is set by the RTC on the trailing edge and is sensed
+by the master on low clock.
+
+Required properties:
+
+- compatible : Should be "maxim,rtc-ds1302"
+
+Required SPI properties:
+
+- reg : Should be address of the device chip select within
+  the controller.
+
+- spi-max-frequency : DS-1302 has 500 kHz if powered at 2.2V,
+  and 2MHz if powered at 5V.
+
+- spi-3wire : The device has a shared signal IN/OUT line.
+
+- spi-lsb-first : DS-1302 requires least significant bit first
+  transfers.
+
+- spi-cs-high: DS-1302 has active high chip select line. This is
+  required unless inverted in hardware.
+
+Example:
+
+spi0@901c {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	compatible = "icpdas,spi-lp8841-rtc";
+	reg = <0x901c 0x1>;
+
+	rtc@0 {
+		compatible = "maxim,rtc-ds1302";
+		reg = <0>;
+		spi-max-frequency = <500000>;
+		spi-3wire;
+		spi-lsb-first;
+		spi-cs-high;
+	};
+};

drivers/rtc/Kconfig +9 -6

index 2a52424..2e54aad 100644
@@ -646,6 +646,15 @@ 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

@@ -811,12 +820,6 @@ config RTC_DRV_DS1286
 	help
 	  If you say yes here you get support for the Dallas DS1286 RTC chips.
 
-config RTC_DRV_DS1302
-	tristate "Dallas DS1302"
-	depends on SH_SECUREEDGE5410
-	help
-	  If you say yes here you get support for the Dallas DS1302 RTC chips.
-
 config RTC_DRV_DS1511
 	tristate "Dallas DS1511"
 	depends on HAS_IOMEM

drivers/rtc/rtc-ds1302.c +157 ~~-191~~

396 lines not on this page · raw message

Signature · 1 line

2.6.3

Rob Herring

maintainer

2016-02-22 18:45 UTC #8 lore raw

Re: [PATCH v6] rtc: rewrite DS1302 using SPI

Quoted 45 lines · Sergei Ianovich

DS1302 is half-duplex SPI device. The driver respects this fact now.
Pin configurations should be implemented using SPI subsystem.
Signed-off-by Sergei Ianovich <[email protected]>
CC Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/[email protected]>
CC Rob Herring <[email protected]>
---
v5..v6
* rewrite the driver as an SPI slave device
* use "maxim" for vendor name per Kconfig
* stop touching device RAM in device presence test
* only return time from device if valid
* use burst mode for reading/writing time
* droppped charging control. I cannot test it, and it looks broken
v4..v5
* drop THIS_MODULE from struct platform driver
* use "dallas" for vendor name per vendor-prefixes.txt
v3..v4
* move DTS bindings to a different patch
v2..v3
* use usleep_range instead of custom nsleep
* number change (07/16 -> 09/21)
v0..v2
* use device tree
* use devm helpers where possible
 .../devicetree/bindings/rtc/rtc-ds1302.txt         |  46 +++
 drivers/rtc/Kconfig                                |  15 +-
 drivers/rtc/rtc-ds1302.c                           | 348 ++++++++++-----------
 3 files changed, 212 insertions(+), 197 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/rtc/rtc-ds1302.txt
Documentation/devicetree/bindings/rtc/rtc-ds1302.txt new file +2 -0
new file mode 100644
index 0000000..b6c0973
@@ -0,0 +1,46 @@
+* Maxim/Dallas Semiconductor DS-1302 RTC
+

Documentation/devicetree/bindings/rtc/rtc-ds1302.txt line 12

Quoted 10 lines

Documentation/devicetree/bindings/rtc/rtc-ds1302.txt new file +10 -0

+Simple device which could be used to store date/time between reboots.
+
+The device uses the standard MicroWire half-duplex transfer timing.
+Master output is set on low clock and sensed by the RTC on the rising
+edge. Master input is set by the RTC on the trailing edge and is sensed
+by the master on low clock.
+
+Required properties:
+
+- compatible : Should be "maxim,rtc-ds1302"

Just maxim,ds1032. RTC is implied by the part number and inline with existing dallas,ds1307.

Quoted 10 lines

Documentation/devicetree/bindings/rtc/rtc-ds1302.txt new file +10 -0

+
+Required SPI properties:
+
+- reg : Should be address of the device chip select within
+  the controller.
+
+- spi-max-frequency : DS-1302 has 500 kHz if powered at 2.2V,
+  and 2MHz if powered at 5V.
+
+- spi-3wire : The device has a shared signal IN/OUT line.

Documentation/devicetree/bindings/rtc/rtc-ds1302.txt line 32

Quoted 10 lines

Documentation/devicetree/bindings/rtc/rtc-ds1302.txt new file +10 -0

+
+- spi-lsb-first : DS-1302 requires least significant bit first
+  transfers.
+
+- spi-cs-high: DS-1302 has active high chip select line. This is
+  required unless inverted in hardware.
+
+Example:
+
+spi0@901c {

spi@...

Documentation/devicetree/bindings/rtc/rtc-ds1302.txt line 35

Quoted 3 lines

Documentation/devicetree/bindings/rtc/rtc-ds1302.txt new file +3 -0
+	#address-cells = <1>;
+	#size-cells = <0>;
+	compatible = "icpdas,spi-lp8841-rtc";

And this will need updating...

Documentation/devicetree/bindings/rtc/rtc-ds1302.txt line 46

Quoted 11 lines

Documentation/devicetree/bindings/rtc/rtc-ds1302.txt new file +11 -0

+	reg = <0x901c 0x1>;
+
+	rtc@0 {
+		compatible = "maxim,rtc-ds1302";
+		reg = <0>;
+		spi-max-frequency = <500000>;
+		spi-3wire;
+		spi-lsb-first;
+		spi-cs-high;
+	};
+};

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Sergei Ianovich

author

2016-02-23 10:54 UTC #9 lore raw

PATCH v7 1/1 rtc: rewrite DS1302 using SPI

In reply to Sergei Ianovich

DS1302 is half-duplex SPI device. The driver respects this fact now.

Pin configurations should be implemented using SPI subsystem.

Signed-off-by Sergei Ianovich <[email protected]>

CC Alexandre Belloni <[email protected]>

CC Rob Herring <[email protected]>

v6..v7
* change binding and doc file names

v5..v6
* rewrite the driver as an SPI slave device
* use "maxim" for vendor name per Kconfig
* stop changing device RAM in device presence test
* only return time from device if valid
* use burst mode for reading/writing time
* dropped charging control. I cannot test it, and it looks broken

v4..v5
* drop THIS_MODULE from struct platform driver
* use "dallas" for vendor name per vendor-prefixes.txt

v3..v4
* move DTS bindings to a different patch

v2..v3
* use usleep_range instead of custom nsleep
* number change (07/16 -> 09/21)

v0..v2
* use device tree
* use devm helpers where possible

---
 .../devicetree/bindings/rtc/maxim-ds1302.txt       |  46 +++
 drivers/rtc/Kconfig                                |  15 +-
 drivers/rtc/rtc-ds1302.c                           | 348 ++++++++++-----------
 3 files changed, 212 insertions(+), 197 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/rtc/maxim-ds1302.txt

Documentation/devicetree/bindings/rtc/maxim-ds1302.txt new file +46 -0

new file mode 100644
index 0000000..ba470c5
@@ -0,0 +1,46 @@
+* Maxim/Dallas Semiconductor DS-1302 RTC
+
+Simple device which could be used to store date/time between reboots.
+
+The device uses the standard MicroWire half-duplex transfer timing.
+Master output is set on low clock and sensed by the RTC on the rising
+edge. Master input is set by the RTC on the trailing edge and is sensed
+by the master on low clock.
+
+Required properties:
+
+- compatible : Should be "maxim,ds1302"
+
+Required SPI properties:
+
+- reg : Should be address of the device chip select within
+  the controller.
+
+- spi-max-frequency : DS-1302 has 500 kHz if powered at 2.2V,
+  and 2MHz if powered at 5V.
+
+- spi-3wire : The device has a shared signal IN/OUT line.
+
+- spi-lsb-first : DS-1302 requires least significant bit first
+  transfers.
+
+- spi-cs-high: DS-1302 has active high chip select line. This is
+  required unless inverted in hardware.
+
+Example:
+
+spi@901c {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	compatible = "icpdas,lp8841-spi-rtc";
+	reg = <0x901c 0x1>;
+
+	rtc@0 {
+		compatible = "maxim,ds1302";
+		reg = <0>;
+		spi-max-frequency = <500000>;
+		spi-3wire;
+		spi-lsb-first;
+		spi-cs-high;
+	};
+};

drivers/rtc/Kconfig +9 -6

index 376322f..e20e804 100644
@@ -646,6 +646,15 @@ 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

@@ -811,12 +820,6 @@ config RTC_DRV_DS1286
 	help
 	  If you say yes here you get support for the Dallas DS1286 RTC chips.
 
-config RTC_DRV_DS1302
-	tristate "Dallas DS1302"
-	depends on SH_SECUREEDGE5410
-	help
-	  If you say yes here you get support for the Dallas DS1302 RTC chips.
-
 config RTC_DRV_DS1511
 	tristate "Dallas DS1511"
 	depends on HAS_IOMEM

drivers/rtc/rtc-ds1302.c +157 ~~-191~~

396 lines not on this page · raw message

Signature · 1 line

2.7.0

Rob Herring

maintainer Acked-by on v7 1/1

2016-02-23 23:29 UTC #10 lore raw

Re: [PATCH v7] rtc: rewrite DS1302 using SPI

Quoted 30 lines · Sergei Ianovich

DS1302 is half-duplex SPI device. The driver respects this fact now.
Pin configurations should be implemented using SPI subsystem.
Signed-off-by Sergei Ianovich <[email protected]>
CC Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/[email protected]>
CC Rob Herring <[email protected]>
v6..v7
* change binding and doc file names
v5..v6
* rewrite the driver as an SPI slave device
* use "maxim" for vendor name per Kconfig
* stop changing device RAM in device presence test
* only return time from device if valid
* use burst mode for reading/writing time
* dropped charging control. I cannot test it, and it looks broken
v4..v5
* drop THIS_MODULE from struct platform driver
* use "dallas" for vendor name per vendor-prefixes.txt
v3..v4
* move DTS bindings to a different patch
v2..v3
* use usleep_range instead of custom nsleep
* number change (07/16 -> 09/21)

Quoted 5 lines

v0..v2
* use device tree
* use devm helpers where possible
---
 .../devicetree/bindings/rtc/maxim-ds1302.txt       |  46 +++

Acked-by Rob Herring <[email protected]>

Quoted 4 lines

 drivers/rtc/Kconfig                                |  15 +-
 drivers/rtc/rtc-ds1302.c                           | 348 ++++++++++-----------
 3 files changed, 212 insertions(+), 197 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/rtc/maxim-ds1302.txt

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Alexandre Belloni

2016-03-15 00:18 UTC #11 lore raw

Re: [PATCH v7] rtc: rewrite DS1302 using SPI

In reply to Sergei Ianovich

Hi,

Thank you for your work!

drivers/rtc/rtc-ds1302.c line 52

Quoted 13 lines · Sergei Ianovich

drivers/rtc/rtc-ds1302.c +0 ~~-13~~

-#ifdef CONFIG_SH_SECUREEDGE5410
-#include <asm/rtc.h>
-#include <mach/secureedge5410.h>
-
-#define	RTC_RESET	0x1000
-#define	RTC_IODATA	0x0800
-#define	RTC_SCLK	0x0400
-
-#define set_dp(x)	SECUREEDGE_WRITE_IOPORT(x, 0x1c00)
-#define get_dp()	SECUREEDGE_READ_IOPORT()
-#define ds1302_set_tx()
-#define ds1302_set_rx()
-

I would like to have a solution for secureedge5410 even if it is untested. Else, we are breaking an existing platform without any solution.

I've put the sh maintainers in copy, maybe they have an opinion. Else I'll let your patch sit in linux-next for the next cycle.

I have further cleanups in that driver but they can probably be done later.

Signature · 3 lines

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

Sergei Ianovich

author

2016-03-18 10:38 UTC #12 lore raw

Re: [PATCH v7] rtc: rewrite DS1302 using SPI

Quoted 6 lines · Alexandre Belloni

I would like to have a solution for secureedge5410 even if it is untested. Else, we are breaking an existing platform without any solution.
I've put the sh maintainers in copy, maybe they have an opinion. Else I'll let your patch sit in linux-next for the next cycle.

secureedge5410 will need an SPI host driver. The driver will be similar to the one I did for lp8841. I can make a clone for secureedge5410, but I cannot test it.

The only reason, I didn't file the patch for secureedge5410, is I thought SPI people won't accept an untested patch.

Alexandre Belloni

Applied

2016-03-28 20:57 UTC #13 lore raw

Re: [PATCH v7] rtc: rewrite DS1302 using SPI

In reply to Sergei Ianovich

Quoted 33 lines · Sergei Ianovich

DS1302 is half-duplex SPI device. The driver respects this fact now.
Pin configurations should be implemented using SPI subsystem.
Signed-off-by Sergei Ianovich <[email protected]>
CC Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/[email protected]>
CC Rob Herring <[email protected]>
v6..v7
* change binding and doc file names
v5..v6
* rewrite the driver as an SPI slave device
* use "maxim" for vendor name per Kconfig
* stop changing device RAM in device presence test
* only return time from device if valid
* use burst mode for reading/writing time
* dropped charging control. I cannot test it, and it looks broken
v4..v5
* drop THIS_MODULE from struct platform driver
* use "dallas" for vendor name per vendor-prefixes.txt
v3..v4
* move DTS bindings to a different patch
v2..v3
* use usleep_range instead of custom nsleep
* number change (07/16 -> 09/21)
v0..v2
* use device tree
* use devm helpers where possible

Quoted 7 lines

---
 .../devicetree/bindings/rtc/maxim-ds1302.txt       |  46 +++
 drivers/rtc/Kconfig                                |  15 +-
 drivers/rtc/rtc-ds1302.c                           | 348 ++++++++++-----------
 3 files changed, 212 insertions(+), 197 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/rtc/maxim-ds1302.txt

Applied, thanks.

Signature · 7 lines

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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html