- 05 Jan, 2012 7 commits
-
-
Mauro Carvalho Chehab authored
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
convert to Unix eol, run Lindent and remove bad whitespaces Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Those files are marked as licensed with GPL, so, it is ok to merge. They came from Terratec site: http://linux.terratec.de/files/TERRATEC_H7/20110323_TERRATEC_H7_Linux.tar.gzSigned-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
- 04 Jan, 2012 15 commits
-
-
Steven Toth authored
Found an odd bug while implementing support for the HVR1850 that lead to jerky video during the first capture, if the encoder was not initialized early. I've modied the driver to configure the encoder early, and this avoids the issue - a reasonable workaround. Regression tested against the HVR1800 and soon to be added HVR1850 [mchehab@redhat.com: Fix this compilation issue: drivers/media/video/cx23885/cx23885-417.c:1351:2: error: too few arguments to function ‘cx23885_initialize_codec’] Signed-off-by: Steven Toth <stoth@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Steven Toth authored
Bugfix: The height was not always correctly configured if switching between different video standards. Change the encode height based on the standard. Signed-off-by: Steven Toth <stoth@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Steven Toth authored
During initialization the prior GPIO's were not being preserved and restore correctly. Small cleanups to configure the GPIO's for the HVR1700, HVR1800 and HVR1850. Signed-off-by: Steven Toth <stoth@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Steven Toth authored
Since the conversion to subdev in Oct 2010 the audio controls have not functioned correctly in the cx23885 driver. Passing values of 0-3f did not translate into meaningfull register writes. I've converted the cx23885 driver to match the cx25840 volume control definition and now audio is working reliably again. Signed-off-by: Steven Toth <stoth@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
matthieu castet authored
Signed-off-by: Matthieu CASTET <castet.matthieu@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
matthieu castet authored
- enable fast usb quirk - use usleep_range instead on msleep for short sleep - merge i2c out and usb delay - do like the windows driver that upload the tuner firmware with 80 bytes packets Signed-off-by: Matthieu CASTET <castet.matthieu@free.fr> CC: Thierry Reding <thierry.reding@avionic-design.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Now that this field is deprecated, and core generates it for DVBv3 calls, remove it from the drivers. It also adds .delsys on the few drivers where this were missed. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Mark info.type as deprecated inside the header, recommending the usage of DTV_ENUM_DELSYS DVBv5 command instead. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
This var were used during DVBv3 times, in order to keep a copy of the parameters used by the events. This is not needed anymore, as the parameters are now dynamically generated from the DVBv5 structure. So, just get rid of it. That means that a DVBv5 pure call won't use anymore any DVBv3 parameters. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
using -1 for ISDB-T parameters do the wrong thing. Fix it. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
For frontends with ISDB-T, DVB-T2, CMDBTH, etc, some code is needed, in order to provide emulation. Add such code, and check if the desired delivery system is supported by the frontend. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Get rid of using ops->info.type defined on DVB drivers, as it doesn't apply anymore. Currently, one driver (cxd2820) supports more than one different info.type, as it can be used for DVB-T/T2 and DVB-C. There are more drivers like that to come. So, the same frontend will have different DVBv3 types, depending on the current delivery system. This breaks the existing logic at dvb_frontend, that assumes that just one delivery system DVBv3 type is supported by all delsys. In order to easy the DVBv3->DVBv5 conversion, an ancillary function that maps DVBv3 delivery systems into DVBv5 were added. Also, on all places, except for the event logic, the DVBv5 cache will be used to check parameters, instead of the DVBv5 copy. This patch simplifies the cache sync logic, and warrants that the cache will be in a clear state at DVB frontend register. This way, ops->info.type will be filled to reflect the first delivery system, providing backward compatibility support for it. For example, in the cases like cxd2820, where the delivery systems are defined as: .delsys = { SYS_DVBT, SYS_DVBT2, SYS_DVBC_ANNEX_A }, A pure DVBv3 will be able to use both DVB-T and DVB-T2, as, at DVB cache clear, the ops->info.type will be equal to FE_OFDM. However, DVB-C won't be visible. A quick workaround would be to do a DVBv5 call to set the delivery system to SYS_DVBC_ANNEX_A. After such call, ops->info.type will be equal to FE_QAM, and a DVBv3 application will see the frontend as a DVB-C one. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
This change is there in order to prepare the code to avoid calling dvb_frontend_ioctl_legacy() from FE_SET_PROPERTY. A call to dvb_frontend_ioctl_legacy() would require to update the DVBv3 cache without need, mangling calls for newer delivery system without any reason. No functional changes here. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Due to DVB-T2, several new possible values for bandwidth were added. As the DVBv3 struct were updated to handle them, the core needs to handle all of them, as a DVBv3 application might try to use it. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
By default, initialize the frontend current delivery system with the first one. This warrants that a DVBv3 application will be able to tune to it, after the removal of ops->init.type filling at the drivers. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
- 01 Jan, 2012 1 commit
-
-
Mauro Carvalho Chehab authored
Return the complete RC-5 code, instead of just the 8 least significant bits. Reported-by: Dorozel Csaba <mrjuuzer@upcmail.hu> Tested-by: Dorozel Csaba <mrjuuzer@upcmail.hu> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
- 31 Dec, 2011 17 commits
-
-
Mauro Carvalho Chehab authored
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Only the ioctl core should see the DVBv3 compat stuff, as its contents are not available anymore to the drivers. As fs/compat_ioctl also handles DVBv3 ioctl's, it needs those definitions: fs/compat_ioctl.c:1345: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345: error: array type has incomplete element type fs/compat_ioctl.c:1345: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345: error: array type has incomplete element type fs/compat_ioctl.c:1345: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345: error: array type has incomplete element type fs/compat_ioctl.c:1345: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345: error: initializer element is not constant fs/compat_ioctl.c:1345: error: (near initialization for ‘ioctl_pointer[462]’) fs/compat_ioctl.c:1346: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346: error: array type has incomplete element type fs/compat_ioctl.c:1346: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346: error: array type has incomplete element type fs/compat_ioctl.c:1346: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346: error: array type has incomplete element type fs/compat_ioctl.c:1346: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346: error: initializer element is not constant fs/compat_ioctl.c:1346: error: (near initialization for ‘ioctl_pointer[463]’) fs/compat_ioctl.c:1347: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’ fs/compat_ioctl.c:1347: error: array type has incomplete element type fs/compat_ioctl.c:1347: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’ fs/compat_ioctl.c:1347: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’ fs/compat_ioctl.c:1347: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’ fs/compat_ioctl.c:1347: error: array type has incomplete element type fs/compat_ioctl.c:1347: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’ fs/compat_ioctl.c:1347: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’ fs/compat_ioctl.c:1347: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’ fs/compat_ioctl.c:1347: error: array type has incomplete element type fs/compat_ioctl.c:1347: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’ fs/compat_ioctl.c:1347: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’ fs/compat_ioctl.c:1347: error: initializer element is not constant fs/compat_ioctl.c:1347: error: (near initialization for ‘ioctl_pointer[464]’) Reported-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
A few drivers don't have .delsys. Add it, in order to allow future patches for dvb_frontend.c to not use info.type. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Just like set_frontend, use the dvb cache properties for get_frontend. This is more consistent, as both functions are now symetric. Also, at the places get_frontend is called, it makes sense to update the cache. Most of this patch were generated by this small perl script: while (<>) { $file .= $_; } if ($file =~ m/\.get_frontend\s*=\s*([\d\w_]+)/) { my $get = $1; $file =~ s/($get)(\s*\([^\,\)]+)\,\s*struct\s+dtv_frontend_properties\s*\*\s*([_\d\w]+)\)\s*\{/\1\2)\n{\n\tstruct dtv_frontend_properties *\3 = &fe->dtv_property_cache;/g; } print $file; Of course, the changes at dvb_frontend.[ch] were made by hand, as well as the changes on a few other places, where get_frontend() is called internally inside the driver. On some places, get_frontend() were just a void function. Those occurrences were removed, as the DVB core handles such cases. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
On several places inside dvb_frontend, only the DVBv3 parameters were updated. Change it to be sure that, on all places, the DVBv5 parameters will be changed instead. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Before this patch, a query for the delivery systems were returned SYS_UNDEFINED. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Now that all frontends are implementing DVBv5, don't export the DVBv3 specific stuff to the drivers. Only the core should be aware of that, as it will keep providing DVBv3 backward compatibility. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
The cx23885-dvb driver has a dirty hack: 1) it hooks the DVBv3 legacy call to FE_SET_FRONTEND; 2) it uses internally the DVBv3 struct to decide some configs. Replace it by a change during the gate control. This will likely work, but requires testing. Anyway, the current way will break, as soon as we stop copying data for DVBv3 for pure DVBv5 calls. Compile-tested only. Cc: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Every frontend now uses DVBv5 way. So, let's not use the DVBv3 macros internally anymore. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Now that everybody is talking DVBv5 API dialect, using this DVBv3 macro internally is not ok. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
This callback is not used anywhere. Maybe it were used in the past to optimize the custom algo, but, as it is not used anymore, let's just remove it. If later needed, some patch may re-add it with a proper implementation. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Just like the other DVB algorithms, drivers should use the DVBv5 way to retrieve parameters: via the cache struct. Actually, several drivers were partially using the DVBv3 struct and partially using the DVBv5 way, with is confusing and may lead into troubles. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
As all parameters are passed via DVBv5 to the frontends, there's no need to pass them again via fops. Also, most drivers weren't using it anyway. So, instead, just pass a parameter to indicate if the hardware algorithm wants the driver to re-tune or not. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
In the past, dvb_frontent_parameters were passed inside the struct where get_tuner_settings should store their result. This is not needed anymore, as all parameters needed are stored already at the fe property cache. So, use it, where needed. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Now that all drivers were converted, we can get rid of those emulation calls. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-