Skip to contentSkip to conversation

da9063: Support for RTC and register definition updates

PATCH Applied Opensource [Steve Twiss] 3 participants 18 messages Mar 6, 2014 – Apr 11, 2014

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

cover da9063: Support for RTC and register definition updates

From: Opensource [Steve Twiss] <[email protected]>

This patch series updates the register definitions for the DA9063 PMIC and adds support for the DA9063 RTC.

- Changes to the DA9063 registers.h to support production silicon;
- Add a new RTC driver which is applicable to this version of the silicon;

Thank you,
Steve Twiss, Dialog Semiconductor Ltd.

S Twiss (2):
mfd: da9063: Upgrade of register definitions to support production
silicon
rtc: da9063: RTC driver

 drivers/rtc/Kconfig                  |   10 +
 drivers/rtc/Makefile                 |    1 +
 drivers/rtc/rtc-da9063.c             |  332 ++++++++++++++++++++++++++++++++++
 include/linux/mfd/da9063/registers.h |  120 ++++++------
 4 files changed, 405 insertions(+), 58 deletions(-)
 create mode 100644 drivers/rtc/rtc-da9063.c
Signature · 1 line
end-of-patch for PATCH V1
#1 lore raw

PATCH 1/2 mfd: da9063: Upgrade of register definitions to support production silicon

From: Opensource [Steve Twiss] <[email protected]>

This patch updates the register definitions for DA9063 to support the production silicon variant code ID (0x5). These changes are not backwards compatible with the previous register definitions and can only be used with the production variant of DA9063.

---
Checks performed with next-20140306/scripts/checkpatch.pl
registers.h total: 0 errors, 0 warnings, 1032 lines checked

A brief summary of the changes include:

- Introduction of a new DA9063_REG_ALARM_S register (now appearing at addr=0x46) allowing alarm second resolutions and which causes a shift in the register map for the RTC registers;
- Two new configuration registers DA9063_REG_CONFIG_M/N at 0x112 & 0x113;
- Modified register ranges for MON_REG_[1-6] which now appears at the addr=0x114 onwards;
- New register addresses for the general purpose registers GP_ID_[0-19] (now appearing at 0x121 onwards);
- Renaming of some definitions to match our hardware design conventions;
- There are also some bit-pattern additions that define some functionality alterations of the registers. One notable addition is:
DA9063_BUCK_SLOWSTART can also be found in the CONTROL_B register and enables a BUCK slow start (reduced inrush current; increased startup time);

This patch applies against kernel version linux-next next-20140306

Regards,
Steve Twiss, Dialog Semiconductor Ltd.

 include/linux/mfd/da9063/registers.h |  120 ++++++++++++++++++----------------
 1 file changed, 62 insertions(+), 58 deletions(-)
include/linux/mfd/da9063/registers.h +62 -58
index 5834813..09a85c6 100644
@@ -17,11 +17,7 @@
 #define	_DA9063_REG_H
 
 #define DA9063_I2C_PAGE_SEL_SHIFT	1
-
 #define	DA9063_EVENT_REG_NUM		4
-#define	DA9210_EVENT_REG_NUM		2
-#define	DA9063_EXT_EVENT_REG_NUM	(DA9063_EVENT_REG_NUM + \
-						DA9210_EVENT_REG_NUM)
 
 /* Page selection I2C or SPI always in the begining of any page. */
 /* Page 0 : I2C access 0x000 - 0x0FF	SPI access 0x000 - 0x07F */
@@ -61,9 +57,9 @@
 #define	DA9063_REG_GPIO_10_11		0x1A
 #define	DA9063_REG_GPIO_12_13		0x1B
 #define	DA9063_REG_GPIO_14_15		0x1C
-#define	DA9063_REG_GPIO_MODE_0_7	0x1D
-#define	DA9063_REG_GPIO_MODE_8_15	0x1E
-#define	DA9063_REG_GPIO_SWITCH_CONT	0x1F
+#define	DA9063_REG_GPIO_MODE0_7		0x1D
+#define	DA9063_REG_GPIO_MODE8_15	0x1E
+#define	DA9063_REG_SWITCH_CONT		0x1F
 
 /* Regulator Control Registers */
 #define	DA9063_REG_BCORE2_CONT		0x20
@@ -83,7 +79,7 @@
 #define	DA9063_REG_LDO9_CONT		0x2E
 #define	DA9063_REG_LDO10_CONT		0x2F
 #define	DA9063_REG_LDO11_CONT		0x30
-#define	DA9063_REG_VIB			0x31
+#define	DA9063_REG_SUPPLIES		0x31
 #define	DA9063_REG_DVC_1		0x32
 #define	DA9063_REG_DVC_2		0x33
 
@@ -97,9 +93,9 @@
 #define	DA9063_REG_ADCIN1_RES		0x3A
 #define	DA9063_REG_ADCIN2_RES		0x3B
 #define	DA9063_REG_ADCIN3_RES		0x3C
-#define	DA9063_REG_MON1_RES		0x3D
-#define	DA9063_REG_MON2_RES		0x3E
-#define	DA9063_REG_MON3_RES		0x3F
+#define	DA9063_REG_MON_A8_RES		0x3D
+#define	DA9063_REG_MON_A9_RES		0x3E
+#define	DA9063_REG_MON_A10_RES		0x3F
 
 /* RTC Calendar and Alarm Registers */
 #define	DA9063_REG_COUNT_S		0x40
