em28xx: msi Digivox ATSC board id [0db0:8810]

Am 04.12.2012 03:58, schrieb Devin Heitmueller:
> On Mon, Dec 3, 2012 at 9:42 PM, Matthew Gyurgyik <matthew@pyther.net> wrote:
>>> I would try running "lsusb -v" and send the output.  Make sure that
>>> it's not expecting to use bulk mode for DVB (which would require
>>> driver changes to support).
>>>
>>> Devin
>>>
>> Here is the output of lsusb -v
>> http://pyther.net/a/digivox_atsc/patch2/lsusb.txt
> Hmmm, it's isoc, so that should be ok.  Maybe the 3305 TS
> configuration is mismatched (serial vs. parallel).  I don't recall off
> the top of my head, but I think em2875 is pretty much always in serial
> mode, so check the lgdt3305 config block passed in the dvb_attach()
> call and see if it's the same.

I double-checked the log and it is indeed set to LGDT3305_MPEG_SERIAL,
but LGDT3305_TPCLK_FALLING_EDGE is used instead of
LGDT3305_TPCLK_RISING_EDGE.
OTOH, the KWorld A340 bord sets this to LGDT3305_MPEG_PARALLEL...

Matthew, could you please test V3 of the patch ? It is written against
the media_tree staging/for_v3.8 (see http://git.linuxtv.org/media_tree.git).
You could also already test the remote control key map (e.g. with evtest)

Regards,
Frank

>
> Devin
>
  

On 12/04/2012 04:06 PM, Frank Schäfer wrote:
> I double-checked the log and it is indeed set to LGDT3305_MPEG_SERIAL,
> but LGDT3305_TPCLK_FALLING_EDGE is used instead of
> LGDT3305_TPCLK_RISING_EDGE.
> OTOH, the KWorld A340 bord sets this to LGDT3305_MPEG_PARALLEL...
>
> Matthew, could you please test V3 of the patch ? It is written against
> the media_tree staging/for_v3.8 (see http://git.linuxtv.org/media_tree.git).
> You could also already test the remote control key map (e.g. with evtest)
>
> Regards,
> Frank
Version 3 has the same behavior has v2. It seems I can tune a channel, 
but trying to watch it fails. There is no data being set to 
/dev/dvb/adapter0/dvr0

Tune channel
> [root@tux ~]# azap -r -c /home/pyther/channels.conf "ION LIF"

> [root@tux ~]# dvbdate
> dvbdate: Unable to get time from multiplex.

I got further on a channel scan but then encountered some errors (no 
channels detected):

http://pyther.net/a/digivox_atsc/patch3/scan.txt
http://pyther.net/a/digivox_atsc/patch3/dmesg_after_scan.txt

dmesg: http://pyther.net/a/digivox_atsc/patch3/dmesg.txt
azap: http://pyther.net/a/digivox_atsc/patch3/azap.txt
dvbtraffic: http://pyther.net/a/digivox_atsc/patch3/dvbtraffic.txt

Matthew
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On 12/05/2012 05:41 AM, Matthew Gyurgyik wrote:
> On 12/04/2012 04:06 PM, Frank Schäfer wrote:
>> I double-checked the log and it is indeed set to LGDT3305_MPEG_SERIAL,
>> but LGDT3305_TPCLK_FALLING_EDGE is used instead of
>> LGDT3305_TPCLK_RISING_EDGE.
>> OTOH, the KWorld A340 bord sets this to LGDT3305_MPEG_PARALLEL...
>>
>> Matthew, could you please test V3 of the patch ? It is written against
>> the media_tree staging/for_v3.8 (see
>> http://git.linuxtv.org/media_tree.git).
>> You could also already test the remote control key map (e.g. with evtest)
>>
>> Regards,
>> Frank
> Version 3 has the same behavior has v2. It seems I can tune a channel,
> but trying to watch it fails. There is no data being set to
> /dev/dvb/adapter0/dvr0
>
> Tune channel
>> [root@tux ~]# azap -r -c /home/pyther/channels.conf "ION LIF"
>
>> [root@tux ~]# dvbdate
>> dvbdate: Unable to get time from multiplex.
>
> I got further on a channel scan but then encountered some errors (no
> channels detected):
>
> http://pyther.net/a/digivox_atsc/patch3/scan.txt
> http://pyther.net/a/digivox_atsc/patch3/dmesg_after_scan.txt
>
> dmesg: http://pyther.net/a/digivox_atsc/patch3/dmesg.txt
> azap: http://pyther.net/a/digivox_atsc/patch3/azap.txt
> dvbtraffic: http://pyther.net/a/digivox_atsc/patch3/dvbtraffic.txt
>
> Matthew

There is something really wrong.

I am not at US expert but why the hell 
us-Cable-Standard-center-frequencies-QAM256 scans up to 999MHz whilst 
demodulator max is set 858? Either one is wrong.

Also, demod seems to be HAS_LOCK about all the time. As that basic LOCK 
flag is simply false you cannot even thing if there is correct 
configuration on TS interface. If you start zapping that known channel 
and then unplug & plug antenna cable did you see still all the time 
HAS_LOCK? (it should disappear when antenna cable is unplugged).

regards
Antti
  

On 12/05/2012 07:35 AM, Antti Palosaari wrote:
>
> There is something really wrong.
>
> I am not at US expert but why the hell 
> us-Cable-Standard-center-frequencies-QAM256 scans up to 999MHz whilst 
> demodulator max is set 858? Either one is wrong.
>
> Also, demod seems to be HAS_LOCK about all the time. As that basic 
> LOCK flag is simply false you cannot even thing if there is correct 
> configuration on TS interface. If you start zapping that known channel 
> and then unplug & plug antenna cable did you see still all the time 
> HAS_LOCK? (it should disappear when antenna cable is unplugged).
>
> regards
> Antti
>
When I disconnected the coax cable, the lock went away. When I 
reconnected FE_HAS_LOCK came back.

http://pyther.net/a/digivox_atsc/patch3/azap_disconnect_coax.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On 12/05/2012 11:35 PM, Matthew Gyurgyik wrote:
> On 12/05/2012 07:35 AM, Antti Palosaari wrote:
>>
>> There is something really wrong.
>>
>> I am not at US expert but why the hell
>> us-Cable-Standard-center-frequencies-QAM256 scans up to 999MHz whilst
>> demodulator max is set 858? Either one is wrong.
>>
>> Also, demod seems to be HAS_LOCK about all the time. As that basic
>> LOCK flag is simply false you cannot even thing if there is correct
>> configuration on TS interface. If you start zapping that known channel
>> and then unplug & plug antenna cable did you see still all the time
>> HAS_LOCK? (it should disappear when antenna cable is unplugged).
>>
>> regards
>> Antti
>>
> When I disconnected the coax cable, the lock went away. When I
> reconnected FE_HAS_LOCK came back.
>
> http://pyther.net/a/digivox_atsc/patch3/azap_disconnect_coax.txt

OK, fine, I was then wrong. I have to say you have a lot of channels 
over there what I can see from scan result [1]. Those channels which 
says "tuning failed" are channels where is no transmission and those 
"filter timeout pid" means there is ta ransmission and demod locks. Here 
in Finland we have only ~4 MUX DVB-T and maybe other 4 for DVB-T2.

It is then actually working quite well from the developer point of view 
(as demod loses lock when antenna is unplugged). It means tuner and 
demodular are working but interface (transport stream interface, TS IF) 
between demod and USB-bridge is still broken.

I tried to look again your sniff if I can see what it does just before 
streaming starts, but unfortunately there is no any mention about those 
streaming packets (isoc packets where picture stream is going). Did you 
remove those yourself?


[1] http://pyther.net/a/digivox_atsc/patch3/scan.txt

regards
Antti
  

On 12/05/2012 05:01 PM, Antti Palosaari wrote:
> OK, fine, I was then wrong. I have to say you have a lot of channels 
> over there what I can see from scan result [1]. Those channels which 
> says "tuning failed" are channels where is no transmission and those 
> "filter timeout pid" means there is ta ransmission and demod locks. 
> Here in Finland we have only ~4 MUX DVB-T and maybe other 4 for DVB-T2.
>
> It is then actually working quite well from the developer point of 
> view (as demod loses lock when antenna is unplugged). It means tuner 
> and demodular are working but interface (transport stream interface, 
> TS IF) between demod and USB-bridge is still broken.
>
> I tried to look again your sniff if I can see what it does just before 
> streaming starts, but unfortunately there is no any mention about 
> those streaming packets (isoc packets where picture stream is going). 
> Did you remove those yourself?
>
No I did not remove the the streaming packets. However I did use the 
parse-usbsnoop.php script to generate parsed-usbsnoop.txt. The original 
snooping log is 354M (I'm assuming it has stream data in it).

I have put the entire log on the server ~85MB bzipped: 
http://pyther.net/a/digivox_atsc/UsbSnoop.log.bz2

Let me know if you think I should do another snoop.

Thanks,
Matthew


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On 12/06/2012 12:33 AM, Matthew Gyurgyik wrote:
> On 12/05/2012 05:01 PM, Antti Palosaari wrote:
>> OK, fine, I was then wrong. I have to say you have a lot of channels
>> over there what I can see from scan result [1]. Those channels which
>> says "tuning failed" are channels where is no transmission and those
>> "filter timeout pid" means there is ta ransmission and demod locks.
>> Here in Finland we have only ~4 MUX DVB-T and maybe other 4 for DVB-T2.
>>
>> It is then actually working quite well from the developer point of
>> view (as demod loses lock when antenna is unplugged). It means tuner
>> and demodular are working but interface (transport stream interface,
>> TS IF) between demod and USB-bridge is still broken.
>>
>> I tried to look again your sniff if I can see what it does just before
>> streaming starts, but unfortunately there is no any mention about
>> those streaming packets (isoc packets where picture stream is going).
>> Did you remove those yourself?
>>
> No I did not remove the the streaming packets. However I did use the
> parse-usbsnoop.php script to generate parsed-usbsnoop.txt. The original
> snooping log is 354M (I'm assuming it has stream data in it).
>
> I have put the entire log on the server ~85MB bzipped:
> http://pyther.net/a/digivox_atsc/UsbSnoop.log.bz2
>
> Let me know if you think I should do another snoop.

It was good snoop. I didn't saw nothing very interesting. But, I think I 
found the reason. Just add that one line writing 0x42 to register 0x0d. 
IIRC I saw earlier it caused that kind of bug...

+static struct em28xx_reg_seq msi_digivox_atsc[] = {
+	{EM2874_R80_GPIO, 0xff, 0xff,  50}, /* GPIO_0=1 */
+	{0x0d,            0xff, 0xff,   0},
+	{EM2874_R80_GPIO, 0xfe, 0xff,   0}, /* GPIO_0=0 */
	{0x0d,            0x42, 0xff,   0},
+	{EM2874_R80_GPIO, 0xbe, 0xff, 135}, /* GPIO_6=0 */
+	{EM2874_R80_GPIO, 0xfe, 0xff, 135}, /* GPIO_6=1 */
+	{EM2874_R80_GPIO, 0x7e, 0xff,  20}, /* GPIO_7=0 */
+	{             -1,   -1,   -1,  -1},
+};

regards
Antti
  

On 12/05/2012 07:55 PM, Antti Palosaari wrote:
>
> It was good snoop. I didn't saw nothing very interesting. But, I think 
> I found the reason. Just add that one line writing 0x42 to register 
> 0x0d. IIRC I saw earlier it caused that kind of bug...
>
> +static struct em28xx_reg_seq msi_digivox_atsc[] = {
> +    {EM2874_R80_GPIO, 0xff, 0xff,  50}, /* GPIO_0=1 */
> +    {0x0d,            0xff, 0xff,   0},
> +    {EM2874_R80_GPIO, 0xfe, 0xff,   0}, /* GPIO_0=0 */
>     {0x0d,            0x42, 0xff,   0},
> +    {EM2874_R80_GPIO, 0xbe, 0xff, 135}, /* GPIO_6=0 */
> +    {EM2874_R80_GPIO, 0xfe, 0xff, 135}, /* GPIO_6=1 */
> +    {EM2874_R80_GPIO, 0x7e, 0xff,  20}, /* GPIO_7=0 */
> +    {             -1,   -1,   -1,  -1},
> +};
>
> regards
> Antti
>
>
I added that line, recompiled, tried the new module. Unfortunately there 
was no improvement. I didn't see any differences in any of the output 
(dmesg, azap). Let me know if there is any info you want me to get.

Matthew
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On 12/04/2012 04:06 PM, Frank Schäfer wrote:
>
> I double-checked the log and it is indeed set to LGDT3305_MPEG_SERIAL,
> but LGDT3305_TPCLK_FALLING_EDGE is used instead of
> LGDT3305_TPCLK_RISING_EDGE.
> OTOH, the KWorld A340 bord sets this to LGDT3305_MPEG_PARALLEL...
>
> Matthew, could you please test V3 of the patch ? It is written against
> the media_tree staging/for_v3.8 (see http://git.linuxtv.org/media_tree.git).
> You could also already test the remote control key map (e.g. with evtest)
I tested the remote using evtest. However, no events are generated in 
evtest. I verified the remote works in windows.
> Regards,
> Frank
>

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

Am 06.12.2012 03:16, schrieb Matthew Gyurgyik:
> On 12/05/2012 07:55 PM, Antti Palosaari wrote:
>>
>> It was good snoop. I didn't saw nothing very interesting. But, I
>> think I found the reason. Just add that one line writing 0x42 to
>> register 0x0d. IIRC I saw earlier it caused that kind of bug...
>>
>> +static struct em28xx_reg_seq msi_digivox_atsc[] = {
>> +    {EM2874_R80_GPIO, 0xff, 0xff,  50}, /* GPIO_0=1 */
>> +    {0x0d,            0xff, 0xff,   0},
>> +    {EM2874_R80_GPIO, 0xfe, 0xff,   0}, /* GPIO_0=0 */
>>     {0x0d,            0x42, 0xff,   0},
>> +    {EM2874_R80_GPIO, 0xbe, 0xff, 135}, /* GPIO_6=0 */
>> +    {EM2874_R80_GPIO, 0xfe, 0xff, 135}, /* GPIO_6=1 */
>> +    {EM2874_R80_GPIO, 0x7e, 0xff,  20}, /* GPIO_7=0 */
>> +    {             -1,   -1,   -1,  -1},
>> +};
>>
>> regards
>> Antti
>>
>>
> I added that line, recompiled, tried the new module. Unfortunately
> there was no improvement. I didn't see any differences in any of the
> output (dmesg, azap). Let me know if there is any info you want me to
> get.
>
> Matthew

Did you switch back to

    .mpeg_mode      = LGDT3305_MPEG_SERIAL,
    .tpclk_edge         = LGDT3305_TPCLK_FALLING_EDGE,

in struct lgdt3305_config em2874_lgdt3305_dev (em28xx-dvb.c) before
testing this ?

You could also play with the other gpio settings.

And the last idea (at the moment):

+    /* 0db0:8810 MSI DIGIVOX ATSC (HU345-Q)
+     * Empia EM2874B + TDA18271HDC2 + LGDT3305 */
+    [EM2874_BOARD_MSI_DIGIVOX_ATSC] = {
+        .name         = "MSI DIGIVOX ATSC",
+        .dvb_gpio     = msi_digivox_atsc,
+        .has_dvb      = 1,
+        .tuner_type   = TUNER_ABSENT,
+        .ir_codes     = RC_MAP_MSI_DIGIVOX_III,        /* just a guess
from looking at the picture */
+        .xclk         = EM28XX_XCLK_FREQUENCY_12MHZ,    /* TODO */
+        .i2c_speed    = EM2874_I2C_SECONDARY_BUS_SELECT |
+                EM28XX_I2C_CLK_WAIT_ENABLE |
+                EM28XX_I2C_FREQ_100_KHZ,
+    },

=> change .xclk to 0x0f.
We know that 12MHz is the right xclk setting, which means 0x07. But OTOH
the Windows drivers seems to use 0x0f instead and we don't what 0x0f
means...

Hope this helps,
Frank


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

Am 06.12.2012 03:32, schrieb Matthew Gyurgyik:
> On 12/04/2012 04:06 PM, Frank Schäfer wrote:
>>
>> I double-checked the log and it is indeed set to LGDT3305_MPEG_SERIAL,
>> but LGDT3305_TPCLK_FALLING_EDGE is used instead of
>> LGDT3305_TPCLK_RISING_EDGE.
>> OTOH, the KWorld A340 bord sets this to LGDT3305_MPEG_PARALLEL...
>>
>> Matthew, could you please test V3 of the patch ? It is written against
>> the media_tree staging/for_v3.8 (see
>> http://git.linuxtv.org/media_tree.git).
>> You could also already test the remote control key map (e.g. with
>> evtest)
> I tested the remote using evtest. However, no events are generated in
> evtest. I verified the remote works in windows.

Ok :(
I'm not sure if it makes sense to test other maps at the moment.

>> Regards,
>> Frank
>>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On Thu, Dec 6, 2012 at 4:49 PM, Frank Schäfer
<fschaefer.oss@googlemail.com> wrote:
>
> Am 06.12.2012 03:16, schrieb Matthew Gyurgyik:
> > On 12/05/2012 07:55 PM, Antti Palosaari wrote:
> >>
> >> It was good snoop. I didn't saw nothing very interesting. But, I
> >> think I found the reason. Just add that one line writing 0x42 to
> >> register 0x0d. IIRC I saw earlier it caused that kind of bug...
> >>
> >> +static struct em28xx_reg_seq msi_digivox_atsc[] = {
> >> +    {EM2874_R80_GPIO, 0xff, 0xff,  50}, /* GPIO_0=1 */
> >> +    {0x0d,            0xff, 0xff,   0},
> >> +    {EM2874_R80_GPIO, 0xfe, 0xff,   0}, /* GPIO_0=0 */
> >>     {0x0d,            0x42, 0xff,   0},
> >> +    {EM2874_R80_GPIO, 0xbe, 0xff, 135}, /* GPIO_6=0 */
> >> +    {EM2874_R80_GPIO, 0xfe, 0xff, 135}, /* GPIO_6=1 */
> >> +    {EM2874_R80_GPIO, 0x7e, 0xff,  20}, /* GPIO_7=0 */
> >> +    {             -1,   -1,   -1,  -1},
> >> +};
> >>
> >> regards
> >> Antti
> >>
> >>
> > I added that line, recompiled, tried the new module. Unfortunately
> > there was no improvement. I didn't see any differences in any of the
> > output (dmesg, azap). Let me know if there is any info you want me to
> > get.
> >
> > Matthew
>
> Did you switch back to
>
>     .mpeg_mode      = LGDT3305_MPEG_SERIAL,
>     .tpclk_edge         = LGDT3305_TPCLK_FALLING_EDGE,
>
> in struct lgdt3305_config em2874_lgdt3305_dev (em28xx-dvb.c) before
> testing this ?
>
> You could also play with the other gpio settings.
>
> And the last idea (at the moment):
>
> +    /* 0db0:8810 MSI DIGIVOX ATSC (HU345-Q)
> +     * Empia EM2874B + TDA18271HDC2 + LGDT3305 */
> +    [EM2874_BOARD_MSI_DIGIVOX_ATSC] = {
> +        .name         = "MSI DIGIVOX ATSC",
> +        .dvb_gpio     = msi_digivox_atsc,
> +        .has_dvb      = 1,
> +        .tuner_type   = TUNER_ABSENT,
> +        .ir_codes     = RC_MAP_MSI_DIGIVOX_III,        /* just a guess
> from looking at the picture */
> +        .xclk         = EM28XX_XCLK_FREQUENCY_12MHZ,    /* TODO */
> +        .i2c_speed    = EM2874_I2C_SECONDARY_BUS_SELECT |
> +                EM28XX_I2C_CLK_WAIT_ENABLE |
> +                EM28XX_I2C_FREQ_100_KHZ,
> +    },
>
> => change .xclk to 0x0f.
> We know that 12MHz is the right xclk setting, which means 0x07. But OTOH
> the Windows drivers seems to use 0x0f instead and we don't what 0x0f
> means...
>
> Hope this helps,
> Frank

I'm pretty sure the XCLK register isn't used at all on the em2874
(it's probably being set in the Windows driver because of some shared
code with the older devices).

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

Am 06.12.2012 22:57, schrieb Devin Heitmueller:
> On Thu, Dec 6, 2012 at 4:49 PM, Frank Schäfer
> <fschaefer.oss@googlemail.com> wrote:
>> Am 06.12.2012 03:16, schrieb Matthew Gyurgyik:
>>> On 12/05/2012 07:55 PM, Antti Palosaari wrote:
>>>> It was good snoop. I didn't saw nothing very interesting. But, I
>>>> think I found the reason. Just add that one line writing 0x42 to
>>>> register 0x0d. IIRC I saw earlier it caused that kind of bug...
>>>>
>>>> +static struct em28xx_reg_seq msi_digivox_atsc[] = {
>>>> +    {EM2874_R80_GPIO, 0xff, 0xff,  50}, /* GPIO_0=1 */
>>>> +    {0x0d,            0xff, 0xff,   0},
>>>> +    {EM2874_R80_GPIO, 0xfe, 0xff,   0}, /* GPIO_0=0 */
>>>>     {0x0d,            0x42, 0xff,   0},
>>>> +    {EM2874_R80_GPIO, 0xbe, 0xff, 135}, /* GPIO_6=0 */
>>>> +    {EM2874_R80_GPIO, 0xfe, 0xff, 135}, /* GPIO_6=1 */
>>>> +    {EM2874_R80_GPIO, 0x7e, 0xff,  20}, /* GPIO_7=0 */
>>>> +    {             -1,   -1,   -1,  -1},
>>>> +};
>>>>
>>>> regards
>>>> Antti
>>>>
>>>>
>>> I added that line, recompiled, tried the new module. Unfortunately
>>> there was no improvement. I didn't see any differences in any of the
>>> output (dmesg, azap). Let me know if there is any info you want me to
>>> get.
>>>
>>> Matthew
>> Did you switch back to
>>
>>     .mpeg_mode      = LGDT3305_MPEG_SERIAL,
>>     .tpclk_edge         = LGDT3305_TPCLK_FALLING_EDGE,
>>
>> in struct lgdt3305_config em2874_lgdt3305_dev (em28xx-dvb.c) before
>> testing this ?
>>
>> You could also play with the other gpio settings.
>>
>> And the last idea (at the moment):
>>
>> +    /* 0db0:8810 MSI DIGIVOX ATSC (HU345-Q)
>> +     * Empia EM2874B + TDA18271HDC2 + LGDT3305 */
>> +    [EM2874_BOARD_MSI_DIGIVOX_ATSC] = {
>> +        .name         = "MSI DIGIVOX ATSC",
>> +        .dvb_gpio     = msi_digivox_atsc,
>> +        .has_dvb      = 1,
>> +        .tuner_type   = TUNER_ABSENT,
>> +        .ir_codes     = RC_MAP_MSI_DIGIVOX_III,        /* just a guess
>> from looking at the picture */
>> +        .xclk         = EM28XX_XCLK_FREQUENCY_12MHZ,    /* TODO */
>> +        .i2c_speed    = EM2874_I2C_SECONDARY_BUS_SELECT |
>> +                EM28XX_I2C_CLK_WAIT_ENABLE |
>> +                EM28XX_I2C_FREQ_100_KHZ,
>> +    },
>>
>> => change .xclk to 0x0f.
>> We know that 12MHz is the right xclk setting, which means 0x07. But OTOH
>> the Windows drivers seems to use 0x0f instead and we don't what 0x0f
>> means...
>>
>> Hope this helps,
>> Frank
> I'm pretty sure the XCLK register isn't used at all on the em2874
> (it's probably being set in the Windows driver because of some shared
> code with the older devices).

That's possible, because Matthews log doesn't show any access to this
register.
If it is not used, the question is if writing 0x07 to this register can
cause any trouble...

Frank

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

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On Thu, Dec 6, 2012 at 5:01 PM, Frank Schäfer
<fschaefer.oss@googlemail.com> wrote:
> That's possible, because Matthews log doesn't show any access to this
> register.
> If it is not used, the question is if writing 0x07 to this register can
> cause any trouble...

Historically speaking, on that family of devices registers that are no
longer used get treated as scratch registers (meaning writing to them
has no adverse effect).

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

Am 06.12.2012 23:03, schrieb Devin Heitmueller:
> On Thu, Dec 6, 2012 at 5:01 PM, Frank Schäfer
> <fschaefer.oss@googlemail.com> wrote:
>> That's possible, because Matthews log doesn't show any access to this
>> register.
>> If it is not used, the question is if writing 0x07 to this register can
>> cause any trouble...
> Historically speaking, on that family of devices registers that are no
> longer used get treated as scratch registers (meaning writing to them
> has no adverse effect).

Wow, seems like chip manufactures CAN make sane hardware design
decisions after all !  :D

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

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On 12/06/2012 04:49 PM, Frank Schäfer wrote:
>
> Did you switch back to
>
>      .mpeg_mode      = LGDT3305_MPEG_SERIAL,
>      .tpclk_edge         = LGDT3305_TPCLK_FALLING_EDGE,
>
> in struct lgdt3305_config em2874_lgdt3305_dev (em28xx-dvb.c) before
> testing this ?
I did not, but switching back doesn't help.
> You could also play with the other gpio settings.
Can you give me some examples of what I might want to try. I don't 
really understand these gpio settings.
> And the last idea (at the moment):
>
> +    /* 0db0:8810 MSI DIGIVOX ATSC (HU345-Q)
> +     * Empia EM2874B + TDA18271HDC2 + LGDT3305 */
> +    [EM2874_BOARD_MSI_DIGIVOX_ATSC] = {
> +        .name         = "MSI DIGIVOX ATSC",
> +        .dvb_gpio     = msi_digivox_atsc,
> +        .has_dvb      = 1,
> +        .tuner_type   = TUNER_ABSENT,
> +        .ir_codes     = RC_MAP_MSI_DIGIVOX_III,        /* just a guess
> from looking at the picture */
> +        .xclk         = EM28XX_XCLK_FREQUENCY_12MHZ,    /* TODO */
> +        .i2c_speed    = EM2874_I2C_SECONDARY_BUS_SELECT |
> +                EM28XX_I2C_CLK_WAIT_ENABLE |
> +                EM28XX_I2C_FREQ_100_KHZ,
> +    },
>
> => change .xclk to 0x0f.
> We know that 12MHz is the right xclk setting, which means 0x07. But OTOH
> the Windows drivers seems to use 0x0f instead and we don't what 0x0f
> means...
Unfortunately, this didn't make a difference either.

Here is my current sent of changes against upstream: 
http://pyther.net/a/digivox_atsc/diff-Dec-06-v1.patch
> Hope this helps,
> Frank
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On 12/06/2012 04:49 PM, Frank Schäfer wrote:
>
>
> Did you switch back to
>
>      .mpeg_mode      = LGDT3305_MPEG_SERIAL,
>      .tpclk_edge         = LGDT3305_TPCLK_FALLING_EDGE,
>
> in struct lgdt3305_config em2874_lgdt3305_dev (em28xx-dvb.c) before
> testing this ?
>
> You could also play with the other gpio settings.
>
> And the last idea (at the moment):
>
> +    /* 0db0:8810 MSI DIGIVOX ATSC (HU345-Q)
> +     * Empia EM2874B + TDA18271HDC2 + LGDT3305 */
> +    [EM2874_BOARD_MSI_DIGIVOX_ATSC] = {
> +        .name         = "MSI DIGIVOX ATSC",
> +        .dvb_gpio     = msi_digivox_atsc,
> +        .has_dvb      = 1,
> +        .tuner_type   = TUNER_ABSENT,
> +        .ir_codes     = RC_MAP_MSI_DIGIVOX_III,        /* just a guess
> from looking at the picture */
> +        .xclk         = EM28XX_XCLK_FREQUENCY_12MHZ,    /* TODO */
> +        .i2c_speed    = EM2874_I2C_SECONDARY_BUS_SELECT |
> +                EM28XX_I2C_CLK_WAIT_ENABLE |
> +                EM28XX_I2C_FREQ_100_KHZ,
> +    },
>
> => change .xclk to 0x0f.
> We know that 12MHz is the right xclk setting, which means 0x07. But OTOH
> the Windows drivers seems to use 0x0f instead and we don't what 0x0f
> means...
>
> Hope this helps,
> Frank
>

I lied, it works! I must have forgotten to do run make modules_install 
or something! This patch accurately states my current code changes: 
http://pyther.net/a/digivox_atsc/diff-Dec-06-v1.patch

I will do more testing and try more channels. Playing the stream with 
mplayer, the audio is clearly out-of-sync. But if I can the stream to a 
file, it doesn't seem out-of-sync but I will do more testing and report 
back.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On 12/06/2012 05:58 PM, Matthew Gyurgyik wrote:
> On 12/06/2012 04:49 PM, Frank Schäfer wrote:
>>
>>
>> Did you switch back to
>>
>>      .mpeg_mode      = LGDT3305_MPEG_SERIAL,
>>      .tpclk_edge         = LGDT3305_TPCLK_FALLING_EDGE,
>>
>> in struct lgdt3305_config em2874_lgdt3305_dev (em28xx-dvb.c) before
>> testing this ?
>>
>> You could also play with the other gpio settings.
>>
>> And the last idea (at the moment):
>>
>> +    /* 0db0:8810 MSI DIGIVOX ATSC (HU345-Q)
>> +     * Empia EM2874B + TDA18271HDC2 + LGDT3305 */
>> +    [EM2874_BOARD_MSI_DIGIVOX_ATSC] = {
>> +        .name         = "MSI DIGIVOX ATSC",
>> +        .dvb_gpio     = msi_digivox_atsc,
>> +        .has_dvb      = 1,
>> +        .tuner_type   = TUNER_ABSENT,
>> +        .ir_codes     = RC_MAP_MSI_DIGIVOX_III,        /* just a guess
>> from looking at the picture */
>> +        .xclk         = EM28XX_XCLK_FREQUENCY_12MHZ,    /* TODO */
>> +        .i2c_speed    = EM2874_I2C_SECONDARY_BUS_SELECT |
>> +                EM28XX_I2C_CLK_WAIT_ENABLE |
>> +                EM28XX_I2C_FREQ_100_KHZ,
>> +    },
>>
>> => change .xclk to 0x0f.
>> We know that 12MHz is the right xclk setting, which means 0x07. But OTOH
>> the Windows drivers seems to use 0x0f instead and we don't what 0x0f
>> means...
>>
>> Hope this helps,
>> Frank
>>
>
> I lied, it works! I must have forgotten to do run make modules_install 
> or something! This patch accurately states my current code changes: 
> http://pyther.net/a/digivox_atsc/diff-Dec-06-v1.patch
>
> I will do more testing and try more channels. Playing the stream with 
> mplayer, the audio is clearly out-of-sync. But if I can the stream to 
> a file, it doesn't seem out-of-sync but I will do more testing and 
> report back.

I was able to do a bit of testing tonight and this is what I found.

A channel scan was unsuccessful:
http://pyther.net/a/digivox_atsc/dec06/scan.txt (no errors in dmesg)

Changing channels by pressing "h" in "mplayer dvb://" caused mplayer to 
crash and this messages to be logged in dmesg
http://pyther.net/a/digivox_atsc/dec06/dmesg_mplayer_switch_channels.txt

Audio is out-of-sync in mplayer. Using cache helps, but over time the 
audio still goes out of sync.
http://pyther.net/a/digivox_atsc/dec06/mplayer_audio_out_of_sync.txt

Using azap to tune and using cat /dev/dvb/adapter0/dvr0 > test.mpg to 
generate a test.mpg

mplayer plays the file fine without audio-sync issues, but VLC and Xine 
refuse to play it. (is this normal?)
> tux:~ $ file test.mpg
> test.mpg: data

I have upload a ~30 second capture from the card: 
http://pyther.net/a/digivox_atsc/dec06/test.mpg (not sure if its helpful 
or not)

I really appreciate the help so far. Things are looking promising.

Thanks,
Matthew



--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On Thu, Dec 6, 2012 at 8:40 PM, Matthew Gyurgyik <matthew@pyther.net> wrote:
> I was able to do a bit of testing tonight and this is what I found.
>
> A channel scan was unsuccessful:
> http://pyther.net/a/digivox_atsc/dec06/scan.txt (no errors in dmesg)
>
> Changing channels by pressing "h" in "mplayer dvb://" caused mplayer to
> crash and this messages to be logged in dmesg
> http://pyther.net/a/digivox_atsc/dec06/dmesg_mplayer_switch_channels.txt

This looks like a combination of a misconfiguration of GPIOs and
mplayer not properly handling an exception condition.  You should
definitely bring this up with the mplayer developers since their app
shouldn't crash under this circumstance.

> Audio is out-of-sync in mplayer. Using cache helps, but over time the audio
> still goes out of sync.
> http://pyther.net/a/digivox_atsc/dec06/mplayer_audio_out_of_sync.txt

This has nothing to do with the tuner.  The tuner delivers the MPEG2
stream already compressed and synchronized.  If you're playback is
out-of-sync, it's probably your ALSA drivers, PulseAudio, or mplayer
that is the culprit.

> Using azap to tune and using cat /dev/dvb/adapter0/dvr0 > test.mpg to
> generate a test.mpg
>
> mplayer plays the file fine without audio-sync issues, but VLC and Xine
> refuse to play it. (is this normal?)

What errors are VLC or Xine showing?  Unless the stream is really
corrupt VLC and Xine should play it fine.  And if the stream were
corrupt it wouldn't play with mplayer either?  This sounds like bugs
in VLC and Xine.

There's definitely something going on in the tuner which is causing
the channel scan to fail (and probably the tuning failure in mplayer).
 But all the stuff with actual playback causing segfaults, A/V sync
issues, and failures to play back in certain applications are all
userland problems that you would need to raise with the developers for
those respective projects.

Cheers,

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On 12/06/2012 10:21 PM, Devin Heitmueller wrote:
> On Thu, Dec 6, 2012 at 8:40 PM, Matthew Gyurgyik <matthew@pyther.net> wrote:
>> I was able to do a bit of testing tonight and this is what I found.
>>
>> A channel scan was unsuccessful:
>> http://pyther.net/a/digivox_atsc/dec06/scan.txt (no errors in dmesg)
>>
>> Changing channels by pressing "h" in "mplayer dvb://" caused mplayer to
>> crash and this messages to be logged in dmesg
>> http://pyther.net/a/digivox_atsc/dec06/dmesg_mplayer_switch_channels.txt
> This looks like a combination of a misconfiguration of GPIOs and
> mplayer not properly handling an exception condition.  You should
> definitely bring this up with the mplayer developers since their app
> shouldn't crash under this circumstance.

Sorry I misspoke. mplayer isn't crashing, however it can't read data 
from the tuner and thus closes.

for completeness, mplayer output: 
http://pyther.net/a/digivox_atsc/dec06/mplayer_channel_switch.txt

>
>> Audio is out-of-sync in mplayer. Using cache helps, but over time the audio
>> still goes out of sync.
>> http://pyther.net/a/digivox_atsc/dec06/mplayer_audio_out_of_sync.txt
> This has nothing to do with the tuner.  The tuner delivers the MPEG2
> stream already compressed and synchronized.  If you're playback is
> out-of-sync, it's probably your ALSA drivers, PulseAudio, or mplayer
> that is the culprit.
Ok that make sense, I'd bank it being on mplayer and how it reads the 
stream.

>
>> Using azap to tune and using cat /dev/dvb/adapter0/dvr0 > test.mpg to
>> generate a test.mpg
>>
>> mplayer plays the file fine without audio-sync issues, but VLC and Xine
>> refuse to play it. (is this normal?)
> What errors are VLC or Xine showing?  Unless the stream is really
> corrupt VLC and Xine should play it fine.  And if the stream were
> corrupt it wouldn't play with mplayer either?  This sounds like bugs
> in VLC and Xine.
I would agree with. I got the chance to test another mpeg from my other 
tuner (that I know works well) and had the same issue.

The vlc errors consist of similar messages such as those below:
> [0x7f0200c015a8] ts demux warning: lost synchro
> [0x7f0200c015a8] ts demux debug: skipping 187 bytes of garbage
I had thought I was able to play previous captures in VLC. I was unable 
to test my other card (that I know works well) last night. Now I see 
this is not the case, and it separate issue.

> There's definitely something going on in the tuner which is causing
> the channel scan to fail (and probably the tuning failure in mplayer).
>   But all the stuff with actual playback causing segfaults, A/V sync
> issues, and failures to play back in certain applications are all
> userland problems that you would need to raise with the developers for
> those respective projects.
>
> Cheers,
>
> Devin
>
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

Am 06.12.2012 23:58, schrieb Matthew Gyurgyik:
> On 12/06/2012 04:49 PM, Frank Schäfer wrote:
>>
>>
>> Did you switch back to
>>
>>      .mpeg_mode      = LGDT3305_MPEG_SERIAL,
>>      .tpclk_edge         = LGDT3305_TPCLK_FALLING_EDGE,
>>
>> in struct lgdt3305_config em2874_lgdt3305_dev (em28xx-dvb.c) before
>> testing this ?
>>
>> You could also play with the other gpio settings.
>>
>> And the last idea (at the moment):
>>
>> +    /* 0db0:8810 MSI DIGIVOX ATSC (HU345-Q)
>> +     * Empia EM2874B + TDA18271HDC2 + LGDT3305 */
>> +    [EM2874_BOARD_MSI_DIGIVOX_ATSC] = {
>> +        .name         = "MSI DIGIVOX ATSC",
>> +        .dvb_gpio     = msi_digivox_atsc,
>> +        .has_dvb      = 1,
>> +        .tuner_type   = TUNER_ABSENT,
>> +        .ir_codes     = RC_MAP_MSI_DIGIVOX_III,        /* just a guess
>> from looking at the picture */
>> +        .xclk         = EM28XX_XCLK_FREQUENCY_12MHZ,    /* TODO */
>> +        .i2c_speed    = EM2874_I2C_SECONDARY_BUS_SELECT |
>> +                EM28XX_I2C_CLK_WAIT_ENABLE |
>> +                EM28XX_I2C_FREQ_100_KHZ,
>> +    },
>>
>> => change .xclk to 0x0f.
>> We know that 12MHz is the right xclk setting, which means 0x07. But OTOH
>> the Windows drivers seems to use 0x0f instead and we don't what 0x0f
>> means...
>>
>> Hope this helps,
>> Frank
>>
>
> I lied, it works! I must have forgotten to do run make modules_install
> or something! This patch accurately states my current code changes:
> http://pyther.net/a/digivox_atsc/diff-Dec-06-v1.patch

Great, that's a big one step forward.

Based on this (your) patch, could you please verify that ist was really
the adding of

    {0x0d,            0x42, 0xff,   0},

to struct em28xx_reg_seq msi_digivox_atsc ? The tests before this change
were all made with a wrong combination of configuration values for the
LGDT3305...

Regards,
Frank

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On 12/08/2012 08:52 AM, Frank Schäfer wrote:
>> I lied, it works! I must have forgotten to do run make modules_install
>> or something! This patch accurately states my current code changes:
>> http://pyther.net/a/digivox_atsc/diff-Dec-06-v1.patch
> Great, that's a big one step forward.
>
> Based on this (your) patch, could you please verify that ist was really
> the adding of
>
>      {0x0d,            0x42, 0xff,   0},
>
> to struct em28xx_reg_seq msi_digivox_atsc ? The tests before this change
> were all made with a wrong combination of configuration values for the
> LGDT3305...
I have commented that line out and from some basic testing, it doesn't 
appear to change anything. I can still tune and watch a channel, scan 
still fails.

Thanks,
Matthew
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html