Am Mittwoch, den 16.05.2007, 23:48 +0400 schrieb Manu Abraham: > 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 > Thanks for reply, but that forkout stuff is still in the air and you don't really calm it down. My questions are much more simple. Example, the Avermedia a16a(r) is hanging in space since ever for analog, but works since a while with the Avermedia 777 for DVB-T. The mt352 is in the way for analog tuning, datasheets have been publically available before sold to Intel. Avermedia has a closed source binary driver for it for some older kernels, coupled with the E506 cardbus XCeive, with _stolen_ code from us! One can likely _hack_ it for analog tuning, the registers and reset recommendations are clear and gpio 35,36 for bit banging, but it will likely interfere with dvb init on autolaoding of the hybrid device. So, how to proceed? Cheers, Hermann _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
