On 5/16/07, Manu Abraham <abraham.manu@xxxxxxxxx> wrote:
hermann pitton wrote:
> Manu,
>
I am writing this reply with quite a lot of reluctance/hesitation, since
some people create unnecessary noise alone: people being stubborn,
practically creating a waste of time for others.
Removing all those CC's since they are already addressed on the ML's.
Sometimes it is better to keep quiet, seeing all those *noise*. The main
issue: half knowledge is too dangerous!
> what do you think already could have a GO?
>
> Markus can't invade like that, but must have a next safe harbour to
> continue to work on it.
>
> The hybrid stuff will invade the planet for long, and then ... die.
Convergence of media is not a new thing. Now it is Analog stuff added
in, the reason for a vendor: it does not make much of a difference in
terms of cost to make a chip like that, but with regards to marketing it
makes a huge difference. Later on, we will be seeing the convergence of
other media as well.
> Do you think to share tuners between digital and analog is really
> impossible, or just wait until these zilliards are gone?
I don't think it is impossible, just that it needs sufficient efforts to
do so. Now there are 2 types of designs, the analog interface is thrown
in additionally into each of them.
1) using a Single chip, bus interface + demodulator + tuner
2) using Two chips, chip1 = bus interface, chip2 = demodulator + tuner
3) using 3 chips, chip1 = bus interface, chip2 = demodulator, chip3 = tuner
I am aware of this constellation, but again I'm refering to the code now.
The dvb subsystem already uses a way to modularize some tuners.
The approach which is implemented in the em28xx/hybrid repository interfaces this design and all it does is to abstract the function arguments and adds support for it to the analogue framework.
As for the DVB side there is no redesign involved at all with that method, so everything else would still work the same way as it worked before.
I'll explain it more detailed:
The dvb framework already uses a broken out tuner approach. The structs look like following:
struct dvb_tuner_ops {
struct dvb_tuner_info info;
int (*release)(struct dvb_frontend *fe);
int (*init)(struct dvb_frontend *fe);
int (*sleep)(struct dvb_frontend *fe);
/** This is for simple PLLs - set all parameters in one go. */
int (*set_params)(struct dvb_frontend *fe, struct dvb_frontend_parameters *p);
/** This is support for demods like the mt352 - fills out the supplied buffer with what to write. */
int (*calc_regs)(struct dvb_frontend *fe, struct dvb_frontend_parameters *p, u8 *buf, int buf_len);
int (*get_frequency)(struct dvb_frontend *fe, u32 *frequency);
int (*get_bandwidth)(struct dvb_frontend *fe, u32 *bandwidth);
#define TUNER_STATUS_LOCKED 1
int (*get_status)(struct dvb_frontend *fe, u32 *status);
/** These are provided seperately from set_params in order to facilitate silicon
* tuners which require sophisticated tuning loops, controlling each parameter seperately. */
int (*set_frequency)(struct dvb_frontend *fe, u32 frequency);
int (*set_bandwidth)(struct dvb_frontend *fe, u32 bandwidth);
};
The updates struct looks like:
struct v4l_dvb_tuner_ops {
void *priv; /* some privat data for internal use */
void *dev; /* v4l private data for tuner-core */
struct dvb_frontend *fe; /* dvb_frontend, for dvb only drivers, internal use */
struct dvb_tuner_info info;
int (*ioctl)(struct v4l_dvb_tuner_ops *dev, int cmd, int arg);
int (*release)(struct v4l_dvb_tuner_ops *fe);
int (*init)(struct v4l_dvb_tuner_ops *fe);
int (*sleep)(struct v4l_dvb_tuner_ops *fe);
/** This is for simple PLLs - set all parameters in one go. */
int (*set_params)(struct v4l_dvb_tuner_ops *fe, struct dvb_int_frontend_parameters *p);
/** This is support for demods like the mt352 - fills out the supplied buffer with what to write. */
int (*calc_regs)(struct v4l_dvb_tuner_ops *fe, struct dvb_int_frontend_parameters *p, u8 *buf, int buf_len);
int (*get_frequency)(struct v4l_dvb_tuner_ops *fe, u32 *frequency);
int (*get_bandwidth)(struct v4l_dvb_tuner_ops *fe, u32 *bandwidth);
#define TUNER_STATUS_LOCKED 1
int (*get_status)(struct v4l_dvb_tuner_ops *fe, u32 *status);
/** These are provided seperately from set_params in order to facilitate silicon
* tuners which require sophisticated tuning loops, controlling each parameter seperately. */
int (*set_frequency)(struct v4l_dvb_tuner_ops *fe, u32 frequency);
int (*set_bandwidth)(struct v4l_dvb_tuner_ops *fe, u32 bandwidth);
int (*set_mode)(struct v4l_dvb_tuner_ops *dev, struct dvb_int_frontend_parameters *params);
};
So the parameters change to not directly having a dependency to dvb_frontend, this is the only change at the dvb framework, of course it touches everything that works with these callbacks. Some tuners also still use the dvb_frontend parameters, in that case (v4l_dvb_tuner_ops).fe is set to it and the tuner modules can still access it if really needed and if they are dvb tuners only.
The changes at the v4l side make it also possible to load these modules, also this doesn't lock out anything it's still nearly the same as it was before.
the usage in case 1) is highly vendor specific and we can't say much
about it. ie, it might be a certain way from vendor A and another way
from vendor B
in 2 cases except for (1), there are each 2 ways a tuner is interfaced
a) on a separate bus
In this case, the tuner is directly connected to an I2C/SPI/GPIO bus. In
this case things are very simple and the tuner is accessible always.
Plain and simple, no hassles in accessing the tuner.
b) on a bus which is private to the demodulator
In this case, the tuner is behind a demodulator, or another device too
(maybe some damned device which is not even a demodulator, even
proprietary ones you can imagine here). In the normal case that we have,
the tuner is just behind the demodulator.
Now the demodulator alone controls access to the tuner. No probes,
nothing will work if the demodulator has disabled access. (ie the tuner
is completely unaccessible without the demodulator control) You can
imagine a road which is blocked by a barrier, which is controlled by an
entity (the demodulator in this case) the access is private to the
demodulator and the demodulator alone has access to the same. How the
access is controlled only the demodulator knows. Some demodulators keep
it open all the time once a request is issued. Some close the access
based on some criteria (again the criteria is device specific)
There are advantages and disadvantages of both these methods.
(a)
* this requires an additional bus, or in some cases the tuner is just on
another address on the same bus
this additional bus in some cases would mean an additional cost, in some
case it could be just some unused GPIO used as bit-banging.
* quite simple hardware as the hardware designer doesn't have to bother
much, since it is a straight forward design
* the downside is that a bus which is left open/unterminated, creates a
lot of noise. Such devices have typically lower SNR and are much
susceptible to noise (gaussian noise is cumulative, ie additive)
(b)
* this on the same bus, just like a barrier on the same road an entity
controlling the barrier
* the advantages in this case are
1) once the gate is closed, no further communication occurs -- lesser
noise results
One might think: about the amount of noise created @ 100 khz etc, mind
you newer devices all use 400 khz as default, some do even have options
for going faster still (even though the devices what we have now just
use 400k as standard) At this rate, it is possible for an open bus to
create harmonics, especially and that too quite near to a RF stage (the
tuner is the first block, looking at any RF design) is sufficient enough
to reduce the SNR.
In this case, once the device has successfully tuned, no further
communication occurs and there is absolute silence on the bus.
In such a case, it contributes to an overall slightly higher SNR.
2) reduced usage of pins
just 2 pins are used for communication with the demodulator and no
further pins are needed for communication with the tuner.
* the disadvantage is that it adds in a small additional complication
such as communication bus control in terms of switching.
That is mostly about the hardware.
Now, for a hybrid device approach,
* the minimal changes it has to be applied to a running system, the
better it is. The larger the changes, the worser it is to fix when there
is another new category of devices. (Small is beautiful)
* even though there needs to be a hybrid between 2 systems, it doesn't
mean that one necessarily has to pull in stuff from one part of the
system to the other. This is a very bad approach of doing things and is
not at all a hybrid. We call this a "masala" or you can think of
"spaghetti" which is better known.
That said, couple of points to be noted:
1) Markus's/ Mauro's approach addresses just 3 a) alone which is
probably < ~10 % of the hardware design. The rest all do not work that
way, as i addressed above. So there indeed a necessity to address the
same issue again, inspite of this huge "masala" applied.
Instead of judging the code beeing whatever you think you should have a look how it's already done and focus on facts. I see you write alot around the whole issue again.
It's good that you explain the possibilities how a demod can work together with a tuner. Where did you get that ~10% value from, I'd like to see some sources for that.
I'm also aware that this solution won't work for everything, but it covers one of the mentioned requirements already. There's no point in saying that this is wrong or something else, if I look at your proposal it's more uncomplete than my or Mauro's proposal.
The current modularized DVB tuners in the v4l-dvb main repository all take an i2c parameter as argument, if you have a device with other requirements you can still write the specific drivers for it.
2) the other aspect is that it unnecessarily pulls in stuff into the
API, which does not fall under that system at all. In the end we have
systems which are really "fscked" up.
The dependencies are extracted into own headers.
I could also refactor some other simple tuners that way and they would work with dvb and v4l by writing one tuner driver, so there are already quite a few usecases in the v4l-dvb repository for such an approach.
3) In the circumstances mentioned both the approaches that are mentioned
in 1) are critically flawed. The only option for things to be handled in
a generic way: the DVB part has to attach the tuner and not the other
way. The other way works only for 10% (which means a failure in the
other 90%) of the cases. Whereas what i mention works in both the cases.
Additionally you don't have to make a mess of systems (minimal changes)
just 2 callbacks (IIRC) are needed, which are specific to each of the
system, hence you don't violate a systems integrity as a whole.
In the approach that which i mentioned, it additionally uses multiproto.
Johannes pointed out earlier that it is too early for multiproto to be
used in a hybrid approach in the large. The very same approach minus the
multiproto update currently can be used. When multiproto goes in, that
update will finally make it look look like what i posted earlier. (Not
only will it work for I2C, it will work with other protocols, being at a
bus interface level)
The only valid point from your side is that you have multiproto code on the other side I have support for quite a few more devices and several new device drivers and pending code from companies which already rely on that code.
I would moreover appreciate if you
Manu
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
--
Markus Rechberger
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
