[lkml]   [2001]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: Incorrect mdelay() results on Power Managed Machines x86
    > During resume the IBM thinkpad with the cs46xx driver needs 
    > to delay 700
    > milleseconds, so if the machine is booted up on battery power, then to
    > ensure that the delay is long enough, then a value of 3000
    > milleseconds is
    > must be programmed into the driver (3 seconds!). all the
    > mdelay and udelay
    > wait times are incorrect by the same factor, resulting in some serious
    > problems when attempting to wait specific delay times in
    > other parts of the
    > driver.

    Well yes this is a problem, but only when starting out with a low effective
    CPU freq and going high - the reverse is usually OK because longer than
    anticipated waits are OK.

    However, you can alleviate this problem by not using udelay (or mdelay) but
    using a kernel timer. I would think you should be doing this anyway (700ms
    is a LONG TIME) but this should also work regardless of effective CPU freq.

    A grep of the kernel source shows cs46xx isn't even doing the biggest
    mdelay. I can understand the use of spinning on a calibrated loop for less
    than a clock tick, but I gotta think there are better ways for longer

    I wonder if there is a way to modify mdelay to use a kernel timer if
    interval > 10msec? I am not familiar with this section of the kernel, but I
    do know that Microsoft's similar function KeStallExecutionProcessor is not
    recommended for more than 50 *micro*seconds.

    Regards -- Andy

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:17    [W:0.021 / U:0.096 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site