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

8 commits


23 Oct, 2008

3 commits


11 Aug, 2008

1 commit

  • In kernel 2.6.26, the ability to select I2C algorithm drivers manually
    was removed, as all in-kernel drivers do that automatically. However
    there were some complaints that it was a problem for out-of-tree I2C
    bus drivers. In order to address these complaints, let's allow manual
    selection of these drivers again, but still hide them by default for
    better general user experience.

    This closes bug #11140:
    http://bugzilla.kernel.org/show_bug.cgi?id=11140

    Signed-off-by: Jean Delvare

    Jean Delvare
     

15 Jul, 2008

3 commits

  • Improve lost-arbitration handling of PCF8584. This is necessary for
    support of a currently out-of-kernel driver for Sun Microsystems E250
    environmental management; perhaps others.

    Signed-off-by: Eric Brower
    Acked-by: Dan Smolik
    Signed-off-by: Jean Delvare

    Eric Brower
     
  • Give a more concrete error code, when the bus is not idle.

    Signed-off-by: Wolfram Sang
    Signed-off-by: Jean Delvare

    Wolfram Sang
     
  • Tighten error paths used by various i2c adapters (mostly x86) so
    they return real fault/errno codes instead of a "-1" (which is
    most often interpreted as "-EPERM"). Build tested, with eyeball
    review.

    One minor initial goal is to have adapters consistently return
    the code "-ENXIO" when addressing a device doesn't get an ACK
    response, at least in the probe paths where they are already
    good at stifling related logspam.

    Signed-off-by: David Brownell
    Signed-off-by: Jean Delvare

    David Brownell
     

23 Apr, 2008

2 commits

  • The separation between algorithm and adapter was unsharp at places. This was
    partly hidden by the fact, that the ISA-driver allowed just one instance and
    had all private data in static variables. This patch makes neccessary
    preparations to add a platform driver on top of the algorithm, while still
    supporting ISA. Note: Due to lack of hardware, the ISA-driver could not be
    tested except that it builds.

    Concerning the core struct i2c_algo_pca_data:

    - A private data field was added, all hardware dependant data may go here.
    Similar to other algorithms, now a pointer to this data is passed to the
    adapter's functions. In order to make as less changes as possible to the
    ISA-driver, it leaves the private data empty and still only uses its static
    variables.

    - A "reset_chip" function pointer was added; such a functionality must come
    from the adapter, not the algorithm.

    - use a variable "i2c_clock" instead of a function pointer "get_clock",
    allowing for write access to a default in case a wrong value was supplied.

    In the algorithm-file:

    - move "i2c-pca-algo.h" into "linux/i2c-algo-pca.h"
    - now using per_instance timeout values (i2c_adap->timeout)
    - error messages specify the device, not only the driver name
    - restructure initialization to easily support "i2c_add_numbered_adapter"
    - drop "retries" and "own" (i2c address) as they were unused

    (The state-machine for I2C-communication was not touched.)

    In the ISA-driver:

    - adapt to new algorithm

    Signed-off-by: Wolfram Sang
    Signed-off-by: Jean Delvare

    Wolfram Sang
     
  • Remove trailing whitespaces to make further patches more readable. Also remove
    an unnecessary UTF-char for simplicity ("us" for microseconds is fine enough).

    Signed-off-by: Wolfram Sang
    Signed-off-by: Jean Delvare

    Wolfram Sang