i2c_davinci_cpufreq_transition() is implemented in a way that will
block if it ever gets called while no transfer is in progress.

Not only that, but reinit_completion() is never called for xfr_complete.

Use the fact that cpufreq uses an srcu_notifier (running in process
context) for transitions and that the bus_lock is taken during the call
to master_xfer() and simplify the code by removing the transfer
completion entirely and protecting i2c_davinci_cpufreq_transition()
with i2c_lock/unlock_adapter().
Reported-by: David Lechner <david@lechnology.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Tested-by: David Lechner <david@lechnology.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

gcc noticed the kerneldoc was wrongly formatted. Fix it!

drivers/i2c/busses/i2c-rk3x.c:164: warning:
  Cannot understand  * @grf_offset: ...
  on line 164 - I thought it was a doc line
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>

This driver creates a number of const structures that it stores in
the data field of an of_device_id array.

The data field of an of_device_id structure has type const void *, so
there is no need for a const-discarding cast when putting const values
into such a structure.

Furthermore, adding const to the declaration of the location that
receives a const value from such a field ensures that the compiler
will continue to check that the value is not modified.  The
const-discarding cast on the extraction from the data field is thus
no longer needed.

Done using Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

That path has gone away for a long time. Move the HW name upwards for a
proper header.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

As of v4.15, Kbuild warns about missing MODULE_LICENSE tags:

WARNING: modpost: missing MODULE_LICENSE() in drivers/i2c/busses/i2c-acorn.o

This adds a license, author and description tag, matching the
comment at the start of the acorn i2c driver.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

We can force levels of SCL and SDA, so we can use that for bus recovery.
Note that we cannot read SDA back, because we will only get the internal
state of the bus free detection.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

If we managed to get a client release SDA again, send a STOP afterwards
to make sure we have a consistent state on the bus again.
Tested-by: Phil Reid <preid@electromag.com.au>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

If we have a function to control SDA, we should ensure that SDA is not
held down by us. So, release the GPIO in this case.
Tested-by: Phil Reid <preid@electromag.com.au>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

This will be needed when we want to create STOP conditions, too, later.
Create the needed fields and populate them for the GPIO case if the GPIO
is set to output.
Tested-by: Phil Reid <preid@electromag.com.au>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

No reason to have them undefined, so let's add them.
Tested-by: Phil Reid <preid@electromag.com.au>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

"Used internally" is vague. What it actually means is that those fields
are populated by the core if valid GPIOs are provided. Change the
comments to reflect that.
Tested-by: Phil Reid <preid@electromag.com.au>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

Exynos-I2C uses default timeout of 1 second for the whole transaction,
including re-transmissions due to arbitration lost errors (-EAGAIN).
To allow re-transmissions driver's internal timeout should be significantly
lower, 100ms seems to be good candidate.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

Use only a portion of the data buffer for DMA transfers, which is always
16-byte aligned. This makes the DMA buffer address 16-byte aligned and
compensates for spurious hardware parity errors that may appear when the
DMA buffer address is not 16-byte aligned.

The data buffer is enlarged in order to accommodate any possible 16-byte
alignment offset and changes the DMA code to only use a portion of the
data buffer, which is 16-byte aligned.

The symptom of the hardware issue is the same as the one addressed in
v3.12-rc2-5-gbf416910 and manifests by transfers failing with EIO, with
bit 9 being set in the ERRSTS register.
Signed-off-by: Radu Rendec <radu.rendec@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

Remove the facility for setting the prescaler value at compile time
entirely. It was only used for two SoCs, duplicating the actual value
for one of them and setting sometimes bogus value for another. Make all
MPC8xxx SoCs obtain their actual I2C clock prescaler from a single place
in the code.

Changes from v2:
- left Device Tree compatibles in place
Signed-off-by: Arseny Solokha <asolokha@kb.kras.ru>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

According to the reference manuals for the corresponding SoCs, SEC
frequency ratio configuration is indicated by bit 26 of the POR Device
Status Register 2. Consequently, SEC_CFG bit should be tested by mask 0x20,
not 0x80. Testing the wrong bit leads to selection of wrong I2C clock
prescaler on those SoCs.
Signed-off-by: Arseny Solokha <asolokha@kb.kras.ru>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

