[pvrusb2] Problems Tuning Digital Channels on HVR-1950

[Michael Krufky]

On Mon, Nov 24, 2008 at 6:05 PM, Mike Isely <isely at isely.net> wrote:
> On Mon, 24 Nov 2008, Michael Krufky wrote:
>
>   [...]
>
>>
>> I've been meaning to respond to this all day long, but I've been short
>> on spare time.  I will keep this short and sweet.
>>
>> I did a diff comparison between the code in the ubuntu-intrepid kernel
>> versus the code in the v4l-dvb tree.  The following is a description
>> of the changes of the major components that have to do with the ATSC /
>> QAM tuner components in the HVR1950:
>>
>> 1) TDA18271 -- no change (other than some compat code and the removal
>> of a no-op break statement)
>>
>> 2) S5H1411 -- very small changes.  I looked these over with the author
>> of the driver and we do not believe these to be causing the issue, but
>> anything is possible.
>>
>> 3) PVRUSB2 -- some larger changes that I cannot review or describe
>> fairly given the lack of time that I have for this.
>
>   [...]
>
> I just skimmed the diff rather quickly.
>
> The vast majority of the changes are what one would expect when
> transforming the source code for a driver from the v4l-dvb repository
> into the Linux kernel, e.g. stripping out various "if 0" bits, removing
> kernel-version-specific sections, getting rid of compat.h, etc.  Every
> driver in v4l-dvb has changes like these and they are all known to be
> safe of course.  The transformation is mechanical in nature; it is done
> via a script by the v4l-dvb maintainer when pushing changes up to the
> kernel tree.
>
> Of the remaining changes, nearly all have to do with adding cropping
> support, which is in v4l-dvb but (not surprisingly) won't be in 2.6.27.y
> since that's a feature addition that appeared long after the 2.6.27
> merge window closed.  Beyond that, there are a few other minor bits to
> help with overall functional stability (e.g. avoid an oops if the driver
> is attempted to be associated with a device ID that it doesn't know
> about, something that can only happen if an alien device ID is forced
> into the driver at run-time).
>
> None of the changes however have anything to do with tuning.
>
> I'm not trying to "point the finger" here.  Allow me to explain (and
> feel free to tell me where I went astray)...  Until this reply I thought
> I had understood the situation: Back in the early 2.6.27.y releases
> (over a month ago), there was apparently a problem which impacted the
> ability to do digital tuning on the HVR-1950 - exactly the problem
> described in this thread.  The root cause had to do with some issues
> with the underlying tuner driver for the HVR-1950's tuner, not the
> pvrusb2 driver itself.  Mike Krufky and I talked about that at the time,
> and it just so happens that Steve Toth just the previous day had
> committed tuner fixes into v4l-dvb that radically improved this
> situation.  I have since confirmed that v4l-dvb is fine in this regard
> for the HVR-1950 - without any related pvrusb fixes needed.  Obviously
> those changes weren't in any mainline kernel then.  Since that time I
> believe the tuner fixes have indeed gotten into 2.6.27.y and probably
> also 2.6.26.y (but I haven't personally tested that at this point).  So
> AFAIK, there is nothing wrong with 2.6.27.y - at least with respect to
> the pvrusb2 driver or anything it depends upon.
>
> After seeing roccomoretti's reply, I interpreted that to mean that the
> fixes hadn't made their way into the Ubuntu kernel yet.  But now with
> Mike's comparison between the Ubuntu sources and v4l-dvb I'm a little
> confused.  Are you sure roccomoretti that you were running the kernel
> version that Mike just compared?
>
> I don't run Ubuntu here, so I do not know what "2.6.27-7" corresponds
> with.  That *could* correspond to vanilla kernel 2.6.27.7, but I don't
> really know.  (In Debian this would definitely not be the case.)
>
> It might be a good experiment to grab vanilla kernel 2.6.27.7 from
> kernel.org, build that, and see if the tuning problem shows up again.
> If so, then we can compare the vanilla kernel tree with v4l-dvb and
> eliminate another source of uncertainty.

DOH!

I totally overlooked what Mike Isely just pointed out.

I was looking at the ubuntu-intrepid kernel from a week or two ago...
The most recent version tag is, "UBUNTU: Ubuntu-2.6.27-10.20"

I just looked back in history, and 2.6.27-7 does not include the
s5h1411 fixes that Mike was referring to.

Please try the latest ubuntu-intrepid kernel 2.6.27-10 or later, and
report back as to whether or not the problem is yet reproducible.

Thanks Mike -- I missed that one :-P

Cheers,

Mike Krufky