Am 02.02.2010 00:05, schrieb Mauro Carvalho Chehab:
> Stefan Ringel wrote:
>
>> Am 01.02.2010 22:44, schrieb Devin Heitmueller:
>>
>>> On Mon, Feb 1, 2010 at 4:23 PM, Stefan Ringel <stefan.ringel@xxxxxxxx> wrote:
>>>
>>>
>>>>> You should start by breaking it down into a patch series, so that the
>>>>> incremental changes can be reviewed. That will allow you to explain
>>>>> in the patch descriptions why all the individual changes you have made
>>>>> are required.
>>>>>
>>>>>
>>>>>
>>>>>
>>>> how can I generate it?
>>>>
>>>>
>>> You can use quilt to break it up into a patch series, or create a
>>> local hg clone of v4l-dvb.
>>>
>>>
>>>
>>>>> Why did you define a new callback for changing the tuner mode? We
>>>>> have successfully provided infrastructure on other bridges to toggle
>>>>> GPIOs when changing modes. For example, the em28xx has fields in the
>>>>> board profile that allow you to toggle GPIOs when going back and forth
>>>>> between digital and analog mode.
>>>>>
>>>>>
>>>>>
>>>>>
>>>> I don't know, how you mean it. I'm amateur programmer.
>>>>
>>>>
>>> Look at how the ".dvb_gpio" and ".gpio" fields are used in the board
>>> profiles in em28xx-cards.c. We toggle the GPIOs when switching the
>>> from analog to digital mode, without the tuner having to do any sort
>>> of callback.
>>>
>>>
>>>
>> It's a bad example. em28xx use a reg-set, but tm6000 not !! It use a
>> gpio usb request.
>>
>> tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6010_GPIO_5, 1);
>>
>>
>> I don't know, that it with the ".gpio" fields works. And when it switch
>> from analog to digital, I don't see the way.
>>
> All devices with Xceive tuners need to reset the chip via GPIO, in order to load
> the firmware. On em28xx, I wrote a patch that moved all specific init code to
> a struct (basically used by gpio's), and a generic code to do the reset. It basically
> contains what GPIO pins are used, and how many time it should wait.
>
> For example:
>
> /* Board Hauppauge WinTV HVR 900 digital */
> static struct em28xx_reg_seq hauppauge_wintv_hvr_900_digital[] = {
> {EM28XX_R08_GPIO, 0x2e, ~EM_GPIO_4, 10},
> {EM2880_R04_GPO, 0x04, 0x0f, 10},
> {EM2880_R04_GPO, 0x0c, 0x0f, 10},
> { -1, -1, -1, -1},
> };
>
> The first line of the above code will execute this logic:
> a = read(EM28XXR08_GPIO) & ~0x2e;
> write (a & ~EM_GPIO_4);
> msleep(10);
>
>
> So, it will basically preserve bits 8,7,6,4 and 1 of register 8,
> and will clear bit 4 (EM_GPIO_4 is 1 << 4 - e. g. bit 4).
> After that, it will sleep for 10 miliseconds, and will then do a
> reset on bit 3 of Register 4 (writing 0, then 1 to the bit).
>
reset example :
static struct tm6010_seq terratec[] = {
{TM6010_GPIO_2, 1, 60}, /* GPIO 2 going to high */
{TM6010_GPIO_2, 0, 75}, /* GPIO 2 going to lo */
{TM6010_GPIO_2, 1, 60}, /* GPIO 2 going to high */
{ -1 , -1, -1},
}
Is that correct?
>>
>>>>> What function does the "tm6000" member in the zl10353 config do? It
>>>>> doesn't seem to be used anywhere.
>>>>>
>>>>>
>>>>>
>>>>>
>>>> I'll switch it next week to demodulator module.
>>>>
>>>>
>>> Are you saying the zl10353 isn't working right now in your patch? I'm
>>> a bit confused. If it doesn't work, then your patch title is a bit
>>> misleading since it suggests that your patch provides DVB support for
>>> the tm6000. If it does work, then the tm6000 member shouldn't be
>>> needed at all in the zl10353 config.
>>>
>>>
>>>
>> I'm emulating it in hack.c and the zl10353 module doesn't work, if I
>> switch to it.
>>
> the hack.c needs to be validated against the zl10353, in order to identify
> what are the exact needs for tm6000. Some devices require serial mode, while
> others require parallel mode.
>
> I bet that playing with zl10353_config, we'll find the proper init values
> required by tm6000.
>
>
I have separately write in the hack.c the value from terratec hybrid
stick. The older value I haven't clean.
--
Stefan Ringel <stefan.ringel@xxxxxxxx>
--
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
