Hi Jason,
On Thu, Dec 13, 2012 at 07:38:26PM -0700, Jason Gunthorpe wrote:
>
> > make the HCTOSYS option be dependent on !HAS_PERSISTENT_CLOCK. This
> > way we avoid having configs where there are conflicting paths that
> > we chose from.
>
> On ARM the read_presistent_clock is used to access a
Hi Jason,
On Thu, Dec 13, 2012 at 07:38:26PM -0700, Jason Gunthorpe wrote:
make the HCTOSYS option be dependent on !HAS_PERSISTENT_CLOCK. This
way we avoid having configs where there are conflicting paths that
we chose from.
On ARM the read_presistent_clock is used to access a true
On Mon, Dec 17, 2012 at 11:22:02AM -0700, Jason Gunthorpe wrote:
> On Tue, Dec 18, 2012 at 12:14:33AM +0800, Feng Tang wrote:
>
> > > Sure, but my view on this is that it has nothing to do with
> > > read_persistent_clock. If the RTC driver can run with IRQs off is a
> > > property of the RTC
On Tue, Dec 18, 2012 at 12:14:33AM +0800, Feng Tang wrote:
> > Sure, but my view on this is that it has nothing to do with
> > read_persistent_clock. If the RTC driver can run with IRQs off is a
> > property of the RTC driver and RTC hardware - it has nothing to do
> > with the platform. ARM
On Fri, Dec 14, 2012 at 02:56:51PM -0700, Jason Gunthorpe wrote:
> On Fri, Dec 14, 2012 at 01:22:50PM -0800, John Stultz wrote:
>
> > Although from a timekeeping perspective, the read_persistent_clock()
> > interface is actually *much* preferred over the rtc HCTOSYS device.
> >
> > Since
On Tue, Dec 18, 2012 at 12:14:33AM +0800, Feng Tang wrote:
Sure, but my view on this is that it has nothing to do with
read_persistent_clock. If the RTC driver can run with IRQs off is a
property of the RTC driver and RTC hardware - it has nothing to do
with the platform. ARM platforms
On Mon, Dec 17, 2012 at 11:22:02AM -0700, Jason Gunthorpe wrote:
On Tue, Dec 18, 2012 at 12:14:33AM +0800, Feng Tang wrote:
Sure, but my view on this is that it has nothing to do with
read_persistent_clock. If the RTC driver can run with IRQs off is a
property of the RTC driver and RTC
On Fri, Dec 14, 2012 at 02:56:51PM -0700, Jason Gunthorpe wrote:
On Fri, Dec 14, 2012 at 01:22:50PM -0800, John Stultz wrote:
Although from a timekeeping perspective, the read_persistent_clock()
interface is actually *much* preferred over the rtc HCTOSYS device.
Since
On 12/14/2012 01:56 PM, Jason Gunthorpe wrote:
On Fri, Dec 14, 2012 at 01:22:50PM -0800, John Stultz wrote:
Although from a timekeeping perspective, the read_persistent_clock()
interface is actually *much* preferred over the rtc HCTOSYS device.
Since read_persistent_clock() has the
On Fri, Dec 14, 2012 at 01:22:50PM -0800, John Stultz wrote:
> Although from a timekeeping perspective, the read_persistent_clock()
> interface is actually *much* preferred over the rtc HCTOSYS device.
>
> Since read_persistent_clock() has the requirement that its safe to
> call with IRQs
On 12/13/2012 06:38 PM, Jason Gunthorpe wrote:
On Thu, Dec 13, 2012 at 06:00:23PM -0800, John Stultz wrote:
So per Jason's related patch, he's made the point that the
persistent_clock and RTC class functionality are basically exclusive
(well, in his case, he said this with respect to updating
On 12/13/2012 08:10 PM, Jason Gunthorpe wrote:
Ah, I see, there is some duplication here, my earlier comments about
update_persistent_clock are not quite right, some places like PCs
stick a RTC driver and then continue to access the same hardware
directly outside the rtc driver context! That
On 12/13/2012 08:10 PM, Jason Gunthorpe wrote:
Ah, I see, there is some duplication here, my earlier comments about
update_persistent_clock are not quite right, some places like PCs
stick a RTC driver and then continue to access the same hardware
directly outside the rtc driver context! That
On 12/13/2012 06:38 PM, Jason Gunthorpe wrote:
On Thu, Dec 13, 2012 at 06:00:23PM -0800, John Stultz wrote:
So per Jason's related patch, he's made the point that the
persistent_clock and RTC class functionality are basically exclusive
(well, in his case, he said this with respect to updating
On Fri, Dec 14, 2012 at 01:22:50PM -0800, John Stultz wrote:
Although from a timekeeping perspective, the read_persistent_clock()
interface is actually *much* preferred over the rtc HCTOSYS device.
Since read_persistent_clock() has the requirement that its safe to
call with IRQs disabled,
On 12/14/2012 01:56 PM, Jason Gunthorpe wrote:
On Fri, Dec 14, 2012 at 01:22:50PM -0800, John Stultz wrote:
Although from a timekeeping perspective, the read_persistent_clock()
interface is actually *much* preferred over the rtc HCTOSYS device.
Since read_persistent_clock() has the
On Fri, Dec 14, 2012 at 11:13:30AM +0800, Feng Tang wrote:
> > This seems like a great use of that hardware resource, and no doubt
> > those mach's also have a class RTC driver available talking to
> > different hardware.
>
> Interesting to know this, thanks for the info. For the x86 desktop
>
On Thu, Dec 13, 2012 at 07:38:26PM -0700, Jason Gunthorpe wrote:
> On Thu, Dec 13, 2012 at 06:00:23PM -0800, John Stultz wrote:
>
> > So per Jason's related patch, he's made the point that the
> > persistent_clock and RTC class functionality are basically exclusive
> > (well, in his case, he said
On Thu, Dec 13, 2012 at 06:00:23PM -0800, John Stultz wrote:
> So per Jason's related patch, he's made the point that the
> persistent_clock and RTC class functionality are basically exclusive
> (well, in his case, he said this with respect to updating the RTC,
> not reading it - I don't mean to
On Thu, Dec 13, 2012 at 06:00:23PM -0800, John Stultz wrote:
> On 12/13/2012 05:37 PM, Feng Tang wrote:
> >On Thu, Dec 13, 2012 at 05:20:36PM -0800, John Stultz wrote:
> >>On 12/12/2012 06:05 PM, Feng Tang wrote:
> >>>In current kernel, there are several places which need to check
> >>>whether
On 12/13/2012 05:37 PM, Feng Tang wrote:
On Thu, Dec 13, 2012 at 05:20:36PM -0800, John Stultz wrote:
On 12/12/2012 06:05 PM, Feng Tang wrote:
In current kernel, there are several places which need to check
whether there is a persistent clock for the platform. Current check
is done by calling
Hi John,
Thanks for the review.
On Thu, Dec 13, 2012 at 05:20:36PM -0800, John Stultz wrote:
> On 12/12/2012 06:05 PM, Feng Tang wrote:
> >In current kernel, there are several places which need to check
> >whether there is a persistent clock for the platform. Current check
> >is done by calling
On 12/12/2012 06:05 PM, Feng Tang wrote:
In current kernel, there are several places which need to check
whether there is a persistent clock for the platform. Current check
is done by calling the read_persistent_clock() and validating the
return value.
Add such a flag to make code more readable
On 12/12/2012 06:05 PM, Feng Tang wrote:
In current kernel, there are several places which need to check
whether there is a persistent clock for the platform. Current check
is done by calling the read_persistent_clock() and validating the
return value.
Add such a flag to make code more readable
Hi John,
Thanks for the review.
On Thu, Dec 13, 2012 at 05:20:36PM -0800, John Stultz wrote:
On 12/12/2012 06:05 PM, Feng Tang wrote:
In current kernel, there are several places which need to check
whether there is a persistent clock for the platform. Current check
is done by calling the
On 12/13/2012 05:37 PM, Feng Tang wrote:
On Thu, Dec 13, 2012 at 05:20:36PM -0800, John Stultz wrote:
On 12/12/2012 06:05 PM, Feng Tang wrote:
In current kernel, there are several places which need to check
whether there is a persistent clock for the platform. Current check
is done by calling
On Thu, Dec 13, 2012 at 06:00:23PM -0800, John Stultz wrote:
On 12/13/2012 05:37 PM, Feng Tang wrote:
On Thu, Dec 13, 2012 at 05:20:36PM -0800, John Stultz wrote:
On 12/12/2012 06:05 PM, Feng Tang wrote:
In current kernel, there are several places which need to check
whether there is a
On Thu, Dec 13, 2012 at 06:00:23PM -0800, John Stultz wrote:
So per Jason's related patch, he's made the point that the
persistent_clock and RTC class functionality are basically exclusive
(well, in his case, he said this with respect to updating the RTC,
not reading it - I don't mean to put
On Thu, Dec 13, 2012 at 07:38:26PM -0700, Jason Gunthorpe wrote:
On Thu, Dec 13, 2012 at 06:00:23PM -0800, John Stultz wrote:
So per Jason's related patch, he's made the point that the
persistent_clock and RTC class functionality are basically exclusive
(well, in his case, he said this
On Fri, Dec 14, 2012 at 11:13:30AM +0800, Feng Tang wrote:
This seems like a great use of that hardware resource, and no doubt
those mach's also have a class RTC driver available talking to
different hardware.
Interesting to know this, thanks for the info. For the x86 desktop
and mobile
In current kernel, there are several places which need to check
whether there is a persistent clock for the platform. Current check
is done by calling the read_persistent_clock() and validating the
return value.
Add such a flag to make code more readable and call read_persistent_clock()
only once
In current kernel, there are several places which need to check
whether there is a persistent clock for the platform. Current check
is done by calling the read_persistent_clock() and validating the
return value.
Add such a flag to make code more readable and call read_persistent_clock()
only once
32 matches
Mail list logo
