01 Dec, 2015

1 commit


01 Jun, 2015

1 commit


08 Nov, 2014

1 commit


30 Jan, 2014

2 commits

  • Pull more i2c updates from Wolfram Sang:
    "Mostly bugfixes, small but wanted cleanups, and Paul's init.h removal
    applied"

    * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
    i2c: rcar: fix NACK error code
    i2c: update i2c_algorithm documentation
    i2c: rcar: use devm_clk_get to ensure clock is properly ref-counted
    i2c: rcar: do not print error if device nacks transfer
    i2c: rely on driver core when sanitizing devices
    i2c: delete non-required instances of include
    i2c: acorn: is tristate and should use module.h
    i2c: piix4: Standardize log messages
    i2c: piix4: Use different message for AMD Auxiliary SMBus Controller
    i2c: piix4: Add support for AMD ML and CZ SMBus changes

    Linus Torvalds
     
  • Signed-off-by: Jean Delvare

    Jean Delvare
     

25 Jan, 2014

1 commit


08 Oct, 2012

1 commit


06 Oct, 2012

1 commit

  • The parameter passed to pca9665_reset is adap->data (which is bus driver
    specific), not i2c_algp_pca_data *adap. pca9665_reset expects it to be
    i2c_algp_pca_data *adap. All other wrappers from the algo call back to
    the bus driver, which knows to handle its custom data. Only pca9665_reset
    resides inside the algorithm code and does not know how to handle a custom
    data structure. This can result in a kernel crash.

    Fix by re-factoring pca_reset() from a macro to a function handling chip
    specific code, and only call adap->reset_chip() if the chip is not PCA9665.

    Signed-off-by: Thomas Kavanagh
    Signed-off-by: Guenter Roeck
    Signed-off-by: Wolfram Sang

    Thomas Kavanagh
     

14 Sep, 2012

1 commit

  • The code currently always selects turbo mode for PCA9665, no matter which
    clock frequency is configured. This is because it compares the clock frequency
    against constants reflecting (boundary / 100). Compare against real boundary
    frequencies to fix the problem.

    Signed-off-by: Thomas Kavanagh
    Signed-off-by: Guenter Roeck
    Signed-off-by: Wolfram Sang

    Thomas Kavanagh
     

30 May, 2012

1 commit

  • Since there are uses for I2C_M_NOSTART which are much more sensible and
    standard than most of the protocol mangling functionality (the main one
    being gather writes to devices where something like a register address
    needs to be inserted before a block of data) create a new I2C_FUNC_NOSTART
    for this feature and update all the users to use it.

    Also strengthen the disrecommendation of the protocol mangling while we're
    at it.

    In the case of regmap-i2c we remove the requirement for mangling as
    I2C_M_NOSTART is the only mangling feature which is being used.

    Signed-off-by: Mark Brown
    Acked-by: Wolfram Sang
    Signed-off-by: Jean Delvare

    Mark Brown
     

27 Mar, 2012

2 commits

  • Clock stretching is not supposed to last long, so asking to be
    rescheduled while waiting for the clock line to be released by a slave
    makes little sense. Odds are that the clock line will long have been
    released when we run again, so we will have lost time and may even
    get an SMBus timeout because of this.

    So just busy-wait in that case. This also participates in the effort
    to make i2c-algo-bit usable in contexts that can't sleep.

    Signed-off-by: Jean Delvare
    Cc: Ben Skeggs

    Jean Delvare
     
  • Signed-off-by: Jean Delvare

    Jean Delvare
     

23 Mar, 2012

