Make sure your processor will not hang to long, a processor must walk
through a quiesce state after some time else you will get RCU
starvation.
On Sun, Mar 8, 2009 at 9:50 PM, Asim <linkasim@xxxxxxxxx> wrote:
> Thanks guys.
>
> The msleep solution looks good, but if my device does its work in 1
> micro or nano second then it seems a tad too long to sleep. Here is
> what I ended up using -
>
> {
> .
> unsigned long long delta = (cpu/khz/HZ)*2;
> unsigned long long _start = 0;
> unsigned long long _cur = 0;
> .
>
> timeout = rdstcll(start) + delta ;
>
> while (1) {
> if (_cur < timeout) {
> rdstcll(_cur);
> } else {
> flag_error()
> }
> }
>
>
> -Asim
>
> On 3/7/09, Greg KH <greg@xxxxxxxxx> wrote:
>> On Fri, Mar 06, 2009 at 12:17:37PM -0600, Asim wrote:
>>> I need it for a device. The device performs some operation in a loop
>>> but I cannot wait in that loop forever, so I need to wait for the
>>> maximum time I can (2 clock ticks) before giving up on the device.
>>> Interrupts may be disabled so I cannot use jiffies. Any simple
>>> solution would be appreciated.
>>
>> Do what is done in lots of places in the kernel, something like the
>> following from drivers/usb/host/pci-quirks.c:
>>
>> /* if boot firmware now owns EHCI, spin till
>> * it hands it over.
>> */
>> msec = 1000;
>> while ((cap & EHCI_USBLEGSUP_BIOS) && (msec > 0)) {
>> tried_handoff = 1;
>> msleep(10);
>> msec -= 10;
>> pci_read_config_dword(pdev, offset, &cap);
>> }
>>
>> Don't think in "clock ticks" but rather in "real" units of time, like
>> portions of seconds. That way your code will work properly when a
>> "clock tick" changes over time, becoming faster or slower, as they
>> always do.
>>
>> Hope this helps,
>>
>> greg k-h
>>
>
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
