Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 27 7月, 2014 4 次提交
  3. 26 7月, 2014 10 次提交
  5. 24 7月, 2014 3 次提交
    • D
      [media] rc-core: document the protocol type · 120703f9
      由 David Härdeman 提交于 
      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: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      120703f9
    • D
      [media] dib0700: NEC scancode cleanup · af3a4a9b
      由 David Härdeman 提交于 
      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: NDavid Härdeman <david@hardeman.nu>
CC: Patrick Boettcher <pboettcher@kernellabs.com>
Tested-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      af3a4a9b
    • D
      [media] rc-core: improve ir-kbd-i2c get_key functions · 4dd9bb91
      由 David Härdeman 提交于 
      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: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      4dd9bb91
  7. 23 7月, 2014 1 次提交
  9. 22 7月, 2014 17 次提交
  11. 18 7月, 2014 2 次提交
  13. 17 7月, 2014 2 次提交
    • L
      [media] v4l: Support extending the v4l2_pix_format structure · d52e2381
      由 Laurent Pinchart 提交于 
      The v4l2_pix_format structure has no reserved field. It is embedded in
the v4l2_framebuffer structure which has no reserved fields either, and
in the v4l2_format structure which has reserved fields that were not
previously required to be zeroed out by applications.

To allow extending v4l2_pix_format, inline it in the v4l2_framebuffer
structure, and use the priv field as a magic value to indicate that the
application has set all v4l2_pix_format extended fields and zeroed all
reserved fields following the v4l2_pix_format field in the v4l2_format
structure.

The availability of this API extension is reported to userspace through
the new V4L2_CAP_EXT_PIX_FORMAT capability flag. Just checking that the
priv field is still set to the magic value at [GS]_FMT return wouldn't
be enough, as older kernels don't zero the priv field on return.

To simplify the internal API towards drivers zero the extended fields
and set the priv field to the magic value for applications not aware of
the extensions.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      d52e2381
    • H
      [media] Fix 64-bit division fall-out from 64-bit control ranges · 0d5e8c43
      由 Hans Verkuil 提交于 
      Commit 0ba2aeb6 increased the internal control ranges
to 64 bit, but that caused problems in drivers that use the minimum/maximum/step/default_value
control values in a division or modulus operations since not all architectures support
those natively.

Luckily, in almost all cases it is possible to just cast to 32 bits (the control value
is known to be 32 bits, so it is safe to cast). Only in v4l2-ctrls.c was it necessary to
use do_div in one function.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      0d5e8c43
  15. 15 7月, 2014 1 次提交