Commit 8ce795cb ("i2c: mpc: assign the correct prescaler from SVR")
introduced the common helper function for obtaining the actual clock
prescaler value for MPC85xx. However, getting the prescaler for MPC8544
which depends on the SEC frequency ratio on this platform, has been always
performed separately based on the corresponding Device Tree configuration.

Move special handling of MPC8544 into that common helper. Make it dependent
on the SoC version and not on Device Tree compatible node, as is the case
with all other SoCs. Handle MPC8533 the same way which is similar
to MPC8544 in this regard, according to AN2919 "Determining the I2C
Frequency Divider Ratio for SCL".
Signed-off-by: Arseny Solokha <asolokha@kb.kras.ru>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

Obtaining the actual I2C clock prescaler value in mpc_i2c_setup_8xxx() only
happens when the clock parameter is set to something other than
MPC_I2C_CLOCK_LEGACY. When the clock parameter is exactly
MPC_I2C_CLOCK_LEGACY, the prescaler parameter is used in arithmetic
division as provided by the caller, resulting in a division by zero
for the majority of processors supported by the module.

Avoid division by zero by obtaining the actual I2C clock prescaler
in mpc_i2c_setup_8xxx() unconditionally regardless of the passed clock
value.
Signed-off-by: Arseny Solokha <asolokha@kb.kras.ru>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

This patch dumps general and master registers at the end of transactions
when debugging is enabled. Previously, registers were only dumped before
submitting new descriptors (at the beginning of transactions).

This helps debugging if some registers change as result of a failed
transaction (e.g. bits are set in the ERRSTS general register).
Signed-off-by: Radu Rendec <radu.rendec@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

Make use of the new formula for more precise bus frequencies.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

The formula to generate the desired bus speeds has changed a little over
time. Implement the new formula and allow drivers to opt-in by changing
to this new config set. Ensure in probe that we don't divide by zero.
The returned values on a R-Car H2 (r8a7790/Lager board) match the
suggested values in the datasheet.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

Because we will add a second formula soon, put the sanity checks for the
computed results into a separate function.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

Start RuntimePM a bit earlier, so we can use it to enable the clock
during probe for frequency calculations. Make sure it is enabled before
calling setup().
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

Require the setup callback and move the frequency calculation into it.
This is in preparation for supporting multiple formulas.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

The setup callback will be more generic and, thus, need to be able to
return error codes. Change the return type to 'int' for that.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

For refactoring reasons, we will need this information before the setup
callback. Also, simplify the comment to a oneliner.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

"Slow" GPIOs (usually those connected over an SPI or an I2C bus) are,
well, slow in their operation. It is generally a good idea to avoid
using them for time-critical operation, but sometimes the hardware just
sucks, and the software has to cope. In addition to that, the I2C bus
itself does not actually define any strict timing limits; the bus is
free to go all the way down to DC. The timeouts (and therefore the
slowest acceptable frequency) are present only in SMBus.

The `can_sleep` is IMHO a wrong concept to use here. My SPI-to-quad-UART
chip (MAX14830) is connected via a 26MHz SPI bus, and it happily drives
SCL at 200kHz (5µs pulses) during my benchmarks. That's faster than the
maximal allowed speed of the traditional I2C.

The previous version of this code did not really block operation over
slow GPIO pins, anyway. Instead, it just resorted to printing a warning
with a backtrace each time a GPIO pin was accessed, thereby slowing
things down even more.

Finally, it's not just me. A similar patch was originally submitted in
2015 [1].

[1] https://patchwork.ozlabs.org/patch/450956/Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

Make sure i2c module clock has been enabled before i2c registers
access.
Signed-off-by: Jun Gao <jun.gao@mediatek.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

Add i2c compatible for MT2712. Compare to MT8173 i2c controller,
internal divider of i2c source clock need to be configured for
MT2712 i2c speed calculation.
Signed-off-by: Jun Gao <jun.gao@mediatek.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

