Eric Lee / smarc-fsl-linux-kernel

12 Aug, 2015

1 commit

25 Nov, 2014

1 commit

26 Jul, 2014

1 commit

  • c5540fbb9   [media] rc-core: remove protocol arrays ... Browse Code »

    The basic API of rc-core used to be:

    dev = rc_allocate_device();
    dev->x = a;
    dev->y = b;
    dev->z = c;
    rc_register_device();

    which is a pretty common pattern in the kernel, after the introduction of
    protocol arrays the API looks something like:

    dev = rc_allocate_device();
    dev->x = a;
    rc_set_allowed_protocols(dev, RC_BIT_X);
    dev->z = c;
    rc_register_device();

    There's no real need for the protocols to be an array, so change it
    back to be consistent (and in preparation for the following patches).

    [m.chehab@samsung.com: added missing changes at some files]
    Signed-off-by: David Härdeman
    Signed-off-by: Mauro Carvalho Chehab

    David Härdeman
     

24 Jul, 2014

2 commits

  • 120703f9e   [media] rc-core: document the protocol type ... Browse Code »

    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
    Signed-off-by: Mauro Carvalho Chehab

    David Härdeman
     
  • 4dd9bb91b   [media] rc-core: improve ir-kbd-i2c get_key functions ... Browse Code »

    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
    Signed-off-by: Mauro Carvalho Chehab

    David Härdeman
     

12 Mar, 2014

1 commit

  • 1a1934fab   [media] rc: abstract access to allowed/enabled protocols ... Browse Code »

    The allowed and enabled protocol masks need to be expanded to be per
    filter type in order to support wakeup filter protocol selection. To
    ease that process abstract access to the rc_dev::allowed_protos and
    rc_dev::enabled_protocols members with inline functions.

    Signed-off-by: James Hogan
    Reviewed-by: Antti Seppälä
    Signed-off-by: Mauro Carvalho Chehab

    James Hogan
     

30 Nov, 2013

1 commit

  • 39c1cb2b1   [media] media_tree: Fix spelling errors ... Browse Code »

    Fix various spelling errors in strings and comments throughout the media
    tree. The majority of these were found using Lucas De Marchi's codespell
    tool.

    [m.chehab@samsung.com: discard hunks with conflicts]

    Signed-off-by: Jonathan McCrohan
    Signed-off-by: Hans Verkuil
    Signed-off-by: Mauro Carvalho Chehab

    Jonathan McCrohan
     

21 May, 2013

1 commit

  • c02b211df   [media] media: i2c: Convert to devm_kzalloc() ... Browse Code »

    Using the managed function the kfree() calls can be removed from the
    probe error path and the remove handler.

    Signed-off-by: Laurent Pinchart
    Acked-by: Sylwester Nawrocki
    Acked-by: Lad, Prabhakar
    Acked-by: Andy Shevchenko
    Reviewed-by: Benoît Thébaudeau
    Signed-off-by: Mauro Carvalho Chehab

    Laurent Pinchart
     

08 Apr, 2013

1 commit

23 Mar, 2013

1 commit

  • 9719afae5   [media] rc-core: don't treat dev->rc_map.rc_type as a bitmap ... Browse Code »

    store_protocols() treats dev->rc_map.rc_type as a bitmap which is wrong for
    two reasons. First of all, it is pretty bogus to change the protocol type of
    the keymap just because the hardware has been asked to decode a different
    protocol.
    Second, dev->rc_map.rc_type is an enum (i.e. a single protocol) as pointed
    out by James Hogan .
    Fix both issues by introducing a separate enabled_protocols member to
    struct rc_dev.

    Signed-off-by: David Härdeman
    Signed-off-by: Mauro Carvalho Chehab

    David Härdeman
     

27 Oct, 2012

1 commit

  • c003ab1be   [media] rc-core: add separate defines for protocol bitmaps and numbers ... Browse Code »

    The RC_TYPE_* defines are currently used both where a single protocol is
    expected and where a bitmap of protocols is expected.

    Functions like rc_keydown() and functions which add/remove entries to the
    keytable want a single protocol. Future userspace APIs would also
    benefit from numeric protocols (rather than bitmap ones). Keytables are
    smaller if they can use a small(ish) integer rather than a bitmap.

    Other functions or struct members (e.g. allowed_protos,
    enabled_protocols, etc) accept multiple protocols and need a bitmap.

    Using different types reduces the risk of programmer error. Using a
    protocol enum whereever possible also makes for a more future-proof
    user-space API as we don't need to worry about a sufficient number of
    bits being available (e.g. in structs used for ioctl() calls).

    The use of both a number and a corresponding bit is dalso one in e.g.
    the input subsystem as well (see all the references to set/clear bit when
    changing keytables for example).

    This patch separate the different usages in preparation for
    upcoming patches.

    Where a single protocol is expected, enum rc_type is used; where one or more
    protocol(s) are expected, something like u64 is used.

    The patch has been rewritten so that the format of the sysfs "protocols"
    file is no longer altered (at the loss of some detail). The file itself
    should probably be deprecated in the future though.

    Signed-off-by: David Härdeman
    Cc: Andy Walls
    Cc: Maxim Levitsky
    Cc: Antti Palosaari
    Cc: Mike Isely
    Signed-off-by: Mauro Carvalho Chehab

    David Härdeman
     

16 Aug, 2012

1 commit