[linux-dvb] Re: [RFC] multi std silicon tuners and analog tuners
Hi Manu, Em Qui, 2007-04-05 às 00:16 +0400, Manu Abraham escreveu: > so when subsystem A acquires control, a lock is acquired by the bridge > (the bridge can be imagined as a fulcrum for switching between systems) > This locking would be a FSM for handling different switches. > > now the bridge can acquire/release locks, needs some code additions to > the bridge to have this, for old devices it doesn't matter at all. > > now when subsystem B request control, it makes a request to the control > manager on the bridge, the control is passed all the way down from the > frontend(DVB)/ tuner(V4L) so it still remains quite independent the > tuner/frontend part from the bridge > > with regards to TUNER (V4L) the same can be achieved using set standard > or similar. > Will have additionally one more callback (a new one) Currently, there two different tuner approaches for dealing with hybrid tuners. One as part of DVB frontend and another on V4L tuner implementation. This is bad, since it results on duplicating some code. For example, if you look on non-silicon tuners, the core of dvb-pll do the same programming as tuner-simple. Also, for silicon tuners, we have a recent case, where tda897x deals with dvb, while tda8290 deals also with tda897x, but for v4l. The right direction for this is to have the same tuner code used by both V4L and DVB. DVB callback approach for dvb_frontends seems to be an interesting approach. It doesn't cover, however, all needs for V4L. For example, some devices have also FM radio support, where stereo carrier detect and analog signal strengh are important measures. So, it is needed to add newer callbacks and maybe some extra data field for this struct to be used also by v4l. One interesting target is to have a common tuner/frontend code that can be used by radio, analog and digital tuners, in a way that it can be attached to dvb_frontend and/or to tuner_core. If just one module is handling both analog and digital tuning, it would be easier to have locks protecting the concurrence troubles you've pointed above. -- Cheers, Mauro ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: [RFC] multi std silicon tuners and analog tuners
Mauro Carvalho Chehab wrote: > Hi Manu, > > Em Qui, 2007-04-05 às 00:16 +0400, Manu Abraham escreveu: >> so when subsystem A acquires control, a lock is acquired by the bridge >> (the bridge can be imagined as a fulcrum for switching between systems) >> This locking would be a FSM for handling different switches. >> >> now the bridge can acquire/release locks, needs some code additions to >> the bridge to have this, for old devices it doesn't matter at all. >> >> now when subsystem B request control, it makes a request to the control >> manager on the bridge, the control is passed all the way down from the >> frontend(DVB)/ tuner(V4L) so it still remains quite independent the >> tuner/frontend part from the bridge >> > >> with regards to TUNER (V4L) the same can be achieved using set standard >> or similar. >> Will have additionally one more callback (a new one) > > Currently, there two different tuner approaches for dealing with hybrid > tuners. One as part of DVB frontend and another on V4L tuner > implementation. This is bad, since it results on duplicating some code. > ACK, not only is that duplication bad, but when there will be large changes with one system, that approach will be a failure. Too much work will be involved when an internal API changes, not to mention when the external API change occurs. > For example, if you look on non-silicon tuners, the core of dvb-pll do > the same programming as tuner-simple. > > Also, for silicon tuners, we have a recent case, where tda897x deals > with dvb, while tda8290 deals also with tda897x, but for v4l. > > The right direction for this is to have the same tuner code used by both > V4L and DVB. > > DVB callback approach for dvb_frontends seems to be an interesting > approach. It doesn't cover, however, all needs for V4L. For example, > some devices have also FM radio support, where stereo carrier detect and > analog signal strengh are important measures. So, it is needed to add > newer callbacks and maybe some extra data field for this struct to be > used also by v4l. With what i thought, with some slight changes at both ends (very minimal) it should be able to work. > > One interesting target is to have a common tuner/frontend code that can > be used by radio, analog and digital tuners, in a way that it can be > attached to dvb_frontend and/or to tuner_core. > Even without a common tuner, things can be achieved quite well, which require lesser maintenance. With the case of DVB, things are moving, ie not stagnant due to the arrival/addition of new stuff, so that is also an important aspect in deciding how to go about. A high maintenance path is not a viable option. Having a common tuner is not a nice aspect. Subsystems should be separated out, while still being interoperable. > If just one module is handling both analog and digital tuning, it would > be easier to have locks protecting the concurrence troubles you've > pointed above. > Already have a driver now. It requires some trimming of the V4L parts (someone probably might need to retouch/complete the V4L area), will post after a few reviews. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: [RFC] multi std silicon tuners and analog tuners
Em Qui, 2007-04-05 às 23:41 +0400, Manu Abraham escreveu: > > DVB callback approach for dvb_frontends seems to be an interesting > > approach. It doesn't cover, however, all needs for V4L. For example, > > some devices have also FM radio support, where stereo carrier detect and > > analog signal strengh are important measures. So, it is needed to add > > newer callbacks and maybe some extra data field for this struct to be > > used also by v4l. > > > With what i thought, with some slight changes at both ends (very > minimal) it should be able to work. Yes. It doesn't seem to be hard to do a few changes on both sides in a way that the same tuner driver can be used by both subsystem cores. > > One interesting target is to have a common tuner/frontend code that can > > be used by radio, analog and digital tuners, in a way that it can be > > attached to dvb_frontend and/or to tuner_core. > > > > > Even without a common tuner, things can be achieved quite well, which > require lesser maintenance. > With the case of DVB, things are moving, ie not stagnant due to the > arrival/addition of new stuff, so that is also an important aspect in > deciding how to go about. A high maintenance path is not a viable option. > > Having a common tuner is not a nice aspect. Subsystems should be > separated out, while still being interoperable. I'm thinking on having a common tuner/frontend struct that can be attached on both subsystem cores. For now, I agree that it is better to have the cores separate, since there are some internal interfaces that would be difficult to merge. Basically, on DVB, i2c support is used at the lowest possible API, while, on V4L, we use the higher level I2C support. I2C guys are working on providing some newer ways to attach devices at the high level API. After those changes, maybe it would valuable to have dvb and v4l using the same i2c api. Then, we may have one common tuner core. > > If just one module is handling both analog and digital tuning, it would > > be easier to have locks protecting the concurrence troubles you've > > pointed above. > > > > > Already have a driver now. It requires some trimming of the V4L parts > (someone probably might need to retouch/complete the V4L area), will > post after a few reviews. Ok. Markus also did another approach on his RFC. We really should address this issue as soon as possible, to allow better support for hybrid devices. -- Cheers, Mauro ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: [RFC] multi std silicon tuners and analog tuners
Manu Abraham wrote:
> Hi All,
>
> Currently, we have silicon tuners loading FIR filter specific DSP boot
> codes for tuners as well, of course Silicon tuners. While working with
> the STB6100 silicon tuner which had been a rogue for that matter, found
> that the same could be extended for tuners as well.
>
> Some tuners as what i see, loads delivery system specific firmware to
> optimize the FIR filter characteristics on the teeny DSP of the silicon
> tuner. In some cases the DSP boot code is as well included in the
> firmware which needs a reset of the DSP, but in many cases doesn't need so
>
> The approach can be used for *all* hybrid tuners how complex it might be
> since it leaves room for future expansion as well.
>
> My thoughts go like this.
>
> currently the existing infrastructure is assumed to be thus ...
>
> DVB API is modified with the multiproto API update which thus has the
> enhanced Silicon tuner changes already for the STB6100.
>
> with regards to the DVB API , the userspace sets a delivery system for
> the demodulator, which can be a cached parameter at the bridge(ie, the
> card config to be precise, which is also known as the glue logic)
>
> so when subsystem A acquires control, a lock is acquired by the bridge
> (the bridge can be imagined as a fulcrum for switching between systems)
> This locking would be a FSM for handling different switches.
>
> now the bridge can acquire/release locks, needs some code additions to
> the bridge to have this, for old devices it doesn't matter at all.
>
> now when subsystem B request control, it makes a request to the control
> manager on the bridge, the control is passed all the way down from the
> frontend(DVB)/ tuner(V4L) so it still remains quite independent the
> tuner/frontend part from the bridge
>
[..]
> with regards to TUNER (V4L) the same can be achieved using set standard
> or similar.
> Will have additionally one more callback (a new one)
>
A possible implementation patch i have attached to this post. The base
tree is at http://jusst.de/manu/stb0899-v4l-dvb.tar.bz2
The bridge specific locking code also i have included in the tuner
driver. In reality it should go all the way down to the bridge driver.
The driver doesn't actually do any real read/writes, but just provides
the placeholders for the same. All delivery systems(DVB)/standards(V4L)
are used in it. In real life one wouldn't have so many standards and
delivery systems (for illustrational purposes)
Awaiting comments
Manu
diff -Naurp stb0899-v4l-dvb.orig/v4l-dvb/linux/drivers/media/dvb/dvb-core/dvb_frontend.h stb0899-v4l-dvb/v4l-dvb/linux/drivers/media/dvb/dvb-core/dvb_frontend.h
--- stb0899-v4l-dvb.orig/v4l-dvb/linux/drivers/media/dvb/dvb-core/dvb_frontend.h 2007-02-24 14:57:15.0 +0400
+++ stb0899-v4l-dvb/v4l-dvb/linux/drivers/media/dvb/dvb-core/dvb_frontend.h 2007-04-09 19:34:31.0 +0400
@@ -209,6 +209,12 @@ struct dvb_tuner_ops {
*/
int (*set_state)(struct dvb_frontend *fe, enum tuner_param param, struct tuner_state *state);
int (*get_state)(struct dvb_frontend *fe, enum tuner_param param, struct tuner_state *state);
+
+ /* These are specifically meant for hybrid tuners */
+ int (*state_lock)(struct dvb_frontend *fe, int lock);
+ int (*get_info)(struct dvb_frontend *fe, struct dvbfe_info *tuner_info);
+ void (*get_delsys)(struct dvb_frontend *fe, enum dvbfe_delsys *tuner_delsys);
+ int (*set_delsys)(struct dvb_frontend *fe, struct dvbfe_params *params);
};
struct dvb_frontend_ops {
diff -Naurp stb0899-v4l-dvb.orig/v4l-dvb/linux/drivers/media/dvb/frontends/dummy_hybrid_tuner.c stb0899-v4l-dvb/v4l-dvb/linux/drivers/media/dvb/frontends/dummy_hybrid_tuner.c
--- stb0899-v4l-dvb.orig/v4l-dvb/linux/drivers/media/dvb/frontends/dummy_hybrid_tuner.c 1970-01-01 04:00:00.0 +0400
+++ stb0899-v4l-dvb/v4l-dvb/linux/drivers/media/dvb/frontends/dummy_hybrid_tuner.c 2007-04-09 20:34:15.0 +0400
@@ -0,0 +1,788 @@
+/*
+ Dummy Hybrid Tuner driver for illustrational purposes
+
+ Copyright (C) Manu Abraham <[EMAIL PROTECTED]>
+ Copyright (C) Christoph pfister <[EMAIL PROTECTED]>
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software
+ Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "dvb_frontend.h"
+
+#include "dummy_hybrid_tuner.h"
+
+#define dprintk(args...)
Re: [linux-dvb] Re: [RFC] multi std silicon tuners and analog tuners
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. Regards, Michael Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [RFC] multi std silicon tuners and analog tuners
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. 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. 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. 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? > 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. 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. I intend to convert all tuner drivers to the newer API, to allow to modularize the tuners, including tuner-simple. -- Cheers, Mauro ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [RFC] multi std silicon tuners and analog tuners
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@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [RFC] multi std silicon tuners and analog tuners
Em Qui, 2007-04-05 às 17:10 -0400, Michael Krufky escreveu: > 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. Yes. It doesn't make sense touching the code right now, before we've agreed on the changes. There's just a point that worries me: Markus, Manu and you are coding different solutions for the API. We should focus our discussion at the API changes *then* coding the drivers. Otherwise, the discussion will just generate warm, since each one will defend his approach, according with his own foot and it would be really hard to have a common approach. My suggestion is to start the discussion from Markus RFC, since it is the first one who proposed an RFC on this subject, (his second approach is dated from Feb, 27). He sent the 3rd approach today. As it is an RFC, and provided that *all* keep the discussions at the highest possible technical level, not starting or answering to personal flames, I can see everyone collaborating on this and converging to a common sense. This is a good time to remind about good values. Happy Easter for all! -- Cheers, Mauro ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [RFC] multi std silicon tuners and analog tuners
Mauro Carvalho Chehab wrote: > Em Qui, 2007-04-05 às 17:10 -0400, Michael Krufky escreveu: > >> 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. > Yes. > > It doesn't make sense touching the code right now, before we've agreed > on the changes. > > There's just a point that worries me: Markus, Manu and you are coding > different solutions for the API. We should focus our discussion at the > API changes *then* coding the drivers. Otherwise, the discussion will > just generate warm, since each one will defend his approach, according > with his own foot and it would be really hard to have a common approach. I am not touching the API. I am working on adding support for the tda8295+8275a and tda8295+18271 to tda8290.c and tda827x.c . For now, I have the analog parts working and ready, will push in a patch after Hartmut's review. Manu's proposal runs deeper than Markus, and address the issue in a much more thorough manner. I like the direction that the discussion between you and Manu are going. We must all keep an open mind, and make the BEST decision. This is not a race, and it doesnt matter who came first. I have no proposal on the table. I just want to see the best solution made. > My suggestion is to start the discussion from Markus RFC, since it is > the first one who proposed an RFC on this subject, (his second approach > is dated from Feb, 27). He sent the 3rd approach today. Manu's rfc has been outstanding for over a year now. Multiproto is required for dvb-s2 support, and Markus' proposal does not take multiproto into account. I am sure Manu will be able to get into better detail, here. > As it is an RFC, and provided that *all* keep the discussions at the > highest possible technical level, not starting or answering to personal > flames, I can see everyone collaborating on this and converging to a > common sense. Yes. > This is a good time to remind about good values. > > Happy Easter for all! same to you. Regards, Michael Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [RFC] multi std silicon tuners and analog tuners
Mauro Carvalho Chehab wrote: > Em Qui, 2007-04-05 às 17:10 -0400, Michael Krufky escreveu: > >> 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. > Yes. > > It doesn't make sense touching the code right now, before we've agreed > on the changes. > > There's just a point that worries me: Markus, Manu and you are coding > different solutions for the API. We should focus our discussion at the > API changes *then* coding the drivers. Otherwise, the discussion will > just generate warm, since each one will defend his approach, according > with his own foot and it would be really hard to have a common approach. > > My suggestion is to start the discussion from Markus RFC, since it is > the first one who proposed an RFC on this subject, (his second approach > is dated from Feb, 27). He sent the 3rd approach today. > > As it is an RFC, and provided that *all* keep the discussions at the > highest possible technical level, not starting or answering to personal > flames, I can see everyone collaborating on this and converging to a > common sense. As i said .. "With the case of DVB, things are moving, ie not stagnant due to the arrival/addition of new stuff, so that is also an important aspect in deciding how to go about. A high maintenance path is not a viable option." The reason being DVB is a fast moving commercial target. Linux/OSS just barely tries to catch up. I don't care what option is chosen (for the same reason had been silent), but the above is extremely important. There are more things important to DVB than just Hybrid/Analog device support alone. > > This is a good time to remind about good values. > > Happy Easter for all! > Wishing you all the same Regards, Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [RFC] multi std silicon tuners and analog tuners
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. Markus On 4/9/07, Manu Abraham <[EMAIL PROTECTED]> wrote: Manu Abraham wrote: > Hi All, > > Currently, we have silicon tuners loading FIR filter specific DSP boot > codes for tuners as well, of course Silicon tuners. While working with > the STB6100 silicon tuner which had been a rogue for that matter, found > that the same could be extended for tuners as well. > > Some tuners as what i see, loads delivery system specific firmware to > optimize the FIR filter characteristics on the teeny DSP of the silicon > tuner. In some cases the DSP boot code is as well included in the > firmware which needs a reset of the DSP, but in many cases doesn't need so > > The approach can be used for *all* hybrid tuners how complex it might be > since it leaves room for future expansion as well. > > My thoughts go like this. > > currently the existing infrastructure is assumed to be thus ... > > DVB API is modified with the multiproto API update which thus has the > enhanced Silicon tuner changes already for the STB6100. > > with regards to the DVB API , the userspace sets a delivery system for > the demodulator, which can be a cached parameter at the bridge(ie, the > card config to be precise, which is also known as the glue logic) > > so when subsystem A acquires control, a lock is acquired by the bridge > (the bridge can be imagined as a fulcrum for switching between systems) > This locking would be a FSM for handling different switches. > > now the bridge can acquire/release locks, needs some code additions to > the bridge to have this, for old devices it doesn't matter at all. > > now when subsystem B request control, it makes a request to the control > manager on the bridge, the control is passed all the way down from the > frontend(DVB)/ tuner(V4L) so it still remains quite independent the > tuner/frontend part from the bridge > [..] > with regards to TUNER (V4L) the same can be achieved using set standard > or similar. > Will have additionally one more callback (a new one) > A possible implementation patch i have attached to this post. The base tree is at http://jusst.de/manu/stb0899-v4l-dvb.tar.bz2 The bridge specific locking code also i have included in the tuner driver. In reality it should go all the way down to the bridge driver. The driver doesn't actually do any real read/writes, but just provides the placeholders for the same. All delivery systems(DVB)/standards(V4L) are used in it. In real life one wouldn't have so many standards and delivery systems (for illustrational purposes) Awaiting comments Manu -- Markus Rechberger ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [RFC] multi std silicon tuners and analog tuners
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. 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. 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. 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 ? I doubt that i will be able write any further on this thread, time being very much limited. HTH Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [RFC] multi std silicon tuners and analog tuners
On 5/15/07, Manu Abraham <[EMAIL PROTECTED]> 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 m
