* [PATCH 4/4] time: rtc-lib: Add CONFIG_RTC_SHOW_TIME_RTC
From: Mark Salyzyn @ 2017-07-19 19:50 UTC (permalink / raw)
To: linux-kernel
Cc: rjw, len.brown, pavel, linux-pm, a.zummo, alexandre.belloni,
linux-rtc, prarit, andy.shevchenko, Mark Salyzyn,
Paul E. McKenney
Add an option to report REALTIME in RTC time format for
rtc_show_time() function.
Feature activated by CONFIG_RTC_SHOW_TIME_RTC.
Signed-off-by: Mark Salyzyn <salyzyn@android.com>
---
kernel/time/Kconfig | 17 +++++++++++++++++
kernel/time/rtc_show_time.c | 12 ++++++++++++
2 files changed, 29 insertions(+)
diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
index 2dc891056635..3c2920b8825c 100644
--- a/kernel/time/Kconfig
+++ b/kernel/time/Kconfig
@@ -221,4 +221,21 @@ choice
continues, and the timestamps help re-orient post-analysis.
Print boottime <s>.<ns> timestamp in rtc_show_time
+ config RTC_SHOW_TIME_RTC
+ bool "realtime in wall clock format"
+ select RTC_SHOW_TIME
+ select RTC_LIB
+ help
+ Activate optional rtc_show_time(const char *msg) wall clock
+ time instrumentation.
+
+ The primary use of the instrumentation is to aid field
+ analysis of Battery and Power usage. The instrumentation
+ may also help triage and synchronize kernel logs and user
+ space activity logs at key displacements. For instance
+ CLOCK_MONOTONIC stops while suspended, while CLOCK_REALTIME
+ continues, and the timestamps help re-orient post-analysis.
+
+ Print realtime YYYY-MM-DD hh:mm:ss.<ns> timestamp in
+ rtc_show_time.
endchoice
diff --git a/kernel/time/rtc_show_time.c b/kernel/time/rtc_show_time.c
index 6c7b8ae6be0c..d861a30aef77 100644
--- a/kernel/time/rtc_show_time.c
+++ b/kernel/time/rtc_show_time.c
@@ -24,9 +24,21 @@ void rtc_show_time(const char *prefix_msg)
struct timespec64 ts;
getnstimeofday64(&ts);
+#if defined(CONFIG_RTC_SHOW_TIME_RTC)
+ {
+ struct rtc_time tm;
+
+ rtc_time64_to_tm(ts.tv_sec, &tm);
+ pr_info("%s %d-%02d-%02d %02d:%02d:%02d.%09lu UTC\n",
+ prefix_msg ? prefix_msg : "Time:",
+ tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
+ tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec);
+ }
+#else
pr_info("%s %lu.%09lu UTC\n",
prefix_msg ? prefix_msg : "Time:", ts.tv_sec, ts.tv_nsec);
#endif
+#endif
}
EXPORT_SYMBOL(rtc_show_time);
--
2.14.0.rc0.284.gd933b75aa4-goog
^ permalink raw reply related
* Re: [PATCH v2 3/4] PM: Print wall time at suspend & hibernate entry and exit
From: Rafael J. Wysocki @ 2017-07-19 20:40 UTC (permalink / raw)
To: Mark Salyzyn
Cc: Linux Kernel Mailing List, Rafael J. Wysocki, Len Brown,
Pavel Machek, Linux PM, Alessandro Zummo, Alexandre Belloni,
linux-rtc
In-Reply-To: <20170719194600.29210-1-salyzyn@android.com>
On Wed, Jul 19, 2017 at 9:45 PM, Mark Salyzyn <salyzyn@android.com> wrote:
> Permits power state and battery life diagnosis.
>
> Since one is not guaranteed to have a persistent hardware clock to
> report Suspended for in milliseconds, we report at a higher level
> at just the entry and exit points for suspend and hibernate.
>
> Feature activated by CONFIG_RTC_SHOW_TIME_*
>
> Signed-off-by: Mark Salyzyn <salyzyn@android.com>
>
> v2:
> - merge suspend and hibernate into a single patch
So now I guess you realize that this conflicts with
https://patchwork.kernel.org/patch/9850217/ and it actually would make
sense for it to go on top of that?
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH v4 1/4] time: rtc-lib: Add rtc_show_time(const char *prefix_msg)
From: Alexandre Belloni @ 2017-07-19 21:22 UTC (permalink / raw)
To: Mark Salyzyn
Cc: linux-kernel, rjw, len.brown, pavel, linux-pm, a.zummo, linux-rtc,
Kees Cook, Anton Vorontsov, Colin Cross, Tony Luck,
Paul E. McKenney, Thomas Gleixner, John Stultz, Nicolas Pitre,
Richard Cochran
In-Reply-To: <20170719194511.28899-1-salyzyn@android.com>
Hi,
On 19/07/2017 at 12:44:41 -0700, Mark Salyzyn wrote:
> Primary purpose of rtc_show_time is to provide a marker used for
> post-mortem Battery and Power analysis. These markers occur at
> major discontinuities of time, and thus optionally add a timestamp
> to aid the analysis. This function is to be called at a higher
> level, and were added because of a lack of current kernel logging
> data.
>
I really think you should drop rtc from the config, function and file
names because this doesn't have any relationship with any RTC stuff.
I can just see that you are (ab)using rtc_time64_to_tm because there is
no struct tm or gmtime() in the kernel.
> The persistent clock that is used to report Suspended for message
> is not present on all platforms, and is currently standardized for
> millisecond precision.
>
> An added value to the time report is the ability in post-mortem
> triage analysis to synchronize kernel activities in MONOTONIC
> time with user space activities in REALTIME.
>
> Feature activated by CONFIG_RTC_SHOW_TIME_<TYPE>, where <TYPE> is
> None (default, disabled), realtime, boottime or monotonic.
>
> Since this is for post mortem field analysis, there is no debugfs
> or trace facility that can generally be leveraged. analyze_suspend.py
> for example requires a debug configured kernel, on the other hand
> these prints can remain in a field product. The purpose for
> rtc_show_time is not for development debugging.
>
> Data collected may be recorded by klogd with a longer logspan
> than the built-in dmesg buffer, or land in pstore console driver
> to be collected after a reboot.
>
> Signed-off-by: Mark Salyzyn <salyzyn@android.com>
>
> v2:
> - move implementation to kernel timekeeping from rtc_lib files
> - use rtc_time64_to_tm() instead of rtc_time_to_tm()
> - use inline in include/linux/rtc.h for !CONFIG_RTC_SHOW_TIME
> v3:
> - _correctly_ use rtc_time64_to_tm
> v4:
> - introduce CONFIG_RTC_SHOW_TIME_<TYPE> and split off rtc time
> format printing to a separate patch.
>
> ---
> include/linux/rtc.h | 5 +++
> kernel/time/Kconfig | 77 +++++++++++++++++++++++++++++++++++++++++++++
> kernel/time/Makefile | 1 +
> kernel/time/rtc_show_time.c | 29 +++++++++++++++++
> 4 files changed, 112 insertions(+)
> create mode 100644 kernel/time/rtc_show_time.c
>
> diff --git a/include/linux/rtc.h b/include/linux/rtc.h
> index 0a0f0d14a5fb..779401c937d5 100644
> --- a/include/linux/rtc.h
> +++ b/include/linux/rtc.h
> @@ -22,6 +22,11 @@ extern int rtc_year_days(unsigned int day, unsigned int month, unsigned int year
> extern int rtc_valid_tm(struct rtc_time *tm);
> extern time64_t rtc_tm_to_time64(struct rtc_time *tm);
> extern void rtc_time64_to_tm(time64_t time, struct rtc_time *tm);
> +#ifdef CONFIG_RTC_SHOW_TIME
> +extern void rtc_show_time(const char *prefix_msg);
> +#else
> +static inline void rtc_show_time(const char *prefix_msg) { }
> +#endif
> ktime_t rtc_tm_to_ktime(struct rtc_time tm);
> struct rtc_time rtc_ktime_to_tm(ktime_t kt);
>
> diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
> index ac09bc29eb08..2dc891056635 100644
> --- a/kernel/time/Kconfig
> +++ b/kernel/time/Kconfig
> @@ -145,3 +145,80 @@ config HIGH_RES_TIMERS
>
> endmenu
> endif
> +
> +config RTC_SHOW_TIME
> + bool
> + help
> + Activate optional rtc_show_time(const char *msg) wall clock
> + time instrumentation.
> +
> + The primary use of the instrumentation is to aid field
> + analysis of Battery and Power usage. The instrumentation
> + may also help triage and synchronize kernel logs and user
> + space activity logs at key displacements. For instance
> + CLOCK_MONOTONIC stops while suspended, while CLOCK_REALTIME
> + continues, and the timestamps help re-orient post-analysis.
> +
> + Select the appropriate RTC_SHOW_TIME_<type>
> +
> +choice
> + prompt "choose a clock for rtc_show_time"
> + config RTC_SHOW_TIME_NONE
> + bool "not activated"
> + help
> + Turn off all printing associated with rtc_show_time
> +
> + The primary use of the instrumentation is to aid field
> + analysis of Battery and Power usage. The instrumentation
> + may also help triage and synchronize kernel logs and user
> + space activity logs at key displacements. For instance
> + CLOCK_MONOTONIC stops while suspended, while CLOCK_REALTIME
> + continues, and the timestamps help re-orient post-analysis.
> +
> + This is the default behavior.
> + config RTC_SHOW_TIME_REALTIME
> + bool "realtime"
> + select RTC_SHOW_TIME
> + help
> + Activate optional rtc_show_time(const char *msg) wall clock
> + time instrumentation.
> +
> + The primary use of the instrumentation is to aid field
> + analysis of Battery and Power usage. The instrumentation
> + may also help triage and synchronize kernel logs and user
> + space activity logs at key displacements. For instance
> + CLOCK_MONOTONIC stops while suspended, while CLOCK_REALTIME
> + continues, and the timestamps help re-orient post-analysis.
> +
> + Print realtime <epoch>.<ns> timestamp in rtc_show_time
> + config RTC_SHOW_TIME_MONOTONIC
> + bool "monotonic"
> + select RTC_SHOW_TIME
> + help
> + Activate optional rtc_show_time(const char *msg) wall clock
> + time instrumentation.
> +
> + The primary use of the instrumentation is to aid field
> + analysis of Battery and Power usage. The instrumentation
> + may also help triage and synchronize kernel logs and user
> + space activity logs at key displacements. For instance
> + CLOCK_MONOTONIC stops while suspended, while CLOCK_REALTIME
> + continues, and the timestamps help re-orient post-analysis.
> +
> + Print only the supplied message in rtc_show_time
> + config RTC_SHOW_TIME_BOOTTIME
> + bool "boottime"
> + select RTC_SHOW_TIME
> + help
> + Activate optional rtc_show_time(const char *msg) wall clock
> + time instrumentation.
> +
> + The primary use of the instrumentation is to aid field
> + analysis of Battery and Power usage. The instrumentation
> + may also help triage and synchronize kernel logs and user
> + space activity logs at key displacements. For instance
> + CLOCK_MONOTONIC stops while suspended, while CLOCK_REALTIME
> + continues, and the timestamps help re-orient post-analysis.
> +
> + Print boottime <s>.<ns> timestamp in rtc_show_time
> +endchoice
> diff --git a/kernel/time/Makefile b/kernel/time/Makefile
> index 938dbf33ef49..66f17e641052 100644
> --- a/kernel/time/Makefile
> +++ b/kernel/time/Makefile
> @@ -17,3 +17,4 @@ obj-$(CONFIG_GENERIC_SCHED_CLOCK) += sched_clock.o
> obj-$(CONFIG_TICK_ONESHOT) += tick-oneshot.o tick-sched.o
> obj-$(CONFIG_DEBUG_FS) += timekeeping_debug.o
> obj-$(CONFIG_TEST_UDELAY) += test_udelay.o
> +obj-$(CONFIG_RTC_SHOW_TIME) += rtc_show_time.o
> diff --git a/kernel/time/rtc_show_time.c b/kernel/time/rtc_show_time.c
> new file mode 100644
> index 000000000000..19a8a0cc94f0
> --- /dev/null
> +++ b/kernel/time/rtc_show_time.c
> @@ -0,0 +1,29 @@
> +/*
> + * rtc time printing utility functions
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/rtc.h>
> +
> +void rtc_show_time(const char *prefix_msg)
> +{
> +#if defined(CONFIG_RTC_SHOW_TIME_MONOTONIC) /* dmesg is in monotonic */
> + pr_info("%s\n", prefix_msg ? prefix_msg : "Time:");
> +#elif defined(CONFIG_RTC_SHOW_TIME_BOOTTIME)
> + struct timespec64 ts;
> +
> + getboottime64(&ts);
> + pr_info("%s %lu.%09lu B\n",
> + prefix_msg ? prefix_msg : "Time:", ts.tv_sec, ts.tv_nsec);
> +#else /* realtime */
> + struct timespec64 ts;
> +
> + getnstimeofday64(&ts);
> + pr_info("%s %lu.%09lu UTC\n",
> + prefix_msg ? prefix_msg : "Time:", ts.tv_sec, ts.tv_nsec);
> +#endif
> +}
> +EXPORT_SYMBOL(rtc_show_time);
> --
> 2.14.0.rc0.284.gd933b75aa4-goog
>
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v2 3/4] PM: Print wall time at suspend & hibernate entry and exit
From: Mark Salyzyn @ 2017-07-19 21:23 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Rafael J. Wysocki, Len Brown,
Pavel Machek, Linux PM, Alessandro Zummo, Alexandre Belloni,
linux-rtc
In-Reply-To: <CAJZ5v0iVwUy5fdvYu=6HEwLPpw7g6owbFuwNpUJcb_iJ3LCFMA@mail.gmail.com>
On 07/19/2017 01:40 PM, Rafael J. Wysocki wrote:
> On Wed, Jul 19, 2017 at 9:45 PM, Mark Salyzyn <salyzyn@android.com> wrote:
>> Permits power state and battery life diagnosis.
>>
>> Since one is not guaranteed to have a persistent hardware clock to
>> report Suspended for in milliseconds, we report at a higher level
>> at just the entry and exit points for suspend and hibernate.
>>
>> Feature activated by CONFIG_RTC_SHOW_TIME_*
>>
>> Signed-off-by: Mark Salyzyn <salyzyn@android.com>
>>
>> v2:
>> - merge suspend and hibernate into a single patch
> So now I guess you realize that this conflicts with
> https://patchwork.kernel.org/patch/9850217/ and it actually would make
> sense for it to go on top of that?
>
> Thanks,
> Rafael
I see. It would make sense to merge the concepts a bit since the prints
are at the same locations.
Optimization idea: rtc_show_time() in my patch series should be able to
support varargs, never be _disabled_ (CONFIG_RTC_SHOW_TIME_NONE idea is
dropped) and the function would be a drop-in replacement for pr_info,
but add the specified timestamp before the newline. Change it's name to
pr_info_show_time() instead to reflect this adjustment.
I would also prefer that the base messages in patch/980217 be "PM:
suspend entry" and "PM: suspend exit", only because I believe 1.6billion
Linux devices would not need to be retooled, and besides these messages
are shorter/sweeter.
Anyone disagree with some more over-engineering (pr_info_show_time() and
varargs)
-- Mark
^ permalink raw reply
* Re: [PATCH v4 1/4] time: rtc-lib: Add rtc_show_time(const char *prefix_msg)
From: Mark Salyzyn @ 2017-07-19 21:30 UTC (permalink / raw)
To: Alexandre Belloni
Cc: linux-kernel, rjw, len.brown, pavel, linux-pm, a.zummo, linux-rtc,
Kees Cook, Anton Vorontsov, Colin Cross, Tony Luck,
Paul E. McKenney, Thomas Gleixner, John Stultz, Nicolas Pitre,
Richard Cochran
In-Reply-To: <20170719212241.kla3d3j6vgaxy4ba@piout.net>
On 07/19/2017 02:22 PM, Alexandre Belloni wrote:
> Hi,
>
> On 19/07/2017 at 12:44:41 -0700, Mark Salyzyn wrote:
>> Primary purpose of rtc_show_time is to provide a marker used for
>> post-mortem Battery and Power analysis. These markers occur at
>> major discontinuities of time, and thus optionally add a timestamp
>> to aid the analysis. This function is to be called at a higher
>> level, and were added because of a lack of current kernel logging
>> data.
>>
> I really think you should drop rtc from the config, function and file
> names because this doesn't have any relationship with any RTC stuff.
Agreed and Thanks. In another response, this function has more in common
with a pr_info_show_time() than I previously have accepted. Most of the
rtc part goes away if I follow that thread/idea Leaving the following:
> I can just see that you are (ab)using rtc_time64_to_tm because there is
> no struct tm or gmtime() in the kernel.
Yes, since we put that part into a separate patch, that can be
punted/accepted on its own, using rtc-lib is a simple concept. The
commit message for that patch should have had your line of sentiment in
it! (even (ab)using message :-) )
-- Mark
^ permalink raw reply
* Re: [PATCH v2 3/4] PM: Print wall time at suspend & hibernate entry and exit
From: Rafael J. Wysocki @ 2017-07-19 21:31 UTC (permalink / raw)
To: Mark Salyzyn
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Rafael J. Wysocki,
Len Brown, Pavel Machek, Linux PM, Alessandro Zummo,
Alexandre Belloni, linux-rtc
In-Reply-To: <507dec5d-3beb-4dd8-0d5f-90f22fccccd2@android.com>
On Wed, Jul 19, 2017 at 11:23 PM, Mark Salyzyn <salyzyn@android.com> wrote:
> On 07/19/2017 01:40 PM, Rafael J. Wysocki wrote:
>>
>> On Wed, Jul 19, 2017 at 9:45 PM, Mark Salyzyn <salyzyn@android.com> wrote:
>>>
>>> Permits power state and battery life diagnosis.
>>>
>>> Since one is not guaranteed to have a persistent hardware clock to
>>> report Suspended for in milliseconds, we report at a higher level
>>> at just the entry and exit points for suspend and hibernate.
>>>
>>> Feature activated by CONFIG_RTC_SHOW_TIME_*
>>>
>>> Signed-off-by: Mark Salyzyn <salyzyn@android.com>
>>>
>>> v2:
>>> - merge suspend and hibernate into a single patch
>>
>> So now I guess you realize that this conflicts with
>> https://patchwork.kernel.org/patch/9850217/ and it actually would make
>> sense for it to go on top of that?
>>
>> Thanks,
>> Rafael
>
>
> I see. It would make sense to merge the concepts a bit since the prints are
> at the same locations.
Exactly.
> Optimization idea: rtc_show_time() in my patch series should be able to
> support varargs, never be _disabled_ (CONFIG_RTC_SHOW_TIME_NONE idea is
> dropped) and the function would be a drop-in replacement for pr_info, but
> add the specified timestamp before the newline. Change it's name to
> pr_info_show_time() instead to reflect this adjustment.
>
> I would also prefer that the base messages in patch/980217 be "PM: suspend
> entry" and "PM: suspend exit", only because I believe 1.6billion Linux
> devices would not need to be retooled, and besides these messages are
> shorter/sweeter.
I can change the messages in patch/980217 if that helps.
> Anyone disagree with some more over-engineering (pr_info_show_time() and
> varargs)
Hmm, do it as a macro maybe?
^ permalink raw reply
* [rtc-linux] Re: [PATCH v3 1/4] mfd: cros_ec: Get rid of cros_ec_check_features from cros_ec_dev.
From: Enric Balletbo Serra @ 2017-07-20 6:31 UTC (permalink / raw)
To: Lee Jones
Cc: Gwendal Grignou, Enric Balletbo i Serra, Jonathan Cameron,
Benson Leung, Javier Martinez Canillas, Guenter Roeck,
Linux Kernel, linux-iio, rtc-linux
In-Reply-To: <20170718091906.trvcaacdfrizjfks@dell>
Lee,
2017-07-18 11:19 GMT+02:00 Lee Jones <lee.jones@linaro.org>:
> On Mon, 17 Jul 2017, Enric Balletbo Serra wrote:
>
>> Hi Gwendal,
>>
>> 2017-07-13 22:33 GMT+02:00 Gwendal Grignou <gwendal@chromium.org>:
>> > On Wed, Jul 12, 2017 at 3:13 AM, Enric Balletbo i Serra
>> > <enric.balletbo@collabora.com> wrote:
>> >> The cros_ec_dev driver should be used only to expose the Chrome OS Em=
bedded
>> >> Controller to user-space and should not be used to add MFD devices by
>> >> calling mfd_add_devices. This patch moves this logic to the MFD cros_=
ec
>> >> driver and removes the MFD bits from the character device driver. Als=
o
>> >> makes independent the IIO driver from the character device as also ha=
s no
>> >> sense.
>> >
>> > cros_ec_dev serves another purpose: it allows to represent an EC that
>> > does not have a cros_ec structure. It happens when there are several
>> > EC in a chromebook, and one EC is connected through another EC.
>> > One example is Samus (Pixel 2): where we have:
>> >
>> > (main SOC, Application Processor) AP --> (main Embedded Controller) EC
>> > ---> (Power Delivery [PD}) EC
>> >
>> > We access to the PD EC via pass-through commands through the main EC.
>> > Each EC has a cros_ec_dev structure, but only the main EC as a
>> > cros_ec_device structure (I will forever regret the structure names).
>> >
>> > Now form the AP point of view, both ECs use the same protocol. That
>> > why the sensors and other devcies that are registered by looking at
>> > the feature fields are registered with cros_ec_dev as their parent.
>> > Other devices that are registered from the device tree, predating the
>> > feature field support, are registered with cros_ec_device as their
>> > parent.
>> >
>>
>> Interesting I didn't know that. So are you saying that this patch will
>> break support for devices like Pixel 2? I tested the patches on
>> various devices but not on Pixel 2 so could be.
>
> Does this affect the rest of the series?
>
Yes, because this patch moves cros_ec_check_features from char dev driver..=
.
> Or should I review/apply as usual?
>
Please, hold on while I figure out what's exactly the problem with
Samus. Sorry for the noise.
Cheers,
Enric
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org =E2=94=82 Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
--=20
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---=20
You received this message because you are subscribed to the Google Groups "=
rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [rtc-linux] Re: [PATCH v3 4/4] mfd: cros_ec: add RTC as mfd subdevice
From: Lee Jones @ 2017-07-20 7:15 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: Jonathan Cameron, bleung, martinez.javier, Guenter Roeck,
Gwendal Grignou, linux-kernel, linux-iio, rtc-linux,
Stephen Barber
In-Reply-To: <20170712101309.6045-5-enric.balletbo@collabora.com>
On Wed, 12 Jul 2017, Enric Balletbo i Serra wrote:
> From: Stephen Barber <smbarber@chromium.org>
>=20
> If the EC supports RTC host commands, expose an RTC device.
>=20
> Signed-off-by: Stephen Barber <smbarber@chromium.org>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> ---
> drivers/mfd/cros_ec.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>=20
> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> index 75a27a6..ff972fb 100644
> --- a/drivers/mfd/cros_ec.c
> +++ b/drivers/mfd/cros_ec.c
> @@ -51,6 +51,10 @@ static const struct mfd_cell ec_pd_cell =3D {
> .pdata_size =3D sizeof(pd_p),
> };
> =20
> +static const struct mfd_cell ec_rtc_cell =3D {
> + .name =3D "cros-ec-rtc",
> +};
> +
> static irqreturn_t ec_irq_thread(int irq, void *data)
> {
> struct cros_ec_device *ec_dev =3D data;
> @@ -245,6 +249,16 @@ static void cros_ec_sensors_register(struct cros_ec_=
device *ec_dev)
> kfree(msg);
> }
> =20
> +static void cros_ec_rtc_register(struct cros_ec_device *ec_dev)
> +{
> + int ret;
> +
> + ret =3D mfd_add_devices(ec_dev->dev, PLATFORM_DEVID_AUTO, &ec_rtc_cell,
> + 1, NULL, 0, NULL);
> + if (ret)
> + dev_err(ec_dev->dev, "failed to add EC RTC\n");
> +}
Why do you need a new function just to call a single function?
And by making it void, you're also loosing the return value.
If mfd_add_devices() fails, something has gone wrong!
> int cros_ec_register(struct cros_ec_device *ec_dev)
> {
> struct device *dev =3D ec_dev->dev;
> @@ -294,6 +308,10 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
> if (cros_ec_check_features(ec_dev, EC_FEATURE_MOTION_SENSE))
> cros_ec_sensors_register(ec_dev);
> =20
> + /* Check whether this EC has RTC support */
> + if (cros_ec_check_features(ec_dev, EC_FEATURE_RTC))
> + cros_ec_rtc_register(ec_dev);
> +
> if (ec_dev->max_passthru) {
> /*
> * Register a PD device as well on top of this device.
--=20
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org =E2=94=82 Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--=20
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---=20
You received this message because you are subscribed to the Google Groups "=
rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v2 1/4] time: rtc-lib: Add rtc_show_time(const char *prefix_msg)
From: Pavel Machek @ 2017-07-20 8:20 UTC (permalink / raw)
To: Mark Salyzyn
Cc: Thomas Gleixner, linux-kernel, rjw, len.brown, linux-pm, a.zummo,
alexandre.belloni, linux-rtc, andy.shevchenko, Mark Salyzyn,
Paul E. McKenney, Thierry Strudel, John Stultz, Richard Cochran,
Nicolas Pitre, Kees Cook
In-Reply-To: <8afb372a-3951-6fb9-c0be-82756623061f@android.com>
[-- Attachment #1: Type: text/plain, Size: 711 bytes --]
Hi!
> >
> > pr_info("My so important log message %lld\n", ktime_get_real_seconds());
>
> Legacy (these prints have been in Android tree since 2013) for all our
> battery and power analysis tools are keyed off RTC format. There is some
> momentum, default should be epoch seconds/nanoseconds as that is a good
> example; and another option can select RTC (the option can be an internal
> patch to alter the format ... ick)
Yes, android development is broken. Please fix it, rather then trying
to break kernel to match.
Thank you,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] time: rtc-lib: Add CONFIG_RTC_SHOW_TIME_RTC
From: Pavel Machek @ 2017-07-20 8:26 UTC (permalink / raw)
To: Mark Salyzyn
Cc: linux-kernel, rjw, len.brown, linux-pm, a.zummo,
alexandre.belloni, linux-rtc, prarit, andy.shevchenko,
Paul E. McKenney
In-Reply-To: <20170719195012.30187-1-salyzyn@android.com>
[-- Attachment #1: Type: text/plain, Size: 653 bytes --]
> +#if defined(CONFIG_RTC_SHOW_TIME_RTC)
> + {
> + struct rtc_time tm;
> +
> + rtc_time64_to_tm(ts.tv_sec, &tm);
> + pr_info("%s %d-%02d-%02d %02d:%02d:%02d.%09lu UTC\n",
> + prefix_msg ? prefix_msg : "Time:",
> + tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
> + tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec);
> + }
> +#else
This was NAKed before. Are you even listening, or are you trying to
flood us with enough mail so that someone applies your patches by
mistake?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v1 01/25] lib/vsprintf: Remove useless NULL checks
From: Andy Shevchenko @ 2017-07-20 10:22 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: Rasmus Villemoes, Greg Kroah-Hartman, Andrew Morton, linux-kernel,
Alessandro Zummo, Alexandre Belloni, linux-rtc
In-Reply-To: <87shjakxg1.fsf@rasmusvillemoes.dk>
On Thu, 2017-06-08 at 22:59 +0200, Rasmus Villemoes wrote:
> On Thu, Jun 08 2017, Andy Shevchenko <andriy.shevchenko@linux.intel.co
> m> wrote:
> > The pointer can't be NULL since it's first what has been done in the
> > pointer().
> > - if (ZERO_OR_NULL_PTR(addr))
> > - return string(buf, end, NULL, spec); /* NULL
> > pointer */
> > -
> > -
>
> Well, ZERO_OR_NULL_PTR checks for a little more than !addr, but I
> suppose that if anyone passes the result from kmalloc(0) to %ph,
> they'd
> better also pass 0 as the size, so the .field_width tests should be
> sufficient.
If we care about kmalloc(0) check we better to do this in pointer()?
> > - if (!IS_ENABLED(CONFIG_HAVE_CLK) || !clk)
> > - return string(buf, end, NULL, spec);
> > -
>
> Well, it may be safe, but removing the IS_ENABLED(CONFIG_HAVE_CLK)
> check
> means that clock() becomes a much bigger function when
> !IS_ENABLED(CONFIG_HAVE_CLK).
I return back this in v2.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* Re: [PATCH v1 04/25] lib/vsprintf: Print time and date in human readable format via %pt
From: Andy Shevchenko @ 2017-07-20 10:30 UTC (permalink / raw)
To: Arnd Bergmann, Andy Shevchenko
Cc: Rasmus Villemoes, Alexandre Belloni, Rasmus Villemoes,
Greg Kroah-Hartman, Andrew Morton, Linux Kernel Mailing List,
Alessandro Zummo, linux-rtc, Bartlomiej Zolnierkiewicz,
Dmitry Torokhov, Geert Uytterhoeven, Guan Xuetao, Ingo Molnar,
Jason Wessel, Jonathan Corbet, Jonathan Hunter,
Krzysztof Kozlowski, Rafael J. Wysocki
In-Reply-To: <CAK8P3a36FYzExs4UxB=dJ_rvEmvamq=__O9PXKgtpN=OqF6VSQ@mail.gmail.com>
On Thu, 2017-06-08 at 23:45 +0200, Arnd Bergmann wrote:
> On Thu, Jun 8, 2017 at 11:25 PM, Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Thu, Jun 8, 2017 at 11:42 PM, Rasmus Villemoes
> > <linux@rasmusvillemoes.dk> wrote:
> > > On Thu, Jun 08 2017, Andy Shevchenko <andy.shevchenko@gmail.com>
> > > wrote:
> > > > On Thu, Jun 8, 2017 at 9:41 PM, Alexandre Belloni
> > > > <alexandre.belloni@free-electrons.com> wrote:
> > > > > On 08/06/2017 at 20:57:05 +0300, Andy Shevchenko wrote:
> > > > > > On Thu, Jun 8, 2017 at 6:05 PM, Alexandre Belloni
> > > > > > <alexandre.belloni@free-electrons.com> wrote:
> > > > Yeah, but the problem is to pass the reference. All dances
> > > > around will
> > > > uglify the code.
> > > > (Obviously we can't pass timespec64/time64_t or anything longer
> > > > than
> > > > 32 bits as is in %p extension)
> > > I like that this gets rid of some mm/dd/yy and other more or less
> > > random
> > > format and ends up standardizing yyyy-mm-dd HH:MM:SS. However, I
> > > do
> > > think %pt should take either ktime_t or timespec64 (obviously by
> > > reference),
> >
> > I will try to look in this direction.
>
> sounds good.
>
> > > Please don't give people the option of eliding either the time or
> > > the
> > > date; I've spent too much time dealing with syslog files that
> > > don't
> > > include the year in the timestamps.
> >
> > I understand that, but see above.
>
> When we pretty-print a ktime_t, we probably want to leave out the high
> fields as well, as this often refers to a time interval, e.g. a few
> seconds.
> Even for absolute values, the start of ktime_t is usually not the 1970
> epoch but system boot, so we may not necessarily want the higher
> fields. I hoped to find some inspiration in the 'date' man page, which
> contains a lot of formatting options, but it's hard to translate that
> into
> a useful format string within the constraints of %p flags in printk.
Rasmus et al.,
Summarizing this discussion I would go forward with the following
- add one more letter in the format to provide argument type (timespec,
ktime, ...)
- make a config option to enable / disable this facility and select it
by users (and/or make it visible for configuration?)
- still leave possibility to print either date or time or both
- add suffix to print nanoseconds in cases where input has them (and
output is not just plain date)
- address other (technical) comments
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* Re: [PATCH v1 00/25] lib, rtc: Print rtc_time via %pt[dt][rv]
From: Andy Shevchenko @ 2017-07-20 10:33 UTC (permalink / raw)
To: Mark Salyzyn, Joe Perches, Rasmus Villemoes, Greg Kroah-Hartman,
Andrew Morton, linux-kernel, Alessandro Zummo, Alexandre Belloni,
linux-rtc
In-Reply-To: <861fe353-eb95-615f-b1dc-3326501342af@android.com>
On Tue, 2017-07-18 at 12:57 -0700, Mark Salyzyn wrote:
> On 07/18/2017 10:50 AM, Joe Perches wrote:
> > On Thu, 2017-06-08 at 16:47 +0300, Andy Shevchenko wrote:
> > > Recently I have noticed too many users of struct rtc_time that
> > > printing
> > > its content field by field.
> > >
> > > In this series I introduce %pt[dt][rv] specifier to make life a
> > > bit
> > > easier.
> >
> > Hey Andy.
> >
> > I just saw a patch with a printk for rtc time from Mark Salyzyn.
> > https://lkml.org/lkml/2017/7/18/885
> >
> > Any idea if you want to push this extension?
> >
> > I like the concept and still think it could be extended a bit more.
> >
> > from: https://lkml.org/lkml/2017/6/8/1134
> >
> > My preference would be for %pt[type]<output style>
> > where <type> is mandatory and could be:
> >
> > r for struct rtc_time
> > 6 for time64_t
> > k for ktime_t
> > T for struct timespec64
> > etc
> >
> > and <output style> has an unspecified default of
> > YYYY-MM-DD:hh:mm:ss
> >
> > Perhaps use the "date" formats without the leading
> > % uses for <output style> for additional styles.
> >
>
> YYYY-MM-DD hh:mm:ss.nnnnnnnnn ?
As a separate modifier, yes.
See my answer to subthread in patch 4.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* Re: [PATCH 4/4] time: rtc-lib: Add CONFIG_RTC_SHOW_TIME_RTC
From: Mark Salyzyn @ 2017-07-20 17:52 UTC (permalink / raw)
To: Pavel Machek
Cc: linux-kernel, rjw, len.brown, linux-pm, a.zummo,
alexandre.belloni, linux-rtc, prarit, andy.shevchenko,
Paul E. McKenney
In-Reply-To: <20170720082620.GB14149@amd>
On 07/20/2017 01:26 AM, Pavel Machek wrote:
>> +#if defined(CONFIG_RTC_SHOW_TIME_RTC)
>> + {
>> + struct rtc_time tm;
>> +
>> + rtc_time64_to_tm(ts.tv_sec, &tm);
>> + pr_info("%s %d-%02d-%02d %02d:%02d:%02d.%09lu UTC\n",
>> + prefix_msg ? prefix_msg : "Time:",
>> + tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
>> + tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec);
>> + }
>> +#else
>
> This was NAKed before. Are you even listening, or are you trying to
> flood us with enough mail so that someone applies your patches by
> mistake?
> Pavel
It was NAKed in the group, I put it aside in its own patch to keep from
throwing out the baby with the bathwater. Was hoping that a private
CONFIG_RTC_SHOW_TIME_RTC would be acceptable.
I guess not, topic is dead. A refresh is being tested that addresses
many of the other concerns.
-- Mark
^ permalink raw reply
* Re: [PATCH v1 00/25] lib, rtc: Print rtc_time via %pt[dt][rv]
From: Mark Salyzyn @ 2017-07-20 17:57 UTC (permalink / raw)
To: Andy Shevchenko, Joe Perches, Rasmus Villemoes,
Greg Kroah-Hartman, Andrew Morton, linux-kernel, Alessandro Zummo,
Alexandre Belloni, linux-rtc
In-Reply-To: <1500546822.29303.136.camel@linux.intel.com>
On 07/20/2017 03:33 AM, Andy Shevchenko wrote:
> On Tue, 2017-07-18 at 12:57 -0700, Mark Salyzyn wrote:
>> On 07/18/2017 10:50 AM, Joe Perches wrote:
>>> On Thu, 2017-06-08 at 16:47 +0300, Andy Shevchenko wrote:
>>>> Recently I have noticed too many users of struct rtc_time that
>>>> printing
>>>> its content field by field.
>>>>
>>>> In this series I introduce %pt[dt][rv] specifier to make life a
>>>> bit
>>>> easier.
>>> Hey Andy.
>>>
>>> I just saw a patch with a printk for rtc time from Mark Salyzyn.
>>> https://lkml.org/lkml/2017/7/18/885
>>>
>>> Any idea if you want to push this extension?
>>>
>>> I like the concept and still think it could be extended a bit more.
>>>
>>> from: https://lkml.org/lkml/2017/6/8/1134
>>>
>>> My preference would be for %pt[type]<output style>
>>> where <type> is mandatory and could be:
>>>
>>> r for struct rtc_time
>>> 6 for time64_t
>>> k for ktime_t
>>> T for struct timespec64
>>> etc
>>>
>>> and <output style> has an unspecified default of
>>> YYYY-MM-DD:hh:mm:ss
>>>
>>> Perhaps use the "date" formats without the leading
>>> % uses for <output style> for additional styles.
>>>
>> YYYY-MM-DD hh:mm:ss.nnnnnnnnn ?
> As a separate modifier, yes.
>
> See my answer to subthread in patch 4.
>
It would probably need to take struct timespec64 as an argument. Pass by
structure might be difficult to swallow, so pass by pointer?
As for my need for this in my suspend/resume/hibernate/restore patch
set, we have already been told three times to _not_ report wall clock
time. I could imagine being a consumer of it in the future if we have
difficulty migrating the analysis tools ... so tepid support from me.
-- Mark
^ permalink raw reply
* [PATCH 0/4] Make PL031 interrupt optional
From: Russell King - ARM Linux @ 2017-07-20 23:17 UTC (permalink / raw)
To: Alessandro Zummo
Cc: Alexandre Belloni, Linus Walleij, linux-arm-kernel, linux-rtc
There are some boards out there which have a PL031 RTC, but its
interrupt is not wired up. To support these, we need the PL031
to support the primecell without interrupts.
When no interrupt is present, there's little point exposing the
RTC's alarm capabilities, so we omit the alarm-related function
calls - the RTC merely becomes a source of time-of-day.
This patch series cleans pu the pl031 driver a little, and adds
support for this configuration.
drivers/rtc/rtc-pl031.c | 48 +++++++++++++++++++++++++++---------------------
1 file changed, 27 insertions(+), 21 deletions(-)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 1/4] rtc: pl031: constify amba_ids
From: Russell King @ 2017-07-20 23:18 UTC (permalink / raw)
To: Alessandro Zummo
Cc: Linus Walleij, Alexandre Belloni, linux-arm-kernel, linux-rtc
In-Reply-To: <20170720231745.GE31807@n2100.armlinux.org.uk>
The AMBA device IDs should be marked const. Make that so.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/rtc/rtc-pl031.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-pl031.c b/drivers/rtc/rtc-pl031.c
index e1687e19c59f..0d87b90b1903 100644
--- a/drivers/rtc/rtc-pl031.c
+++ b/drivers/rtc/rtc-pl031.c
@@ -446,7 +446,7 @@ static struct pl031_vendor_data stv2_pl031 = {
.irqflags = IRQF_SHARED | IRQF_COND_SUSPEND,
};
-static struct amba_id pl031_ids[] = {
+static const struct amba_id pl031_ids[] = {
{
.id = 0x00041031,
.mask = 0x000fffff,
--
2.7.4
^ permalink raw reply related
* [PATCH 2/4] rtc: pl031: use devm_* for allocating memory and mapping resource
From: Russell King @ 2017-07-20 23:18 UTC (permalink / raw)
To: Alessandro Zummo
Cc: Linus Walleij, Alexandre Belloni, linux-arm-kernel, linux-rtc
In-Reply-To: <20170720231745.GE31807@n2100.armlinux.org.uk>
Use the devm_* APIs for allocating memory and mapping the memory in
the probe function to relieve the driver from having to deal with
this in the cleanup paths.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/rtc/rtc-pl031.c | 19 +++++++------------
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/rtc/rtc-pl031.c b/drivers/rtc/rtc-pl031.c
index 0d87b90b1903..5960fbd08b05 100644
--- a/drivers/rtc/rtc-pl031.c
+++ b/drivers/rtc/rtc-pl031.c
@@ -310,8 +310,6 @@ static int pl031_remove(struct amba_device *adev)
device_init_wakeup(&adev->dev, false);
free_irq(adev->irq[0], ldata);
rtc_device_unregister(ldata->rtc);
- iounmap(ldata->base);
- kfree(ldata);
amba_release_regions(adev);
return 0;
@@ -322,25 +320,26 @@ static int pl031_probe(struct amba_device *adev, const struct amba_id *id)
int ret;
struct pl031_local *ldata;
struct pl031_vendor_data *vendor = id->data;
- struct rtc_class_ops *ops = &vendor->ops;
+ struct rtc_class_ops *ops;
unsigned long time, data;
ret = amba_request_regions(adev, NULL);
if (ret)
goto err_req;
- ldata = kzalloc(sizeof(struct pl031_local), GFP_KERNEL);
+ ldata = devm_kzalloc(&adev->dev, sizeof(struct pl031_local),
+ GFP_KERNEL);
if (!ldata) {
ret = -ENOMEM;
goto out;
}
ldata->vendor = vendor;
- ldata->base = ioremap(adev->res.start, resource_size(&adev->res));
-
+ ldata->base = devm_ioremap(&adev->dev, adev->res.start,
+ resource_size(&adev->res));
if (!ldata->base) {
ret = -ENOMEM;
- goto out_no_remap;
+ goto out;
}
amba_set_drvdata(adev, ldata);
@@ -378,7 +377,7 @@ static int pl031_probe(struct amba_device *adev, const struct amba_id *id)
THIS_MODULE);
if (IS_ERR(ldata->rtc)) {
ret = PTR_ERR(ldata->rtc);
- goto out_no_rtc;
+ goto out;
}
if (request_irq(adev->irq[0], pl031_interrupt,
@@ -391,10 +390,6 @@ static int pl031_probe(struct amba_device *adev, const struct amba_id *id)
out_no_irq:
rtc_device_unregister(ldata->rtc);
-out_no_rtc:
- iounmap(ldata->base);
-out_no_remap:
- kfree(ldata);
out:
amba_release_regions(adev);
err_req:
--
2.7.4
^ permalink raw reply related
* [PATCH 3/4] rtc: pl031: avoid exposing alarm if no interrupt
From: Russell King @ 2017-07-20 23:18 UTC (permalink / raw)
To: Alessandro Zummo
Cc: Linus Walleij, Alexandre Belloni, linux-arm-kernel, linux-rtc
In-Reply-To: <20170720231745.GE31807@n2100.armlinux.org.uk>
If the RTC has no interrupt, there is little point in exposing the RTC
alarm capabilities, as it can't be used as a wakeup source nor can it
deliver an event to userspace.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/rtc/rtc-pl031.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-pl031.c b/drivers/rtc/rtc-pl031.c
index 5960fbd08b05..64c77ec1b4ea 100644
--- a/drivers/rtc/rtc-pl031.c
+++ b/drivers/rtc/rtc-pl031.c
@@ -329,12 +329,14 @@ static int pl031_probe(struct amba_device *adev, const struct amba_id *id)
ldata = devm_kzalloc(&adev->dev, sizeof(struct pl031_local),
GFP_KERNEL);
- if (!ldata) {
+ ops = devm_kmemdup(&adev->dev, &vendor->ops, sizeof(vendor->ops),
+ GFP_KERNEL);
+ if (!ldata || !ops) {
ret = -ENOMEM;
goto out;
}
- ldata->vendor = vendor;
+ ldata->vendor = vendor;
ldata->base = devm_ioremap(&adev->dev, adev->res.start,
resource_size(&adev->res));
if (!ldata->base) {
@@ -372,6 +374,13 @@ static int pl031_probe(struct amba_device *adev, const struct amba_id *id)
}
}
+ if (!adev->irq[0]) {
+ /* When there's no interrupt, no point in exposing the alarm */
+ ops->read_alarm = NULL;
+ ops->set_alarm = NULL;
+ ops->alarm_irq_enable = NULL;
+ }
+
device_init_wakeup(&adev->dev, true);
ldata->rtc = rtc_device_register("pl031", &adev->dev, ops,
THIS_MODULE);
--
2.7.4
^ permalink raw reply related
* [PATCH 4/4] rtc: pl031: make interrupt optional
From: Russell King @ 2017-07-20 23:18 UTC (permalink / raw)
To: Alessandro Zummo
Cc: Linus Walleij, Alexandre Belloni, linux-arm-kernel, linux-rtc
In-Reply-To: <20170720231745.GE31807@n2100.armlinux.org.uk>
On some platforms, the interrupt for the PL031 is optional. Avoid
trying to claim the interrupt if it's not specified.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/rtc/rtc-pl031.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/rtc/rtc-pl031.c b/drivers/rtc/rtc-pl031.c
index 64c77ec1b4ea..82eb7da2c478 100644
--- a/drivers/rtc/rtc-pl031.c
+++ b/drivers/rtc/rtc-pl031.c
@@ -308,7 +308,8 @@ static int pl031_remove(struct amba_device *adev)
dev_pm_clear_wake_irq(&adev->dev);
device_init_wakeup(&adev->dev, false);
- free_irq(adev->irq[0], ldata);
+ if (adev->irq[0])
+ free_irq(adev->irq[0], ldata);
rtc_device_unregister(ldata->rtc);
amba_release_regions(adev);
@@ -389,12 +390,13 @@ static int pl031_probe(struct amba_device *adev, const struct amba_id *id)
goto out;
}
- if (request_irq(adev->irq[0], pl031_interrupt,
- vendor->irqflags, "rtc-pl031", ldata)) {
- ret = -EIO;
- goto out_no_irq;
+ if (adev->irq[0]) {
+ ret = request_irq(adev->irq[0], pl031_interrupt,
+ vendor->irqflags, "rtc-pl031", ldata);
+ if (ret)
+ goto out_no_irq;
+ dev_pm_set_wake_irq(&adev->dev, adev->irq[0]);
}
- dev_pm_set_wake_irq(&adev->dev, adev->irq[0]);
return 0;
out_no_irq:
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v1 00/25] lib, rtc: Print rtc_time via %pt[dt][rv]
From: Joe Perches @ 2017-07-21 4:07 UTC (permalink / raw)
To: Mark Salyzyn, Andy Shevchenko, Rasmus Villemoes,
Greg Kroah-Hartman, Andrew Morton, linux-kernel, Alessandro Zummo,
Alexandre Belloni, linux-rtc
In-Reply-To: <0b7ab8a2-9ec9-8d0b-3e45-20610f3ab598@android.com>
On Thu, 2017-07-20 at 10:57 -0700, Mark Salyzyn wrote:
> It would probably need to take struct timespec64 as an argument. Pass by
> structure might be difficult to swallow, so pass by pointer?
Every %p<foo> extension is passed via a pointer.
^ permalink raw reply
* [PATCH v3 1/8] Documentation: Add device tree binding for Goldfish RTC driver
From: Aleksandar Markovic @ 2017-07-21 16:53 UTC (permalink / raw)
To: linux-mips
Cc: Aleksandar Markovic, Miodrag Dinic, Goran Ferenc,
Alessandro Zummo, Alexandre Belloni, Bo Hu, David S. Miller,
devicetree, Douglas Leung, Greg Kroah-Hartman, James Hogan,
Jin Qian, linux-kernel, linux-rtc, Mark Rutland,
Mauro Carvalho Chehab, Paul Burton, Petar Jovanovic,
Raghu Gandham, Rob Herring
In-Reply-To: <1500656111-9520-1-git-send-email-aleksandar.markovic@rt-rk.com>
From: Aleksandar Markovic <aleksandar.markovic@imgtec.com>
Add documentation for DT binding of Goldfish RTC driver. The compatible
string used by OS for binding the driver is "google,goldfish-rtc".
Signed-off-by: Miodrag Dinic <miodrag.dinic@imgtec.com>
Signed-off-by: Goran Ferenc <goran.ferenc@imgtec.com>
Signed-off-by: Aleksandar Markovic <aleksandar.markovic@imgtec.com>
---
.../devicetree/bindings/rtc/google,goldfish-rtc.txt | 17 +++++++++++++++++
MAINTAINERS | 5 +++++
2 files changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/google,goldfish-rtc.txt
diff --git a/Documentation/devicetree/bindings/rtc/google,goldfish-rtc.txt b/Documentation/devicetree/bindings/rtc/google,goldfish-rtc.txt
new file mode 100644
index 0000000..634312d
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/google,goldfish-rtc.txt
@@ -0,0 +1,17 @@
+Android Goldfish RTC
+
+Android Goldfish RTC device used by Android emulator.
+
+Required properties:
+
+- compatible : should contain "google,goldfish-rtc"
+- reg : <registers mapping>
+- interrupts : <interrupt mapping>
+
+Example:
+
+ goldfish_timer@9020000 {
+ compatible = "google,goldfish-rtc";
+ reg = <0x9020000 0x1000>;
+ interrupts = <0x3>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 02994f4..847da3f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -841,6 +841,11 @@ S: Supported
F: drivers/android/
F: drivers/staging/android/
+ANDROID GOLDFISH RTC DRIVER
+M: Miodrag Dinic <miodrag.dinic@imgtec.com>
+S: Supported
+F: Documentation/devicetree/bindings/rtc/google,goldfish-rtc.txt
+
ANDROID ION DRIVER
M: Laura Abbott <labbott@redhat.com>
M: Sumit Semwal <sumit.semwal@linaro.org>
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/8] MIPS: ranchu: Add Goldfish RTC driver
From: Aleksandar Markovic @ 2017-07-21 16:53 UTC (permalink / raw)
To: linux-mips
Cc: Miodrag Dinic, Goran Ferenc, Aleksandar Markovic,
Alessandro Zummo, Alexandre Belloni, Bo Hu, David S. Miller,
Douglas Leung, Greg Kroah-Hartman, James Hogan, Jin Qian,
linux-kernel, linux-rtc, Mauro Carvalho Chehab, Paul Burton,
Petar Jovanovic, Raghu Gandham
In-Reply-To: <1500656111-9520-1-git-send-email-aleksandar.markovic@rt-rk.com>
From: Miodrag Dinic <miodrag.dinic@imgtec.com>
Add device driver for a virtual Goldfish RTC clock.
The driver can be built only if CONFIG_MIPS and CONFIG_GOLDFISH are
set. The compatible string used by OS for binding the driver is
defined as "google,goldfish-rtc".
Signed-off-by: Miodrag Dinic <miodrag.dinic@imgtec.com>
Signed-off-by: Goran Ferenc <goran.ferenc@imgtec.com>
Signed-off-by: Aleksandar Markovic <aleksandar.markovic@imgtec.com>
---
MAINTAINERS | 1 +
drivers/rtc/Kconfig | 8 ++
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-goldfish.c | 233 +++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 243 insertions(+)
create mode 100644 drivers/rtc/rtc-goldfish.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 847da3f..768426d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -845,6 +845,7 @@ ANDROID GOLDFISH RTC DRIVER
M: Miodrag Dinic <miodrag.dinic@imgtec.com>
S: Supported
F: Documentation/devicetree/bindings/rtc/google,goldfish-rtc.txt
+F: drivers/rtc/rtc-goldfish.c
ANDROID ION DRIVER
M: Laura Abbott <labbott@redhat.com>
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 72419ac..7cd27d3 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1780,5 +1780,13 @@ config RTC_DRV_HID_SENSOR_TIME
If this driver is compiled as a module, it will be named
rtc-hid-sensor-time.
+config RTC_DRV_GOLDFISH
+ tristate "Goldfish Real Time Clock"
+ depends on MIPS && GOLDFISH || COMPILE_TEST
+ help
+ Say yes to enable RTC driver for the Goldfish based virtual platform.
+
+ Goldfish is a code name for the virtual platform developed by Google
+ for Android emulation.
endif # RTC_CLASS
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index acd366b..d995d49 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -170,3 +170,4 @@ obj-$(CONFIG_RTC_DRV_WM8350) += rtc-wm8350.o
obj-$(CONFIG_RTC_DRV_X1205) += rtc-x1205.o
obj-$(CONFIG_RTC_DRV_XGENE) += rtc-xgene.o
obj-$(CONFIG_RTC_DRV_ZYNQMP) += rtc-zynqmp.o
+obj-$(CONFIG_RTC_DRV_GOLDFISH) += rtc-goldfish.o
diff --git a/drivers/rtc/rtc-goldfish.c b/drivers/rtc/rtc-goldfish.c
new file mode 100644
index 0000000..aa13062
--- /dev/null
+++ b/drivers/rtc/rtc-goldfish.c
@@ -0,0 +1,233 @@
+/* drivers/rtc/rtc-goldfish.c
+ *
+ * Copyright (C) 2007 Google, Inc.
+ * Copyright (C) 2017 Imagination Technologies Ltd.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/rtc.h>
+
+#define TIMER_TIME_LOW 0x00 /* get low bits of current time */
+ /* and update TIMER_TIME_HIGH */
+#define TIMER_TIME_HIGH 0x04 /* get high bits of time at last */
+ /* TIMER_TIME_LOW read */
+#define TIMER_ALARM_LOW 0x08 /* set low bits of alarm and */
+ /* activate it */
+#define TIMER_ALARM_HIGH 0x0c /* set high bits of next alarm */
+#define TIMER_IRQ_ENABLED 0x10
+#define TIMER_CLEAR_ALARM 0x14
+#define TIMER_ALARM_STATUS 0x18
+#define TIMER_CLEAR_INTERRUPT 0x1c
+
+struct goldfish_rtc {
+ void __iomem *base;
+ u32 irq;
+ struct rtc_device *rtc;
+};
+
+static int goldfish_rtc_read_alarm(struct device *dev,
+ struct rtc_wkalrm *alrm)
+{
+ u64 rtc_alarm;
+ u64 rtc_alarm_low;
+ u64 rtc_alarm_high;
+ void __iomem *base;
+ struct goldfish_rtc *rtcdrv;
+
+ rtcdrv = dev_get_drvdata(dev);
+ base = rtcdrv->base;
+
+ rtc_alarm_low = readl(base + TIMER_ALARM_LOW);
+ rtc_alarm_high = readl(base + TIMER_ALARM_HIGH);
+ rtc_alarm = (rtc_alarm_high << 32) | rtc_alarm_low;
+
+ do_div(rtc_alarm, NSEC_PER_SEC);
+ memset(alrm, 0, sizeof(struct rtc_wkalrm));
+
+ rtc_time_to_tm(rtc_alarm, &(alrm->time));
+
+ if (readl(base + TIMER_ALARM_STATUS))
+ alrm->enabled = 1;
+ else
+ alrm->enabled = 0;
+
+ return 0;
+}
+
+static int goldfish_rtc_set_alarm(struct device *dev,
+ struct rtc_wkalrm *alrm)
+{
+ struct goldfish_rtc *rtcdrv;
+ unsigned long rtc_alarm;
+ u64 rtc_status_reg;
+ void __iomem *base;
+ int ret = 0;
+
+ rtcdrv = dev_get_drvdata(dev);
+ base = rtcdrv->base;
+
+ if (alrm->enabled) {
+ ret = rtc_tm_to_time(&(alrm->time), &rtc_alarm);
+ if (ret != 0)
+ return ret;
+
+ rtc_alarm *= NSEC_PER_SEC;
+ writel((rtc_alarm >> 32), base + TIMER_ALARM_HIGH);
+ writel(rtc_alarm, base + TIMER_ALARM_LOW);
+ } else {
+ /*
+ * if this function was called with enabled=0
+ * then it could mean that the application is
+ * trying to cancel an ongoing alarm
+ */
+ rtc_status_reg = readl(base + TIMER_ALARM_STATUS);
+ if (rtc_status_reg)
+ writel(1, base + TIMER_CLEAR_ALARM);
+ }
+
+ return ret;
+}
+
+static int goldfish_rtc_alarm_irq_enable(struct device *dev,
+ unsigned int enabled)
+{
+ void __iomem *base;
+ struct goldfish_rtc *rtcdrv;
+
+ rtcdrv = dev_get_drvdata(dev);
+ base = rtcdrv->base;
+
+ if (enabled)
+ writel(1, base + TIMER_IRQ_ENABLED);
+ else
+ writel(0, base + TIMER_IRQ_ENABLED);
+
+ return 0;
+
+}
+
+static irqreturn_t goldfish_rtc_interrupt(int irq, void *dev_id)
+{
+ struct goldfish_rtc *rtcdrv = dev_id;
+ void __iomem *base = rtcdrv->base;
+
+ writel(1, base + TIMER_CLEAR_INTERRUPT);
+
+ rtc_update_irq(rtcdrv->rtc, 1, RTC_IRQF | RTC_AF);
+
+ return IRQ_HANDLED;
+}
+
+static int goldfish_rtc_read_time(struct device *dev, struct rtc_time *tm)
+{
+ struct goldfish_rtc *rtcdrv;
+ void __iomem *base;
+ u64 time_high;
+ u64 time_low;
+ u64 time;
+
+ rtcdrv = dev_get_drvdata(dev);
+ base = rtcdrv->base;
+
+ time_low = readl(base + TIMER_TIME_LOW);
+ time_high = readl(base + TIMER_TIME_HIGH);
+ time = (time_high << 32) | time_low;
+
+ do_div(time, NSEC_PER_SEC);
+
+ rtc_time_to_tm(time, tm);
+
+ return 0;
+}
+
+static int goldfish_rtc_set_time(struct device *dev, struct rtc_time *tm)
+{
+ struct goldfish_rtc *rtcdrv;
+ void __iomem *base;
+ unsigned long now;
+ int ret;
+
+ rtcdrv = dev_get_drvdata(dev);
+ base = rtcdrv->base;
+
+ ret = rtc_tm_to_time(tm, &now);
+ if (ret == 0) {
+ now *= NSEC_PER_SEC;
+ writel((now >> 32), base + TIMER_TIME_HIGH);
+ writel(now, base + TIMER_TIME_LOW);
+ }
+
+ return ret;
+}
+
+static const struct rtc_class_ops goldfish_rtc_ops = {
+ .read_time = goldfish_rtc_read_time,
+ .set_time = goldfish_rtc_set_time,
+ .read_alarm = goldfish_rtc_read_alarm,
+ .set_alarm = goldfish_rtc_set_alarm,
+ .alarm_irq_enable = goldfish_rtc_alarm_irq_enable
+};
+
+static int goldfish_rtc_probe(struct platform_device *pdev)
+{
+ struct resource *r;
+ struct goldfish_rtc *rtcdrv;
+ int err;
+
+ rtcdrv = devm_kzalloc(&pdev->dev, sizeof(*rtcdrv), GFP_KERNEL);
+ if (rtcdrv == NULL)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, rtcdrv);
+
+ r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (r == NULL)
+ return -ENODEV;
+
+ rtcdrv->base = devm_ioremap_resource(&pdev->dev, r);
+ if (IS_ERR(rtcdrv->base))
+ return -ENODEV;
+
+ rtcdrv->irq = platform_get_irq(pdev, 0);
+ if (rtcdrv->irq < 0)
+ return -ENODEV;
+
+ rtcdrv->rtc = devm_rtc_device_register(&pdev->dev, pdev->name,
+ &goldfish_rtc_ops, THIS_MODULE);
+ if (IS_ERR(rtcdrv->rtc))
+ return PTR_ERR(rtcdrv->rtc);
+
+ err = devm_request_irq(&pdev->dev, rtcdrv->irq, goldfish_rtc_interrupt,
+ 0, pdev->name, rtcdrv);
+ if (err)
+ return err;
+
+ return 0;
+}
+
+static const struct of_device_id goldfish_rtc_of_match[] = {
+ { .compatible = "google,goldfish-rtc", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, goldfish_rtc_of_match);
+
+static struct platform_driver goldfish_rtc = {
+ .probe = goldfish_rtc_probe,
+ .driver = {
+ .name = "goldfish_rtc",
+ .of_match_table = goldfish_rtc_of_match,
+ }
+};
+
+module_platform_driver(goldfish_rtc);
--
2.7.4
^ permalink raw reply related
* Re: Hardware specific rtc regression in v4.4.76
From: Alexandre Belloni @ 2017-07-22 21:58 UTC (permalink / raw)
To: elseifthen; +Cc: rtc
In-Reply-To: <5c2ebf93-e45b-bc2d-e13b-618fdc12b3f3@gmx.com>
Hi,
Thanks for the report.
On 06/07/2017 at 15:16:11 -0400, elseifthen@gmx.com wrote:
> There appears to be a hardware specific rtc regression in v4.4.76.
>
> Introduced in v4.4.52 by:
>
> commit f0414c1f8bb7a4e69064296f460773170c5435ac
> Author: Colin Ian King <colin.king@canonical.com>
> Date: Mon May 16 17:22:54 2016 +0100
>
> rtc: interface: ignore expired timers when enqueuing new timers
>
> commit 2b2f5ff00f63847d95adad6289bd8b05f5983dd5 upstream.
>
> 8< ---
>
> The problem does not appear to be in v4.9.x kernels.
>
> Maybe v4.4.76 is missing one of these?
> http://marc.info/?l=linux-rtc&m=149489307123605&w=2
> Which also includes the commit in question.
>
> See this thread for more details:
> https://www.linuxquestions.org/questions/slackware-14/slow-hwclock-systohc-on-reboot-shutdown-4175609040/
>
> Note: I am not the one having this issue. I'm only reporting it, so any
> questions would need to be asked in the above thread. Or perhaps the
> person with the problem will follow this email thread. I will post a
> link to it for them.
>
I can see a small issue with f0414c1f8bb7a4e69064296f460773170c5435ac
but I'm not sure why it would be hit on v4.4 and not v4.9.
Maybe one has CONFIG_RTC_INTF_DEV_UIE_EMUL and not the other one.
Could you try with the following on top of v4.4.57 (or any other
v4.4.x):
--- a/drivers/rtc/interface.c
+++ b/drivers/rtc/interface.c
@@ -764,7 +764,7 @@ static int rtc_timer_enqueue(struct rtc_device *rtc,
struct rtc_timer *timer)
}
timerqueue_add(&rtc->timerqueue, &timer->node);
- if (!next) {
+ if (!next || ktime_before(timer->node.expires, next->expires)) {
struct rtc_wkalrm alarm;
int err;
alarm.time = rtc_ktime_to_tm(timer->node.expires);
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Duplicated drivers for Epson RX8025 RTC support
From: Heiner Kallweit @ 2017-07-23 20:15 UTC (permalink / raw)
To: Alexandre Belloni; +Cc: Matthias Fuchs, linux-rtc
When working on refactoring parts of the ds1307 I stumbled across the fact
that there are two rtc drivers claiming to support the Epson RX8025 chip.
1. ds1307 claims to support also this chip. Support was added in 2009,
however I have doubts that it actually works.
RX8025 needs a special addressing mode (register address has to be
left-shifted by 4 bits) which is implemented for both control
registers but not for the standard registers.
Also support for this chip misses the fix from patch 2e10e74df72
("rtc: rx8025: fix transfer mode")
I'm curious whether support for this chip was ever tested, commit message
of a216685818a5 "rtc: add EPSON RX8025 support to DS1307 RTC driver"
does not mention that this piece of code was tested with any device
with this chip.
2. There's a separate driver for this chip (rtc-rx8025), also added in 2009.
This drivers is actively maintained.
The separate driver mentions that it supports SA/NB variants of the chip.
There's no info regarding supported chip variants in the ds1307-integrated
driver. So there is a small chance that both drivers support different
chip variants (in this case however the ds1307-integrated driver should
clearly mention this, also in the Kconfig help text).
For me it's more likely that both drivers try support the same chip.
Having said that I would propose to remove (rudimentary) RX8025 support
in ds1307. As a first step we could leave the code in but use a WARN_ON
to notify potential users that this code is deprecated and they should
use the separate driver instead.
Rgds, Heiner
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox