On Tue, Mar 31, 2009 at 3:20 PM, Gabriele Dini Ciacci
<dark.schnei...@iol.it> wrote:
> On Tue, 31 Mar 2009 07:56:10 -0300
> Mauro Carvalho Chehab <mche...@infradead.org> wrote:
>
>> Hi Gabriele,
>>
>> On Sun, 29 Mar 2009 15:56:08 +0200
>> Gabriele Dini Ciacci <dark.schnei...@iol.it> wrote:
>>
>> > Hello,
>> >
>> > This is a stub patch to make the subjects card work.
>> >
>> > I am using the driver on a pctv60e and it is very stable, I use it
>> > daily. It should work for pctv200e but not owning the device I
>> > cannot test it.
>> >
>> > The code need to be cleaned, as I am not an experienced kernel
>> > coder. The code in mt352.c contains an hard-coded address for the
>> > device, while Pinnalce devices with that tuner uses a different
>> > address. Currently the address is "hijacked" to be the correct one.
>> > This is a hack, and i think that mt352.c should be changed to
>> > support multiple addresses, selected via params, duplicate code or
>> > something.
>> >
>> > Remote support is missing, cause it was not working out of the box.
>> > I do not use it and so developing it for myself only was not very
>> > useful, if someone wants it or is interested I can have a look.
>> >
>> > The patch is generally messy, I need help there. I do not know if I
>> > have to change all the functions to take as parameter an adapter_nr
>> > or change the caller to continue to pass them a struct
>> > dvb_usb_device obtained with i2c_get_adapdata(adapter_nr).
>> >
>> > Here is the patch, as an attachment, thanks meanwhile.
>>
>> Well, let's go by parts.
>>
>> It seems that you wrote your driver based on some USB sniffing. Do
>> you know what are the chipsets present on your driver? Maybe there's
>> another driver already developed or under development for the same
>> chipset.
>
> I actually did not any sniffing at all. I was ready to go for it (so I
> asked a windows guy to send me the sniff).
> Obtained that, I started to look at it, then I
> realized that v4l already had support for all the chipsets the thing
> was using. I just made the code that connects the parts and such,
> indeed the patch is only the main file, no low level chip file, or
> anything else touched. So there is no actual code for the chipsets.
> I'm using mt353 and mt2060, that are already in the main tree.
>
> As I explained above, mt353.c makes a wrong assumption about the address
> the chip has, at it also states that in a comment, explaining that on
> pinnacle hardware (like in this case) the address is different. I just
> had to hijack that and hack this. I was suggesting above to fix
> mt353.c else, no pinnacle card with mt353 can be implemented with a
> clean code.
>
>> In the case of your patch, you should first run checkpatch.pl for it
>> to show you the non-compliances of your driver and Linux Kernel
>> CodingStyle. checkpatch.pl is avaliable at kernel tree,
>> under /scripts dir. You'll also find it at v4l-dvb development tree,
>> at v4l/script/checkpatch.pl.
>> It is also a good idea to read README.patches at v4l-dvb development
>> tree.
>>
>
> I have checked coding style manually, I'll use the script.
> I read README.patches the first time i coded the driver, reread it on
> January when I updated the driver to the new interface and decided to
> send it the first time to the ml on 01/06/2009. In January it was
> outdated in regards to the new patch system adopted, wiki was also
> outdated. I'll reread it to see if I am missing something and to check
> if it needs to be updated to explain the new system for patch.
>
> To sum up I will run checkpatch.pl and when it run fine I will resend
> the patch.
>
> But note that the problem with mt353.c stays, I do not have the
> necessary confidence to change a low level chipset driver interface to
> make it not assume an hardcoded adderss.
>
>> Cheers,
>> Mauro
>
> Thanks, see you :)
> Best Regards,
> Gabriele

Is this device not based on a Cypress FX2?  If so, then there
shouldn't be a new driver at all.  We would just need a device profile
in the existing driver.

http://linuxtv.org/wiki/index.php/Pinnacle_PCTV_60e

Devin

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

Reply via email to