Change in how projects are going to work.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Mauro Carvalho Chehab wrote:
> On Wed, 9 Apr 2008 21:27:18 -0700
> Greg KH <greg at kroah.com> wrote:
> 
>> On Wed, Apr 09, 2008 at 08:43:32AM +0400, Manu Abraham wrote:
>>> Mauro Carvalho Chehab wrote:
>>>
>>>> I'm currently lacking the time to work on they by myself, since I'm currently
>>>> evolved on fixing em28xx, and finishing tm6000 driver, but I can help someone
>>>> interested on working on the drivers to give them the proper directions.
>>>
>>> Yuck ! you mean to say , to write drivers similarly to your tm6000 hack.c?
>>>
>>> (LOL, Just happened to have a loud fart !)
>>>
>>> http://linuxtv.org/hg/~mchehab/tm6000/file/499c88f177c1/linux/drivers/media/video/tm6000/hack.c
>> Heh, that's too funny!  And here I thought only I wrote code for USB
>> devices like that :)
> 
> Yes, it is funny ;)
> 
> Just a side note: 
> 
> As marked on the changeset that introduced this hack [1], this code and the
> rest of the DVB code were written by Michael Ludwig. I didn't have time yet to
> look at the DVB part of the driver. I've just received this week my first
> tm6000-based device with DVB.
>

Still, what will you do without any DVB-T transmissions ? Fiddling with
a DVB demod without a transmission, is quite hopeless.


> The big issue here is that he couldn't get the proper documentation for Zarlink
> 10353. It seems that tm6000 needs to program different parameters than the
> other DVB bridges. Also, tm6000 doesn't seem to be reliable enough to allow
> reading something from I2C.
> 
> The proper solution here is to remove this hack, and add support at the
> existing mt352 driver. However, for doing this, we need more information.

No, please use the zl10353 driver. There are significant differences
between the MT352 and the 10353. Please don't screw up working
demodulators! If you need anything more you can fix the 10353 driver.

Most likely you might need to fiddle around with the AGC targets only.
Markus has some similar changes for his devices, the same what you are
looking at.

Almost all devices uses the same tuning algorithm for acquisition for
the 10353.


> That part of Zarlink were bought by Intel. I've already tried to get Intel, in
> order to their datasheets without success.
> 
> We are also lacking contact on Trident, to get their datasheets. So, the driver
> are being written based on the listened traffic at USB bus, generated by a M$
> driver.

As basic I/O works, things aren't much too different. It is a standard
bridge. It is a matter of reorganizing your code and sanitizing it a bit.

> Maybe someone at the list may help us to get those datasheets.

Believe me: the datasheets aren't going to help any further ..

Regards,
Manu



[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux