From owner-freebsd-multimedia@FreeBSD.ORG Tue Feb 28 20:19:50 2006 Return-Path: X-Original-To: multimedia@FreeBSD.org Delivered-To: freebsd-multimedia@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DF1216A422; Tue, 28 Feb 2006 20:19:50 +0000 (GMT) (envelope-from ariff@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE08543D48; Tue, 28 Feb 2006 20:19:49 +0000 (GMT) (envelope-from ariff@FreeBSD.org) Received: from misaki (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with SMTP id k1SKJk6m087401; Tue, 28 Feb 2006 20:19:47 GMT (envelope-from ariff@FreeBSD.org) Date: Wed, 1 Mar 2006 04:19:28 +0800 From: Ariff Abdullah To: Scott Long Message-Id: <20060301041928.33af36ca.ariff@FreeBSD.org> In-Reply-To: <44047C40.2080907@samsco.org> References: <20060227105017.77c18b20.ariff@FreeBSD.org> <200602271251.32890.mi+mx@aldan.algebra.com> <44034054.3090104@samsco.org> <200602271321.33055.mi+mx@aldan.algebra.com> <20060228025154.01db3dff.ariff@FreeBSD.org> <44035532.1060408@samsco.org> <20060228043735.33bddf5d.ariff@FreeBSD.org> <44036500.4090802@samsco.org> <20060228051140.31f56b4f.ariff@FreeBSD.org> <44039366.7080605@samsco.org> <44047C40.2080907@samsco.org> Organization: FreeBSD X-Mailer: /usr/local/lib/ruby/1.8/net/smtp.rb Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Wed__1_Mar_2006_04_19_28_+0800_R_U2MNEB4AyB__Lj" Cc: mi+mx@aldan.algebra.com, re@FreeBSD.org, multimedia@FreeBSD.org Subject: Re: today's 6.1 would not boot here X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2006 20:19:50 -0000 --Signature=_Wed__1_Mar_2006_04_19_28_+0800_R_U2MNEB4AyB__Lj Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 28 Feb 2006 09:37:20 -0700 Scott Long wrote: > Scott Long wrote: > > Ariff Abdullah wrote: > >=20 > >> On Mon, 27 Feb 2006 13:45:52 -0700 > >> Scott Long wrote: > >> > >>> Ariff Abdullah wrote: > >>> > >>>> On Mon, 27 Feb 2006 12:38:26 -0700 > >>>> Scott Long wrote: > >>>> > >>>> > >>>>> Is this a problem with calibrating the sample rate on the > >chip? >>>> There was a problem with snd_ich several years ago > >where the >>>> calibration would fail or be unpredictable during > >boot. I fixed >>> > >>>> > >>>> it >my moving the calibration code to a separate step that > >gets >>> run via >the config_intrhook API. That made it work > >reliably >>> during boot >and when loaded after boot. Is this new > >problem >>> somehow related to >this? Since I was the one who > >fixed it in the >>> past, I'd be happy to >help now. > >>>> > >>>> It seems related. From my naked eyes, I can sense that the > >>>> interrupt was trigered during/before sampling rate calibration, > >>>> and since the calibration expect to not trigger any interrupt, > >>>> this will cause unexpected behaviour especially for this > >MPSAFEed >>> driver *and* during boot. Besides, the pcm > >construction also done >>> before the calibration, unlike > >snd_atiixp where the hook is use to >>> bring everything alive > >after the necessary step is finished. >>> > >>>> > >>>> I'll come up with something shortly. > >>>> > >>> > >>> Maybe move the bus_setup_intr() call to after the calibration?=20 > >If >> the driver doesn't need interrupts until after calibration, I > >think >> that this would cleanly solve the problem. > >>> > >> > >> Good idea, or, simply ignore interrupt trigger until all has been > >> calibrated. Pretty much like this: > >> > >> http://people.freebsd.org/~ariff/test/ich.c > >> > >=20 > > Yup, that looks good too. > >=20 > > Scott > >=20 >=20 > Actually, I'll ammend that. If the ich device is sharing an > interrupt (increasingly common these days) then interrupts from > those other devices will still cause the ich handler to run, and you > catch that with the the calibration flag that you put in there. But > even though you exit right away from the handler, you still have to > wait while the other handlers run, block on mutexes, etc. At the > very least this will still corrupt the calibration results. On the > other hand, if you don't register an interrupt handler until after > the calibration is done and you are ready to handle interrupts, then > you are guaranteed to avoid these problems. Adding a critical > section around the calibration loop would further guarantee this. >=20 Indeed. For driver requiring this type of initialization hook, moving various pcm_addchan/AC97_CREATE *after* the calibration completed seems reasonable too. -- Ariff Abdullah FreeBSD --Signature=_Wed__1_Mar_2006_04_19_28_+0800_R_U2MNEB4AyB__Lj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (FreeBSD) iD4DBQFEBLBSlr+deMUwTNoRAj1fAJ9+oJgVV1cMN2nlZKh1JqMw3jK+SACXRqIx hHhkdvpZU6y5AFQavqYD8Q== =2y+k -----END PGP SIGNATURE----- --Signature=_Wed__1_Mar_2006_04_19_28_+0800_R_U2MNEB4AyB__Lj--