On 5/15/07, Manu Abraham <abraham.manu@xxxxxxxxx> wrote:
Markus Rechberger wrote: > Hi, > > TUNER_SET_TYPE_ADDR, seems to break with that approach, it's possible > to change the tuner type on the fly with it. > There have been some devices around which for example use an xc3028 > for analogue TV and a qt1010 for DVB-T, so in that case we wouldn't > like the xc3028 hybrid tuner module to attach to the DVB part. Normally, a tuner/PLL (note that a tuner is not exactly the same as a PLL) is behind a DVB demodulator in most cases ~90% of the times. The demod of course does control access to it, also this control is private to the demod a control which is exported to the dvb-core such that DVB-CORE might use that control to do various operations with regards to the devices that are behind the demodulator. Now, there are few devices, that do not use the bus behind the demodulator. But these devices are comparatively lesser in number, say the remaining ~10%. The statement that V4L cannot set tuner address is baseless, as V4L is not supposed to do that since what the DVB subsystem controls, that alone should handle.
that your current approach breaks the TUNER_SET_TYPE_ADDR approach is not baseless. Look up where it's used at the moment and how it is used. This was the only point of what I wrote there.
http://article.gmane.org/gmane.comp.video.video4linux/32821/match=multi+std+silicon+tuners+analog If you have read through the code that i posted you see this comment +/* NOTE! + * Almost all tuners are behind a secondary bus behind a digital demodulator. + * Access to this bus is controlled by the demodulator itself by the means of a + * control with the demodulator. viz, i2c_gate_ctrl. A hybrid device (in Analog + * mode) should never try to enable/disable the i2c_gate_ctrl, ie the gate + * control is private to the demodulator. Since the demodulator only has access + * to this secondary bus, initialization is handled in a better manner by the + * digital mode. ie, dvb-core + */ The reason being manufacturers are more oriented to making DVB devices with Analog as a small add on feature, not that Analog is the main feature on it. moreover if you think that a hybrid tuner which has a major feature such as DVB stating things like: "> There have been some devices around which for example use an xc3028 > for analogue TV and a qt1010 for DVB-T, so in that case we wouldn't > like the xc3028 hybrid tuner module to attach to the DVB part." is absurd. If you think that V4L should handle this, then your thoughts (logic) itself is fundamentally flawed to a very great extend.
I think you have the wrong idea about what I wrote. V4L should only deal with analogue/radio mode of a tuner, dvb only the digital part.
Additionally, if you take a look, the proposed method doesn't require *all* the DVB drivers to be modified to make the XC3028 to work. Only the XC3028 need to be modified, which IMHO is much easier and cleaner approach that will work with other hybrid devices too in a nice and clean way, rather than messing up with the entire DVB tree.
Remember there was a proposal which didn't touch that many drivers, it got discussed till there was nothing to discuss anymore and that approach just died, I encourage everyone to participate at both projects and I don't insist on keeping the old structures as they are because they were ok for the first devices which were available but the framework simply doesn't fit for current devices anymore.
It is not that i do want to see my code being accepted or anything like that, but i do prefer to not have changes that do have a negative impact going into the DVB tree. I just wrote that as a means for people to look at it such that better drivers can be written, rather than wasting time again and again on long discussions that lead to nowhere. Also if you think that the code that which i have pasted doesn't work for you, with regards to personality issues: You can as an alternate use an approach handled by Michael which has been proven to work as well. http://www.linuxtv.org/~mkrufky/xc-bluebird.patch This will save you a lot of time too, as he is offering to spend some of his time to have a better approach. You should probably additionally test that tree whether it breaks things for you. Additionally for one driver, if the entire DVB driver tree has to be changed, don't you think that there is something wrong with your patches/driver ?
This bluebird patch makes a DVB tuner out of the v4l tuner so this is no solution for the problem, my change introduces a new way for handling these hybrid tuners which aren't directly handled by the dvb demodulator (eg. which are not behind a demod bus) dvb_tuner_ops was designed to split out the tuner functionality in DVB, this is where the V4L approach connects. The only change that I've done there is to unify the function parameters that v4l doesn't need initialized dvb structures (for example dvb_frontend). If you look at the mt2060 it's also a hybrid _tuner_ which is not directly controlled by the demod and it also uses that split out dvb_tuner_ops mechanism. I also remember that you claimed the dvb_tuner_ops approach to be broken, it exists and it is included at the moment and it works fine with many devices already. The patches I sent is only an approach to reuse that method in the v4l framework. After all that the "design" changes are very small for the DVB part, all together it's about unifying the parameters, fixing the user counter and adding a locking mechanism.
I doubt that i will be able write any further on this thread, time being very much limited. HTH Manu
-- Markus Rechberger _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
