[PATCHv3,4/5] rtc: s3c: Add support for RTC of Exynos3250 SoC

This patch add support for RTC of Exynos3250 SoC. The Exynos3250 needs source
clock(32.768KHz) for RTC block. If source clock of RTC is registerd on clock
list of common clk framework, Exynos RTC drvier have to control this clock.

Clock list for s3c-rtc device:
- rtc : CLK_RTC of CLK_GATE_IP_PERIR is gate clock for RTC.
- rtc_src : XrtcXTI is 32.768.kHz source clock for RTC.
 (XRTCXTI: Specifies a clock from 32.768 kHz crystal pad with XRTCXTI and
 XRTCXTO pins. RTC uses this clock as the source of a real-time clock.)

Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
 Documentation/devicetree/bindings/rtc/s3c-rtc.txt |  1 +
 drivers/rtc/rtc-s3c.c                             | 93 ++++++++++++++++++++++-
 2 files changed, 93 insertions(+), 1 deletion(-)

Hello Chanwoo,

On Thu, Aug 28, 2014 at 11:02 AM, Chanwoo Choi <cw00.choi@samsung.com> wrote:
> This patch add support for RTC of Exynos3250 SoC. The Exynos3250 needs source
> clock(32.768KHz) for RTC block. If source clock of RTC is registerd on clock
> list of common clk framework, Exynos RTC drvier have to control this clock.
>
> Clock list for s3c-rtc device:
> - rtc : CLK_RTC of CLK_GATE_IP_PERIR is gate clock for RTC.
> - rtc_src : XrtcXTI is 32.768.kHz source clock for RTC.

Is this RTC source clock needed for all Exynos SoCs?

> @@ -480,11 +530,19 @@ static int s3c_rtc_probe(struct platform_device *pdev)
>
>         info->rtc_clk = devm_clk_get(&pdev->dev, "rtc");
>         if (IS_ERR(info->rtc_clk)) {
> -               dev_err(&pdev->dev, "failed to find rtc clock source\n");
> +               dev_err(&pdev->dev, "failed to find rtc clock\n");
>                 return PTR_ERR(info->rtc_clk);
>         }
>         clk_prepare_enable(info->rtc_clk);
>
> +       info->rtc_src_clk = devm_clk_get(&pdev->dev, "rtc_src");
> +       if (IS_ERR(info->rtc_src_clk)) {
> +               dev_err(&pdev->dev, "failed to find rtc source clock\n");
> +               return PTR_ERR(info->rtc_src_clk);

On an Exynos5420 Peach Pit machine I'm having the following error and
the driver fails to probe:

[    2.095700] s3c-rtc: probe of 101e0000.rtc failed with error -2

Reverting this patch fixes the issue and the s3c RTC works again on
this machine.

Best regards,
Javier

On Tue, Sep 16, 2014 at 7:48 AM, Javier Martinez Canillas
<javier@dowhile0.org> wrote:
>> Clock list for s3c-rtc device:
>> - rtc : CLK_RTC of CLK_GATE_IP_PERIR is gate clock for RTC.
>> - rtc_src : XrtcXTI is 32.768.kHz source clock for RTC.
>
> Is this RTC source clock needed for all Exynos SoCs?

It is at least needed on Exynos4412, which has the XrtcXTI thing
exactly as you describe. However the very standard setup there is to
hook it up to the CP clock output of the MAX76686 PMIC. This CP clock
is on by default, so you can potentially live without that detail
being present in the DT.

However... one small issue with this setup is that when you enable
CONFIG_COMMON_CLK_MAX77686, the CP clock gets exposed in Linux's
common clock framework, and Linux then turns it off because it
believes it is unused. Then the RTC stops ticking.

So the rtc_src idea would also be good for Exynos4412. Maybe it would
make sense to drop the needs_src_clk flag, and simply require/enable
the src clock whenever it is present in the DT.

Also, are you sure about the way you are treating this clock, all
those enable/disable calls? You only seem to enable it when doing some
particular driver operations e.g. reading the time, leaving it
disabled at all other times. However I believe on Exynos4412 that if
you disable this clock then the RTC will not tick.

Daniel

Hello Daniel,

On Tue, Sep 16, 2014 at 5:03 PM, Daniel Drake <drake@endlessm.com> wrote:
> On Tue, Sep 16, 2014 at 7:48 AM, Javier Martinez Canillas
> <javier@dowhile0.org> wrote:
>>> Clock list for s3c-rtc device:
>>> - rtc : CLK_RTC of CLK_GATE_IP_PERIR is gate clock for RTC.
>>> - rtc_src : XrtcXTI is 32.768.kHz source clock for RTC.
>>
>> Is this RTC source clock needed for all Exynos SoCs?
>
> It is at least needed on Exynos4412, which has the XrtcXTI thing
> exactly as you describe. However the very standard setup there is to
> hook it up to the CP clock output of the MAX76686 PMIC. This CP clock
> is on by default, so you can potentially live without that detail
> being present in the DT.
>

Thanks for confirming for Exynos4412, I just answered my own email
saying that I found to be needed on Exynos5420 as well and as you
said, it was just working because the Maxim clocks were left on by
default.

> However... one small issue with this setup is that when you enable
> CONFIG_COMMON_CLK_MAX77686, the CP clock gets exposed in Linux's
> common clock framework, and Linux then turns it off because it
> believes it is unused. Then the RTC stops ticking.
>

Indeed, this is an issue about relying on default state. We had a
quite long discussion a couple of weeks ago about simplefb relying on
clocks and regulators left enabled by the bootloader but once these
were know to the kernel, the frameworks disable them because were
unused making simplefb to fail.

> So the rtc_src idea would also be good for Exynos4412. Maybe it would
> make sense to drop the needs_src_clk flag, and simply require/enable
> the src clock whenever it is present in the DT.
>

That sounds more sensible to me as well. I wonder what should happen
in this case with DT backward compatibility though. But as you said,
the external clock is required and the kernel will disable this clock
once is know to the CCF since is not used so maybe will be hard to
maintain DT backward compatibility in this case.

> Also, are you sure about the way you are treating this clock, all
> those enable/disable calls? You only seem to enable it when doing some
> particular driver operations e.g. reading the time, leaving it
> disabled at all other times. However I believe on Exynos4412 that if
> you disable this clock then the RTC will not tick.
>
> Daniel

Best regards,
Javier

Hi,

On Tue, Sep 16, 2014 at 8:20 AM, Javier Martinez Canillas
<javier@dowhile0.org> wrote:
> Hello Daniel,
>
> On Tue, Sep 16, 2014 at 5:03 PM, Daniel Drake <drake@endlessm.com> wrote:
>> On Tue, Sep 16, 2014 at 7:48 AM, Javier Martinez Canillas
>> <javier@dowhile0.org> wrote:
>>>> Clock list for s3c-rtc device:
>>>> - rtc : CLK_RTC of CLK_GATE_IP_PERIR is gate clock for RTC.
>>>> - rtc_src : XrtcXTI is 32.768.kHz source clock for RTC.
>>>
>>> Is this RTC source clock needed for all Exynos SoCs?
>>
>> It is at least needed on Exynos4412, which has the XrtcXTI thing
>> exactly as you describe. However the very standard setup there is to
>> hook it up to the CP clock output of the MAX76686 PMIC. This CP clock
>> is on by default, so you can potentially live without that detail
>> being present in the DT.
>>
>
> Thanks for confirming for Exynos4412, I just answered my own email
> saying that I found to be needed on Exynos5420 as well and as you
> said, it was just working because the Maxim clocks were left on by
> default.
>
>> However... one small issue with this setup is that when you enable
>> CONFIG_COMMON_CLK_MAX77686, the CP clock gets exposed in Linux's
>> common clock framework, and Linux then turns it off because it
>> believes it is unused. Then the RTC stops ticking.
>>
>
> Indeed, this is an issue about relying on default state. We had a
> quite long discussion a couple of weeks ago about simplefb relying on
> clocks and regulators left enabled by the bootloader but once these
> were know to the kernel, the frameworks disable them because were
> unused making simplefb to fail.
>
>> So the rtc_src idea would also be good for Exynos4412. Maybe it would
>> make sense to drop the needs_src_clk flag, and simply require/enable
>> the src clock whenever it is present in the DT.
>>
>
> That sounds more sensible to me as well. I wonder what should happen
> in this case with DT backward compatibility though. But as you said,
> the external clock is required and the kernel will disable this clock
> once is know to the CCF since is not used so maybe will be hard to
> maintain DT backward compatibility in this case.

I think you can turn off CONFIG_COMMON_CLK_MAX77686 and then this
clock will be left at whatever the bootloader set it to, right?  Then
there will be no auto-disabling by the CCF and the RTC will work.
That's one argument for making the clock "optional".

NOTE: I don't think that the builtin RTC is terribly important for any
exynos-based Chromebooks that I'm aware of.  We rely on the RTC that's
part of the Maxim PMIC itself and pretty much ignore the one built-in
to the exynos.  I think there are some cases it was used (as a
fallback wakeup source in certain test scripts), but nothing very
important.

-Doug

Hello Doug,

On Wed, Sep 17, 2014 at 12:15 AM, Doug Anderson <dianders@chromium.org> wrote:
>
> I think you can turn off CONFIG_COMMON_CLK_MAX77686 and then this
> clock will be left at whatever the bootloader set it to, right?  Then
> there will be no auto-disabling by the CCF and the RTC will work.

Yes, that's how Daniel was working around the issue.

> That's one argument for making the clock "optional".
>

Indeed.

> NOTE: I don't think that the builtin RTC is terribly important for any
> exynos-based Chromebooks that I'm aware of.  We rely on the RTC that's
> part of the Maxim PMIC itself and pretty much ignore the one built-in
> to the exynos.  I think there are some cases it was used (as a
> fallback wakeup source in certain test scripts), but nothing very
> important.
>

Ok, I'll post the patch I shared before that makes the rtc to claim
the max77802 32kHz clock as "rtc_src" anyways since that is the right
thing to do even if the "rtc_src" ends being optional due DT backward
compat.

> -Doug

Best regards,
Javier

On Tue, Sep 16, 2014 at 4:15 PM, Doug Anderson <dianders@chromium.org> wrote:
> NOTE: I don't think that the builtin RTC is terribly important for any
> exynos-based Chromebooks that I'm aware of.  We rely on the RTC that's
> part of the Maxim PMIC itself and pretty much ignore the one built-in
> to the exynos.  I think there are some cases it was used (as a
> fallback wakeup source in certain test scripts), but nothing very
> important.

That's not true for all hardware though, at least the board I'm
working on now has the SoC RTC as battery-backed and the PMIC one with
no battery. So in this case at least, the interesting RTC is the SoC
one.

Daniel

Daniel,

On Wed, Sep 17, 2014 at 9:49 AM, Daniel Drake <drake@endlessm.com> wrote:
> On Tue, Sep 16, 2014 at 4:15 PM, Doug Anderson <dianders@chromium.org> wrote:
>> NOTE: I don't think that the builtin RTC is terribly important for any
>> exynos-based Chromebooks that I'm aware of.  We rely on the RTC that's
>> part of the Maxim PMIC itself and pretty much ignore the one built-in
>> to the exynos.  I think there are some cases it was used (as a
>> fallback wakeup source in certain test scripts), but nothing very
>> important.
>
> That's not true for all hardware though, at least the board I'm
> working on now has the SoC RTC as battery-backed and the PMIC one with
> no battery. So in this case at least, the interesting RTC is the SoC
> one.

Yup, I can totally believe that.  My statement was meant only to apply
to the boards I knew about firsthand...

-Doug