Add MT2712 i2c binding to binding file. Compare to MT8173 i2c
controller, MT2712 has timing adjust registers which can adjust
the internal divider of i2c source clock, SCL duty cycle, SCL
compare point, start(repeated start) and stop time, SDA change
time.
Signed-off-by: Jun Gao <jun.gao@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

Merge tag 'at24-4.16-updates-for-wolfram' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into i2c/for-4.16

"AT24 updates for 4.16 merge window

The driver has been converted to using regmap instead of raw i2c and
smbus calls which shrank the code significantly.

Device tree binding document has been cleaned up. Device tree support in
the driver has been improved and we now support all at24 models as well
as two new DT properties (no-read-rollover and wp-gpios).

We no longer user unreadable magic values for driver data as the way it
was implemented caused problems for some EEPROM models - we switched to
regular structs.

Aside from that, there's a bunch of coding style fixes and minor
improvements all over the place."

Add all supported at24 variants to the of_match table.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>

Add other variants of at24 EEPROMs we support in the driver to the
list of allowed compatible fallbacks.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Rob Herring <robh@kernel.org>

Make formatting and style consistent for the entire document.

This patch doesn't change the content of the binding.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Rob Herring <robh@kernel.org>

Current description of the compatible property for at24 is quite vague.

State explicitly that any "<manufacturer>,<model>" pair is accepted as
long as a correct fallback is used for non-atmel chips.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: Rob Herring <robh@kernel.org>

Replace spaces with tabs in the definition of AT24_FLAG_NO_RDROL.

Fixes: 9d404411091c ("eeprom: at24: support eeproms that do not auto-rollover reads")
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>

AT24 EEPROMs have a write-protect pin, which - when pulled high -
inhibits writes to the upper quadrant of memory (although it has been
observed that on some chips it disables writing to the entire memory
range).

On some boards, this pin is connected to a GPIO and pulled high by
default, which forces the user to manually change its state before
writing. On linux this means that we either need to hog the line all
the time, or set the GPIO value before writing from outside of the
at24 driver.

Make the driver check if the write-protect GPIO was defined in the
device tree and pull it low whenever writing to the EEPROM.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

AT24 EEPROMs have a write-protect pin, which - when pulled high -
inhibits writes to the upper quadrant of memory (although it has been
observed that on some chips it disables writing to the entire memory
range).

On some boards, this pin is connected to a GPIO and pulled high by
default, which forces the user to manually change its state before
writing. On linux this means that we either need to hog the line all
the time, or set the GPIO value before writing from outside of the
at24 driver.

Add a new optional property to the device tree binding document, which
allows to specify the GPIO line to which the write-protect pin is
connected.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>

The chip size passed via devicetree, i2c, or acpi device ids is now no
longer limited to a power of two. So the temporary fix can be removed.
Signed-off-by: Sven Van Asbroeck <svendev@arcx.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>

Fundamental properties such as capacity and page size differ among
at24-type chips. But these chips do not have an id register, so this
can't be discovered at runtime.

Traditionally, at24-type eeprom properties were determined in two ways:
- by passing a 'struct at24_platform_data' via platform_data, or
- by naming the chip type in the devicetree, which passes a 'magic
  number' to probe(), which is then converted to a 'struct
  at24_platform_data'.

Recently a bug was discovered because the magic number rounds down all
chip sizes to the lowest power of two. This was addressed by
a work-around commit 5478e478 ("eeprom: at24: correctly set the
size for at24mac402"), with the wish that magic numbers should over
time be converted to structs.

This patch replaces the magic numbers with 'struct at24_chip_data'.
Signed-off-by: Sven Van Asbroeck <svendev@arcx.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>

A regmap_config struct is pretty big and declaring two of them
statically just to tweak the reg_bits value adds unnecessary bloat.

Declare the regmap config locally in at24_probe() instead.

Bloat-o-meter output for ARM:

add/remove: 0/2 grow/shrink: 1/0 up/down: 4/-272 (-268)
Function                                     old     new   delta
at24_probe                                  1560    1564      +4
regmap_config_8                              136       -    -136
regmap_config_16                             136       -    -136
Total: Before=7012, After=6744, chg -3.82%
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>