@@ -108,15 +104,16 @@
 #define	DA9063_REG_COUNT_D		0x43
 #define	DA9063_REG_COUNT_MO		0x44
 #define	DA9063_REG_COUNT_Y		0x45
-#define	DA9063_REG_ALARM_MI		0x46
-#define	DA9063_REG_ALARM_H		0x47
-#define	DA9063_REG_ALARM_D		0x48
-#define	DA9063_REG_ALARM_MO		0x49
-#define	DA9063_REG_ALARM_Y		0x4A
-#define	DA9063_REG_SECOND_A		0x4B
-#define	DA9063_REG_SECOND_B		0x4C
-#define	DA9063_REG_SECOND_C		0x4D
-#define	DA9063_REG_SECOND_D		0x4E
+#define	DA9063_REG_ALARM_S		0x46
+#define	DA9063_REG_ALARM_MI		0x47
+#define	DA9063_REG_ALARM_H		0x48
+#define	DA9063_REG_ALARM_D		0x49
+#define	DA9063_REG_ALARM_MO		0x4A
+#define	DA9063_REG_ALARM_Y		0x4B
+#define	DA9063_REG_SECOND_A		0x4C
+#define	DA9063_REG_SECOND_B		0x4D
+#define	DA9063_REG_SECOND_C		0x4E
+#define	DA9063_REG_SECOND_D		0x4F
 
 /* Sequencer Control Registers */
 #define	DA9063_REG_SEQ			0x81
@@ -226,35 +223,37 @@
 #define	DA9063_REG_CONFIG_J		0x10F
 #define	DA9063_REG_CONFIG_K		0x110
 #define	DA9063_REG_CONFIG_L		0x111
-#define	DA9063_REG_MON_REG_1		0x112
-#define	DA9063_REG_MON_REG_2		0x113
-#define	DA9063_REG_MON_REG_3		0x114
-#define	DA9063_REG_MON_REG_4		0x115
-#define	DA9063_REG_MON_REG_5		0x116
-#define	DA9063_REG_MON_REG_6		0x117
-#define	DA9063_REG_TRIM_CLDR		0x118
-
+#define	DA9063_REG_CONFIG_M		0x112
+#define	DA9063_REG_CONFIG_N		0x113
+
+#define	DA9063_REG_MON_REG_1		0x114
+#define	DA9063_REG_MON_REG_2		0x115
+#define	DA9063_REG_MON_REG_3		0x116
+#define	DA9063_REG_MON_REG_4		0x117
+#define	DA9063_REG_MON_REG_5		0x11E
+#define	DA9063_REG_MON_REG_6		0x11F
+#define	DA9063_REG_TRIM_CLDR		0x120
 /* General Purpose Registers */
-#define	DA9063_REG_GP_ID_0		0x119
-#define	DA9063_REG_GP_ID_1		0x11A
-#define	DA9063_REG_GP_ID_2		0x11B
-#define	DA9063_REG_GP_ID_3		0x11C
-#define	DA9063_REG_GP_ID_4		0x11D
-#define	DA9063_REG_GP_ID_5		0x11E
-#define	DA9063_REG_GP_ID_6		0x11F
-#define	DA9063_REG_GP_ID_7		0x120
-#define	DA9063_REG_GP_ID_8		0x121
-#define	DA9063_REG_GP_ID_9		0x122
-#define	DA9063_REG_GP_ID_10		0x123
-#define	DA9063_REG_GP_ID_11		0x124
-#define	DA9063_REG_GP_ID_12		0x125
-#define	DA9063_REG_GP_ID_13		0x126
-#define	DA9063_REG_GP_ID_14		0x127
-#define	DA9063_REG_GP_ID_15		0x128
-#define	DA9063_REG_GP_ID_16		0x129
-#define	DA9063_REG_GP_ID_17		0x12A
-#define	DA9063_REG_GP_ID_18		0x12B
-#define	DA9063_REG_GP_ID_19		0x12C
+#define	DA9063_REG_GP_ID_0		0x121
+#define	DA9063_REG_GP_ID_1		0x122
+#define	DA9063_REG_GP_ID_2		0x123
+#define	DA9063_REG_GP_ID_3		0x124
+#define	DA9063_REG_GP_ID_4		0x125
+#define	DA9063_REG_GP_ID_5		0x126
+#define	DA9063_REG_GP_ID_6		0x127
+#define	DA9063_REG_GP_ID_7		0x128
+#define	DA9063_REG_GP_ID_8		0x129
+#define	DA9063_REG_GP_ID_9		0x12A
+#define	DA9063_REG_GP_ID_10		0x12B
+#define	DA9063_REG_GP_ID_11		0x12C
+#define	DA9063_REG_GP_ID_12		0x12D
+#define	DA9063_REG_GP_ID_13		0x12E
+#define	DA9063_REG_GP_ID_14		0x12F
+#define	DA9063_REG_GP_ID_15		0x130
+#define	DA9063_REG_GP_ID_16		0x131
+#define	DA9063_REG_GP_ID_17		0x132
+#define	DA9063_REG_GP_ID_18		0x133
+#define	DA9063_REG_GP_ID_19		0x134
 
 /* Chip ID and variant */
 #define	DA9063_REG_CHIP_ID		0x181
