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
next prev parent 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