From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mout.perfora.net ([74.208.4.194]:51746 "EHLO mout.perfora.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751312Ab0DUW0k (ORCPT ); Wed, 21 Apr 2010 18:26:40 -0400 Message-ID: <4BCF7B92.6010608@vorgon.com> Date: Wed, 21 Apr 2010 15:26:26 -0700 From: "Timothy D. Lenz" MIME-Version: 1.0 To: Devin Heitmueller CC: Andy Walls , linux-media@vger.kernel.org Subject: Re: cx5000 default auto sleep mode References: <4BC5FB77.2020303@vorgon.com> <1271303099.7643.7.camel@palomino.walls.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-media-owner@vger.kernel.org List-ID: On 4/14/2010 9:39 PM, Devin Heitmueller wrote: > On Wed, Apr 14, 2010 at 11:44 PM, Andy Walls wrote: >> On Wed, 2010-04-14 at 13:40 -0400, Devin Heitmueller wrote: >>> On Wed, Apr 14, 2010 at 1:29 PM, Timothy D. Lenz wrote: >>>> Thanks to Andy Walls, found out why I kept loosing 1 tuner on a FusionHD7 >>>> Dual express. Didn't know linux supported an auto sleep mode on the tuner >>>> chips and that it defaulted to on. Seems like it would be better to default >>>> to off. >>> >>> Regarding the general assertion that the power management should be >>> disabled by default, I disagree. The power savings is considerable, >>> the time to bring the tuner out of sleep is negligible, and it's >>> generally good policy. >>> >>> Andy, do you have any actual details regarding the nature of the problem? >> >> Not really. DViCo Fusion dual digital tv card. One side of the card >> would yield "black video screen" when starting a digital capture >> sometime after (?) the VDR ATSC EPG plugin tried to suck off data. I'm >> not sure there was a causal relationship. >> >> I hypothesized that one side of the dual-tuner was going stupid or one >> of the two channels used in the cx23885 was getting confused. I was >> looking at how to narrow the problem down to cx23885 chip or xc5000 >> tuner, or s5h14xx demod when I noted the power managment module option >> for the xc5000. I suggested Tim try it. >> >> It was dumb luck that my guess actually made his symptoms go away. >> >> That's all I know. > > We did have a similar issue with the PCTV 800i. Basically, the GPIO > definition was improperly defined for the xc5000 reset callback. As a > result, it was strobing the reset on both the xc5000 *and* the > s5h1411, which would then cause the s5h1411's hardware state to not > match the driver state. > > After multiple round trips with the hardware engineer at PCTV, I > finally concluded that there actually wasn't a way to strobe the reset > without screwing up the demodulator, which prompted me to disable the > xc5000 reset callback (see cx88-cards:2944). > > My guess is that the reset GPIO definition for that board is wrong (a > problem exposed by this change), or that it's resetting the s5h1411 as > well. > > Devin > Are any of the logs usefull?