Re: [PATCH 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)

[Antti Palosaari <crope@iki.fi>]

On 07/15/2011 08:01 PM, Andreas Oberritter wrote:
> On 15.07.2011 15:25, Mauro Carvalho Chehab wrote:
>> Em 15-07-2011 05:26, Ralph Metzler escreveu:
>>> At the same time I want to add delivery system properties to
>>> support everything in one frontend device.
>>> Adding a parameter to select C or T as default should help in most
>>> cases where the application does not support switching yet.
>>
>> If I understood well, creating a multi-delivery type of frontend for
>> devices like DRX-K makes sense for me.
>>
>> We need to take some care about how to add support for them, to avoid
>> breaking userspace, or to follow kernel deprecating rules, by adding
>> some legacy compatibility glue for a few kernel versions. So, the sooner
>> we add such support, the better, as less drivers will need to support
>> a "fallback" mechanism.
>>
>> The current DVB version 5 API doesn't prevent some userspace application
>> to change the delivery system[1] for a given frontend. This feature is
>> actually used by DVB-T2 and DVB-S2 drivers. This actually improved the
>> DVB API multi-fe support, by avoiding the need of create of a secondary
>> frontend for T2/S2.
>>
>> Userspace applications can detect that feature by using FE_CAN_2G_MODULATION
>> flag, but this mechanism doesn't allow other types of changes like
>> from/to DVB-T/DVB-C or from/to DVB-T/ISDB-T. So, drivers that allow such
>> type of delivery system switch, using the same chip ended by needing to
>> add two frontends.
>>
>> Maybe we can add a generic FE_CAN_MULTI_DELIVERY flag to fe_caps_t, and
>> add a way to query the type of delivery systems supported by a driver.
>>
>> [1] http://linuxtv.org/downloads/v4l-dvb-apis/FE_GET_SET_PROPERTY.html#DTV-DELIVERY-SYSTEM
>
> I don't think it's necessary to add a new flag. It should be sufficient
> to add a property like "DTV_SUPPORTED_DELIVERY_SYSTEMS", which should be
> read-only and return an array of type fe_delivery_system_t.
>
> Querying this new property on present kernels hopefully fails with a
> non-zero return code. in which case FE_GET_INFO should be used to query
> the delivery system.
>
> In future kernels we can provide a default implementation, returning
> exactly one fe_delivery_system_t for unported drivers. Other drivers
> should be able to override this default implementation in their
> get_property callback.

One thing I want to say is that consider about devices which does have 
MFE using two different *physical* demods, not integrated to same silicon.

If you add such FE delsys switch mechanism it needs some more glue to 
bind two physical FEs to one virtual FE. I see much easier to keep all 
FEs as own - just register those under the same adapter if FEs are shared.

regards
Antti


-- 
http://palosaari.fi/