> Felix Domke wrote: > > Though I didn't test this, i strongly agree that we need this. I don't > > think it should be user selectable, though (except for the "SIMPLE" > > mode) - either the frontends supports a specific algorithm or not. > > Otherwise i fear that user applications start to workaround frontend > > driver bugs by selecting another algorithm... > > > > What's the exact difference between HW and ADAPTIVE? Isn't "it's done in > > hardware" the same as "it's done in the frontend driver", as far as the > > API is concerned? > > > > Some frontends support blindscanning, but require heavy software support > > for this (Fujitsu mb86a15 for example). Such code is not really suitable > > in the kernel (it sleeps, includes complicated algorithms etc.), so i > > think the best would be to make it a userspace library with frontend > > specific private ioctls, providing more or less direct register (or even > > i2c) access. What do you think? > > After a while, i would like to continue this discussion from where we > left off last time. In this regard i did some basic homework ( no code > yet ) > but did come to the thoughts that a userspace library would be indeed > the solution. In such a case i was drawn to the conclusion that a > userspace i2c like extension which interfaces from the kernel to the > userspace in such a manner that it interfaces to the Host Bridge directly. > Why i would think that a generic i2c interface probably might not be the > solution is because almost all Host Bridges have General Purpose Input > Output (GPIO) for controlling some peripherals. for ex. frontends. > > Under such a circumstance i made my ideas into block diagrams for easier > self explanation, without too many words. > > But in any case i would like to make a small outline on the very same. > We could add just 2 IOCTL's to the existing API for making it compatible > with applications such that applications can choose between these two > and or switch between the interfaces. > Currently i came to a conclusion something like this. > > http://www.thadathil.net/dvb/msg_transfer_interface/interface_desc.txt > > > There are other advantages more than what was discussed earlier on this > aspect than just tuning algorithms. Some of the advantages are > > * we don't loose anything as all these communications that are exchanged > are low speed communications > * lesser bloat in kernel > * being in userspace, things can be easily debugged > * cards with lot of cross definitions can be easily implemented, without > the need of huge arrays in kernel > * the application can get a better control of the drivers (the frontend > thread could easily be in the application, rather being in the kernel) > But will need to keep the existing one as it is for compatibility reasons. > * userspace can handle math libraries compared to kernel. > * we can do tuning algorithms specific to frontends too.(such that we > can make use of the hardware features) Yeah, I like this idea. If we keep on as we are, we're not really going to get anywhere; it is becoming increasingly obvious that putting all the tuning code in the kernel is hampering things a great deal. Many of the window drivers I have examined have a similar architecture as well: raw device access in kernel land, with the "interesting" stuff happening in userspace. This way means we can support the old system so it provides minimum disruption to existing users, but that we can also develop the more advanced stuff required by others at the same time. I also like the idea of an i2c-like communications (but not i2c itself). i2c itself is a very neat idea well understood by many people, so it makes sense to mimic it. Obviously we can't use the kernel i2c layer directly because we don't want to impose a dependency like that, since not all DVB devices support i2c. I suppose there might be an argument that we should "emulate" an i2c host for non-i2c based DVB cards - personally I don't like this since IMO it would be overkill, but I thought I should mention it for completeness. We could even do interesting things like have a python/perl interface to the tuning system for rapid prototyping of tuning/frontend drivers - something that sounds good to me. _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
