- Jan 30, 2020
-
-
Luca Ceresoli authored
"I2C transfer" is a legitimate english sentence, no need for a hyphen between the two words, as as such it is used in most of the documentation. Remove the hyphen in the few places where it is present. Signed-off-by:
Luca Ceresoli <luca@lucaceresoli.net> Acked-by:
Peter Rosin <peda@axentia.se> Reviewed-by:
Jean Delvare <jdelvare@suse.de> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
Luca Ceresoli authored
Fix "issus" -> "issues". Signed-off-by:
-
Luca Ceresoli authored
Uppercase "I2C" is used almost everywhere in the docs, but the lowercase version "i2c" is used somewhere. Use the uppercase form consistently. Signed-off-by:
-
Luca Ceresoli authored
This section, partly dating back to the pre-git era, is somewhat unclear and partly incorrect. Rewrite it almost completely including a reference figure, concise but precise definition of each term and the paths where drivers are found. Particular care has been put in clarifying the relation between adapter and algorithm, which has no correspondence in the I2C spec terminology. Signed-off-by:
-
Luca Ceresoli authored
- state the "official" name (I²C, not I2C, according to the spec) at the beginning but keep using the more practical I2C elsewhere - mention some known different names - add link to the specification document Signed-off-by:
-
Luca Ceresoli authored
The index page currently lists sections in alphabetical file order without caring about their content. Sort sections based on their content logically, according to the following structure: * Intro to I2C/SMBus and their usage in Linux: summary, i2c-protocol, smbus-protocol, instantiating-devices, busses/index, i2c-topology, muxes/i2c-mux-gpio * Implementing drivers: writing-clients, dev-interface, dma-considerations, fault-codes, functionality * Debugging: gpio-fault-injection, i2c-stub * Slave I2C: slave-interface, slave-eeprom-backend * Advanced: ten-bit-addresses * Obsolete info: upgrading-clients, old-module-parameters Signed-off-by:
-
https://github.com/peda-r/i2c-muxWolfram Sang authored
The main feature is the idle-state rework of the pca954x driver from Biwen Li.
-
Wolfram Sang authored
Merge tag 'at24-updates-for-v5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into i2c/for-5.6 at24 updates for linux v5.6 - minor maintenance: update the license tag, sort headers - move support for the write-protect pin into nvmem core - add a reference to the new wp-gpios property in nvmem to at25 bindings - add support for regulator and pm_runtime control
-
Colin Ian King authored
There is a statement that is indented one level too deeply, remove the extraneous tab. Fixes: b4c119db ("i2c: xiic: Add timeout to the rx fifo wait loop") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
Shubhrajyoti Datta <shubhrajyoti.datta@gmail.com> Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in a module parameter description. Fix it. Signed-off-by:
-
- Jan 23, 2020
-
-
Bibby Hsieh authored
Although in the most platforms, the power of eeprom are alway on, some platforms disable the eeprom power in order to meet low power request. This patch add the pm_runtime ops to control power to support all platforms. Signed-off-by:
Bibby Hsieh <bibby.hsieh@mediatek.com> [Bartosz: rebased on top of current at24/for-next] Signed-off-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com>
-
Bibby Hsieh authored
In some platforms, they disable the power-supply of eeprom due to power consumption reduction. This patch add vcc-supply property. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Krzysztof Kozlowski authored
Update the help text to reflect current support devices: 1. The Exynos high speed I2C driver supports Exynos5 (ARMv7), Exynos5433 and Exynos7 (both ARMv8) SoCs, 2. The S3C I2C driver supports S3C, S5Pv210 and Exynos{3,4,5} SoCs. Signed-off-by:Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Krzysztof Kozlowski authored
Some of the I2C bus drivers can be compile tested to increase build coverage. This requires also: 1. Adding dependencies on COMMON_CLK for BCM2835 and Meson I2C controllers, 2. Adding 'if' conditional to 'default y' so they will not get enabled by default on all other architectures, 3. Limiting few compile test options to supported architectures (which provide the readsX()/writesX() primitives). Signed-off-by:
-
- Jan 16, 2020
-
-
Shubhrajyoti Datta authored
The recommendation is that the set_active should be done with pm runtime disabled. Also fix the remove path for clocking. Signed-off-by:
Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> Signed-off-by:
Michal Simek <michal.simek@xilinx.com> Signed-off-by:
-
Venkatesh Yadav Abbarapu authored
It's not always the case that clock is already available when i2c driver get probed at the first time, e.g. the clock is provided by clock wizard which may be probed after i2c driver. So let's defer the probe when devm_clk_get() call fails and give it chance to try later. Signed-off-by:
Venkatesh Yadav Abbarapu <venkatesh.abbarapu@xilinx.com> Signed-off-by:
-
Shubhrajyoti Datta authored
Add timeout to the rx fifo empty wait loop. Also check for the return value for xiic_reinit and pass it to xiic_start_xfer. Signed-off-by:
-
Krzysztof Kozlowski authored
size_t should be printed with its own format to be 64-bit friendly and fix warning when compiling on 64-bit platform (e.g. with COMPILE_TEST): drivers/i2c/busses/i2c-highlander.c: In function ‘highlander_i2c_smbus_xfer’: drivers/i2c/busses/i2c-highlander.c:325:22: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘size_t {aka long unsigned int}’ [-Wformat=] Signed-off-by: -
Krzysztof Kozlowski authored
resource_size_t should be printed with its own size-independent format to fix warnings when compiling on 64-bit platform (e.g. with COMPILE_TEST): drivers/i2c/busses/i2c-pnx.c: In function ‘i2c_pnx_probe’: drivers/i2c/busses/i2c-pnx.c:737:47: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 5 has type ‘resource_size_t {aka long long unsigned int}’ [-Wformat=] Signed-off-by: -
Krzysztof Kozlowski authored
resource_size_t should be printed with its own size-independent format to fix warnings when compiling on 64-bit platform (e.g. with COMPILE_TEST): drivers/i2c/busses/i2c-pmcmsp.c: In function ‘pmcmsptwi_probe’: drivers/i2c/busses/i2c-pmcmsp.c:276:25: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 3 has type ‘resource_size_t {aka long long unsigned int}’ [-Wformat=] Signed-off-by: -
Wolfram Sang authored
i2c_new_device is deprecated, use i2c_new_client_device. Also, align a paragraph while here. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by:
-
Wolfram Sang authored
i2c_new_device is deprecated, use i2c_new_client_device. Signed-off-by:
-
Wolfram Sang authored
Move away from the deprecated API and return the shiny new ERRPTR where useful. Signed-off-by:
-
Wolfram Sang authored
Move away from the deprecated API and return the shiny new ERRPTR where useful. Signed-off-by:
-
Wolfram Sang authored
Move away from the deprecated API and return the shiny new ERRPTR where useful. Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
Wolfram Sang authored
Move away from the deprecated API and return the shiny new ERRPTR where useful. Signed-off-by:
-
Wolfram Sang authored
Move away from the deprecated API and return the shiny new ERRPTR where useful. Signed-off-by:
-
Wolfram Sang authored
Move away from the deprecated API and return the shiny new ERRPTR where useful. Signed-off-by:
-
Wolfram Sang authored
Move away from the deprecated API and return the shiny new ERRPTR where useful. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Peter Korsgaard <peter@korsgaard.com> Signed-off-by:
-
Wolfram Sang authored
Move away from the deprecated API and return the shiny new ERRPTR where useful. Signed-off-by:
-
Wolfram Sang authored
Move away from the deprecated API and return the shiny new ERRPTR where useful. Signed-off-by:
-
Wolfram Sang authored
Move away from the deprecated API and return the shiny new ERRPTR where useful. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
-
Krzysztof Kozlowski authored
iomem pointers should be printed with pointer format to hide the actual value and fix warnings when compiling on 64-bit platform (e.g. with COMPILE_TEST): drivers/i2c/busses/i2c-stu300.c: In function ‘stu300_wait_while_busy’: drivers/i2c/busses/i2c-stu300.c:446:76: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] Signed-off-by:Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Dmitry Osipenko authored
It is more robust to check completion status in addition to the left time in a case of DMA transfer because transfer's completion happens in two phases [one is ISR, other is tasklet] and thus it is possible that DMA is completed while I2C completion awaiting times out because of the deferred notification done by the DMA driver. The DMA completion status becomes 100% actual after DMA synchronization. This fixes spurious DMA timeouts when system is under load. Tested-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Signed-off-by:
-
Dmitry Osipenko authored
It is possible that I2C could error out in the middle of DMA transfer and in this case DMA channel needs to be reset, otherwise a follow up transfer will fail because DMA channel stays blocked. Tested-by:
-
Dmitry Osipenko authored
There is nothing to synchronize in regards to memory accesses for PIO transfers and for DMA transfers the DMA API takes care of the syncing. Tested-by:
-
Dmitry Osipenko authored
DMA is preferred for a larger transfers, while PIO is preferred for a smaller transfers to avoid unnecessary DMA overhead. There is no strict size limitations for the PIO-mode transfers, so let's rename the constant for clarity. Tested-by:
-
Dmitry Osipenko authored
System shutdown may happen with interrupts being disabled and in this case kernel may hang if atomic transfer isn't supported by driver. There were several occurrences where I found my Nexus 7 completely discharged despite of being turned off and then one day I spotted this in the log: reboot: Power down ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at drivers/i2c/i2c-core.h:40 i2c_transfer+0x95/0x9c No atomic I2C transfer handler for 'i2c-1' Modules linked in: tegra30_devfreq CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 5.4.0-next-20191202-00120-gf7ecd80fb803-dirty #3195 Hardware name: NVIDIA Tegra SoC (Flattened Device Tree) [<c010e4b5>] (unwind_backtrace) from [<c010a0fd>] (show_stack+0x11/0x14) [<c010a0fd>] (show_stack) from [<c09995e5>] (dump_stack+0x85/0x94) [<c09995e5>] (dump_stack) from [<c011f3d1>] (__warn+0xc1/0xc4) [<c011f3d1>] (__warn) from [<c011f691>] (warn_slowpath_fmt+0x61/0x78) [<c011f691>] (warn_slowpath_fmt) from [<c069a8dd>] (i2c_transfer+0x95/0x9c) [<c069a8dd>] (i2c_transfer) from [<c05667f1>] (regmap_i2c_read+0x4d/0x6c) [<c05667f1>] (regmap_i2c_read) from [<c0563601>] (_regmap_raw_read+0x99/0x1cc) [<c0563601>] (_regmap_raw_read) from [<c0563757>] (_regmap_bus_read+0x23/0x38) [<c0563757>] (_regmap_bus_read) from [<c056293d>] (_regmap_read+0x3d/0xfc) [<c056293d>] (_regmap_read) from [<c0562d3b>] (_regmap_update_bits+0x87/0xc4) [<c0562d3b>] (_regmap_update_bits) from [<c0563add>] (regmap_update_bits_base+0x39/0x50) [<c0563add>] (regmap_update_bits_base) from [<c056fd39>] (max77620_pm_power_off+0x29/0x2c) [<c056fd39>] (max77620_pm_power_off) from [<c013bbdd>] (__do_sys_reboot+0xe9/0x170) [<c013bbdd>] (__do_sys_reboot) from [<c0101001>] (ret_fast_syscall+0x1/0x28) Exception stack(0xde907fa8 to 0xde907ff0) 7fa0: 00000000 00000000 fee1dead 28121969 4321fedc 00000000 7fc0: 00000000 00000000 00000000 00000058 00000000 00000000 00000000 00000000 7fe0: 0045adf0 bed9abb8 004444a0 b6c666d0 ---[ end trace bdd18f87595b1a5e ]--- The atomic transferring is implemented by enforcing PIO mode for the transfer and by polling interrupt status until transfer is completed or failed. Now system shuts down properly every time. Tested-by:
-
Dmitry Osipenko authored
Potentially it is possible that interrupt may fire after transfer timeout. That may not end up well for the next transfer because interrupt handling may race with hardware resetting. This is very unlikely to happen in practice, but anyway let's prevent the potential problem by enabling interrupt only at the moments when it is actually necessary to get some interrupt event. Tested-by:
-
Wolfram Sang authored
-
