| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
Reviewed-by: Jean Delvare <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout and turn
the SMBus-specific termination message to debug.
Signed-off-by: Wolfram Sang <[email protected]>
Reviewed-by: Jean Delvare <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
Add Zhaoxin I2C controller driver. It provides the access to the i2c
busses, which connects to the touchpad, eeprom, I2S, etc.
Zhaoxin I2C controller has two separate busses, so may accommodate up
to two I2C adapters. Those adapters are listed in the ACPI namespace
with the IIC1D17 HID, and probed by a platform driver.
The driver works with IRQ mode, and supports basic I2C features. Flags
I2C_AQ_NO_ZERO_LEN and I2C_AQ_COMB_WRITE_THEN_READ are used to limit
the unsupported access.
Acked-by: Wolfram Sang <[email protected]>
Signed-off-by: Hans Hu <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
Enumeration variables are added to differentiate
between different platforms.
Acked-by: Wolfram Sang <[email protected]>
Signed-off-by: Hans Hu <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
During each byte access, the host performs clock stretching.
To reduce the host performs clock stretching, move most of
the per-msg processing to the interrupt context.
Suggested-by: Wolfram Sang <[email protected]>
Reviewed-by: Wolfram Sang <[email protected]>
Signed-off-by: Hans Hu <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
1. The I2C IP for both wmt and zhaoxin originates from VIA. Rename
common registers, functions, and variable names to follow the
VIAI2C_ and viai2c_ naming conventions for consistency and clarity.
2. rename i2c_dev to i2c, to shorten the length of a line.
3. rename wait_result to time_left, make it better to reflect the meaning
of the value returned by wait_for_completion_timeout().
4. remove TCR_MASTER_WRITE, its value is 0.
Reviewed-by: Wolfram Sang <[email protected]>
Signed-off-by: Hans Hu <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
Since the I2C IP of both wmt and zhaoxin originates from VIA,
it is better to separate the common code first.
The common driver is named as i2c-viai2c-common.c.
Old i2c-wmt.c renamed to i2c-viai2c-wmt.c.
The MAINTAINERS file will be updated accordingly in upcoming commits.
Reviewed-by: Wolfram Sang <[email protected]>
Signed-off-by: Hans Hu <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
Some common initialization actions are put in the function
wmt_i2c_init(), which is convenient to share with zhaoxin.
Reviewed-by: Andi Shyti <[email protected]>
Reviewed-by: Wolfram Sang <[email protected]>
Signed-off-by: Hans Hu <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
Read the ioclk property as reference clock if sclk not present in acpi
table to make it SOC agnostic.
In case, it's not populated from dts/acpi table, use the default clock
of 800 MHz which is optimal in either case of sclk/ioclk.
Signed-off-by: Piyush Malgujar <[email protected]>
Acked-by: Andi Shyti <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
Add watchdog timeout handling to cater to the unhandled warnings
seen during validation on boards with different I2C slaves.
This status code reflects the state that controller couldn't
receive any response from slave while being in non-idle state
and HW recommends to reset before any further bus access.
Signed-off-by: Suneel Garapati <[email protected]>
Signed-off-by: Piyush Malgujar <[email protected]>
Acked-by: Andi Shyti <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
The macros for TWSI register's offset are generically
named, rename them to be platform specific macros by
adding 'OCTEON_REG' as prefix.
Signed-off-by: Piyush Malgujar <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
To support bus operations for high speed bus frequencies greater than
400KHZ following control bits need to be setup accordingly
- hs_mode (bit 0) field in Mode register to switch controller
between low-speed and high-speed frequency operating mode.
- Setup clock divisors for desired TWSI bus frequency using
FOSCL output frequency divisor (D):
0 - sets the divisor to 10 for low speed mode
1 - sets the divisor to 15 for high speed mode.
The TWSI bus output frequency, in master mode is based on:
TCLK = 100MHz / (THP + 2)
FOSCL = FSAMP / (M+1)×D = TCLK / (2 ^ N × (M + 1) × 15)
FSAMP = TCLK / 2 ^ N
where,
N is <2:0> and M is <6:3> of TWSI Clock Control Register
D is 10 for low speed or 15 for HS_MODE
With high speed mode support, HLC mode usage is limited to
low speed frequency (<=400KHz) bus transfers in hardware.
Signed-off-by: Suneel Garapati <[email protected]>
Signed-off-by: Piyush Malgujar <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
Handle changes to clock divisor logic for OcteonTX2 SoC family using
subsystem ID and using default reference clock source as 100MHz.
Signed-off-by: Suneel Garapati <[email protected]>
Signed-off-by: Piyush Malgujar <[email protected]>
Acked-by: Andi Shyti <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
Add RISCV support to Cadence I2C Kconfig which is used in platform
such as the StarFive JH8100.
Signed-off-by: Eng Lee Teh <[email protected]>
Signed-off-by: Ji Sheng Teoh <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
Acked-by: Heiko Stuebner <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
Reviewed-by: Bjorn Andersson <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
Reviewed-by: Bjorn Andersson <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout and
simplify the logic a little.
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
Acked-by: Michal Simek <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
Instead of repeatedly calling clk_get_rate for each transfer, lock
the clock rate and cache the value.
A deadlock has been observed while adding tlv320aic32x4 audio codec to
the system. When this clock provider adds its clock, the clk mutex is
locked already, it needs to access i2c, which in return needs the mutex
for clk_get_rate as well.
Signed-off-by: Alexander Stein <[email protected]>
Reviewed-by: Uwe Kleine-König <[email protected]>
Reviewed-by: Andi Shyti <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
Annotate this variable as __ro_after_init to protect it from being
overwritten later.
Signed-off-by: Heiner Kallweit <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
i801 as only user of gpio i2c mux removed support for class-based device
instantiation on muxed busses. Class-based device instantiation is a
legacy mechanism and shouldn't be used in new code, therefore remove
support also here.
Signed-off-by: Heiner Kallweit <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
Only remaining client driver supporting I2C_CLASS_SPD is jc42. This
type of thermal sensor can be found on several DDR3/DDR4 modules.
i2c_register_spd() instantiates also such thermal sensor i2c devices.
Since 893fef0bc6aa ("i2c: i801: Call i2c_register_spd for muxed child
segments") i2c_register_spd() is called also for the remaining use case,
systems with muxed SMBUS segments for SPD EEPROMs.
Therefore I2C_CLASS_SPD class-based instantiation isn't needed any longer
in this driver, so remove it.
Signed-off-by: Heiner Kallweit <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
Granite Rapids-D has additional I2C controller that is enumerated via
ACPI. Add ACPI ID for it.
Signed-off-by: Shanth Murthy <[email protected]>
Signed-off-by: Jarkko Nikula <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
Remove of_node_put from node_ctrl and node struct device_nodes.
Move the declaration to initialization for ensuring scope sanity.
Suggested-by: Julia Lawall <[email protected]>
Signed-off-by: Abhinav Jain <[email protected]>
Reviewed-by: Chris Packham <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
The original change adds usage of i2c_root_adapter(), which is
implemented in i2c-mux.c. Therefore we can't use the multiplexing
if I2C_I801=y and I2C_MUX=m.
Handling the dependencies in the code would become unnecessarily
complex, therefore create a new config symbol.
Fixes: 893fef0bc6aa ("i2c: i801: Call i2c_register_spd for muxed child segments")
Reported-by: kernel test robot <[email protected]>
Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
Signed-off-by: Heiner Kallweit <[email protected]>
Reviewed-by: Wolfram Sang <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
There is at least one machine that uses this driver but does not
have support for inb()/outb() instructions.
Convert this to using ioport_map() so it can build on architectures
that don't provide these but work correctly on machines that require
using port I/O.
Fixes: 47c21d2d52e0 ("i2c: add HAS_IOPORT dependencies")
Reported-by: Geert Uytterhoeven <[email protected]>
Link: https://lore.kernel.org/lkml/CAMuHMdVUQ2WgtpYPYfO2T=itMmZ7w=geREqDtsP8Q3ODh9rxdw@mail.gmail.com/
Signed-off-by: Arnd Bergmann <[email protected]>
Acked-by: Peter Korsgaard <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
The Driver unintentionally programs ctrl reg to clear the fifo, which
happens after the start of transaction. Previously, this was not an issue
as it involved read-modified-write. However, this issue breaks i2c reads
on QEMU, as i2c-read is executed before guest starts programming control
register.
Fixes: ff0cf7bca630 ("i2c: cadence: Remove unnecessary register reads")
Signed-off-by: Sai Pavan Boddu <[email protected]>
Acked-by: Michal Simek <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at
compile time. We thus need to add HAS_IOPORT as dependency for those
drivers using them.
Co-developed-by: Arnd Bergmann <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Niklas Schnelle <[email protected]>
Reviewed-by: Wolfram Sang <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
Once the gpio mux driver binds to the "i2c-mux-gpio" platform device,
this creates the i2c adapters for the muxed child segments.
We can use the bus notifier mechanism to check for creation of the
child i2c adapters, and call i2c_register_spd() for them. This allows
to detect all DIMM's on systems with more than 8 memory slots.
Reviewed-by: Wolfram Sang <[email protected]>
Signed-off-by: Heiner Kallweit <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
Core in platform_driver_register() already sets the .owner, so driver
does not need to.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
Extend the RIIC driver to support the RZ/V2H(P) ("R9A09G057") SoC. It
accomplishes this by appending the compatible string list and passing
the RZ/V2H-specific OF data.
Signed-off-by: Lad Prabhakar <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Wolfram Sang <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
With an increasing number of SoCs reusing this driver, each with slight
variations in the RIIC IP, it becomes necessary to support passing these
details as OF data. This approach simplifies the extension of the driver
for other SoCs.
This patch lays the groundwork for adding support for the Renesas RZ/V2H
SoC.
Signed-off-by: Lad Prabhakar <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Wolfram Sang <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
Introduce helper functions for performing I2C read and write operations
in the RIIC driver.
These helper functions lay the groundwork for adding support for the
RZ/V2H SoC. This is essential because the register offsets for the RZ/V2H
SoC differ from those of the RZ/A SoC. By abstracting the read and write
operations, we can seamlessly adapt the driver to support different SoC
variants without extensive modifications.
This patch is part of the preparation process for integrating support for
the RZ/V2H SoC into the RIIC driver.
Signed-off-by: Lad Prabhakar <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Wolfram Sang <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
Baruch reported an OOPS when using the designware controller as target
only. Target-only modes break the assumption of one transfer function
always being available. Fix this by always checking the pointer in
__i2c_transfer.
Reported-by: Baruch Siach <[email protected]>
Closes: https://lore.kernel.org/r/4269631780e5ba789cf1ae391eec1b959def7d99.1712761976.git.baruch@tkos.co.il
Fixes: 4b1acc43331d ("i2c: core changes for slave support")
[wsa: dropped the simplification in core-smbus to avoid theoretical regressions]
Signed-off-by: Wolfram Sang <[email protected]>
Tested-by: Baruch Siach <[email protected]>
|
|
Amba bus core already sets owner, so driver does not need to.
Link: https://lore.kernel.org/r/[email protected]
Acked-by: Linus Walleij <[email protected]>
Acked-by: Andi Shyti <[email protected]>
Acked-by: Suzuki K Poulose <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>
|
|
The function using this is hidden in an #ifdef, so the variable
needs the same one for a clean W=1 build:
drivers/i2c/busses/i2c-pxa.c:327:26: error: 'icr_bits' defined but not used [-Werror=unused-const-variable=]
Fixes: d6a7b5f84b5c ("[ARM] 4827/1: fix two warnings in drivers/i2c/busses/i2c-pxa.c")
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|
|
Commit 857cc04cdf50 ("i2c: i801: Add helper i801_get_block_len")
introduced a slight functional change: the status variable is now
overwritten with the length of an SMBUS tranasaction,
even in case of success.
This breaks the touchpad on at least my Lenovo P1:
rmi4_physical rmi4-00: Read PDT entry at 0x00e9 failed, code: -6.
rmi4_physical rmi4-00: RMI initial reset failed! Continuing in spite of this.
rmi4_physical rmi4-00: Read PDT entry at 0x00e9 failed, code: -6.
rmi4_physical rmi4-00: IRQ counting failed with code -6.
Fixes: 857cc04cdf50 ("i2c: i801: Add helper i801_get_block_len")
Signed-off-by: Maxim Levitsky <[email protected]>
Reviewed-by: Heiner Kallweit <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
|