[linux-dvb] DVB-S2 / Multiproto and future modulation support

Steven Toth stoth at linuxtv.org
Thu Sep 11 14:51:38 CEST 2008

hermann pitton wrote:
> Am Mittwoch, den 10.09.2008, 22:59 -0400 schrieb Steven Toth:
>> hermann pitton wrote:
>>> Hi,
>>> Am Mittwoch, den 10.09.2008, 21:00 -0400 schrieb Steven Toth:
>>>> Christophe Thommeret wrote:
>>>>> Le Thursday 11 September 2008 00:59:31 Andreas Oberritter, vous avez écrit :
>>>>>> Hans Werner wrote:
>>>>>>>> So applications could know that these 2 frontends are exclusive.
>>>>>>>> That would not require any API change, but would have to be a rule
>>>>>>>> followed by
>>>>>>>> all drivers.
>>>>>>> Yes, if we keep to that rule then only frontends which can operate truly
>>>>>>> simultaneously should have a different adapter number.
>>>>>> An adapter refers to a self-contained piece of hardware, whose parts can
>>>>>> not be used by a second adapter (e.g. adapter0/demux0 can not access the
>>>>>> data from adapter1/frontend1). In a commonly used setup it means that
>>>>>> adapter0 is the first initialized PCI card and adapter1 is the second.
>>>>>> Now, if you want a device with two tuners that can be accessed
>>>>>> simultaneously to create a second adapter, then you would have to
>>>>>> artificially divide its components so that it looks like two independant
>>>>>> PCI cards. This might become very complicated and limits the functions
>>>>>> of the hardware.
>>>>>> However, on a setup with multiple accessible tuners you can expect at
>>>>>> least the same amount of accessible demux devices on the same adapter
>>>>>> (and also dvr devices for that matter). There is an ioctl to connect a
>>>>>> frontend to a specific demux (DMX_SET_SOURCE).
>>>>>> So, if there are demux0, frontend0 and frontend1, then the application
>>>>>> knows that it can't use both frontends simultaneously. Otherwise, if 
>>>>>> there are demux0, demux1, frontend0 and frontend1, then it can use both
>>>>>> of them (by using both demux devices and connecting them to the
>>>>>> frontends via the ioctl mentioned above).
>>>>> Sounds logical. And that's why Kaffeine search for frontend/demux/dvr > 0 and 
>>>>> uses demux1 with frontend1. (That was just a guess since i've never seen 
>>>>> neither any such devices nor comments/recommendations/rules about such case).
>>>>> However, all dual tuners devices drivers i know expose the 2 frontends as 
>>>>> frontend0 in separate adapters. But all these devices seems to be USB.
>>>>> The fact that Kaffeine works with the experimental hvr4000 driver indicates 
>>>>> that this driver populates frontend1/demux1/dvr1 and then doesn't follow the 
>>>>> way you describe (since the tuners can't be used at once).
>>>>> I would like to hear from Steve on this point.
>>>> Correct, frontend1, demux1, dvr1 etc. All on the same adapter. The 
>>>> driver and multi-frontend patches manage exclusive access to the single 
>>>> internal resource.
>>> then please explain what is about the analog usage, which can always be
>>> first and don't tell it has to stay back, since you always sit on that
>>> bridge and else come nowhere ...
>> Hermann, I'm not sure I understand your question, but I'll try.
>> This has nothing to do with analog, I never suggested these patches 
>> effected analog.
>> Either you're confused, or I am :)
>> The multifrontend patches are related to DVB only, the analog ports on 
>> the cx88 remain untouched, unchanged.
> Steve,
> likely we should have all some sleep previously again.

Hermann, I have problems trying to understand your written English, I do 
not always understand what you write. This leads to confusion.

> But I'm quit sure what I'talking about.

Of course you do, I never suggested that you were not.

> If using the dma engines of the saa713x at once, you can't say analog
> and dvb are not related!

Oh, I understand the topic you are mentioning now.

I have no experience with the 7134 and I'm not aware of it's hardware 
capabilities, or lack of. I'm not fit to comment on what resources can 
be shared and the implications of.

What I can say with confidence, is that if it has a digital transport 
port, and if some of the cards share this port with DVB-T and DVB-S then 
the multiple-frontend patches will probably help with those designs. 
Rather than having to specify DVB-T or DVB-S during module load time, 
the patches will negotiate user access and allow both to be present.

This may be a good feature for the 7134, it may not.

> There are clear restrictions and you can cause major dammage ignoring
> them.

Nobody is ignoring them, thank you for raising the issue.

- Steve

More information about the linux-dvb mailing list