On Mon, Nov 24, 2008 at 6:05 PM, Mike Isely <[EMAIL PROTECTED]> 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 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
