On Friday 26 October 2007 13:28, 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.>> Any decision taken, however, would mean that the newer v4l-dvb tree> will require 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> the way 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> much significant. I'm counting with you both to help on solving the> conflicts that 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> the conflicts.>> > > 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> same time, since both deals with similar things.>> Since I've replaced the CONFIG_TUNER_XC3028 by CONFIG_XC2028 on all> drivers [1], including ivtv, some minor conflicts might arrive. Since> ivtv xc3028 support is based at the userspace module, you will need> to fix 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 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.>> > > > 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. Of course, I understand. Just to make it absolutely clear: my i2c changes DO NOT TOUCH bttv. Or any other V4L driver for that matter. You need to explicitly change the V4L driver to make use of the new i2c code, without those changes the old probing will still be used. The only change is that in the kernel log messages you will see that the name of the i2c driver has a ' (single quote) appended to indicate that it uses i2c probing. I'm not even certain if bttv can ever be converted to the new i2c mechanism: the i2c addresses of the devices on each board were never recorded as far as I know. For ivtv I either have the board myself, or know who has a specific board so I can get hold of the required i2c addresses. Regarding testing xc2028 devices: I think all my xc2028 devices are in Oslo right now, and I'm back home for the week in Holland. So it will have to wait a week before I can test anything. Bad timing :-( These days my hardware is spread over two locations :-) Regards, Hans _______________________________________________linux-dvb mailing listlinux-dvb@xxxxxxxxxxxxxxx://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
