> Still, you're right that adding the GET_TIME check wouldn't hurt... at
> worst it just does nothing. I'll try it out.
Hmm... so it basically works (when you hack the RTC read out of the
firmware), but only on reboot for some reason (which makes it way less
useful). After a full power off I'm rea
> Technically you could still implement this and if firmware happens to
> read the RTC (and doesn't correct things) then we won't be able to
> correct things. ...but certainly if you read the old time and then
> the new time and the old time was < 11/31 and the new time was >=
> 11/31 you know you
Julius,
On Mon, Dec 7, 2015 at 12:28 PM, Julius Werner wrote:
>> I was presuming that alarms were never set at power off time unless
>> power off happened due to an exceptional case. AKA: normal Linux
>> shutdown disables all alarms.
>
> Hmm... maybe I misunderstand how this works. Are alarms ne
[+Alexandre... sorry, didn't notice that you somehow fell off the
thread again, but I presume you get rtc-linux anyway]
> Agreed, scheduling alarms in the future is also an important point. So
> I guess I'll update the patch to fix alarm scheduling and S3 as well,
> and we'll just ignore S5 as inf
> I was presuming that alarms were never set at power off time unless
> power off happened due to an exceptional case. AKA: normal Linux
> shutdown disables all alarms.
Hmm... maybe I misunderstand how this works. Are alarms never used to
wake from S5? (It doesn't seem to work on my HiSense Chrom
On 12/07/2015 10:52 AM, Doug Anderson wrote:
Hi,
On Sun, Dec 6, 2015 at 6:50 PM, Doug Anderson wrote:
Chris,
On Sun, Dec 6, 2015 at 5:33 PM, Chris Zhong wrote:
Hi Doug
RK808 has a shadowed register for saving a "frozen" RTC time.
When we setting "GET_TIME" to 1, the time will save in thi
Hi,
On Sun, Dec 6, 2015 at 6:50 PM, Doug Anderson wrote:
> Chris,
>
> On Sun, Dec 6, 2015 at 5:33 PM, Chris Zhong wrote:
>> Hi Doug
>>
>> RK808 has a shadowed register for saving a "frozen" RTC time.
>> When we setting "GET_TIME" to 1, the time will save in this shadowed
>> register. So if we do
Chris,
On Sun, Dec 6, 2015 at 5:33 PM, Chris Zhong wrote:
> Hi Doug
>
> RK808 has a shadowed register for saving a "frozen" RTC time.
> When we setting "GET_TIME" to 1, the time will save in this shadowed
> register. So if we do not set the "GET_TIME", we always get the last time.
>
> read the ol
Hi Doug
RK808 has a shadowed register for saving a "frozen" RTC time.
When we setting "GET_TIME" to 1, the time will save in this shadowed
register. So if we do not set the "GET_TIME", we always get the last time.
read the old time before "get_time", and then read the time again for new
time. If
Julius,
On Fri, Dec 4, 2015 at 11:17 PM, Julius Werner wrote:
>> If you set the alarm
>> for Dec 25th and it's currently Oct 31st then you'll have to adjust in
>> the alarm code and you'll really set it for Dec 24th. As per above,
>> we're in S3 (presumably) or have some persistent kernel state
> If you set the alarm
> for Dec 25th and it's currently Oct 31st then you'll have to adjust in
> the alarm code and you'll really set it for Dec 24th. As per above,
> we're in S3 (presumably) or have some persistent kernel state so we
> know to adjust everything when we wake up (even if we wake u
Hi,
On Fri, Dec 4, 2015 at 8:02 PM, Doug Anderson wrote:
> Hi,
>
> On Fri, Dec 4, 2015 at 5:54 PM, Julius Werner wrote:
>>> How would such a hook work? If userspace sees the system suspend on
>>> Nov 30th and sees the system wake up on Dec 1st, how does it know
>>> whether it should adjust? If
Hi,
On Fri, Dec 4, 2015 at 5:54 PM, Julius Werner wrote:
>> How would such a hook work? If userspace sees the system suspend on
>> Nov 30th and sees the system wake up on Dec 1st, how does it know
>> whether it should adjust? If it's truly Dec 1st then the kernel will
>> have adjusted the date
> How would such a hook work? If userspace sees the system suspend on
> Nov 30th and sees the system wake up on Dec 1st, how does it know
> whether it should adjust? If it's truly Dec 1st then the kernel will
> have adjusted the date from Nov 31st to Dec 1st. If it's truly Dec
> 2nd then the ker
Julius,
On Fri, Dec 4, 2015 at 4:25 PM, Julius Werner wrote:
>> If a device is in S3 for the whole day that the glitch occurs and then
>> we wake up then we'll end up thinking it's Dec 1st instead of Dec 2nd,
>> right? That case _could_ be handled by knowing that the last time we
>> read the clo
> If a device is in S3 for the whole day that the glitch occurs and then
> we wake up then we'll end up thinking it's Dec 1st instead of Dec 2nd,
> right? That case _could_ be handled by knowing that the last time we
> read the clock it was before 12/1 and that this time it is after
> 11/30. Then
Julius,
On Wed, Dec 2, 2015 at 5:53 PM, Julius Werner wrote:
> In Fuzhou, China, the month of November seems to be having 31 days.
> That's nice and all (I'm sure you can get a lot more done in a year that
> way), but back here in other parts of the world we are not so lucky.
> Therefore, if we r
> I would have liked to be in copy of that mail. Maybe you used
> get_maintainers on an old tree?
Oops, yes, sorry, I ran it on a 3.14 backport and then just added
people I found in older patches for that file.
> I hope reading the time properly fails thanks to the rtc_valid_tm(tm) in
> __rtc_rea
Hi,
I would have liked to be in copy of that mail. Maybe you used
get_maintainers on an old tree?
On 02/12/2015 at 17:53:04 -0800, Julius Werner wrote :
> In Fuzhou, China, the month of November seems to be having 31 days.
> That's nice and all (I'm sure you can get a lot more done in a year that
In Fuzhou, China, the month of November seems to be having 31 days.
That's nice and all (I'm sure you can get a lot more done in a year that
way), but back here in other parts of the world we are not so lucky.
Therefore, if we read that date from the RTC we should correct it to
December 1st.
This
20 matches
Mail list logo