@@ -405,8 +404,10 @@
 /* DA9063_REG_CONTROL_B (addr=0x0F) */
 #define	DA9063_CHG_SEL				0x01
 #define	DA9063_WATCHDOG_PD			0x02
+#define	DA9063_RESET_BLINKING			0x04
 #define	DA9063_NRES_MODE			0x08
 #define	DA9063_NONKEY_LOCK			0x10
+#define	DA9063_BUCK_SLOWSTART			0x80
 
 /* DA9063_REG_CONTROL_C (addr=0x10) */
 #define	DA9063_DEBOUNCING_MASK			0x07
@@ -466,6 +467,7 @@
 #define	DA9063_GPADC_PAUSE			0x02
 #define	DA9063_PMIF_DIS				0x04
 #define	DA9063_HS2WIRE_DIS			0x08
+#define	DA9063_CLDR_PAUSE			0x10
 #define	DA9063_BBAT_DIS				0x20
 #define	DA9063_OUT_32K_PAUSE			0x40
 #define	DA9063_PMCONT_DIS			0x80
@@ -660,7 +662,7 @@
 #define		DA9063_GPIO15_TYPE_GPO		0x04
 #define	DA9063_GPIO15_NO_WAKEUP			0x80
 
-/* DA9063_REG_GPIO_MODE_0_7 (addr=0x1D) */
+/* DA9063_REG_GPIO_MODE0_7 (addr=0x1D) */
 #define	DA9063_GPIO0_MODE			0x01
 #define	DA9063_GPIO1_MODE			0x02
 #define	DA9063_GPIO2_MODE			0x04
@@ -670,7 +672,7 @@
 #define	DA9063_GPIO6_MODE			0x40
 #define	DA9063_GPIO7_MODE			0x80
 
-/* DA9063_REG_GPIO_MODE_8_15 (addr=0x1E) */
+/* DA9063_REG_GPIO_MODE8_15 (addr=0x1E) */
 #define	DA9063_GPIO8_MODE			0x01
 #define	DA9063_GPIO9_MODE			0x02
 #define	DA9063_GPIO10_MODE			0x04
@@ -702,12 +704,12 @@
 #define		DA9063_SWITCH_SR_5MV		0x10
 #define		DA9063_SWITCH_SR_10MV		0x20
 #define		DA9063_SWITCH_SR_50MV		0x30
-#define	DA9063_SWITCH_SR_DIS			0x40
+#define	DA9063_CORE_SW_INTERNAL			0x40
 #define	DA9063_CP_EN_MODE			0x80
 
 /* DA9063_REGL_Bxxxx_CONT common bits (addr=0x20-0x25) */
 #define	DA9063_BUCK_EN				0x01
-#define DA9063_BUCK_GPI_MASK			0x06
+#define	DA9063_BUCK_GPI_MASK			0x06
 #define		DA9063_BUCK_GPI_OFF		0x00
 #define		DA9063_BUCK_GPI_GPIO1		0x02
 #define		DA9063_BUCK_GPI_GPIO2		0x04
@@ -841,25 +843,27 @@
 #define DA9063_COUNT_YEAR_MASK			0x3F
 #define DA9063_MONITOR				0x40
 
-/* DA9063_REG_ALARM_MI (addr=0x46) */
+/* DA9063_REG_ALARM_S (addr=0x46) */
+#define DA9063_ALARM_S_MASK			0x3F
 #define DA9063_ALARM_STATUS_ALARM		0x80
 #define DA9063_ALARM_STATUS_TICK		0x40
+/* DA9063_REG_ALARM_MI (addr=0x47) */
 #define DA9063_ALARM_MIN_MASK			0x3F
 
-/* DA9063_REG_ALARM_H (addr=0x47) */
+/* DA9063_REG_ALARM_H (addr=0x48) */
 #define DA9063_ALARM_HOUR_MASK			0x1F
 
-/* DA9063_REG_ALARM_D (addr=0x48) */
+/* DA9063_REG_ALARM_D (addr=0x49) */
 #define DA9063_ALARM_DAY_MASK			0x1F
 
-/* DA9063_REG_ALARM_MO (addr=0x49) */
+/* DA9063_REG_ALARM_MO (addr=0x4A) */
 #define DA9063_TICK_WAKE			0x20
 #define DA9063_TICK_TYPE			0x10
 #define		DA9063_TICK_TYPE_SEC		0x00
 #define		DA9063_TICK_TYPE_MIN		0x10
 #define DA9063_ALARM_MONTH_MASK			0x0F
 
-/* DA9063_REG_ALARM_Y (addr=0x4A) */
+/* DA9063_REG_ALARM_Y (addr=0x4B) */
 #define DA9063_TICK_ON				0x80
 #define DA9063_ALARM_ON				0x40
 #define DA9063_ALARM_YEAR_MASK			0x3F
@@ -906,7 +910,7 @@
 
 /* DA9063_REG_Bxxxx_CFG common bits (addr=0x9D-0xA2) */
 #define DA9063_BUCK_FB_MASK			0x07
-#define DA9063_BUCK_PD_DIS_SHIFT		5
+#define DA9063_BUCK_PD_DIS_MASK		0x20
 #define DA9063_BUCK_MODE_MASK			0xC0
 #define		DA9063_BUCK_MODE_MANUAL		0x00
 #define		DA9063_BUCK_MODE_SLEEP		0x40
Signature · 1 line
end-of-patch for PATCH V1
#2 lore raw

Re: [PATCH V1 1/2] mfd: da9063: Upgrade of register definitions to support production silicon

Quoted 29 lines

From: Opensource [Steve Twiss] <[email protected]>

This patch updates the register definitions for DA9063 to support the production silicon variant code ID (0x5). These changes are not backwards compatible with the previous register definitions and can only be used with the production variant of DA9063.

---
Checks performed with next-20140306/scripts/checkpatch.pl
registers.h total: 0 errors, 0 warnings, 1032 lines checked

A brief summary of the changes include:

- Introduction of a new DA9063_REG_ALARM_S register (now appearing at addr=0x46) allowing alarm second resolutions and which causes a shift in the register map for the RTC registers;
- Two new configuration registers DA9063_REG_CONFIG_M/N at 0x112 & 0x113;
- Modified register ranges for MON_REG_[1-6] which now appears at the addr=0x114 onwards;
- New register addresses for the general purpose registers GP_ID_[0-19] (now appearing at 0x121 onwards);
- Renaming of some definitions to match our hardware design conventions;
- There are also some bit-pattern additions that define some functionality alterations of the registers. One notable addition is:
DA9063_BUCK_SLOWSTART can also be found in the CONTROL_B register and enables a BUCK slow start (reduced inrush current; increased startup time);

Quoted 4 lines

This patch applies against kernel version linux-next next-20140306

 include/linux/mfd/da9063/registers.h |  120 ++++++++++++++++++----------------
 1 file changed, 62 insertions(+), 58 deletions(-)

What's the difference between this patch and the one you sent 2 days ago?

Signature · 4 lines
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
#3 lore raw

RE: [PATCH V1 1/2] mfd: da9063: Upgrade of register definitions to support production silicon

Quoted 34 lines

From: Lee Jones [mailto:[email protected]]
Sent: 07 March 2014 03:32

Quoted 29 lines

From: Opensource [Steve Twiss] <[email protected]>

This patch updates the register definitions for DA9063 to support the production silicon variant code ID (0x5). These changes are not backwards compatible with the previous register definitions and can only be used with the production variant of DA9063.

---
Checks performed with next-20140306/scripts/checkpatch.pl
registers.h total: 0 errors, 0 warnings, 1032 lines checked

A brief summary of the changes include:

- Introduction of a new DA9063_REG_ALARM_S register (now appearing at addr=0x46) allowing alarm second resolutions and which causes a shift in the register map for the RTC registers;
- Two new configuration registers DA9063_REG_CONFIG_M/N at 0x112 & 0x113;
- Modified register ranges for MON_REG_[1-6] which now appears at the addr=0x114 onwards;
- New register addresses for the general purpose registers GP_ID_[0-19] (now appearing at 0x121 onwards);
- Renaming of some definitions to match our hardware design conventions;
- There are also some bit-pattern additions that define some functionality alterations of the registers. One notable addition is:
DA9063_BUCK_SLOWSTART can also be found in the CONTROL_B register and enables a BUCK slow start (reduced inrush current; increased startup time);

Quoted 8 lines
Quoted 4 lines

This patch applies against kernel version linux-next next-20140306

 include/linux/mfd/da9063/registers.h |  120 ++++++++++++++++++----------------
 1 file changed, 62 insertions(+), 58 deletions(-)

What's the difference between this patch and the one you sent 2 days ago?

Hi Lee,

There's no difference in the patch for the registers.h.

I resent the whole patch set and renamed it from RFC to PATCH after making the changes requested by Alessandro in the RTC driver.

