Re: cx5000 default auto sleep mode

From: Devin Heitmueller <dheitmueller@kernellabs.com>
To: Andy Walls <awalls@md.metrocast.net>
Cc: "Timothy D. Lenz" <tlenz@vorgon.com>, linux-media@vger.kernel.org
Subject: Re: cx5000 default auto sleep mode
Date: Thu, 15 Apr 2010 00:39:01 -0400	[thread overview]
Message-ID: <h2h829197381004142139q35705f60q61dd04b05f509af6@mail.gmail.com> (raw)
In-Reply-To: <1271303099.7643.7.camel@palomino.walls.org>

On Wed, Apr 14, 2010 at 11:44 PM, Andy Walls <awalls@md.metrocast.net> 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 <tlenz@vorgon.com> 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

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com