On Thu, Apr 25, 2013 at 01:03:00PM -0700, John Stultz wrote:
> On 04/25/2013 11:33 AM, Jason Gunthorpe wrote:
> >John mentioned they might be kept for embedded - eg size reduction.
> >The issue with that idea is if you do not enable the class RTC
> >subsystem then there is no way for a small
On Thu, Apr 25, 2013 at 12:54:15PM -0700, John Stultz wrote:
> That said, I suspect we need RTC equivalents to the xen/kvm/vrtc
> logic in the x86 persistent_clock code before we'll be able to tear
> out the persistent_clock code (I think just cmos and efi have RTC
> drivers).
Aha! Maybe this is
On 04/25/2013 11:33 AM, Jason Gunthorpe wrote:
John mentioned they might be kept for embedded - eg size reduction.
The issue with that idea is if you do not enable the class RTC
subsystem then there is no way for a small embedded userspace to set
the RTC. The /dev/rtc* device obviously goes
On 04/25/2013 12:45 PM, Kay Sievers wrote:
On Thu, Apr 25, 2013 at 8:33 PM, Jason Gunthorpe
wrote:
So, my conclusion is nobody with a RTC looking for space savings, will
disable CONFIG_RTC, which means we can safely rely on
CONFIG_RTC_SYSTOHC to do this work. To that end, I would encourage
On Thu, Apr 25, 2013 at 8:33 PM, Jason Gunthorpe
wrote:
> So, my conclusion is nobody with a RTC looking for space savings, will
> disable CONFIG_RTC, which means we can safely rely on
> CONFIG_RTC_SYSTOHC to do this work. To that end, I would encourage
> everyone who sets
On Thu, Apr 25, 2013 at 09:13:32AM -0700, John Stultz wrote:
> On 04/25/2013 12:11 AM, Alexander Holler wrote:
> >Am 24.04.2013 18:07, schrieb John Stultz:
> >
> >>>And why is RTC_SYSTOHC now gone on x86?
> >>
> >>So summarizing the above, because as much as I'm aware, its always been
>
On 04/25/2013 12:11 AM, Alexander Holler wrote:
Am 24.04.2013 18:07, schrieb John Stultz:
And why is RTC_SYSTOHC now gone on x86?
So summarizing the above, because as much as I'm aware, its always been
redundant and unnecessary on x86. Thus being able at build time to mark
it as unnecessary
On Thu, Apr 25, 2013 at 9:11 AM, Alexander Holler wrote:
> Hmm, I thought RTC_SYSTOHC was there to update the used RTC clock with the
> time from NTP (and liked that).
That seems to have the nice self-explaining name CONFIG_GENERIC_CMOS_UPDATE. :)
> Therefor I don't understand why it is
>
Am 24.04.2013 18:07, schrieb John Stultz:
And why is RTC_SYSTOHC now gone on x86?
So summarizing the above, because as much as I'm aware, its always been
redundant and unnecessary on x86. Thus being able at build time to mark
it as unnecessary was attractive, since it reduced the code paths
Am 24.04.2013 18:07, schrieb John Stultz:
And why is RTC_SYSTOHC now gone on x86?
So summarizing the above, because as much as I'm aware, its always been
redundant and unnecessary on x86. Thus being able at build time to mark
it as unnecessary was attractive, since it reduced the code paths
On Thu, Apr 25, 2013 at 9:11 AM, Alexander Holler hol...@ahsoftware.de wrote:
Hmm, I thought RTC_SYSTOHC was there to update the used RTC clock with the
time from NTP (and liked that).
That seems to have the nice self-explaining name CONFIG_GENERIC_CMOS_UPDATE. :)
Therefor I don't understand
On 04/25/2013 12:11 AM, Alexander Holler wrote:
Am 24.04.2013 18:07, schrieb John Stultz:
And why is RTC_SYSTOHC now gone on x86?
So summarizing the above, because as much as I'm aware, its always been
redundant and unnecessary on x86. Thus being able at build time to mark
it as unnecessary
On Thu, Apr 25, 2013 at 09:13:32AM -0700, John Stultz wrote:
On 04/25/2013 12:11 AM, Alexander Holler wrote:
Am 24.04.2013 18:07, schrieb John Stultz:
And why is RTC_SYSTOHC now gone on x86?
So summarizing the above, because as much as I'm aware, its always been
redundant and unnecessary
On Thu, Apr 25, 2013 at 8:33 PM, Jason Gunthorpe
jguntho...@obsidianresearch.com wrote:
So, my conclusion is nobody with a RTC looking for space savings, will
disable CONFIG_RTC, which means we can safely rely on
CONFIG_RTC_SYSTOHC to do this work. To that end, I would encourage
everyone who
On 04/25/2013 12:45 PM, Kay Sievers wrote:
On Thu, Apr 25, 2013 at 8:33 PM, Jason Gunthorpe
jguntho...@obsidianresearch.com wrote:
So, my conclusion is nobody with a RTC looking for space savings, will
disable CONFIG_RTC, which means we can safely rely on
CONFIG_RTC_SYSTOHC to do this work. To
On 04/25/2013 11:33 AM, Jason Gunthorpe wrote:
John mentioned they might be kept for embedded - eg size reduction.
The issue with that idea is if you do not enable the class RTC
subsystem then there is no way for a small embedded userspace to set
the RTC. The /dev/rtc* device obviously goes
On Thu, Apr 25, 2013 at 12:54:15PM -0700, John Stultz wrote:
That said, I suspect we need RTC equivalents to the xen/kvm/vrtc
logic in the x86 persistent_clock code before we'll be able to tear
out the persistent_clock code (I think just cmos and efi have RTC
drivers).
Aha! Maybe this is why
On Thu, Apr 25, 2013 at 01:03:00PM -0700, John Stultz wrote:
On 04/25/2013 11:33 AM, Jason Gunthorpe wrote:
John mentioned they might be kept for embedded - eg size reduction.
The issue with that idea is if you do not enable the class RTC
subsystem then there is no way for a small embedded
On Wed, Apr 24, 2013 at 6:30 PM, John Stultz wrote:
>> Until the above commits we always needed:
>>CONFIG_RTC_HCTOSYS=y
>>CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
>> to get the system time correctly initialized at bootup on x86.
> So... always needed to get system time correctly initialized?
On 04/24/2013 09:32 AM, Kay Sievers wrote:
On Wed, Apr 24, 2013 at 6:07 PM, John Stultz wrote:
So summarizing the above, because as much as I'm aware, its always been
redundant and unnecessary on x86. Thus being able at build time to mark it
as unnecessary was attractive, since it reduced
On 04/23/2013 08:51 PM, Kay Sievers wrote:
On Wed, Apr 24, 2013 at 5:33 AM, Kay Sievers wrote:
Also:
$ cat /sys/class/rtc/rtc0/hctosys
0
always carried "1", and this now breaks setups which expect an
automatically created symlink /dev/rtc to the actual "system rtc".
We used to do this
On Wed, Apr 24, 2013 at 6:07 PM, John Stultz wrote:
> So summarizing the above, because as much as I'm aware, its always been
> redundant and unnecessary on x86. Thus being able at build time to mark it
> as unnecessary was attractive, since it reduced the code paths running at
>
On 04/23/2013 08:33 PM, Kay Sievers wrote:
On Wed, Apr 24, 2013 at 5:19 AM, John Stultz wrote:
On 04/23/2013 08:05 PM, Kay Sievers wrote:
On Wed, Apr 24, 2013 at 4:43 AM, John Stultz
wrote:
On 04/23/2013 06:34 PM, Kay Sievers wrote:
Hey,
what's the intention of:
On 04/23/2013 10:12 PM, Alexander Holler wrote:
Hello,
Am 24.04.2013 05:19, schrieb John Stultz:
On x86 the persistent_clock() is backed by the
CMOS/EFI/kvm-wall/xen/vrtc clock (all via x86_platform.get_wallclock)
should be present and we'll initialize the time in timekeeping_init()
there.
On 04/23/2013 10:12 PM, Alexander Holler wrote:
Hello,
Am 24.04.2013 05:19, schrieb John Stultz:
On x86 the persistent_clock() is backed by the
CMOS/EFI/kvm-wall/xen/vrtc clock (all via x86_platform.get_wallclock)
should be present and we'll initialize the time in timekeeping_init()
there.
On 04/23/2013 08:33 PM, Kay Sievers wrote:
On Wed, Apr 24, 2013 at 5:19 AM, John Stultz john.stu...@linaro.org wrote:
On 04/23/2013 08:05 PM, Kay Sievers wrote:
On Wed, Apr 24, 2013 at 4:43 AM, John Stultz john.stu...@linaro.org
wrote:
On 04/23/2013 06:34 PM, Kay Sievers wrote:
Hey,
what's
On Wed, Apr 24, 2013 at 6:07 PM, John Stultz john.stu...@linaro.org wrote:
So summarizing the above, because as much as I'm aware, its always been
redundant and unnecessary on x86. Thus being able at build time to mark it
as unnecessary was attractive, since it reduced the code paths running
On 04/23/2013 08:51 PM, Kay Sievers wrote:
On Wed, Apr 24, 2013 at 5:33 AM, Kay Sievers k...@vrfy.org wrote:
Also:
$ cat /sys/class/rtc/rtc0/hctosys
0
always carried 1, and this now breaks setups which expect an
automatically created symlink /dev/rtc to the actual system rtc.
We used to
On 04/24/2013 09:32 AM, Kay Sievers wrote:
On Wed, Apr 24, 2013 at 6:07 PM, John Stultz john.stu...@linaro.org wrote:
So summarizing the above, because as much as I'm aware, its always been
redundant and unnecessary on x86. Thus being able at build time to mark it
as unnecessary was
On Wed, Apr 24, 2013 at 6:30 PM, John Stultz john.stu...@linaro.org wrote:
Until the above commits we always needed:
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE=rtc0
to get the system time correctly initialized at bootup on x86.
So... always needed to get system time correctly
Hello,
Am 24.04.2013 05:19, schrieb John Stultz:
On x86 the persistent_clock() is backed by the
CMOS/EFI/kvm-wall/xen/vrtc clock (all via x86_platform.get_wallclock)
should be present and we'll initialize the time in timekeeping_init()
there.
Its only systems where there isn't a
On Wed, Apr 24, 2013 at 5:33 AM, Kay Sievers wrote:
> Also:
> $ cat /sys/class/rtc/rtc0/hctosys
> 0
> always carried "1", and this now breaks setups which expect an
> automatically created symlink /dev/rtc to the actual "system rtc".
We used to do this in upstream standard udev rules:
On Wed, Apr 24, 2013 at 5:19 AM, John Stultz wrote:
> On 04/23/2013 08:05 PM, Kay Sievers wrote:
>>
>> On Wed, Apr 24, 2013 at 4:43 AM, John Stultz
>> wrote:
>>>
>>> On 04/23/2013 06:34 PM, Kay Sievers wrote:
Hey,
what's the intention of:
On 04/23/2013 08:05 PM, Kay Sievers wrote:
On Wed, Apr 24, 2013 at 4:43 AM, John Stultz wrote:
On 04/23/2013 06:34 PM, Kay Sievers wrote:
Hey,
what's the intention of:
e90c83f757fffdacec8b3c5eee5617dcc038338f ?
x86: Select HAS_PERSISTENT_CLOCK on x86
It unconditionally sets:
On Wed, Apr 24, 2013 at 4:43 AM, John Stultz wrote:
> On 04/23/2013 06:34 PM, Kay Sievers wrote:
>>
>> Hey,
>>
>> what's the intention of:
>>e90c83f757fffdacec8b3c5eee5617dcc038338f ?
>>x86: Select HAS_PERSISTENT_CLOCK on x86
>>
>> It unconditionally sets:
>>HAS_PERSISTENT_CLOCK
>>
On 04/23/2013 06:34 PM, Kay Sievers wrote:
Hey,
what's the intention of:
e90c83f757fffdacec8b3c5eee5617dcc038338f ?
x86: Select HAS_PERSISTENT_CLOCK on x86
It unconditionally sets:
HAS_PERSISTENT_CLOCK
but:
RTC_SYSTOHC
got a depends on !HAS_PERSISTENT_CLOCK
This makes it
Hey,
what's the intention of:
e90c83f757fffdacec8b3c5eee5617dcc038338f ?
x86: Select HAS_PERSISTENT_CLOCK on x86
It unconditionally sets:
HAS_PERSISTENT_CLOCK
but:
RTC_SYSTOHC
got a depends on !HAS_PERSISTENT_CLOCK
This makes it impossible to sync the system time from the RTC on x86.
Hey,
what's the intention of:
e90c83f757fffdacec8b3c5eee5617dcc038338f ?
x86: Select HAS_PERSISTENT_CLOCK on x86
It unconditionally sets:
HAS_PERSISTENT_CLOCK
but:
RTC_SYSTOHC
got a depends on !HAS_PERSISTENT_CLOCK
This makes it impossible to sync the system time from the RTC on x86.
On 04/23/2013 06:34 PM, Kay Sievers wrote:
Hey,
what's the intention of:
e90c83f757fffdacec8b3c5eee5617dcc038338f ?
x86: Select HAS_PERSISTENT_CLOCK on x86
It unconditionally sets:
HAS_PERSISTENT_CLOCK
but:
RTC_SYSTOHC
got a depends on !HAS_PERSISTENT_CLOCK
This makes it
On Wed, Apr 24, 2013 at 4:43 AM, John Stultz john.stu...@linaro.org wrote:
On 04/23/2013 06:34 PM, Kay Sievers wrote:
Hey,
what's the intention of:
e90c83f757fffdacec8b3c5eee5617dcc038338f ?
x86: Select HAS_PERSISTENT_CLOCK on x86
It unconditionally sets:
HAS_PERSISTENT_CLOCK
On 04/23/2013 08:05 PM, Kay Sievers wrote:
On Wed, Apr 24, 2013 at 4:43 AM, John Stultz john.stu...@linaro.org wrote:
On 04/23/2013 06:34 PM, Kay Sievers wrote:
Hey,
what's the intention of:
e90c83f757fffdacec8b3c5eee5617dcc038338f ?
x86: Select HAS_PERSISTENT_CLOCK on x86
It
On Wed, Apr 24, 2013 at 5:19 AM, John Stultz john.stu...@linaro.org wrote:
On 04/23/2013 08:05 PM, Kay Sievers wrote:
On Wed, Apr 24, 2013 at 4:43 AM, John Stultz john.stu...@linaro.org
wrote:
On 04/23/2013 06:34 PM, Kay Sievers wrote:
Hey,
what's the intention of:
On Wed, Apr 24, 2013 at 5:33 AM, Kay Sievers k...@vrfy.org wrote:
Also:
$ cat /sys/class/rtc/rtc0/hctosys
0
always carried 1, and this now breaks setups which expect an
automatically created symlink /dev/rtc to the actual system rtc.
We used to do this in upstream standard udev rules:
Hello,
Am 24.04.2013 05:19, schrieb John Stultz:
On x86 the persistent_clock() is backed by the
CMOS/EFI/kvm-wall/xen/vrtc clock (all via x86_platform.get_wallclock)
should be present and we'll initialize the time in timekeeping_init()
there.
Its only systems where there isn't a
44 matches
Mail list logo
