Am 06.12.2012 22:57, schrieb Devin Heitmueller:
> On Thu, Dec 6, 2012 at 4:49 PM, Frank Schäfer
> <fschaefer.oss@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