1 commit

  • Pull drm main changes from Dave Airlie:
    "This is the main drm pull request, I'm probably going to send two more
    smaller ones, will explain below.

    This contains a patch that is also in the fbdev tree, but it should be
    the same patch, it added an API for hot unplugging framebuffer
    devices, and I need that API for a new driver.

    It also contains some changes to the i2c tree which Jean has acked,
    and one change to moorestown platform stuff in x86.

    Highlights:
    - new drivers: UDL driver for USB displaylink devices, kms only,
    should support correct hotplug operations.
    - core: i2c speedups + better hotplug support, EDID overriding via
    firmware interface - allows user to load a firmware for a broken
    monitor/kvm from userspace, it even has documentation for it.
    - exynos: new HDMI audio + hdmi 1.4 + virtual output driver
    - gma500: code cleanup
    - radeon: cleanups, CS optimisations, streamout support and pageflip
    fix
    - nouveau: NVD9 displayport support + more reclocking work
    - i915: re-enabling GMBUS, finish gpu patch (might help hibernation
    who knows), missed irq fixes, stencil tiling fixes, interlaced
    support, aliasesd PPGTT support for SNB/IVB, swizzling for SNB/IVB,
    semaphore fixes

    As well as the usual bunch of cleanups and fixes all over the place.

    I've got two things I'd like to merge a bit later:

    a) AMD support for all their new radeonhd 7000 series GPU and APUs.
    AMD dropped this a bit late due to insane internal review
    processes, (please AMD just follow Intel and let open source guys
    ship stuff early) however I don't want to penalise people who own
    this hardware (since its been on sale for 3-4 months and GPU hw
    doesn't exactly have a lifetime in years) and consign them to
    using closed drivers for longer than necessary. The changes are
    well contained and just plug into the driver new gpu functionality
    so they should be fairly regression proof. I just want to give
    them a bit of a run on the hw AMD kindly sent me.

    b) drm prime/dma-buf interface code. This is just infrastructure
    code to expose the dma-buf stuff to drm drivers and to userspace.
    I'm not planning on pushing any driver support in this cycle
    (except maybe exynos), but I'd like to get the infrastructure code
    in so for the next cycle I can start getting the driver support
    into the individual drivers. We have started driver support for
    i915, nouveau and udl along with I think exynos and omap in
    staging. However this code relies on the dma-buf tree being
    pulled into your tree first since it needs the latest interfaces
    from that tree. I'll push to get that tree sent asap.

    (oh and any warnings you see in i915 are gcc's fault from what anyone
    can see)."

    Fix up trivial conflicts in arch/x86/platform/mrst/mrst.c due to the new
    msic_thermal_platform_data() thermal function being added next to the
    tc35876x_platform_data() i2c device function..

    * 'drm-next' of git://people.freedesktop.org/~airlied/linux: (326 commits)
    drm/i915: use DDC_ADDR instead of hard-coding it
    drm/radeon: use DDC_ADDR instead of hard-coding it
    drm: remove unneeded redefinition of DDC_ADDR
    drm/exynos: added virtual display driver.
    drm: allow loading an EDID as firmware to override broken monitor
    drm/exynos: enable hdmi audio feature
    drm/exynos: add default pixel format for plane
    drm/exynos: cleanup exynos_hdmi.h
    drm/exynos: add is_local member in exynos_drm_subdrv struct
    drm/exynos: add subdrv open/close functions
    drm/exynos: remove module of exynos drm subdrv
    drm/exynos: release pending pageflip events when closed
    drm/exynos: added new funtion to get/put dma address.
    drm/exynos: update gem and buffer framework.
    drm/exynos: added mode_fixup feature and code clean.
    drm/exynos: add HDMI version 1.4 support
    drm/exynos: remove exynos_mixer.h
    gma500: Fix mmap frambuffer
    drm/radeon: Drop radeon_gem_object_(un)pin.
    drm/radeon: Restrict offset for legacy display engine.
    ...

    Linus Torvalds
     

16 Mar, 2012

1 commit

  • When the system is under heavy load, there can be a significant delay
    between the getscl() and time_after() calls inside sclhi(). That delay
    may cause the time_after() check to trigger after SCL has gone high,
    causing sclhi() to return -ETIMEDOUT.

    To fix the problem, double check that SCL is still low after the
    timeout has been reached, before deciding to return -ETIMEDOUT.

    Signed-off-by: Ville Syrjala
    Cc: stable@vger.kernel.org
    Signed-off-by: Jean Delvare

    Ville Syrjala
     

01 Mar, 2012

1 commit

  • i915 has a hw i2c controller (gmbus) but for a bunch of stupid reasons
    we need to be able to fall back to the bit-banging algo on gpio pins.

    The current code sets up a 2nd i2c controller for the same i2c bus using
    the bit-banging algo. This has a bunch of issues, the major one being
    that userspace can directly access this fallback i2c adaptor behind
    the drivers back.

    But we need to frob a few registers before and after using fallback
    gpio bit-banging, so this horribly fails.

    The new plan is to only set up one i2c adaptor and transparently fall
    back to bit-banging by directly calling the xfer function of the bit-
    banging algo in the i2c core.

    To make that possible, export the 2 i2c algo functions.

    v2: As suggested by Jean Delvare, simply export the i2c_bit_algo
    vtable instead of the individual functions.

    Acked-by: Jean Delvare
    Signed-off-by: Daniel Vetter

    Daniel Vetter
     

23 Nov, 2011

1 commit


30 Oct, 2011

4 commits


17 Apr, 2011

1 commit

  • Apparently some distros set i2c-algo-bit.bit_test to 1 by
    default. In some cases this causes i2c_bit_add_bus
    to fail and prevents the i2c bus from being added. In the
    radeon case, we fail to add the ddc i2c buses which prevents
    the driver from being able to detect attached monitors.
    The i2c bus works fine even if bit_test fails. This is likely
    due to gpio switching that is required and handled in the
    pre/post_xfer hooks, so call the pre/post_xfer hooks in the
    bit test as well.

    Fixes:
    https://bugs.freedesktop.org/show_bug.cgi?id=36221

    Signed-off-by: Alex Deucher
    Signed-off-by: Jean Delvare
    Cc: stable@kernel.org [.38 down to .34]

    Alex Deucher
     

31 Mar, 2011

1 commit


11 Jan, 2011

2 commits


22 Nov, 2010

2 commits


25 Oct, 2010

2 commits

  • Replace EXTRA_CFLAGS with ccflags-y.

    Signed-off-by: matt mooney
    Signed-off-by: Jean Delvare

    matt mooney
     
  • drivers/i2c/algos/Kconfig makes all the algorithms dependent on
    !I2C_HELPER_AUTO, which triggers a Kconfig warning about broken
    dependencies when some driver selects one of the algorithms. Ideally
    we would make only the prompts dependent on !I2C_HELPER_AUTO, however
    Kconfig doesn't currently support that. So we have to redefine the
    symbols separately for the I2C_HELPER_AUTO=y case.

    Signed-off-by: Jean Delvare
    Acked-by: Michal Marek

    Jean Delvare
     

22 May, 2010

1 commit

  • Fix up some coding style issues. i2c-algo-pca.c has been built
    successfully after applying this patch and the binary object is
    still exactly the same. Other issues found by checkpatch.pl were
    voluntarily not fixed, either to keep readability, or because of
    false positive errors.

    Signed-off-by: Farid Hammane
    Signed-off-by: Jean Delvare

    Farid Hammane
     

30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

14 Mar, 2010

1 commit


08 Mar, 2010

1 commit


02 Mar, 2010

1 commit


05 Feb, 2010

1 commit


05 May, 2009

2 commits

  • Currently, the i2c-algo-pca driver does nothing if the chip enters state
    0x30 (Data byte in I2CDAT has been transmitted; NOT ACK has been
    received). Thus, the i2c bus connected to the controller gets stuck
    afterwards.

    I have seen this kind of error on a custom board in certain load
    situations most probably caused by interference or noise.

    A possible reaction is to let the controller generate a STOP condition.
    This is documented in the PCA9564 data sheet (2006-09-01) and the same
    is done for other NACK states as well.

    Further, state 0x38 isn't handled completely, either. Try to do another
    START in this case like the data sheet says. As this couldn't be tested,
    I've added a comment to try to reset the chip if the START doesn't help
    as suggested by Wolfram Sang.

    Signed-off-by: Enrik Berkhan
    Reviewed-by: Wolfram Sang
    Signed-off-by: Jean Delvare

    Enrik Berkhan
     
  • When fetching DDC using i2c algo bit, we were often seeing timeouts
    before getting valid EDID on a retry. The VESA spec states 2ms is the
    DDC timeout, so when this translates into 1 jiffie and we are close
    to the end of the time period, it could return with a timeout less than
    2ms.

    Change this code to use time_after instead of time_after_eq.

    Signed-off-by: Dave Airlie
    Signed-off-by: Jean Delvare

    Dave Airlie
     

13 Apr, 2009

1 commit


07 Apr, 2009

1 commit


29 Mar, 2009

2 commits