[linux-dvb] [PATCH] 8PSK/BPSK DVB-S/S2 support

Manu Abraham abraham.manu at gmail.com
Sat Feb 25 22:15:42 CET 2006

Ralph Metzler wrote:
> Marcel Siegert writes:
>  > i also did talk to manu yesterday alot, and i think his idea,
>  > moving frontend stuff to userspace and just implement a
>  > simple read/write register within the kernel, is a nice thing.
>  > it should be forced to become reality imho. i do know there
>  > will be a lot of work todo, but with having this interface, we could
>  > even do a migration to a different api version for those lib users,
>  > without having to change the client application at all.
>  > we were talking about some stuff to implement so that from end users
>  > view everything will be a stable and consistent interface.
>  > you may read on the irc log of #linutx from yesterday at linuxtv.org
> While I agree that some of the more generic frontend stuff (probably
> most of dvb_frontend.c) could be handled in user space I am still 
> wondering how you want to handle very card specific features/quirks
> (also after reading the IRC logs) if you move all the frontend drivers
> into userspace.
> The user space library will not only have to know about things like
> specific GPIO controls (like mentioned in IRC) but things like
> necessary locking between busses of different logical frontends which
> belong to the same card. This can not only be necessary for one I2C
> transfer but around specific command sequences going to different devices.
Can't we use a state machine to handle this ? We don't use the RAW i2c 
bus as it is, but we use another interface (which fits in the 
requirements) that interfaces to the i2c bus.

This part of the state machine does exist in kernel space as well as 
user space. The state machine can be included in this interface in both 
kernelspace and userspace. and the relevant functions does the necessary 
translation depending upon the state. In any case a semaphore is in a 
way a state machine.

Some of the quirks, are basically from the bridge device, we can solve 
some parts of the issues there. At present almost all frontends do 
attach with an xx_attach function, and communicate through the i2c 
interface. Some do use the GPIO also for handling things in between 
alongwith i2c, and some even a pseudo i2c interface. anyhow i2c 
communications are quite slow and do not exceed 400kHz, so this can be 
really handled in userspace.

I have a link to my original idea here.

> So, would the library have to know those details about each card!?

Yes, another one of the advantages would be that even the board 
specifications, all those larger arrays can be moved out to userspace. 
For this the library will even need to know PCI ID's etc. The interface 
has to export information like this and more to userspace for the 
library for identifying the boards etc, and even for doing a similar 
attach routine also.

Looking at the large number of card database structures, another 
advantage of moving things to userspace is that even cards can easily be 
forced to use a specific board type as this is easier in userspace 
compared to kernel. Lesser bloat in the kernel too.

The good thing would be that we can do whatever frontend operations 
necessary, without any limitations.


More information about the linux-dvb mailing list