- 24 Jul, 2014 4 commits
-
-
David Härdeman authored
Simplify and cleanup the sysfs code a bit. [m.chehab@samsung.com: rebased and fixed a CodingStyle issue] Signed-off-by:
David Härdeman <david@hardeman.nu> Signed-off-by:
Mauro Carvalho Chehab <m.chehab@samsung.com>
-
David Härdeman authored
This driver codes the two address bytes in reverse order when compared to the other drivers, so make it consistent (and update the keymap, note that the result is a prefix change from 0x6b86 -> 0x866b, and the latter is pretty common among the NECX keymaps. While not conclusive, it's still a strong hint that the change is correct). Signed-off-by:
-
David Härdeman authored
Right now the protocol information is not preserved, rc-core gets handed a scancode but has no idea which protocol it corresponds to. This patch (which required reading through the source/keymap for all drivers, not fun) makes the protocol information explicit which is important documentation and makes it easier to e.g. support multiple protocols with one decoder (think rc5 and rc-streamzap). The information isn't used yet so there should be no functional changes. [m.chehab@samsung.com: rebased, added cxusb and removed bad whitespacing] Signed-off-by:
-
David Härdeman authored
the RC RX packet is defined as: struct dib0700_rc_response { ... u8 not_system; u8 system; ... u8 data; u8 not_data; The NEC protocol transmits in the order: system not_system data not_data Note that the code defines the NEC extended scancode as: scancode = be16_to_cpu(poll_reply->system16) << 8 | poll_reply->data; i.e. scancode = poll_reply->not_system << 16 | poll_reply->system << 8 | poll_reply->data; Which, if the order *is* reversed, would mean that the scancode that gets defined is in reality: scancode = poll_reply->system << 16 | poll_reply->not_system << 8 | poll_reply->data; Which is the same as the order used in drivers/media/rc/ir-nec-decoder.c. This patch changes the code to match my assumption (the generated scancode should, however, not change). [m.chehab@samsung.com: rebased and fixed the decoding error message] Signed-off-by:
-
- 23 Jul, 2014 24 commits
-
-
David Härdeman authored
The arguments used for ir-kbd-i2c's get_key() functions are not really suited for rc-core and the ir_raw/ir_key distinction is just confusing. Convert all of them to return a protocol/scancode/toggle triple instead. Signed-off-by:
-
David Härdeman authored
The bt8xx driver does RC5 decoding for Nebula digi hardware, but includes some pointless limitations (both start bits must be one, the device/address/system must be 0x00). Remove those limitations and update the keymap to use the full RC5 scancode (fortunately the 0x00 address means that this is perfectly backwards compatible). Signed-off-by:
-
Daeseok Youn authored
"ir" is already checked before calling unregister_from_lirc(). Signed-off-by:
Daeseok Youn <daeseok.youn@gmail.com> Reviewed-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
As reported by Vincent: [ 16.332247] xc2028 0-0061: Loading firmware for type=BASE F8MHZ (3), id 0000000000000000. [ 16.344378] cxusb: i2c wr: len=64 is too big! 64 bytes is too short for firmware load on this device. So, increase it to 80 bytes. Reported-by:
Vincent McIntyre <vincent.mcintyre@gmail.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
The DocBook documentation is incorrect: on ISDB-T, interleaving time is always a power of 2. Fix it and provides a table showing the actual interleaving length for each mode. Signed-off-by: -
Mauro Carvalho Chehab authored
The programmed frequency on xc4000 is not the middle frequency, but the initial frequency on the bandwidth range. However, the DVB API works with the middle frequency. This works fine on set_frontend, as the device calculates the needed offset. However, at get_frequency(), the returned value is the initial frequency. That's generally not a big problem on most drivers, however, starting with changeset 6fe1099c, the frequency drift is taken into account at dib7000p driver. This broke support for PCTV 340e, with uses dib7000p demod and xc4000 tuner. Cc: stable@vger.kernel.org Signed-off-by:
-
Mauro Carvalho Chehab authored
The programmed frequency on xc5000 is not the middle frequency, but the initial frequency on the bandwidth range. However, the DVB API works with the middle frequency. Cc: stable@vger.kernel.org Signed-off-by: -
Mauro Carvalho Chehab authored
This meta-tag is used by some distros to help them package the firmware and generate proper initrd images. So, add the firmware names there. Signed-off-by: -
Mauro Carvalho Chehab authored
The firmware name at: http://www.kernellabs.com/firmware/xc4000/ Is different from the one at the Kernel. Update it try first the new name, falling back to the previous one if the new name can't be found. Signed-off-by:
-
Himangi Saraogi authored
This patch removes the null test on ch. ch is initialized at the beginning of the function to &demod->dtv_property_cache. Since demod is dereferenced prior to the null test, demod must be a valid pointer, and &demod->dtv_property_cache cannot be null. The following Coccinelle script is used for detecting the change: @r@ expression e,f; identifier g,y; statement S1,S2; @@ *e = &f->g <+... f->y ...+> *if (e != NULL || ...) S1 else S2 Signed-off-by:
Himangi Saraogi <himangi774@gmail.com> Acked-by:
Julia Lawall <julia.lawall@lip6.fr> Signed-off-by:
-
Mauro Carvalho Chehab authored
Instead of looking at the guard interval field, it was using the interval length, with is wrong. Fix it. Signed-off-by: -
Mauro Carvalho Chehab authored
Interleaving code was wrong at mb86a20s: instead, it was looking at the Guard Interval. Fix it. Signed-off-by: -
Mauro Carvalho Chehab authored
The driver was reporting an incorrect mode, when mode 2 is selected. While testing it, noticed that neither mode 1 or guard interval 1/32 is supported by this device. Document it, and ensure that it will report _AUTO when it doesn't lock, in order to not report a wrong detection to userspace. Signed-off-by: -
Antti Palosaari authored
Implement read_ber for BER estimate. Signed-off-by:
Antti Palosaari <crope@iki.fi> Signed-off-by:
-
Antti Palosaari authored
There was 32-bit calculation overflow. Use div_u64. Signed-off-by:
-
Fabian Frederick authored
Signed-off-by:
Fabian Frederick <fabf@skynet.be> Signed-off-by:
-
Fabian Frederick authored
Signed-off-by:
-
Fabian Frederick authored
Cc: Antti Palosaari <crope@iki.fi> Signed-off-by:
-
Fabian Frederick authored
Signed-off-by:
-
Fabian Frederick authored
Cc: Antti Palosaari <crope@iki.fi> Cc: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
-
Emil Goode authored
This cleans up some line over 80 character violations. Signed-off-by:
Emil Goode <emilgoode@gmail.com> Signed-off-by:
-
Emil Goode authored
This removes checks of struct member addresses since they likely result in the condition always being true. Also in the stb6100_get_bandwidth and tda8261_get_bandwidth functions the pointers frontend_ops and tuner_ops are assigned the same addresses twice. Signed-off-by:
-
Heinrich Schuchardt authored
This updated patch also fixes out of bound access to b[]. In dib9000_risc_apb_access_write() an out of bound access to mb[]. The current test to avoid out of bound access to mb[] is insufficient. For len = 19 non-existent mb[10] will be accessed. For odd values of len b[] is accessed out of bounds. For large values of len an of bound access to mb[] may occur in dib9000_mbx_send_attr. Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Dan Carpenter authored
>From the context this should be hex 0x80 instead of decimal 80. Signed-off-by:
-
- 22 Jul, 2014 12 commits
-
-
Mauro Carvalho Chehab authored
changeset a733291d didn't merge the fixes well. It ended by restoring some bad logic removed there. Signed-off-by:
-
Mauro Carvalho Chehab authored
As reported by Kbuildtest: warning: (VIDEO_PVRUSB2 && VIDEO_TLG2300 && VIDEO_USBVISION && VIDEO_GO7007 && VIDEO_AU0828_V4L2 && VIDEO_CX231XX && VIDEO_TM6000 && VIDEO_EM28XX && VIDEO_IVTV && VIDEO_MXB && VIDEO_CX18 && VIDEO_CX23885 && VIDEO_CX88 && VIDEO_BT848 && VIDEO_SAA7134 && VIDEO_SAA7164) selects VIDEO_TUNER which has unmet direct dependencies (MEDIA_SUPPORT && MEDIA_TUNER) That happens when: # CONFIG_MEDIA_ANALOG_TV_SUPPORT is not set CONFIG_MEDIA_DIGITAL_TV_SUPPORT=y # CONFIG_MEDIA_RADIO_SUPPORT is not set # CONFIG_MEDIA_SDR_SUPPORT is not set CONFIG_VIDEO_AU0828_V4L2=y CONFIG_VIDEO_CX231XX=y CONFIG_VIDEO_TM6000=y CONFIG_VIDEO_EM28XX=y CONFIG_VIDEO_TUNER=y CONFIG_MEDIA_SUPPORT=y With means that we need to enable MEDIA_TUNER also when DTV is enabled. While the above config doesn't cover, if we enable SDR, the same error can also happen. Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
-
Hans Verkuil authored
Now that the custom motion detection API in this driver has been replaced with a standard API there is no reason anymore to keep it in staging. So (finally!) move it to drivers/media/usb. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Hans Verkuil authored
Now that the custom motion detection API has been replaced with a standard API there is no reason anymore to keep it in staging. So (finally!) move it to drivers/media/pci. Signed-off-by:
-
Philipp Zabel authored
Similarly to workbuf_size and tempbuf_size, store iram_size in the coda_devtype structure. This also decreases the IRAM used on i.MX6DL to 128 KiB. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
Kamil Debski <k.debski@samsung.com> Signed-off-by:
-
Philipp Zabel authored
Similarly to the work buffer size, store the temporary buffer size in the coda_devtype structure. Signed-off-by:
-
Philipp Zabel authored
We had the workbuf_size field since the beginning. Use it to tighten the code a little bit. Signed-off-by:
-
Philipp Zabel authored
This patch exports all auxiliary buffers, including SRAM, as debugfs binary blobs for debugging purposes. It shows, for example, that psbuf currently doesn't seem to be used at all on CODA7541, and that slicebuf and workbuf usage is far from the maximum. It can also be used to validate SRAM size allocation. Signed-off-by:
-
Philipp Zabel authored
When encoding into h.264, the input frame stride needs to be a multiple of 16. During allocation of the input buffers, it may not be known yet whether the encoder should create h.264 or not. Assume the worst and always use a frame stride that is a multiple of 16. Signed-off-by:
-
Philipp Zabel authored
CODA7541 only supports encoding h.264 frames with width and height that are multiples of the macroblock size. Signed-off-by:
-
Philipp Zabel authored
Even though the CODA h.264 decoder always decodes complete macroblocks, we can set the stride to the corresponding multiple of 16 and use a value smaller than that as real width. Unfortunately the same doesn't work for height, as there is no vertical linesperframe stride for discontiguous planar YUV frames. Signed-off-by:
-
Philipp Zabel authored
bytesperline is calculated in multiple places, store it in the coda_q_data structure. This will be more useful later when adding JPEG support. Signed-off-by:
-
