at24 updates for v5.17
- add support for a new model: Microchip 24c1025
- reorganize the compatible definitions in the DT binding document
- drop the at24_client structure by retrieving the struct device associated
with the chip's regmap
platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
allocation of IRQ resources in DT core code, this causes an issue
when using hierarchical interrupt domains using "interrupts" property
in the node as this bypasses the hierarchical setup and messes up the
irq chaining.
In preparation for removal of static setup of IRQ resource from DT core
code use platform_get_irq().
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
allocation of IRQ resources in DT core code, this causes an issue
when using hierarchical interrupt domains using "interrupts" property
in the node as this bypasses the hierarchical setup and messes up the
irq chaining.
In preparation for removal of static setup of IRQ resource from DT core
code use platform_get_irq_optional() for DT users only.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
allocation of IRQ resources in DT core code, this causes an issue
when using hierarchical interrupt domains using "interrupts" property
in the node as this bypasses the hierarchical setup and messes up the
irq chaining.
In preparation for removal of static setup of IRQ resource from DT core
code use platform_get_irq().
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
No symbols from the linux/irqchip/chained_irq.h and linux/irqdomain.h
headers are used in the driver, so they can be removed.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
'#interrupt-cells' is not documented which causes a warning when
'unevaluatedProperties' is implemented. Unless the I2C controller is
also an interrupt controller, '#interrupt-cells' is not valid. This
doesn't appear to be the case from the driver, so just remove it from
the example.
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
dmaengine_terminate_all() is deprecated. When converting the existing
calls, it turned out that the termination in the DMA setup and callback
were superfluous and only a side effect of simply calling
rcar_i2c_cleanup_dma(). As either no DMA transfers have been submitted
yet or the last one has successfully completed, there is nothing to
terminate and we can leave it out. So, merge the DMA unmap and cleanup
function to save some code. Then, add a flag if the new cleanup function
needs to terminate DMA. This is only the case for the erorr handling in
the main thread, so we can finally switch from dmaengine_terminate_all()
to dmaengine_terminate_sync() here.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
dmaengine_terminate_all() is deprecated. When converting the existing
calls, it turned out that the termination in the interrupt handlers was
superfluous and only a side effect of simply calling
rcar_i2c_cleanup_dma(). As either no DMA transfers have been submitted
yet or the last one has successfully completed, there is nothing to
terminate and we can leave it out. So, merge the DMA unmap and cleanup
function to save some code. Then, add a flag if the new cleanup function
needs to terminate DMA. This is only the case for the erorr handling in
the main thread, so we can finally switch from dmaengine_terminate_all()
to dmaengine_terminate_sync() here.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
"hsi2c_pclk" clock is optional and may not be present for some SoCs
supported by this driver. Nevertheless, in case the clock is provided
but some error happens during its getting, that error should be handled
properly. Use devm_clk_get_optional() API for that. Also report possible
errors using dev_err_probe() to handle properly -EPROBE_DEFER error (if
clock provider is not ready by the time I2C probe function is executed).
Fixes: 697ad2490c ("i2c: exynos5: Add bus clock support")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Reviewed-by: Chanho Park <chanho61.park@samsung.com>
[wsa: fixed SHA1 of Fixes tag]
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Add a note about struct dw_scl_sda_cfg usage to discourage people
of using this structure on new platforms. Instead they should try
hard to put the needed information into firmware descriptions.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Intel Keem Bay platform supports multi-master operations over same i2c
bus using Synopsys i2c DesignWare IP. When multi-masters initiate i2c
operation simultaneously in a loop, SCL line is stucked low forever
after few i2c operations. Following interrupt sequences are observed
in:
working case: TX_EMPTY, RX_FULL and STOP_DET
non working case: TX_EMPTY, STOP_DET, RX_FULL.
DW_apb_i2c stretches the SCL line when the TX FIFO is empty or when
RX FIFO is full. The DW_apb_i2c master will continue to hold the SCL
line LOW until RX FIFO is read.
Linux kernel i2c DesignWare driver does not handle above non working
sequence. TX_EMPTY, RX_FULL and STOP_DET routine execution are required
in sequence although RX_FULL interrupt is raised after STOP_DET by
hardware. Clear STOP_DET for the following conditions:
(STOP_DET ,RX_FULL, rx_outstanding)
Write Operation: (1, 0, 0)
Read Operation:
RX_FULL followed by STOP_DET: (0, 1, 1) -> (1, 0, 0)
STOP_DET followed by RX_FULL: (1, 0, 1) -> (1, 1, 0)
RX_FULL and STOP_DET together: (1, 1, 1)
Signed-off-by: Tamal Saha <tamal.saha@intel.com>
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Microchip EEPROM 24xx1025 is like a 24c1024. The only difference
between them is that the I2C address bit used to select between the
two banks is bit 2 for the 1025 and not bit 0 as in the 1024.
Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Sort the compatible values for the special cases by EEPROM size, like is
done for the normal cases.
Combine entries with a common fallback using enums, to compact the
table.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
In interrupt mode we clear the status flags twice, in the interrupt
handler and in i801_check_post(). Remove clearing the status flags
from i801_check_post() and handle polling mode by using the
SMBus unlocking write to also clear the status flags if still set.
To be precise: One could still argue that the status flags are
cleared twice in interrupt mode, but it comes for free.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Tested-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
I see no need to read back the registers to verify that the bits
have actually been cleared. I can't imagine any scenario where
the bits would remain set after a write to them.
Whilst at it, change involved syslog messages to use pci_dbg() et al.
to simplify them.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Tested-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
In new Exynos SoCs (like Exynos850) where HSI2C is implemented as a
part of USIv2 block, there are two clocks provided to HSI2C controller:
- PCLK: bus clock (APB), provides access to register interface
- IPCLK: operating IP-core clock; SCL is derived from this one
Both clocks have to be asserted for HSI2C to be functional in that case.
Add code to obtain and enable/disable PCLK in addition to already
handled operating clock. Make it optional though, as older Exynos SoC
variants only have one HSI2C clock.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Reviewed-by: Chanho Park <chanho61.park@samsung.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
ExynosAutoV9 functioning logic mostly follows I2C_TYPE_EXYNOS7, but
timing calculation and configuration procedure is changed: e.g. only
timing_s3 has to be set now.
Another change of HSI2C controller in ExynosAutoV9 SoC is that it's now
a part of USIv2 IP-core. No changes is needed for I2C driver though, as
all USI related configuration is done in USI driver.
Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com>
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
In new Exynos SoCs (like Exynos850) where HSI2C is implemented as a
part of USIv2 block, there are two clocks provided to HSI2C controller:
- PCLK: bus clock (APB), provides access to register interface
- IPCLK: operating IP-core clock; SCL is derived from this one
Both clocks have to be asserted for HSI2C to be functional in that case.
Modify bindings doc to allow specifying bus clock in addition to
already described operating clock.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
The log messages talk about 'bus recovery' while it is not a bus
recovery with 9 pulses but merely a controller reset. Controller resets
are not worth log messages. The 'bus busy' message should be emitted by
upper layers, a busy bus may be expected in some cases.
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Reviewed-by: Alain Volmat <alain.volmat@foss.st.com>
Function stm32f7_i2c_release_bus is always returning 0, hence it
should be a void function. Update the function and remove the
return value error checking code in caller functions.
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
We use member client only to get a reference to the associated struct
device, via &client->dev. However we can get the same reference from
the associated regmap, via regmap_get_device(regmap).
Therefore struct at24_client can be removed and replaced with a regmap
pointer.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
The platform data structures are used in the respective i801_add_tco
functions only. Therefore we can make the definitions local to these
functions.
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Set optimal HCNT, LCNT and hold time values for all the speeds supported
in Intel Programmable Service Engine I2C controller in Intel Elkhart
Lake.
Signed-off-by: Lakshmi Sowjanya D <lakshmi.sowjanya.d@intel.com>
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
This enables the async suspend for i2c client devices. This reduces
the suspend/resume time considerably on platforms where i2c devices
can take a lot of time (hundreds of ms) to resume.
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Signed-off-by: Rajat Jain <rajatja@google.com>
Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Enable async suspend/resume of i2c adapters. It enormously helps with
reducing the resume time of systems (as much as 20%-40%) where I2C devices
can take significant time (100s of ms) to resume.
Signed-off-by: Rajat Jain <rajatja@google.com>
Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Mark the designware devices for asynchronous suspend. With this, the
resume for designware devices does not get stuck behind other unrelated
devices (e.g. intel_backlight that takes hundreds of ms to resume,
waiting for its parent devices).
Signed-off-by: Rajat Jain <rajatja@google.com>
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Current I2C reset procedure is broken in two ways:
1) It only generate 1 START instead of 9 STARTs and STOP.
2) It leaves the bus Busy so every I2C xfer after the first
fixup calls the reset routine again, for every xfer there after.
This fixes both errors.
Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
Acked-by: Scott Wood <oss@buserror.net>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
$ scripts/kernel-doc -none drivers/i2c/busses/i2c-designware-core.h
warning: Function parameter or member 'rst' not described in 'dw_i2c_dev'
warning: Function parameter or member 'get_clk_rate_khz' not described in 'dw_i2c_dev'
warning: Function parameter or member 'flags' not described in 'dw_i2c_dev'
warning: Function parameter or member 'functionality' not described in 'dw_i2c_dev'
warning: Function parameter or member 'master_cfg' not described in 'dw_i2c_dev'
warning: Function parameter or member 'set_sda_hold_time' not described in 'dw_i2c_dev'
warning: Function parameter or member 'rinfo' not described in 'dw_i2c_dev'
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Acked-by: Randy Dunlap <rdunla@infradead.org>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
clk_get_rate() is documented as requiring the clock to be enabled.
Ensure that the bus clock is enabled before calling clk_get_rate() in
rk3x_i2c_probe() to satisfy this requirement.
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
If FEATURE_BLOCK_BUFFER is set then bit SMBAUXCTL_E32B is supported
and there's no benefit in reading it back. Origin of this check
seems to be 14 yrs ago when people were not completely sure which
chip versions support the block buffer mode.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Tested-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
If an invalid block size is provided, reject it instead of silently
changing it to a supported value. Especially critical I see the case of
a write transfer with block length 0. In this case we have no guarantee
that the byte we would write is valid. When silently reducing a read to
32 bytes then we don't return an error and the caller may falsely
assume that we returned the full requested data.
If this change should break any (broken) caller, then I think we should
fix the caller.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Add support for the ACPI based device registration so that the driver
can be also enabled through ACPI table.
This does not include the ACPI support for Tegra VI and DVC I2C.
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Add i.MX8DXL lpi2c compatible to the bindings documentation.
Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
