drivers: support new Siano tuner devices.

Commit Message

Doron Cohen Aug. 3, 2011, 5:06 a.m. UTC

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. 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. 
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.

Regards,
Doron 


-----Original Message-----
From: BOUWSMA Barry [mailto:[e-mail]] 
Sent: Tuesday, August 02, 2011 11:19
To: Doron Cohen
Cc: [e-mail]
Subject: Re: [PATCH] drivers: support new Siano tuner devices.

On k (kedd) 19.júl (július) 2011, 14:21,  Doron Cohen wrote:

> This is the first time I ever post changes to linux kernel, so excuse me
> if I have errors in the process.
> As Siano team member, I would like to update the drivers for Siano
> devices with the latest and greatest fixes. Unfortunately there is a hug
> gap between the current code in the kernel and the code Siano has which
> is more advanced and supports newer devices. I will try to break down
> the changes into small pieces so each of the changes will be clear and
> isolated.
> Here is the first change which is my "test balloon" and includes simple
> changes which includes support in new devices pulished after the kernel
> source maintenance has stopped.

Thanks for your contribution, and I hope it sees usage.

I have found that for many kernel revisions, I have had to have
some variant of the following added code, for my Siano-based
device to function automatically in DVB-T modus:



Apologies if this problem has been addressed by your patchset.
If there was a reason for removing this functionality, I have
not been able to follow it over time.


Another thing, as my device is capable of receiving DAB radio
broadcasts and Siano has provided a library to make this possible
under Linux, are there plans to update this library for the DAB+
standard that is now being used, with the Reed-Solomon error
protection and up to HE-AACv2 audio encoding?  (I am aware of the 
960-sample-window incompatibility with many AAC software players.)



barry bouwsma
mails will be delayed due to infrequent internet access
now on the road in croatia
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Mauro Carvalho Chehab Aug. 3, 2011, 11:08 a.m. UTC | #1

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_property_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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Doron Cohen Aug. 3, 2011, 1:22 p.m. UTC | #2

Hi,
OK, I will change so request_module will be called for all devices.
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.
I will make the proper changes based on the comments about this thread
and publish it again.

Thanks,
Doron

-----Original Message-----
From: Mauro Carvalho Chehab [mailto:[e-mail]] 
Sent: Wednesday, August 03, 2011 14:09
To: Doron Cohen
Cc: BOUWSMA Barry; [e-mail]
Subject: Re: [PATCH] drivers: support new Siano tuner devices.

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.
************************************************************************
************



--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Mauro Carvalho Chehab Aug. 3, 2011, 1:23 p.m. UTC | #3

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:[e-mail]] 
> Sent: Wednesday, August 03, 2011 14:09
> To: Doron Cohen
> Cc: BOUWSMA Barry; [e-mail]
> 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.
> ************************************************************************
> ************
> 
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

--- 3.0.0-rc1-hacks/sms-cards.c.orig    2011-04-06 04:04:12.000000000 +0200
+++ 3.0.0-rc1-hacks/sms-cards.c 2011-07-09 10:17:30.000000000 +0200
@@ -301,6 +301,11 @@ 
        case SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD_R2:
                request_module("smsdvb");
                break;
+/* XXX HACK */
+       case SMS1XXX_BOARD_SIANO_STELLAR:
+               request_module("smsdvb");
+               break;
+
        default:
                /* do nothing */
                break;