Mauro, Mauro Carvalho Chehab wrote: > Michael, > > Em Qui, 2007-04-05 às 16:31 -0400, Michael Krufky escreveu: >> Mauro Carvalho Chehab wrote: >>> Also, for silicon tuners, we have a recent case, where tda897x deals >>> with dvb, while tda8290 deals also with tda897x, but for v4l. >> Please leave tda8290 / tda8275(a) alone for now. Hartmut and I have some big >> changes coming, and external changes made to those files will screw us up. >> >> FYI, tda8290 is predominantly a driver for the analog IF demod. > >> The tuning code itself can easily be factored into a unified tuning >> sub-module, useable by both >> subsystems. I have plans to do this now, without any need for API >> changes. >> >> Once we reach agreement on how we handle hybrid silicon, I will handle >> the >> conversion for the tda827x tuners. > > This doesn't make my argument invalid. It appears that I may have been misunderstood. Your argument is completely valid, I only ask that nobody touch tda8290.c or tda827x.c until Hartmut and I are done with our upcoming changes. > The fact is that the support for hybrid tuners is hard due the lack of a > proper way to connect the same driver to both cores. This lead each > developer to find his own way for handling tuners, resulting on > duplicated stuff and two different drivers for the same device. Agreed. > Not having a standard way for this is not good. We need to have one way, > used by all developers that works with hybrid devices. Agreed. > It should also have a locking schema avoiding the usage of both tuner > modes at the same time. What happens if you call both a dvb and an > analog app at the same time with the current code? Agreed. >> The tuning code itself can easily be factored into a unified tuning >> sub-module, useable by both subsystems. I have plans to do this now, >> without any need for API changes. > > How would you do this without API changes? V4L tuners currently can't > currently be a separate module, but should be part of tuner-core. So, to > allow a tuner to register on tuner-core, some API changes are required. > Otherwise, you cannot load a sub-module at tuner-core. Again, I am being misunderstood.... The API changes are indeed needed. I am just working on reusing the code without duplication. In order for us to Do The Right Thing (tm) , we *do* need some api changes. I'd rather not go into detail about my uncommitted changes. Maybe it would be best if you pretend I never said "I have plans to do this now, without any need for API changes". I was only talking about code unification. We still need the API changes to provide a single tuner interface, and locking abilities. I repeat - the discussion that you and Manu are having is a very good discussion, and I fully support the direction that this is taking. > Also, tuner struct is different from dvb_frontends struct, although both > have several stuff that can be common. If you pass a dvb_frontends > struct to tuner-core, or otherwise, pass a struct tuner to dvb, there > will be some missing parameters. > >> Once we reach agreement on how we handle hybrid silicon, I will handle >> the >> conversion for the tda827x tuners. > > This seems to be the proper way. Let's first close the API changes, then > convert the drivers. Yes. For now, I am developing my tuner driver with the current methods. It will be very easy to convert to the new methods once we reach agreement. > I intend to convert all tuner drivers to the newer API, to allow to > modularize the tuners, including tuner-simple. Good. Hopefully I will be able to get my change into tda8290.c before we're ready for the conversion. I should be able to push in some patches in a week or so... -- Michael Krufky _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
