Hi!
> > > > +config PM_WAKEALARM_TEST
> > > > + bool "Test suspend/resume and wakealarm during bootup"
> > > > + depends on SUSPEND && PM_DEBUG && RTC_LIB
> >
> > I guess it also should depend on CONFIG_RTC_DRV_CMOS (not being a module)
> > and !CONFIG_RTC.
>
> No -- we need a *generi
Hi!
> > > > The changes look good to me.
> > >
> > > They feel unfinished to me though. :)
> > >
> > > Like using "jiffies" instead of a clocksource, which makes trouble
> > > since the timing covers periods with IRQs disabled. And the test
> > > mode parameter needs work.
> >
> > Well, I'd sa
Hi!
> > [ 23.893598] Calling initcall 0xc0c518b0: be_sleepy+0x0/0x170()
> > [ 23.901601] PM: no wakelarm-capable RTC
> > [ 23.905599] initcall 0xc0c518b0: be_sleepy+0x0/0x170() returned 0.
> > [ 23.910879] initcall 0xc0c518b0 ran for 3 msecs: be_sleepy+0x0/0x170()
> >
> > so close, ye
> > > The changes look good to me.
> >
> > They feel unfinished to me though. :)
> >
> > Like using "jiffies" instead of a clocksource, which makes trouble
> > since the timing covers periods with IRQs disabled. And the test
> > mode parameter needs work.
>
> Well, I'd say that timing has bigge
Hi!
> > The changes look good to me.
>
> They feel unfinished to me though. :)
>
> Like using "jiffies" instead of a clocksource, which makes trouble
> since the timing covers periods with IRQs disabled. And the test
> mode parameter needs work.
Well, I'd say that timing has bigger problem, r
On Sunday, 3 of February 2008, David Brownell wrote:
> > > See the appended; it includes more of Ingo's suggestions.
> > >
> > > Since this is increasingly unrelated to the "sleepy linux" concept
> > > (a version of what systems like OLPC, N700, and N800 are doing), I
> > > got rid of the "sleepy.
> > See the appended; it includes more of Ingo's suggestions.
> >
> > Since this is increasingly unrelated to the "sleepy linux" concept
> > (a version of what systems like OLPC, N700, and N800 are doing), I
> > got rid of the "sleepy.c" file.
>
> The changes look good to me.
They feel unfinished
On Sunday, 3 of February 2008, David Brownell wrote:
> > > > +config PM_WAKEALARM_TEST
> > > > + bool "Test suspend/resume and wakealarm during bootup"
> > > > + depends on SUSPEND && PM_DEBUG && RTC_LIB
> >
> > I guess it also should depend on CONFIG_RTC_DRV_CMOS (not being a module)
>
> > > +config PM_WAKEALARM_TEST
> > > + bool "Test suspend/resume and wakealarm during bootup"
> > > + depends on SUSPEND && PM_DEBUG && RTC_LIB
>
> I guess it also should depend on CONFIG_RTC_DRV_CMOS (not being a module)
> and !CONFIG_RTC.
No -- we need a *generic* test, not one that
On Sunday, 3 of February 2008, David Brownell wrote:
> On Saturday 02 February 2008, Ingo Molnar wrote:
> > randconfig testing found the following build failure:
> >
> > kernel/built-in.o: In function `be_sleepy':
> > sleepy.c:(.init.text+0x1952): undefined reference to `rtc_class'
> > sleepy.c:(.
On Saturday 02 February 2008, Sam Ravnborg wrote:
> > --- g26.orig/drivers/char/Kconfig
> > +++ g26/drivers/char/Kconfig
> > @@ -715,9 +715,12 @@ config NVRAM
> > To compile this driver as a module, choose M here: the
> > module will be called nvram.
> >
> > +comment "You are using th
> --- g26.orig/drivers/char/Kconfig
> +++ g26/drivers/char/Kconfig
> @@ -715,9 +715,12 @@ config NVRAM
> To compile this driver as a module, choose M here: the
> module will be called nvram.
>
> +comment "You are using the RTC framework, not the legacy CMOS RTC driver"
> + dep
On Saturday 02 February 2008, Ingo Molnar wrote:
> randconfig testing found the following build failure:
>
> kernel/built-in.o: In function `be_sleepy':
> sleepy.c:(.init.text+0x1952): undefined reference to `rtc_class'
> sleepy.c:(.init.text+0x1963): undefined reference to `rtc_class_open'
Becau
On Saturday 02 February 2008, Ingo Molnar wrote:
> > [ 23.509562] Calling initcall 0xc0c49e00: be_sleepy+0x0/0x170()
> > [ 23.515837] PM: no wakelarm-capable RTC
> > [ 23.517562] initcall 0xc0c49e00: be_sleepy+0x0/0x170() returned 0.
Because CONFIG_RTC_DRV_CMOS was not configured, though
you
randconfig testing found the following build failure:
kernel/built-in.o: In function `be_sleepy':
sleepy.c:(.init.text+0x1952): undefined reference to `rtc_class'
sleepy.c:(.init.text+0x1963): undefined reference to `rtc_class_open'
config attached.
Ingo
#
# Automatically generated make
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> [ 23.893598] Calling initcall 0xc0c518b0: be_sleepy+0x0/0x170()
> [ 23.901601] PM: no wakelarm-capable RTC
> [ 23.905599] initcall 0xc0c518b0: be_sleepy+0x0/0x170() returned 0.
> [ 23.910879] initcall 0xc0c518b0 ran for 3 msecs: be_sleepy+0x0
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> i didnt have all RTC drivers enabled (it was a randconfig .config i
> started out with) - but this did not appear to cure the problem. New
> bootlog and new config attached.
i disabled all hpet items in the .config on the theory that they might
inter
* David Brownell <[EMAIL PROTECTED]> wrote:
> On Saturday 02 February 2008, Ingo Molnar wrote:
> >
> > * Pavel Machek <[EMAIL PROTECTED]> wrote:
> >
> > > > It would have been easier to just use the public interface and
> > > > hard-wire "rtc0". But going directly to the hardware was dirtier,
On Saturday 02 February 2008, Ingo Molnar wrote:
>
> * Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> > > It would have been easier to just use the public interface and
> > > hard-wire "rtc0". But going directly to the hardware was dirtier,
> > > and more in the spirit of "hack that obviously sho
On Sat 2008-02-02 20:38:43, Ingo Molnar wrote:
>
> * Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> > > It would have been easier to just use the public interface and
> > > hard-wire "rtc0". But going directly to the hardware was dirtier,
> > > and more in the spirit of "hack that obviously shoul
On Saturday 02 February 2008, Ingo Molnar wrote:
>
> * David Brownell <[EMAIL PROTECTED]> wrote:
>
> > On Saturday 02 February 2008, Ingo Molnar wrote:
> > >
> > > i'd really love to have a /dev/rtc device compatibility APIs, both
> > > inside and outside the kernel.
> >
> > Unfortunately the
* Pavel Machek <[EMAIL PROTECTED]> wrote:
> > It would have been easier to just use the public interface and
> > hard-wire "rtc0". But going directly to the hardware was dirtier,
> > and more in the spirit of "hack that obviously shouldn't go upstream
> > until it gets done properly".
>
> Ye
On Sat 2008-02-02 11:13:21, David Brownell wrote:
> On Saturday 02 February 2008, Ingo Molnar wrote:
> >
> > > > Yep, you are right, but that is the easy issue to fix.
> > >
> > > Which is why I was puzzled that you didn't start out doing it the
> > > "right" way ... even just hard-wiring the dub
On Saturday 02 February 2008, Ingo Molnar wrote:
>
> > > Yep, you are right, but that is the easy issue to fix.
> >
> > Which is why I was puzzled that you didn't start out doing it the
> > "right" way ... even just hard-wiring the dubious assumption that
> > "rtc0" is the right RTC to use. :)
* David Brownell <[EMAIL PROTECTED]> wrote:
> On Saturday 02 February 2008, Ingo Molnar wrote:
> >
> > i'd really love to have a /dev/rtc device compatibility APIs, both
> > inside and outside the kernel.
>
> Unfortunately the /dev/rtc code became a legacy API for good reasons.
>
> Like not r
* David Brownell <[EMAIL PROTECTED]> wrote:
> > > Plus, the way you're doing it now is violating the locking
> > > protocol used by that driver.
> >
> > Yep, you are right, but that is the easy issue to fix.
>
> Which is why I was puzzled that you didn't start out doing it the
> "right" way .
On Saturday 02 February 2008, David Brownell wrote:
> static char *find_wake_rtc(void)
> {
> char *pony = NULL;
>
> dev = class_find_device(rtc_class, &rtc, has_wakealarm);
&pony,
... sorry, not al
On Saturday 02 February 2008, Ingo Molnar wrote:
>
> i'd really love to have a /dev/rtc device compatibility APIs, both
> inside and outside the kernel.
Unfortunately the /dev/rtc code became a legacy API for good reasons.
Like not recognizing that all the world's not a PC, with a single RTC
th
On Saturday 02 February 2008, Pavel Machek wrote:
> Hi!
>
> > > --- a/drivers/rtc/rtc-cmos.c
> > > +++ b/drivers/rtc/rtc-cmos.c
> > > @@ -78,7 +78,7 @@ static inline int is_intr(u8 rtc_intr)
> > >
> > > /**/
> > >
> > > -static i
* Pavel Machek <[EMAIL PROTECTED]> wrote:
> > Plus, the way you're doing it now is violating the locking protocol
> > used by that driver.
>
> Yep, you are right, but that is the easy issue to fix. There's hard
> issue: I need
>
> struct rtc_device *rtc
>
> for the rtc that can be used for s
Hi!
> > --- a/drivers/rtc/rtc-cmos.c
> > +++ b/drivers/rtc/rtc-cmos.c
> > @@ -78,7 +78,7 @@ static inline int is_intr(u8 rtc_intr)
> >
> > /**/
> >
> > -static int cmos_read_time(struct device *dev, struct rtc_time *t)
> > +int c
On Wednesday 30 January 2008, Pavel Machek wrote:
> --- a/drivers/rtc/rtc-cmos.c
> +++ b/drivers/rtc/rtc-cmos.c
> @@ -78,7 +78,7 @@ static inline int is_intr(u8 rtc_intr)
>
> /**/
>
> -static int cmos_read_time(struct device *dev
32 matches
Mail list logo
