Replace EXTRA_CFLAGS with ccflags-y.
Signed-off-by: Nmatt mooney <mfm@muteddisk.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

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: NJean Delvare <khali@linux-fr.org>
Acked-by: NMichal Marek <mmarek@suse.cz>

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: NFarid Hammane <farid.hammane@gmail.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit 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: NTejun Heo <tj@kernel.org>
Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

Drivers might have to do random things before and/or after I2C
transfers. Add hooks to the i2c-algo-bit implementation to let them do
so.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Alex Deucher <alexdeucher@gmail.com>

Thanks to -Wshadow.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Reviewed-by: NWolfram Sang <w.sang@pengutronix.de>

Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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: NEnrik Berkhan <Enrik.Berkhan@ge.com>
Reviewed-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

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: NDave Airlie <airlied@redhat.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

A recent change broke debugging of pca_xfer(), fix it.
Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Acked-by: NWolfram Sang <w.sang@pengutronix.de>

The i2c-algo-sgi code was merged into the vino driver, so we can
delete it now.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

We now timeout also if the state machine does not change within the
given time. For that, the driver-specific completion-functions are
extended to return true or false depending on the timeout. This then
gets checked in the algorithm.
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Waiting for a free bus now accepts the timeout value in jiffies and does
proper checking using time_before.
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Add support for the PCA9665 I2C controller.
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

According to kerneljanitors todo list all printk calls (beginning
a new line) should have an according KERN_* constant.
Those are the changes to the debug macros in the i2c subsystem
to meet this requirement. Also changing no-debug statements
to raw printks again.
Signed-off-by: NFrank Seidel <frank@f-seidel.de>
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Tested-by: NWolfram Sang <w.sang@pengutronix.de>

Setting a default timeout value on a per-algo basis doesn't make any
sense. Move the default value setting to i2c-core. Individual adapter
drivers can specify a different (non-zero) value if they wish.

Also express the timeout value in a way which results in the same
duration regarless of the value of HZ.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Acked-by: NWolfram Sang <w.sang@pengutronix.de>

According to kerneljanitors todo list all printk calls (beginning
a new line) should have an according KERN_* constant.
Those are the missing pieces here for the i2c subsystem.
Signed-off-by: NFrank Seidel <frank@f-seidel.de>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

With a postfix decrement these timeouts reach -1 rather than 0, but after the
loop it is tested whether they have become 0.

As pointed out by Jean Delvare, the msg_num should be tested before the timeout.
With the current order, you could exit with a timeout error while all the
messages were successfully transferred.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Acked-by: NEric Brower <ebrower@gmail.com>

cleanup whitespace, fix comments and remove the unused STUB_I2C.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Acked-by: NEric Brower <ebrower@gmail.com>

Fix typo in debugging log message.

deteted --> detected
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Some I2C bus implementations need to synchronize with external
entities, such as system firmware, which might also be programming the
same I2C bus.

In order to facilitate this add ->xfer_begin() and ->xfer_end() hooks
which are invoked around pcf_xfer().

[JD: Make these hooks optional.]
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Pass adapter data into ->waitforpin() method.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

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=11140Signed-off-by: NJean Delvare <khali@linux-fr.org>

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: NEric Brower <ebrower@gmail.com>
Acked-by: NDan Smolik <marvin@mydatex.cz>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Give a more concrete error code, when the bus is not idle.
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

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: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

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: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

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: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

The algorithm drivers are helper drivers that are selected automatically
as needed. There's no point in listing them in the config menu, it can
only confuse users and waste their time.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

The 10-bit address support in i2c-algo-pcf is so heavily broken that
it can't have ever been used. Nobody ever complained, so I'll take it
that nobody needs it. Let's just delete it.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Update comments and logging on return path for byte writes.  NAK is
an error, to be reported or optionally ignored.  Timeouts are always
errors.  Lost arbitration is not currently handled, so don't even list
it as an option in the error message.

Don't return bogus EFAULT code for inappropriate NAK; EIO is better,
there is no bad userspace address in question.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Fix *LOTS* of whitespace goofs and checkpatch.pl warnings, strangely
parenthesized ternary expressions, and other CodingStyle glitches.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

* Convert files to UTF-8.

  * Also correct some people's names
    (one example is Eißfeldt, which was found in a source file.
    Given that the author used an ß at all in a source file
    indicates that the real name has in fact a 'ß' and not an 'ss',
    which is commonly used as a substitute for 'ß' when limited to
    7bit.)

  * Correct town names (Goettingen -> Göttingen)

  * Update Eberhard Mönkeberg's address (http://lkml.org/lkml/2007/1/8/313)
Signed-off-by: NJan Engelhardt <jengelh@gmx.de>
Signed-off-by: NAdrian Bunk <bunk@kernel.org>

This fixes a bug in the way i2c-algo-bit handles I2C_M_RECV_LEN,
used to implement i2c_smbus_read_block_data().  Previously, in the
absence of PEC (rarely used!) it would NAK the "length" byte:

	S addr Rd [A] [length] NA

That prevents the subsequent data bytes from being read:

	S addr Rd [A] [length] { A [data] }* NA

The primary fix just reorders two code blocks, so the length used
in the "should I NAK now?" check incorporates the data which it
just read from the slave device.

However, that move also highlighted other fault handling glitches.
This fixes those by abstracting the RX path ack/nak logic, so it
can be used in more than one location.  Also, a few CodingStyle
issues were also resolved.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

This driver has been broken forever. It depends on i2c-algo-8xx which
has never been in the mainline kernel.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Allow the whole I2C menu to be disabled at once without diving into
the submenus for deselecting all options (should the user desire so).
Signed-off-by: NJan Engelhardt <jengelh@gmx.de>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Improve the debugging features of the i2c-algo-bit driver:
* Make it possible to compile the driver without debugging support
  at all, making it much smaller.
* Use dev_dbg() for debugging messages where possible, and dev_err()
  for error messages.
* Remove redundant debugging messages.

These changes allowed for minor code cleanups, which are included
as well.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

The original i2c-algo-bit implementation uses a 33/66 SCL duty cycle
when bits are being written on the bus. While the I2C specification
doesn't forbid it, this prevents us from driving the I2C bus to its
max speed, limiting us to 66 kbps max on standard I2C busses.

Implementing a 50/50 duty cycle instead lets us max out the bandwidth
up to the theoretical max of 100 kbps on standard I2C busses. This is
particularly important when large amounts of data need to be transfered
over the bus, as is the case with some TV adapters when the firmware is
being uploaded.

In fact this change even allows, at least in theory, fast-mode I2C
support at 125, 166 and 250 kbps. There's no way to reach the
theoretical max of 400 kbps with this implementation. But I don't
think we want to put efforts in that direction anyway: software-driven
I2C is very CPU-intensive and bad for latency.

Other timing changes:
* Don't set SDA high explicitly on error, we're going to issue a stop
  condition before we leave anyway.
* If an error occurs when sending the slave address, yield the CPU
  before retrying, and remove the additional delay after the new start
  condition.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Signed-off-by: NLadislav Michl <ladis@linux-mips.org>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Add i2c_bit_add_numbered_bus(), which is equivalent to i2c_bit_add_bus
except that it calls i2c_add_numbered_adapter() at the end instead of
i2c_add_adapter().
Signed-off-by: NJean Delvare <khali@linux-fr.org>