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 changesto avoid breaking bttv. Any decision taken, however, would mean that the newer v4l-dvb tree willrequire more tests than it used to require, to be stable. > 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. bttv has several "hacks" for probing i2c audio devices. Depending on theway Hans touched bttv, the conflicts will emerge. > > The pending bttv patch> > probably needs updating anyway, due to changes upstream.Yes. before hybrid redesign, however, the changes at bttv weren't muchsignificant. I'm counting with you both to help on solving the conflictsthat might emerge. > 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.If you didn't touch much on bttv, than it should be easier to solve theconflicts. > > 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. I'll probably try to do xc2028 and hybrid tuner changes about the sametime, since both deals with similar things. Since I've replaced the CONFIG_TUNER_XC3028 by CONFIG_XC2028 on alldrivers [1], including ivtv, some minor conflicts might arrive. Sinceivtv xc3028 support is based at the userspace module, you will need tofix ivtv driver later, for it to work with the newer driver. [1] http://linuxtv.org/hg/~mchehab/tm6000-ng/rev/065874933156 With the new tuner-xc2028, the tuner will only work after receiving aTUNER_SET_CONFIG, specifying the firmware driver name[2] and the audiomode (RF or MTS). [2] from what I got, it seems that different bridge chips may needdifferent firmwares. TM6000 driver, for example, doesn't work withxc3028 version 2.7 firmware. > > > 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. I'll try to finish this on Sat, but I can't promise. Cheers,Mauro _______________________________________________linux-dvb mailing listlinux-dvb@xxxxxxxxxxxxxxx://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
