da9063: Support for RTC and register definition updates
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
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
@@ -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
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.Signed-off-by Opensource [Steve Twiss] <[email protected]>---
Checks performed withnext-20140306/scripts/checkpatch.pl
registers.htotal: 0 errors, 0 warnings, 1032 lines checkedA brief summary of the changes include:
- Introduction of a new
DA9063_REG_ALARM_Sregister (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 at0x112&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 at0x121onwards);
- 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_SLOWSTARTcan also be found in theCONTROL_Bregister 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
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:32Quoted 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.Signed-off-by Opensource [Steve Twiss] <[email protected]>---
Checks performed withnext-20140306/scripts/checkpatch.pl
registers.htotal: 0 errors, 0 warnings, 1032 lines checkedA brief summary of the changes include:
- Introduction of a new
DA9063_REG_ALARM_Sregister (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 at0x112&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 at0x121onwards);
- 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_SLOWSTARTcan also be found in theCONTROL_Bregister 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�
Lee Jones
AppliedRe: [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.Signed-off-by Opensource [Steve Twiss] <[email protected]>---
Checks performed withnext-20140306/scripts/checkpatch.pl
registers.htotal: 0 errors, 0 warnings, 1032 lines checkedA brief summary of the changes include:
- Introduction of a new
DA9063_REG_ALARM_Sregister (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 at0x112&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 at0x121onwards);
- 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_SLOWSTARTcan also be found in theCONTROL_Bregister 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
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.Signed-off-by Opensource [Steve Twiss] <[email protected]>---
Checks performed withnext-20140306/scripts/checkpatch.pl
registers.htotal: 0 errors, 0 warnings, 1032 lines checkedA brief summary of the changes include:
- Introduction of a new
DA9063_REG_ALARM_Sregister (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 at0x112&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 at0x121onwards);
- 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_SLOWSTARTcan also be found in theCONTROL_Bregister 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�
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.Signed-off-by Opensource [Steve Twiss] <[email protected]>---
Checks performed withnext-20140306/scripts/checkpatch.pl
registers.htotal: 0 errors, 0 warnings, 1032 lines checkedA brief summary of the changes include:
- Introduction of a new
DA9063_REG_ALARM_Sregister (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 at0x112&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 at0x121onwards);
- 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_SLOWSTARTcan also be found in theCONTROL_Bregister 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
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
@@ -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
@@ -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
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 returnPTR_ERR(rtc->rtc_dev); instead of goto err; return err.
- Request the interrupt before the RTC device is registered with the call todevm_rtc_device_register.
Signature · 6 lines
Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
RE: [PATCH V1 2/2] rtc: da9063: RTC driver
Quoted 17 lines
From: Alessandro Zummo [mailto:[email protected]]
Sent: 07 March 2014 09:33Quoted 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 returnPTR_ERR(rtc->rtc_dev); instead of goto err; return err.
- Request the interrupt before the RTC device is registered with the call todevm_rtc_device_register.
Quoted 2 lines
Acked-by Alessandro Zummo <[email protected]>
Thank you.
Regards,
Steve
RE: [PATCH V1 2/2] rtc: da9063: RTC driver
In reply to Alessandro ZummoOn 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 returnPTR_ERR(rtc->rtc_dev); instead of goto err; return err.
- Request the interrupt before the RTC device is registered with the call todevm_rtc_device_register.Acked-by Alessandro Zummo <[email protected]>
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
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
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.
Signed-off-by Opensource [Steve Twiss] <[email protected]>Acked-by Alessandro Zummo <[email protected]>Acked-by Lee Jones <[email protected]>
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/346This 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/112Also, 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
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.
Signed-off-by Opensource [Steve Twiss] <[email protected]>Acked-by Alessandro Zummo <[email protected]>Acked-by Lee Jones <[email protected]>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/346This 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/369Ah, 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�
RE: [RESEND] [PATCH V1 2/2] rtc: da9063: RTC driver
In reply to Lee JonesHi 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.
Signed-off-by Opensource [Steve Twiss] <[email protected]>Acked-by Alessandro Zummo <[email protected]>Acked-by Lee Jones <[email protected]>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/346This 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/112Also, 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�
RE: [RESEND] [PATCH V1 2/2] rtc: da9063: RTC driver
In reply to Lee JonesHi 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�
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.hchanges ...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/346I 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/369And the other half, was Acked by Alessandro Zummo here:
https://lkml.org/lkml/2014/3/7/112Quoted 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/248The 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
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.hchanges ...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/346I 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/369And the other half, was Acked by Alessandro Zummo here:
https://lkml.org/lkml/2014/3/7/112Quoted 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