- 07 7月, 2012 1 次提交
-
-
由 Martin Blumenstingl 提交于
Currently there are two different implementations (in the firmware) for the QAM demodulator command: one takes 4 and the other takes 2 parameters. The driver shows an error in dmesg When using the 4-parameter command with firmware that implements the 2-parameter command. Unfortunately this happens every time when chaning the frequency (on DVB-C). This patch simply makes configurable, how many command parameters will be used. All existing drxk_config instances using the "drxk_a3.mc" were updated because this firmware is the only loadable firmware where the QAM demodulator command takes 4 parameters. Some firmwares in the ROM might also use it. The drxk instances in the em28xx-dvb driver were also updated to silence the warnings. If no qam_demod_parameter_count is given in the drxk_config struct, then the correct number of parameters will be auto-detected. [mchehab@redhat.com: Fix a small CodingStyle issue at one comment] Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Tested-by: NMauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 30 6月, 2012 3 次提交
-
-
由 Mauro Carvalho Chehab 提交于
If firmware is not loaded for some reason, or if it is not ready yet, it makes no sense to honour to any DVB callbacks. So, return -EAGAIN, as the error condition may be temporary. If the device doesn't initialize, either because it requires a firmware or because there's an error during init_drxk, returns -ENODEV, to indicate such error, on all DVB callbacks. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
Don't allow other devices at the same I2C bus to use it during firmware load, in order to prevent using the device while it is not on a sane state. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
The firmware blob may not be available when the driver probes. Instead of blocking the whole kernel use request_firmware_nowait() and continue without firmware. This shouldn't be that bad on drx-k devices, as they all seem to have an internal firmware. So, only the firmware update will take a little longer to happen. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 21 1月, 2012 1 次提交
-
-
由 Mauro Carvalho Chehab 提交于
Those two settings are different when used with az6007. Add a config option to enable it. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 06 1月, 2012 2 次提交
-
-
由 Mauro Carvalho Chehab 提交于
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
Instead of creating two DVB frontend entries for the same device, create just one entry, and fill the delivery_system according with the supported standards. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 31 12月, 2011 1 次提交
-
-
由 Mauro Carvalho Chehab 提交于
Instead of using dvb_frontend_parameters struct, that were designed for a subset of the supported standards, use the DVBv5 cache information. Also, fill the supported delivery systems at dvb_frontend_ops struct. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 10 12月, 2011 1 次提交
-
-
由 Mauro Carvalho Chehab 提交于
The DRX-K doesn't change the delivery system at set_properties, but do it at frontend init. This causes problems on programs like w_scan that, by default, opens both frontends. Instead, explicitly set the format when set_parameters callback is called. Tested-by: NEddi De Pieri <eddi@depieri.net> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 28 7月, 2011 8 次提交
-
-
由 Mauro Carvalho Chehab 提交于
Now, it outputs: [10927.639641] drxk: SCU_RESULT_INVPAR while sending cmd 0x0203 with params: [10927.646283] drxk: 02 00 00 00 10 00 07 00 03 02 .......... Better than ERROR -3. This happens with Terratec H5 firmware. It adds 2 new error conditions, and something useful to track what the heck is that. I suspect that the scu_command is dependent on the firmware revision. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
The driver is too limited: it assumes that UIO is used only for controlling the antenna, and that only UIO-1 is in usage. However, from Terratec H7 driver [1], 3 UIO's can be used. In fact, it seems that H7 needs to use all 3. So, make the code generic enough to handle the most complex scenario. For now, only antena GPIO can be specified, but is is easier now to add the other GPIO/UIO needs. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
Terratec H5 doesn't require to switch mode, but generates an error due to this logic. Also, GPIO's are board-dependent. So, add it at the board config struct. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
On em28xx, tda18271C2 is accessible when the i2c port is not touched. Touching on it breaks the driver. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
The microcode firmware provided on Terratec H5 seems to be different. Add a parameter to allow specifying a different firmware per-device. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
Instead of using #ifdef I2C_LONG_ADR for some devices, convert it into a parameter. Terratec H5 logs from the original driver seems to need this mode. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Oliver Endriss 提交于
Tons of coding-style fixes Signed-off-by: NOliver Endriss <o.endriss@gmx.de> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Ralph Metzler 提交于
Driver for the DRX-K DVB-C/T demodulator. Signed-off-by: NRalph Metzler <rjkm@metzlerbros.de> Signed-off-by: NOliver Endriss <o.endriss@gmx.de> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-