[linux-dvb] Re: Twinhan DVB-T: Works, what's next?

[Holger Waechtler <holger@convergence.de>]

Dmitri Katchalov wrote:
> Greetings,
>
> I've got Twinhan DVB-T card frontend working as you can see here:
> http://robdvd.radfiles.net/viewtopic.php?t=341.
>
> Now I want to make a proper frontend driver for it.
>
> I started with Twinhan DVB-S "dst" frontend and butchered
> it to death in the process. There are a some things in 
> common between the two but there are some subtle differences.
> It may be easier for me to do a completely new frontend for 
> this card only and leave dst as it is as I have no way of 
> testing my changes with the satellite version.
> The frontend is going to be quite small and simple really.
> bttv and dvb-bt8xx will do most of the hard work, I only need
> to set up the tuner.
>
> The card supports 2 commands (those that I'm aware of).
> One is SET_TUNER, it takes frequency and bandwidth and returns
> non-zero if the tuner has a lock, 0 otherwise. The CPU on board
> takes care of the rest. It can take upto 1 second to complete. 
> The other command is GET_STATUS, it returns 3 1-byte values 
> somehow related to signal strength and quality. The first byte 
> is zero if the tuner is not locked onto signal and non-zero 
> otherwise. Apart from that I've no idea how to interpret them yet.
>
> I have a few questions
>
>
> * Are these 2 commands above enough to control the tuner 
> or do I need to dig deeper?
don't know the DST protocol well enough, so I can't say much here...

Basically there are 2 ways for specialized frontends like the DST: 
Either write a 'classic' standalone driver module located the frontends/ 
directory or hook it into the dst-driver: call dvb_register_frontend() 
directly and don't use the i2c-autoprobing feature. This saves code 
space and avoids that the wrong i2c frontend driver attaches to the bus. 
And it might save initialisation time since you don't need to probe 
other drivers (and don't need to export/register the i2c bus at all - )


> * What API level should I aim for? I understand that version 
> 3 is current and v4 is being discussed, is it correct?
yes.

> * My card only requires frequency and bandwidth. I can
> ignore all the extra parameters in SET_FRONTEND but what 
> should I return in GET_FRONTEND?
The appropriate XXX_AUTO values, so it's possible to tune again with the 
values you obtained.

> * Do I need to implement non-blocking mode in my frontend?
> I see that not all of the front-ends have it.
The other frontends don't block, the SET_FRONTEND ioctl usually returns 
after the communication to the frontend finished. Status is returned 
asynchronously using the GET_STATUS ioctl.

> Do I need to worry about locking at all?
You need to care about the usual locking, interrupts might arrive at any 
time. Semaphores are used in the dvb-core code to serialize the frontend 
communication, so you can be sure that only one frontend ioctl is called 
at a time.

> * I'm running the latest and greatest 2.6.0-testX kernels.
> 2.4.x simply does not work well on my hardware (something 
> to do with SATA and ACPI, has only been fixed recently).
> Is there anything special I need to do to make my frontend
> work with 2.4.x kernels? 
You should check that the dvb_functions.[hc] and dvb_compat.[hc] stuff 
compiles correctly for both 2.4 and 2.6.

> * What is the scale of SNR, BER and signal strength
> values as returned by the frontend? Where are they used?
Read cvs.linuxtv.org/DVB/doc/HOWTO-use-the-frontend-api for an explanation.

> Do I have to implement all of them?
:) all the hardware supports...
or: if you don't have the required info to implement them you simply 
can't do it...

> * Anything else I'm missing?
>
> One last thing, I guess I will need CVS access sometines soon.
No problem, just send Johannes, Michael or me your ssh2 key and we'll 
create an account for you.

Holger



--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.