Regards,
Steve ���{.n�+�������+%�����ݶ��w��{.n�+����{��G�����{ay�ʇڙ�,j��f���h��������z_�(�階�ݢj"���m������G������?����&���~��iO��z��v�^�m���� ������?�I�

Applied
#4 lore raw

Re: [PATCH V1 1/2] mfd: da9063: Upgrade of register definitions to support production silicon

In reply to Opensource [Steve Twiss]
Quoted 29 lines

From: Opensource [Steve Twiss] <[email protected]>

This patch updates the register definitions for DA9063 to support the production silicon variant code ID (0x5). These changes are not backwards compatible with the previous register definitions and can only be used with the production variant of DA9063.

---
Checks performed with next-20140306/scripts/checkpatch.pl
registers.h total: 0 errors, 0 warnings, 1032 lines checked

A brief summary of the changes include:

- Introduction of a new DA9063_REG_ALARM_S register (now appearing at addr=0x46) allowing alarm second resolutions and which causes a shift in the register map for the RTC registers;
- Two new configuration registers DA9063_REG_CONFIG_M/N at 0x112 & 0x113;
- Modified register ranges for MON_REG_[1-6] which now appears at the addr=0x114 onwards;
- New register addresses for the general purpose registers GP_ID_[0-19] (now appearing at 0x121 onwards);
- Renaming of some definitions to match our hardware design conventions;
- There are also some bit-pattern additions that define some functionality alterations of the registers. One notable addition is:
DA9063_BUCK_SLOWSTART can also be found in the CONTROL_B register and enables a BUCK slow start (reduced inrush current; increased startup time);

Quoted 2 lines
 include/linux/mfd/da9063/registers.h |  120 ++++++++++++++++++----------------
 1 file changed, 62 insertions(+), 58 deletions(-)

Well, as this doesn't seem to cause any issues when building and I'm going to guess that the other patch in the set won't be a problem (as you didn't send it to me, so I'm gussing it's insignificant), I'll apply the patch.

Applied, thanks.

Signature · 4 lines
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
#5 lore raw

RE: [PATCH V1 1/2] mfd: da9063: Upgrade of register definitions to support production silicon

Quoted 32 lines · Lee Jones
Quoted 29 lines

From: Opensource [Steve Twiss] <[email protected]>

This patch updates the register definitions for DA9063 to support the production silicon variant code ID (0x5). These changes are not backwards compatible with the previous register definitions and can only be used with the production variant of DA9063.

---
Checks performed with next-20140306/scripts/checkpatch.pl
registers.h total: 0 errors, 0 warnings, 1032 lines checked

A brief summary of the changes include:

- Introduction of a new DA9063_REG_ALARM_S register (now appearing at addr=0x46) allowing alarm second resolutions and which causes a shift in the register map for the RTC registers;
- Two new configuration registers DA9063_REG_CONFIG_M/N at 0x112 & 0x113;
- Modified register ranges for MON_REG_[1-6] which now appears at the addr=0x114 onwards;
- New register addresses for the general purpose registers GP_ID_[0-19] (now appearing at 0x121 onwards);
- Renaming of some definitions to match our hardware design conventions;
- There are also some bit-pattern additions that define some functionality alterations of the registers. One notable addition is:
DA9063_BUCK_SLOWSTART can also be found in the CONTROL_B register and enables a BUCK slow start (reduced inrush current; increased startup time);

Quoted 2 lines
 include/linux/mfd/da9063/registers.h |  120 ++++++++++++++++++----------------
 1 file changed, 62 insertions(+), 58 deletions(-)
Quoted 6 lines

Well, as this doesn't seem to cause any issues when building and I'm going to guess that the other patch in the set won't be a problem (as you didn't send it to me, so I'm gussing it's insignificant), I'll apply the patch.

Applied, thanks.

Hi Lee,

Thanks for this.

It looks like made a mess of the To: and Cc: e-mail list in my submission patches for this one. The second patch (the RTC driver) should have been CC'ed to you also.
Sorry. I will try to get my e-mail lists in order for my next submission.

The RTC driver component relies on the register change patch which you just applied. This RTC component was reviewed and Ack'ed by Alessandro Zummo here:
http://www.kernelhub.org/?p=2&msg=427642

There was no way for you to know any of this because I had not CC'ed you properly on this part.

It is possible to add the RTC component as well or shall I resend that part again?

Regards,
Steve ���{.n�+�������+%�����ݶ��w��{.n�+����{��G�����{ay�ʇڙ�,j��f���h��������z_�(�階�ݢj"���m������G������?����&���~��iO��z��v�^�m���� ������?�I�

#6 lore raw

Re: [PATCH V1 1/2] mfd: da9063: Upgrade of register definitions to support production silicon

Quoted 53 lines
Quoted 32 lines
Quoted 29 lines

From: Opensource [Steve Twiss] <[email protected]>

This patch updates the register definitions for DA9063 to support the production silicon variant code ID (0x5). These changes are not backwards compatible with the previous register definitions and can only be used with the production variant of DA9063.

---
Checks performed with next-20140306/scripts/checkpatch.pl
registers.h total: 0 errors, 0 warnings, 1032 lines checked

A brief summary of the changes include:

- Introduction of a new DA9063_REG_ALARM_S register (now appearing at addr=0x46) allowing alarm second resolutions and which causes a shift in the register map for the RTC registers;
- Two new configuration registers DA9063_REG_CONFIG_M/N at 0x112 & 0x113;
- Modified register ranges for MON_REG_[1-6] which now appears at the addr=0x114 onwards;
- New register addresses for the general purpose registers GP_ID_[0-19] (now appearing at 0x121 onwards);
- Renaming of some definitions to match our hardware design conventions;
- There are also some bit-pattern additions that define some functionality alterations of the registers. One notable addition is:
DA9063_BUCK_SLOWSTART can also be found in the CONTROL_B register and enables a BUCK slow start (reduced inrush current; increased startup time);

Quoted 2 lines
 include/linux/mfd/da9063/registers.h |  120 ++++++++++++++++++----------------
 1 file changed, 62 insertions(+), 58 deletions(-)
Quoted 6 lines

Well, as this doesn't seem to cause any issues when building and I'm going to guess that the other patch in the set won't be a problem (as you didn't send it to me, so I'm gussing it's insignificant), I'll apply the patch.

Applied, thanks.

Hi Lee,

Thanks for this.

It looks like made a mess of the To: and Cc: e-mail list in my submission patches for this one. The second patch (the RTC driver) should have been CC'ed to you also.
Sorry. I will try to get my e-mail lists in order for my next submission.

The RTC driver component relies on the register change patch which you just applied. This RTC component was reviewed and Ack'ed by Alessandro Zummo here:
http://www.kernelhub.org/?p=2&msg=427642

Quoted 5 lines

There was no way for you to know any of this because I had not CC'ed you properly on this part.

It is possible to add the RTC component as well or shall I resend that part again?

It needs to be in my inbox for me to apply it.

Can you send it again with Alessandro and my Acks applied please?

Signature · 4 lines
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
#7 lore raw

PATCH 2/2 rtc: da9063: RTC driver

In reply to Opensource [Steve Twiss]

From: Opensource [Steve Twiss] <[email protected]>

Add the RTC driver for DA9063.

---
Checks performed with next-20140306/scripts/checkpatch.pl

 Kconfig                   total: 0 errors, 21 warnings, 1344 lines checked
 Makefile                  total: 0 errors, 0 warnings, 139 lines checked
 rtc-da9063.c              total: 0 errors, 0 warnings, 332 lines checked

Although there are 21 warnings in Kconfig, these do not apply to the changes made in this patch set.

Change History:

Changes made to this driver since previous RFC V1 Comments by Alessandro Zummo
- http://www.kernelhub.org/?p=2&msg=426327
- Use return PTR_ERR(rtc->rtc_dev); instead of goto err; return err.
- Request the interrupt before the RTC device is registered with the call to devm_rtc_device_register.

Dependencies:

This driver requires the register changes associated with this patch set. It requires the changes made to registers.h and in particular, the new register DA9063_REG_ALARM_S (now appearing at addr=0x46) and DA9063_ALARM_S_MASK 0x3F are required to allow the triggering of alarms down to the second resolution level.

This patch applies against kernel version linux-next next-20140306

Regards,
Steve Twiss, Dialog Semiconductor Ltd.

 drivers/rtc/Kconfig      |   10 ++
 drivers/rtc/Makefile     |    1 +
 drivers/rtc/rtc-da9063.c |  332 ++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 343 insertions(+)
 create mode 100644 drivers/rtc/rtc-da9063.c
drivers/rtc/Kconfig +10 -0
index db933de..472a5b9 100644
@@ -746,6 +746,16 @@ config RTC_DRV_DA9055
 	  This driver can also be built as a module. If so, the module
 	  will be called rtc-da9055
 
+config RTC_DRV_DA9063
+	tristate "Dialog Semiconductor DA9063 RTC"
+	depends on MFD_DA9063
+	help
+	  If you say yes here you will get support for the RTC subsystem
+	  of the Dialog Semiconductor DA9063.
+
+	  This driver can also be built as a module. If so, the module
+	  will be called "rtc-da9063".
+
 config RTC_DRV_EFI
 	tristate "EFI RTC"
 	depends on IA64
drivers/rtc/Makefile +1 -0
index b427bf7..4a4fed9 100644
@@ -32,6 +32,7 @@ obj-$(CONFIG_RTC_DRV_CMOS)	+= rtc-cmos.o
 obj-$(CONFIG_RTC_DRV_COH901331)	+= rtc-coh901331.o
 obj-$(CONFIG_RTC_DRV_DA9052)	+= rtc-da9052.o
 obj-$(CONFIG_RTC_DRV_DA9055)	+= rtc-da9055.o
+obj-$(CONFIG_RTC_DRV_DA9063)	+= rtc-da9063.o
 obj-$(CONFIG_RTC_DRV_DAVINCI)	+= rtc-davinci.o
 obj-$(CONFIG_RTC_DRV_DM355EVM)	+= rtc-dm355evm.o
 obj-$(CONFIG_RTC_DRV_VRTC)	+= rtc-mrst.o
drivers/rtc/rtc-da9063.c new file +332 -0

332 lines not on this page · raw message

Signature · 1 line
end-of-patch for PATCH V1
Acked-by on v1 2/2
#8 lore raw

Re: [PATCH V1 2/2] rtc: da9063: RTC driver

Quoted 8 lines · On Thu, 6 Mar 2014 16:40:02 +0000 "Opensource [Steve Twiss]"…

Change History:

Changes made to this driver since previous RFC V1 Comments by Alessandro Zummo
- http://www.kernelhub.org/?p=2&msg=426327
- Use return PTR_ERR(rtc->rtc_dev); instead of goto err; return err.
- Request the interrupt before the RTC device is registered with the call to devm_rtc_device_register.

Signature · 6 lines
 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it
#9 lore raw

RE: [PATCH V1 2/2] rtc: da9063: RTC driver

Quoted 17 lines

From: Alessandro Zummo [mailto:[email protected]]
Sent: 07 March 2014 09:33

Quoted 8 lines · On Thu, 6 Mar 2014 16:40:02 +0000 "Opensource [Steve Twiss]"…

Change History:

Changes made to this driver since previous RFC V1 Comments by Alessandro Zummo
- http://www.kernelhub.org/?p=2&msg=426327
- Use return PTR_ERR(rtc->rtc_dev); instead of goto err; return err.
- Request the interrupt before the RTC device is registered with the call to devm_rtc_device_register.

Quoted 2 lines

Thank you.
Regards,
Steve

#10 lore raw

RE: [PATCH V1 2/2] rtc: da9063: RTC driver

In reply to Alessandro Zummo

On 07 March 2014 09:33, Alessandro Zummo wrote,

Quoted 10 lines
Quoted 7 lines · On Thu, 6 Mar 2014 16:40:02 +0000 "Opensource [Steve Twiss]"…

Change History:
Changes made to this driver since previous RFC V1 Comments by Alessandro Zummo
- http://www.kernelhub.org/?p=2&msg=426327
- Use return PTR_ERR(rtc->rtc_dev); instead of goto err; return err.
- Request the interrupt before the RTC device is registered with the call to devm_rtc_device_register.

Hi Alessandro,

Is it possible to merge my RTC patch so it appears in linux-next please?

You originally Acked it around 1 month ago
https://lkml.org/lkml/2014/3/7/112

But I've been unable to get it merged because that part needs your consent.
https://lkml.org/lkml/2014/3/25/240

Regards,
Steve

Quoted 8 lines

--

Best regards,

Alessandro Zummo,
Tower Technologies - Torino, Italy

http://www.towertech.it

#11 lore raw

Re: [PATCH V1 2/2] rtc: da9063: RTC driver

Quoted 4 lines · On Fri, 11 Apr 2014 11:45:33 +0000 "Opensource [Steve Twiss]"…

Is it possible to merge my RTC patch so it appears in linux-next please?

You originally Acked it around 1 month ago
https://lkml.org/lkml/2014/3/7/112

Please send me (cc to the list) the whole patchset. thanks!

Signature · 6 lines
 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it
#12 lore raw

Re: [RESEND] [PATCH V1 2/2] rtc: da9063: RTC driver

In reply to Opensource [Steve Twiss]
Quoted 7 lines

From: Opensource [Steve Twiss] <[email protected]>

Add the RTC driver for DA9063.

How could I have Acked a patch that I've never seen?

<snip>

Quoted 9 lines

The original patch is here:
- https://lkml.org/lkml/2014/3/6/346

This patch resend is identical to the original patch, except it adds the Acked-by: line from Alessandro Zummo, previously provided here:
- https://lkml.org/lkml/2014/3/7/112

Also, it adds an Acked-by line on behalf of Lee Jones, as requested:
- https://lkml.org/lkml/2014/3/10/369

Ah, no. I meant send the set with my Ack applied to the patch I actually reviewed.

Alessandro,
Are you happy for me to take this set through the MFD tree and send you a pull-request for an immutable branch?

Signature · 4 lines
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
#13 lore raw

RE: [RESEND] [PATCH V1 2/2] rtc: da9063: RTC driver

Quoted 21 lines · Lee Jones

Subject: Re: [RESEND] [PATCH V1 2/2] rtc: da9063: RTC driver

Quoted 7 lines

From: Opensource [Steve Twiss] <[email protected]>

Add the RTC driver for DA9063.

How could I have Acked a patch that I've never seen?

<snip>

Quoted 7 lines

The original patch is here:
- https://lkml.org/lkml/2014/3/6/346

This patch resend is identical to the original patch, except it adds the Acked-by: line from Alessandro Zummo, previously provided here:
- https://lkml.org/lkml/2014/3/7/112

Quoted 5 lines
Quoted 2 lines

Also, it adds an Acked-by line on behalf of Lee Jones, as requested:
- https://lkml.org/lkml/2014/3/10/369

Ah, no. I meant send the set with my Ack applied to the patch I actually reviewed.

Oh, no! I'm sorry about that.
I completely misunderstood.

Quoted 4 lines

Alessandro,
Are you happy for me to take this set through the MFD tree and send you a pull-request for an immutable branch?

Alessandro & Lee,
Please accept my apology on this one, I've really messed things up on this patch set.

Regards,
Steve ���{.n�+�������+%�����ݶ��w��{.n�+����{��G�����{ay�ʇڙ�,j��f���h��������z_�(�階�ݢj"���m������G������?����&���~��iO��z��v�^�m���� ������?�I�

#14 lore raw

RE: [RESEND] [PATCH V1 2/2] rtc: da9063: RTC driver

In reply to Lee Jones

Hi Alessandro,

Just over a week ago I sent a patch for the rtc: da9063: RTC driver file that added RTC support for the DA9063 currently in the kernel.

I'm not sure if it may have been missed in your inbox
https://lkml.org/lkml/2014/3/11/230

The RTC patch was previously Acked by you here:
https://lkml.org/lkml/2014/3/7/112

Quoted 23 lines · Lee Jones

Subject: Re: [RESEND] [PATCH V1 2/2] rtc: da9063: RTC driver

Quoted 7 lines

From: Opensource [Steve Twiss] <[email protected]>

Add the RTC driver for DA9063.

How could I have Acked a patch that I've never seen?

<snip>

Quoted 9 lines

The original patch is here:
- https://lkml.org/lkml/2014/3/6/346

This patch resend is identical to the original patch, except it adds the Acked-by: line from Alessandro Zummo, previously provided here:
- https://lkml.org/lkml/2014/3/7/112

Also, it adds an Acked-by line on behalf of Lee Jones, as requested:
- https://lkml.org/lkml/2014/3/10/369

Quoted 7 lines

Ah, no. I meant send the set with my Ack applied to the patch I actually reviewed.

Alessandro,
Are you happy for me to take this set through the MFD tree and send you a pull-request for an immutable branch?

I believe that I made a mess of the resend and Ack'ed when I shouldn't have on Lee Jones's behalf -- but then there was a reply from Lee who suggested that he could take the patch through despite this. I think that was his intention.
(Lee: I hope I am not stepping outside the line again!)

If you have time to quickly take another look at this, then I would appreciate that.

Thank you,
Steve ���{.n�+�������+%�����ݶ��w��{.n�+����{��G�����{ay�ʇڙ�,j��f���h��������z_�(�階�ݢj"���m������G������?����&���~��iO��z��v�^�m���� ������?�I�

#15 lore raw

RE: [RESEND] [PATCH V1 2/2] rtc: da9063: RTC driver

In reply to Lee Jones

Hi Lee,

I realise that you and Alessandro are very busy (I have not often seen Alessandro do any posting in the past fortnight), but a couple of weeks ago I sent an RTC patch set with register.h changes ...

Quoted 3 lines
Quoted 3 lines

From: Opensource [Steve Twiss] <[email protected]>

Add the RTC driver for DA9063.

<snip>

Quoted 2 lines
Quoted 2 lines

The original patch is here:
- https://lkml.org/lkml/2014/3/6/346

I believe you applied the first half of my alterations here:
https://lkml.org/lkml/2014/3/6/348
https://lkml.org/lkml/2014/3/10/369

And the other half, was Acked by Alessandro Zummo here:
https://lkml.org/lkml/2014/3/7/112

Quoted 5 lines · Lee Jones

Alessandro,
Are you happy for me to take this set through the MFD tree and send you a pull-request for an immutable branch?

There was a suggestion that this RTC patch could be taken through by you? Can I ask if this still an option please?

I tried to contact Alessandro after about 1 week, but I guess that other things are getting in the way and I have not had a reply.
https://lkml.org/lkml/2014/3/21/248

The reason I ask -- is because I have several patches waiting to add support for an older variant of the silicon, but in order to send those changes I will need to patch the pending RTC with the updates.

Regards,
Steve

���{.n�+�������+%�����ݶ��w��{.n�+����{��G�����{ay�ʇڙ�,j��f���h��������z_�(�階�ݢj"���m������G������?����&���~��iO��z��v�^�m���� ������?�I�

#16 lore raw

Re: [RESEND] [PATCH V1 2/2] rtc: da9063: RTC driver

Quoted 28 lines

I realise that you and Alessandro are very busy (I have not often seen Alessandro do any posting in the past fortnight), but a couple of weeks ago I sent an RTC patch set with register.h changes ...

Quoted 3 lines
Quoted 3 lines

From: Opensource [Steve Twiss] <[email protected]>

Add the RTC driver for DA9063.

<snip>

Quoted 2 lines
Quoted 2 lines

The original patch is here:
- https://lkml.org/lkml/2014/3/6/346

I believe you applied the first half of my alterations here:
https://lkml.org/lkml/2014/3/6/348
https://lkml.org/lkml/2014/3/10/369

And the other half, was Acked by Alessandro Zummo here:
https://lkml.org/lkml/2014/3/7/112

Quoted 5 lines · Lee Jones

Alessandro,
Are you happy for me to take this set through the MFD tree and send you a pull-request for an immutable branch?

There was a suggestion that this RTC patch could be taken through by you? Can I ask if this still an option please?

Quoted 7 lines

I tried to contact Alessandro after about 1 week, but I guess that other things are getting in the way and I have not had a reply.
https://lkml.org/lkml/2014/3/21/248

The reason I ask -- is because I have several patches waiting to add support for an older variant of the silicon, but in order to send those changes I will need to patch the pending RTC with the updates.

I can't really take the RTC patches without Alessandro's consent. Besides, the merge window is going to open in about a week. I'm sorry to say this, but I think this set is best left for v3.16 now. That also gives Alessandro a while to reply properly.

Signature · 4 lines
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
#17 lore raw

RE: [RESEND] [PATCH V1 2/2] rtc: da9063: RTC driver

Quoted 32 lines
Quoted 32 lines

I realise that you and Alessandro are very busy (I have not often seen Alessandro do any posting in the past fortnight), but a couple of weeks ago I sent an RTC patch set with register.h changes ...

Quoted 3 lines
Quoted 3 lines

From: Opensource [Steve Twiss] <[email protected]>

Add the RTC driver for DA9063.

<snip>

Quoted 2 lines
Quoted 2 lines

The original patch is here:
- https://lkml.org/lkml/2014/3/6/346

I believe you applied the first half of my alterations here:
https://lkml.org/lkml/2014/3/6/348
https://lkml.org/lkml/2014/3/10/369

And the other half, was Acked by Alessandro Zummo here:
https://lkml.org/lkml/2014/3/7/112

Quoted 5 lines · Lee Jones

Alessandro,
Are you happy for me to take this set through the MFD tree and send you a pull-request for an immutable branch?

There was a suggestion that this RTC patch could be taken through by you? Can I ask if this still an option please?

I tried to contact Alessandro after about 1 week, but I guess that other things are getting in the way and I have not had a reply.
https://lkml.org/lkml/2014/3/21/248

Quoted 9 lines
Quoted 3 lines

The reason I ask -- is because I have several patches waiting to add support for an older variant of the silicon, but in order to send those changes I will need to patch the pending RTC with the updates.

I can't really take the RTC patches without Alessandro's consent. Besides, the merge window is going to open in about a week. I'm sorry to say this, but I think this set is best left for v3.16 now. That also gives Alessandro a while to reply properly.

Okay, thanks ���{.n�+�������+%�����ݶ��w��{.n�+����{��G�����{ay�ʇڙ�,j��f���h��������z_�(�階�ݢj"���m������G������?����&���~��iO��z��v�^�m���� ������?�I