Re: [RFC] tuner-refactor-phase-2

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

 



Mauro Carvalho Chehab wrote:> Em Sex, 2007-10-26 às 12:09 +0200, Hans Verkuil escreveu:>   >> On Friday 26 October 2007 06:24, Michael Krufky wrote:>>     >>> Mauro Carvalho Chehab wrote:>>>       >>>> Hi Michael,>>>>>>>> Em Seg, 2007-10-22 às 16:03 -0400, mkrufky@xxxxxxxxxxx escreveu:>>>>         >>>>> Mauro & others,>>>>>>>>>> After our conversation last week, I decided to move forward with>>>>> tuner-refactor-phase-2, so that you can have the pathway for your>>>>> tda9887 & tea5767 changes to go in without clashing with my>>>>> pending work.>>>>>>>>>> My code is now ready for review:>>>>>>>>>> http://linuxtv.org/hg/~mkrufky/tuner-refactor-phase-2>>>>>           >>>> I expect a few troubles on merging the newer patches for 2.6.25,>>>> since there are several significant changes that are expected to>>>> happen, during this development period, like:>>>>>>>> - the newer tuner-redesign changesets;>>>> - i2c redesign;>>>> - bttv removal of V4L1 support;>>>>         >>> ^^^ These above do not conflict with each other. >>>       >> I suspect that bttv V4L1 removal will conflict with both changesets.> I'll need to decide what's the better order for merging those 3 changes> to avoid breaking bttv. >   NO -- the tuner changes do not touch bttv -- they are all internal tothe tuner code.
If you have to remove some v4l1 support from tuner-core, that willsimply be the removal of a few lines, and it can be easily done by hand.
OTOH, If you push in the v4l1 removal first, and it conflicts with thepending tuner changes, that _will_ cause a problem.  It will require forthe entire patch series to be regenerated, and this will result inholding up Hans from moving forward with his work, until I have time toregenerate the entire series.
> bttv has several "hacks" for probing i2c audio devices. Depending on the> way Hans touched bttv, the conflicts will emerge.>>   Hans did not touch anything yet -- he's waiting for the pending changesto first be merged.
As I said before, Hans and I spoke about our changes with each other,and made sure that we would not create any patch conflicts.  Everybodyis waiting for the large changes to be merged in first before they moveon to making new changes to the affected code.
> With the new tuner-xc2028, the tuner will only work after receiving a> TUNER_SET_CONFIG, specifying the firmware driver name[2] and the audio> mode (RF or MTS).>> [2] from what I got, it seems that different bridge chips may need> different firmwares. TM6000 driver, for example, doesn't work with> xc3028 version 2.7 firmware.>   If you are going to push in the xc2028 stuff, the core changes should goin first, then you should alter your new patch as required.  I do notexpect this xc2028 driver to work with the devices that I have, and Ibelieve that you are going to create a large confusion about firmware,not to mention that you do not have any legal rights to alter ordistribute the firmware.
I wouldn't rush in the xc2028 stuff before the other changes.
-Mike
_______________________________________________linux-dvb mailing listlinux-dvb@xxxxxxxxxxxxxxx://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb


[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux