[pvrusb2] Problems Tuning Digital Channels on HVR-1950

[Michael Krufky]

On Mon, Nov 24, 2008 at 6:27 PM, Michael Krufky <mkrufky at linuxtv.org> wrote:
> 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


Apparently, 2.6.27-7 is the current release intrepid kernel.  This
kernel does not yet have the required fixes, but they are in the
ubuntu-intrepid git tree.

If you file a bug on Ubuntu's bug tracking system located at
http://bugs.launchpad.net , maybe that can help get the Ubuntu kernel
maintainers to release that fix sooner.  Either way, it will be fixed
in the intrepid release kernel eventually.

-Mike