From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: Fwd: Problems with hda_intel, Santa Rosa, and suspend Date: Thu, 21 Jun 2007 12:29:38 +0200 Message-ID: References: <200706171149.27547.rjw@sisk.pl> <75b66ecd0706171749x1c29b4b2u8978ac68888960d@mail.gmail.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id ED8B024441 for ; Thu, 21 Jun 2007 12:29:38 +0200 (CEST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@alsa-project.org Errors-To: alsa-devel-bounces@alsa-project.org To: Matt Mullins Cc: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org At Wed, 20 Jun 2007 16:18:46 -0500, Matt Mullins wrote: > > That doesn't seem to change anything. Maybe I should have been more > clear: I get the azx_get_response timeouts whenever the driver > initializes; DMA never works for that codec. Well, It has nothing to do with DMA... > single_cmd mode just > happens to work before a suspend, but not after. In other words, > reloading the module doesn't really fix the problem, it just masks it > decently enough. So, do you mean that single_cmd _always_ appears even before the suspend? Then it's not the problem of suspend-to-RAM but rather it's a pure luck that you can use that device. The single_cmd is a last but horrible resort for the systems that can't communicate with codec chips properly. > I'll work a little bit trying to figure out which > commands cause the timeouts. And what *is* S2D? suspend-to-disk. Takashi