From: Steve Muckle <smuckle@google.com>
To: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>,
linux-kernel@vger.kernel.org, linux-rtc@vger.kernel.org,
kernel-team@android.com
Subject: Re: [PATCH] rtc: class: support hctosys from modular RTC drivers
Date: Fri, 27 Dec 2019 12:26:58 -0800 [thread overview]
Message-ID: <e43fd369-f0ad-f8bb-be8a-1a3ca038af44@google.com> (raw)
In-Reply-To: <20191115133627.GT3572@piout.net>
(accidentally sent as HTML, resending in text)
On 11/15/19 5:36 AM, Alexandre Belloni wrote:
> On 06/11/2019 15:37:49-0800, Steve Muckle wrote:
>> On 11/6/19 3:19 PM, Alexandre Belloni wrote:
>>> On 06/11/2019 11:46:25-0800, Steve Muckle wrote:
>>>> Due to distribution constraints it may not be possible to statically
>>>> compile the required RTC driver into the kernel.
>>>>
>>>> Expand RTC_HCTOSYS support to cover all RTC devices (statically compiled
>>>> or not) by checking at the end of RTC device registration whether the
>>>> time should be synced.
>>>>
>>>
>>> This does not really help distributions because most of them will still
>>> have "rtc0" hardcoded and rtc0 is often the rtc that shouldn't be used.
>>
>> Just for my own edification, why is that? Is rtc0 normally useless on PC for
>> some reason?
>>
>
> On PC, rtc0 is probably fine which is not the case for other
> architectures where rtc0 is the SoC RTC and is often not battery backed.
>
>> On the platforms I'm working with I believe it can be assured that rtc0 will
>> be the correct rtc. That doesn't help typical distributions though.
>>
>> What about a kernel parameter to optionally override the rtc hctosys device
>> at runtime?
>>
>
> What about keeping that in userspace instead which is way easier than
> messing with kernel parameters?
This should ideally happen before file systems are mounted so I don't
see many alternatives for communicating which RTC should be used.
Android uses the kernel command line for userspace parameters as well
and that's an option but that defeats part of the value of doing it in
userspace IMO. There's also device tree but I'm not sure this belongs there.
Hctosys is also saving and restoring the system time on suspend/resume.
It seems more efficient to me to do this (which happens very frequently
on an Android device) in the kernel as opposed to in userspace.
If I set the initial system time from the rtc in userspace but continue
to rely on the hctosys suspend/resume code, as it stands there will be a
window after the rtc driver is loaded but before the system time is set
where if suspend is entered, the correct time in the rtc will be lost.
>>> Can't you move away from HCTOSYS and do the correct thing in userspace
>>> instead of the crap hctosys is doing?
>>
>> Yes, I just figured it's a small change, and if hctosys can be made to work
>> might as well use that.
>
> The fact is that hctosys is more related to time keeping than it is to
> the RTC subsytem. It also does a very poor job setting the system time
> because adding 0.5s is not the smartest thing to do. The rtc granularity
> is indeed 1 second but is can be very precisely set.
No argument with that, but millions of devices successfully rely on it
today. AFAICT this simple patch doesn't make anything worse. Together
with a change to support a kernel parameter for runtime rtc selection,
it should allow RTC drivers to be modularized on many systems. Can it be
adopted as a stopgap measure?
next prev parent reply other threads:[~2019-12-27 20:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-06 19:46 [PATCH] rtc: class: support hctosys from modular RTC drivers Steve Muckle
2019-11-06 23:19 ` Alexandre Belloni
2019-11-06 23:37 ` Steve Muckle
2019-11-15 13:36 ` Alexandre Belloni
2019-12-27 20:26 ` Steve Muckle [this message]
2020-01-31 18:35 ` Steve Muckle
[not found] ` <CAL21Ktd3JmRbkwPCCb77knXg4AWi0vWdU147sVaDaoWeEMauDQ@mail.gmail.com>
2020-03-23 20:06 ` Alexandre Belloni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e43fd369-f0ad-f8bb-be8a-1a3ca038af44@google.com \
--to=smuckle@google.com \
--cc=a.zummo@towertech.it \
--cc=alexandre.belloni@bootlin.com \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).