Hi,
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)
I would like to know what you guys think about this.
Thanks,
Manu
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
