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. Hans and I have> coordinated such that we will not patch clash, and the i2c> conversions deal mostly with client modules... any impact on bttv,> if any, will be localized in the i2c code. The pending bttv patch> probably needs updating anyway, due to changes upstream. I agree with Mike here. My i2c patches do not touch the tuner, nor should they conflict with anything else. It does the initial conversion of a bunch of i2c drivers and installs the framework. No v4l driver is actually using it yet, ivtv will be the first to switch over. I'm waiting with the tuner conversion for Mike's patches to go in first because that gives me a better testing baseline, not because I expect merge conflicts. For the same reason the xc2028 addition is unlikely to clash with my intended tuner i2c changes. > The changes above hold priority over the two below.>> > - xc3028 old code removal;> > - tuner-xc2028 addition;>> Regardless, the xc2028 changes are unlikely to cause any conflict> with the other changes.>> Hans is waiting for the tuner-refactor-phase-2 tree to be merged> before he pushes in the i2c changes, and you should wait for those> both to be merged before dealing with xc2028, in my opinion. Actually, xc2028 can go in before my i2c changes since these i2c changes to not involve the tuner. They are not dependent on one another. > > Since those envolves several changes at core, it is likely that> > changesets will conflict.>> anything is possible, but i don't think it's likely :-)>> > So, I intend to carefully handle the 2.6.25 changesets already> > finished during this weekend, hopefully.>> OK. I have more changes planned that depend on these... If I add> changesets to the tree, i'll send you addendums to my original pull> request. >From my perspective it would be great if the tuner and i2c changes would go in on Saturday, then I can use Sunday to do the tuner i2c conversion, deliver yet another i2c driver for the Mitsubishi M52790 A/V switch and add in ivtv patches to support two new boards. It's no wonder ivtv suffers relatively often from i2c detection issues: it supports no less than 15 different i2c devices. Regards, Hans _______________________________________________linux-dvb mailing listlinux-dvb@xxxxxxxxxxxxxxx://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
