[PATCH 0/8] rtc: max77686: Extend driver and add max77802 support

[PATCH 0/8] rtc: max77686: Extend driver and add max77802 support

[Javier Martinez Canillas]

Hello,

On a recent disussion [0] with Krzysztof Kozlowski and Laxman Dewangan,
we came to the conclusion that the max77686 and max77802 RTC are almost
the same with only a few differences so there shouldn't be two separate
drivers and is better to extend max77686 driver and delete rtc-max77802.

By making the driver more generic, other RTC IP blocks from Maxim PMICs
could be supported as well like the max77620.

Patches #1 is just a trivial cleanup.

Patch #2 allows to support RTCs that need a shorter delay when updating
the RTC.

Patch #3 adds a driver data structure to avoid hard-coding parameters
specific to a certain RTC such as the needed delay and RTC register mask.

Patch #4 changes the driver to use a mapping table instead of using the
max77686 registers offsets directly to allow supporting RTC with other
registers addresses and layout.

Patch #5 Adds support for max77802 to max77686 RTC driver and patch #6
removes the old driver since is not needed anymore.

Finally patch #7 and patch #8 removes the Kconfig symbol from defconfigs.

I've tested this patch-set on an Exynos5800 Peach Pi Chromebook that has
a max77802 PMIC and the RTC was working correctly but I don't have a
machine with max77686 so I will really appreaciate if someone can test
that no regressions were introduced.

One thing that I'm not sure is how to handle bisectability, in patch #5
there will be two drivers that matches "rtc-max77802". So I don't know
if I should use a different platform_device_id name and change in the
same patch that max77802 is removed or if this is not a big deal so the
patches could stay as is.

I believe all patches should go through the RTC tree with proper acks or
wait until the RTC patches land to pick the defconfig changes.

[0]: http://www.spinics.net/lists/devicetree/msg110348.html


Javier Martinez Canillas (8):
  rtc: max77686: Use ARRAY_SIZE() instead of current array length
  rtc: max77686: Use usleep_range() instead of msleep()
  rtc: max77686: Use a driver data struct instead hard-coded values
  rtc: max77686: Add an indirection level to access RTC registers
  rtc: max77686: Add max77802 support
  rtc: Remove Maxim 77802 driver
  ARM: exynos_defconfig: Remove MAX77802 RTC Kconfig symbol
  ARM: multi_v7_defconfig: Remove MAX77802 RTC Kconfig symbol

 arch/arm/configs/exynos_defconfig   |   1 -
 arch/arm/configs/multi_v7_defconfig |   1 -
 drivers/rtc/Kconfig                 |  10 -
 drivers/rtc/Makefile                |   1 -
 drivers/rtc/rtc-max77686.c          | 276 +++++++++++++++-----
 drivers/rtc/rtc-max77802.c          | 502 ------------------------------------
 6 files changed, 213 insertions(+), 578 deletions(-)
 delete mode 100644 drivers/rtc/rtc-max77802.c

-- 
2.5.0

[PATCH 8/8] ARM: multi_v7_defconfig: Remove MAX77802 RTC Kconfig symbol

[Javier Martinez Canillas]

The driver has been removed so the Kconfig symbol is not valid anymore.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>


---

 arch/arm/configs/multi_v7_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 314f6be2dca2..bdb42c09332c 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -664,7 +664,6 @@ CONFIG_RTC_DRV_MAX8907=y
 CONFIG_RTC_DRV_MAX8997=m
 CONFIG_RTC_DRV_MAX77686=y
 CONFIG_RTC_DRV_RK808=m
-CONFIG_RTC_DRV_MAX77802=m
 CONFIG_RTC_DRV_RS5C372=m
 CONFIG_RTC_DRV_PALMAS=y
 CONFIG_RTC_DRV_ST_LPC=y
-- 
2.5.0

[PATCH 0/8] rtc: max77686: Extend driver and add max77802 support

[Alexandre Belloni]

Hi,

On 20/01/2016 at 14:14:40 -0300, Javier Martinez Canillas wrote :
> One thing that I'm not sure is how to handle bisectability, in patch #5
> there will be two drivers that matches "rtc-max77802". So I don't know
> if I should use a different platform_device_id name and change in the
> same patch that max77802 is removed or if this is not a big deal so the
> patches could stay as is.
> 

I'm fine with those patches as is.

> I believe all patches should go through the RTC tree with proper acks or
> wait until the RTC patches land to pick the defconfig changes.
> 

I think Olof would prefer the last patches to go through arm-soc.

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

[PATCH 0/8] rtc: max77686: Extend driver and add max77802 support

[Krzysztof Kozlowski]

On 21.01.2016 09:30, Alexandre Belloni wrote:
>> I believe all patches should go through the RTC tree with proper acks or
>> wait until the RTC patches land to pick the defconfig changes.
>>
> 
> I think Olof would prefer the last patches to go through arm-soc.

That would be preferred but merging them before the 5/8 would cause a
loss of functionality on these defconfigs making it non-bisectable
approach. I think it would be good to preserve bisectability in that
matter so either:
1. a tag from RTC on top of which these patches would be applied in arm-soc,
2. take them to RTC tree with our acks.

Best regards,
Krzysztof

[PATCH 0/8] rtc: max77686: Extend driver and add max77802 support

[Krzysztof Kozlowski]

On 21.01.2016 02:14, Javier Martinez Canillas wrote:
> Hello,
> 
> On a recent disussion [0] with Krzysztof Kozlowski and Laxman Dewangan,
> we came to the conclusion that the max77686 and max77802 RTC are almost
> the same with only a few differences so there shouldn't be two separate
> drivers and is better to extend max77686 driver and delete rtc-max77802.
> 
> By making the driver more generic, other RTC IP blocks from Maxim PMICs
> could be supported as well like the max77620.
> 
> Patches #1 is just a trivial cleanup.
> 
> Patch #2 allows to support RTCs that need a shorter delay when updating
> the RTC.
> 
> Patch #3 adds a driver data structure to avoid hard-coding parameters
> specific to a certain RTC such as the needed delay and RTC register mask.
> 
> Patch #4 changes the driver to use a mapping table instead of using the
> max77686 registers offsets directly to allow supporting RTC with other
> registers addresses and layout.
> 
> Patch #5 Adds support for max77802 to max77686 RTC driver and patch #6
> removes the old driver since is not needed anymore.
> 
> Finally patch #7 and patch #8 removes the Kconfig symbol from defconfigs.
> 
> I've tested this patch-set on an Exynos5800 Peach Pi Chromebook that has
> a max77802 PMIC and the RTC was working correctly but I don't have a
> machine with max77686 so I will really appreaciate if someone can test
> that no regressions were introduced.
> 

Thanks for the submission. I like the approach. I'll start reviewing the
code and testing it... or maybe I'll wait with testing for v2 because I
already sent some comments. :)

Anyway I will provide later tested-by on max77686.

Best regards,
Krzysztof

[PATCH 8/8] ARM: multi_v7_defconfig: Remove MAX77802 RTC Kconfig symbol

[Krzysztof Kozlowski]

On 21.01.2016 02:14, Javier Martinez Canillas wrote:
> The driver has been removed so the Kconfig symbol is not valid anymore.
> 
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> 
> 
> ---
> 
>  arch/arm/configs/multi_v7_defconfig | 1 -
>  1 file changed, 1 deletion(-)

Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>

Best regards,
Krzysztof

[PATCH 0/8] rtc: max77686: Extend driver and add max77802 support

[Javier Martinez Canillas]

Hello,

On 01/20/2016 09:34 PM, Krzysztof Kozlowski wrote:
> On 21.01.2016 09:30, Alexandre Belloni wrote:
>>> I believe all patches should go through the RTC tree with proper acks or
>>> wait until the RTC patches land to pick the defconfig changes.
>>>
>>
>> I think Olof would prefer the last patches to go through arm-soc.
>
> That would be preferred but merging them before the 5/8 would cause a
> loss of functionality on these defconfigs making it non-bisectable

Exactly, that's why I suggested merging all through RTC with proper acks.

> approach. I think it would be good to preserve bisectability in that
> matter so either:
> 1. a tag from RTC on top of which these patches would be applied in arm-soc,

I didn't suggest that option because I thought it would be a lot of burden
for such a trivial change.

> 2. take them to RTC tree with our acks.
>

Or another option is to not pick the defconfig changes and I can repost
those again once the RTC changes land into mainline.

But of course if up to you to decide since I'm not a maintainer :)
  
> Best regards,
> Krzysztof
>

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

[PATCH 0/8] rtc: max77686: Extend driver and add max77802 support

[Javier Martinez Canillas]

Hello Krzysztof,

On 01/20/2016 09:48 PM, Krzysztof Kozlowski wrote:
> On 21.01.2016 02:14, Javier Martinez Canillas wrote:
>> Hello,
>>
>> On a recent disussion [0] with Krzysztof Kozlowski and Laxman Dewangan,
>> we came to the conclusion that the max77686 and max77802 RTC are almost
>> the same with only a few differences so there shouldn't be two separate
>> drivers and is better to extend max77686 driver and delete rtc-max77802.
>>
>> By making the driver more generic, other RTC IP blocks from Maxim PMICs
>> could be supported as well like the max77620.
>>
>> Patches #1 is just a trivial cleanup.
>>
>> Patch #2 allows to support RTCs that need a shorter delay when updating
>> the RTC.
>>
>> Patch #3 adds a driver data structure to avoid hard-coding parameters
>> specific to a certain RTC such as the needed delay and RTC register mask.
>>
>> Patch #4 changes the driver to use a mapping table instead of using the
>> max77686 registers offsets directly to allow supporting RTC with other
>> registers addresses and layout.
>>
>> Patch #5 Adds support for max77802 to max77686 RTC driver and patch #6
>> removes the old driver since is not needed anymore.
>>
>> Finally patch #7 and patch #8 removes the Kconfig symbol from defconfigs.
>>
>> I've tested this patch-set on an Exynos5800 Peach Pi Chromebook that has
>> a max77802 PMIC and the RTC was working correctly but I don't have a
>> machine with max77686 so I will really appreaciate if someone can test
>> that no regressions were introduced.
>>
>
> Thanks for the submission. I like the approach. I'll start reviewing the
> code and testing it... or maybe I'll wait with testing for v2 because I
> already sent some comments. :)
>
> Anyway I will provide later tested-by on max77686.
>

Thanks a lot for your detailed review. I'll post v2 shortly so you can
just test that.
  
> Best regards,
> Krzysztof
>

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America