[lkml]   [2003]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectAW: drivers/sound/i810_audio.c bug and patch
    Hi Mike,

    >> Well, why not? The loop will only go through it's body 100 times if
    >> the hardware is actually not available or corrupt and even in this
    >> case the whole block won't take much time. It works for me and it
    >> should work for all the other people using this driver too:
    > Why busy wait especially when you can sleep 1ms each time and poll

    Well, I can tell you why I chose "busy wait" (kind of brainstorming):

    - Why did the originator of the driver made the loop with 10 turns,
    which is "busy wait" in your definition too?

    - Imagine you have workers and you give them a job that's supposed to be
    finished in six minutes. But these workers actually need seven minutes,
    which you don't know. If that job is urgent, would you rather look if
    it's done yet every 60 minutes or every six minutes? In the first case
    (that's your model), you would get your positive result in one hour, in
    the second case (my model), you'd get it in 12 minutes.

    - Seeing the constant of HZ/20 in "schedule_timeout(HZ/20);" gives me
    the feeling that this value is taken from some specification. Perhaps
    it's from a i810 datasheet (I will look at that later because it's very
    late now), but my fix is for SiS 7012 which could have slightly
    different characteristics. In this case, by doing my "busy wait", you
    don't modify the existing code which will initialize the chip in less
    than or equal to 10 turns.

    - When the driver is loaded at boot time I think it's the only piece of
    code which is running at that moment, I don't think there are any other
    threads working during driver init. If it's loaded as a module, the one
    who loads it waits for its results anyway. It's almost impossible that
    doing this "busy wait" will affect a running system with many
    concurrently running processes at a high system load _noticeably_. It
    will instead come to a result faster if the hardware is available (see
    point 1).

    Best Regards,

    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:48    [W:0.022 / U:0.464 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site