Doug / smarc-fsl-linux-kernel

05 Jun, 2013

4 commits

23 May, 2013

3 commits

  • 927b4dc3e   iio: exynos_adc: fix wrong structure extration in suspend and resume ... Browse Code »

    The exynos_adc device structure was wrongly extracted from the dev*
    correcting the same.

    Using the regular conversion of
    struct device* -> struct platform_device* -> struct exynos_adc* seems wrong.
    Instead we should be doing
    struct device* -> struct iio_dev* -> struct exynos_adc*

    Signed-off-by: Naveen Krishna Chatradhi
    Reviewed-by: Doug Anderson
    Signed-off-by: Jonathan Cameron

    Naveen Krishna Chatradhi
     
  • d61a04dc1   iio:common:st: added disable function after read info raw data ... Browse Code »

    Signed-off-by: Denis Ciocca
    Signed-off-by: Jonathan Cameron

    Denis CIOCCA
     
  • 0ae5fb6fd   iio: dac: Fix build error when CONFIG_SPI_MASTER=y && CONFIG_I2C=m ... Browse Code »

    This patch fixes below build error when CONFIG_SPI_MASTER=y && CONFIG_I2C=m:

    drivers/built-in.o: In function `ad5064_i2c_write':
    drivers/iio/dac/ad5064.c:608: undefined reference to `i2c_master_send'
    drivers/built-in.o: In function `ad5064_i2c_register_driver':
    drivers/iio/dac/ad5064.c:646: undefined reference to `i2c_register_driver'
    drivers/built-in.o: In function `ad5064_i2c_unregister_driver':
    drivers/iio/dac/ad5064.c:651: undefined reference to `i2c_del_driver'
    make: *** [vmlinux] Error 1

    When CONFIG_I2C=m, meaning we can't build the drivers in with I2C support.
    Thus don't allow the drivers to be compiled as built-in when CONFIG_I2C=m.

    The real fix though is to break the driver apart into a SPI part, an I2C part
    and a common part. But that's something for 3.11 while this is something for
    3.10/stable.

    Reported-by: Wu Fengguang
    Reported-by: Randy Dunlap
    Signed-off-by: Axel Lin
    Acked-by: Lars-Peter Clausen
    Signed-off-by: Jonathan Cameron

    Axel Lin
     

03 Apr, 2013

4 commits

29 Mar, 2013

1 commit

26 Mar, 2013

2 commits

  • 1e9663c62   iio:trigger: Introduce iio_tigger_{set,get}_drvdata ... Browse Code »

    Introduce iio_tigger_{set,get}_drvdata which allows to attach driver specific
    data to a trigger. The functions wrap access to the triggers private_data field
    and all current users are updated to use iio_tigger_{set,get}_drvdata instead of
    directly accessing the private_data field. This is the first step towards
    removing the private_data field from the iio_trigger struct.

    The following coccinelle script has been used to update the drivers:

    @@
    struct iio_trigger *trigger;
    expression priv;
    @@
    -trigger->private_data = priv
    +iio_trigger_set_drv_data(trigger, priv)

    @@
    struct iio_trigger *trigger;
    @@
    -trigger->private_data
    +iio_trigger_get_drv_data(trigger)

    Signed-off-by: Lars-Peter Clausen
    Signed-off-by: Jonathan Cameron

    Lars-Peter Clausen
     
  • ef994fda4   Merge tag 'iio-for-3.10a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23… ... Browse Code »

    …/iio into staging-next

    Jonathan writes:

    First set of IIO new drivers and cleanup for the 3.10 cycle.

    New stuff

    1) Add OF support for specifying mappings between iio devices and their
    in kernel consumers.
    2) Driver for AD7923 (extra functionality and support for ad7904, ad7914 and
    ad7924 added later in series)
    3) Driver for Exynos adc (dt suppor for phy added later in series).
    4) Make iio_push_event save IRQ context - necessary if it is to be used
    within an interrupt handler. Users of this functionality to follow.
    5) For iio use the device tree node name to provide the hwmon name attribute
    if available.

    Removal and moves out of staging

    1) Drop the adt7410 driver from IIO now that there is a hmwon driver with
    equivalent support. This device is very much targeted at hardware
    monitoring so hwmon is a more appropriate host for the driver.
    2) Move iio_hwmon driver to drivers/hwmon.

    Cleanups

    1) Minor cleanup in ST common library.
    2) Large set of patches to break the info_mask element which previously used
    odd and even bits to specify if a channel attribute was either shared across
    similar channels or specific to only one. Now we have two bitmaps, one for
    those parameters that are specific to this channel and one for those shared
    by all channels with the same type as this one. This has no effect on the
    userspace abi. It simplifies the core code and provides more space for new
    channel parameters. It has been on the todo list for a long time!

    Conflicts:
    drivers/iio/dac/ad5064.c

    Greg Kroah-Hartman
     

18 Mar, 2013

26 commits