Re: KWorld UB435-Q Support
On Tue, Nov 17, 2009 at 11:59 PM, Jarod Wilson wrote: snip >>Or a few months later. About two weeks ago, I finally poked at these >>sticks some more, after getting a bit of info from another user, and >>we've finally got an actual fix for this problem -- .deny_i2c_rptr = 1 >>just needed to be set in the lgdt3305_config struct, as the device's >>tuner isn't actually behind an i2c gate. With that change, the stick >>behaves quite well w/o any alterations to the tda18271 code. Patches >>are here: >> >>http://wilsonet.com/jarod/junk/kworld-a340-20100218/ >> >>They're in Mike's hands now, since they rely so heavily on the lgdt3305 >>driver. I compiled up this change on my setup and the Kworld is working wonderfully for me now. I was able to do a full ATSC us center freq scan pretty quickly and then added it to mythtv and its working well there, too. It's doing OTA capture. Thanks, Jarod. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KWorld UB435-Q Support
On Tue, Nov 17, 2009 at 11:59 PM, Jarod Wilson wrote:
> On Nov 17, 2009, at 9:37 AM, Devin Heitmueller wrote:
> If you see this happen more than once consecutively, and there is only 1
> silicon tuner present, then it means something very bad is happening, and
> there is a chance of burning out a part. I still wouldnt not recommend
> any
> mainline merge until you can prevent this behavior -- I suspect that a
> GPIO
> reset is being toggled where it shouldnt be, which should be harmless ...
> but until we fix it, we cant be sure what damage might get done...
>
> The RF tracking filter calibration is a procedure that should only happen
> once while the tuner is powered on -- it should *only* be repeated if the
> tuner indicated that calibration is necessary, and that would only happen
> after a hardware reset.
>
> This still looks fishy to me...
>>>
>>> Agreed. I did manage to dig into this some more last night, something is
>>> definitely still awry.
> ...
>> Hey Jarod,
>>
>> I haven't seen your exact GPIO config but I noticed something
>> recently: the em28xx driver runs the dvb_gpio sequence whenever
>> starting streaming, not just whenever opening the DVB frontend. This
>> means that if your dvb_gpio definition strobes the tda18271 reset (as
>> opposed to just taking it out of reset), then the chip will get reset
>> whenever the streaming is started (a real problem if multiple tuning
>> attempts are performed without closing the frontend first).
>>
>> Mauro seems to think this is intended behavior, although I cannot see
>> how this could possibly be correct, especially since the .init()
>> callback is not called in that case. I setup a tree to remove the
>> call, but never got far enough into the testing to confirm whether it
>> broke any improperly configured boards depending on the incorrect
>> behavior.
>
> This tree, I presume.
>
> http://kernellabs.com/hg/~dheitmueller/em28xx-modeswitch/
>
> I just tacked on the very last patch there onto my local tree to test with
> one of these sticks. Behavior is the same though, and the tda18271 reg dumps
> look equally bad -- they're all reported 0x00.
>
>> As a test, you might want to check your dvb_gpio config and see if you
>> are pulling anything low and then high, and just remove the line that
>> sets the pin low and see if the recalibration still occurs.
>
> I'm pretty sure you explained how to do this to me once before on irc, but
> its been a while, and that knowledge has since leaked out of my brain...
> Currently, I have:
>
> /*
> * KWorld PlusTV 340U and UB435-Q (ATSC) GPIOs map:
> * EM_GPIO_0 - currently unknown
> * EM_GPIO_1 - LED disable/enable (1 = off, 0 = on)
> * EM_GPIO_2 - currently unknown
> * EM_GPIO_3 - currently unknown
> * EM_GPIO_4 - TDA18271HD tuner (1 = active, 0 = in reset)
> * EM_GPIO_5 - LGDT3304 ATSC/QAM demod (1 = active, 0 = in reset)
> * EM_GPIO_6 - currently unknown
> * EM_GPIO_7 - currently unknown
> */
> static struct em28xx_reg_seq kworld_a340_digital[] = {
> /* only diff from default gpio is to keep 1 clear to turn on LED */
> {EM28XX_R08_GPIO, 0x6d, ~EM_GPIO_4, 10},
> { -1, -1, -1, -1},
> };
>
> I've tried various combinations in here today, all without any significant
> change in behavior. But I suspect I'm missing something I should be trying.
> Ah well. Bed time. More poking tomorrow...
Or a few months later. About two weeks ago, I finally poked at these
sticks some more, after getting a bit of info from another user, and
we've finally got an actual fix for this problem -- .deny_i2c_rptr = 1
just needed to be set in the lgdt3305_config struct, as the device's
tuner isn't actually behind an i2c gate. With that change, the stick
behaves quite well w/o any alterations to the tda18271 code. Patches
are here:
http://wilsonet.com/jarod/junk/kworld-a340-20100218/
They're in Mike's hands now, since they rely so heavily on the lgdt3305 driver.
--
Jarod Wilson
ja...@wilsonet.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KWorld UB435-Q Support
On Nov 17, 2009, at 9:37 AM, Devin Heitmueller wrote:
> On Tue, Nov 17, 2009 at 9:15 AM, Jarod Wilson wrote:
>> On Nov 17, 2009, at 1:03 AM, Robert Cicconetti wrote:
>>
>>> On Tue, Nov 17, 2009 at 12:55 AM, Michael Krufky
>>> wrote:
> [ 812.465930] tda18271: performing RF tracking filter calibration
> [ 818.572446] tda18271: RF tracking filter calibration complete
> [ 818.953946] tda18271: performing RF tracking filter calibration
> [ 825.093211] tda18271: RF tracking filter calibration complete
If you see this happen more than once consecutively, and there is only 1
silicon tuner present, then it means something very bad is happening, and
there is a chance of burning out a part. I still wouldnt not recommend any
mainline merge until you can prevent this behavior -- I suspect that a GPIO
reset is being toggled where it shouldnt be, which should be harmless ...
but until we fix it, we cant be sure what damage might get done...
The RF tracking filter calibration is a procedure that should only happen
once while the tuner is powered on -- it should *only* be repeated if the
tuner indicated that calibration is necessary, and that would only happen
after a hardware reset.
This still looks fishy to me...
>>
>> Agreed. I did manage to dig into this some more last night, something is
>> definitely still awry.
...
> Hey Jarod,
>
> I haven't seen your exact GPIO config but I noticed something
> recently: the em28xx driver runs the dvb_gpio sequence whenever
> starting streaming, not just whenever opening the DVB frontend. This
> means that if your dvb_gpio definition strobes the tda18271 reset (as
> opposed to just taking it out of reset), then the chip will get reset
> whenever the streaming is started (a real problem if multiple tuning
> attempts are performed without closing the frontend first).
>
> Mauro seems to think this is intended behavior, although I cannot see
> how this could possibly be correct, especially since the .init()
> callback is not called in that case. I setup a tree to remove the
> call, but never got far enough into the testing to confirm whether it
> broke any improperly configured boards depending on the incorrect
> behavior.
This tree, I presume.
http://kernellabs.com/hg/~dheitmueller/em28xx-modeswitch/
I just tacked on the very last patch there onto my local tree to test with one
of these sticks. Behavior is the same though, and the tda18271 reg dumps look
equally bad -- they're all reported 0x00.
> As a test, you might want to check your dvb_gpio config and see if you
> are pulling anything low and then high, and just remove the line that
> sets the pin low and see if the recalibration still occurs.
I'm pretty sure you explained how to do this to me once before on irc, but its
been a while, and that knowledge has since leaked out of my brain... Currently,
I have:
/*
* KWorld PlusTV 340U and UB435-Q (ATSC) GPIOs map:
* EM_GPIO_0 - currently unknown
* EM_GPIO_1 - LED disable/enable (1 = off, 0 = on)
* EM_GPIO_2 - currently unknown
* EM_GPIO_3 - currently unknown
* EM_GPIO_4 - TDA18271HD tuner (1 = active, 0 = in reset)
* EM_GPIO_5 - LGDT3304 ATSC/QAM demod (1 = active, 0 = in reset)
* EM_GPIO_6 - currently unknown
* EM_GPIO_7 - currently unknown
*/
static struct em28xx_reg_seq kworld_a340_digital[] = {
/* only diff from default gpio is to keep 1 clear to turn on LED */
{EM28XX_R08_GPIO, 0x6d, ~EM_GPIO_4, 10},
{ -1, -1, -1, -1},
};
I've tried various combinations in here today, all without any significant
change in behavior. But I suspect I'm missing something I should be trying. Ah
well. Bed time. More poking tomorrow...
--
Jarod Wilson
ja...@wilsonet.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KWorld UB435-Q Support
On Tue, Nov 17, 2009 at 9:15 AM, Jarod Wilson wrote: >> It happened at every tuning operation, and made mythfrontend unhappy >> (unable to tune after the first channel). I disabled the check for >> RF_CAL_OK which triggered the recalibration, and mythfrontend worked. > > Yeah, tuning is much quicker here if I skip that check as well, but its > definitely not the proper fix. > >> The stick has been plugged in for a few months, so presumably would've >> caught on fire by now if it was going to. It would be nice if the >> tuning delay went away, though.. it still takes ~6 seconds to switch >> frequencies. > > Wait, it still takes that long with the check gone? I didn't poke for very > long with the check disabled, mostly focusing on trying to figure out why > things are going haywire. Okay.. couple of unscientific tests later show I was wrong above: First tuning, ~5-6 seconds to lock. Later tunings, ~3 seconds to lock. This is with my hack to remove the recalibrations. -Bob -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KWorld UB435-Q Support
On Tue, Nov 17, 2009 at 9:15 AM, Jarod Wilson wrote: > On Nov 17, 2009, at 1:03 AM, Robert Cicconetti wrote: > >> On Tue, Nov 17, 2009 at 12:55 AM, Michael Krufky wrote: [ 812.465930] tda18271: performing RF tracking filter calibration [ 818.572446] tda18271: RF tracking filter calibration complete [ 818.953946] tda18271: performing RF tracking filter calibration [ 825.093211] tda18271: RF tracking filter calibration complete >>> >>> >>> If you see this happen more than once consecutively, and there is only 1 >>> silicon tuner present, then it means something very bad is happening, and >>> there is a chance of burning out a part. I still wouldnt not recommend any >>> mainline merge until you can prevent this behavior -- I suspect that a GPIO >>> reset is being toggled where it shouldnt be, which should be harmless ... >>> but until we fix it, we cant be sure what damage might get done... >>> >>> The RF tracking filter calibration is a procedure that should only happen >>> once while the tuner is powered on -- it should *only* be repeated if the >>> tuner indicated that calibration is necessary, and that would only happen >>> after a hardware reset. >>> >>> This still looks fishy to me... > > Agreed. I did manage to dig into this some more last night, something is > definitely still awry. Here's a dmesg dump with some extra debug spew added > in key spots: > > ... > em28xx driver loaded > tda18271 4-0060: creating new instance > TDA18271HD/C2 detected @ 4-0060 > tda18271: R_EP1 is 0xce > cal is not initialized (cal_initialized=false)... > tda18271: performing RF tracking filter calibration > tda18271: RF tracking filter calibration complete (0xde) > DVB: registering new adapter (em28xx #0) > DVB: registering adapter 0 frontend 0 (LG Electronics LGDT3304 VSB/QAM > Frontend)... > em28xx #0: Successfully loaded em28xx-dvb > Em28xx: Initialized (Em28xx dvb Extension) extension > > 1st tuning attempt > > tda18271: R_EP1 is 0x00 > cal is not initialized (cal_initialized=true)... > tda18271: performing RF tracking filter calibration > tda18271: RF tracking filter calibration complete (0x00) > tda18271: R_EP1 is 0x00 > cal is not initialized (cal_initialized=true)... > tda18271: performing RF tracking filter calibration > tda18271: RF tracking filter calibration complete (0x00) > > 2nd tuning attempt > > tda18271: R_EP1 is 0x00 > cal is not initialized (cal_initialized=true)... > tda18271: performing RF tracking filter calibration > tda18271: RF tracking filter calibration complete (0x00) > tda18271: R_EP1 is 0x00 > cal is not initialized (cal_initialized=true)... > tda18271: performing RF tracking filter calibration > tda18271: RF tracking filter calibration complete (0x00) > > I'll try tweaking the GPIO reset mask and whatnot, definitely does seem like > something's getting reset that shouldn't, because you can clearly see that > cal *was* initialized, then R_EP1 got zeroed out. > >> It happened at every tuning operation, and made mythfrontend unhappy >> (unable to tune after the first channel). I disabled the check for >> RF_CAL_OK which triggered the recalibration, and mythfrontend worked. > > Yeah, tuning is much quicker here if I skip that check as well, but its > definitely not the proper fix. > >> The stick has been plugged in for a few months, so presumably would've >> caught on fire by now if it was going to. It would be nice if the >> tuning delay went away, though.. it still takes ~6 seconds to switch >> frequencies. > > Wait, it still takes that long with the check gone? I didn't poke for very > long with the check disabled, mostly focusing on trying to figure out why > things are going haywire. > >> I have not yet compiled and tested the lastest patches from Jarod. > > Really shouldn't be any difference from what you've got, they're just rebased > to the latest v4l-dvb tree. Hey Jarod, I haven't seen your exact GPIO config but I noticed something recently: the em28xx driver runs the dvb_gpio sequence whenever starting streaming, not just whenever opening the DVB frontend. This means that if your dvb_gpio definition strobes the tda18271 reset (as opposed to just taking it out of reset), then the chip will get reset whenever the streaming is started (a real problem if multiple tuning attempts are performed without closing the frontend first). Mauro seems to think this is intended behavior, although I cannot see how this could possibly be correct, especially since the .init() callback is not called in that case. I setup a tree to remove the call, but never got far enough into the testing to confirm whether it broke any improperly configured boards depending on the incorrect behavior. As a test, you might want to check your dvb_gpio config and see if you are pulling anything low and then high, and just remove the line that sets the pin low and see if the recalibration still occurs. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.c
Re: KWorld UB435-Q Support
On Nov 17, 2009, at 1:03 AM, Robert Cicconetti wrote: > On Tue, Nov 17, 2009 at 12:55 AM, Michael Krufky wrote: >>> [ 812.465930] tda18271: performing RF tracking filter calibration >>> [ 818.572446] tda18271: RF tracking filter calibration complete >>> [ 818.953946] tda18271: performing RF tracking filter calibration >>> [ 825.093211] tda18271: RF tracking filter calibration complete >> >> >> If you see this happen more than once consecutively, and there is only 1 >> silicon tuner present, then it means something very bad is happening, and >> there is a chance of burning out a part. I still wouldnt not recommend any >> mainline merge until you can prevent this behavior -- I suspect that a GPIO >> reset is being toggled where it shouldnt be, which should be harmless ... >> but until we fix it, we cant be sure what damage might get done... >> >> The RF tracking filter calibration is a procedure that should only happen >> once while the tuner is powered on -- it should *only* be repeated if the >> tuner indicated that calibration is necessary, and that would only happen >> after a hardware reset. >> >> This still looks fishy to me... Agreed. I did manage to dig into this some more last night, something is definitely still awry. Here's a dmesg dump with some extra debug spew added in key spots: ... em28xx driver loaded tda18271 4-0060: creating new instance TDA18271HD/C2 detected @ 4-0060 tda18271: R_EP1 is 0xce cal is not initialized (cal_initialized=false)... tda18271: performing RF tracking filter calibration tda18271: RF tracking filter calibration complete (0xde) DVB: registering new adapter (em28xx #0) DVB: registering adapter 0 frontend 0 (LG Electronics LGDT3304 VSB/QAM Frontend)... em28xx #0: Successfully loaded em28xx-dvb Em28xx: Initialized (Em28xx dvb Extension) extension 1st tuning attempt tda18271: R_EP1 is 0x00 cal is not initialized (cal_initialized=true)... tda18271: performing RF tracking filter calibration tda18271: RF tracking filter calibration complete (0x00) tda18271: R_EP1 is 0x00 cal is not initialized (cal_initialized=true)... tda18271: performing RF tracking filter calibration tda18271: RF tracking filter calibration complete (0x00) 2nd tuning attempt tda18271: R_EP1 is 0x00 cal is not initialized (cal_initialized=true)... tda18271: performing RF tracking filter calibration tda18271: RF tracking filter calibration complete (0x00) tda18271: R_EP1 is 0x00 cal is not initialized (cal_initialized=true)... tda18271: performing RF tracking filter calibration tda18271: RF tracking filter calibration complete (0x00) I'll try tweaking the GPIO reset mask and whatnot, definitely does seem like something's getting reset that shouldn't, because you can clearly see that cal *was* initialized, then R_EP1 got zeroed out. > It happened at every tuning operation, and made mythfrontend unhappy > (unable to tune after the first channel). I disabled the check for > RF_CAL_OK which triggered the recalibration, and mythfrontend worked. Yeah, tuning is much quicker here if I skip that check as well, but its definitely not the proper fix. > The stick has been plugged in for a few months, so presumably would've > caught on fire by now if it was going to. It would be nice if the > tuning delay went away, though.. it still takes ~6 seconds to switch > frequencies. Wait, it still takes that long with the check gone? I didn't poke for very long with the check disabled, mostly focusing on trying to figure out why things are going haywire. > I have not yet compiled and tested the lastest patches from Jarod. Really shouldn't be any difference from what you've got, they're just rebased to the latest v4l-dvb tree. -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KWorld UB435-Q Support
On Tue, Nov 17, 2009 at 12:55 AM, Michael Krufky wrote: >> [ 812.465930] tda18271: performing RF tracking filter calibration >> [ 818.572446] tda18271: RF tracking filter calibration complete >> [ 818.953946] tda18271: performing RF tracking filter calibration >> [ 825.093211] tda18271: RF tracking filter calibration complete > > > If you see this happen more than once consecutively, and there is only 1 > silicon tuner present, then it means something very bad is happening, and > there is a chance of burning out a part. I still wouldnt not recommend any > mainline merge until you can prevent this behavior -- I suspect that a GPIO > reset is being toggled where it shouldnt be, which should be harmless ... > but until we fix it, we cant be sure what damage might get done... > > The RF tracking filter calibration is a procedure that should only happen > once while the tuner is powered on -- it should *only* be repeated if the > tuner indicated that calibration is necessary, and that would only happen > after a hardware reset. > > This still looks fishy to me... It happened at every tuning operation, and made mythfrontend unhappy (unable to tune after the first channel). I disabled the check for RF_CAL_OK which triggered the recalibration, and mythfrontend worked. The stick has been plugged in for a few months, so presumably would've caught on fire by now if it was going to. It would be nice if the tuning delay went away, though.. it still takes ~6 seconds to switch frequencies. I have not yet compiled and tested the lastest patches from Jarod. R C -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KWorld UB435-Q Support
Jarod Wilson wrote: On Nov 15, 2009, at 11:55 PM, Jarod Wilson wrote: On 11/15/2009 11:46 PM, Jarod Wilson wrote: On 10/09/2009 09:27 PM, Robert Cicconetti wrote: On Wed, Oct 7, 2009 at 10:08 PM, Jarod Wilson wrote: On Oct 7, 2009, at 9:39 PM, Robert Cicconetti wrote: Okay... I built the tip of the archive linked above. It works with my UB435-Q fairly well, built against 2.6.28-15-generic #52-Ubuntu SMP x86_64. I've been able to stream QAM256 content for several hours reliably. Mythfrontend works somewhat... it'll tune the initial channel, but fails afterward. I suspect it is timing out while waiting for the RF tracking filter calibration... it adds about 6 seconds to every tuning operation. [ 812.465930] tda18271: performing RF tracking filter calibration [ 818.572446] tda18271: RF tracking filter calibration complete [ 818.953946] tda18271: performing RF tracking filter calibration [ 825.093211] tda18271: RF tracking filter calibration complete Any suggestions? Further data needed? Nothing off the top of my head, no. But I've got a UB435-Q of my own now, sitting on my desk waiting for me to poke at it... Not sure when I'll have time to actually poke at it though. :\ A little further poking yields that RF_CAL_OK in EP1 is 0, which is why it keeps recalibrating. I've commented out the part of the code that recalibrates if RF_CAL_OK is 0; EP1 always seems to be c6... and now mythfrontend is happy. :) This is not a long term solution, but as ugly hacks go it was pretty straight forward. :) Finally got around to poking at this again. Forward-ported the patches to the current v4l-dvb tip Meant to include this: http://wilsonet.com/jarod/junk/kworld-a340-20091115/ , and gave 'em a spin with my own UB435-Q, as well as a 340U that Doug gave me when he was in town a bit ago. Both are working just fine with my QAM feed here at the house, albeit with the same lengthy delay when changing channels you (Robert) mentioned. At a glance, I was hoping simply setting rf_cal_on_startup for the card-specific tda18271_config would remove the delay, but neither a 0 or a 1 seems to particularly help with tuning delays. Hoping maybe Mike has an idea on this part... In related news, I actually managed to get my original 340U with the C1 tuner to work briefly as well, and with the same code, no tuning delays. Seems either the PCB is cracked or the usb connector is just that bad, and it only works when positioned just so... I'll give all three sticks I've got here a quick spin with an OTA signal tomorrow too. But I think I'm not seeing any significant reason to not move forward with trying to get this code finally merged. All three check out with an OTA signal as well. I'll try to poke at the tuning delay thing a bit more tonight, but I'm inclined to send off formal patches Real Soon Now. Jarod, I havent had time to review this entire email thread yet... but: > [ 812.465930] tda18271: performing RF tracking filter calibration > [ 818.572446] tda18271: RF tracking filter calibration complete > [ 818.953946] tda18271: performing RF tracking filter calibration > [ 825.093211] tda18271: RF tracking filter calibration complete If you see this happen more than once consecutively, and there is only 1 silicon tuner present, then it means something very bad is happening, and there is a chance of burning out a part. I still wouldnt not recommend any mainline merge until you can prevent this behavior -- I suspect that a GPIO reset is being toggled where it shouldnt be, which should be harmless ... but until we fix it, we cant be sure what damage might get done... The RF tracking filter calibration is a procedure that should only happen once while the tuner is powered on -- it should *only* be repeated if the tuner indicated that calibration is necessary, and that would only happen after a hardware reset. This still looks fishy to me... -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KWorld UB435-Q Support
On Nov 15, 2009, at 11:55 PM, Jarod Wilson wrote: > On 11/15/2009 11:46 PM, Jarod Wilson wrote: >> On 10/09/2009 09:27 PM, Robert Cicconetti wrote: >>> On Wed, Oct 7, 2009 at 10:08 PM, Jarod Wilson wrote: On Oct 7, 2009, at 9:39 PM, Robert Cicconetti wrote: > Okay... I built the tip of the archive linked above. It works with my > UB435-Q fairly well, built against 2.6.28-15-generic #52-Ubuntu SMP > x86_64. I've been able to stream QAM256 content for several hours > reliably. Mythfrontend works somewhat... it'll tune the initial > channel, but fails afterward. I suspect it is timing out while waiting > for the RF tracking filter calibration... it adds about 6 seconds to > every tuning operation. > > [ 812.465930] tda18271: performing RF tracking filter calibration > [ 818.572446] tda18271: RF tracking filter calibration complete > [ 818.953946] tda18271: performing RF tracking filter calibration > [ 825.093211] tda18271: RF tracking filter calibration complete > > Any suggestions? Further data needed? Nothing off the top of my head, no. But I've got a UB435-Q of my own now, sitting on my desk waiting for me to poke at it... Not sure when I'll have time to actually poke at it though. :\ >>> >>> A little further poking yields that RF_CAL_OK in EP1 is 0, which is >>> why it keeps recalibrating. >>> >>> I've commented out the part of the code that recalibrates if RF_CAL_OK >>> is 0; EP1 always seems to be c6... and now mythfrontend is happy. :) >>> >>> This is not a long term solution, but as ugly hacks go it was pretty >>> straight forward. :) >> >> Finally got around to poking at this again. Forward-ported the patches >> to the current v4l-dvb tip > > Meant to include this: > > http://wilsonet.com/jarod/junk/kworld-a340-20091115/ > >> , and gave 'em a spin with my own UB435-Q, as >> well as a 340U that Doug gave me when he was in town a bit ago. Both are >> working just fine with my QAM feed here at the house, albeit with the >> same lengthy delay when changing channels you (Robert) mentioned. At a >> glance, I was hoping simply setting rf_cal_on_startup for the >> card-specific tda18271_config would remove the delay, but neither a 0 or >> a 1 seems to particularly help with tuning delays. Hoping maybe Mike has >> an idea on this part... >> >> In related news, I actually managed to get my original 340U with the C1 >> tuner to work briefly as well, and with the same code, no tuning delays. >> Seems either the PCB is cracked or the usb connector is just that bad, >> and it only works when positioned just so... > > I'll give all three sticks I've got here a quick spin with an OTA signal > tomorrow too. But I think I'm not seeing any significant reason to not move > forward with trying to get this code finally merged. All three check out with an OTA signal as well. I'll try to poke at the tuning delay thing a bit more tonight, but I'm inclined to send off formal patches Real Soon Now. -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KWorld UB435-Q Support
On 11/15/2009 11:46 PM, Jarod Wilson wrote: On 10/09/2009 09:27 PM, Robert Cicconetti wrote: On Wed, Oct 7, 2009 at 10:08 PM, Jarod Wilson wrote: On Oct 7, 2009, at 9:39 PM, Robert Cicconetti wrote: Okay... I built the tip of the archive linked above. It works with my UB435-Q fairly well, built against 2.6.28-15-generic #52-Ubuntu SMP x86_64. I've been able to stream QAM256 content for several hours reliably. Mythfrontend works somewhat... it'll tune the initial channel, but fails afterward. I suspect it is timing out while waiting for the RF tracking filter calibration... it adds about 6 seconds to every tuning operation. [ 812.465930] tda18271: performing RF tracking filter calibration [ 818.572446] tda18271: RF tracking filter calibration complete [ 818.953946] tda18271: performing RF tracking filter calibration [ 825.093211] tda18271: RF tracking filter calibration complete Any suggestions? Further data needed? Nothing off the top of my head, no. But I've got a UB435-Q of my own now, sitting on my desk waiting for me to poke at it... Not sure when I'll have time to actually poke at it though. :\ A little further poking yields that RF_CAL_OK in EP1 is 0, which is why it keeps recalibrating. I've commented out the part of the code that recalibrates if RF_CAL_OK is 0; EP1 always seems to be c6... and now mythfrontend is happy. :) This is not a long term solution, but as ugly hacks go it was pretty straight forward. :) Finally got around to poking at this again. Forward-ported the patches to the current v4l-dvb tip Meant to include this: http://wilsonet.com/jarod/junk/kworld-a340-20091115/ , and gave 'em a spin with my own UB435-Q, as well as a 340U that Doug gave me when he was in town a bit ago. Both are working just fine with my QAM feed here at the house, albeit with the same lengthy delay when changing channels you (Robert) mentioned. At a glance, I was hoping simply setting rf_cal_on_startup for the card-specific tda18271_config would remove the delay, but neither a 0 or a 1 seems to particularly help with tuning delays. Hoping maybe Mike has an idea on this part... In related news, I actually managed to get my original 340U with the C1 tuner to work briefly as well, and with the same code, no tuning delays. Seems either the PCB is cracked or the usb connector is just that bad, and it only works when positioned just so... I'll give all three sticks I've got here a quick spin with an OTA signal tomorrow too. But I think I'm not seeing any significant reason to not move forward with trying to get this code finally merged. -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KWorld UB435-Q Support
On 10/09/2009 09:27 PM, Robert Cicconetti wrote: On Wed, Oct 7, 2009 at 10:08 PM, Jarod Wilson wrote: On Oct 7, 2009, at 9:39 PM, Robert Cicconetti wrote: Okay... I built the tip of the archive linked above. It works with my UB435-Q fairly well, built against 2.6.28-15-generic #52-Ubuntu SMP x86_64. I've been able to stream QAM256 content for several hours reliably. Mythfrontend works somewhat... it'll tune the initial channel, but fails afterward. I suspect it is timing out while waiting for the RF tracking filter calibration... it adds about 6 seconds to every tuning operation. [ 812.465930] tda18271: performing RF tracking filter calibration [ 818.572446] tda18271: RF tracking filter calibration complete [ 818.953946] tda18271: performing RF tracking filter calibration [ 825.093211] tda18271: RF tracking filter calibration complete Any suggestions? Further data needed? Nothing off the top of my head, no. But I've got a UB435-Q of my own now, sitting on my desk waiting for me to poke at it... Not sure when I'll have time to actually poke at it though. :\ A little further poking yields that RF_CAL_OK in EP1 is 0, which is why it keeps recalibrating. I've commented out the part of the code that recalibrates if RF_CAL_OK is 0; EP1 always seems to be c6... and now mythfrontend is happy. :) This is not a long term solution, but as ugly hacks go it was pretty straight forward. :) Finally got around to poking at this again. Forward-ported the patches to the current v4l-dvb tip, and gave 'em a spin with my own UB435-Q, as well as a 340U that Doug gave me when he was in town a bit ago. Both are working just fine with my QAM feed here at the house, albeit with the same lengthy delay when changing channels you (Robert) mentioned. At a glance, I was hoping simply setting rf_cal_on_startup for the card-specific tda18271_config would remove the delay, but neither a 0 or a 1 seems to particularly help with tuning delays. Hoping maybe Mike has an idea on this part... In related news, I actually managed to get my original 340U with the C1 tuner to work briefly as well, and with the same code, no tuning delays. Seems either the PCB is cracked or the usb connector is just that bad, and it only works when positioned just so... -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KWorld UB435-Q Support
On Wed, Oct 7, 2009 at 10:08 PM, Jarod Wilson wrote: > On Oct 7, 2009, at 9:39 PM, Robert Cicconetti wrote: >> Okay... I built the tip of the archive linked above. It works with my >> UB435-Q fairly well, built against 2.6.28-15-generic #52-Ubuntu SMP >> x86_64. I've been able to stream QAM256 content for several hours >> reliably. Mythfrontend works somewhat... it'll tune the initial >> channel, but fails afterward. I suspect it is timing out while waiting >> for the RF tracking filter calibration... it adds about 6 seconds to >> every tuning operation. >> >> [ 812.465930] tda18271: performing RF tracking filter calibration >> [ 818.572446] tda18271: RF tracking filter calibration complete >> [ 818.953946] tda18271: performing RF tracking filter calibration >> [ 825.093211] tda18271: RF tracking filter calibration complete >> >> Any suggestions? Further data needed? > > Nothing off the top of my head, no. But I've got a UB435-Q of my own now, > sitting on my desk waiting for me to poke at it... Not sure when I'll have > time to actually poke at it though. :\ A little further poking yields that RF_CAL_OK in EP1 is 0, which is why it keeps recalibrating. I've commented out the part of the code that recalibrates if RF_CAL_OK is 0; EP1 always seems to be c6... and now mythfrontend is happy. :) This is not a long term solution, but as ugly hacks go it was pretty straight forward. :) -Bob -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KWorld UB435-Q Support
On Oct 7, 2009, at 9:39 PM, Robert Cicconetti wrote: Jarod Wilson wrote: With that caveat emptor, here's where the tree that should at least get you 95% of the way there with that stick resides: http://www.kernellabs.com/hg/~mkrufky/lgdt3304-3/ Okay... I built the tip of the archive linked above. It works with my UB435-Q fairly well, built against 2.6.28-15-generic #52-Ubuntu SMP x86_64. I've been able to stream QAM256 content for several hours reliably. Mythfrontend works somewhat... it'll tune the initial channel, but fails afterward. I suspect it is timing out while waiting for the RF tracking filter calibration... it adds about 6 seconds to every tuning operation. [ 812.465930] tda18271: performing RF tracking filter calibration [ 818.572446] tda18271: RF tracking filter calibration complete [ 818.953946] tda18271: performing RF tracking filter calibration [ 825.093211] tda18271: RF tracking filter calibration complete Initialization: [ 217.319831] em28xx: New device USB 2870 Device @ 480 Mbps (1b80:a340, interfa ce 0, class 0) [ 217.319842] em28xx #0: Identified as KWorld PlusTV 340U (ATSC) (card=71) [ 217.320062] em28xx #0: chip ID is em2870 [ 217.448225] em28xx #0: i2c eeprom 00: 1a eb 67 95 80 1b 40 a3 c0 13 6b 10 6a 22 00 00 [ 217.448244] em28xx #0: i2c eeprom 10: 00 00 04 57 00 0d 00 00 00 00 00 00 00 00 00 00 [ 217.448260] em28xx #0: i2c eeprom 20: 44 00 00 00 f0 10 01 00 00 00 00 00 5b 1c c0 00 [ 217.448275] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 00 00 00 00 [ 217.448290] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 217.448304] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 217.448319] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 22 03 55 00 53 00 [ 217.448333] em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 37 00 30 00 20 00 44 00 [ 217.448348] em28xx #0: i2c eeprom 80: 65 00 76 00 69 00 63 00 65 00 00 00 00 00 00 00 [ 217.448362] em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 217.448376] em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 217.448390] em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 217.448405] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 217.448419] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 217.448433] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 217.448447] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 217.448465] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x2888a312 [ 217.448469] em28xx #0: EEPROM info: [ 217.448472] em28xx #0: No audio on board. [ 217.448475] em28xx #0: 500mA max power [ 217.448479] em28xx #0: Table at 0x04, strings=0x226a, 0x, 0x [ 217.448488] em28xx #0: v4l2 driver version 0.1.2 [ 217.454853] em28xx #0: V4L2 device registered as /dev/video0 and / dev/vbi0 [ 217.454889] usbcore: registered new interface driver em28xx [ 217.454895] em28xx driver loaded Any suggestions? Further data needed? Nothing off the top of my head, no. But I've got a UB435-Q of my own now, sitting on my desk waiting for me to poke at it... Not sure when I'll have time to actually poke at it though. :\ -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
KWorld UB435-Q Support
Jarod Wilson wrote: > With that caveat emptor, here's where the tree that should at least get you > 95% of the way > there with that stick resides: > > http://www.kernellabs.com/hg/~mkrufky/lgdt3304-3/ Okay... I built the tip of the archive linked above. It works with my UB435-Q fairly well, built against 2.6.28-15-generic #52-Ubuntu SMP x86_64. I've been able to stream QAM256 content for several hours reliably. Mythfrontend works somewhat... it'll tune the initial channel, but fails afterward. I suspect it is timing out while waiting for the RF tracking filter calibration... it adds about 6 seconds to every tuning operation. [ 812.465930] tda18271: performing RF tracking filter calibration [ 818.572446] tda18271: RF tracking filter calibration complete [ 818.953946] tda18271: performing RF tracking filter calibration [ 825.093211] tda18271: RF tracking filter calibration complete Initialization: [ 217.319831] em28xx: New device USB 2870 Device @ 480 Mbps (1b80:a340, interfa ce 0, class 0) [ 217.319842] em28xx #0: Identified as KWorld PlusTV 340U (ATSC) (card=71) [ 217.320062] em28xx #0: chip ID is em2870 [ 217.448225] em28xx #0: i2c eeprom 00: 1a eb 67 95 80 1b 40 a3 c0 13 6b 10 6a 22 00 00 [ 217.448244] em28xx #0: i2c eeprom 10: 00 00 04 57 00 0d 00 00 00 00 00 00 00 00 00 00 [ 217.448260] em28xx #0: i2c eeprom 20: 44 00 00 00 f0 10 01 00 00 00 00 00 5b 1c c0 00 [ 217.448275] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 00 00 00 00 [ 217.448290] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 217.448304] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 217.448319] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 22 03 55 00 53 00 [ 217.448333] em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 37 00 30 00 20 00 44 00 [ 217.448348] em28xx #0: i2c eeprom 80: 65 00 76 00 69 00 63 00 65 00 00 00 00 00 00 00 [ 217.448362] em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 217.448376] em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 217.448390] em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 217.448405] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 217.448419] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 217.448433] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 217.448447] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 217.448465] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x2888a312 [ 217.448469] em28xx #0: EEPROM info: [ 217.448472] em28xx #0: No audio on board. [ 217.448475] em28xx #0: 500mA max power [ 217.448479] em28xx #0: Table at 0x04, strings=0x226a, 0x, 0x [ 217.448488] em28xx #0: v4l2 driver version 0.1.2 [ 217.454853] em28xx #0: V4L2 device registered as /dev/video0 and /dev/vbi0 [ 217.454889] usbcore: registered new interface driver em28xx [ 217.454895] em28xx driver loaded Any suggestions? Further data needed? Thanks! R C -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KWorld UB435-Q support?
On Mon August 17 2009, Jarod Wilson wrote: > On Aug 17, 2009, at 3:28 PM, Thomas Fjellstrom wrote: > > Yeah, I've had absolutely no luck with it so far, and have returned > > it :( > > given your experience, and mine combined, I don't think its worth > > the time to > > fix it. Especially since I can't even tune a channel on the darn > > thing in any > > OS I have access to. > > Now, did you try it with some other OS before trying it under Linux, > and it failed to work, or did you only try other OS after trying under > Linux w/that tree? There's some concern that perhaps the stick might > be getting neutered on the Linux side by an incorrect gpio setting or > something... But my stick worked (flaky usb connection aside) for > quite some time before it stopped working, even with lots of > unplugging and replugging over several days while working on the > driver... I may have plugged it in in linux before windows, but at that point I didn't have the drivers for linux installed, so I doubt incorrect gpio settings could have damaged it. > > It did indeed have trouble keeping a connection, but when ever it lost > > connection, I got that message. And the driver is pretty much stuck. > > can't > > rmmod it, and it won't redetect the stick, so every single time it > > looses > > connection, I have to reboot. Hardly a good way to work. > > Indeed. I wonder if there are bad solder joints in these, or what?... > Mine's dead, yours is dead, Mike Krufky had to RMA his first one and > his second one seems it might be dead too... :\ I dunno, but I'm thinking of just getting a HVR 1800 or similar. Go with my two PVR 150's that work flawlessly. -- Thomas Fjellstrom tfjellst...@shaw.ca -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KWorld UB435-Q support?
On Aug 17, 2009, at 3:28 PM, Thomas Fjellstrom wrote: Yeah, I've had absolutely no luck with it so far, and have returned it :( given your experience, and mine combined, I don't think its worth the time to fix it. Especially since I can't even tune a channel on the darn thing in any OS I have access to. Now, did you try it with some other OS before trying it under Linux, and it failed to work, or did you only try other OS after trying under Linux w/that tree? There's some concern that perhaps the stick might be getting neutered on the Linux side by an incorrect gpio setting or something... But my stick worked (flaky usb connection aside) for quite some time before it stopped working, even with lots of unplugging and replugging over several days while working on the driver... It did indeed have trouble keeping a connection, but when ever it lost connection, I got that message. And the driver is pretty much stuck. can't rmmod it, and it won't redetect the stick, so every single time it looses connection, I have to reboot. Hardly a good way to work. Indeed. I wonder if there are bad solder joints in these, or what?... Mine's dead, yours is dead, Mike Krufky had to RMA his first one and his second one seems it might be dead too... :\ -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KWorld UB435-Q support?
On Mon August 17 2009, Jarod Wilson wrote: > On Aug 14, 2009, at 11:03 AM, Thomas Fjellstrom wrote: > > On Fri August 14 2009, Jarod Wilson wrote: > >> On Aug 14, 2009, at 1:12 AM, Thomas Fjellstrom wrote: > >>> On Thu August 13 2009, Jarod Wilson wrote: > On Aug 13, 2009, at 12:53 AM, Thomas Fjellstrom wrote: > > I stupidly bought the KWorld UB435-Q usb ATSC tuner thinking it > > was > > supported > > under linux, and it turns out it isn't. I'm wondering what it > > would > > take to > > get it supported. It seems like all of the main chips it uses are > > supported, > > but the glue code is missing. > > > > I have some C (10 years) programming experience, and have wanted > > to > > contribute > > to the linux kernel for quite a while, now I have a good excuse ;) > > > > Would anyone be willing to point me in the right direction? > > The UB435-Q is a rebadge of the revision B 340U, which is an em2870 > bridge, lgdt3304 demodulator and an nxp tda18271hd/c2 tuner. Its > got > the same device ID and everything. I've got a rev A 340U, the only > difference being that it has an nxp tda18271hd/c1 tuner (also same > device ID). I *had* it working just fine until the stick up and > died > on me, before I could push the code for merge, but its still > floating > about. It wasn't quite working with a c2 device, but that could > have > been a device problem (these are quite franky, cheap and poorly > made > devices, imo). It could also be that the code ate both sticks and > will > pickle yours as well. > > With that caveat emptor, here's where the tree that should at least > get you 95% of the way there with that stick resides: > > http://www.kernellabs.com/hg/~mkrufky/lgdt3304-3/ > > The last two patches are the relevant ones. They add lgdt3304 demod > support to the lgdt3305 driver (because the current lgdt3304 driver > is, um, lacking) and then add the bits to wire up the stick. > >>> > >>> Hi, thanks for the tips. I've applied the last two patches to v4l > >>> "tip", a few > >>> hunks failed, but I managed to apply them by hand, though possibly > >>> not > >>> correctly as I can't seem to find a program that thinks the /dev/ > >>> video0 device > >>> that pops up is valid. One app claims there is no input on /dev/ > >>> video0, and > >>> others just get "select timeouts" and such (also errors regarding > >>> formats and > >>> whatnot). > >> > >> These sticks are digital-only. Its a driver shortcoming that the > >> *analog* /dev/video0 device is being created. You need to be > >> hitting / > >> dev/dvb/adapterX/*, not /dev/video0. See > >> http://linuxtv.org/wiki/index.php/Testing_your_DVB_device > > > > Ah, thanks for that. > > > > So far I've noticed the lgdt driver is very NOT robust, or maybe its > > one of > > the other drivers (em28xx?) causing it to die, but if the stick looses > > connection with usb at all, the driver locks up, spews a BUNCH of > > errors to > > dmesg, and eventually the kernel complains: > > > > [ 840.552148] INFO: task khubd:170 blocked for more than 120 seconds. > > [ 840.552155] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > > disables > > this message. > > [ 840.552162] khubd D 8800010220c0 0 170 2 > > [ 840.552172] 88003793a500 0046 88007bd2f600 > > 0286 > > [ 840.552182] 88007a011900 000120c0 e250 > > 88007d13a3c0 > > [ 840.552191] 88007d13a6b0 8034e421 88007bd3d800 > > a046a7c8 > > [ 840.552200] Call Trace: > > [ 840.552220] [] ? schedule+0x9/0x1d > > [ 840.552243] [] ? dvb_dmxdev_release+0xd8/0x119 > > [dvb_core] > > [ 840.552253] [] ? autoremove_wake_function > > +0x0/0x2e > > [ 840.552265] [] ? dvb_fini+0x5b/0x91 [em28xx_dvb] > > [ 840.552289] [] ? em28xx_close_extension > > +0x35/0x56 > > [em28xx] > > [ 840.552308] [] ? em28xx_usb_disconnect > > +0xf4/0x120 > > [em28xx] > > [ 840.552319] [] ? usb_unbind_interface+0x5b/0xe1 > > [ 840.552329] [] ? __device_release_driver > > +0x77/0x9e > > [ 840.552336] [] ? device_release_driver+0x1e/0x2a > > [ 840.552344] [] ? bus_remove_device+0x8d/0xac > > [ 840.552352] [] ? device_del+0x130/0x198 > > [ 840.552359] [] ? usb_disable_device+0x6c/0xe4 > > [ 840.552370] [] ? usb_disconnect+0x8c/0x10a > > [ 840.552378] [] ? hub_thread+0x625/0x1040 > > [ 840.552387] [] ? dequeue_entity+0xf/0x11f > > [ 840.552395] [] ? autoremove_wake_function > > +0x0/0x2e > > [ 840.552403] [] ? hub_thread+0x0/0x1040 > > [ 840.552410] [] ? hub_thread+0x0/0x1040 > > [ 840.552418] [] ? hub_thread+0x0/0x1040 > > [ 840.552427] [] ? kthread+0x54/0x80 > > [ 840.552435] [] ? child_rip+0xa/0x20 > > [ 840.552444] [] ? kthread+0x0/0x80 > > [ 840.552450] [] ? child_rip+0x0/0x20 > > > > I'm assuming the only way t
Re: KWorld UB435-Q support?
On Aug 14, 2009, at 11:03 AM, Thomas Fjellstrom wrote: On Fri August 14 2009, Jarod Wilson wrote: On Aug 14, 2009, at 1:12 AM, Thomas Fjellstrom wrote: On Thu August 13 2009, Jarod Wilson wrote: On Aug 13, 2009, at 12:53 AM, Thomas Fjellstrom wrote: I stupidly bought the KWorld UB435-Q usb ATSC tuner thinking it was supported under linux, and it turns out it isn't. I'm wondering what it would take to get it supported. It seems like all of the main chips it uses are supported, but the glue code is missing. I have some C (10 years) programming experience, and have wanted to contribute to the linux kernel for quite a while, now I have a good excuse ;) Would anyone be willing to point me in the right direction? The UB435-Q is a rebadge of the revision B 340U, which is an em2870 bridge, lgdt3304 demodulator and an nxp tda18271hd/c2 tuner. Its got the same device ID and everything. I've got a rev A 340U, the only difference being that it has an nxp tda18271hd/c1 tuner (also same device ID). I *had* it working just fine until the stick up and died on me, before I could push the code for merge, but its still floating about. It wasn't quite working with a c2 device, but that could have been a device problem (these are quite franky, cheap and poorly made devices, imo). It could also be that the code ate both sticks and will pickle yours as well. With that caveat emptor, here's where the tree that should at least get you 95% of the way there with that stick resides: http://www.kernellabs.com/hg/~mkrufky/lgdt3304-3/ The last two patches are the relevant ones. They add lgdt3304 demod support to the lgdt3305 driver (because the current lgdt3304 driver is, um, lacking) and then add the bits to wire up the stick. Hi, thanks for the tips. I've applied the last two patches to v4l "tip", a few hunks failed, but I managed to apply them by hand, though possibly not correctly as I can't seem to find a program that thinks the /dev/ video0 device that pops up is valid. One app claims there is no input on /dev/ video0, and others just get "select timeouts" and such (also errors regarding formats and whatnot). These sticks are digital-only. Its a driver shortcoming that the *analog* /dev/video0 device is being created. You need to be hitting / dev/dvb/adapterX/*, not /dev/video0. See http://linuxtv.org/wiki/index.php/Testing_your_DVB_device Ah, thanks for that. So far I've noticed the lgdt driver is very NOT robust, or maybe its one of the other drivers (em28xx?) causing it to die, but if the stick looses connection with usb at all, the driver locks up, spews a BUNCH of errors to dmesg, and eventually the kernel complains: [ 840.552148] INFO: task khubd:170 blocked for more than 120 seconds. [ 840.552155] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 840.552162] khubd D 8800010220c0 0 170 2 [ 840.552172] 88003793a500 0046 88007bd2f600 0286 [ 840.552182] 88007a011900 000120c0 e250 88007d13a3c0 [ 840.552191] 88007d13a6b0 8034e421 88007bd3d800 a046a7c8 [ 840.552200] Call Trace: [ 840.552220] [] ? schedule+0x9/0x1d [ 840.552243] [] ? dvb_dmxdev_release+0xd8/0x119 [dvb_core] [ 840.552253] [] ? autoremove_wake_function +0x0/0x2e [ 840.552265] [] ? dvb_fini+0x5b/0x91 [em28xx_dvb] [ 840.552289] [] ? em28xx_close_extension +0x35/0x56 [em28xx] [ 840.552308] [] ? em28xx_usb_disconnect +0xf4/0x120 [em28xx] [ 840.552319] [] ? usb_unbind_interface+0x5b/0xe1 [ 840.552329] [] ? __device_release_driver +0x77/0x9e [ 840.552336] [] ? device_release_driver+0x1e/0x2a [ 840.552344] [] ? bus_remove_device+0x8d/0xac [ 840.552352] [] ? device_del+0x130/0x198 [ 840.552359] [] ? usb_disable_device+0x6c/0xe4 [ 840.552370] [] ? usb_disconnect+0x8c/0x10a [ 840.552378] [] ? hub_thread+0x625/0x1040 [ 840.552387] [] ? dequeue_entity+0xf/0x11f [ 840.552395] [] ? autoremove_wake_function +0x0/0x2e [ 840.552403] [] ? hub_thread+0x0/0x1040 [ 840.552410] [] ? hub_thread+0x0/0x1040 [ 840.552418] [] ? hub_thread+0x0/0x1040 [ 840.552427] [] ? kthread+0x54/0x80 [ 840.552435] [] ? child_rip+0xa/0x20 [ 840.552444] [] ? kthread+0x0/0x80 [ 840.552450] [] ? child_rip+0x0/0x20 I'm assuming the only way to restore any kind of function is to reboot (rmmoding em28xx_dbv hangs, and rmmod is unkillable). I'll try working with this a bit more tomorrow (if I can figure out why its hanging), as it is I'm off for some sleep :) Huh, that looks nothing like anything I ever saw with my stick. However, I will note that mine seemed to have major issues keeping a solid physical connection to the usb bus, but it only manifested as huge amounts of packet loss. These are cheaply made devices that I have little faith in now... -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line "unsubscribe
Re: KWorld UB435-Q support?
On Fri August 14 2009, Jarod Wilson wrote: > On Aug 14, 2009, at 1:12 AM, Thomas Fjellstrom wrote: > > On Thu August 13 2009, Jarod Wilson wrote: > >> On Aug 13, 2009, at 12:53 AM, Thomas Fjellstrom wrote: > >>> I stupidly bought the KWorld UB435-Q usb ATSC tuner thinking it was > >>> supported > >>> under linux, and it turns out it isn't. I'm wondering what it would > >>> take to > >>> get it supported. It seems like all of the main chips it uses are > >>> supported, > >>> but the glue code is missing. > >>> > >>> I have some C (10 years) programming experience, and have wanted to > >>> contribute > >>> to the linux kernel for quite a while, now I have a good excuse ;) > >>> > >>> Would anyone be willing to point me in the right direction? > >> > >> The UB435-Q is a rebadge of the revision B 340U, which is an em2870 > >> bridge, lgdt3304 demodulator and an nxp tda18271hd/c2 tuner. Its got > >> the same device ID and everything. I've got a rev A 340U, the only > >> difference being that it has an nxp tda18271hd/c1 tuner (also same > >> device ID). I *had* it working just fine until the stick up and died > >> on me, before I could push the code for merge, but its still floating > >> about. It wasn't quite working with a c2 device, but that could have > >> been a device problem (these are quite franky, cheap and poorly made > >> devices, imo). It could also be that the code ate both sticks and > >> will > >> pickle yours as well. > >> > >> With that caveat emptor, here's where the tree that should at least > >> get you 95% of the way there with that stick resides: > >> > >> http://www.kernellabs.com/hg/~mkrufky/lgdt3304-3/ > >> > >> The last two patches are the relevant ones. They add lgdt3304 demod > >> support to the lgdt3305 driver (because the current lgdt3304 driver > >> is, um, lacking) and then add the bits to wire up the stick. > > > > Hi, thanks for the tips. I've applied the last two patches to v4l > > "tip", a few > > hunks failed, but I managed to apply them by hand, though possibly not > > correctly as I can't seem to find a program that thinks the /dev/ > > video0 device > > that pops up is valid. One app claims there is no input on /dev/ > > video0, and > > others just get "select timeouts" and such (also errors regarding > > formats and > > whatnot). > > These sticks are digital-only. Its a driver shortcoming that the > *analog* /dev/video0 device is being created. You need to be hitting / > dev/dvb/adapterX/*, not /dev/video0. See > http://linuxtv.org/wiki/index.php/Testing_your_DVB_device Ah, thanks for that. So far I've noticed the lgdt driver is very NOT robust, or maybe its one of the other drivers (em28xx?) causing it to die, but if the stick looses connection with usb at all, the driver locks up, spews a BUNCH of errors to dmesg, and eventually the kernel complains: [ 840.552148] INFO: task khubd:170 blocked for more than 120 seconds. [ 840.552155] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 840.552162] khubd D 8800010220c0 0 170 2 [ 840.552172] 88003793a500 0046 88007bd2f600 0286 [ 840.552182] 88007a011900 000120c0 e250 88007d13a3c0 [ 840.552191] 88007d13a6b0 8034e421 88007bd3d800 a046a7c8 [ 840.552200] Call Trace: [ 840.552220] [] ? schedule+0x9/0x1d [ 840.552243] [] ? dvb_dmxdev_release+0xd8/0x119 [dvb_core] [ 840.552253] [] ? autoremove_wake_function+0x0/0x2e [ 840.552265] [] ? dvb_fini+0x5b/0x91 [em28xx_dvb] [ 840.552289] [] ? em28xx_close_extension+0x35/0x56 [em28xx] [ 840.552308] [] ? em28xx_usb_disconnect+0xf4/0x120 [em28xx] [ 840.552319] [] ? usb_unbind_interface+0x5b/0xe1 [ 840.552329] [] ? __device_release_driver+0x77/0x9e [ 840.552336] [] ? device_release_driver+0x1e/0x2a [ 840.552344] [] ? bus_remove_device+0x8d/0xac [ 840.552352] [] ? device_del+0x130/0x198 [ 840.552359] [] ? usb_disable_device+0x6c/0xe4 [ 840.552370] [] ? usb_disconnect+0x8c/0x10a [ 840.552378] [] ? hub_thread+0x625/0x1040 [ 840.552387] [] ? dequeue_entity+0xf/0x11f [ 840.552395] [] ? autoremove_wake_function+0x0/0x2e [ 840.552403] [] ? hub_thread+0x0/0x1040 [ 840.552410] [] ? hub_thread+0x0/0x1040 [ 840.552418] [] ? hub_thread+0x0/0x1040 [ 840.552427] [] ? kthread+0x54/0x80 [ 840.552435] [] ? child_rip+0xa/0x20 [ 840.552444] [] ? kthread+0x0/0x80 [ 840.552450] [] ? child_rip+0x0/0x20 I'm assuming the only way to restore any kind of function is to reboot (rmmoding em28xx_dbv hangs, and rmmod is unkillable). I'll try working with this a bit more tomorrow (if I can figure out why its hanging), as it is I'm off for some sleep :) -- Thomas Fjellstrom tfjellst...@shaw.ca -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KWorld UB435-Q support?
On Aug 14, 2009, at 1:12 AM, Thomas Fjellstrom wrote: On Thu August 13 2009, Jarod Wilson wrote: On Aug 13, 2009, at 12:53 AM, Thomas Fjellstrom wrote: I stupidly bought the KWorld UB435-Q usb ATSC tuner thinking it was supported under linux, and it turns out it isn't. I'm wondering what it would take to get it supported. It seems like all of the main chips it uses are supported, but the glue code is missing. I have some C (10 years) programming experience, and have wanted to contribute to the linux kernel for quite a while, now I have a good excuse ;) Would anyone be willing to point me in the right direction? The UB435-Q is a rebadge of the revision B 340U, which is an em2870 bridge, lgdt3304 demodulator and an nxp tda18271hd/c2 tuner. Its got the same device ID and everything. I've got a rev A 340U, the only difference being that it has an nxp tda18271hd/c1 tuner (also same device ID). I *had* it working just fine until the stick up and died on me, before I could push the code for merge, but its still floating about. It wasn't quite working with a c2 device, but that could have been a device problem (these are quite franky, cheap and poorly made devices, imo). It could also be that the code ate both sticks and will pickle yours as well. With that caveat emptor, here's where the tree that should at least get you 95% of the way there with that stick resides: http://www.kernellabs.com/hg/~mkrufky/lgdt3304-3/ The last two patches are the relevant ones. They add lgdt3304 demod support to the lgdt3305 driver (because the current lgdt3304 driver is, um, lacking) and then add the bits to wire up the stick. Hi, thanks for the tips. I've applied the last two patches to v4l "tip", a few hunks failed, but I managed to apply them by hand, though possibly not correctly as I can't seem to find a program that thinks the /dev/ video0 device that pops up is valid. One app claims there is no input on /dev/ video0, and others just get "select timeouts" and such (also errors regarding formats and whatnot). These sticks are digital-only. Its a driver shortcoming that the *analog* /dev/video0 device is being created. You need to be hitting / dev/dvb/adapterX/*, not /dev/video0. See http://linuxtv.org/wiki/index.php/Testing_your_DVB_device -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KWorld UB435-Q support?
On Thu August 13 2009, Jarod Wilson wrote: > On Aug 13, 2009, at 12:53 AM, Thomas Fjellstrom wrote: > > I stupidly bought the KWorld UB435-Q usb ATSC tuner thinking it was > > supported > > under linux, and it turns out it isn't. I'm wondering what it would > > take to > > get it supported. It seems like all of the main chips it uses are > > supported, > > but the glue code is missing. > > > > I have some C (10 years) programming experience, and have wanted to > > contribute > > to the linux kernel for quite a while, now I have a good excuse ;) > > > > Would anyone be willing to point me in the right direction? > > The UB435-Q is a rebadge of the revision B 340U, which is an em2870 > bridge, lgdt3304 demodulator and an nxp tda18271hd/c2 tuner. Its got > the same device ID and everything. I've got a rev A 340U, the only > difference being that it has an nxp tda18271hd/c1 tuner (also same > device ID). I *had* it working just fine until the stick up and died > on me, before I could push the code for merge, but its still floating > about. It wasn't quite working with a c2 device, but that could have > been a device problem (these are quite franky, cheap and poorly made > devices, imo). It could also be that the code ate both sticks and will > pickle yours as well. > > With that caveat emptor, here's where the tree that should at least > get you 95% of the way there with that stick resides: > > http://www.kernellabs.com/hg/~mkrufky/lgdt3304-3/ > > The last two patches are the relevant ones. They add lgdt3304 demod > support to the lgdt3305 driver (because the current lgdt3304 driver > is, um, lacking) and then add the bits to wire up the stick. Hi, thanks for the tips. I've applied the last two patches to v4l "tip", a few hunks failed, but I managed to apply them by hand, though possibly not correctly as I can't seem to find a program that thinks the /dev/video0 device that pops up is valid. One app claims there is no input on /dev/video0, and others just get "select timeouts" and such (also errors regarding formats and whatnot). Upon inserting the stick I get the following from dmesg: [68582.498964] em28xx: New device USB 2870 Device @ 480 Mbps (1b80:a340, interface 0, class 0) [68582.499243] em28xx #0: chip ID is em2870 [68582.627112] em28xx #0: i2c eeprom 00: 1a eb 67 95 80 1b 40 a3 c0 13 6b 10 6a 22 00 00 [68582.627134] em28xx #0: i2c eeprom 10: 00 00 04 57 00 0d 00 00 00 00 00 00 00 00 00 00 [68582.627153] em28xx #0: i2c eeprom 20: 44 00 00 00 f0 10 01 00 00 00 00 00 5b 1c c0 00 [68582.627173] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 00 00 00 00 [68582.627192] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [68582.627211] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [68582.627229] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 22 03 55 00 53 00 [68582.627249] em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 37 00 30 00 20 00 44 00 [68582.627268] em28xx #0: i2c eeprom 80: 65 00 76 00 69 00 63 00 65 00 00 00 00 00 00 00 [68582.627287] em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [68582.627306] em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [68582.627325] em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [68582.627344] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [68582.627362] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [68582.627381] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [68582.627400] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [68582.627422] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x2888a312 [68582.627426] em28xx #0: EEPROM info: [68582.627430] em28xx #0: No audio on board. [68582.627433] em28xx #0: 500mA max power [68582.627438] em28xx #0: Table at 0x04, strings=0x226a, 0x, 0x [68582.628230] em28xx #0: Identified as KWorld PlusTV 340U (ATSC) (card=72) [68582.628239] em28xx #0: v4l2 driver version 0.1.2 [68582.633740] em28xx #0: V4L2 device registered as /dev/video0 and /dev/vbi0 [68582.633783] usbcore: registered new interface driver em28xx [68582.633789] em28xx driver loaded [68582.711423] tda18271 3-0060: creating new instance [68582.713367] TDA18271HD/C2 detected @ 3-0060 [68582.944857] DVB: registering new adapter (em28xx #0) [68582.944865] DVB: registering adapter 0 frontend 0 (LG Electronics LGDT3304 VSB/QAM Frontend)... [68582.945500] Successfully loaded em28xx-dvb [68582.945504] Em28xx: Initialized (Em28xx dvb Extension) extension ... [69539.736866] tda18271: performing RF tracking filter calibration [69542.492537] tda18271: RF tracking filter calibration complete and this is what I get from mplayer (one of the more verbose players I found) Selected device: KWorld PlusTV 340U (ATSC) Capabilites: video capture read/write streaming supported norms: 0 = NTSC;
Re: KWorld UB435-Q support?
On Aug 13, 2009, at 12:53 AM, Thomas Fjellstrom wrote: I stupidly bought the KWorld UB435-Q usb ATSC tuner thinking it was supported under linux, and it turns out it isn't. I'm wondering what it would take to get it supported. It seems like all of the main chips it uses are supported, but the glue code is missing. I have some C (10 years) programming experience, and have wanted to contribute to the linux kernel for quite a while, now I have a good excuse ;) Would anyone be willing to point me in the right direction? The UB435-Q is a rebadge of the revision B 340U, which is an em2870 bridge, lgdt3304 demodulator and an nxp tda18271hd/c2 tuner. Its got the same device ID and everything. I've got a rev A 340U, the only difference being that it has an nxp tda18271hd/c1 tuner (also same device ID). I *had* it working just fine until the stick up and died on me, before I could push the code for merge, but its still floating about. It wasn't quite working with a c2 device, but that could have been a device problem (these are quite franky, cheap and poorly made devices, imo). It could also be that the code ate both sticks and will pickle yours as well. With that caveat emptor, here's where the tree that should at least get you 95% of the way there with that stick resides: http://www.kernellabs.com/hg/~mkrufky/lgdt3304-3/ The last two patches are the relevant ones. They add lgdt3304 demod support to the lgdt3305 driver (because the current lgdt3304 driver is, um, lacking) and then add the bits to wire up the stick. -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
KWorld UB435-Q support?
I stupidly bought the KWorld UB435-Q usb ATSC tuner thinking it was supported under linux, and it turns out it isn't. I'm wondering what it would take to get it supported. It seems like all of the main chips it uses are supported, but the glue code is missing. I have some C (10 years) programming experience, and have wanted to contribute to the linux kernel for quite a while, now I have a good excuse ;) Would anyone be willing to point me in the right direction? (sorry if this is a dupe) -- Thomas Fjellstrom tfjellst...@shaw.ca -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
KWorld UB435-Q support?
I stupidly bought the KWorld UB435-Q usb ATSC tuner thinking it was supported under linux, and it turns out it isn't. I'm wondering what it would take to get it supported. It seems like all of the main chips it uses are supported, but the glue code is missing. I have some C (10 years) programming experience, and have wanted to contribute to the linux kernel for quite a while, now I have a good excuse ;) Would anyone be willing to point me in the right direction? -- Thomas Fjellstrom tfjellst...@shaw.ca -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
