kernel/linux.git/include/linux/i2c.h, branch v4.10.9

i2c: do not enable fall back to Host Notify by default

2017-01-12T19:06:15+00:00

Falling back unconditionally to HostNotify as primary client's interrupt breaks some drivers which alter their functionality depending on whether interrupt is present or not, so let's introduce a board flag telling I2C core explicitly if we want wired interrupt or HostNotify-based one: I2C_CLIENT_HOST_NOTIFY. For DT-based systems we introduce "host-notify" property that we convert to I2C_CLIENT_HOST_NOTIFY board flag. Tested-by: Benjamin Tissoires Signed-off-by: Dmitry Torokhov Acked-by: Pali Rohár Acked-by: Rob Herring Signed-off-by: Wolfram Sang

i2c: use an IRQ to report Host Notify events, not alert

2016-11-24T15:22:06+00:00

The current SMBus Host Notify implementation relies on .alert() to relay its notifications. However, the use cases where SMBus Host Notify is needed currently is to signal data ready on touchpads. This is closer to an IRQ than a custom API through .alert(). Given that the 2 touchpad manufacturers (Synaptics and Elan) that use SMBus Host Notify don't put any data in the SMBus payload, the concept actually matches one to one. Benefits are multiple: - simpler code and API: the client will just have an IRQ, and nothing needs to be added in the adapter beside internally enabling it. - no more specific workqueue, the threading is handled by IRQ core directly (when required) - no more races when removing the device (the drivers are already required to disable irq on remove) - simpler handling for drivers: use plain regular IRQs - no more dependency on i2c-smbus for i2c-i801 (and any other adapter) - the IRQ domain is created automatically when the adapter exports the Host Notify capability - the IRQ are assign only if ACPI, OF and the caller did not assign one already - the domain is automatically destroyed on remove - fewer lines of code (minus 20, yeah!) Signed-off-by: Benjamin Tissoires Signed-off-by: Wolfram Sang

i2c: Provide a temporary .probe_new() call-back type

2016-11-17T15:10:23+00:00

This will aid the seamless removal of the current probe()'s, more commonly unused than used second parameter. Most I2C drivers can simply switch over to the new interface, others which have DT support can use its own matching instead and others can call i2c_match_id() themselves. This brings I2C's device probe method into line with other similar interfaces in the kernel and prevents the requirement to pass an i2c_device_id table. Suggested-by: Grant Likely Signed-off-by: Lee Jones [Kieran: fix rebase conflicts and adapt for dev_pm_domain_{attach,detach}] Tested-by: Kieran Bingham Reviewed-by: Javier Martinez Canillas Tested-by: Javier Martinez Canillas Signed-off-by: Kieran Bingham Signed-off-by: Wolfram Sang

i2c: Export i2c_match_id() for direct use by device drivers

2016-11-17T15:10:22+00:00

When there was no other way to match a I2C device to driver i2c_match_id() was exclusively used. However, now there are other types of tables which are commonly supplied, matching on an i2c_device_id table is used less frequently. Instead of _always_ calling i2c_match_id() from within the framework, we only need to do so from drivers which have no other way of matching. This patch makes i2c_match_id() available to the aforementioned device drivers. Acked-by: Grant Likely Signed-off-by: Lee Jones Tested-by: Kieran Bingham Reviewed-by: Javier Martinez Canillas Tested-by: Javier Martinez Canillas Signed-off-by: Kieran Bingham Signed-off-by: Wolfram Sang

i2c: Match using traditional OF methods, then by vendor-less compatible strings

2016-11-17T15:10:20+00:00

This function provides a single call for all I2C devices which need to match firstly using traditional OF means i.e by of_node, then if that fails we attempt to match using the supplied I2C client name with a list of supplied compatible strings with the ',' string removed. The latter is required due to the unruly naming conventions used currently by I2C devices. Acked-by: Grant Likely Signed-off-by: Lee Jones [Kieran: Fix static inline usage on !CONFIG_OF] Tested-by: Kieran Bingham Reviewed-by: Javier Martinez Canillas Tested-by: Javier Martinez Canillas Signed-off-by: Kieran Bingham Signed-off-by: Wolfram Sang

i2c: export i2c_adapter_depth()

2016-09-24T08:48:18+00:00

For crazy setups in which an i2c gpio expander is behind an i2c gpio multiplexer controlled by a gpio provided a second expander using the same device driver we need to explicitly tell lockdep how to handle nested locking. Export i2c_adapter_depth() as public API to be reused outside of i2c core code. Signed-off-by: Bartosz Golaszewski Acked-by: Peter Rosin Acked-by: Peter Zijlstra (Intel) Signed-off-by: Wolfram Sang

i2c: move locking operations to their own struct

2016-08-30T20:56:14+00:00

This makes it trivial to constify them, so do that. Signed-off-by: Peter Rosin Acked-by: Daniel Vetter Signed-off-by: Wolfram Sang

i2c: core: Add function for finding the bus speed from ACPI, take 2

2016-08-25T22:42:10+00:00

ACPI 5 specification doesn't have property for the I2C bus speed but I2cSerialBus resource descriptor which define each controller-slave connection define the maximum speed supported by that connection. Thus finding the maximum safe speed for the bus is to walk through all I2cSerialBus resources that are associated to I2C controller and use the speed of slowest connection. Add function i2c_acpi_find_bus_speed() to the i2c-core that adapter drivers can call prior registering itself to core. This implies two-step walk through the I2cSerialBus resources: call to i2c_acpi_find_bus_speed() does the first scan and finds the safe bus speed that adapter drivers can set up. Adapter driver registration does the second scan when i2c-core creates the I2C slaves by calling the i2c_acpi_register_devices(). In that way the bus speed is set in case slave device probe gets called during registration and does communication. Previous version commit 55d38d060e99 ("i2c: core: Add function for finding the bus speed from ACPI") got reverted due merge conflicts from commit 525e6fabeae2 ("i2c / ACPI: add support for ACPI reconfigure notifications"). This version is a bit bigger than previous version but is still sharing the lowest and complicated part of I2cSerialBus lookup routines with the existing code. Signed-off-by: Jarkko Nikula Reviewed-by: Andy Shevchenko Signed-off-by: Wolfram Sang

i2c: add i2c_trylock_bus wrapper, use it

2016-08-25T16:02:14+00:00

This unifies usage with i2c_lock_bus and i2c_unlock_bus, and paves the way for the next patch which looks a bit saner with this preparatory work taken care of beforehand. Signed-off-by: Peter Rosin Signed-off-by: Wolfram Sang

Revert "i2c: core: Add function for finding the bus speed from ACPI"

2016-07-19T03:57:23+00:00

This reverts commit 55d38d060e999ca1a3ea6eb132105a0301e4cd04. There were too heavy merge conflicts and the driver code making use of this was not ready yet anyhow. So, we wait one cycle. Signed-off-by: Wolfram Sang