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 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. 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. 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) Manu _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
