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
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 driv
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 platf
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 read_per
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 requirement
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 disable
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 t
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 see
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
> an
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 p
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 ther
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 t
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 t
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
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
16 matches
Mail list logo
