Chris Friesen wrote:
Kevin Diggs wrote:
Hi,
I have the following near the top of my cpufreq driver target
routine:
while(test_and_set_bit(cf750gxmCfgChangeBit,&cf750gxvStateBits)) {
/*
* Someone mucking with our cfg? (I hope it is ok to call
* schedule() here! - truth is I have no idea what I am doing
* ... my reasoning is I want to yeild the cpu so whoever is
* mucking around can finish)
*/
schedule();
}
This is to prevent bad things from happening if someone is trying to
change a parameter for the driver via sysfs while the target routine
is running. Fortunately, because I had a bug where this bit was not
getting cleared on one of the paths through the target routine ... I
now know it is not safe to call schedule (it got stuck in there -
knocked out my adb keyboard! - (I think target is called from a timer
that the governor sets up ... interrupt context?)).
Is the issue that someone may be in the middle of a multi-stage
procedure, and you've woken up partway through?
If so, what about simply rescheduling the timer for some short time in
the future and aborting the current call?
Chris
Chris,
Thanks for taking the time to reply. The parameter in question modifies
the frequency table. It is used several times in the target routine.
I've addressed the issue by making a local copy of the frequency table
upon entry to the target routine and use that while there. I don't care
who wins the race.
kevin
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
