On 12/12/2012 09:21 PM, Jason Gunthorpe wrote:
On Wed, Dec 12, 2012 at 04:18:31PM -0800, John Stultz wrote:
I do, although again, in the case where the arch specific
implementation is "better", we end up losing granularity (s390 is
the specific example I'm thinking of), since this prefers the R
On Wed, Dec 12, 2012 at 04:18:31PM -0800, John Stultz wrote:
> I do, although again, in the case where the arch specific
> implementation is "better", we end up losing granularity (s390 is
> the specific example I'm thinking of), since this prefers the RTC
> implementation over the arch specific o
On 12/12/2012 01:04 PM, Jason Gunthorpe wrote:
On Wed, Dec 12, 2012 at 11:40:26AM -0800, John Stultz wrote:
The option also overrides the call to any platform update_persistent_clock
so that the RTC subsystem completely and generically replaces this
functionality.
Tested on ARM kirkwood and PP
On Wed, Dec 12, 2012 at 11:40:26AM -0800, John Stultz wrote:
> >The option also overrides the call to any platform update_persistent_clock
> >so that the RTC subsystem completely and generically replaces this
> >functionality.
> >
> >Tested on ARM kirkwood and PPC405
> So I'm initially mixed on t
On 12/11/2012 09:56 PM, Jason Gunthorpe wrote:
The purpose of this option is to allow ARM/etc systems that rely on the
class RTC subsystem to have the same kind of automatic NTP based
synchronization that we have on PC platforms. Today ARM does not
implement update_persistent_clock and makes exte
The purpose of this option is to allow ARM/etc systems that rely on the
class RTC subsystem to have the same kind of automatic NTP based
synchronization that we have on PC platforms. Today ARM does not
implement update_persistent_clock and makes extensive use of the
class RTC system.
When enabled
6 matches
Mail list logo
