public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andris Pavenis <pavenis@latnet.lv>
To: Doug Ledford <dledford@redhat.com>
Cc: Nathan Bryant <nbryant@optonline.net>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] i810_audio fix for version 0.11
Date: Sat, 8 Dec 2001 11:45:10 +0200	[thread overview]
Message-ID: <200112080945.fB89jAC00998@hal.astr.lu.lv> (raw)
In-Reply-To: <Pine.A41.4.05.10112081022560.23064-100000@ieva06> <200112080925.fB89PJ200926@hal.astr.lu.lv> <3C11DF15.1020107@redhat.com>
In-Reply-To: <3C11DF15.1020107@redhat.com>

On Saturday 08 December 2001 11:36, Doug Ledford wrote:
> Andris Pavenis wrote:
> >On Saturday 08 December 2001 10:39, Andris Pavenis wrote:
> >>Sorry, but this patch is still not OK. It still causes system
> >>locking up for me.
> >>
> >>In some cases I have (I added printk in __start_dac):
> >>	dmabuf->count = 0
> >>	dmabuf->ready = 1
> >>	dmabuf->enable = 1
> >>	PCM_ENABLE_OUTPUT set in dmabuf->triger
>
> Actually, since the problem is that there are obviously some "just in
> case" type calls if i810_update_lvi(), the best answer is not to even go
> through all those motions when dmabuf->count == 0.  So, I would add a
> line to i810_update_lvi() that makes it return without doing anything
> when dmabuf->count == 0.  That one line should solve your lockups (and
> finalize the 0.12 version).
>

Why returning non zero from __start_dac() and similar procedures when 
something real has been done there is so bad. Using such return code would
ensure we never try to wait for results of __start_dac() if nothing is done 
by this procedure. I think such way is also more safe against possible future 
modifications as real conditions are only in a single place. Keeping them in 
2 places is possible source of bitrot if driver will be updated in future.

Andris

  reply	other threads:[~2001-12-08  9:45 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-07 16:03 [PATCH] i810_audio fix for version 0.11 Andris Pavenis
2001-12-07 17:18 ` Nathan Bryant
2001-12-07 17:37   ` Andris Pavenis
2001-12-07 17:55   ` Doug Ledford
2001-12-07 18:36     ` Doug Ledford
2001-12-08  8:39       ` Andris Pavenis
2001-12-08  9:25         ` Andris Pavenis
2001-12-08  9:36           ` Doug Ledford
2001-12-08  9:45             ` Andris Pavenis [this message]
2001-12-11  0:42               ` Doug Ledford
2001-12-11  6:59                 ` Andris Pavenis
2001-12-27 11:10                 ` i810_audio driver version 0.13 still broken Andris Pavenis
2001-12-27 21:44                   ` Nathan Bryant
2001-12-28  7:16                     ` Andris Pavenis
2001-12-28 20:14                       ` Nathan Bryant
2002-01-05 12:29                     ` Andris Pavenis
2001-12-31  4:06                   ` Nick Papadonis
  -- strict thread matches above, loose matches on Subject: below --
2001-12-07  2:44 [PATCH] i810_audio fix for version 0.11 Nathan Bryant

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200112080945.fB89jAC00998@hal.astr.lu.lv \
    --to=pavenis@latnet.lv \
    --cc=dledford@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nbryant@optonline.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox