01 Feb, 2016

1 commit

  • This is a partial revert of commit ed8d1cf07cb16d ("[media] Export I2C
    module alias information in missing drivers") that exported the module
    aliases for the I2C drivers that were missing to make autoload to work.

    But there is a bug report [0] that auto load of the ir-kbd-i2c driver
    cause the Hauppauge HD-PVR driver to not behave correctly.

    This is a hdpvr latent bug that was just exposed by ir-kbd-i2c module
    autoloading working and will also happen if the I2C driver is built-in
    or a user calls modprobe to load the module and register the driver.

    But there is a regression experimented by users so until the real bug
    is fixed, let's not export the module alias for the ir-kbd-i2c driver
    even when this just masks the actual issue.

    [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810726

    Fixes: ed8d1cf07cb1 ("[media] Export I2C module alias information in missing drivers")

    Cc: # 4.3+
    Signed-off-by: Javier Martinez Canillas

    Javier Martinez Canillas
     

17 Nov, 2015

1 commit

  • Currently, include/media is messy, as it contains both the V4L2 core
    headers and some driver-specific headers on the same place. That makes
    harder to identify what core headers should be documented and what
    headers belong to I2C drivers that are included only by bridge/main
    drivers that would require the functions provided by them.

    Let's move those i2c specific files to its own subdirectory.

    The files to move were produced via the following script:
    mkdir include/media/i2c
    (cd include/media; for i in *.h; do n=`echo $i|sed s/.h$/.c/`; if [ -e ../../drivers/media/i2c/$n ]; then echo $i; git mv $i i2c/; fi; done)
    (cd include/media; for i in *.h; do n=`echo $i|sed s/.h$/.c/`; if [ -e ../../drivers/media/*/i2c/$n ]; then echo $i; git mv $i i2c/; fi; done)
    for i in include/media/*.h; do n=`basename $i`; (for j in $(git grep -l $n); do dirname $j; done)|sort|uniq|grep -ve '^.$' > list; num=$(wc -l list|cut -d' ' -f1); if [ $num == 1 ]; then if [ "`grep i2c list`" != "" ]; then git mv $i include/media/i2c; fi; fi; done

    And the references corrected via this script:
    MAIN_DIR="media/"
    PREV_DIR="media/"
    DIRS="i2c/"

    echo "Checking affected files" >&2
    for i in $DIRS; do
    for j in $(find include/$MAIN_DIR/$i -type f -name '*.h'); do
    n=`basename $j`
    git grep -l $n
    done
    done|sort|uniq >files && (
    echo "Handling files..." >&2;
    echo "for i in \$(cat files|grep -v Documentation); do cat \$i | \\";
    (
    cd include/$MAIN_DIR;
    for j in $DIRS; do
    for i in $(ls $j); do
    echo "perl -ne 's,(include [\\\"\\&2;
    echo "for i in MAINTAINERS \$(cat files); do cat \$i | \\";
    (
    cd include/$MAIN_DIR;
    for j in $DIRS; do
    for i in $(ls $j); do
    echo " perl -ne 's,include/$PREV_DIR($i)\b,include/$MAIN_DIR$j\1,; print \$_' |\\";
    done;
    done;
    echo "cat > a && mv a \$i; done"
    );
    ) >script && . ./script

    Merged Sakari Ailus patch that moves smiapp.h to include/media/i2c.

    Signed-off-by: Mauro Carvalho Chehab
    Acked-by: Arnd Bergmann

    Mauro Carvalho Chehab
     

12 Aug, 2015

1 commit


25 Nov, 2014

1 commit


26 Jul, 2014

1 commit

  • 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

  • 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
     
  • 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

  • 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

  • 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

  • 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

  • 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

  • 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