Hello,
I am still not sure why you cannot use an IPI for this... on the CPU that
you want to access this resource, send an IPI to all other CPUs, and add
code in handling that IPI that they should spin and wait till you are done
with accessing the chip... then let the other CPUs continue.
> [EMAIL PROTECTED] said:
> > There is no such exported variable in the 'stable' kernel tree:
>
> Then there should be, and the RTC accesses in 2.2 are probably racy.
>
> In which case, feel free to provide Alan with a patch for 2.2.18.
Andrea has some bits for this on the current/pending
On Wed, 18 Oct 2000, David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > You want to patch /drivers/char/rtc.c ?? If you have a later kernel
> > than me, it would be helpful. Just apply my patch than do the rtc.c.
>
> /me looks at his TODO list.
>
> Not really.
Okay. I'll do it tonight.
[EMAIL PROTECTED] said:
> You want to patch /drivers/char/rtc.c ?? If you have a later kernel
> than me, it would be helpful. Just apply my patch than do the rtc.c.
/me looks at his TODO list.
Not really.
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Wed, 18 Oct 2000, David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > 2.2.17 should be able to do.
>
> Cool. drivers/char/rtc.c needs to use it too. Then you need to pester Alan
> till he puts it in 2.2.18-pre-de-jour :)
>
You want to patch /drivers/char/rtc.c ?? If you have a
[EMAIL PROTECTED] said:
> 2.2.17 should be able to do.
Cool. drivers/char/rtc.c needs to use it too. Then you need to pester Alan
till he puts it in 2.2.18-pre-de-jour :)
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Wed, 18 Oct 2000, David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > There is no such exported variable in the 'stable' kernel tree:
>
> Then there should be, and the RTC accesses in 2.2 are probably racy.
>
> In which case, feel free to provide Alan with a patch for 2.2.18.
>
> --
>
> > You need to put the spinlock in for every other use of the chip
>
> I can't control somebody else's use of `hwclock` or even some future
> kernel module.
You'll have to
> What I do is have a daemon which wakes up at 1 second intervals
> and writes 'time_t' to a spare group of CMOS
[EMAIL PROTECTED] said:
> There is no such exported variable in the 'stable' kernel tree:
Then there should be, and the RTC accesses in 2.2 are probably racy.
In which case, feel free to provide Alan with a patch for 2.2.18.
--
dwmw2
-
To unsubscribe from this list: send the line
On Wed, 18 Oct 2000, David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > I can't control somebody else's use of `hwclock` or even some future
> > kernel module.
>
> What you actually need to do is use the same spinlock as other users of the
> RTC hardware do.
>
> extern spinlock_t
[EMAIL PROTECTED] said:
> I can't control somebody else's use of `hwclock` or even some future
> kernel module.
What you actually need to do is use the same spinlock as other users of the
RTC hardware do.
extern spinlock_t rtc_lock;
It is exported to modules for this very reason.
--
dwmw2
I think you need to use the smp_call_funtion service and define the
function to be a spin_until_notified function. Each other processor will
call spin_until_notified when it receives the IPI for smp_call_function.
You can do what you need, then change some global that's keeping all the
other
On Wed, 18 Oct 2000, Alan Cox wrote:
> > spin_lock_irqsave(_lock, flags);
> > Muck_With_The_RTC_Chip();
> > spin_unlock_irqrestore(_lock, flags);
> >
> > This protects only the local procedure. In the meantime, somebody
> > else, using another CPU is mucking with the same RTC Chip.
Hello,
I need to clear the interrupts on a SMP machine!
Before everybody jumps up and says 'idiot', let me
assure you that I know about spin locks. Here's the
problem:
spin_lock_irqsave(_lock, flags);
Muck_With_The_RTC_Chip();
spin_unlock_irqrestore(_lock, flags
On Wed, 18 Oct 2000, Alan Cox wrote:
spin_lock_irqsave(local_lock, flags);
Muck_With_The_RTC_Chip();
spin_unlock_irqrestore(local_lock, flags);
This protects only the local procedure. In the meantime, somebody
else, using another CPU is mucking with the same RTC Chip.
I think you need to use the smp_call_funtion service and define the
function to be a spin_until_notified function. Each other processor will
call spin_until_notified when it receives the IPI for smp_call_function.
You can do what you need, then change some global that's keeping all the
other
[EMAIL PROTECTED] said:
I can't control somebody else's use of `hwclock` or even some future
kernel module.
What you actually need to do is use the same spinlock as other users of the
RTC hardware do.
extern spinlock_t rtc_lock;
It is exported to modules for this very reason.
--
dwmw2
On Wed, 18 Oct 2000, David Woodhouse wrote:
[EMAIL PROTECTED] said:
I can't control somebody else's use of `hwclock` or even some future
kernel module.
What you actually need to do is use the same spinlock as other users of the
RTC hardware do.
extern spinlock_t rtc_lock;
It
[EMAIL PROTECTED] said:
There is no such exported variable in the 'stable' kernel tree:
Then there should be, and the RTC accesses in 2.2 are probably racy.
In which case, feel free to provide Alan with a patch for 2.2.18.
--
dwmw2
-
To unsubscribe from this list: send the line
You need to put the spinlock in for every other use of the chip
I can't control somebody else's use of `hwclock` or even some future
kernel module.
You'll have to
What I do is have a daemon which wakes up at 1 second intervals
and writes 'time_t' to a spare group of CMOS registers and
On Wed, 18 Oct 2000, David Woodhouse wrote:
[EMAIL PROTECTED] said:
There is no such exported variable in the 'stable' kernel tree:
Then there should be, and the RTC accesses in 2.2 are probably racy.
In which case, feel free to provide Alan with a patch for 2.2.18.
--
dwmw2
[EMAIL PROTECTED] said:
2.2.17 should be able to do.
Cool. drivers/char/rtc.c needs to use it too. Then you need to pester Alan
till he puts it in 2.2.18-pre-de-jour :)
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Wed, 18 Oct 2000, David Woodhouse wrote:
[EMAIL PROTECTED] said:
2.2.17 should be able to do.
Cool. drivers/char/rtc.c needs to use it too. Then you need to pester Alan
till he puts it in 2.2.18-pre-de-jour :)
You want to patch /drivers/char/rtc.c ?? If you have a later
[EMAIL PROTECTED] said:
You want to patch /drivers/char/rtc.c ?? If you have a later kernel
than me, it would be helpful. Just apply my patch than do the rtc.c.
/me looks at his TODO list.
Not really.
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Wed, 18 Oct 2000, David Woodhouse wrote:
[EMAIL PROTECTED] said:
You want to patch /drivers/char/rtc.c ?? If you have a later kernel
than me, it would be helpful. Just apply my patch than do the rtc.c.
/me looks at his TODO list.
Not really.
Okay. I'll do it tonight. There are
Hello,
I am still not sure why you cannot use an IPI for this... on the CPU that
you want to access this resource, send an IPI to all other CPUs, and add
code in handling that IPI that they should spin and wait till you are done
with accessing the chip... then let the other CPUs continue.
26 matches
Mail list logo
