Am 02.02.2010 17:44, schrieb Mauro Carvalho Chehab:
> Stefan Ringel wrote:
>
>
>>> 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?
>>
> Yes. In the case of tm6010, it has separate registers for each GPIO, so, you
> don't need a bitmask.
>
>
>>> 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.
>>
> Ok, but maybe you missed my point: at the long term, we should get rid of hack.c, and
> be sure that all needed initializations are done by zl10353 driver or by tm6010-dvb.
>
I think I all are done by zl10353 driver.
I thinbk all config param is usefull and ".tm6000" for tm6000 specific
once. For what is ".parallel_ts" ?
int tm6000_dvb_attach_frontend(struct tm6000_core *dev)
{
struct tm6000_dvb *dvb = dev->dvb;
if(dev->caps.has_zl10353) {
struct zl10353_config config =
{.demod_address = dev->demod_addr,
.no_tuner = 1,
.parallel_ts = 1,
.if2 = 45700,
.disable_i2c_gate_ctrl = 1,
.tm6000 = 1,
};
dvb->frontend = pseudo_zl10353_attach(dev, &config,
// dvb->frontend = dvb_attach (zl10353_attach, &config,
&dev->i2c_adap);
}
else {
printk(KERN_ERR "tm6000: no frontend defined for the device!\n");
return -1;
}
return (!dvb->frontend) ? -1 : 0;
}
--
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
