Re: [PATCH] drivers: support new Siano tuner devices.

[Mauro Carvalho Chehab <mchehab@redhat.com>]

Em 03-08-2011 10:22, Doron Cohen escreveu:
> Hi,
> OK, I will change so request_module will be called for all devices.

OK, thanks!

> Regarding the other comment you have sent about the IR module - I have
> noticed it when I continued with the merges and fixed it last week but
> I had a small accident where I formatted the wrong disk and had to start
> over my merges.

Sorry to hear. Yeah, bad things happen.

> I will make the proper changes based on the comments about this thread
> and publish it again.

Ok, no problem.

> Thanks,
> Doron
> 
> -----Original Message-----
> From: Mauro Carvalho Chehab [mailto:mchehab@redhat.com] 
> Sent: Wednesday, August 03, 2011 14:09
> To: Doron Cohen
> Cc: BOUWSMA Barry; linux-media@vger.kernel.org
> Subject: Re: [PATCH] drivers: support new Siano tuner devices.

Btw, please, don't top-post. It makes harder for people to understand, when
the answer is written before the question.

Thanks!
Mauro

> 
> Em 03-08-2011 02:06, Doron Cohen escreveu:
>> Hi Barry,
>> One thing I need to check before I approve and even extent this
> change:
>> What happens if the smsdvb module does not exists.
>> I assume nothing happens since we are not checking the return code and
> therefore everything will work as if this call was
>> not exist, but I would like to check that before my final decision.
>> The reason is that the devices from HAUPPAUGE which currently request
> for the smsdvb module must use the
>> v4l as defined by HAUPPAUGE. Other device based on other SMS chips
> (Not just the STELLAR but also the NOVA, VENICE, RIO
>> and other device series) not always uses the v4l but sometimes has
> proprietary player which used the SMS device directly. 
>> So I wouldn't like to cause harm for those users.
>> I seems that requesting the module will not harm, if the module does
> not exists - the request will fail and everything
>> will keep working, and if the module exists it will load but they
> still won't have to use it.
> 
> I think you're calling the DVB API as "v4l". Be careful, as "v4l" is the
> name of 
> the API used for analog TV and webcams. "DVB API" is the name of the API
> used for
> Digital TV, where DVBv3 means the API that supports only DVB/C/T/S and
> ATSC, and
> DVBv5 is the flexible API that supports multiple Delivery Systems, and
> whose addition
> of a new one is just a matter of adding a new set of properties to
> FE_GET_PROPERTY and
> FE_SET_PROPERTY.
> 
> The only API acceptable for a DVB driver at the Linux Kernel is the DVB
> API.
> Nothing prevents you to offer other API's to your customers, but
> upstream 
> patches with another API aren't accepted. We had a similar discussion
> years 
> ago, when Uri synced the Siano's internal tree with the kernel one.
> 
> That's said, if smsdvb doesn't exist, request_module("smsdvb") won't
> produce 
> any error.
> 
>> So in that case I would also add a few more devices to the list (all
> of Siano devices which 
>> supports standards supported by v4l. 
> 
> The right solution is to move request_module("smsdvb")to be outside of
> the card-specific test, trying to load it for all boards, as it won't 
> make sense otherwise (as there's no sense to add the driver to Kernel
> without the DVB API, as it won't work as-is).
> 
> 
> If there are some Delivery System not yet supported, then the right
> solution 
> is to propose a DVB API addition (using DVBv5 API) to support the new
> Delivery
> System. There are a few ones not properly supported yet. So, go ahead
> and propose 
> adding new properties to support such standards.
> 
> Recently, I found some time to update DVBv5 API description for the
> supported 
> Delivery Systems. It is at:
> 	
> http://linuxtv.org/downloads/v4l-dvb-apis/FE_GET_SET_PROPERTY.html#fe_pr
> operty_parameters
> The DocBook source for it is at
> Documentation/DocBook/media/dvb/dvbproperty.xml.
> 
> Basically, the API currently documents: DVB-T/T2/C/S/S2, ISDB-T/S and
> ATSC.
> 
> It misses a few standards like DVB-H, DMB and CMMB. Yet, there are a few
> frontends implementing
> them (lgs8gl5, for example, implements DMB-TH). So, maybe all that it is
> needed for some of
> those standards are already there or maybe the current implementations
> just put everything on
> the AUTO mode.
> 
> So, maybe it is just a matter of properly documenting what properties
> those standards need. If not,
> adding a few new properties and/or extending the existing ones should be
> enough to add support
> for them.
> 
>> If the change will cause problems for users who doesn't need the v4l I
> will object to this change.
>> I will run a few tests on that and either add these changes or let you
> know of a problem in a few days.
>>
>> Regarding DAB+, it was added to the firmware about a year ago, it is
> required to change the firmware
>> file with a newer one and nothing is required in the host layers for
> that support. Bad news is that 
>> according to the patch you gave - you are probably using STELLAR
> device and there is no such firmware 
>> for that device. The DAB+ support was added to newer Siano devices
> (NOVA and up) but not for the 
>> STELLAR due to device HW limitations.
> 
> Currently, DAB is not covered by DVBv5 API. So, we'll likely need to add
> some new properties there
> for it.
> 
> Cheers,
> Mauro
> 
>  
>  
> ************************************************************************
> ************
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code, vandals &
> computer viruses.
> ************************************************************************
> ************
> 
> 
>