[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200809101436.26162.david-b@pacbell.net>
Date: Wed, 10 Sep 2008 14:36:25 -0700
From: David Brownell <david-b@...bell.net>
To: David Miller <davem@...emloft.net>
Cc: rdunlap@...otime.net, akpm@...ux-foundation.org,
James.Bottomley@...senpartnership.com,
torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
linux-parisc@...r.kernel.org, alessandro.zummo@...ertech.it,
tglx@...utronix.de
Subject: Re: [PATCH] fix RTC_CLASS regression with PARISC
On Wednesday 10 September 2008, David Miller wrote:
> >
> > I don't think anyone in particular has been _pushing_ to resolve these
> > NTP related issues ... lack of urgency. Maybe it's fair to think of
> > that as a process issue. If DaveM wants SPARC64 to completely remove
> > its legacy RTC support for some release (which?) then: (a) great! and
> > (b) that should be sufficient urgency.
>
> Well, firstly my RTC sparc work is 2.6.28 targetted.
Fine; Andrew and Thomas won't need to worry about this patch
for now, then.
> Secondly, that sleeping capability is only really needed for I2C based
> RTC chips, of which sparc isn't currently making any use of.
Not quite right. The RTC calls you make grabs a mutex; *ALL* calls
into the framework are made in task context. Even if the underlying
RTC happens to be the type with registers on the CPU bus, where
there's no need to sleep when reading values.
Of course, you're very unlikely to sleep while waiting for that
mutex; or even while holding it, if you stick to Sun hardware.
Someone running Linux on one of the FPGA-based SPARCs might well
use an I2C based RTC though.
- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists