summaryrefslogtreecommitdiffstats
path: root/drivers/i2c/i2c-core.c
Commit message (Collapse)AuthorAgeFilesLines
...
* | i2c / ACPI: add support for ACPI reconfigure notificationsOctavian Purdila2016-07-081-38/+137
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds supports for I2C device enumeration and removal via ACPI reconfiguration notifications that are send as a result of an ACPI table load or unload operation. The code is very similar with the device tree reconfiguration code with only small differences in the way we test and set the enumerated state of the device: * the equivalent of device tree's OF_POPULATED flag is the flags.visited field in the ACPI device and the following wrappers are used to manipulate it: acpi_device_enumerated(), acpi_device_set_enumerated() and acpi_device_clear_enumerated() * the device tree code checks of status of the OF_POPULATED flag to avoid trying to create duplicate Linux devices in two places: once when the controller is probed, and once when the reconfigure event is received; in the ACPI code the check is performed only once when the ACPI namespace is searched because this code path is invoked in both of the two mentioned cases The rest of the enumeration handling is similar with device tree: when the Linux device is unregistered the ACPI device is marked as not enumerated; also, when a device remove notification is received we check that the device is in the enumerated state before continuing with the removal of the Linux device. Signed-off-by: Octavian Purdila <octavian.purdila@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* i2c: only check scl functions when using generic recoveryWolfram Sang2016-05-131-3/+5
| | | | | | | | A custom recovery function doesn't need these pointers to be populated because it may work differently internally. Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Tested-by: Peter Griffin <peter.griffin@linaro.org>
* i2c: mux: relax locking of the top i2c adapter during mux-locked muxingPeter Rosin2016-05-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With a i2c topology like the following GPIO ---| ------ BAT1 | v / I2C -----+----------+---- MUX | \ EEPROM ------ BAT2 there is a locking problem with the GPIO controller since it is a client on the same i2c bus that it muxes. Transfers to the mux clients (e.g. BAT1) will lock the whole i2c bus prior to attempting to switch the mux to the correct i2c segment. In the above case, the GPIO device is an I/O expander with an i2c interface, and since the GPIO subsystem knows nothing (and rightfully so) about the lockless needs of the i2c mux code, this results in a deadlock when the GPIO driver issues i2c transfers to modify the mux. So, observing that while it is needed to have the i2c bus locked during the actual MUX update in order to avoid random garbage on the slave side, it is not strictly a must to have it locked over the whole sequence of a full select-transfer-deselect mux client operation. The mux itself needs to be locked, so transfers to clients behind the mux are serialized, and the mux needs to be stable during all i2c traffic (otherwise individual mux slave segments might see garbage, or worse). Introduce this new locking concept as "mux-locked" muxes, and call the pre-existing mux locking scheme "parent-locked". Modify the i2c mux locking so that muxes that are "mux-locked" locks only the muxes on the parent adapter instead of the whole i2c bus when there is a transfer to the slave side of the mux. This lock serializes transfers to the slave side of the muxes on the parent adapter. Add code to i2c-mux-gpio and i2c-mux-pinctrl that checks if all involved gpio/pinctrl devices have a parent that is an i2c adapter in the same adapter tree that is muxed, and request a "mux-locked mux" if that is the case. Modify the select-transfer-deselect code for "mux-locked" muxes so that each of the select-transfer-deselect ops locks the mux parent adapter individually. Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: muxes always lock the parent adapterPeter Rosin2016-05-041-18/+3
| | | | | | | | | Instead of checking for i2c parent adapters for every lock/unlock, simply override the locking for muxes to always lock/unlock the parent adapter directly. Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: allow adapter drivers to override the adapter lockingPeter Rosin2016-05-041-14/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add i2c_lock_bus() and i2c_unlock_bus(), which call the new lock_bus and unlock_bus ops in the adapter. These funcs/ops take an additional flags argument that indicates for what purpose the adapter is locked. There are two flags, I2C_LOCK_ROOT_ADAPTER and I2C_LOCK_SEGMENT, but they are both implemented the same. For now. Locking the root adapter means that the whole bus is locked, locking the segment means that only the current bus segment is locked (i.e. i2c traffic on the parent side of a mux is still allowed even if the child side of the mux is locked). Also support a trylock_bus op (but no function to call it, as it is not expected to be needed outside of the i2c core). Implement i2c_lock_adapter/i2c_unlock_adapter in terms of the new locking scheme (i.e. lock with the I2C_LOCK_ROOT_ADAPTER flag). Locking the root adapter and locking the segment is the same thing for all root adapters (e.g. in the normal case of a simple topology with no i2c muxes). The two locking variants are also the same for traditional muxes (aka parent-locked muxes). These muxes traverse the tree, locking each level as they go until they reach the root. This patch is preparatory for a later patch in the series introducing mux-locked muxes, which behave differently depending on the requested locking. Since all current users are using i2c_lock_adapter, which is a wrapper for I2C_LOCK_ROOT_ADAPTER, we only need to annotate the calls that will not need to lock the root adapter for mux-locked muxes. I.e. the instances that needs to use I2C_LOCK_SEGMENT instead of i2c_lock_adapter/I2C_LOCK_ROOT_ADAPTER. Those instances are in the i2c_transfer and i2c_smbus_xfer functions, so that mux-locked muxes can single out normal i2c accesses to its slave side and adjust the locking for those accesses. Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: let I2C masters ignore their children for PMLinus Walleij2016-04-121-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using a certain I2C device with runtime PM enabled on a certain I2C bus adaper the following happens: struct amba_device *foo \ struct i2c_adapter *bar \ struct i2c_client *baz The AMBA device foo has its device PM struct set to ignore children with pm_suspend_ignore_children(&foo->dev, true). This makes runtime PM work just fine locally in the driver: the fact that devices on the bus are suspended or resumed individually does not affect its operation, and the hardware does not power up unless transferring messages. However this child ignorance property is not inherited into the struct i2c_adapter *bar. On system suspend things will work fine. On system resume the following annoying phenomenon occurs: - In the pm_runtime_force_resume() path of struct i2c_client *baz, pm_runtime_set_active(&baz->dev); is eventually called. - This becomes __pm_runtime_set_status(&baz->dev, RPM_ACTIVE); - __pm_runtime_set_status() detects that RPM state is changed, and checks whether the parent is: not active (RPM_ACTIVE) and not ignoring its children If this happens it concludes something is wrong, because a parent that is not ignoring its children must be active before any children activate. - Since the struct i2c_adapter *bar does not ignore its children, the PM core thinks that it must indeed go online before its children, the check bails out with -EBUSY, i.e. the i2c_client *baz thinks it can't work because it's parent is not online, and it respects its parent. - In the driver the .resume() callback returns -EBUSY from the runtime_force_resume() call as per above. This leaves the device in a suspended state, leading to bad behaviour later when the device is used. The following debug print is made with an extra printg patch but illustrates the problem: [ 17.040832] bh1780 2-0029: parent (i2c-2) is not active parent->power.ignore_children = 0 [ 17.040832] bh1780 2-0029: pm_runtime_force_resume: pm_runtime_set_active() failed (-16) [ 17.040863] dpm_run_callback(): pm_runtime_force_resume+0x0/0x88 returns -16 [ 17.040863] PM: Device 2-0029 failed to resume: error -16 Fix this by letting all struct i2c_adapter:s ignore their children: i2c children have no business doing keeping their parents awake: they are completely autonomous devices that just use their parent to talk, a usecase which must be power managed in the host on a per-message basis. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: core: use new 8 bit address helper functionWolfram Sang2016-04-111-1/+1
| | | | | Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: prevent endless uevent loop with CONFIG_I2C_DEBUG_COREWolfram Sang2016-03-301-8/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Jan reported this: === After enabling CONFIG_I2C_DEBUG_CORE my system was broken (no network, console login not possible). System log was flooded with the this message: ... [ 608.052077] rtc-ds1307 0-0068: uevent [ 608.052500] rtc-ds1307 0-0068: uevent [ 608.052925] rtc-ds1307 0-0068: uevent ... The culprit is the dev_dbg printk in the i2c uevent handler. If this is activated (for instance by CONFIG_I2C_DEBUG_CORE) it results in an endless loop with systemd-journald. This happens if user-space scans the system log and reads the uevent file to get information about a newly created device, which seems fair use to me. Unfortunately reading the "uevent" file uses the same function that runs for creating the uevent for a new device, generating the next syslog entry. Ideally user-space would implement a recursion detection and after reading the same device file for the 1000th time call it a day, but nevertheless I think we should avoid this problem by removing the debug print completely or using another print variant. The same problem seems to be reported here: https://bugs.freedesktop.org/show_bug.cgi?id=76886 === His patch converted the message to pr_debug, but I think the debug can simply go. We have other means to see code paths these days. This enables us to clean up the function some more while we are here. Reported-by: Jan Glauber <jglauber@cavium.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Acked-by: Alexander Sverdlin <alexander.sverdlin@nokia.com> Tested-by: Jan Glauber <jglauber@cavium.com>
* i2c: immediately mark ourselves as registeredWolfram Sang2016-03-141-1/+4
| | | | | | | | | | Mark the i2c bus as registered right after the the bus_register call, not at the end of init. Otherwise, we can't register our own dummy driver. Reported-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Fixes: 95026658c46ea2 ("i2c: do not use internal data from driver core")
* i2c: do not use internal data from driver coreSudip Mukherjee2016-03-121-2/+4
| | | | | | | | | | | The variable p is a data structure which is used by the driver core internally and it is not expected that busses will be directly accessing these driver core internal only data. Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [wsa: removed the unlikely()] Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: i2c-core: sort includesWolfram Sang2016-02-201-15/+15
| | | | | | | I request this for drivers, so the core should adhere to sorted includes as well. Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: always enable RuntimePM for the adapter deviceWolfram Sang2016-01-101-0/+3
| | | | | | | | | | The adapter device is a logical device. Because of that, it already uses pm_runtime_no_callbacks() in the core. To ensure proper propagation from the children (i2c devices) to the parent of the adapter (the HW device), make sure RuntimePM is enabled in any case. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: make i2c_parse_fw_timings() always visibleWolfram Sang2015-12-171-52/+52
| | | | | | | | | | | This function used to be DT only, so it lived inside a CONFIG_OF block. Now it uses device attributes and must be moved outside of it. No further code changes, only one whitespace improvement. Reported-by: Jim Davis <jim.epost@gmail.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: add generic routine to parse DT for timing informationWolfram Sang2015-12-141-0/+53
| | | | | | | | | Inspired from the i2c-rk3x driver (thanks guys!) but refactored and extended. See built-in docs for further information. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: fix wakeup irq parsingGrygorii Strashko2015-11-201-1/+1
| | | | | | | | | | | | | This patch fixes obvious copy-past error in wake up irq parsing code which leads to the fact that dev_pm_set_wake_irq() will be called with wrong IRQ number when "wakeup" IRQ is not defined in DT. Fixes: 3fffd1283927 ("i2c: allow specifying separate wakeup interrupt in device tree") Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Cc: <stable@vger.kernel.org> # v4.3
* Merge branch 'i2c/for-4.4' of ↵Linus Torvalds2015-11-101-23/+59
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c updates from Wolfram Sang: - New drivers: UniPhier (with and without FIFO) - some drivers got some bigger rework: ismt, designware, img-scb (rcar had to be reverted because issues were showing up just lately) - ACPI: reworked the device scanning and added support for muxes ... and quite a lot of driver bugfixes and cleanups this time. All files touched outside of the i2c realm have proper acks. * 'i2c/for-4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: (70 commits) i2c: rcar: Revert the latest refactoring series i2c: pnx: remove superfluous assignment MAINTAINERS: i2c: drop i2c-pnx maintainer MAINTAINERS: i2c: mark also subdirectories as maintained i2c: cadence: enable driver for ARM64 i2c: i801: Document Intel DNV and Broxton i2c: at91: manage unexpected RXRDY flag when starting a transfer i2c: pnx: Use setup_timer instead of open coding it i2c: add ACPI support for I2C mux ports acpi: add acpi_preset_companion() stub i2c: pxa: Add support for pxa910/988 & new configuration features i2c: au1550: Convert to devm_kzalloc and devm_ioremap_resource i2c-dev: Fix I2C_SLAVE ioctl comment i2c-dev: Fix typo in ioctl name reference i2c: sirf: tune the divider to make i2c bus freq more accurate i2c: imx: Use -ENXIO as error in the NACK case i2c: i801: Add support for Intel Broxton i2c: i801: Add support for Intel DNV i2c: mediatek: add i2c resume support i2c: imx: implement bus recovery ...
| * i2c: add ACPI support for I2C mux portsDustin Byford2015-10-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Although I2C mux devices are easily enumerated using ACPI (_HID/_CID or device property compatible string match), enumerating I2C client devices connected through an I2C mux needs a little extra work. This change implements a method for describing an I2C device hierarchy that includes mux devices by using an ACPI Device() for each mux channel along with an _ADR to set the channel number for the device. See Documentation/acpi/i2c-muxes.txt for a simple example. To make this work the ismt, i801, and designware pci/platform devs now share an ACPI companion with their I2C adapter dev similar to how it's done in OF. This is done on the assumption that power management functions will not be called directly on the I2C dev that is sharing the ACPI node. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Dustin Byford <dustin@cumulusnetworks.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
| * i2c / ACPI: Rework I2C device scanningMika Westerberg2015-10-201-23/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The way we currently scan I2C devices behind an I2C host controller does not work in cases where the I2C device in question is not declared directly below the host controller ACPI node. This is perfectly legal according the ACPI 6.0 specification and some existing systems are doing this. To be able to enumerate all devices which are connected to a certain I2C host controller we need to rework the current I2C scanning routine a bit. Instead of scanning directly below the host controller we scan the whole ACPI namespace for present devices with valid I2cSerialBus() connection pointing to the host controller in question. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Dustin Byford <dustin@cumulusnetworks.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* | i2c: return probe deferred status on dev_pm_domain_attachKieran Bingham2015-10-151-6/+6
|/ | | | | | | | | | | | | | | A change of return status was introduced in commit 3fffd1283927 ("i2c: allow specifying separate wakeup interrupt in device tree") The commit prevents the defer status being passed up the call stack appropriately when dev_pm_domain_attach returns -EPROBE_DEFER. Catch the PROBE_DEFER and clear up the IRQ wakeup status Signed-off-by: Kieran Bingham <kieranbingham@gmail.com> Fixes: 3fffd1283927 ("i2c: allow specifying separate wakeup interrupt in device tree") Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: allow specifying separate wakeup interrupt in device treeDmitry Torokhov2015-08-261-9/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of having each i2c driver individually parse device tree data in case it or platform supports separate wakeup interrupt, and handle enabling and disabling wakeup interrupts in their power management routines, let's have i2c core do that for us. Platforms wishing to specify separate wakeup interrupt for the device should use named interrupt syntax in their DTSes: interrupt-parent = <&intc1>; interrupts = <5 0>, <6 0>; interrupt-names = "irq", "wakeup"; This patch is inspired by work done by Vignesh R <vigneshr@ti.com> for pixcir_i2c_ts driver. Note that the original code tried to preserve any existing wakeup settings from userspace but was not quite right in that regard: it would preserve wakeup flag set by userspace upon driver rebinding; but it would re-arm the wakeup flag if it was disabled by userspace. We think that resetting the flag upon re-binding the driver is proper behavior as the driver is responsible for setting up and handling wakeups. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Tested-by: Vignesh R <vigneshr@ti.com> [wsa: updated the commit message] Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: core: Add support for best effort block read emulationIrina Tirdea2015-08-241-0/+57
| | | | | | | | | | | | | | | There are devices that need to handle block transactions regardless of the capabilities exported by the adapter. For performance reasons, they need to use i2c read blocks if available, otherwise emulate the block transaction with word or byte transactions. Add support for a helper function that would read a data block using the best transfer available: I2C_FUNC_SMBUS_READ_I2C_BLOCK, I2C_FUNC_SMBUS_READ_WORD_DATA or I2C_FUNC_SMBUS_READ_BYTE_DATA. Signed-off-by: Irina Tirdea <irina.tirdea@intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: slave: print warning if slave flag not setWolfram Sang2015-08-241-0/+4
| | | | | | | | Address collisions will be rare, but we should let the user know that slaves have their own address space nonetheless. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: support 10 bit and slave addresses in sysfs 'new_device'Wolfram Sang2015-08-241-1/+11
| | | | | | | | | | We now have seperate address spaces for 10 bit and we-are-slave clients. Update the sysfs device instantiation method to support these types by accepting the address offsets that are assigned to the extra address spaces. Update the documentation, too. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: take address space into account when checking for used addressesWolfram Sang2015-08-241-4/+4
| | | | | | | | | | | | It is not enough to compare the plain address value, we also need to check the flags enabling a different address space. E.g. it is valid to have address 0x50 as a 7-bit address and 0x050 as 10-bit address on the same bus. Same for addresses when we are the slave. Tested-by: Andrey Danin <danindrey@mail.ru> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: apply DT flags when probingWolfram Sang2015-08-241-5/+18
| | | | | | | | | | Check for slave and 10-bit flags when probing and mark the client when found. Improve the address validity check, too Tested-by: Andrey Danin <danindrey@mail.ru> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: make address check indpendent from client structWolfram Sang2015-08-241-6/+5
| | | | | | | | | | | | We want to use this function with struct boardinfo soon, so let's just pass the parameters really needed. We also extend the type of addr, so more types can be input. Remove a superfluous dangling comment while here. Tested-by: Andrey Danin <danindrey@mail.ru> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: rename address check functionsWolfram Sang2015-08-241-6/+6
| | | | | | | | | | | The current naming is based on the arguments of the functions and not on what they do. Even I as the maintainer find this confusing, so let's rename them to something more descriptive. Tested-by: Andrey Danin <danindrey@mail.ru> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: apply address offset for slaves, tooWolfram Sang2015-08-241-3/+19
| | | | | | | | | | | | We want a separate address range for being an I2C slave. Add an offset of 0x1000, so it can be combined with ten bit addresses as well. Add a separate function to create the address value, we will need it later in other places. Tested-by: Andrey Danin <danindrey@mail.ru> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: core: add and export of_get_i2c_adapter_by_node() interfaceVladimir Zapolskiy2015-08-101-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | of_find_i2c_adapter_by_node() call requires quite often missing put_device(), and i2c_put_adapter() releases a device locked by i2c_get_adapter() only. In general module_put(adapter->owner) and put_device(dev) are not interchangeable. This is a common error reproduction scenario as a result of the misusage described above (for clearness this is run on iMX6 platform with HDMI and I2C bus drivers compiled as kernel modules): root@mx6q:~# lsmod | grep i2c i2c_imx 10213 0 root@mx6q:~# lsmod | grep dw_hdmi_imx dw_hdmi_imx 3631 0 dw_hdmi 11846 1 dw_hdmi_imx imxdrm 8674 3 dw_hdmi_imx,imx_ipuv3_crtc,imx_ldb drm_kms_helper 113765 5 dw_hdmi,imxdrm,imx_ipuv3_crtc,imx_ldb root@mx6q:~# rmmod dw_hdmi_imx root@mx6q:~# lsmod | grep i2c i2c_imx 10213 -1 ^^^^^ root@mx6q:~# rmmod i2c_imx rmmod: ERROR: Module i2c_imx is in use To fix existing users of these interfaces and to avoid any further confusion and misusage in future, add one more interface of_get_i2c_adapter_by_node(), it is similar to i2c_get_adapter() in sense that an I2C bus device driver found and locked by user can be correctly unlocked by i2c_put_adapter(). Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: core: manage i2c bus device refcount in i2c_[get|put]_adapterVladimir Zapolskiy2015-08-101-3/+12
| | | | | | | | | | In addition to module_get()/module_put() add get_device()/put_device() calls into i2c_get_adapter()/i2c_put_adapter() exported interfaces. This is done to lock I2C bus device, if it is in use by a client. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: fix leaked device refcount on of_find_i2c_* error pathVladimir Zapolskiy2015-08-011-6/+14
| | | | | | | | | If of_find_i2c_device_by_node() or of_find_i2c_adapter_by_node() find a device by node, but its type does not match, a reference to that device is still held. This change fixes the problem. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: core: only use set_scl for bus recovery after calling prepare_recoveryJan Luebbe2015-07-311-1/+3
| | | | | | | | | | | | Using set_scl may be ineffective before calling the driver specific prepare_recovery callback, which might change into a test mode. So instead of setting SCL in i2c_generic_scl_recovery, move it to i2c_generic_recovery (after the optional prepare_recovery). Signed-off-by: Jan Luebbe <jlu@pengutronix.de> Acked-by: Alexander Sverdlin <alexander.sverdlin@nokia.com> Tested-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* i2c: Mark instantiated device nodes with OF_POPULATEPantelis Antoniou2015-07-091-1/+15
| | | | | | | | | | | | Mark (and unmark) device nodes with the POPULATE flag as appropriate. This is required to avoid multi probing when using I2C and device overlays containing a mux. This patch is also more careful with the release of the adapter device which caused a deadlock with muxes, and does not break the build on !OF since the node flag accessors are not defined then. Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* Merge branch 'i2c/for-4.2' of ↵Linus Torvalds2015-06-251-23/+40
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c updates from Wolfram Sang: "Highlights: - new drivers for Mediatek I2C, APM X-Gene, Broadcom Settop - major updates to at91, davinci - bugfixes to the mux infrastructure when dealing with the new quirk mechanism - more users for the bus recovery feature - further improvements to the slave framework Plus the usual bunch of smaller driver and core improvements and fixes. There is one patch removing old code from an ARM platform. This has been acked by the sh_mobile maintainer Simon Horman" * 'i2c/for-4.2' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: (48 commits) i2c: busses: i2c-bcm2835: limits cdiv to allowed values i2c: sh_mobile: use proper type for timeout i2c: sh_mobile: use adapter default for timeout i2c: rcar: use proper type for timeout i2c: rcar: use adapter default for timeout i2c: designware: Make sure the device is suspended before disabling runtime PM i2c: tegra: apply size limit quirk i2c: tegra: don't advertise SMBUS_QUICK i2c: octeon: remove unused signal handling i2c: davinci: Optimize SCL generation i2c: mux: pca954x: Use __i2c_transfer because of quirks i2c: mux: Use __i2c_transfer() instead of calling parent's master_xfer() i2c: use parent adapter quirks in mux i2c: bcm2835: clear reserved bits in S-Register ARM: shmobile: r8a7740: remove I2C errata handling i2c: sh_mobile: add errata workaround i2c: at91: fix code checker warnings i2c: busses: xgene-slimpro: fix incorrect __init declation for probe i2c: davinci: Avoid sending to own address i2c: davinci: Refactor i2c_davinci_wait_bus_not_busy() ...
| * i2c: core: Reduce stack size of acpi_i2c_space_handler()Jarkko Nikula2015-06-031-16/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sizeof(struct i2c_client) is 1088 bytes on a CONFIG_X86_64=y build and produces following warning when CONFIG_FRAME_WARN is set to 1024: drivers/i2c/i2c-core.c: In function ‘acpi_i2c_space_handler’: drivers/i2c/i2c-core.c:367:1: warning: the frame size of 1152 bytes is larger than 1024 bytes [-Wframe-larger-than=] This is not critical given that kernel stack is 16 kB on x86_64 but lets reduce the stack usage by allocating the struct i2c_client from the heap. Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
| * i2c: core: fix typo in commentShailendra Verma2015-06-011-1/+1
| | | | | | | | | | Signed-off-by: Shailendra Verma <shailendra.capricorn@gmail.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
| * i2c: check for proper length of the reg propertyWolfram Sang2015-06-011-1/+1
| | | | | | | | | | | | | | | | int is vague, let's simply use the type of the variable in question. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
| * i2c: slave: add error messages to slave coreWolfram Sang2015-06-011-5/+17
| | | | | | | | | | | | | | | | | | Inform users what went wrong from the core, so drivers don't have to do it. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* | i2c / ACPI: Assign IRQ for devices that have GpioInt automaticallyMika Westerberg2015-05-131-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Following what DT already does. If the device does not have ACPI Interrupt resource but instead it has one or more GpioInt resources listed below it, we take the first GpioInt resource, convert it to suitable Linux IRQ number and pass it to the driver instead. This makes drivers simpler because the don't need to care about GPIOs at all if only thing they need is interrupt. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* | i2c / ACPI: Use 0 to indicate that device does not have interrupt assignedMika Westerberg2015-05-131-2/+1
|/ | | | | | | | | | This is the convention used in most parts of the kernel including DT counterpart of I2C slave enumeration. To make things consistent do the same for ACPI I2C slave enumeration path as well. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* i2c: Mark adapter devices with pm_runtime_no_callbacksCharles Keepax2015-04-231-0/+2
| | | | | | | | | | | | | | | | | | | Commit 523c5b89640e ("i2c: Remove support for legacy PM") removed the PM ops from the bus type, which causes the pm operations on the s3c2410 adapter device to fail (-ENOSUPP in rpm_callback). The adapter device doesn't get bound to a driver and as such can't have its own pm_runtime callbacks. Previously this was fine as the bus callbacks would have been used, but now this can cause devices which use PM runtime and are attached over I2C to fail to resume. This commit fixes this issue by marking all adapter devices with pm_runtime_no_callbacks, since they can't have any. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Acked-by: Beata Michalska <b.michalska@samsung.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Fixes: 523c5b89640e Cc: stable@kernel.org
* i2c: core: Export bus recovery functionsMark Brown2015-04-151-0/+3
| | | | | | | | | | | | | | | | Current -next fails to link an ARM allmodconfig because drivers that use the core recovery functions can be built as modules but those functions are not exported: ERROR: "i2c_generic_gpio_recovery" [drivers/i2c/busses/i2c-davinci.ko] undefined! ERROR: "i2c_generic_scl_recovery" [drivers/i2c/busses/i2c-davinci.ko] undefined! ERROR: "i2c_recover_bus" [drivers/i2c/busses/i2c-davinci.ko] undefined! Add exports to fix this. Fixes: 5f9296ba21b3c (i2c: Add bus recovery infrastructure) Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* Merge tag 'pm+acpi-4.1-rc1' of ↵Linus Torvalds2015-04-141-2/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management and ACPI updates from Rafael Wysocki: "These are mostly fixes and cleanups all over, although there are a few items that sort of fall into the new feature category. First off, we have new callbacks for PM domains that should help us to handle some issues related to device initialization in a better way. There also is some consolidation in the unified device properties API area allowing us to use that inferface for accessing data coming from platform initialization code in addition to firmware-provided data. We have some new device/CPU IDs in a few drivers, support for new chips and a new cpufreq driver too. Specifics: - Generic PM domains support update including new PM domain callbacks to handle device initialization better (Russell King, Rafael J Wysocki, Kevin Hilman) - Unified device properties API update including a new mechanism for accessing data provided by platform initialization code (Rafael J Wysocki, Adrian Hunter) - ARM cpuidle update including ARM32/ARM64 handling consolidation (Daniel Lezcano) - intel_idle update including support for the Silvermont Core in the Baytrail SOC and for the Airmont Core in the Cherrytrail and Braswell SOCs (Len Brown, Mathias Krause) - New cpufreq driver for Hisilicon ACPU (Leo Yan) - intel_pstate update including support for the Knights Landing chip (Dasaratharaman Chandramouli, Kristen Carlson Accardi) - QorIQ cpufreq driver update (Tang Yuantian, Arnd Bergmann) - powernv cpufreq driver update (Shilpasri G Bhat) - devfreq update including Tegra support changes (Tomeu Vizoso, MyungJoo Ham, Chanwoo Choi) - powercap RAPL (Running-Average Power Limit) driver update including support for Intel Broadwell server chips (Jacob Pan, Mathias Krause) - ACPI device enumeration update related to the handling of the special PRP0001 device ID allowing DT-style 'compatible' property to be used for ACPI device identification (Rafael J Wysocki) - ACPI EC driver update including limited _DEP support (Lan Tianyu, Lv Zheng) - ACPI backlight driver update including a new mechanism to allow native backlight handling to be forced on non-Windows 8 systems and a new quirk for Lenovo Ideapad Z570 (Aaron Lu, Hans de Goede) - New Windows Vista compatibility quirk for Sony VGN-SR19XN (Chen Yu) - Assorted ACPI fixes and cleanups (Aaron Lu, Martin Kepplinger, Masanari Iida, Mika Westerberg, Nan Li, Rafael J Wysocki) - Fixes related to suspend-to-idle for the iTCO watchdog driver and the ACPI core system suspend/resume code (Rafael J Wysocki, Chen Yu) - PM tracing support for the suspend phase of system suspend/resume transitions (Zhonghui Fu) - Configurable delay for the system suspend/resume testing facility (Brian Norris) - PNP subsystem cleanups (Peter Huewe, Rafael J Wysocki)" * tag 'pm+acpi-4.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (74 commits) ACPI / scan: Fix NULL pointer dereference in acpi_companion_match() ACPI / scan: Rework modalias creation when "compatible" is present intel_idle: mark cpu id array as __initconst powercap / RAPL: mark rapl_ids array as __initconst powercap / RAPL: add ID for Broadwell server intel_pstate: Knights Landing support intel_pstate: remove MSR test cpufreq: fix qoriq uniprocessor build ACPI / scan: Take the PRP0001 position in the list of IDs into account ACPI / scan: Simplify acpi_match_device() ACPI / scan: Generalize of_compatible matching device property: Introduce firmware node type for platform data device property: Make it possible to use secondary firmware nodes PM / watchdog: iTCO: stop watchdog during system suspend cpufreq: hisilicon: add acpu driver ACPI / EC: Call acpi_walk_dep_device_list() after installing EC opregion handler cpufreq: powernv: Report cpu frequency throttling intel_idle: Add support for the Airmont Core in the Cherrytrail and Braswell SOCs intel_idle: Update support for Silvermont Core in Baytrail SOC PM / devfreq: tegra: Register governor on module init ...
| * driver core / ACPI: Represent ACPI companions using fwnode_handleRafael J. Wysocki2015-03-161-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we have struct fwnode_handle, we can use that to point to ACPI companions from struct device objects instead of pointing to struct acpi_device directly. There are two benefits from that. First, the somewhat ugly and hackish struct acpi_dev_node can be dropped and, second, the same struct fwnode_handle pointer can be used in the future to point to other (non-ACPI) firmware device node types. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Grant Likely <grant.likely@linaro.org>
* | Merge branch 'i2c/for-next' of ↵Linus Torvalds2015-04-141-2/+71
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c updates from Wolfram Sang: "Most notable: - introducing the i2c_quirk infrastructure. Now, flaws of I2C controllers can be described and the core will check if the flaws collide with the messages to be sent - wait_for_completion return type cleanup series - new drivers for Digicolor, Netlogic XLP, Ingenic JZ4780 - updates to the I2C slave framework which include API changes. Its only user was updated, too. Documentation was finally added - changed dynamic bus numbering for the DT case. This could change bus numbers for users. However, it fixes a collision where dynamic and static busses request the same id. - driver bugfixes, cleanups" * 'i2c/for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: (52 commits) i2c: xlp9xx: Driver for Netlogic XLP9XX/5XX I2C controller of: Add vendor prefix 'netlogic' i2c: davinci: use ICPFUNC to toggle I2C as gpio for bus recovery i2c: davinci: use bus recovery infrastructure i2c: change input parameter to i2c_adapter for prepare/unprepare_recovery i2c: i2c-mux-gpio: remove error messages for probe deferrals i2c: jz4780: Add i2c bus controller driver for Ingenic JZ4780 i2c: dln2: set the device tree node of the adapter i2c: davinci: fixup wait_for_completion_timeout handling i2c: mpc: Fix ISR return value i2c: slave-eeprom: add more info when to increase the pointer i2c: slave: add documentation for i2c-slave-eeprom Documentation: i2c: describe the new slave mode i2c: slave: rework the slave API i2c: add support for the Digicolor I2C controller i2c: busses with dynamic ids should start after fixed ids for DT of: base: add function to get highest id of an alias stem i2c: designware: Suppress error message if platform_get_irq() < 0 i2c: mpc: assign the correct prescaler from SVR i2c: img-scb: fixup of wait_for_completion_timeout return handling ...
| * i2c: change input parameter to i2c_adapter for prepare/unprepare_recoveryGrygorii Strashko2015-04-101-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch changes type of input parameter for prepare/unprepare_recovery() callbacks from struct i2c_bus_recovery_info * to struct i2c_adapter *. This allows to simplify implementation of these callbacks and avoid type conversations from i2c_bus_recovery_info to i2c_adapter. The i2c_bus_recovery_info can be simply retrieved from struct i2c_adapter which contains pointer on it. There are no users currently, so this is safe to do. Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Alexander Sverdlin <alexander.sverdlin@nokia.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
| * i2c: busses with dynamic ids should start after fixed ids for DTWolfram Sang2015-03-181-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make sure dynamic ids do not interfere with fixed ones and let them start after the highest fixed id. This patch might cause different bus-numbers than before for dynamic ids, however it fixes a bug. Assume: - fixed id0 defers probe - fixed id1 succeeds and registers a muxed bus with dynamic id - muxed bus gets id0 - fixed id0 wants to probe again, but its fixed id is gone now - fixed id0 probe fails With this patch, the fixed ids are always reserved in the DT case. For legacy board init, we already have a mechanism like this in i2c_register_board_info(). Reported-by: Bob Feretich <bob.feretich@rafresearch.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
| * i2c: add quirk checks to coreWolfram Sang2015-03-131-0/+62
| | | | | | | | | | | | | | | | | | | | | | Let the core do the checks if HW quirks prevent a transfer. Saves code from drivers and adds consistency. Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Tested-by: Ray Jui <rjui@broadcom.com> Tested-by: Ivan T. Ivanov <iivanov@mm-sol.com> Tested-by: Neelesh Gupta <neelegup@linux.vnet.ibm.com> Tested-By: Ludovic Desroches <ludovic.desroches@atmel.com>
* | Revert "i2c: core: Dispose OF IRQ mapping at client removal time"Jakub Kicinski2015-03-121-3/+0
|/ | | | | | | | | | | | | | | | | | | | | | This reverts commit e4df3a0b6228 ("i2c: core: Dispose OF IRQ mapping at client removal time") Calling irq_dispose_mapping() will destroy the mapping and disassociate the IRQ from the IRQ chip to which it belongs. Keeping it is OK, because existent mappings are reused properly. Also, this commit breaks drivers using devm* for IRQ management on OF-based systems because devm* cleanup happens in device code, after bus's remove() method returns. Signed-off-by: Jakub Kicinski <kubakici@wp.pl> Reported-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> [wsa: updated the commit message with findings fromt the other bug report] Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org Fixes: e4df3a0b6228
* Merge branch 'i2c/for-3.20' of ↵Linus Torvalds2015-02-211-148/+14
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c updates from Wolfram Sang: "Summary: - legacy PM code removed from the core, there were no users anymore (thanks to Lars-Peter Clausen) - new driver for Broadcom iProc - bigger driver updates for designware, rk3x, cadence, ocores - a bunch of smaller updates and bugfixes" * 'i2c/for-3.20' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: (31 commits) i2c: ocores: rework clk code to handle NULL cookie i2c: designware-baytrail: another fixup for proper Kconfig dependencies i2c: fix reference to functionality constants definition i2c: iproc: Add Broadcom iProc I2C Driver i2c: designware-pci: update Intel copyright line i2c: ocores: add common clock support i2c: hix5hd2: add COMPILE_TEST i2c: clarify comments about the dev_released completion i2c: ocores: fix clock-frequency binding usage i2c: tegra: Maintain CPU endianness i2c: designware-baytrail: use proper Kconfig dependencies i2c: designware: Do not calculate SCL timing parameters needlessly i2c: do not try to load modules for of-registered devices i2c: designware: Add Intel Baytrail PMIC I2C bus support i2c: designware: Add i2c bus locking support of: i2c: Add i2c-mux-idle-disconnect DT property to PCA954x mux driver i2c: designware: use {readl|writel}_relaxed instead of readl/writel i2c: designware-pci: no need to provide clk_khz i2c: designware-pci: remove Moorestown support i2c: imx: whitespace and checkpatch cleanup ...